Step ⑤ — Remediate

Why this exists: a failed check has exactly three exits, and shipping it quietly is not one of them. The dangerous move is the silent fourth path: tweak the symptom until the verdict looks better, or quietly call it done. "I can't fix it, so I'll lower the bar" is hiding, not aligning.

The three exits (every fail goes to exactly one, with a trace)

1. Fix the output (default). Go to root cause, don't suppress the symptom to make the verdict look better. Then re-verify. (For metric claims, the fix is re-validated the same strict way it was caught — see references/hard-gates.md.)
2. Fix the table. Only if verification reveals the table itself was wrong → align toward truth, with explicit declaration + human sign-off + the time-anchor test from freeze-acceptance. Lowering the bar because it was hard is not this — that's the forbidden fourth path wearing a disguise.
3. Accept with a known defect. The human explicitly signs off on shipping with the fail → record it: which item failed, why, the recovery trigger, the owner. This is ship-with-defect, not done — never relabel it "complete" afterward.

Bounded loop

Default to one fix → re-check cycle. If it still fails on the second pass, do not auto-loop — escalate to the human (keep investing / fix the table / accept the defect). This keeps re-review cost from spiraling.

Feed the lesson back

If the root cause is a process / recurring problem, don't just fix this instance — pick a prevention layer (L1 code enforcement … L4 a written rule) and push it upstream. The closer to code, the more reliable. See references/prevention-layers.md.

Relationship to superpowers

superpowers receiving-code-review gives the posture: take feedback with technical rigor, not performative agreement and not blind implementation. This skill adds the three-exits discipline and the prevention-layer feedback.