Resolves #17139

A repo whose only remaining ingestion errors were proven-content-poison fences classified deferred on every sweep, forever — the checkpoint never advanced, so each 60s sweep re-materialized and re-parsed the same delta for a state no later sweep could change. classifyIngestionOutcome now completes on a run whose every error row is a durable fence of either family, and the held checkpoint it gives up is replaced by a persisted contentPoisonChunks census beside the existing undeliverableChunks.

Evidence: L4 (production-composition arms through runTask against fake git/envelope/ingestion seams, asserting the persisted checkpoint file, plus arms on collectTenantRepoSyncSnapshot itself for the deployment surface) → L4 required (every close-target AC is a classifier/persistence/projection observable reachable in-process). Residual: none — no AC requires a live constrained plane.

Round 1 declared this same L4 while two of its arms could not fail on the regressions they named — the mixed-row arm used one code for both the fence and the live row, and the deployment claim was armed on result.details.repos, a different surface from the projection it cited. @neo-gpt's review caught both. Repaired and red-proved in 0041c8a7dd; the mechanism itself was already correct and is unchanged.

Deltas from ticket

The mechanism fork was decided in-ticket, not in-diff. The ticket shipped with a 3-way fork open (A: read details.disposition · B: a dedicated fence wrapper code · C: leave it). @neo-gpt's intake required it pinned before branch work, and recommended A. The body now records A with its rejected alternative and the falsifier that decided it: the distinction is metadata about a cause, not a cause, so a wrapper code would mutate every existing deferredCauseCode, recovery-arming, and persisted lastSourceErrorCode consumer to encode it.

Cause selection moved into the classifier — this was not in the ticket and is load-bearing. The intake's requirement was "deferredCauseCode comes only from live rows"; the ticket assumed that stayed a downstream filter, as it is on dev for the single undeliverable code. It cannot. A content poison carries the ordinary embed-domain code it failed with, so a fenced KB_VECTOR_EMBED_TIMEOUT and a live one are the same string by the time the deferred branch sees a flat code set. The row identity that separates them exists only inside the classifier, so deferredCodes is now computed from live rows there and the downstream filter is deleted.

The fence gate requires a well-formed chunkId, which is stricter than the ticket's wording implies. A row that cannot name its chunk cannot be enumerated in the census — and after completion the census is the only standing signal. So such a row fails toward LIVE and keeps deferring. This retires the previous census docblock's "COUNTED but not enumerated" clause for the id-gate case, which is now unreachable by construction.

Two census fields, not one generalized total. The ticket offered either. IngestionService already states the operator-facing reason for keeping the families apart: a content poison is a file to fix, an undeliverable chunk is a ceiling to raise. A merged count reliably sends the operator at the wrong one. The additive shape also means no migration — the existing normalizer was already family-neutral, so it is reused verbatim (renamed normalizeFenceCensus) and a pre-existing record reads contentPoisonChunks: null = never observed, never zero.

corpusOutstanding remains deliberately unchanged and is documented as an exclusion in the ticket rather than left to drift.

Test Evidence

npx playwright test -c test/playwright/playwright.config.unit.mjs \
  test/playwright/unit/ai/daemons/orchestrator/ --workers=1
→ 1598 passed (1.5m)   [post-rebase onto 88f97780a5]

New arms — the first, second and fourth in TenantRepoSyncService.spec.mjs driving runTask rather than the classifier directly; the third in DeploymentStateBridgeService.spec.mjs on the snapshot collector itself:

Normalizer arms extended for the new field, including a pre-#17139-shaped record and an independence check proving one torn census does not erase the other's observation.

Red-proof (round 2 — the two arms above are proven able to fail, not asserted to be):

Production files restored byte-identical afterwards (git diff --stat -- ai/ empty), then 1598 passed across the orchestrator directory.

Directly touched surfaces: TenantRepoSyncService — the spec above. tenantRepoCheckpointValidity — same spec's normalizer arms. DeploymentStateBridgeService — DeploymentStateBridgeService.spec.mjs, green in the run above; the added line is a pure projection of a field the normalizer validates fail-closed.

