Skip to content

feat(chat-swarm): add durable worker continuity and conversation rollover #51

Description

@James3014

OWNER HOLD — CoS PILOT FIRST (2026-09-20)
Do not implement or extend DevSpace-owned ChatGPT worker continuity/rollover from this Issue until #218 establishes which worker-runtime responsibilities remain in DevSpace. Preserve the logical-worker-vs-conversation invariant as portable design evidence. No auto-chain.

Textual prerequisite: #218.

Owner scope amendment — macOS only (2026-09-11)

依 Owner 最新裁決,本工作線相關功能設計、實作、交付與驗收 只處理 macOS。本裁決取代下文較早的跨平台/三平台要求。

  • Windows、Linux 支援、移植、修復與平台驗證不在本次工作範圍;不再以三平台全綠作為本工作線的 acceptance criterion。
  • 驗收保留 macOS 上必要的 source tests、獨立 package/install、真實呼叫入口、operation/副作用/讀回及適用的恢復與終態證據;ownership、lease、CAS、安全與獨立審查要求保持有效。
  • 下方歷史測試、PR、平台結果與問題紀錄保留作為歷史證據,不代表目前仍有跨平台交付承諾。後續設計及驗收計畫以此 macOS-only 範圍為準。
  • 本次更新僅修正 Issue 與規劃範圍;實作、部署與重啟仍依 Owner 的暫停指令保持暫停。
  • 此文字更新不會自行修改 GitHub CI 設定或 branch protection;既有檢查設定如與新範圍不符,須另行明確調整,不得假稱已通過或繞過保護。

Status

BLOCKED_BY #49

Purpose

Add durable logical worker continuity so a ChatGPT Swarm worker can survive ordinary conversation replacement/context rollover without changing worker identity or losing task/reconciliation lineage.

This is the continuity layer after the basic MCP peer Swarm has passed live canary. It is not required for V0.1.

Hard prerequisite

OpenCLI #50 is optional and not a hard prerequisite. Continuity must be defined at the Swarm/Core level so multiple runtime carriers can use it.

Core principle

workerId != conversationId

A worker is durable logical execution identity. A ChatGPT conversation is a replaceable carrier.

Expected model:

worker-01
  continuationEpoch: 4
  currentCarrier: conversation-B

history:
  epoch 3 -> conversation-A -> closed/rolled over
  epoch 4 -> conversation-B -> active

Objective

Implement explicit, auditable continuation/rollover semantics with one-time binding material and fail-closed recovery.

Required behavior

Worker continuity state

Represent at least:

  • stable worker ID
  • current continuation epoch
  • current carrier identity fingerprint
  • prior carrier/epoch lineage sufficient for audit/reconciliation
  • last acknowledged checkpoint
  • current task binding
  • rollover/continuation state

Continuation ticket

If a ticket/token is used to bind a replacement conversation:

  • short-lived
  • single-use
  • scoped to one exact worker + swarm + next epoch
  • stored as hash only
  • invalid after successful consumption
  • cannot be replayed by the old carrier
  • cannot bind a different worker
  • must not upgrade task/controller authority

Rollover safety

  • do not roll over while an effect is ambiguous without a checkpoint/reconciliation rule;
  • if a worker has an active task, continuation must preserve exact task/attempt identity;
  • if old and new carriers both appear active, fail closed until ownership is resolved;
  • loss of old conversation must not silently mark task complete/failed/retryable;
  • controller must be able to distinguish carrier_lost, continuation_pending, continuation_bound, and reconcile_required.

Context/checkpoint capsule

Define a bounded continuation capsule sufficient to resume worker role without copying full conversation history.

Expected contents may include:

  • worker/swarm identity
  • continuation epoch
  • current/last task IDs
  • stable worker role instructions
  • bounded task/result summaries
  • unresolved unknowns/blockers
  • explicit authority/claim ceiling
  • checksum/schema version

Do not treat model-generated narrative as authoritative task state; canonical state remains in Swarm storage.

Context pressure

Do not claim exact ChatGPT token telemetry unless a supported host/runtime signal exists.

