feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover

[James3014]

Parent

Child of #104 (DevSpace Ultra parity reconciliation).

Priority

P1 — required to prevent Main controller loss before hard context exhaustion.

Closed #101 / PR #102 now provides crash-safe continuation after a Main ChatGPT controller is already lost or unusable. That is a fallback path.

Ultra v0.5 demonstrates a distinct proactive behavior: before a user-facing Main conversation reaches an unsafe context boundary, preserve a bounded Goal/Plan/frontier capsule and continue on a fresh backend conversation/carrier while keeping one logical work stream.

This Issue owns that proactive Main path for macOS DevSpace.

Goal

Support:

Main conversation A
  -> context/continuity pressure becomes unsafe soon
  -> prepare bounded authoritative checkpoint
  -> wait for safe transport boundary
  -> bind fresh Main carrier/conversation B
  -> preserve logical work identity + Goal/frontier
  -> fence stale carrier where authority transfer occurs
  -> continue next real user turn / authorized continuation

The normal path should happen before the user is forced to manually abandon a full conversation.

If proactive rollover fails or A dies abruptly, #101 remains the fallback:

new Session -> coordination_continuation_latest -> reconcile -> takeover

Core principle

logical engineering goal != ChatGPT conversation ID

Do not reconstruct continuity by copying the full transcript.

Ultra behavior to preserve conceptually

The Ultra Main path keeps bounded:

• Goal objective;
• current Plan/frontier;
• constraints;
• current/next execution frontier;
• compact progress/checkpoint state;
• sanitized conversation descriptor / continuity identity;
• enough state to make the next turn meaningful.

It explicitly excludes full raw mapping/transcript, raw tool history, hidden reasoning, credentials, and expired transport/session state.

DevSpace should adopt those principles while using current DevSpace authority/reconciliation semantics rather than Ultra's exact Windows/Classic implementation.

Relationship to #101

#101 is reactive crash takeover and is already merged.

This Issue is proactive rollover.

Required ordering:

proactive continuation possible
  -> use this Issue's path

proactive path impossible / carrier hard-fails
  -> #101 crash-safe recovery

Do not merge the two states; telemetry/receipts should say whether continuity was planned rollover or crash takeover.

Relationship to #51

#51 owns the same core principle for a Chat Swarm worker:

workerId != conversationId.

This Issue owns Main/controller continuity. Reuse common capsule/continuation primitives where safe, but do not make Main a Swarm worker merely to reuse code.

Required capability 1 — Main continuity record

Persist or project a bounded Main continuity object that references authoritative DevSpace state rather than duplicating it.

Equivalent fields:

continuityId
logicalGoalId / goalRef
authority/controller binding
repository/project identity when applicable
workspace/lease refs
base/current/Candidate revision refs
active agent/operation refs
objective
constraints[]
plan/frontier
checkpoint
verification/evidence refs[]
blockers[]
remainingGap
nextGate
sourceCarrier fingerprint
continuationEpoch
status
createdAt / updatedAt

The record must remain small and versioned.

Required capability 2 — pressure signal without false precision

Do not claim exact ChatGPT token usage unless a supported native signal exists.

Pressure may combine bounded conservative signals such as:

• host/native exact usage when actually available;
• DevSpace-observed task/prompt/result/context ledger;
• bounded UI/transport estimate if a supported adapter exposes one.

Rules:

estimate != exact token truth

• expose source/provenance of every signal;
• use conservative thresholds;
• prepare/checkpoint may happen early;
• pressure alone does not authorize carrier transfer;
• no fabricated get_context_remaining exactness.

Required capability 3 — bounded capsule

The carry-forward capsule must include only material continuity state.

Allowed categories:

• current goal/user intent;
• constraints;
• settled decisions needed for next action;
• exact repository/workspace/revision pointers;
• current Candidate/evidence/test summary refs;
• active/unresolved effects;
• blockers;
• remaining gap + next gate;
• bounded recent semantic summary when needed.

Forbidden:

• full transcript copy;
• hidden chain-of-thought/reasoning;
• raw tool arguments/output dumps unless separately stored as evidence refs;
• credentials/tokens/cookies;
• stale transport state;
• unbounded conversation history.

Required capability 4 — safe rollover boundary

A Main rollover may only cross at a safe boundary.

Examples:

• no consequential operation is ambiguity-pinned; or
• exact active effect is known and transferable/reconcilable under its existing contract;
• ownership/grant remains valid for the target carrier;
• target carrier identity can be verified sufficiently for the selected continuation mechanism.

If an active effect is unknown:

pressure high
+ outcome unknown
=> checkpoint/reconciliation only
!= new duplicate action

Required capability 5 — target validation before authority moves

Creating/opening a target conversation is not enough.

Before logical Main authority moves, validate applicable evidence:

• target carrier/session/conversation identity;
• capsule schema/version/hash;
• expected goal/continuity ID;
• expected source epoch;
• authority/lease/grant compatibility;
• no duplicate active-owner state;
• first target turn/carry marker observed where the adapter can prove it.

