Quality Gates
Before any change is even eligible for a human approval gate, it has to clear a fixed, automated bar. This bar doesn't move to accommodate a stretch of work being difficult — the rule is to fix the system until it clears the bar, never to lower the bar until the system clears it.
Four checks, run in sequence. A failure at any stage is a defect in the system to fix — never a reason to soften the check itself.
The four checks
Type checking in strict mode, with zero errors tolerated. Linting, with zero warnings tolerated. Automated tests, all of them passing. Test coverage on whatever code was actually touched, at or above a fixed minimum threshold.
What "fix the system, not the test" means in practice
When a test fails because the system doesn't do what was specified, the test is telling the truth — the correct response is to investigate why the system doesn't meet the requirement and fix that, not to quietly loosen the test's acceptance criteria until it stops complaining. Requirements can genuinely change, but only as an explicit, acknowledged decision with a stated reason — never as a quiet side effect of a test being inconvenient to satisfy.
A pre-existing failure isn't a pass
Finding a check that was already failing before any new work started is not treated as somebody else's problem to silently step around. It gets fixed, or it gets explicitly flagged and raised before proceeding — either way, it doesn't get quietly ignored.