repair-in-placelisted

<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. --> # 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 sympto