The recurring defect in this repo is a rule applied at one door and not its siblings. Most of that class cannot be caught statically and this issue does not claim otherwise. Two instances from round three can:
-
A PRIMARY KEY whose column list omits a column added by a migration in the same file. That is round three's R3 exactly: a context column was added, the key was left narrow, INSERT OR REPLACE then had two contexts overwriting each other, and the poller looped forever — shipped on the strength of a comment I wrote asserting it was safe.
-
A default constant substituted in more than one function instead of through a single normalizer. Round three's R4: Store.Save defaulted an empty status context and Runner.Run did not, so the forge and the store disagreed about which check had spoken. Policy.normalized() exists because of it.
Both are cheap checks over a single file. Neither is general. Ship them as narrow gates with negative controls, per the standing rule that a gate which cannot fail is not a gate.
The recurring defect in this repo is a rule applied at one door and not its siblings. Most of that class cannot be caught statically and this issue does not claim otherwise. Two instances from round three can:
A
PRIMARY KEYwhose column list omits a column added by a migration in the same file. That is round three's R3 exactly: acontextcolumn was added, the key was left narrow,INSERT OR REPLACEthen had two contexts overwriting each other, and the poller looped forever — shipped on the strength of a comment I wrote asserting it was safe.A default constant substituted in more than one function instead of through a single normalizer. Round three's R4:
Store.Savedefaulted an empty status context andRunner.Rundid not, so the forge and the store disagreed about which check had spoken.Policy.normalized()exists because of it.Both are cheap checks over a single file. Neither is general. Ship them as narrow gates with negative controls, per the standing rule that a gate which cannot fail is not a gate.