The problem
Review verdicts under .2119/verdicts/ are written as REQ-<id>--<hash>.json, one new file per review. Re-reviewing a requirement appends a new file rather than superseding the previous one, so stale verdicts accumulate in the working tree forever.
Measured on a real PR (panopticon #112, task service authentication):
- 248 verdict files covering 72 unique requirements — ~3.4 files each
- worst case
REQ-035.28.1 with 15 verdicts
- 1,984 lines, 31% of the PR's entire diff
The visible cost is that a PR with ~865 lines of production code reads as +5,847. Reviewers discount the whole diff as noise, which is the opposite of what this tool is for.
Why this is a correctness issue, not just ergonomics
A verdict asserts "this requirement was reviewed against this state of the code." A verdict keyed to a superseded diff isn't weaker evidence — it is not evidence, because the thing it attested to no longer exists.
Keeping superseded verdicts in the working tree invites exactly the failure mode 2119 exists to prevent: a green check satisfied by an artifact that no longer corresponds to the code. The current design detects this only because the filename hash stops matching, which means staleness is inferred from a naming convention rather than asserted by the data.
Proposed change
One verdict file per requirement, content-addressed internally.
- filename becomes
REQ-<id>.json — stable, one per requirement
- the reviewed diff's hash moves inside the file
- re-review overwrites rather than appends
check compares the recorded hash against the current diff: match = current, mismatch = stale, fail loudly
This is a strictly stronger guarantee than today, because staleness becomes an explicit assertion the checker validates rather than a property implied by a filename nobody diffs. No requirement is dropped, no review is skipped, no gate is loosened.
The audit trail is not lost — superseded verdicts live in git history, which is where superseded versions of any file belong.
Effect on the measured case: 248 files collapse to 72, and ~1,900 lines leave the diff.
Also worth doing: mark verdicts as generated
Independently of the dedup, verdict files are machine-generated artifacts and should be marked as such:
.2119/verdicts/*.json linguist-generated=true
GitHub then collapses them in the diff view by default. This is a one-line change that helps immediately and keeps helping after the dedup lands.
Both changes are wanted — they address different halves of the same problem. The dedup fixes what is stored; the marker fixes how what remains is presented.
Design constraint
Do not weaken the gate to make diffs smaller. The 4:1 test-to-production ratio these workflows produce is the product working as intended for agent-written code, and it is not in scope here. The target is duplicated and superseded evidence, not the evidence itself.
The problem
Review verdicts under
.2119/verdicts/are written asREQ-<id>--<hash>.json, one new file per review. Re-reviewing a requirement appends a new file rather than superseding the previous one, so stale verdicts accumulate in the working tree forever.Measured on a real PR (panopticon #112, task service authentication):
REQ-035.28.1with 15 verdictsThe visible cost is that a PR with ~865 lines of production code reads as +5,847. Reviewers discount the whole diff as noise, which is the opposite of what this tool is for.
Why this is a correctness issue, not just ergonomics
A verdict asserts "this requirement was reviewed against this state of the code." A verdict keyed to a superseded diff isn't weaker evidence — it is not evidence, because the thing it attested to no longer exists.
Keeping superseded verdicts in the working tree invites exactly the failure mode 2119 exists to prevent: a green
checksatisfied by an artifact that no longer corresponds to the code. The current design detects this only because the filename hash stops matching, which means staleness is inferred from a naming convention rather than asserted by the data.Proposed change
One verdict file per requirement, content-addressed internally.
REQ-<id>.json— stable, one per requirementcheckcompares the recorded hash against the current diff: match = current, mismatch = stale, fail loudlyThis is a strictly stronger guarantee than today, because staleness becomes an explicit assertion the checker validates rather than a property implied by a filename nobody diffs. No requirement is dropped, no review is skipped, no gate is loosened.
The audit trail is not lost — superseded verdicts live in git history, which is where superseded versions of any file belong.
Effect on the measured case: 248 files collapse to 72, and ~1,900 lines leave the diff.
Also worth doing: mark verdicts as generated
Independently of the dedup, verdict files are machine-generated artifacts and should be marked as such:
GitHub then collapses them in the diff view by default. This is a one-line change that helps immediately and keeps helping after the dedup lands.
Both changes are wanted — they address different halves of the same problem. The dedup fixes what is stored; the marker fixes how what remains is presented.
Design constraint
Do not weaken the gate to make diffs smaller. The 4:1 test-to-production ratio these workflows produce is the product working as intended for agent-written code, and it is not in scope here. The target is duplicated and superseded evidence, not the evidence itself.