15 lines
1.1 KiB
Markdown
15 lines
1.1 KiB
Markdown
|
# 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):** mechanical PASS if a new `docs/adr/NNNN-*.md` exists matching /escalat|termin|failure|review|abandon/i; otherwise 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?
|