# P3-L3 — write-trigger: fully conceptual (job reliability)

> 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:** Purely intent-based framing, no ADR vocabulary, no file paths. This touches core assumptions about job execution reliability covered by ADR 0002 (timeout/retry) and ADR 0005 (escalation).
- **Correct decision:** Ensuring work "always finishes or is explicitly abandoned" is an architectural concern tied to the timeout/retry strategy
- **Checker, axis (a):** any tool_use touching the ADR system
- **Checker, axis (b):** PASS via any of: new topical ADR created (/abandon|finish|complet|reliability|guarant/i); final message cites a governing ADR (0002/0005/0006); judge-rubric fallback

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

Ensure that any work submitted to the system always either finishes successfully, fails and is logged for review, or is explicitly abandoned by the user — nothing should vanish silently into an unknown state. What guarantees do we need to make, and how should we track job state to ensure this is true?
