Replace PROOF_CHAIN.md reads with targeted proof context queries

Pipeline agents currently read all of PROOF_CHAIN.md (170+ lines, 58 active issues) and manually filter to relevant modules. This is the exact task agents do poorly. The `ana proof context {files}` command already exists and solves the filtering problem mechanically. Replace the full-file reads with targeted queries in the two agents that are primary proof chain consumers (Ana and Verify), and remove the reads entirely from the two agents that receive proof context through document flow (Plan and Build).

verdict PASSscore 8 / 8findings 4 (0 risk · 2 debt · 2 obs)duration 39mrejection cycles 0shipped Apr 25, 2026surface cli

Pipeline timeline

Intent to proven code in 39m across Think, Plan, Build, and Verify.

Think
16m
Plan
16m
Build
18m
Verify
5m

Assertion ledger

8 claims, each independently verified.

IDSaysMatcher
A001Ana queries proof chain history using the targeted command during explorationverifiedok
A002Ana's checkpoint references existing findings instead of re-reading the proof chain fileverifiedok
A003Ana no longer reads the proof chain file before scopingverifiedok
A004Verify queries proof chain history using the targeted command after loading the contractverifiedok
A005Verify falls back to reading the proof chain file when the command is unavailableverifiedok
A006Plan agents receive proof context through the scope, not by reading the file directlyverifiedok
A007Build agents receive proof context through the spec, not by reading the file directlyverifiedok
A008Dogfood agent definitions match the shipped templates exactlyverifiedok

Findings 4 total

debtpackages/cli/tests/templates/agent-proof-context.test.tsclosed
A001/A004 use whole-file contains, weaker than section-specific extraction: `packages/cli/tests/templates/agent-proof-context.test.ts:14,43` — These tests would still pass if someone moved `ana proof context` to the wrong section of the file. The contract targets (`ana.md.content`, `ana-verify.md.content`) are whole-file scoped, so the test is technically correct. But A002/A003 demonstrate the stronger pattern (section extraction before assertion). Future contract assertions for section-specific content should use section-specific targets.
debtpackages/cli/tests/templates/agent-proof-context.test.tsclosed
A008 tests all 4 dogfood files in a single `it` block: `agent-proof-context.test.ts:67-75` — If the first file comparison fails, the loop short-circuits and the remaining 3 aren't checked. The error message includes the filename (`${file} dogfood should match template`), which mitigates debugging difficulty. Separate `it` blocks per file would give complete coverage reporting, but the contract only has one assertion (A008) covering all 4, making a single test reasonable.
obspackages/cli/templates/.claude/agents/ana.mdclosed
Checkpoint wording deviates from spec prescription: `packages/cli/templates/.claude/agents/ana.md:119` — Spec said `"relevant proofs if asked"`, implementation says `"relevant proof chain findings if asked"`. The implementation wording is arguably better (more specific), but it's a spec-implementation delta the deployer should be aware of.
obs.ana/PROOF_CHAIN.mdclosed
AC7 and AC8 are in tension: AC7 says "no agent definition references `.ana/PROOF_CHAIN.md` as a file to read" while AC8 requires a fallback that references it. The spec's gotcha resolves this ("exactly ONE `.ana/PROOF_CHAIN.md` literal string should remain"), but future scope should word AC7 more precisely: "no agent definition references `.ana/PROOF_CHAIN.md` as a primary file to read in its normal flow."

Integrity seal

scopesha256:01d677eb45005...
contractsha256:038d5bfc0c3a5...
plansha256:b8783cef855a0...
specsha256:70529a0235ec0...
build-reportsha256:557de239ac4d3...
verify-reportsha256:89a85e043c726...
audit cmd$ ana proof audit proof-chain-targeted-queries   → all hashes match