cc-os/plugins/os-adr/eval-c/scenarios/P1-L1-execution.md

P1-L1 — write-trigger: explicit cue (job timeout/retry)

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: Explicit cues — file path named, decision vocabulary explicit
• Correct decision: Should recognize this is deciding/changing the job timeout + retry strategy, covered by ADR 0002
• Checker, axis (a): any tool_use touching the ADR system (os-adr:* skill, bin/adr-* CLI, or read/glob of docs/adr/)
• Checker, axis (b): PASS via any of: new topical ADR created (/timeout|retry|backoff|exponential|attempt/i); final message cites governing ADR 0002 (find→cite→comply is correct — the decision is already recorded); judge-rubric fallback

Task (give verbatim to the model under test)

The job execution engine in taskq/execution.py currently has no timeout or retry logic. Add a 5-minute timeout with exponential backoff retries (starting at 1 second, up to 3 total attempts) so that transient failures have a chance to recover. Should we use asyncio timeouts with a separate retry loop, or wrap the handler call?