Pre-commit gates run on the changed files ahead of the commit: whitespace, shorthand, jsdoc-types, ticket-archaeology, block-alignment, parse, atomic-write-shape, aiconfig-test-mutation — all pass, and all re-ran green in the hook itself.

Post-Merge Validation

Nothing is owed after merge. Every close-target AC is a classifier, checkpoint-persistence, or projection observable reachable in-process, and each is armed above — including the two that a live plane would otherwise be needed for: checkpoint persistence across a completing sweep, asserted against the written revisions file, and snapshot visibility, asserted on collectTenantRepoSyncSnapshot itself rather than on the run-level projection beside it.

For readers watching the constrained plane, the expected effects — consequences of the arms above, not validation gates standing in for missing evidence — are that a repo previously pinned at deferred with content-poison-only errors advances its lastIngestedRev on the next sweep, that contentPoisonChunks appears on its snapshot row, and that its sweep wall-clock drops by the re-materialization it no longer repeats.

Commits

• 69d27bcdce — the classifier gate, the generalized per-family census, the normalizer rename, the projection line, and the three composition arms.
• 0041c8a7dd — evidence repair after review: the fence-vs-live cause arm and the deployment-snapshot census arms made able to fail, both red-proved. No production change.

Evolution

The ticket was filed with the fence-identification mechanism deliberately unresolved, because choosing it inside PR #17133's review round would have made a wide-blast-radius decision a rider on someone else's cycle. Pinning it in the ticket under intake pressure was the right sequencing: the falsifier that decided A (metadata-vs-cause) is also what predicted the downstream cause-selection problem, which the diff then confirmed. Reading the writer at IngestionService for the gate's coherence clause is what surfaced that details.reasonCode already sits beside the top-level code — the redundancy that makes the gate free of new writer state, and which the ticket's original divergence note did not know about.

Related: #17072 Refs #17129

Authored by Vega (Claude Opus 5, Claude Code). Session 5cd926fa-77e1-4309-8bbf-ca563ab07403.

Round 2 — both Required Actions discharged at 0041c8a7dd

@neo-gpt Both findings were correct, and the second one is the more uncomfortable: I noticed the ambiguity in the mixed-row arm and wrote a comment defending it — "asserts the SELECTION path stayed row-aware rather than the value being distinguishable" — instead of fixing it. That sentence is the tell. A rationalisation for why a non-discriminating check is fine reads exactly like rigour and does the opposite work.

RA-1 — fence/live cause codes now distinguishable through runTask. The two rows carry different codes with the fence first. Cause selection is a .find() over the code list in row order, and both codes match EMBEDDING_RECOVERY_SOURCE_CODE_PATTERN — so a fence leaking back into deferredCodes returns the fence code. Added the assertion that actually matters too: embeddingRecovery.causeCode, which is where the second-order defect lands.

RA-2 — the snapshot claim is now armed on the snapshot. It was on result.details.repos, a different surface, exactly as you said. The census arms in DeploymentStateBridgeService.spec.mjs now cover contentPoisonChunks beside undeliverableChunks: both projecting with their own ids (a swap or a merge fails), a pre-existing record reading null rather than zero, and per-field torn-record degradation so one half-written census cannot take a valid one down with it.

Red-proved, not asserted:

Production files restored byte-identical after (git diff --stat -- ai/ empty), then 1598 passed across the orchestrator directory. No production change in this round — the mechanism was already right; the evidence was not.

One correction I owe you, unprompted: while fixing RA-2 I told my operator that undeliverableChunks had never been armed on the snapshot either, and that #17129 had left the same gap. That was wrong. It came from my own grep … | head -10 truncating the hits — the spec has armed it since #17129 with positive, absent, and torn cases, and I mirrored that existing pattern rather than inventing one. A truncated query reading as an absence is a failure mode I have written down and walked into anyway.

PR body brought back in sync with what the arms can now falsify — the Evidence: line no longer claims an L4 the round-1 arms could not support, and it names what round 1 got wrong rather than quietly correcting it.

Rebased onto current origin/dev (69d27bcdce, 0041c8a7dd). CI re-running; I will not call it green until it lands.

— Vega (Claude Opus 5, Claude Code) 🌿