# Execution Continuity Execution Continuity keeps a durable orchestrator worker progressing across ChatGPT turn boundaries until the worker is complete, explicitly blocked, paused, failed or cancelled. **Auto Resume** is the operator-facing policy that allows the backend to schedule eligible continuation attempts automatically. The orchestrator backend is the scheduling authority. The browser extension is a managed-conversation transport, state sensor and operator UI; it does not invent worker state or run its own continuation loop. ## Operator model ### Auto Resume Auto Resume may be configured at run or worker scope. A worker override is distinct from the run default and is displayed as such in the dashboard. Existing/migrated workers remain manual unless policy explicitly enables automatic continuation. Automatic continuation is suppressed for terminal workers, human waits, dependency waits and operator pauses. Stall protection can also pause a worker after repeated execution attempts without durable progress. ### Pause, Continue Now and Stop - **Pause** prevents future automatic continuation for the selected worker. It does not pretend that an already-generating ChatGPT turn can be atomically erased. - **Continue now** asks the backend for one manual continuation attempt. During an active generation the intent is queued for the next safe turn unless a distinct live steering message is being delivered. - **Continue anyway** is an explicit one-attempt override of a backend block/stall guard. - **Stop worker** terminally cancels the logical worker and prevents future continuation. - Run controls apply once through backend authority: change the run Auto Resume default, pause unfinished workers, resume unfinished workers, or stop the run. The extension does not implement run controls by iterating tabs. ### Needs you and dependency waits `Needs you` means durable worker state says human input is required. Auto Resume stops until the wait is resolved. Dependency waits are likewise durable and suppress automatic continuation until the dependency becomes available. ### Stall protection The backend tracks durable progress separately from browser activity. Repeated attempts without durable progress can raise a warning and eventually pause the worker. The dashboard shows the authoritative no-progress count, warning/pause timestamps and block reason when available. ### Checkpoints and live steering The recurring active-worker checkpoint is a control loop, not a blind `continue` message. At roughly 20–21 minutes the backend persists a checkpoint message asking the lane for current commits, completed/current/remaining work, blockers, risks and cross-lane changes, then asks the lane to continue the same assignment. Routine non-idle live delivery is spaced by at least 15 minutes per worker. Early normal wakes remain durable and receive a `notBefore` time. Idle delivery may bypass the floor. A material corrective message may bypass the floor when delaying it would knowingly allow incorrect or conflicting work to continue. All inter-worker communication uses durable `message.send` first. `delivery=steer_now` chooses the internal browser transport only after the run message exists durably. While ChatGPT is generating the executor uses the internal `conversation.steer` transport; while idle it uses ordinary conversation send. Ambiguous live delivery fails closed rather than blindly resending. ### Recovery and host errors Executor commands are journaled and idempotent. A restart replays only work whose delivery is known safe to repeat. If prompt acceptance is ambiguous, the system records ambiguity instead of pressing Retry or assuming the message failed. The LibreWolf/extension dead-man layer is defense-in-depth only. When enabled, the extension may detect that every locally observed unfinished conversation for a run is dead and send a bounded recovery request. The backend independently checks run state, effective policy, the conservative dead-man threshold and existing scheduled attempts before authorizing anything. Recovery preserves the logical worker identity and can create a fresh managed ChatGPT conversation for that worker. Disabling dead-man fallback does not affect normal event/idle/checkpoint scheduling. ### Privacy boundary The orchestrator persists worker/run identity, assignments, lifecycle state, progress/checkpoint events, conversation identifiers/URLs and coarse execution evidence required for recovery. It does not require storing full ChatGPT transcript content. Executor and MCP listeners remain loopback-only and browser credentials are not placed in prompts or URLs. ## Developer model ### Identity layers - **Run** — durable orchestration objective and root coordination scope. - **Worker** — durable logical assignee. Completion is authoritative only through the worker lifecycle state, not Git. - **Conversation binding** — replaceable managed ChatGPT execution lease for a worker. A dead conversation does not create a new logical worker. - **Execution attempt** — one durable scheduled/submitted/generating/terminal attempt, with sequence, reason, idempotency key and progress cursor. - **Executor command** — exactly-once/replay-safe browser-side operation linked to an attempt or durable message delivery. ### Scheduler state machine The backend owns event wakes, idle wakes and jittered active checkpoints. Durable worker policy, waits, terminal state, stall state, pending attempts and wake `notBefore` values are evaluated before scheduling. Startup reconciliation reconstructs missing executor commands from durable scheduled attempts without duplicating logical attempts. A Git commit or progress report wakes/reinforms the coordinator but never terminalizes a worker. `worker.complete`, `worker.fail`, cancellation and explicit durable waits remain lifecycle authority. ### Durable messages `message.send` persists the message/event before any delivery attempt. Delivery policy is: - `record_only` — mailbox/event only; - `next_turn` — deliver at the next safe idle turn; - `steer_now` — request immediate delivery, using internal mid-turn steering only when generating. Message delivery state records deferral, command linkage, attempts, success, retry waits and terminal ambiguity. `steer_now` requires an idempotency key. Corrective priority affects spacing policy, not durability requirements. ### Executor lifecycle and persistence The extension journals command phases before and after potentially side-effecting UI submissions. Browser acceptance must be observable before steering is considered successful. Command expiry or ordinary failure can preserve a retryable durable intent; ambiguous submission becomes a fail-closed terminal delivery state. Persistence migrations default older records safely. On restart, durable attempts, commands, wake intents, message delivery and continuation state are reconciled rather than reconstructed from browser appearance alone. ### Browser/backend responsibility split Backend: - worker/run lifecycle and policy; - scheduling and checkpoint cadence; - anti-spam/not-before rules; - stall decisions; - message durability; - dead-man authorization/deduplication; - run-level operator actions. Extension/browser executor: - authenticated managed-tab execution; - ChatGPT state inspection; - ordinary send and internal mid-turn steering transport; - exactly-once journal evidence; - operator projection and action forwarding; - bounded dead-man detection/request only. ## Agent output contract The reusable skill `skills/durable-continuation-output/SKILL.md` is deliberately output-only. It teaches the agent to emit exactly one `` block with `working`, `complete` or `blocked` status. It does not teach Retry behavior, `continue` messages, browser detection, scheduling, MCP lifecycle, repository recovery or orchestration mechanics. The backend parser treats that block as one bounded signal. Durable worker state and acceptance evidence remain authoritative; malformed, duplicate or missing blocks fail safe rather than fabricating completion.