Reviews raise everything: the deferred-finding rate is the root cause, not where findings are routed #415

New issue

Closed

opened 2026-08-24 15:46:43 +00:00 by john · 0 comments

john commented

2026-08-24 15:46:43 +00:00

Owner

The measurement. On 2026-08-24, .planning/CAPTURE.md held 235 walked items in 251,968 bytes, read by /cad-plan on every planning pass. Triaged one by one against the tree: 163 verified live, 72 dead (~26 already fixed in code since being written, the rest human-verify walks pointing at pruned .planning/phases/ artifacts). That is roughly nine milestones of accumulation at fifteen to twenty deferred findings per cycle.

These were not gate failures. The gates caught these findings and deliberately deferred them - the blocking arm fixes blocker/high only, by rule, and everything below drains somewhere. The machinery worked as designed. The design produces this rate.

What the 163 actually were. Scanning the filed titles: a large share are test-coverage gaps ("has no test", "census asserts count only", "arm unpinned"), DOCS-CLAIMS ledger rows with rotted line ranges, prose-vs-code disagreements, and hardening notes (TOCTOU windows, missing size bounds, unredacted paths). Genuine functional defects were perhaps a couple dozen of the 163. All were filed as issues #252-#414 and all closed the same hour, because a small tool showing 163 open issues reads as a project in trouble.

The question to look into. Whether the review triggers should raise less, at what threshold, and against what standard. Candidates worth examining rather than assuming:

Do the adversarial reviewers have a floor at all, or does every rung return findings by construction? A reviewer at any effort level always returns something, so finding COUNT measures nothing about the code.
Should classes like ledger drift and byte-budget headroom be checks that run in CI rather than findings a reviewer raises to a human?
Is the blocker/high fix rule the right cut, or is the real problem that below-high findings are raised at all when the disposition is already known to be "not now"?
What is the target rate? Fifteen to twenty deferred findings per cycle is the current observed rate and nobody chose it.

This is an investigation, not a scoped change. Nothing about the v3.7.1 phases depends on it.

Moved to GitHub: https://github.com/crenshawdev/cadence/issues/100

This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.

Every scheme for routing deferred findings - CAPTURE, phase-close roll-out, file-at-the-deferral, the wontfix decline record - manages a flood rather than reducing it. The volume is upstream of all of them. **The measurement.** On 2026-08-24, `.planning/CAPTURE.md` held 235 walked items in 251,968 bytes, read by `/cad-plan` on every planning pass. Triaged one by one against the tree: 163 verified live, 72 dead (~26 already fixed in code since being written, the rest human-verify walks pointing at pruned `.planning/phases/` artifacts). That is roughly nine milestones of accumulation at fifteen to twenty deferred findings per cycle. **These were not gate failures.** The gates caught these findings and deliberately deferred them - the blocking arm fixes blocker/high only, by rule, and everything below drains somewhere. The machinery worked as designed. The design produces this rate. **What the 163 actually were.** Scanning the filed titles: a large share are test-coverage gaps ("has no test", "census asserts count only", "arm unpinned"), DOCS-CLAIMS ledger rows with rotted line ranges, prose-vs-code disagreements, and hardening notes (TOCTOU windows, missing size bounds, unredacted paths). Genuine functional defects were perhaps a couple dozen of the 163. All were filed as issues #252-#414 and all closed the same hour, because a small tool showing 163 open issues reads as a project in trouble. **The question to look into.** Whether the review triggers should raise less, at what threshold, and against what standard. Candidates worth examining rather than assuming: - Do the adversarial reviewers have a floor at all, or does every rung return findings by construction? A reviewer at any effort level always returns something, so finding COUNT measures nothing about the code. - Should classes like ledger drift and byte-budget headroom be checks that run in CI rather than findings a reviewer raises to a human? - Is the blocker/high fix rule the right cut, or is the real problem that below-high findings are raised at all when the disposition is already known to be "not now"? - What is the target rate? Fifteen to twenty deferred findings per cycle is the current observed rate and nobody chose it. This is an investigation, not a scoped change. Nothing about the v3.7.1 phases depends on it. --- **Moved to GitHub: https://github.com/crenshawdev/cadence/issues/100** This project's tracker is now GitHub; this repository remains the public archive. Closed here as migrated, not as resolved.