Skip to content

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

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

Description

@James3014
James3014
opened on Sep 11, 2026

OWNER CONTRACT DELTA — EXTERNAL WORKER RUNTIME EVALUATION FIRST (2026-09-20)
This Epic remains the product/architecture reconciliation home, but it no longer authorizes DevSpace to implement Ultra-style ChatGPT worker/browser parity by default. #218 now owns the bounded Chat On Steroids pilot. Do not auto-chain #49/#50/#51/#105/#117 while #218 is unresolved. After #218, reconcile which capabilities are KEEP / RETIRE / SUPERSEDE / STILL-GAP. #106 remains a separate Main-controller continuity question and must not be assumed replaced.

Current external-runtime gates: #217 Codeg execution plane, #218 CoS ChatGPT worker runtime.

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.

Activity

  1. James3014 commented on Sep 11, 2026

    @James3014
    James3014
    on Sep 11, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    Child mapping created

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

    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.

  2. James3014 commented on Sep 11, 2026

    @James3014
    James3014
    on Sep 11, 2026
    OwnerAuthor

    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 必須顯式

    同一任務的 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。

  3. James3014 commented on Sep 12, 2026

    @James3014
    James3014
    on Sep 12, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  4. James3014 commented on Sep 13, 2026

    @James3014
    James3014
    on Sep 13, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

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

    Worker-side parity mapping advanced without overstating live capability:

    #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.

  5. James3014 commented on Sep 13, 2026

    @James3014
    James3014
    on Sep 13, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

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

    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.

  6. James3014 commented on Sep 13, 2026

    @James3014
    James3014
    on Sep 13, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    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.

  7. James3014 commented on Sep 27, 2026

    @James3014
    James3014
    on Sep 27, 2026 – with ChatGPT Codex Connector
    OwnerAuthor

    Wave 4 architecture reconciliation — external worker runtime decision complete

    Closure classification: DONE_NO_FOLLOW_UP for this Epic's current reconciliation contract.

    The Epic's 2026-09-20 Owner delta explicitly required a post-#218 KEEP / RETIRE / SUPERSEDE / STILL-GAP decision. That decision is now durable:

    Capability family Wave 4 disposition Current durable home
    U1 GPT peer swarm / worker browser runtime SUPERSEDED for DevSpace custom implementation Chat On Steroids under Nexus-new #1154
    custom Dev MCP live swarm canary (#49) RETIRE historical evidence only
    OpenCLI ChatGPT runtime adapter (#50) RETIRE optional diagnostic/compatibility evidence only
    U3 DevSpace worker continuity (#51) SUPERSEDED implementation; KEEP portable invariant CoS lifecycle now; workerId != conversationId retained as design principle
    U2 macOS elastic worker carrier lifecycle (#105) SUPERSEDED CoS supported worker lifecycle
    zero-touch Chrome/CDP worker pool (#117) RETIRE historical macOS/CDP evidence only
    U4 proactive worker context/rollover RESIDUAL_GAP, non-blocking optional future CoS/external-controller work; not current direct-control acceptance
    U5 proactive Main conversation continuity KEEP #106 remains separate and open
    supported external Nexus -> CoS controller RESIDUAL_GAP, optional upstream totec448-spec/chat-on-steroids#82 or equivalent supported/authenticated API

    Evidence boundary:

    • Nexus-new #1154 records CHATGPT_DIRECT_CONTROL_PLANE_CANARY_PASS.
    • CoS workers have proven real parallel execution, targeted follow-up, and sleep/wake/reuse inside an owning Prime family.
    • Desktop Commander + CoS + Main ChatGPT completed one real bounded Nexus repository task without Dev MCP.
    • Cross-client Prime-family migration remains unproven.
    • No private external CoS controller is authorized.
    • DevSpace remains an optional compatibility transport for explicitly selected work; it is not a required direct-control transport.

    Affected child Issues #49/#50/#51/#105/#117 are now closed as superseded/retired without rewriting their historical evidence.

    #106 is deliberately not closed by this Epic reconciliation. CoS worker-runtime adoption neither proves nor invalidates proactive Main-controller continuity.

    Causal watermark:

    This closes the reconciliation Epic, not every optional future continuity feature.

    AUTO_CHAIN=false.

  8. James3014
    closed this as completedon Sep 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions