# Execution Continuity / Auto Resume — Implementation Plan Status: ready for implementation Date: 2026-08-20 Authoritative spec: `docs/specs/execution-continuity-auto-resume.md` Repository: `alexcodeplace/chatgpt-orchestrator` ## Outcome Implement Execution Continuity so a durable orchestrator worker keeps working across ChatGPT turn boundaries until it is truly complete, explicitly blocked, paused, failed or cancelled. The finished system must replace the user's manual `continue` loop with an observable, idempotent backend state machine while preserving the current architecture: ```text logical worker / durable assignment | v orchestrator continuation policy | v executor command | v managed ChatGPT conversation | +-- execution attempt 1 +-- execution attempt 2 +-- execution attempt 3 ``` The extension remains a narrow ChatGPT-Web executor. It observes `generating`/`idle`, submits exactly-once prompts and presents operator controls. It does not determine whether the engineering objective is complete. ## Working rules 1. Preserve `SPEC.md` logical-worker/executor separation. 2. Treat current uncommitted extension/concurrency work independently; integrate rather than overwrite it. 3. `Worker` is the durable job; ChatGPT turns are execution attempts. 4. Do not attempt to identify a hidden internal timeout cause. `idle + non-terminal worker` is sufficient to evaluate continuation. 5. Backend/core owns continuation policy and scheduler semantics. 6. Extension owns only managed-tab execution, state observation, exactly-once command handling and operator presentation. 7. No correctness property may depend on a single MCP/WebSocket/content-script request remaining open for a whole long ChatGPT generation. 8. Preserve fail-closed behavior for ambiguous prompt submission and host UI changes. 9. Keep conversation contents out of persistence; use MCP/repository/worktree state as authority. 10. Pause is non-terminal; Stop/Cancel is terminal/destructive. 11. Long productive workflows may use many turns. Stall protection must be progress-aware. 12. Browser E2E uses isolated `debian1/2/3` profiles/displays only, never the user's active workstation browser display. 13. Land coherent milestones so an interrupted implementation is restartable from Git and durable progress records. 14. Primary continuity scheduling is backend-owned: event wake + idle wake + jittered active keepalive. The LibreWolf extension remains a transport/state sensor; plugin-owned dead-man continuation is a final defense-in-depth slice only. 15. Active keepalive currently assumes a fresh owner-visible checkpoint/steering message at approximately 20–21 minutes may reset/extend the upstream turn window even while ChatGPT is generating. Treat this as a provisional empirical assumption and record contrary evidence without silently changing behavior. 16. Enforce a 15-minute minimum interval between non-idle continuation deliveries to one worker. Early event/keepalive wakes are durably queued/coalesced until `notBefore`; idle may bypass the floor. 17. Workers report checkpoint commits/progress durably to root throughout work. Progress/commit events wake root; root reviews every material checkpoint against the run-level plan, architecture, ownership and acceptance criteria, then may continue, correct, reprioritize, request evidence, provide dependency information or pause the lane. Git is progress evidence, never authoritative completion. Material corrective steering may bypass the ordinary 15-minute keepalive spacing floor but remains durable, deduplicated and exactly-once. ## Current implementation baseline As of `origin/main` at plan creation, the repository already provides: - protocol schemas for runs/workers/assignments/events/executor commands; - durable orchestration core and JSON persistence; - `worker.spawn`, `worker.attach`, `worker.progress`, `worker.complete`, `worker.fail`, `worker.interrupt`, `worker.followup`; - bounded `events.wait`; - authenticated loopback executor bridge; - extension-managed worker/tab bindings; - `conversation.create`, `conversation.send`, `conversation.inspect`, `conversation.close`; - extension command journal/idempotency handling; - managed-tab recovery/republishing; - DOM adapter generating/idle detection; - active WIP for extension concurrency/backpressure and MutationObserver-based waits. The implementation should evolve these seams rather than create a parallel subsystem. ## Phase 0 — Spec/protocol alignment ### C0.1 Add execution-continuity schemas Extend `packages/protocol` with schemas/types for: - `ContinuationPolicy`; - `ExecutionAttempt`; - execution-attempt reason/state/outcome; - worker execution disposition or compatible projection; - continuation/stall events; - continuation-specific stable error codes as necessary. Acceptance: - invalid policy thresholds rejected; - per-worker execution sequence is positive/monotonic; - execution attempt references valid worker/run identifiers; - protocol round-trip tests pass; - no browser/MCP dependency enters protocol package. ### C0.2 Decide compatibility shape for worker state Choose and document one of: A. extend `WorkerState`; or B. retain existing `WorkerState` and add `WorkerDisposition`. Prefer B if it avoids breaking existing worker lifecycle semantics during rollout. Required distinctions: ```text running awaiting_execution awaiting_human awaiting_dependency paused terminal ``` Acceptance: existing serialized state can migrate/load without destructive reset. ## Phase 1 — Persistence and execution-attempt domain ### C1.1 Persist policy/disposition/attempts Extend `StoredState` and repository migrations/defaulting for: - worker continuation policy overrides; - run-level default policy if implemented in v1; - worker disposition; - execution attempts keyed by `executionId`; - per-worker sequence/index; - pending continuation intent; - last progress cursor/time; - consecutive no-progress attempts; - stall warning/pause state. Atomic mutation + event append remains mandatory. ### C1.2 Execution-attempt service operations Add core operations for: - schedule initial/manual/auto/followup/recovery attempt; - mark submitted; - mark generating; - mark idle; - complete/block/fail attempt; - read/list attempts by worker; - recover latest attempt after restart. Do not expose browser-specific concepts such as `tabId` in domain APIs. ### C1.3 Progress accounting Make `worker.progress` update durable last-progress metadata and reset no-progress attempt counters. Later ownership/Git events may feed the same accounting seam, but do not block initial implementation on that integration. Acceptance: - restart reconstructs the exact latest policy/disposition/attempt state; - duplicate attempt scheduling with same idempotency key is harmless; - progress resets no-progress counters transactionally. ## Phase 2 — Explicit worker blocking/pause semantics ### C2.1 Human wait Implement `worker.await_human` with structured reason/request text. State/event requirements: ```text worker disposition -> awaiting_human worker.awaiting_human event no auto continuation allowed ``` ### C2.2 Dependency wait Implement `worker.await_dependency` with dependency/reason metadata. Provide a narrow mechanism for root/operator/dependency events to make it runnable again. ### C2.3 Pause/resume Implement non-terminal pause semantics: - pause immediately when idle; - `pause after current turn` intent while generating; - resume clears pause and may schedule execution if idle/runnable. ### C2.4 Continue now Implement `worker.continue_now`: - terminal -> error; - blocked -> require explicit unblock/override semantics; - paused -> explicit manual resume is allowed; - idle -> exactly one manual execution attempt; - already scheduled/submitted -> idempotent no duplicate; - generating -> either queue one visible post-turn intent or return `ALREADY_RUNNING`; select one behavior and cover it in UI/tests. Acceptance: core tests prove Pause, Continue Now and Stop are distinct. ## Phase 3 — Continuation policy API ### C3.1 Worker policy Add MCP/core operations to read/change worker continuation policy. Minimum: ```text mode: manual | auto idleGraceMs stall thresholds ``` ### C3.2 Run default Optionally add run-level default policy inherited by child workers. Explicit worker override wins. If run default is deferred, plugin may apply policy to selected workers individually; document the temporary behavior. ### C3.3 Policy events Append `continuation.policy_changed` for every mutation. Acceptance: policy survives restart and never lives only in extension storage. ## Phase 4 — Backend continuation scheduler ### C4.1 Idle evaluation When a managed conversation transitions to idle: 1. record/close current execution attempt as idle; 2. begin durable/recoverable idle-grace evaluation; 3. after grace, load current worker/run state; 4. apply the normative evaluation order from the spec; 5. schedule exactly one `auto_resume` attempt when eligible. ### C4.2 Cancellation races Handle: - worker completes during grace; - worker fails/cancels during grace; - operator pauses during grace; - worker becomes human/dependency blocked during grace; - policy switches off during grace; - duplicate/repeated idle frames; - executor disconnect while resume is scheduled. ### C4.3 Dispatch seam Refactor the current explicit `dispatchFollowup` pattern into reusable execution dispatch capable of: ```text initial bootstrap follow-up assignment manual resume auto resume recovery resume ``` Each attempt gets a unique command ID and stable idempotency key. Do not replace `worker.followup`: follow-up means a new/replaced assignment, whereas resume means continue the current assignment. Acceptance: synthetic core/bridge integration can drive idle -> auto-resume -> idle repeatedly without browser code. #### Active keepalive + event wake extension Implement backend-owned wake intents with: - jittered 20–21 minute active keepalive deadlines for active Auto workers, including workers currently `generating`; - checkpoint prompt generation that requires an immediate durable update to `/root` (commit(s), completed work, current work, remaining work, blockers/contracts) and then explicitly says to continue working to completion; - mid-turn ordinary-ChatGPT-UI steering delivery for generating conversations, with exactly-once journaling and fail-closed behavior if the steering seam is unavailable; - 15-minute non-idle minimum continuation spacing; - durable `notBefore` deferral rather than dropping an early wake; - idle bypass of the spacing floor after idle grace; - coalescing of commit/progress/dependency/root/watchdog reasons into one pending continuation; - restart reconstruction of pending wake deadlines/intents; - root wake on worker progress/message/commit reports; - root review of each material report against the complete run plan, ownership map, dependencies, integration state and acceptance criteria; - explicit steering outcomes (`continue_as_planned`, `correct_direction`, `change_priority`, `provide_dependency`, `request_evidence`, `pause`, `terminal_reconcile`); - ordinary lane continuation routing with the 15-minute anti-spam floor; - immediate material corrective steering when waiting for the floor would knowingly allow divergence, with durable dedupe/exactly-once guarantees. Acceptance: a generating worker receives a queued checkpoint keepalive intent at the 20–21 minute deadline; when legally deliverable it receives a steering/checkpoint message without waiting for idle, sends a durable progress/commit report to root, and continues its assignment. If its previous non-idle checkpoint was <15 minutes ago the intent remains durable until the floor expires; an idle transition can deliver immediately; duplicate events coalesce and do not create duplicate prompts. ## Phase 5 — Worker bootstrap / behavioral contract ### C5.1 Update bootstrap text Version the worker bootstrap so workers know the explicit ending protocol: ```text complete -> worker.complete irrecoverable -> worker.fail human input needed -> worker.await_human dependency wait -> worker.await_dependency otherwise stay active ``` ### C5.2 Resume prompt Add a versioned resume prompt generator separate from follow-up assignment prompt generation. It must tell the worker to: - recover authoritative state through MCP; - inspect durable repository/worktree/progress state; - avoid redoing completed work; - continue current assignment/acceptance criteria; - use explicit completion/blocking tools before ending. Do not inject the entire assignment into every resume prompt. ### C5.3 Root bootstrap Ensure `/root` can use the same execution-continuity contract when it has a managed conversation binding. Acceptance: prompt generator tests lock the essential contract without overfitting wording. ## Phase 6 — Make conversation lifecycle asynchronous This phase is critical for avoiding a new execution-time dependency inside the orchestrator itself. ### C6.1 `conversation.send` completion semantics Change executor command semantics so a successful send finishes after safe, exactly-once prompt submission/acceptance. It must not wait for ChatGPT to finish generating. ### C6.2 Continuous/coarse state observer Extend the content/background seam to publish state transitions independently: ```text ready -> generating generating -> idle any -> error/closed ``` Use MutationObserver/reconciliation and coalesce duplicate states. The current WIP `waitFor()` implementation can remain useful for bounded submission prerequisites, but it must not be the sole mechanism for long-generation lifecycle observation. ### C6.3 Reconciliation on reconnect On extension reconnect: - verify each managed tab still belongs to ChatGPT; - inspect current state; - republish binding + state; - allow backend scheduler to reconcile pending continuation. Acceptance: - a 30+ minute simulated generation does not require one executor command to remain unresolved; - executor connection may reconnect during generation without losing the eventual idle transition. - mid-turn checkpoint steering can be submitted through ordinary ChatGPT UI while generation is active when supported, without stopping generation and without waiting for idle; unsupported/changed UI fails closed with the durable intent preserved. ## Phase 7 — Exactly-once resume delivery ### C7.1 Journal phases Ensure journal/recovery paths cover auto/manual resume commands exactly like existing follow-up sends. Required behavior: - `completed` -> replay stored result; - `submitted` -> reconcile, no resend; - `submission-started` ambiguous -> fail closed; - expired command before submission -> fail without side effect. ### C7.2 Backend dedupe Core must also prevent multiple auto-resume attempts for the same idle boundary. Use execution attempt/idempotency identity rather than relying only on extension command journal. ### C7.3 Race qualification Test worker completion arriving: - before resume scheduling; - after scheduling but before command dispatch; - after ACK but before submission; - immediately after submission. Acceptance: no duplicated continuation prompts. ## Phase 8 — Stall/runaway protection ### C8.1 Progress-aware counters Track per worker: - execution attempts since last progress; - duration since last progress; - last progress cursor/time. ### C8.2 Warning threshold When warning threshold is crossed: - append continuation warning event; - show operator warning; - continue only if policy permits. ### C8.3 Automatic stall pause When pause threshold is crossed: - set worker to paused-for-stall; - suppress future Auto Resume; - preserve worker/attempt history; - require explicit operator/root recovery. ### C8.4 Recovery action `Continue anyway` acknowledges/resets stall guard and schedules one manual attempt or restores Auto Resume according to user choice. Acceptance: productive progress across many turns never trips the no-progress counter; repetitive no-progress turns do. ## Phase 9 — Extension toolbar popup ### C9.1 Browser action Add a toolbar popup as the primary operator surface. Top-level content: - executor connection state; - Auto Resume global/run state where available; - counts: active, working, resuming, needs-you; - list of active workers; - current-tab worker section; - Pause and Continue Now actions; - links to dashboard/settings. ### C9.2 Worker rows Each row shows human-relevant fields: ```text assignment/run title or worker label hierarchical worker name Working / Resuming / Needs you / Waiting / Paused / Complete execution attempt number number of automatic resumes last durable progress age ``` Keep raw IDs available only in diagnostics/details. ### C9.3 Action semantics Wire buttons to backend operations, not direct arbitrary DOM submission: - Auto Resume toggle -> continuation policy; - Pause -> worker pause intent; - Continue Now -> worker continuation API; - Stop worker -> existing interrupt/cancel semantics with destructive confirmation if appropriate. Acceptance: extension UI does not independently decide to send resume prompts. ## Phase 10 — Managed-tab overlay ### C10.1 Isolated overlay host Inject an extension-owned Shadow DOM overlay only for managed ChatGPT conversations. Collapsed statuses: ```text Orchestrated · Auto Resume Working · Attempt N Continuing · Attempt N Needs you Paused Complete ``` ### C10.2 Compact drawer Click expands details: - worker/run name; - status; - attempt number; - auto-resume count; - last durable progress; - policy; - Pause / Continue Now / Stop worker; - recent continuity events. ### C10.3 UX constraints - do not cover composer/send/stop controls; - keyboard accessible; - status not encoded by color alone; - user can hide overlay globally; - no reliance on ChatGPT visual CSS classes for overlay layout. Acceptance: overlay appears only on explicitly managed tabs and remains isolated from ChatGPT DOM styling. ## Phase 11 — Operator dashboard and advanced settings split ### C11.1 Preserve advanced options Keep endpoint/token/executor ID/concurrency/managed conversation limits in the existing settings page, relabeled/grouped as Advanced where appropriate. ### C11.2 Runtime dashboard Add an operator-oriented dashboard with: ```text run worker state auto-resume policy current attempt resume count last progress block reason conversation link when available ``` ### C11.3 Run controls Add: - Auto Resume unfinished workers; - Pause all after current turns; - Resume all unfinished; - Stop run. Run-level and worker-level override states must be visually distinguishable. ### C11.4 Stall UX Show actionable stall cards: ```text Worker appears stuck N attempts / no durable progress for T [Continue anyway] [Pause] [Open conversation] [Stop worker] ``` Acceptance: a user can understand the entire active orchestration without inspecting raw extension storage or MCP state. ## Phase 12 — Root-worker continuity ### C12.1 Managed root binding Provide/confirm the mechanism by which `/root` is recognized as the current managed ChatGPT conversation without violating the managed-tabs-only rule. If user-attached root tabs are supported, attachment must be explicit and persisted. ### C12.2 Root scheduler behavior A root worker that becomes idle while run/children remain active may auto-resume according to policy. Typical resumed behavior: ```text read run state events.wait bounded loop answer worker messages unlock dependencies integrate completed work complete root/run when terminal ``` ### C12.3 Human interaction If root calls `worker.await_human`, Auto Resume stops and UI promotes the root request to `Needs you`. Acceptance: full manager/worker run can progress across multiple root execution boundaries with no manual `continue` messages. ## Phase 13 — Ownership/provenance integration Coordinate with `docs/specs/worktree-conversation-ownership.md`. ### C13.1 Execution provenance Ensure worktree ownership/provenance can reference the currently active execution/session while retaining one logical worker/conversation owner. ### C13.2 UI projection Where ownership data is available, show in dashboard/details: - worktree/branch; - current execution attempt/session; - conversation; - last WIP preservation/landing state. Do not block the initial Auto Resume MVP on full Git integration. Acceptance: automatic resumes never create a second worktree owner or lose the original conversation provenance chain. ## Phase 14 — Error/restriction handling ### C14.1 Host UI change `HOST_UI_CHANGED` pauses affected execution and surfaces operator action. Never approximate-click after locator invariant failure. ### C14.2 Ambiguous submission `AMBIGUOUS_SUBMISSION` pauses/requires reconciliation. Never auto-resend a possibly delivered prompt. ### C14.3 Product/error states Classify coarse recoverable vs non-recoverable browser/product states where feasible. The orchestrator may retry ordinary transient transport/UI recovery according to bounded policy, but must not treat upstream usage/rate/safety/confirmation restrictions as something to evade. ### C14.3a Message delivery timeout: fresh continuation, never Retry Add a dedicated adapter/executor classification for the ChatGPT UI condition: ```text Message delivery timed out. Please try again. ``` Required behavior: - detect the delivery-timeout banner/state semantically; - **do not click ChatGPT's `Retry` button**; - mark the current execution attempt as ended with a delivery-timeout outcome while preserving the worker as unfinished; - wait for the composer to be safely available; - schedule a new continuation attempt through the backend; - send a fresh user message whose content is exactly `continue`; - use the existing exactly-once command journal/idempotency path for that fresh send; - on resume, require normal durable-state reconciliation before repeating any uncertain implementation action; - if the condition repeats, repeat the fresh-continuation path subject to Auto Resume/stall/pause rules, never the Retry control. This rule is intentionally different from replaying an ambiguously delivered orchestrator command: the browser Retry control is prohibited for this UI state, while the new `continue` message is a distinct execution attempt with its own command/execution identity. Acceptance: 1. fixture/unit test contains the delivery-timeout banner and Retry button; 2. adapter returns the dedicated classification; 3. no click is dispatched to Retry; 4. backend records a new continuation attempt; 5. extension submits `continue` exactly once through the composer; 6. resulting generating/idle lifecycle is observed normally. ### C14.4 Executor unavailable Keep intent durable and reconcile after reconnect without duplicate continuation. Acceptance: failure modes are visible in UI and event history rather than silently spinning. ## Phase 15 — Automated test matrix ### C15.1 Protocol/core Cover every continuation evaluation branch and race from the spec. ### C15.2 Persistence chaos Kill/restart around every scheduling/submission/idle boundary and prove convergence. ### C15.3 Extension unit/integration Mock WebExtension APIs for: - popup state/actions; - overlay managed-tab filtering; - continuous state observation; - per-worker serialization; - reconnect state republish; - command journal recovery. ### C15.4 MCP integration Synthetic workflow: ```text run.create worker.spawn worker.attach initial attempt idle event auto resume progress idle event auto resume worker.complete idle event assert no resume ``` Acceptance: no test depends on a real browser until isolated E2E phase. ## Phase 16 — Isolated browser qualification Use `debian1/2/3` isolated displays/profiles only. ### C16.1 Multi-turn completion proof Use an assignment intentionally requiring multiple turns. User sends no follow-up messages. Prove: ```text attempt 1 -> idle -> auto attempt 2 attempt 2 -> idle -> auto attempt 3 ... worker.complete -> idle -> STOP ``` Store state/event receipts, not arbitrary transcript content. ### C16.2 Human wait proof Worker calls `worker.await_human`; no further prompt is submitted until explicit resolution. ### C16.3 Pause proof Pause after current turn suppresses the next attempt while preserving unfinished worker state. Continue Now resumes same managed conversation exactly once. ### C16.4 Restart proof Repeat with extension/backend restart at selected boundaries. Prove no duplicate continuation prompt. ### C16.4a Delivery-timeout proof In an isolated browser fixture/live-safe scenario, produce the ChatGPT `Message delivery timed out. Please try again.` state. Prove: ```text Retry button is present | +-- plugin does NOT click Retry | v worker remains non-terminal | v new execution attempt scheduled | v fresh user message: continue | v normal generation resumes ``` Capture executor/event receipts proving the fresh `continue` command identity and absence of Retry interaction. ### C16.5 Root orchestration proof Root + two children execute across multiple turn boundaries. Root auto-resumes, handles messages, and eventually completes run with no manual `continue`. ### C16.6 Chromium compatibility Repeat core managed resume flow with Chromium build after Firefox qualification. ## Phase 16.5 — LibreWolf dead-man continuity fallback Only after backend timer/event continuity is qualified, add a bounded plugin-side defense-in-depth fallback for catastrophic loss of normal wake paths. It must: - detect that the backend considers a run active while all relevant managed conversations are errored/closed/unrecoverable or normal wake delivery has exceeded a conservative dead-man threshold; - request backend-authorized recovery/rebind rather than inventing new orchestration state locally; - never create a second independent auto-resume policy; - deduplicate against existing scheduled/queued continuation intents; - expose durable evidence that fallback recovery fired; - remain safe if disabled. Acceptance: disabling this layer leaves normal orchestration fully functional; enabling it recovers a synthetic all-conversations-dead condition without duplicate continuation delivery. ## Phase 17 — Documentation and release ### C17.1 Operator docs Document: - what Execution Continuity means; - Auto Resume semantics; - Pause vs Continue Now vs Stop; - `Needs you` and dependency waits; - stall warnings; - recovery from ambiguous/host errors; - privacy boundary. ### C17.2 Developer docs Document: - worker vs conversation vs execution-attempt identity; - scheduler state machine; - executor lifecycle reporting; - idempotency strategy; - persistence/restart invariants; - extension UI/backend responsibility split. ### C17.3 Rollout defaults Recommended rollout: 1. ship backend/manual Continue Now first; 2. opt-in Auto Resume per worker/run; 3. qualify on isolated browsers; 4. enable root-worker continuity; 5. keep migrated/existing workers manual by default until operator enables Auto Resume; 6. consider changing defaults only after production observation. ## UI acceptance snapshot The extension should feel like an execution controller, not a `continue` macro. Toolbar target: ```text +-----------------------------------------+ | ChatGPT Orchestrator * Live | +-----------------------------------------+ | EXECUTION CONTINUITY | | Auto Resume [ ON ] | | Keep unfinished workers running across | | ChatGPT turn boundaries. | | | | Active 3 Working 2 Resuming 1 | | Needs you 0 | +-----------------------------------------+ | /root/backend | | Working · Attempt 3 · progress 2m ago | | | | /root/plugin | | Resuming · Attempt 6 · 5 auto resumes | | [Pause] | +-----------------------------------------+ | Current: /root/plugin | | [Pause] [Continue now] | +-----------------------------------------+ | Open dashboard Settings > | +-----------------------------------------+ ``` Managed-tab overlay target: ```text [ Working · Attempt 4 · Auto Resume ] ``` Expanded: ```text Plugin migration /root/plugin Status Working Attempt 4 Auto resumes 3 Last progress 2m ago Auto Resume On [Pause] [Continue now] [Stop worker] Recent 11:02 Auto-resumed 10:34 Progress checkpoint 10:31 Auto-resumed ``` ## Phase 18 — Agent output contract and reusable skill ### C18.1 Canonical output-only Agent Skill Maintain: ```text skills/durable-continuation-output/SKILL.md ``` with frontmatter name `durable-continuation-output`. The skill only defines the required `` block and status meanings. Explicitly exclude: - ChatGPT Retry behavior; - instructions to send `continue`; - browser state or UI detection; - execution-boundary detection; - auto-resume scheduling; - MCP lifecycle mechanics; - repository/worktree recovery methodology; - project-specific execution policy. Acceptance: a worker can read the skill and learn only how to expose resumable output state, not how orchestration works. ### C18.2 Parser and validation Add a backend parser for the exact end-of-response contract: ```text status: working | complete | blocked summary: ... current: ... next: ... ``` Validate status and required fields, cap field sizes, reject duplicate/malformed blocks, and treat page content as untrusted input. Missing/malformed output must fail safe rather than fabricate completion. ### C18.3 Backend interpretation Map parsed output into durable execution-continuity state without making it the sole source of truth: - `working` -> eligible for another execution when continuation policy permits; - `complete` -> reconcile with durable worker/acceptance state before terminal completion; - `blocked` -> surface blocker and suppress automatic continuation until resolved. Acceptance: backend scheduling remains authoritative and independent of the skill's prose. ### C18.4 Minimal bootstrap The managed-worker bootstrap identifies the assignment/worker and requires the installed/output contract, but does not paste browser or orchestration policy into the agent prompt. Do not tell the agent to click Retry, send `continue`, detect execution boundaries, or schedule itself. ### C18.5 Executor continuation stays executor-owned Keep fresh continuation-message generation, Retry suppression, delivery-timeout behavior, idle observation, scheduling, dedupe, pause/stall policy, and exactly-once submission in the orchestrator/extension implementation. Acceptance: executor policy can change without modifying the Agent Skill. ### C18.6 Skill packaging Add a reproducible packaging path producing an uploadable archive containing the skill directory and `SKILL.md`. Validate frontmatter and archive structure. Do not include secrets, local state, transcripts, or repository-private artifacts. ### C18.7 Acceptance test Use a generic multi-turn worker assignment. Prove the worker can do the task normally and end with a valid continuation-state block while remaining ignorant of browser Retry/`continue`/auto-resume mechanics. Prove the backend independently chooses whether to schedule another execution. ## Completion definition The implementation program is complete only when all of the following are true: - `Worker` remains authoritative across multiple ChatGPT turns; - `ExecutionAttempt`/equivalent durable history exists; - Auto Resume is backend-controlled and policy-driven; - `generating -> idle` is asynchronously observed and does not require one long command; - idle + non-terminal + runnable + Auto Resume produces exactly one continuation; - complete/failed/cancelled/human-wait/dependency-wait/paused states suppress continuation; - Pause, Continue Now and Stop are separate API/UI operations; - continuation survives backend/extension/browser restart without duplicate prompts; - stall protection is based on missing durable progress and can pause runaway loops; - toolbar popup and managed-tab overlay provide clear operator visibility; - advanced connection/concurrency settings remain separate from runtime operation UI; - root and child workers both support continuity; - provenance remains consistent across execution attempts/worktree ownership; - protocol/core/persistence/extension test suites pass; - isolated Firefox and Chromium E2E pass on buildboxes; - a deliberately multi-turn engineering job reaches `worker.complete` with **zero manual `continue` prompts**; - all implementation/docs are committed and pushed with no required feature state existing only as local WIP.