If context pressure is estimated:

  • label it estimated
  • use conservative thresholds
  • keep estimate separate from hard model context facts
  • rollover decision must remain observable

Automatic context compaction/rollover may be added only after deterministic continuity semantics work without it.

Ultra reference boundary

The Ultra project may be used as a reference for:

  • stable worker identity across conversation replacement
  • continuation epochs/tickets
  • checkpoint capsule concept
  • idle-boundary rollover

Do not copy:

  • assumptions tied to Windows AppX cloned runtimes
  • session/cookie seeding
  • context estimates presented as exact native token telemetry
  • automatic authority transfer from browser/session state

Required tests

  • one-time continuation ticket success
  • ticket replay rejected
  • wrong-worker ticket rejected
  • expired ticket rejected
  • old carrier cannot submit after new carrier binding
  • ambiguous dual-carrier state fails closed
  • active task/attempt identity survives rollover
  • restart during continuation does not duplicate worker or task execution
  • checkpoint capsule corruption/version mismatch fails closed
  • controller sees stable worker ID before/after carrier replacement

Live acceptance

After deterministic tests, run a bounded worker rollover witness:

  1. worker joins and completes at least one task;
  2. worker starts/holds a second bounded task or checkpoint;
  3. create replacement ChatGPT conversation;
  4. bind it through the continuation protocol;
  5. prove stable worker ID and incremented epoch;
  6. prove targeted follow-up routes to replacement carrier;
  7. prove old carrier can no longer submit as the worker;
  8. prove no duplicate task execution occurred.

Non-goals

  • automatic browser spawning
  • OpenCLI requirement
  • unlimited persistent conversations
  • mutation grants
  • coding-agent delegation policy
  • automatic model selection
  • account/quota bypass

Claim ceiling

DURABLE_WORKER_CONTINUITY_CANARY_PASS only after exact source + live rollover evidence passes.

Do not claim infinite context, exact token awareness, production autoscaling, or autonomous coding readiness.

