| name | remediation-loop |
| description | Use when independent verification returns any fail — route each fail to one of three exits (fix root cause / fix the table / accept with known defect), leave a trace, then re-verify. Bounded to one cycle before escalating. Part of meta-workflow (Step ⑤); uses superpowers receiving-code-review for posture. |
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)
- 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.)
- 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.
- 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.
