Repository navigation
feat(chat-swarm): add durable worker continuity and conversation rollover #51
Description
Activity
James3014 commented
on Sep 9, 2026 OwnerAuthorMore actions2026-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之後)
- Stable worker / replaceable carrier:在現有Swarm state增加必要的continuation狀態,保留same workerId、exact task/attempt、checkpoint與previous/current epoch。未知effect不能被rollover清成queued。
- 一次性有界交接:依原issue的ticket設計,hash-only、短效、exact swarm+worker+next epoch、原子consume;wrong/expired/replayed ticket拒絕。新carrier綁定後舊carrier不得繼續submit;dual-active ambiguity先reconcile。
- Capsule僅引用可信證據:role/scope、current task與attempt、verified checkpoint、unresolved blockers、artifact refs、schema/checksum、claim ceiling。Model summary只是上下文,不可改canonical state;缺少receipt或stalecheckpoint時fail closed,不靠完整聊天複製填補。
- 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確認。
James3014 commented
on Sep 11, 2026 OwnerAuthorMore actions2026-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 != conversationIdand 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:
- deterministic worker continuation/rebind;
- one-time/expiring continuation ticket;
- old carrier rejected after successful rebind;
- active/unknown task effect remains reconciliation-only;
- 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.
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;Ultra2c61c79ffe269d31523bac37ae6ecd60c9065a5e的 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完成。
James3014 commented
on Sep 12, 2026 OwnerAuthorMore actionsOwner continuity amendment — rollover must be runtime-managed, not user-created
The existing core invariant remains correct:
workerId != conversationIdBut 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 carrierOwner 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 adapterAcceptance 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.
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions2026-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.
- reuse existing
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions2026-09-13 #51-A source Candidate ready via #120 / PR #122
Deterministic continuation source slice (#51-A) has reached
DETERMINISTIC_WORKER_CONTINUATION_SOURCE_CANDIDATE_READYon PR #122 exact head503c900c1d3413207e1db7a9b0a98981c94b0281.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:
- feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A) #120/feat(chat-swarm): add durable worker continuity and conversation rollover #51 owns logical worker identity, continuation epoch, checkpoint, stale-carrier fencing and fail-closed task truth;
- P0: implement macOS zero-touch ChatGPT worker runtime pool #117/P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 owns automatic creation/open/recovery of the replacement ChatGPT carrier.
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.
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions2026-09-13 #51-A source candidate ready via #120 / PR #122
Child #120 has reached source-candidate-ready at exact head
a168bb39ea55a868f40c15e85f91fb1a59c0d8ceagainstmain@c6e09967cb745407de3a7d09808c472d38f6e612.Controller verification is complete: focused continuation macOS tests, full macOS Smoke, Ubuntu Smoke, Local Agent Sessions, and PR
git diff --checkpass. 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.
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions2026-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 claimDETERMINISTIC_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.
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions2026-09-13 Worker Auto Compact planner source accepted via #126 / PR #127
PR #127 merged as
main@07f5c30a6ec8fcb9bfb511cb2b76ae089d6f6244; child #126 is CLOSED / completed with claimWORKER_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 intentImportant boundary:
- feat(chat-swarm): add transport-neutral Worker Auto Compact planner (#51-B/C source) #126 does not create/open a ChatGPT conversation and does not transfer worker authority;
- P0: implement macOS zero-touch ChatGPT worker runtime pool #117/P0: macOS elastic ChatGPT worker runtime lifecycle (zero-touch ensure/wake/recover/scale) #105 must consume the replacement intent, create/recover the real carrier with zero manual worker interaction, then invoke the feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A) #120 continuation/rebind seam;
- a real A->B worker rollover still must prove same workerId, epoch +1 exactly once, old carrier fenced, targeted follow-up reaches B, no duplicate execution;
- live pressure-triggered Auto Compact remains unproven until that physical path runs.
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.
James3014 commented
on Sep 13, 2026 OwnerAuthorMore actions#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:
- create replacement managed carrier B through P0: implement macOS zero-touch ChatGPT worker runtime pool #117;
- same logical workerId, continuationEpoch +1 through feat(chat-swarm): deterministic worker continuation epoch transfer (#51-A) #120;
- old carrier A fenced;
- targeted follow-up reaches B;
- zero duplicate task execution;
- Auto Compact pressure path drives the same physical replacement without copying full transcript/reasoning/credentials.
This live witness depends on #117 G0/G2-G6 native acceptance; source merge alone is not
DURABLE_WORKER_CONTINUITY_CANARY_PASS.James3014 commented
on Sep 27, 2026 OwnerAuthorMore actionsWave 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_PASSwithout 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 invariantworkerId != conversationIdand 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:
- Issue prior
updated_at=2026-09-20T07:12:07Z - DevSpace main
3b92d6165e8531765dbaf929c3c298e0b03505bb - P1: pilot Chat On Steroids as ChatGPT peer-worker runtime #218 is now closed as completed CoS pilot
- Nexus-new Wave 4 Candidate: PR #1158 @
ba3036020c7d87c90f7cf1c4cfa84fa613b13ce2
AUTO_CHAIN=false.
Owner scope amendment — macOS only (2026-09-11)
依 Owner 最新裁決,本工作線相關功能設計、實作、交付與驗收 只處理 macOS。本裁決取代下文較早的跨平台/三平台要求。
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 != conversationIdA worker is durable logical execution identity. A ChatGPT conversation is a replaceable carrier.
Expected model:
Objective
Implement explicit, auditable continuation/rollover semantics with one-time binding material and fail-closed recovery.
Required behavior
Worker continuity state
Represent at least:
Continuation ticket
If a ticket/token is used to bind a replacement conversation:
Rollover safety
carrier_lost,continuation_pending,continuation_bound, andreconcile_required.Context/checkpoint capsule
Define a bounded continuation capsule sufficient to resume worker role without copying full conversation history.
Expected contents may include:
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:
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:
Do not copy:
Required tests
Live acceptance
After deterministic tests, run a bounded worker rollover witness:
Non-goals
Claim ceiling
DURABLE_WORKER_CONTINUITY_CANARY_PASSonly after exact source + live rollover evidence passes.Do not claim infinite context, exact token awareness, production autoscaling, or autonomous coding readiness.