Epic: reconcile DevSpace Ultra parity for GPT peer swarm and conversation continuity

[James3014]

Priority

P0/P1 architecture reconciliation — canonical target for the previously requested DevSpace Ultra behavior.

This Issue records the exact behavioral target after re-reading current enwong93-sketch/devspace-ultra source/docs and comparing it with DevSpace #46–#51 and closed #101.

The requirement is broader than cross-session ownership handoff.

Owner intent / target experience

Normal operation should require the user to interact only with one main ChatGPT controller whenever the surrounding ChatGPT runtime/carrier permits it:

James
  -> Main ChatGPT / orchestrator
       -> GPT worker-01
       -> GPT worker-02
       -> GPT worker-03

Main dispatches targeted/parallel work
Workers submit backend results
Main collects/reasons over results

worker conversation reaches pressure/rollover
  -> fresh conversation carrier
  -> same logical worker identity
  -> bounded continuity capsule
  -> continue next task

main conversation reaches pressure/rollover
  -> bounded Goal/frontier checkpoint
  -> fresh main carrier
  -> same logical work continues

unexpected main/controller loss
  -> crash-safe continuation/takeover (#101 fallback)

Source-derived Ultra capability families

Fresh Ultra evidence (v0.5.x line) shows five distinct capability families that must not be collapsed into one generic 'handoff':

U1 — GPT peer swarm

• main ChatGPT orchestrator;
• multiple independent ChatGPT worker conversations/runtimes;
• generic or targeted dispatch;
• backend task queue;
• submit/collect;
• same-worker follow-up/context continuity.

U2 — Elastic worker carrier lifecycle

Ultra productized lifecycle around workers so the main agent can ensure/start/restore/minimize/wake/recover/scale worker carriers instead of requiring the user to manually prepare every worker conversation.

The implementation in Ultra is Windows/ChatGPT-Classic specific; DevSpace must reproduce the behavioral contract, not copy Windows AppX/runtime cloning assumptions onto macOS.

U3 — Durable logical worker identity

workerId != conversationId

A worker survives replacement of its ChatGPT conversation carrier. Continuation identity/tickets are short-lived/single-use and the old carrier loses authority after successful rebind.

U4 — Proactive worker context continuity / Auto Compact

Before a worker context hard-fails:

context pressure
-> mark compact/rollover required
-> wait for safe/idle boundary
-> build bounded capsule
-> create/bind fresh carrier
-> preserve worker/task identity
-> continue worker loop

Estimated context pressure must remain clearly distinct from exact native token telemetry.

U5 — Proactive Main conversation continuity

The user-facing Main controller is also replaceable before hard context exhaustion. Goal/Plan/current frontier/constraints/next action survive as bounded continuity state without copying the full transcript, raw tool history, hidden reasoning, credentials, or stale transport state.

Closed #101 is the crash/loss fallback; it does not replace proactive Main rollover.

Current DevSpace mapping

Ultra behavior	Current DevSpace owner	Current assessment
U1 peer swarm durable store	#46	correct direction; source exists
U1 peer worker identity/protocol	#47	correct direction; source exists
U1 production chat_swarm_* tools	#48	correct direction; source exists, feature-gated
U1 live two-peer canary	#49	still required as live evidence
worker carrier transport experiment	#50	useful adapter experiment but not sufficient for U2
U3 worker rollover	#51	correct core contract
U4 proactive worker Auto Compact	#51 follow-up gate must become required for parity, not indefinite optional future work
controller crash takeover	#101 / PR #102	implemented fallback only
U2 elastic worker carrier lifecycle	new focused child Issue required
U5 proactive Main continuity	new focused child Issue required

Important DevSpace hardening that MUST remain stronger than Ultra

Do not import Ultra behavior where it conflicts with current DevSpace fail-closed invariants.

In particular:

server restart
!= task absent
!= retry safe

Keep:

• OUTCOME_UNKNOWN != retry permission;
• potentially-started work -> RECONCILE_REQUIRED, not blind claimed -> queued;
• corrupt durable coordination state fails closed, not silent fresh-state reset;
• exact task/attempt/effect identity;
• lease/CAS ownership and stale-carrier fencing;
• no browser/session state minting Nexus/DevSpace task authority;
• no model/worker prose becoming completion authority.

Platform boundary

Current DevSpace delivery scope is macOS only.

Ultra may be used as a behavioral reference, but do not copy:

• Windows AppX clone/package identity mechanics;
• Windows chatgpt:// provisioning assumptions;
• cookie/session cloning as an authority mechanism;
• automatic browser/session authority transfer;
• any context estimate presented as exact native token usage;
• restart requeue behavior that can duplicate uncertain work.

The macOS implementation must first determine which supported carrier(s) can satisfy the behavioral contract: native MCP peer conversation, browser/web carrier, OpenCLI adapter, or another bounded supported transport. Carrier choice is execution infrastructure, not Swarm authority.

Required end-state UX

Peer dispatch

User can tell Main:

讓兩個 GPT 分別研究 A / B，再讓第三個 review

Main can deterministically create/resume worker capacity, dispatch tasks, collect results, and target follow-up to one logical worker without manual prompt copy/paste.

Worker rollover

When worker context pressure reaches the configured safe threshold, rollover occurs only at a safe boundary and the same workerId continues on a fresh carrier without duplicate task execution.

Main rollover

When Main context pressure approaches the unsafe boundary, DevSpace prepares a bounded checkpoint/capsule and supports safe continuation into a fresh carrier before the original conversation hard-fails.

Crash fallback

If proactive rollover cannot occur and Main dies abruptly, #101 recovery remains available:

新 Session: 接續剛才的工作
-> latest continuation discovery
-> reconcile active effects
-> fenced takeover
-> continue next gate

Required child work

1. Existing test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 — prove live peer swarm baseline on the exact loaded capability identity.
2. Existing feat(chat-swarm): add durable worker continuity and conversation rollover #51 — durable worker identity/continuation plus a required subsequent proactive Auto Compact gate.
3. Existing exp(chat-swarm): add optional OpenCLI ChatGPT runtime adapter #50 — remain a bounded OpenCLI/runtime-carrier experiment; do not let it masquerade as complete elastic worker lifecycle.
4. New child: macOS elastic ChatGPT worker carrier lifecycle (ensure/start/wake/park/recover/scale).
5. New child: proactive Main conversation checkpoint/rollover continuity using P0: Crash-safe ChatGPT session continuation after context rollover #101 only as crash fallback.

Closure matrix

This Epic closes only when the exact tested macOS runtime supports, with fresh source/build/capability evidence:

• Main -> >=2 ChatGPT peer workers live dispatch/collect;
• deterministic targeted follow-up to the same worker;
• worker capacity can be ensured/recovered without manual prompt copy/paste in the normal path;
• worker logical identity survives carrier replacement;
• worker Auto Compact/rollover crosses a real bounded pressure gate with no duplicate execution;
• Main proactive continuation crosses a real bounded pressure/rollover gate;
• P0: Crash-safe ChatGPT session continuation after context rollover #101 crash takeover remains a working fallback;
• unknown external effects never authorize blind retry/requeue;
• stale old carriers are fenced;
• full transcript/hidden reasoning/credentials are not copied as continuity state;
• fresh ChatGPT host-visible tool/capability surface matches the claimed runtime.

Claim ceiling

Until every relevant child has exact live evidence:

ULTRA_PARITY_TARGET_RECONCILED — END_TO_END_PARITY_NOT_YET_PROVEN

No child source merge, tool registration, or deterministic unit test alone proves the full Ultra-style user experience.

[James3014]

Child mapping created

The Ultra-parity delta is now split without rewriting existing Issue history:

• test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 — live GPT peer-swarm baseline (U1)
• exp(chat-swarm): add optional OpenCLI ChatGPT runtime adapter #50 — optional bounded OpenCLI/Web carrier adapter experiment; transport only
• feat(chat-swarm): add durable worker continuity and conversation rollover #51 — durable worker identity/rollover (U3) plus required proactive worker Auto Compact gate for U4
• P0: Crash-safe ChatGPT session continuation after context rollover #101 — completed crash-safe Main takeover fallback
• P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 — new macOS elastic ChatGPT worker carrier lifecycle (ensure/start/wake/park/recover/scale) for U2
• feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover #106 — new proactive Main checkpoint/conversation rollover for U5

Additional reconciliation comments were written into #46/#47/#48 so current-main source already present is rebound/accepted rather than accidentally reimplemented.

Current recommended sequencing:

source/acceptance reconciliation #46-#48
-> fresh runtime/tool bind + #49 live peer canary
-> #51 deterministic worker continuation
-> #105 real macOS worker carrier lifecycle
-> #51 proactive worker Auto Compact live gate
-> #106 proactive Main rollover
-> #104 end-to-end parity closure

#50 can proceed as a carrier experiment when its own prerequisites are met, but it is no longer treated as the full U2 lifecycle owner.

[James3014]

Ultra 細讀後的 V2 架構裁決與無循環依賴

完整 native admission 修復規格：#108。

研究版本：DevSpace 8da19eb34e2fcdd9cf36faf2064911d5cbed7020；Ultra 2c61c79ffe269d31523bac37ae6ecd60c9065a5e。讀取實際 dist/chat-swarm.js、continuity 文件／實作、Classic productization、bootstrap script、browser README 與 content.js，並與 DevSpace tools/coordinator/store/meta/config/tests 對照。未重新跑 tests 或 native canary。

需要修正的 baseline

1. Ultra native 初次 join 仍有 inviteCode。sessionBound 主要移除後續 workerToken，不是完全無秘密 admission。DevSpace 既有 next/submit 也已依 peer fingerprint 綁定，不需要重新實作 tokenless worker core。
2. Ultra 的 Windows Classic/CDP、native long-wait、browser event-wake 是不同 transport。不能由 donor 的 Windows 實測推出 macOS 標準 ChatGPT 任意 session 都可自動建立／喚醒。
3. Ultra productization 本身記錄過 join / submit safety-check failure。它不是保證 native host 永不封鎖的範例；本次 bearer-trigger 診斷仍是未證實假說。
4. Ultra browser content.js 實際 wake payload 帶 worker token，且 task 已 claimed；README 描述醒來再 claim。實作與文件需逐一路徑核對，不把 donor 宣稱為全面 secret-free。
5. 部分 Ultra READ_ONLY 工具實際有 state/claim mutation；其 restart claimed->queued 與 corrupt reset 也不符合我們的 fail-closed。這些行為禁止照抄，更不能為了通過安全檢查假標 read-only。

補上 U0：Native peer admission / observability

U0 owner = #108。提供 readonly peer 自查／Main roster，nonsecret request -> exact owner approval -> readback，保留 OAuth + trusted peer context + owner authority。這是減少跨聊天秘密搬運與補充可觀測性，不是承諾消除平台封鎖。不能冒充 OpenAI 支援認證。

Delivery mode 必須顯式

• MANUAL_TURN_DRIVEN：現有 test(chat-swarm): run isolated 2-worker ChatGPT live canary #49 第一條原生 baseline；Worker 由真實使用者回合觸發 next。task:null 不代表已 parked 或會自己醒來。
• MCP_LONG_WAIT：只有目前 Host 確實支援且 native 測過 bounded wait、取消、斷線與 readback 才能聲稱。in-flight tool wait 不等於可啟動已結束的 ChatGPT turn。
• CARRIER_EVENT_WAKE：P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 中明確配置、授權及驗證的 carrier 可接 backend event 並啟動一個 exact target turn。無 carrier support 就回 unavailable，不忙迴圈、不默默改用別條路。

同一任務的 evidence 必須標明 mode；native、browser、SDK 的結果不能相互冒名。

V2 工作拆分與依賴

#46–#48 CLOSED source lineage（保留）
      |
      v
#108 Native admission + diagnostics
      |
      v
#49 Main + 2 real ChatGPT peers / 20 bounded attempts
      |
      +--> #51-A deterministic worker epoch / continuation
      |
      +--> #105-A carrier feasibility + bounded lifecycle/wait/wake
                |
                +-- optional #50 admitted OpenCLI adapter
                |
#51-A + proven #105 carrier boundary
      |
      v
#51-B proactive Worker Auto Compact（U4 必做）

#106 Main checkpoint/pressure design可獨立研究
      +--> real Main carrier可用性 + canonical authority/lease rebind
      +--> planned rollover live witness
      +--> #101 crash-fallback regression

全部所需 live receipts -> #104 parity closure

#105 的 recovery 採 #51-A epoch/rebind；#51-B 的自動 rollover 可使用 #105 已驗證 carrier。不得寫成 #105 等整個 #51 完成、整個 #51 又等 #105 的循環。#49 不等 #105 自動造視窗；先保留 manual native baseline。

統一原則

• 一個 Swarm canonical store/coordinator，carrier 只處理 transport/lifecycle，無第二個 queue、Planner、admission 或 completion authority。
• metadata fingerprint 是 identity correlation，非 OpenAI 簽章；無可信 peer context 則 fail closed，不允許 caller 自填 fingerprint 取得角色。
• CLAIMED、DELIVERED、EXECUTION_STARTED、RESULT_READY、COLLECTED 分別觀測；不從 worker 存在或 BUSY 推導已執行。
• secret 不進聊天任務/capsule/GitHub；能力不可用就明示，禁止 cookie/session cloning、私有 API 偽裝、challenge/rate/quota 或 host safety 繞過。
• context estimate 不當 exact token telemetry；不要把 Ultra 的配置預算當我們模型的真實 context limit。
• P0: Crash-safe ChatGPT session continuation after context rollover #101 source merge只證明其有界交付，不自動證明本工程目標的 Main Goal/Plan/Swarm authority 已全部接線。
• source / accepted / installed / loaded / schema / native evidence 各自綁定。新工具上線需按 Host 正常 action review/refresh 流程；不能靠 cached schema 技巧略過審查。

下一個實作入口

交給 implementer 的第一張 Issue 是 #108；先做 G0 evidence rebind，再作 source contract/測試，交獨立驗收。本次只更新規劃，不啟動實作、部署、重啟或新的 Swarm。

[James3014]

Owner parity amendment — Single-Main / zero-touch worker operation is the canonical UX

Fresh Ultra re-read changed the acceptance interpretation materially.

Ultra's productized worker pool is not merely Main + several manually prepared chats. Its normal operator contract is on-demand:

Main
-> runtime_ensure(desiredWorkers)
-> missing worker runtimes/conversations are created or restored
-> exact conversation mappings are persisted
-> workers autojoin/park
-> dispatch wakes exact workers
-> recover/scale occurs without user operating worker windows

The Main conversation is the normal operator surface. Worker windows may physically exist, but the user does not manage them.

Previous planning error to prevent

#49-style manual peer setup proved useful backend/identity semantics, but it accidentally became the operational model during testing. That must not become the product architecture.

The following is now explicitly non-acceptance for U2/U3/U4/U5 parity:

• Owner pre-opens worker chats;
• Owner labels/identifies A/B manually;
• Owner reconnects/selects dev-c in each worker during normal operation;
• Owner copies join/bootstrap instructions;
• Owner moves swarmId/workerId/taskId/result between conversations;
• Owner manually wakes workers after Main dispatch;
• Owner manually creates replacement worker conversations for rollover.

Canonical product interaction budget

After one-time setup/login/consent:

Owner initial Main request            1
manual worker window creation         0
manual worker app/dev-c selection     0
manual worker admission/join          0
manual worker wake                    0
manual worker ID/task/result relay    0
manual worker rollover                0

Revised child ordering

1. P0: implement macOS zero-touch ChatGPT worker runtime pool #117 / P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 P0 — zero-touch macOS worker runtime pool: real carrier creation, managed admission, ensure/wake/recover/scale.
2. feat(chat-swarm): add durable worker continuity and conversation rollover #51 — worker carrier replacement / continuation / Auto Compact using the runtime pool; replacement conversation must be system-created, not user-created.
3. feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover #106 — proactive Main carrier rollover, reusing the same carrier-creation/control substrate where appropriate.
4. Epic: reconcile DevSpace Ultra parity for GPT peer swarm and conversation continuity #104 final parity witness — one Main instruction causes dynamic N-worker execution with zero worker-window interaction.

#49 remains baseline/manual peer correctness evidence and may retain historical unfinished control-plane scenarios. It does not define the final UX.

New final parity witness

At least one real macOS acceptance must begin with only the user-facing Main available and then prove:

James: 'Use 3 workers for this task.'
-> system ensures/creates 3 workers
-> workers auto-bind/park
-> Main dispatches in parallel
-> exact workers wake/execute/submit
-> Main collects/reviews
-> one worker carrier is lost and automatically recovered
-> one worker rolls conversation generation without James intervention
-> scale to a different worker count

No manual worker conversation interaction is permitted in the witness.

The strongest parity claim remains unavailable until #117 + #51 + #106 and the final zero-touch witness pass on exact source/build/runtime evidence.

[James3014]

2026-09-13 U4 source progress — Auto Compact planner accepted

Worker-side parity mapping advanced without overstating live capability:

• feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A) #120 / PR feat(chat-swarm): deterministic worker continuation epoch transfer (#120) #122: deterministic worker continuation/rebind source accepted;
• feat(chat-swarm): add transport-neutral Worker Auto Compact planner (#51-B/C source) #126 / PR feat(chat-swarm): add worker Auto Compact planner (#126) #127: transport-neutral Worker Auto Compact planner source accepted;
• current main: 07f5c30a6ec8fcb9bfb511cb2b76ae089d6f6244.

#126 adds explicit pressure provenance, compactRequired/safe-boundary/reconciliation decisions, bounded verified capsule and non-authorizing replacement-carrier intent. It does not create a carrier or prove a live pressure-triggered rollover.

U4 therefore remains OPEN at the physical/product layer. Closure still requires #117/#105 real zero-touch carrier creation/recovery plus #120 rebind to prove a real Worker A -> B rollover, same workerId, epoch increment, stale-carrier fence and zero duplicate execution. No #104 closure claim is made.

[James3014]

Ultra parity update: #117 G1 macOS zero-touch worker-runtime source has been integrated into main via PR #131.

• exact PR head: bb06b4df469b8c6d6c47ed894b3d0e97257a137a
• accepted main merge: da4be27769c72e42ec24882145d8a84a804a4999
• exact-head CI refactor(review): compose presentation profiles Waishnav/devspace#234 / 34757239223: macOS Smoke PASS, Ubuntu Smoke PASS, focused macOS continuation + Local Agent PASS; Windows only shows the known 7-test carrier-binding baseline.

This advances U2 source capability and consumes the #51/#120 continuation seam, but does not prove end-to-end Ultra parity or live zero-touch worker lifecycle. #117 remains open for native G0/G2-G6 with manualWorkerInteractionCount=0.

Current exact native blocker: NATIVE_MACOS_CHATGPT_BROWSER_CARRIER_WITNESS_REQUIRED.

[James3014]

Ultra parity matrix update — U2 source integrated, live evidence unchanged

#117 G1 source is now merged via clean PR #131 / main da4be27769c72e42ec24882145d8a84a804a4999.

U2 source now includes the managed macOS web carrier runtime, zero-touch provisioning/bootstrap contract, runtime status/ensure/scale/recover/stop/bootstrap tools, durable wake/reconciliation, safe scale-down, exact saved-conversation recovery and per-boot physical carrier revalidation.

This does not check any #104 live closure box by itself. Remaining U2 evidence is #117 G0 + G2-G6 on the exact installed Mac/ChatGPT/dev-c runtime with post-setup manual worker interaction count = 0. Canonical native manifest: #117 comment 5653475229.

Downstream after that witness:

1. feat(chat-swarm): add durable worker continuity and conversation rollover #51 physical worker A→B rollover + live Auto Compact using P0: implement macOS zero-touch ChatGPT worker runtime pool #117 carrier creation and feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A) #120 epoch transfer;
2. feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover #106 proactive Main rollover;
3. final Epic: reconcile DevSpace Ultra parity for GPT peer swarm and conversation continuity #104 closure matrix.

Current epic claim remains exactly: ULTRA_PARITY_TARGET_RECONCILED — END_TO_END_PARITY_NOT_YET_PROVEN.