P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale)

[James3014]

Parent

Child of #104 (DevSpace Ultra parity reconciliation).

Priority

P1 — required for Ultra-style normal UX after peer-swarm baseline is proven.

Current #46–#49 cover Swarm state/protocol/tooling/live peer baseline. Current #50 is an optional OpenCLI transport experiment. Neither currently owns the full worker carrier lifecycle needed for the Ultra-style experience where the user/main GPT does not manually prepare every worker conversation.

Goal

Provide one bounded macOS worker-carrier lifecycle abstraction so a Main ChatGPT orchestrator can ensure/resume usable ChatGPT worker capacity, then let Chat Swarm remain the task-routing authority.

Behavioral target:

Main GPT
  -> ensure worker capacity N
  -> start/create/resume supported worker carriers as needed
  -> bind/join them to Chat Swarm
  -> park idle workers without model polling
  -> wake exact worker when targeted work arrives
  -> recover stale/lost carrier without changing logical worker identity
  -> scale up/down safely

The user should not need to copy invite codes/prompts between worker conversations during normal operation once the chosen carrier adapter is configured and admitted.

Ultra reference boundary

Ultra proves the behavior using Windows ChatGPT Classic isolated runtimes, CDP/bootstrap, saved conversation mappings, runtime ensure, recovery, and worker wake paths.

DevSpace macOS MUST NOT copy Windows-specific mechanics as architecture:

• no AppX/package-clone assumptions;
• no Windows chatgpt:// ownership/provisioning logic;
• no cookie/session cloning as authority;
• no forced adoption of browser automation if the current platform/runtime does not support a safe bounded carrier;
• no browser state as Swarm/task authority.

The first gate is therefore carrier capability discovery, not implementation by analogy.

Relationship to #50

#50 remains the bounded optional OpenCLI ChatGPT runtime adapter experiment.

This Issue owns the higher-level lifecycle contract:

WorkerCarrierManager
  ensure
  status
  start/create-or-bind
  wake
  park
  recover
  scale
  stop/release

#50 may become one adapter underneath this contract if fresh macOS evidence supports it. A native MCP-peer or another supported carrier may also satisfy the contract. Do not make OpenCLI the Swarm authority.

Required architecture

Chat Swarm durable truth
  workerId / taskId / attemptId / queue / result
        |
        v
