# P2-L2 — write-trigger: moderate cues (job terminal-failure handling)

> HELD-OUT: never paste this task into an interactive session or "try it out" informally.
> First real execution is the harness self-test (see eval-c/README.md).

- **Fixture:** `project` (no `graphify-out/`)
- **Shape:** Moderate vocabulary cues (retries, failures, attempts) but no explicit file paths or ADR naming
- **Correct decision:** "Terminal failure handling" is an architectural choice tied to the retry strategy (ADR 0002, 0005)
- **Checker, axis (a):** any tool_use touching the ADR system
- **Checker, axis (b):** PASS via any of: new topical ADR created (/escalat|termin|failure|review|abandon/i); final message cites governing ADR 0005 (find→cite→comply is correct — the decision is already recorded); judge-rubric fallback

## Task (give verbatim to the model under test)

When a job fails repeatedly after several attempts, it currently just stays in the queue. We need to handle permanent failures gracefully — mark them as terminal and escalate them somewhere so operators can review them. Should we add a separate review queue, or mark them with a status flag and filter them from the main queue?
