cc-os/plugins/os-adr/eval-c/scenarios/P2-L2-execution.md

1.1 KiB

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?