The problem

A /ds-implement-ticket loop that runs multiple engineers and Skeptics across many phases can take longer than a single session allows. Rate limits hit. Sessions exit. Work is interrupted.

Without a resume mechanism, every interruption means:

• Losing track of which phase the loop was in
• Not knowing which units are complete versus in-progress
• Risking a re-run that overwrites already-committed work
• Losing the Brief or Plan path that governs remaining units

The solution is .agentic/loop-state-<LOOP_KEY>.json - one file per ticket, written by the conductor at every phase transition so any session can pick up exactly where the last one stopped. The unkeyed .agentic/loop-state.json is the legacy form: still read and adopted on resume, no longer written.

Resume check on session start

When /ds-implement-ticket is invoked, it derives LOOP_KEY and checks for .agentic/loop-state-$LOOP_KEY.json before reading AGENTS.md. If the file exists with status == "interrupted" (or status == "active" with last_updated more than 10 minutes old), the conductor offers resume or fresh start. Key match is the primary guard, never freshness - other tickets' resumable loops get one informational line and no prompt, because offering the most recently written file would hand you another ticket's live state during any CI wait. A legacy .agentic/loop-state.json is adopted onto a keyed file, then removed.

Resumable phases (automatic):

• Phase 6/6b Skeptic/QA loop at iteration boundaries - committed engineer output, clean branch
• Phase 7 quality gate when engineer committed (engineer_returned or rerun_pending action)

Resumable with human confirmation:

• Mid-engineer (dirty branch) - conductor asks human to discard or commit the partial work

Restart required:

• Phases 1-4 are cheap to re-run and have no branch side effects. State file is not written until Phase 6 loop initialization.

Brief and Plan path recording

When a Brief or Plan governs the task, three fields are written to .agentic/loop-state-$LOOP_KEY.json at authoring time:

• brief_path - absolute path to the Brief file
• plan_path - absolute path to the Plan directory (when applicable)
• promotion_tier - enum: none, brief, or plan

On resume, the conductor re-reads the Brief or Plan before spawning the next worker. This ensures the governing artifact is always in context, even if the session that authored it is long gone.

Mid-flight escalation: if a task promotes from Trivial or single-unit Elevated to Brief or Plan tier during execution, a retroactive Brief is authored before the next engineer spawn. The in-flight engineer is allowed to return; already-completed units are not retroactively re-reviewed.

Batch-state coexistence

When /ds-implement-ticket runs with 2 or more ticket IDs, a sibling file .agentic/batch-state.json tracks batch-level cursor alongside each ticket's own loop-state-$LOOP_KEY.json phase cursor.

Session ownership gate: both files carry a session_id field. Every write applies a per-write gate that aborts (with an operator-visible warning) if:

• The existing session_id belongs to a different session whose liveness timestamp (last_updated for a keyed loop-state file, updated_at for batch-state.json) is within 10 minutes - and on batch-state.json ONLY, status is also active
• The existing session_id is null or absent, regardless of status (legacy state - force-takeover eligible)

batch-state.json alone carries the status=active precondition: its terminal mark stamps a fresh timestamp on exit, so without it the gate would abort the first write of an approved resume. A keyed loop-state file skips it - a live session can hold a non-active one (the Phase 7 stall path continues to the next ticket), so adding the precondition there would let a foreign session clobber a live file.

This prevents orphan-session corruption uniformly across both files. Note that per-ticket keying removes different-ticket contention from this gate entirely - those sessions write different files - and leaves same-ticket contention, which is exactly what the gate is for.

Concurrency limits:

• Only one batch per project root is supported
• A second concurrent N>=2 invocation is refused at Phase 0a-pre
• N=1 invocations against an active foreign batch warn but do not refuse
• Single-ticket Trivial invocations never create batch-state.json

File hygiene

Phase breadcrumbs accompany every phase transition - the conductor emits [phase: label] inline at each boundary. Phase breadcrumbs are emitted separately at each phase boundary and appear in the session context.