Distributed execution: validate and carry forward

1. What does 202 establish? Only the defined durable acceptance, not completed generation.
2. Why keep a transaction short? Do not hold a write lock over slow external work; commit authority before execution.
3. What does an epoch protect? Guarded local writes against a stale owner, not external actions.
4. When is retry safe here? In the explicitly safe pre-external/pure-work region, with bounded attempts and deadline.
5. What stops an agent loop? Trusted tool policy plus step/time/attempt budgets and persistent state.

The 60-second card: accept durably; claim atomically; separate overlap from durability; commit results before acknowledgement; fence stale writers; preserve external ambiguity; bound every tool loop. Review at about one, seven, and 21 days.

• Explain acceptance, execution, and completion without notes in two minutes.
• Draw the retained short API and the new job/queue/worker path.
• Defend the DB queue and a broker alternative under changed workload.
• Diagnose crash-before-effect and crash-after-effect with state and signals.
• Run, modify, and debug the claim/retry/checkpoint tests; learner completion remains unassessed.

ADR-002 adds durable background execution without replacing T18.2’s short request contract. The stage snapshot records the accepted educational after-state independently of the mutable current system.

The complete distribution contains this stage, required earlier guides/labs, architecture/ADRs, and local reference/licence files with their relative paths preserved. No production readiness is inferred.

A later T18.4 can use these durable jobs for document ingestion and versioned indexing. It must preserve trusted scope, replay-safe writes, job status, and uncertainty boundaries. It is not needed to understand or run T18.3.

• RFC 9110: HTTP accepted-response semantics used in the proposed job facade.
• RabbitMQ consumer acknowledgements and publisher confirms: separate publication and delivery boundaries, cited as a broker example rather than an installed dependency.
• SQLite isolation: serialised local writes underlying the claim experiment.

Sources checked 2 November 2026. Workloads, clocks, deadlines, and tool responses are authored assumptions. See validation for actual execution evidence.

• 202 establishes only durable acceptance, not completed generation. Keep transactions short so no write lock is held over slow external work.
• Retry is safe only for pure work before any external effect, within bounded attempts and the job deadline. An epoch protects local writes against a stale owner, not external actions.
• Trusted tool policy, step, time and attempt budgets, and persistent state stop an agent loop. Later document ingestion can reuse these durable jobs if it keeps trusted scope, replay-safe writes, job status and uncertainty boundaries.