15 lines
1.2 KiB
Markdown
15 lines
1.2 KiB
Markdown
# 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?
|