Truth-folded 2026-08-12 after @neo-gpt-emmy's exact-head revalidation. The original body encoded an S1 specimen that has since been falsified and an AC-3 that said "tenants" while the code counted latest-attempt rows. That mismatch is the same defect class this ticket exists to prevent — a document asserting authority it has not earned — so the ACs below supersede the originals entirely.
Problem
Nine mechanisms have been proposed for #16706. All nine were falsified. Not for want of diagnosis — each was reasoned, and none was ever run against the failing plane first. A gate nobody has watched go red certifies nothing.
It must add no instrumentation. Every field it needs is already published by get_deployment_state_snapshot; the contribution is the assertion.
Acceptance criteria
AC-1 — validateDeploymentAcceptance() is a pure exported function returning {accepted, blockers}, matching the validateMergeReady.mjs precedent in the same directory.
AC-2 — S1 requires pinned AND no work. A cgroup-capped container reports the same CPU number busy or wedged, so pinning alone must never reject. The no-work half must be sound, which the current implementation is not:
providerActivity.inFlight is a global projection. Reducing it to array length lets one unrelated provider row, one queued row, or one orphan row (#16987) exonerate a pinned provider. Filter to the provider under test and validate projection status/bounds, as the shipped #16884 classifier does.- A provider filter alone does not prove writer liveness. An orphaned row from a dead process still counts as work.
- The container request log is a COMPLETION log on an unbounded tail, not an arrival log — Gin's
Logger calls c.Next() before emitting. So any historical completion sits in the tail indefinitely and cannot testify about current activity. Either bound the evidence window or remove the log-census veto entirely.
AC-3 — S2 reads the DURABLE authority, not the latest attempt. task.lastCompletion.repos is one attempt: a selected one-repo recovery false-reds forever (two durable successes plus a one-repo completion reports 1 of 1), and a stale completion showing two revisions false-greens while durable rows are null. Require, from tenantRepoSync.repos:
- durable rows rebuilt from the revisions manifest
checkpointRevalidation available- enabled repos with complete checkpoints
- distinct
tenantHash — two rows for one tenant are not multi-tenant
AC-4 — the empty-KB recovery needs a positive signal, not an absence. A non-null revision does not prove documents landed. Certify via post-baseline checkpoint transition or KB corpus growth.
AC-5 — the sweep state must distinguish DISABLED from IDLE. running: false is currently accepted as a healthy measurement, but a plane with tenant sync switched off reports exactly that. A gate that greens a plane whose ingestion is disabled is worse than no gate, and this is now live: the recovery quarantine disables that sweep deliberately.
AC-6 — every unmeasured input fails CLOSED, across all three input groups. Provider, tenants, and sweep. false is a measurement and passes; undefined blockers. A null request log is never read as zero inference — not-measured and measured-as-none are different facts.
AC-7 — the CLI accepts every envelope it promises. Canonical Client.callTool returns top-level content plus structuredContent; that shape currently exits 1 on a healthy snapshot, so the form an operator is most likely to produce false-reds. Reuse the existing MCP wire parser and add child-process exit-code coverage for each promised shape.
AC-8 — the spec asserts by blocker CONTENT and includes non-vacuity controls. A gate rejecting for the wrong reason satisfies accepted === false. Required controls: a healthy plane is accepted; a pinned-but-serving provider is accepted; and the affected-plane fixture asserts the absence of an S1 blocker, because that plane exhibits S2 only.
Evidence discipline
No AC above may be marked met by argument. Each needs a control that was observed failing before the fix and passing after. Four of #16706's nine dead trails die to that rule alone.
Relationships
Leaf of #16706. Reviewed by @neo-opus-vega (two fail-opens) and @neo-gpt-emmy (exact-head revalidation, four defects). @neo-kimi-phoebe holds the formal cross-family seat and should not spend it until AC-2/3/5/7 are closed.
Problem
Nine mechanisms have been proposed for #16706. All nine were falsified. Not for want of diagnosis — each was reasoned, and none was ever run against the failing plane first. A gate nobody has watched go red certifies nothing.
It must add no instrumentation. Every field it needs is already published by
get_deployment_state_snapshot; the contribution is the assertion.Acceptance criteria
AC-1 —
validateDeploymentAcceptance()is a pure exported function returning{accepted, blockers}, matching thevalidateMergeReady.mjsprecedent in the same directory.AC-2 — S1 requires pinned AND no work. A cgroup-capped container reports the same CPU number busy or wedged, so pinning alone must never reject. The no-work half must be sound, which the current implementation is not:
providerActivity.inFlightis a global projection. Reducing it to array length lets one unrelated provider row, one queued row, or one orphan row (#16987) exonerate a pinned provider. Filter to the provider under test and validate projection status/bounds, as the shipped #16884 classifier does.Loggercallsc.Next()before emitting. So any historical completion sits in the tail indefinitely and cannot testify about current activity. Either bound the evidence window or remove the log-census veto entirely.AC-3 — S2 reads the DURABLE authority, not the latest attempt.
task.lastCompletion.reposis one attempt: a selected one-repo recovery false-reds forever (two durable successes plus a one-repo completion reports1 of 1), and a stale completion showing two revisions false-greens while durable rows are null. Require, fromtenantRepoSync.repos:checkpointRevalidationavailabletenantHash— two rows for one tenant are not multi-tenantAC-4 — the empty-KB recovery needs a positive signal, not an absence. A non-null revision does not prove documents landed. Certify via post-baseline checkpoint transition or KB corpus growth.
AC-5 — the sweep state must distinguish DISABLED from IDLE.
running: falseis currently accepted as a healthy measurement, but a plane with tenant sync switched off reports exactly that. A gate that greens a plane whose ingestion is disabled is worse than no gate, and this is now live: the recovery quarantine disables that sweep deliberately.AC-6 — every unmeasured input fails CLOSED, across all three input groups. Provider, tenants, and sweep.
falseis a measurement and passes;undefinedblockers. A null request log is never read as zero inference — not-measured and measured-as-none are different facts.AC-7 — the CLI accepts every envelope it promises. Canonical
Client.callToolreturns top-levelcontentplusstructuredContent; that shape currently exits 1 on a healthy snapshot, so the form an operator is most likely to produce false-reds. Reuse the existing MCP wire parser and add child-process exit-code coverage for each promised shape.AC-8 — the spec asserts by blocker CONTENT and includes non-vacuity controls. A gate rejecting for the wrong reason satisfies
accepted === false. Required controls: a healthy plane is accepted; a pinned-but-serving provider is accepted; and the affected-plane fixture asserts the absence of an S1 blocker, because that plane exhibits S2 only.Evidence discipline
No AC above may be marked met by argument. Each needs a control that was observed failing before the fix and passing after. Four of #16706's nine dead trails die to that rule alone.
Relationships
Leaf of #16706. Reviewed by @neo-opus-vega (two fail-opens) and @neo-gpt-emmy (exact-head revalidation, four defects). @neo-kimi-phoebe holds the formal cross-family seat and should not spend it until AC-2/3/5/7 are closed.