recurrence-preventionlisted

# Recurrence Prevention (재발방지) A defect that happens once is a bug. A defect that happens **twice is a countermeasure failure** — whatever was supposed to prevent the second occurrence (a mental note, a memory entry, a rule) demonstrably did not. So on a recurrence, the unit of work is not the fix (you already know the fix — you applied it last time). The unit of work is the **countermeasure**, and the core move is: **escalate it one level, because the current level just failed.** This skill codifies a practice proven in the harness repo that ships it: the no-false-ship rule was created only after the *third* false-ship incident; CHANGELOG drift survived a written convention for seven releases and stopped only when a test gate enforced it; comment warnings against hardcoded-list drift failed twice before "derive to a single source" became mandatory. The pattern is consistent: **each enforcement level fails in a characteristic way, and the answer is the next level up — not a louder version of the same level.** ## When to use - You just hit a bug/mistake and it feels familiar — "이거 저번에도 그랬잖아". - The user reports a recurrence or asks for a countermeasure: "재발했어", "같은 실수 또 했네", "재발방지 대책 등록해줘", "postmortem this". - You are fixing a defect and, while investigating, find a prior record of the same failure mode (memory entry, rule case table, CHANGELOG note) — even if nobody said "recurrence" out loud. - A rule or gate that was supposed to prevent this class of failure existe