Failed/partial transfer leaves old authority current where still possible; otherwise falls back to #101's explicit recovery states.

Required tool/API surface

Exact names may vary, but provide bounded equivalents of:

continuity_main_status        # read-only
continuity_main_checkpoint    # prepare capsule/checkpoint only
continuity_main_prepare       # one target rollover attempt / ticket
continuity_main_bind          # bind verified fresh carrier
continuity_main_reconcile     # resolve partial/unknown rollover

If the ChatGPT host itself cannot expose enough carrier control to automate prepare/bind, still implement the durable checkpoint/continuity contract and expose the exact remaining host limitation. Do not claim automatic rollover without real carrier evidence.

Gate sequence

G0 — host/carrier capability matrix

Freshly determine what current ChatGPT + Dev MCP on macOS can actually observe/control for Main rollover:

• conversation/session identity metadata;
• ability to start/open a fresh carrier if any;
• ability to bind/correlate first target turn;
• whether OpenCLI/browser adapter is required;
• native context usage signals if any;
• what remains user-mediated.

G1 — durable Main checkpoint/capsule

Implement bounded versioned continuation state independent from one transport.

G2 — pressure estimation + safe-boundary state machine

Prove no false exact-token claim and no rollover during an unreconciled effect.

G3 — first real carrier binding

Use the smallest proven macOS carrier mechanism; keep transport separate from continuity truth.

G4 — proactive A -> B witness

Temporarily lower a configured test pressure threshold, drive the real production path, and prove:

• A prepares before hard failure;
• bounded capsule created;
• B binds to same logical goal;
• next user/authorized continuation can proceed;
• stale/old carrier cannot create conflicting ownership;
• no duplicate command/agent/task effect occurs.

Restore production threshold/config after the test.

G5 — crash fallback witness

Break the proactive path deliberately and prove #101 can still recover the latest authoritative checkpoint without transcript copy/paste.

Required hostile tests

• estimated pressure is labeled estimate;
• unavailable exact token signal stays unavailable;
• oversized capsule rejected/fails closed;
• empty goal/frontier cannot masquerade as valid continuation;
• capsule corruption/version mismatch rejected;
• old source epoch/ticket replay rejected;
• target-carrier mismatch rejected;
• dual-active carrier/owner ambiguity fails closed;
• unresolved active effect blocks duplicate-capable continuation;
• partial target creation does not silently move authority;
• Dev MCP restart preserves prepared/checkpoint state;
• exact replay is idempotent or returns existing continuation outcome;
• P0: Crash-safe ChatGPT session continuation after context rollover #101 latest/takeover fallback remains green.

Non-goals

• no infinite-context claim;
• no exact context-token claim without native evidence;
• no full transcript mirroring;
• no hidden reasoning transfer;
• no credential/cookie/session-secret copying;
• no automatic browser creation if the current platform/carrier cannot safely support it;
• no Nexus Planner/Workforce/Completion authority changes;
• no automatic task retry merely because the conversation changed.

Exact next gate

DEVSPACE_MAIN_CONTINUITY_G0_MACOS_HOST_CAPABILITY_MATRIX

Determine the real macOS ChatGPT carrier/identity/context-pressure surfaces before committing to an automated transport implementation.

Claim ceiling

MAIN_CONTINUITY_REQUIREMENT_RECORDED — PROACTIVE_ROLLOVER_NOT_YET_PROVEN

[James3014]

V2 Main continuity：保留使用者意圖，不假設 MCP 可以任意建立／喚醒新 ChatGPT 對話

Parent #104；native peer admission donor #108；worker continuity #51；carrier capabilities #105。Main仍然是Main，不為了reuse worker ticket而把使用者主對話降成Swarm worker。

研究來源：Ultra 2c61c79ffe269d31523bac37ae6ecd60c9065a5e docs/conversation-continuity.md與相關runtime；DevSpace canonical 8da19eb34e2fcdd9cf36faf2064911d5cbed7020。

正確解讀 Ultra Main 路徑

Ultra描述的是其managed Classic環境的selective continuation：在下一個真正使用者Send，或既有已授權Goal bridge follow-up邊界，傳入bounded capsule並保留logical UI continuity；經目標descriptor與compression contract檢查後才移轉authority。

這不證明標準ChatGPT Web任意新對話可由MCP自動創建，也不是允許攔截私有payload、改寫使用者訊息或製造新的使用者授權。不要照搬Windows/CDP/cookie/session-seeding/private-backend mechanics。

三項分開交付

1. Continuous checkpoint：source改變、task/result terminal或meaningful gate完成時，更新有界Main continuation projection，指向canonical workspace/lease/Swarm/task/attempt/evidence；不要等模型知道context快滿才保存。
2. Proactive prepare：pressure只作估計與預警；準備capsule不代表已轉移owner。無supported exact token信號就維持unknown，不能宣稱精確剩餘容量。
3. Supported target bind：先驗證平台carrier能力與必要使用者同意；target不存在／不支援時明示USER_ACTION_REQUIRED並提供非秘密continuation reference，不能假稱「說接剛才就自動取得完整對話」。