Activity

  1. James3014 commented on Sep 9, 2026

    @James3014
    OwnerAuthor

    2026-09-09 Continuity 重規劃:區分 run context、cache replay 與 worker 身分延續

    Owner 完整目標仍要求本 issue 的實作與真實 rollover;不是只產出規格。本 issue 仍在 #49 原生兩conversation canary 通過後才進入實作,#50維持 optional,不把瀏覽器自動化列成必要前置。

    ODW 來源與可借鏡範圍

    固定 travisliu/open-dynamic-workflow@164b313a75f1e05b0e294a2085b6e44721959762:

    • CHANGELOG 的 run-scoped context 是同一 workflow run 的 JSON-safe 共享狀態。
    • Ultra Loop README 明確區分 Ultra Loop durable goal/evidence resume 與 odw resume 的 cached-call reuse。
    • 兩者都不能證明 DevSpace 的 ChatGPT carrier 置換、跨對話認證或 exactly-once effect。 不因分支名 memory-issues 就把它當跨ChatGPT conversation memory實作。

    借鏡的是小而完整、版本化、可重建的checkpoint;實際worker/epoch/attempt/權限真相仍來自已接受的Swarm store与現有identity contract。沒有獨立memory authority或新的模型路由。

    Implementation slices(#49之後)

    1. Stable worker / replaceable carrier:在現有Swarm state增加必要的continuation狀態,保留same workerId、exact task/attempt、checkpoint與previous/current epoch。未知effect不能被rollover清成queued。
    2. 一次性有界交接:依原issue的ticket設計,hash-only、短效、exact swarm+worker+next epoch、原子consume;wrong/expired/replayed ticket拒絕。新carrier綁定後舊carrier不得繼續submit;dual-active ambiguity先reconcile。
    3. Capsule僅引用可信證據:role/scope、current task與attempt、verified checkpoint、unresolved blockers、artifact refs、schema/checksum、claim ceiling。Model summary只是上下文,不可改canonical state;缺少receipt或stalecheckpoint時fail closed,不靠完整聊天複製填補。
    4. Native physical rollover:Luna完成bounded source、主控獨立驗收後,依正式CI/整合/受控runtime更新,再用真正舊/新ChatGPT conversations完成本issue既有8步見證。需證明replacement targeted follow-up成功、epoch提升、oldcarrier拒絕與零重複effect。

    保留的硬條件

    • OAuth clientId不是conversation,MCP sessionId不是worker;使用現行authenticated host + optional host metadata assertion,不擅增上游簽章服務或改成新permission model。
    • 不声稱精確ChatGPT token/context剩餘量,除非有受支援的實測訊號;估計必须標示為估計。
    • 本機polling取消、browser消失或cache miss不代表遠端generation已停止/未發生。
    • 不把domain單測、capsule檔案、PR合併、ODW cached結果或另一模型session當本issue的真實rollover驗收。
    • #62的coordinator/resource handoff與本issue的worker/carrier rollover分別有owner;僅重用已驗收的共用機制,不能把任一者PASS推論為另一者完成。

    本次只追加來源研究與切片計畫,未開始continuity實作或執行rollover。本issue保持open,最大結果仍須依原contract以exact source+native evidence確認。

  2. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    2026-09-11 scope amendment — Ultra parity requires proactive worker Auto Compact after deterministic rollover

    Canonical parity tracker: #104.

    Fresh Ultra comparison confirms this Issue correctly owns the core invariant:

    workerId != conversationId
    

    and the continuation ticket / epoch / checkpoint / stale-carrier fencing semantics remain the correct first gate.

    However, the original wording leaves automatic compaction/rollover as an indefinite future enhancement. For the previously requested Ultra-style behavior, that is now too weak.

    Updated scope interpretation

    Keep the existing sequence:

    1. deterministic worker continuation/rebind;
    2. one-time/expiring continuation ticket;
    3. old carrier rejected after successful rebind;
    4. active/unknown task effect remains reconciliation-only;
    5. bounded checkpoint capsule.

    Then add a required second gate for Ultra parity:

    conservative context pressure
    -> compactRequired / rollover prepared
    -> wait for safe idle boundary
    -> bounded capsule
    -> fresh carrier via the admitted runtime adapter
    -> bind same workerId at next epoch
    -> resume `chat_swarm_next`
    

    Pressure semantics

    • Do not claim exact ChatGPT token telemetry unless the host/carrier actually exposes it.
    • Estimated pressure must be labeled estimated with provenance.
    • Conservative pressure may trigger preparation early.
    • Pressure never authorizes rollover while a consequential task/effect is ambiguous.

    Capsule rules

    Preserve only bounded material state such as:

    • worker/swarm identity;
    • continuation epoch;
    • current/last task IDs;
    • stable role instructions;
    • task/result summaries;
    • current state/test/blocker/next-step summary;
    • explicit authority/claim ceiling;
    • schema/hash.

    Do not carry full transcripts, hidden reasoning, raw tool history, credentials, or stale transport state.

    Live parity witness required

    After deterministic continuation passes, temporarily lower a test pressure threshold and prove a real worker conversation A -> B rollover:

    • same workerId;
    • incremented continuation epoch;
    • no duplicate task execution;
    • targeted follow-up reaches B;
    • A can no longer submit as the worker;
    • production threshold/config restored afterward.

    #105 owns worker carrier lifecycle/creation/recovery. This Issue owns worker logical continuity and proactive rollover semantics.

  3. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    V2 continuity contract:兩階段交付、受信 admission、不要把 token 或 context estimate 當權威

    Parent #104。初始 native admission / diagnostics由 #108 負責;carrier wait/wake由 #105 負責。沿用現有 Swarm SQLite、workerId、continuationEpoch、task/attempt與reconciliation,不建立新queue/authority。

    研究來源:DevSpace 8da19eb34e2fcdd9cf36faf2064911d5cbed7020;Ultra 2c61c79ffe269d31523bac37ae6ecd60c9065a5e 的 dist/chat-swarm.js / dist/conversation-continuity.js / docs/conversation-continuity.md。

    A — deterministic continuation,#49 後的第一個獨立交付

    workerId != conversationId 保持不變。replacement必須綁 exact swarm、worker、sourceEpoch、targetEpoch、sourceCarrier、targetCarrier、task/attempt/checkpoint hash 與 expiry/version。

    沿用 #108 的 nonsecret request -> exact owner approval -> requester readback 模式;replacement與initial join不同,不消耗新slot,不以新worker假裝原worker復活。

    • 新carrier身分來自authenticated trusted request context;不允許模型自填fingerprint或僅憑label/requestId接管。
    • 只有明確授權的continuation operation能把epoch從N推進到N+1;並行兩個target只能一個成功。
    • 原carrier在prepared/尚未transfer前仍是current;不能因新conversation建立成功就提前失效。
    • 新carrier完成必要capsule hash/schema/worker/task確認後,以單一transaction/CAS切换binding、消耗pending approval、記錄receipt;舊epoch後續next/submit拒絕。
    • lost acknowledgement用receipt/readback找回同一結果;不創建第二replacement。
    • target creation/transfer結果UNKNOWN保持RECONCILE_REQUIRED。只有證明transfer未發生,才能安全保留/恢復舊owner,不能一律rollback自稱無副作用。
    • active task的identity不能換;outcome unknown禁止重新執行。最低版本可只在task terminal/明確safe checkpoint邊界rollover,其他情況blocked。
    • continuation capsule是bounded reference+摘要;canonical task state必須fresh read。沒有full transcript、raw tool dumps、hidden reasoning、credentials。

    Ultra的SESSION_BOUND_CONTINUATION只是已綁定session的舊schema sentinel,不是通用無憑證admission。不要把它拷貝來繞過權限。若某個已批准adapter確需一次性ticket,ticket只屬該明確信任邊界、短效單次hash存儲,不暗中重啟目前被Host封鎖的secret傳遞路徑。

    B — proactive Worker Auto Compact,Ultra parity 必做後續

    A可以獨立交付與驗收,不能因本Issue還有B就阻塞 #105 的epoch-based recovery;B需要 #105 已證明可用的carrier safe-boundary/replace能力。這避免 #51 <-> #105 循環。

    採用 donor 的行為原則而非Windows/CDP細節:

    estimated pressure高 -> compactRequired
    -> 等task安全邊界且turn未generating
    -> bounded capsule
    -> prepare replacement
    -> target validation + approved epoch bind
    -> reset per-epoch ledger
    -> 同workerId繼續
    

    context pressure可使用單調backend ledger與可用的bounded DOM/host signal;重複task/replay不可重複計入,UI virtualization不能讓已觀測context倒退。source/provenance、估值/exact、coverage unknown與reserve必須分开。

    不要硬編碼 Ultra 的1,050,000 token budget作為目前ChatGPT模型真實上限。budget/threshold為explicit configuration,unknown native signal保持unknown。只有估值時不提供假exact get_context_remaining。

    重要限制:等待safe boundary可能晚於真正context上限;持續checkpoint與 #101/#106 對應恢復路徑仍需要存在,不能保證永不滿。

    必做新增測試

    pending/approval重播與撤銷、錯worker/錯swarm/錯epoch、並行replacement、commit前後crash/readback、舊carrier fence、active unknown不重派、capsule hash/version/size/redaction、transport generation仍在執行時不rollover、ledger replay去重與UI縮減不降低壓力、unsupported carrier明確blocked。

    B的live gate可暫時降低測試threshold,但必須跨同一production watchdog/safe-boundary/binding流程並恢復原config;不能mock出continuation成功當作real rollover。

    A/B各自有exact source/build/manifest/native receipt。沒有A證據不解鎖epoch recovery;没有B live witness不宣稱Worker Auto Compact完成。

  4. James3014 commented on Sep 12, 2026

    @James3014
    OwnerAuthor

    Owner continuity amendment — rollover must be runtime-managed, not user-created

    The existing core invariant remains correct:

    workerId != conversationId
    

    But live acceptance must now use #117/#105's zero-touch runtime pool. A user manually opening a replacement Worker conversation and then supplying continuation material is diagnostic-only and cannot satisfy the product gate.

    Required normal rollover

    logical worker W / epoch N
    -> context pressure reaches configured safe threshold
    -> wait for safe boundary
    -> runtime manager creates/opens replacement ChatGPT carrier automatically
    -> bounded continuation capsule/ticket is redeemed
    -> epoch N+1 binds to the same workerId
    -> old carrier is fenced
    -> next targeted task routes to the replacement carrier
    

    Owner interaction with the worker UI after one-time setup must be zero.

    #117 integration

    #117 owns the macOS carrier creation/open/recover substrate. #51 owns the continuity truth and epoch transfer.

    Do not implement a second browser/session launcher in #51. Instead expose a transport-neutral continuation contract that #117 can call.

    The runtime must preserve the separation:

    logical worker identity / task truth     #51 + Swarm
    carrier creation / navigation / wake     #117/#105 adapter
    

    Acceptance correction

    The historical live step 'create replacement ChatGPT conversation' is amended to mean DevSpace runtime manager creates it.

    Manual replacement conversation creation or manual worker rejoin does not count toward DURABLE_WORKER_CONTINUITY_CANARY_PASS.

    Final live evidence must include:

    • manual replacement-worker creation = 0;
    • manual continuation-ticket transfer = 0;
    • same workerId before/after rollover;
    • continuationEpoch increments exactly once;
    • old carrier rejected/fenced;
    • active task/attempt truth preserved;
    • no duplicate execution;
    • runtime mapping updated to the new exact conversation carrier;
    • later runtime_ensure/recover uses the replacement carrier automatically.

    Auto Compact remains required for #104 parity; deterministic continuation semantics must remain transport-neutral and fail closed on ambiguous active effects.

  5. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    2026-09-13 #51-A implementation started as #120

    Deterministic continuation is now split into focused child #120: feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A).

    Fresh source fence: main@ab22dc9d0360bd02d00892734a5c51cdd0873f39.
    Implementation branch created: codex/issue-120-worker-continuation.

    Scope is intentionally transport-neutral and may proceed in parallel with #117:

    • reuse existing workerId, continuationEpoch, checkpoint, task/attempt and authenticated carrier identity;
    • exact sourceEpoch -> targetEpoch CAS;
    • authenticated target request + exact Owner approval;
    • atomic carrier binding transfer;
    • old carrier fencing through the existing worker identity check;
    • active/unknown effects fail closed;
    • durable readback for lost acknowledgement;
    • no browser/session launcher, no second queue/worker registry, no Auto Compact claim.

    #117/#105 remains the carrier creation/navigation/wake owner. #120 only establishes the deterministic continuity truth that #117 recovery will consume. Overall #51 remains OPEN until zero-touch real carrier rollover and later proactive Auto Compact acceptance.

  6. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    2026-09-13 #51-A source Candidate ready via #120 / PR #122

    Deterministic continuation source slice (#51-A) has reached DETERMINISTIC_WORKER_CONTINUATION_SOURCE_CANDIDATE_READY on PR #122 exact head 503c900c1d3413207e1db7a9b0a98981c94b0281.

    macOS exact-head source/CI acceptance is green; independent exact-head review remains required before merge, so #120 and #51 remain OPEN.

    Important boundary unchanged:

    Therefore a future #51 live PASS still requires zero-touch replacement via #117/#105 with manual replacement-worker creation = 0 and manual continuation transfer = 0. This source Candidate does not claim real ChatGPT rollover, Auto Compact or Ultra parity.

  7. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    2026-09-13 #51-A source candidate ready via #120 / PR #122

    Child #120 has reached source-candidate-ready at exact head a168bb39ea55a868f40c15e85f91fb1a59c0d8ce against main@c6e09967cb745407de3a7d09808c472d38f6e612.

    Controller verification is complete: focused continuation macOS tests, full macOS Smoke, Ubuntu Smoke, Local Agent Sessions, and PR git diff --check pass. Windows failure is the same current-main carrier-binding baseline and is not attributed to #120.

    PR #122 is Ready for review. Remaining #120 source gate is independent exact-head review and normal merge governance; no self-approval or merge claim is made.

    Parent #51 remains OPEN after #120. This child provides only transport-neutral deterministic worker continuation truth (epoch transfer, atomic carrier rebind, old-carrier fence, replay/reconciliation/corruption semantics). Real zero-touch ChatGPT conversation creation/replacement remains owned by #117/#105; proactive Auto Compact remains a later #51 phase.

  8. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    2026-09-13 #51-A accepted into main

    Owner waived the independent-reviewer gate for child #120. PR #122 merged normally as main@5256c40f56bbfd5a7eff7737ecf54da4b0359c4d; #120 is CLOSED / completed with claim DETERMINISTIC_WORKER_CONTINUATION_SOURCE_ACCEPTED.

    Parent #51 remains OPEN by design. The deterministic transport-neutral epoch transfer is now canonical source truth. Remaining parent acceptance is native/product work: #117/#105 must create/recover the replacement ChatGPT carrier with zero manual replacement-worker creation and zero manual continuation-ticket transfer, then #51 can prove real rollover and later Auto Compact behavior. Do not reopen or duplicate #120 logic in #117; consume the merged continuation seam.

  9. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    2026-09-13 Worker Auto Compact planner source accepted via #126 / PR #127

    PR #127 merged as main@07f5c30a6ec8fcb9bfb511cb2b76ae089d6f6244; child #126 is CLOSED / completed with claim WORKER_AUTO_COMPACT_PLANNER_SOURCE_ACCEPTED.

    Canonical source now provides the transport-neutral pre-rollover planner on top of the already-merged #120 continuation seam:

    pressure + provenance
    -> compactRequired
    -> safe-boundary/reconciliation/checkpoint gate
    -> bounded verified capsule
    -> NON_AUTHORIZING replacement-carrier intent
    

    Important boundary:

    Therefore #51 remains OPEN. Source prerequisites for the worker-side pressure/capsule/safe-boundary and deterministic rebind layers are now canonical; remaining #51 work is integration with #117 real carrier lifecycle plus live rollover/Auto Compact acceptance.

  10. James3014 commented on Sep 13, 2026

    @James3014
    OwnerAuthor

    #117 dependency update — replacement-carrier source now exists

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

    For #51 this removes the source-side carrier-lifecycle blocker: managed carrier creation/reopen/wake/recover and exact conversation mapping now exist alongside #120 deterministic epoch transfer and #126 Auto Compact planner/capsule.

    #51 still remains OPEN. Its remaining acceptance is physical A→B rollover on the exact installed macOS runtime:

    This live witness depends on #117 G0/G2-G6 native acceptance; source merge alone is not DURABLE_WORKER_CONTINUITY_CANARY_PASS.

  11. James3014 commented on Sep 27, 2026

    @James3014
    OwnerAuthor

    Wave 4 reconciliation — DevSpace worker continuity implementation superseded

    Classification: SUPERSEDED / RETIRED_FOR_CURRENT_DIRECT_CONTROL_PATH.

    Owner architecture decision now proven by Nexus-new #1154:

    • CoS is the current ChatGPT peer-worker/browser runtime for Main ChatGPT direct control.
    • Desktop Commander is the direct physical host/repository tool.
    • Main ChatGPT remains the sole mutation coordinator.
    • Wave 3 reached CHATGPT_DIRECT_CONTROL_PLANE_CANARY_PASS without Dev MCP.
    • DevSpace remains an optional compatibility transport when explicitly selected; it is not a required direct-control dependency.

    Decision:
    The DevSpace-owned worker continuity/rollover implementation is superseded for the current direct-control path by CoS-owned worker conversation lifecycle. Preserve the portable invariant workerId != conversationId and fail-closed ambiguous-effect semantics as design evidence.

    Residual boundary:
    Cross-client/cross-conversation Prime-family migration and supported external CoS control remain unproven optional future gaps; they are not silently claimed solved here.

    This close does not rewrite the Issue's historical implementation/evidence as wrong or completed. It records that this DevSpace-specific implementation line is no longer the selected current path.

    Causal watermark:

    AUTO_CHAIN=false.

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