Timeout-BLOCKs indistinguishable from legitimate code-quality BLOCKs

[benthomasson]

Problem

Spurious timeout-BLOCKs are structurally indistinguishable from legitimate code-quality BLOCKs in the review output. When an LLM reviewer times out or hits an API error, the result is rendered the same way as a genuine "this code is dangerous" BLOCK.

Operators learn to override both, which is rational behavior given the noise. This was demonstrated on PR #96: Claude issued a correct BLOCK identifying a CRITICAL fail-open vulnerability, but the PR was merged in 24 minutes. The finding went untracked for 19 days.

Impact

• Legitimate security findings get overridden because operators have been trained by false positives to discount BLOCK verdicts
• No way to distinguish signal from noise without reading the full review output
• Undermines the review gate as a safety mechanism -- if every third BLOCK is a timeout, operators stop trusting any of them

Suggested fixes

• Distinguish verdict sources: render timeout/error BLOCKs differently from code-quality BLOCKs (different label, color, or category)
• Separate error handling from review verdicts: a timeout is not a review outcome -- it should be a RETRY or ERROR, not a BLOCK
• Track override rate: if operators are overriding >N% of BLOCKs, surface that as a signal that the gate has a noise problem
• Require issue filing on override: when a BLOCK is overridden, require the operator to file issues for each finding or explicitly acknowledge the risk