Graduated from the friction-log inbox (entry: "Deleting a check reintroduced the bug it was masking", severity M, 2026-07-26). The incident itself was fixed inside #31; this files the generalisable rule, which is not written down anywhere.
What happened
The roster check removed during #31 turned out to be the only thing catching , used as punctuation rather than as a separator in --lenses. After the deletion:
--lenses "adversarial, focused on the merge gate"
— an honest way to record one lens — rendered as two, which suppressed the one-lens warning that was the field's entire remaining value.
The sharpest part: the commit that deleted the check quoted that exact input as an example of what it still blocked. The author had the counterexample in hand while writing the justification and did not test it.
Why the existing rules do not cover it
safety-critical-changes.md rule 1 covers tightening a mechanism (and a sibling issue proposes a threshold for it). Nothing covers removing one. Removal feels safe — you are deleting code that was judged unfit, and the reasoning is usually "this doesn't actually verify what it claims", which was true here.
The failure mode is that a mechanism rejected as inadequate for its stated purpose can still be the only thing rejecting some incidental input class. Its stated purpose is documented; the incidental class is, by definition, not.
Proposed rule
When removing a mechanism as unfit, enumerate what it was rejecting and confirm each case is either still rejected elsewhere or deliberately allowed.
A mechanism judged inadequate for its stated purpose may still be the only thing catching an input class nobody wrote down. The deletion commit is the place to record that enumeration — if you cannot list what it rejected, you do not yet know what removing it costs.
Cheap to apply: it is one paragraph in the deletion commit, and it is checkable in review ("what did this reject, and what catches those now?").
Note on where it belongs
Probably safety-critical-changes.md, adjacent to rule 1, since the two are the same question asked in opposite directions — rule 1 is when to stop patching a mechanism, this is what to check before deleting one. Both were learned on the same PR.
Related
The incident's own fix (_countable_lenses counting entries that look like lens names rather than prose) shipped inside #31, so nothing is live on main because of this.
Graduated from the friction-log inbox (entry: "Deleting a check reintroduced the bug it was masking", severity M, 2026-07-26). The incident itself was fixed inside #31; this files the generalisable rule, which is not written down anywhere.
What happened
The roster check removed during #31 turned out to be the only thing catching
,used as punctuation rather than as a separator in--lenses. After the deletion:— an honest way to record one lens — rendered as two, which suppressed the one-lens warning that was the field's entire remaining value.
The sharpest part: the commit that deleted the check quoted that exact input as an example of what it still blocked. The author had the counterexample in hand while writing the justification and did not test it.
Why the existing rules do not cover it
safety-critical-changes.mdrule 1 covers tightening a mechanism (and a sibling issue proposes a threshold for it). Nothing covers removing one. Removal feels safe — you are deleting code that was judged unfit, and the reasoning is usually "this doesn't actually verify what it claims", which was true here.The failure mode is that a mechanism rejected as inadequate for its stated purpose can still be the only thing rejecting some incidental input class. Its stated purpose is documented; the incidental class is, by definition, not.
Proposed rule
Cheap to apply: it is one paragraph in the deletion commit, and it is checkable in review ("what did this reject, and what catches those now?").
Note on where it belongs
Probably
safety-critical-changes.md, adjacent to rule 1, since the two are the same question asked in opposite directions — rule 1 is when to stop patching a mechanism, this is what to check before deleting one. Both were learned on the same PR.Related
The incident's own fix (
_countable_lensescounting entries that look like lens names rather than prose) shipped inside #31, so nothing is live onmainbecause of this.