niksavis Repair in place
Repair is a mode of the implementer, not a fresh start. Same worktree, same scope, same artifact. What differs is that you are briefed with findings rather than with a requirement.
Do not re-plan
The plan was already gated. Re-reading the requirement and reconsidering the approach spends a second full build to reach the same place, and the rework allowance is per gate — grinding through it is how a lane dies with nothing landed.
If the finding shows the plan was wrong rather than the code, that is an escalation, not a repair. Say so and stop.
Fix in the lane's worktree
Never re-dispatch the lane to fix a named defect. A re-dispatch pays the whole scope-reading cost again and arrives at the same defect with less budget. Hand the finding to the worktree that already holds the context.
Reproduce before you fix
Run the failing check and read its actual output first. Two things follow from that and neither is optional:
- A fixture invented to match a suspected error message produces a fix for a failure that never happens. It has happened here: an unobserved error string made a retry path dead code through two consecutive "fixes".
- A gate's own repair advice can be wrong. Verify the premise before obeying the remedy — obeying one here deleted a real suppression on a lying gate's instruction.
Fix the cause at every site, not the symptom at one
Before calling a single-site patch complete, check the other call sites. A defect that reached one place through a shared helper reached the others too.
Never weaken the gate that caught you
Not the tests, not the lint, not the type checker, and never --no-verify.
The cheapest way to pass a size gate is deleting comments — measured at 11-36%
of a module's tokens on this tree — and the cheapest way to pass a test is
loosening its assertion. Both leave the gate reporting green over a defect it
was built to catch.
A fix ships its regression test
Write the test that fails first, then make it pass. A fix with no test is a fix that will be made again.