recovery-classificationlisted

# Recovery Classification Skill When a phase or unit fails, name the failure class first. Generic "retry on failure" hides repeatable failure modes and turns them into flaky tests. ## When to Use - After any Phase 1–6 failure in `verification-loop`. - After any auto-loop unit that exits non-zero. - After any tool call the harness rejects (schema validation, policy gate, deterministic block). - Before re-running anything that just failed — classification fires once, before the first retry. ## Why This Skill Exists GSD-2's [CONTEXT.md](https://github.com/gsd-build/gsd-2/blob/main/CONTEXT.md) names "Recovery Classification" as one of four runtime invariant modules. Common failure modes it catches: - **Deterministic-policy blocks misclassified as generic provider failures** — gateguard denials retried in a loop until budget is exhausted. - **Schema-validation failures retried verbatim** — wasting tokens on a call the validator will keep rejecting. - **Stale-worker / stale-lock states** — no retry can resolve a worker that died holding a lock; the loop just spins. - **Worktree-invalidity errors** — recovery can't fix without operator intervention; retrying writes to a broken root. A retry without a class is a guess; a guess at scale is a budget leak. ## The Classification Taxonomy Six classes. Each maps to one intentional action: | Class | Signal | Action | |---|---|---| | **provider** | API timeout, 5xx, rate limit, network, transient cloud error | retry with exponentia