Feature 013: unattended work continuity — resolved-or-unresolved halts - #1

Why

During an explicitly unattended (--policy autonomous) run, dude-work sometimes ended a turn just to summarize progress, which read as a stop, so work idled with no legitimate basis while ready work remained. Worse, some halts named no reason from the closed stop set, so an unnameable halt looked exactly like a legitimate one after the fact, and a legitimately-named halt could still be undiagnosable without reading runtime internals.

What this does

Under an explicit unattended run, the loop now keeps working through ready work and ends only on a genuine stop. Every work-loop halt carries a report that is one of two structurally distinct forms:

• resolved: exactly one reason from the existing closed stop set, plus actionable detail (affected target, specific causing subject or condition, next owner action), or
• explicitly unresolved: names the fields that could not be established and presents no reason outside the closed set.

A halt that cannot be attributed to a closed-set reason takes the unresolved form rather than masquerading as a named one. Progress reporting is decoupled from stopping, and every safety floor (destructive operations, spending, credentials, external authorization, ownership ambiguity), hard stop, verification gate, and independent review is preserved unchanged. Guarded and non-unattended behavior is byte-for-byte identical.

Approach

The deterministic autonomous runner attaches the report at its single terminal chokepoint finish(row): a hard-stop terminal carries describeUnattendedHalt(...), a clean settlement (ended) carries null. It reuses two landed primitives (endsUnattendedLoop, describeUnattendedHalt) unchanged.

The key design decision, worth calling out: the runner is the sole production driver of the host adapter and the model submits no protocol operations, so having the deterministic runner decide continuation is exactly what FR-010 requires. That single insight let us delete an entire earlier design (a session gate, per-operation gating, checkpoint/handoff/resume threading, and a lane-disposition chain) as machinery guarding a threat the production topology does not contain. The result is one bounded field on the terminal row: no new stop reason, lane, board, command, persistent store, or gate, and no halt attribution persisted anywhere.

Non-obvious notes for reviewers

• The hard-stop-only gate is necessary, not just an optimization: endsUnattendedLoop fails closed to "halt" for any non-authorized/completed reason, so calling the reporter on ended rows would misclassify a clean settlement.
• The named safety-floor category reasons are not reachable as end-to-end runner terminals (completionDispositionV2 emits only accepted/verification-failed/review-rejected; ownership ambiguity is preempted earlier). Their exhaustive per-category coverage lives at the reporter level; the runner wiring is reason-agnostic and proven on every reachable terminal, so the split composes without a gap.
• One decode-failure fallback branch is a deliberate, unreachable defense-in-depth guard that only upholds finish's never-throw contract; it is honestly left uncovered per the "an unreachable guard cannot be honestly covered" rule.

Verification

Full discovered suite 2261 pass / 0 fail (4 pre-existing platform skips); focused runner+recovery 557/0; prompt-contract 117/0; dude-lint 0/0; compose verify all packs OK; pristine release build clean; .github regenerated with src parity. Independent Tester and Code Reviewer both signed off on the runner wiring (T006) and on the complete feature (T005).