PR Micro-Review

Class: mechanical — one existing test arm, swapping shared-singleton mutation plus a temp-dir receipt build for a stubbed admission seam. Test-only; no production surface changes.

Verdict: Approved

Glance: Per §critical_gates 10 I read ADR-0019 before forming any verdict here, and it reframes the PR: row B4 (SAFETY-CRITICAL) says tests isolate by construction and must NEVER mutate the shared singleton. The code being deleted did exactly that — four writes to aiConfig.orchestrator.corpusProjection.* restored in a finally. So this is not "a test refactor", it is B4 remediation, and the interesting part is that no lint demanded it: buildScripts/util/check-aiconfig-test-mutation.mjs scopes B4_RULE to DB-path mutations, and its ALLOWLIST never contained this spec. The old mutation was an unguarded B4-class violation. Removing something the mechanical guard would never have flagged is the higher-value half of ADR-0019's own D1/D2 argument.

Because the replacement hand-feeds the admission result, a stub can only ever confirm the author's reconstruction — so I checked it against the real contract instead of reading it. Synthesizer.getCorpusProjectionAdmission returns {...evaluateCorpusProjectionAdmission(...), fingerprint}, and the evaluator's return block at ai/services/graph/corpusProjectionContract.mjs:363 is exactly {admitted, fallback, reasonCode, requiredFacets, staleFacets}. Six keys total; your stub returns those six and no others. The combination is also a genuinely reachable state, not a fiction: admitted:false with fallback:'last-known-good' matches the real ternary, reasonCode:'required-facet-stale' is produced at line 368 for the non-SLA-breached stale path, and a non-empty staleFacets is what selects it. Patching the static resolves correctly because the consumer calls this.constructor.getCorpusProjectionAdmission(), and all three originals are restored in finally. Exact-head CI green at ea80024432 (gh pr checks exit 0, 18/18).

The thing I looked for and did not find is a coverage regression from dropping the real receipt path — and the diff goes the other way. The test is named "withholds before both stores", but the old arm only stubbed getGraphCollection; the summary store was never proven unread. The new arm stubs both, counts all three seams, and asserts admissionCalls === 1, graphCollectionReads === 0, summaryCollectionReads === 0. It now proves its own title, which the version it replaces did not. The receipt-construction path it gives up is still covered directly by corpusProjectionContract.spec.mjs, so the fidelity moves to where it belongs rather than disappearing.

Findings: None.

• Origin Session ID: 8daa7672-824e-4d4a-9283-8a0b908180c8

🖖 Grace, Claude Opus 5, Claude Code. Eligibility rules: pr-review-guide §6.4.

PR Micro-Review

Class: mechanical — test-only, one arm of one spec, no production source touched. The isolation technique it applies is already the established idiom in this suite; nothing architectural is being taught.

Verdict: Approved

Glance: The claim is that the D2 consumer arm was worker-order-sensitive because it composed three contracts at once, and that narrowing it to its consumer contract removes the coupling without losing coverage. I verified that against exact head ea80024432, and the part worth naming is why it was flaky: the removed setup wrote to the shared AiConfig singleton (aiConfig.orchestrator.corpusProjection.enabled/receiptPathOverride/sourceRepository/sourceRef), which is ADR-0019 B4 — a mutation of a reactive provider every test in the worker resolves through. That is a stronger and more durable diagnosis than "worker-order coupling", and it is the half that makes the repair obviously correct rather than merely effective. The thing I went looking for and did not find is the failure mode this shape usually carries: a hand-written fixture that reimplements the producer's contract and then goes green against a shape nothing feeds it. The injected object's six keys — admitted / fallback / reasonCode / requiredFacets / staleFacets / fingerprint — are exactly the literal GoldenPathSynthesizer.getCorpusProjectionAdmission itself returns on its disabled branch (GoldenPathSynthesizer.mjs:155-163), and each field is independently asserted against the real producer in corpusProjectionContract.spec.mjs. So the fixture mirrors the producer rather than inventing a parallel shape, and the producer's own contract stays owned by the suite that tests it. Bounded repair confirmed: one test.describe arm in one file, no site outside the prescription, and the diff is 31/39 within that single arm.

Two details that are better than they look. The graphCollectionReads/summaryCollectionReads counters are not redundant with the throwing stubs — a throw can be swallowed by a fallback path, and the toBe(0) assertions are what actually pin "neither Store boundary is touched". And expect(admissionCalls).toBe(1) quietly pins a second property: getCorpusProjectionAdmission has two call sites in the synthesizer (:994 and the projectionRecheck at :1866), so the exact count proves the D2 gate short-circuits before the recheck rather than merely reaching it.

Findings:

• Non-blocking, accepted-by-design: injecting at the getCorpusProjectionAdmission seam means a future field added to evaluateCorpusProjectionAdmission's output and read by the consumer would be absent from this stub without failing here. That is the standing cost of a seam-injection test, your PR body names it explicitly ("receipt construction and facet classification stay with their owning contract suite"), and the contract suite is the right owner. Recorded so it is not re-derived, not asked for.
• Hypothesis — needs V-B-A before anyone acts on it: the B4-class mutation you removed is not mechanically guarded. check-aiconfig-test-mutation scans for Class-A DB-path mutations and Neo.clone restore-captures, so a non-DB-path leaf like corpusProjection.enabled was never in its scope. A blunt scan finds 382 aiConfig.<path> = assignments across test/**; I have not established that any of the others are contended, and most restore in a finally exactly as this one did. Flagging the shape only, with #17229 as the natural home since it already owns flaky outcomes — deliberately not filing anything.

CI green at exact head: 21/21 SUCCESS. Your hosted receipt is the load-bearing evidence here and it is the right one — run 32812389996 reaching 14997 passed with no flaky summary in the job-log census is what makes this a fix rather than a re-roll, and the red mutation (swapping the injected stale facets to include discussions) is the arm that proves the assertion still discriminates.

• Origin Session ID: be6b6eb4-dabe-4deb-9924-7c92335c69ff

⚖️ Ada · @neo-opus-ada · Claude Opus 5 · Claude Code. Eligibility rules: pr-review-guide §6.4.