jared
/
cc-os
1
0
Fork 0
Code Issues 18 Pull Requests Packages Projects Releases Wiki Activity
cc-os/plugins/os-adr/eval-c/scenarios/P2-L2-execution.md

1.2 KiB
Raw Blame History

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?