新Main必須fresh read goal/frontier與active effect refs，而不是把模型摘要當current truth。Main切換不能讓仍活著的worker失去任務，也不能重新create swarm把舊任務忘掉。

Authority / transaction contract

• Controller authority與Swarm owner fingerprint、workspace lease、grant、task/operation pins的關係須G0逐項對照；P0: Crash-safe ChatGPT session continuation after context rollover #101 source merge不自動證明上述consumer已整合。
• bounded capsule的schema/hash、goal、source epoch、target trusted identity、grant compatibility與evidence pointers全部驗證後才commit binding。
• readonly discovery只返回本人可讀工作；多個未結束goal有歧義時回候選集合/要求選定，不靠updatedAt任意接管錯repo工作。
• 目標檢查失敗且transfer已證明未發生，舊owner維持有效。transfer或外部Send結果UNKNOWN則reconciliation-only，不盲目rollback/雙owner/retry。
• 目前active/unknown command、agent、task不得因換conversation建立新attempt；依原operation reconcile。
• planned rollover與crash takeover有不同reason/receipt；成功後舊epoch fenced，但不能刪除歷史evidence或原conversation。

Privacy / user-control

只攜帶settled objective/constraints、必要決策、bounded semantic summary、exact refs、remaining gap/next gate。不帶full transcript、hidden reasoning、raw tool arguments、auth token/cookie。

真使用者訊息保持原意和可見文字，不把hidden synthetic message當使用者同意；任何自動continuation都必須在已有bounded authorization內。Host拒絕、unsupported conversation、tool snapshot stale是不同blocker，遵循正常action review/permission，不繞過。

驗收補強

• 無exact token telemetry時label正確；estimate的coverage unknown被揭露。
• 多goal/latest ambiguous不取錯工作；錯repo/goal/epoch/target/capsule拒絕。
• continuous checkpoint在Main突然終止前已durable；新session不用手貼完整聊天。
• Main A->B後，同一既有Swarm與worker/task/attempt lineage仍能query/collect，非重新創建成功假象。
• 若carrier不支援自動create，只能claim已完成checkpoint/user-assisted rebind，不能claim proactive fully automatic rollover。
• real proactive gate與 P0: Crash-safe ChatGPT session continuation after context rollover #101 crash fallback皆用fresh exact runtime測試；source-tests PASS不能替代。

本Issue可以先做checkpoint/feasibility，不必等 #51-B 完整Auto Compact。但 #104 最終parity需要Main與Worker各自live evidence。

[James3014]

Owner Main-continuity amendment — proactive replacement Main must be system-created

The proactive Main UX is now aligned with the same zero-touch carrier substrate being implemented by #117/#105.

Normal product path

A user must not wait for Main A to die and then manually open Main B as the ordinary rollover mechanism.

Required proactive flow:

logical Main / goal epoch N
-> pressure reaches configured safe threshold
-> durable bounded checkpoint/capsule prepared
-> wait for safe authority/effect boundary
-> DevSpace carrier runtime creates/opens a fresh Main conversation automatically
-> verify target conversation + configured DevSpace app/tool binding
-> bind exact continuity record / next epoch
-> fence prior Main carrier where authority transfer applies
-> continue next authorized turn on fresh Main

The user may observe the new Main conversation, but after one-time environment setup must not create it, copy a capsule into it, reconnect dev-c manually, or transport IDs/results between Main generations.

Relationship to #117

#117 owns the reusable macOS ChatGPT Web carrier creation/navigation/health substrate for managed conversations.

#106 owns Main continuity truth and authority transfer:

carrier creation/control          #117/#105 adapter substrate
Main goal/checkpoint/epoch truth  #106
crash takeover fallback           #101

Do not turn Main into a Swarm worker to reuse worker authority. Reuse only transport/control primitives and bounded capsule primitives where safe.

#101 remains fallback, not normal UX

Manual fresh-session creation followed by coordination_continuation_latest/takeover remains accepted crash recovery when the proactive carrier path fails catastrophically.

It does not satisfy #106 proactive G4 acceptance.

Live acceptance correction

The G4 A -> B witness must begin from Main A and have DevSpace itself create/open Main B.

Required evidence includes:

• manual target Main creation = 0;
• manual dev-c/app selection in target Main = 0 after setup;
• manual capsule/ID transfer = 0;
• same logicalGoalId / continuityId across generations;
• continuationEpoch increments once;
• target carrier identity physically verified;
• old owner/carrier is fenced or explicitly downgraded according to authority contract;
• no duplicate agent/command/task/external effect;
• new Main can perform one real next-gate action;
• if proactive creation/bind fails ambiguously, reconcile/fallback to P0: Crash-safe ChatGPT session continuation after context rollover #101 rather than opening another uncontrolled Main.

Host limitation rule

If current ChatGPT Web/macOS automation cannot safely create/bind a fresh Main conversation, expose that exact capability as unsupported and keep #106 open. Do not call a user-created replacement conversation 'proactive rollover' merely to obtain a green test.