Worker Carrier Lifecycle
  runtime/carrier health + wake/recover only
        |
        +--> native MCP peer carrier
        +--> OpenCLI/web carrier (#50 candidate)
        +--> other bounded supported carrier

Carrier state must never grant/revoke task authority by itself.

Required semantics

1. Stable logical identity

workerId != carrier/conversation ID.

Carrier replacement/recovery must preserve the existing logical worker only through an explicit #51-compatible continuation/rebind contract.

2. Ensure

A bounded ensure equivalent must:

• inspect required worker capacity;
• reuse healthy already-bound workers;
• create/start only missing capacity;
• avoid duplicate worker creation under replay;
• return exact logical worker + carrier binding state;
• be idempotent for the same requested capacity/config.

3. Wake / park

Normal idle workers should not burn model turns polling.

The runtime should support a bounded wake signal/event when work becomes available. If the selected carrier cannot be server-pushed/woken safely, expose that limitation explicitly rather than emulating busy polling.

4. Recovery

For stale/lost carrier:

carrier lost
!= worker lost
!= task failed
!= retry safe

Recovery must first inspect Swarm task/attempt state. If a task may have started or an external effect is unknown, preserve RECONCILE_REQUIRED; do not create a fresh worker attempt blindly.

5. Scaling

Scale-up may add idle logical workers/carriers within configured limits.

Scale-down must refuse to evict workers that are:

• executing;
• holding a targeted queued task;
• in continuation/reconciliation;
• otherwise required by an unresolved external effect.

Prefer tail/explicit worker retirement with deterministic identity handling; do not reshuffle live ownership silently.

6. Exact carrier evidence

Receipts/status must distinguish:

• logical worker ID;
• carrier kind;
• carrier/conversation fingerprint or bounded identifier;
• current binding epoch;
• online/parked/busy/reconcile-required state;
• source/build/capability identity of Dev MCP;
• adapter/runtime version when relevant.

Do not expose credentials or raw secret session material.

Required tool surface

Exact names may follow repository conventions, but provide equivalents of:

chat_swarm_runtime_status     # read-only
chat_swarm_runtime_ensure
chat_swarm_runtime_recover
chat_swarm_runtime_scale
chat_swarm_runtime_stop       # owned carriers only

If wake/park are internal lifecycle operations, they still need observable state/tests.

Gate sequence

G0 — macOS carrier feasibility / support matrix

Freshly test what can actually provide isolated/resumable ChatGPT worker carriers on the target Mac:

• native MCP peer conversations;
• OpenCLI/web path from exp(chat-swarm): add optional OpenCLI ChatGPT runtime adapter #50 if available;
• supported browser tab carrier if applicable;
• any other documented supported path.

For each record: create/bind, targeted send/wake, result readback, conversation identity, reconnect/restore, concurrency, cancellation/reconciliation limits.

Do not implement a Windows clone substitute without evidence.

G1 — lifecycle contract + fake/injected adapter

Implement deterministic manager semantics independent from one real carrier.

G2 — first real macOS carrier adapter

Bind the smallest proven carrier behind the contract.

G3 — zero-copy / no-manual-bootstrap witness

Main creates/ensures >=2 worker capacity without the user copying task/invite text between chats.

G4 — targeted wake + recovery

Park both workers, target one exact worker, prove only it wakes/claims; then lose/recover that carrier while preserving logical identity and task truth.

G5 — elastic scale witness

Scale 2 -> 3 -> 2 with no busy/targeted worker eviction and no lost/duplicate work.

Required tests / hostile controls

• exact replay of ensure creates no duplicate worker;
• conflicting ensure/config identity fails closed;
• two logical workers never bind the same live carrier unless explicit sharing semantics exist;
• one worker cannot adopt another worker's carrier continuation;
• busy worker cannot be scaled out;
• unknown task effect blocks destructive recycle/replacement;
• carrier restart/loss never auto-requeues potentially started work;
• old carrier is fenced after successful feat(chat-swarm): add durable worker continuity and conversation rollover #51 continuation rebind;
• Dev MCP restart preserves lifecycle state/projection without minting task truth;
• carrier failure does not corrupt Swarm queue/result state.

Dependencies

• test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 live peer-swarm baseline must be proven before final live lifecycle acceptance.
• feat(chat-swarm): add durable worker continuity and conversation rollover #51 defines logical-worker continuation/rebind semantics used by recovery.
• exp(chat-swarm): add optional OpenCLI ChatGPT runtime adapter #50 may provide a real carrier adapter but is not the lifecycle authority.
• Epic: reconcile DevSpace Ultra parity for GPT peer swarm and conversation continuity #104 owns parity closure.

Non-goals

• no Windows runtime cloning;
• no credential/session-cookie copying;
• no CAPTCHA/rate/quota bypass;
• no automatic model/account rotation;
• no Nexus Planner/Workforce/Completion authority;
• no repository mutation authority merely because the worker carrier exists;
• no claim of automatic ChatGPT carrier creation if the selected macOS transport cannot support it.

Exact next gate

DEVSPACE_ULTRA_WORKER_RUNTIME_G0_MACOS_CARRIER_MATRIX

Prove the supported macOS carrier options and freeze the first real adapter before implementing platform-specific lifecycle automation.

Claim ceiling

WORKER_CARRIER_LIFECYCLE_CONTRACT_PLANNED — MACOS_REAL_CARRIER_NOT_YET_PROVEN

[James3014]

V2 設計補強：真的待命／喚醒，而非 next 回 null 後期待 GPT 自動工作

Parent #104；native admission 與 readonly roster owner 是 #108。以下補強本 Issue 的 lifecycle/delivery contract，不重造 Swarm task store。

Source 對照

DevSpace main 8da19eb34e2fcdd9cf36faf2064911d5cbed7020 的 next 是同步 current-task/claim，無 task 回 null；dispatch 可先綁定 worker/CLAIMED，但不送進另一個已結束的 ChatGPT turn。

Ultra 2c61c79ffe269d31523bac37ae6ecd60c9065a5e 有兩條不同路徑：

• Classic native next：waitForWorker / wakeWorker / bounded lease heartbeat；已有 in-flight tool call 才有等候者。
• Browser bridge：event stream + exact tab wake + 一次 turn + submit_once。content.js 實作的 wake payload 帶 token 與已 claimed task，不等同 README 的 wake 後 claim，也不應照抄 token 洩漏。

因此本 Issue 必須實作／證明 delivery liveness，不只 create/start UI process。不能聲稱 source 有 Swarm 就可自動喚醒所有 ChatGPT session。

三種模式與相容性

1. MANUAL_TURN_DRIVEN：test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 baseline；不承諾常駐、自動喚醒。
2. MCP_LONG_WAIT：限 current Host 支援的 bounded in-flight wait；tool timeout、cancel、斷線均有結果，不能假設 donor 20–25分鐘預算適用 macOS Web。以低頻 transport heartbeat（如果協議支持）維持傳輸，不用 LLM idle polling。
3. CARRIER_EVENT_WAKE：限經 Owner 設定/授權且實測的 carrier；向 exact worker + epoch + conversation 發送有界提示/事件。若 action 被 Host 拒絕，保留拒絕，不換渠道執行同一被封鎖 action。

能力矩陣需逐項標 create/bind、user-consent requirement、wait/wake、result readback、reconnect、cancel、model turn結束後能否重啟。未知/不支援保持 UNKNOWN/UNSUPPORTED，不自動選另一 transport。

Bounded wait contract

• 每個 worker + continuationEpoch 最多一個有效 waiter；重入／舊 waiter 必須有 deterministic identity fence。
• 先檢查 canonical assignment，再註冊 waiter，再 recheck，避免 dispatch 在 check/register 之間丟失喚醒。
• waiter 是短命 transport projection；task/attempt/result 在既有 SQLite，process restart 不讓 waiter 自己重建 task。
• distinguish IDLE_NO_TASK / WAIT_REGISTERED / TASK_AVAILABLE / DISABLED / RECONCILE_REQUIRED / CLOSED；不再用同一 null 暗示所有狀態。
• 取消 wait 只取消等待；不把 assigned task 當作沒執行，不自行 requeue。
• 如 wait 同時 claim task，readOnlyHint 必須 false。唯讀 wait/read 與 mutating claim 可拆開，但不得 fake read-only。

Event-wake contract

若選擇 event carrier：

• 在既有 store 上建立有界 delivery/outbox 記錄（可用同交易），只記 canonical task/attempt/worker/epoch/version refs，不另建第二個 task truth。
• wake 是提示，不是 task authority、不證明已接收／開始。重複事件只觸發 canonical readback，不能創造新 attempt。
• bounded delivery cursor / dedup key；worker換 epoch 後舊 event不能喚醒或派發新carrier。
• durable assignment -> event available -> target delivery acknowledged -> execution start witness -> result persisted，各階段分別觀測。當前 CLAIMED不自動改稱STARTED。
• 外部 Send 可能已生效但 acknowledgement 遺失時，保存 exact delivery/operation reference並reconcile；禁止以新prompt或新attempt盲重送。
• credentials只在受保護transport auth內使用，不放入 model prompt、wake payload、logs或continuity capsule；opaque event ID本身不得授權。
• 支持backpressure、bounded queue/timeout、明確人工介入狀態。不能用持續模型輪詢冒充 zero-idle-cost。

Admission / recovery / protected Main

ensure只重用已驗證正常的worker；缺失 capacity使用 #108 已批准身份／相容admission，不從label或視窗存在推導authority。Worker ID使用真正回傳值。

carrier失聯/視窗關閉不等於remote generation停止。先讀exact task/attempt，再決定恢復。同一logical worker更換conversation透過 #51-A epoch/rebind；unknown維持reconcile，不scale out/discard。

Main/使用者互動中的carrier必須排除自動stop/recycle/rotation；目標不明確時不能為湊worker count關閉視窗或進程。

無循環依賴與 Gate

• test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 manual native baseline 先完成，不能等本 Issue 才解鎖。
• P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 feasibility及injected-adapter source設計可進行；real acceptance仍需 test(chat-swarm): run isolated 2-worker ChatGPT live canary #49。
• feat(chat-swarm): add durable worker continuity and conversation rollover #51-A deterministic identity/epoch提供recovery。
• 本Issue證明可用carrier後，feat(chat-swarm): add durable worker continuity and conversation rollover #51-B才跨real Auto Compact gate；不互相等待整張Issue關閉。
• #50只是其中一個experimental adapter，不是替代native #49的捷徑。

額外必測

lost-wakeup race、duplicate concurrent waits、cancel wait with assigned task、restart with unacked delivery、event replay/old epoch、worker unknown effect禁止recycle、token-free payload/redaction、真Host不支援時回明確block、兩peer各自target wake與零cross attribution。

只有fresh macOS實體證據證明可喚醒已結束turn的精確carrier，才能claim CARRIER_EVENT_WAKE；native tool wait成功本身不授予該claim。Source tests與donorWindows報告都不是本機host acceptance。

[James3014]

G1 injected carrier source is integrated through PR #116. Candidate 12457e5f76cf98aebe9d38704038c5d47c399254 was merged as ab22dc9d0360bd02d00892734a5c51cdd0873f39; GitHub main was read back at that merge. The final tree 6d04aca44167fc6561e3c2b4014bb99619d9a1ed equals the independently checked candidate and CI integration tree.

Luna implemented the slice; the primary controller independently inspected the eleven-file diff and passed the full macOS test suite, typecheck, twelve disposable-fixture behavioral probes, and a real v17-to-v18 database upgrade preserving canonical Swarm/worker/task rows. Node22 CI passed macOS Smoke (tests/build/Doctor), macOS local-agent sessions, and Ubuntu Smoke. Windows Smoke failed seven unchanged carrier-binding tests and remains outside this Owner-selected macOS workstream. No check or protection was weakened.

This delivers durable ENSURE/WAKE intent, semantic replay slots, exact acknowledgement identity, timeout/restart reconciliation, protected-worker guards, and lifecycle inspection/effect boundaries for an injected adapter. It adds no native browser adapter, MCP registration, worker admission, bounded long-wait path, or epoch transfer. No runtime was deployed or restarted by this source integration.

Full acceptance remains pending: #49 still requires its native drain/submit/collect witness; physical carrier feasibility, ended-turn wake, recovery through #51-A, and the overall #104 user workflow remain unproven. The existing Main/Worker-A/Worker-B conversations remain the native test participants.

Bookkeeping correction: a negated sentence in the PR body was parsed as a closing reference and caused an automatic state transition at merge. The sentence and closing association were removed, this Issue was reopened, and its OPEN state was read back. The temporary closure was not an acceptance decision.

[James3014]

Owner product-contract amendment — Zero-touch worker runtime is now P0

This amendment narrows the intended UX and closes the loophole that allowed #49-style manually pre-opened worker conversations to masquerade as product acceptance.

Correction

The normal product topology is not:

James manually opens Main / Worker-A / Worker-B
-> manually reconnects dev-c
-> manually joins/binds
-> manually moves worker/task/result data

That topology is diagnostic/canary-only.

The required product topology is:

James -> one Main ChatGPT conversation
        -> runtime_ensure(desiredWorkers=N)
        -> DevSpace creates/restores/bootstraps worker conversations itself
        -> workers become bound/parked
        -> targeted dispatch wakes exact worker
        -> workers submit
        -> Main collects

After one-time setup/login/consent, normal operation must have zero manual worker interaction.

Ultra donor evidence

devspace-ultra productization explicitly treats Main as the normal operator-facing conversation and worker windows as automatically launched/minimized/monitored lifecycle infrastructure. Its on-demand operator contract uses idempotent runtime_ensure, saved exact conversation mappings, autojoin, targeted recover, project-scoped worker chats, and elastic desiredWorkers; normal work is dispatched through the backend, not by typing into worker UIs.

Reference:

• https://github.com/enwong93-sketch/devspace-ultra/blob/main/docs/chat-swarm-classic-productization.md
• https://github.com/enwong93-sketch/devspace-ultra/blob/main/docs/chat-swarm-classic-operator.md

Current implementation truth

PR #116 is G1 foundation only: durable ENSURE/WAKE operation journaling + injectable adapter contract. PR #116 explicitly adds no real adapter, MCP runtime management tools, browser/session creation, admission bootstrap, long-wait implementation, or live wake acceptance.

Therefore:

#116 merged/deployed
!= real carrier implemented
!= native auto-wake
!= zero-touch worker runtime

New focused implementation owner

#117 — P0: implement macOS zero-touch ChatGPT Web worker runtime pool

#117 owns the first real adapter and product path:

• bounded worker-limit expansion beyond the V0.1 literal two-worker cap;
• real macOS ChatGPT Web carrier adapter;
• dedicated subagent-project conversation creation;
• secret-free managed ensure/autojoin;
• dev-c/app-binding health/bootstrap;
• runtime_status/ensure/scale/recover/stop;
• park/wake/recover;
• zero-touch 3+ worker live witness;
• cold/restart ensure and elastic scale.

Acceptance amendment

Manual-preopened Worker-A/B conversations cannot satisfy G2/G3/G4/G5.

Every final live receipt must state post-setup Owner interaction counts:

manual worker window creation      0
manual worker dev-c selection      0
manual join/invite transfer        0
manual workerId/taskId transfer    0
manual worker wake                 0
manual worker result relay         0

#49 remains useful native/manual peer-baseline evidence, but finishing its historical manual drain scenario is not a prerequisite to implement #117 source/runtime work. Final parity acceptance will be rerun through the zero-touch generation.

[James3014]

#117 G1 source is accepted into main via clean PR #131.

Canonical lineage:

• PR head bb06b4df469b8c6d6c47ed894b3d0e97257a137a
• main merge da4be27769c72e42ec24882145d8a84a804a4999
• exact-head CI refactor(review): compose presentation profiles Waishnav/devspace#234 / run 34757239223: macOS Smoke Typecheck/Test/Build/Doctor PASS; Ubuntu Smoke PASS; all focused macOS continuation + Local Agent PASS. Windows remains the same pre-existing 7-test carrier-binding baseline and is outside the current macOS-only acceptance target.

Source claim: MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_G1_SOURCE_ACCEPTED.

#105/#117 physical product acceptance is still pending real native G0/G2-G6 witness. Exact blocker in the current controller environment: NATIVE_MACOS_CHATGPT_BROWSER_CARRIER_WITNESS_REQUIRED. Do not infer zero-touch live acceptance from source merge alone.

[James3014]

#117 dependency update — G1 source accepted; live lifecycle still pending

Clean #117 source integration is now canonical via PR #131 / main da4be27769c72e42ec24882145d8a84a804a4999.

This advances #105's implementation side: real macOS web carrier source, managed ensure/bootstrap, six runtime tools, wake/recover/scale/stop semantics and per-boot physical revalidation are merged and macOS CI accepted.

Do not close #105 from source merge. The remaining #105/#117 closure is physical target-Mac acceptance: G0 browser/app-binding mechanism plus zero-touch create/bind, targeted wake, recovery, elastic scale and cold ensure. Canonical native manifest is #117 comment 5653475229.

Current ceiling: WORKER_CARRIER_LIFECYCLE_SOURCE_READY — MACOS_REAL_ZERO_TOUCH_CARRIER_NOT_YET_PROVEN.