P0: implement macOS zero-touch ChatGPT worker runtime pool

[James3014]

Status / contract rebound — Wave 2, 2026-09-16

P0 — WAVE1_EVIDENCE_COMPLETE / CONTRACT_REBOUND / G1 IMPLEMENTATION_DELTA_READY / G2–G6 BLOCKED.

Parent: #105. Tracked by #104.

The product goal is unchanged: after one-time environment authorization, James should interact only with Main while DevSpace creates/restores exact ChatGPT worker conversations, binds authenticated peers, parks/wakes workers, recovers lost browser targets, and scales the pool without manual relay.

This contract supersedes the earlier per-worker browser-process/profile requirement. That requirement was inferred from the Windows Ultra donor before macOS carrier evidence was complete. Wave 1 now provides direct macOS evidence that a single authenticated Chrome profile/session can host multiple exact ChatGPT conversations as independently addressable browser targets without cross-navigation or cross-close effects.

Current source watermark for this rebound:

James3014/devspace main = ce1fe574e1a1cdc75c6c691099d70b635a1990a7
tree = a9d23c98ecfc82fcbea0499ddb520fea14f22476

The two commits that advanced main during Wave 1 changed durable-operation recovery code only and did not change the macOS carrier implementation.

---

Owner UX contract

Normal use starts from one user-facing Main conversation:

James
  -> Main ChatGPT
       -> DevSpace runtime_ensure(desiredWorkers=N)
            -> attach/reuse one authorized authenticated Chrome session
            -> find/reopen/create N exact worker conversations
            -> bind each conversation to one logical worker through authenticated peer identity
            -> keep idle workers available without model polling
       -> dispatch targeted work
            -> resolve exact worker conversation
            -> obtain/rebind a current browser target handle
            -> wake exact worker
            -> worker next/execute/submit
       -> Main collect / follow-up

After one-time browser/host authorization, normal ensure / scale / recover / wake must require:

manual worker window creation   = 0
manual worker app selection     = 0
manual join/invite transfer     = 0
manual workerId/taskId transfer = 0
manual worker wake              = 0
manual result relay             = 0
manual per-worker login         = 0

One-time explicit browser remote-debugging / agent authorization is allowed when required by the supported Chrome path. Credential, CAPTCHA, quota, account-rotation, or security-control bypass is not allowed.

---

Wave 1 evidence basis

W1-E1 — direct CDP target isolation

On the target Mac, one managed Chrome runtime successfully held three distinct page targets. Navigating target A did not change B/C; closing B did not disturb A/C.

This proves browser-target isolation at the tab/target lifecycle layer. It does not make targetId durable worker identity.

W1-E2 — authenticated multi-conversation coexistence

An already authenticated Chrome profile successfully opened three existing ChatGPT conversations concurrently. Navigating one conversation away did not change the other two; closing one tab did not affect the remaining conversations. No prompt or tool call was sent during this witness.

W1-E3 — OpenCLI is not a reliable lifecycle dependency

During Wave 1:

opencli daemon = running
Browser Bridge extension = disconnected
opencli profile list = no connected profiles
read-only chatgpt history = BROWSER_CONNECT failure

OpenCLI remains useful as diagnostic/compatibility evidence, but is not accepted as the canonical worker lifecycle carrier.

W1-E4 — ChatGPT macOS app not selected

The ChatGPT macOS app is present and authenticated, but Wave 1 found no stable supported exact-conversation/CDP control surface suitable for DevSpace worker lifecycle. It remains unselected, not disproven forever.

W1-E5 — Chrome existing-session direction

Current Chrome 152 satisfies the version range for Chrome's supported existing-session remote-debugging / agent connection flow introduced for modern Chrome. This direction preserves the user's authenticated browser session without requiring per-worker profile/login setup. Exact DevSpace integration mechanics remain a G1 implementation question; the product contract does not require one particular MCP package or private API.

---

Ultra donor interpretation

Reference donor:

• enwong93-sketch/devspace-ultra/docs/chat-swarm-classic-productization.md
• donor revision inspected: 6d5fa4fb9669f870ea15d43a2b6aba4678a38a97

Ultra proves the product/lifecycle invariants:

• Main-only normal UX;
• setup/login complexity absorbed by controller logic;
• exact durable worker conversation mapping;
• backend remains worker/task authority;
• UI automation is lifecycle/bootstrap/recovery only;
• idempotent ensure;
• paced provisioning;
• exact recovery;
• no blind replay after unknown external effects.

Ultra's Windows AppX/package/profile isolation is not a macOS requirement. The macOS implementation SHALL use the lightest isolation layer that physical evidence proves sufficient and SHALL escalate to browser-context/profile/process isolation only if later evidence falsifies target/conversation isolation.

---

Frozen identity / authority model

These identities are distinct:

logical workerId
!= ChatGPT conversation ID / URL
!= conversation fingerprint
!= authenticated MCP peer/session fingerprint
!= browser targetId / CDP sessionId
!= browser process PID
!= Chrome profile identity

Durability boundary:

DURABLE / authoritative mapping
logical workerId
<-> exact conversation identity
<-> authenticatedPeerFingerprint
<-> Swarm task/attempt/result state

EPHEMERAL browser-generation handle
targetId / CDP sessionId

targetId may disappear or change after tab close/reopen or browser restart. Recovery SHALL re-resolve or reopen the exact persisted conversation and obtain a fresh target handle; it SHALL NOT mint a new logical worker merely because a target disappeared.

Authority remains:

Chat Swarm durable store
  = worker/task/attempt/result/reconciliation authority

Mac browser carrier
  = host lifecycle + exact conversation addressing + wake/recovery transport

Browser/UI/CDP/OpenCLI
  = transport/observation only

Browser state must never mint task, retry, merge, repository, or completion authority.

OUTCOME_UNKNOWN != retry permission remains mandatory.

---

Required primary macOS topology

The first implementation candidate SHALL target:

DevSpace Chat Swarm
        |
        v
MacWebChatCarrierAdapter
        |
        v
Authorized existing authenticated Chrome session
        |
        +-- Worker-01
        |    exact conversation A
        |    current ephemeral target handle A
        |
        +-- Worker-02
        |    exact conversation B
        |    current ephemeral target handle B
        |
        +-- Worker-03
             exact conversation C
             current ephemeral target handle C

The browser connection mechanism SHALL be a supported bounded existing-session control path with explicit user authorization. Do not depend on mutating the user's normal Chrome launch command with legacy --remote-debugging-port against the default data directory.

Escalation rule

Per-worker browser context/profile/process isolation is not required by default.

Escalate only if a later live witness proves one of these cannot be controlled safely at conversation/target isolation:

• exact target addressing;
• independent navigation/close/reopen;
• authenticated peer identity;
• recovery after target loss;
• concurrent targeted wake;
• account/host state separation required for correctness.

Any escalation requires a new evidence-bound contract delta; do not silently strengthen isolation in implementation.

---

Brownfield source delta audit

PRESERVE — no redesign required

The following current behavior remains part of the accepted architecture and should be reused unless implementation evidence finds a bounded defect:

• fix(chat-swarm): add observable, approval-bound native peer admission #108 admission invariants;
• fix(chat-swarm): add durable owner task ledger and queue-safe targeted dispatch #112 durable task/queue truth;
• feat: journal injected Chat Swarm carrier operations #116 durable carrier-operation journal;
• chat_swarm_runtime_status/ensure/scale/recover/stop/bootstrap product surface;
• managed provisioning operation identity / TTL / CAS / idempotency;
• first-uncertain fail-fast behavior;
• no blind resend after ambiguous external effects;
• exact conversation URL/fingerprint persistence;
• authenticatedPeerFingerprint separate from conversation fingerprint;
• logical workerId separate from carrier/conversation identity;
• fail-closed conflicting identity handling;
• continuation/reconciliation semantics;
• scale-down protection for busy/targeted/reconcile-required workers;
• backend dispatch-before-wake ordering.

PRESERVE WITH REBIND — existing CdpMacWebDriver

Current CdpMacWebDriver already models one CDP endpoint with multiple exact targets and supports:

newTarget(projectUrl)
openOrReuse(exact conversation URL)
close exact target
wait for composer
observe conversation URL
send to exact target
recover exact conversation

This shape is directionally aligned with Wave 1 evidence and should not be replaced by a per-worker browser-runtime manager.

Required rebind: its connection/launch boundary must support the selected authorized existing-session Chrome path rather than assuming DevSpace owns a dedicated --user-data-dir runtime whenever preflight is unavailable.

MODIFY — browser connection ownership

Current CDP startup fallback launches Chrome with:

--remote-debugging-port=<port>
--user-data-dir=<managed profile dir>

That remains a bounded fallback for a dedicated managed browser profile, but it SHALL NOT be the canonical normal UX after Wave 1.

G1 must introduce or adapt a connection seam that can:

preflight existing authorized Chrome control session
attach/reconnect without copying session secrets
observe exact targets
open/reopen exact ChatGPT conversation targets
classify authorization/setup-required separately from worker failure

The exact library/process used to obtain that connection is an implementation choice to be proven in G1; #117 does not grant permission to use hidden OpenAI APIs or bypass Chrome's authorization UI.

MODIFY — target lifecycle representation

Persisted registry SHALL NOT treat browser target/session IDs as durable identity.

If target/session generation metadata is recorded for diagnostics, it must be explicitly ephemeral and replaceable.

Recovery semantics:

slot has exact conversation identity
-> inspect current browser targets
-> reuse exact target if present
-> otherwise reopen exact conversation
-> obtain new target/session handle
-> revalidate host/app + authenticated peer identity
-> resume same logical worker

MODIFY — setup/readiness classification

Browser readiness and worker readiness must remain distinct.

At minimum classify:

BROWSER_AUTHORIZATION_REQUIRED
BROWSER_CONTROL_UNAVAILABLE
CHATGPT_SIGNED_OUT
HOST_APP_BINDING_NOT_READY
PEER_IDENTITY_UNRESOLVED
CONVERSATION_IDENTITY_DRIFT
RECONCILE_REQUIRED

A browser target existing is not enough for worker health.

MODIFY — app label/config drift

The current operational DevSpace App/MCP name is dev.

Any source/docs default still referring to dev-c must be audited in G1. Do not silently change unrelated compatibility aliases unless current consumers are verified.

DOWNGRADE — OpenCLI

OpenCliMacWebDriver MAY remain as an optional diagnostic/compatibility adapter while G1 is implemented.

It SHALL NOT be the canonical lifecycle path for:

• pool creation;
• worker recovery;
• scale up/down;
• cold reconstruction;
• acceptance of G2–G6.

Do not delete it merely to simplify the first corrective PR; removal requires separate evidence that no supported consumer needs it.

PARK — ChatGPT macOS app

No G1 implementation effort should target the ChatGPT Mac app unless a supported exact-conversation control seam is newly proven and materially better than Chrome.

REMOVE FROM CONTRACT — per-worker browser process/profile requirements

The following previous requirements are superseded:

• one browser process per logical worker;
• one dedicated profile/user-data-dir per logical worker;
• one CDP endpoint per logical worker;
• process death of one worker as the primary G4 failure model;
• three separate authenticated browser runtimes as a prerequisite to G2.

They remain historical evidence only.

---

G1 required implementation delta

Implement the minimum source delta necessary to bind the existing runtime manager to the Wave 1 proven model.

Expected responsibility boundary:

MacChromeControlSession
  preflight()
  authorization/readiness status
  listTargets()
  newTarget(url)
  openOrReuseExactConversation(url)
  closeExactTarget(url/target)
  evaluateExactTarget(...)
  reconnect/rebind after browser generation change

Names are not normative. Avoid creating a second worker/task/runtime authority.

The implementation SHALL preserve injectable/fake driver tests and the existing MacWebDriver seam unless a smaller compatible change is demonstrably better.

G1 hostile controls

At minimum:

• operation on target A cannot navigate/close target B;
• stale targetId does not become durable identity;
• target lost -> exact conversation reopen -> same logical worker;
• wrong conversation attempts managed-slot admission -> rejected;
• changed conversation identity under one provisioning operation -> rejected/reconcile;
• response lost after conversation creation -> exact readback before any replacement;
• bootstrap acknowledgement unknown -> no duplicate conversation/worker;
• identical concurrent ensure(N) -> no duplicate logical workers/conversations;
• browser control disconnect -> no blind resend;
• browser reconnect does not auto-requeue potentially started task;
• signed-out/authorization-required/app-disabled are setup/host failures, not task failures;
• busy/reconcile-required worker cannot scale down;
• corrupted runtime registry fails closed without deleting Swarm/task truth;
• OpenCLI cannot silently become canonical through configuration fallback.

---

Revised gate sequence

G0 — macOS carrier evidence

PASS — Wave 1.

Evidence supports one authenticated Chrome session with multiple exact conversation/target carriers as the first candidate. OpenCLI-primary rejected; per-worker profile/process isolation not required by current evidence.

Required claim:

MACOS_CONVERSATION_TARGET_ISOLATION_WITNESS_PASS

G1 — source implementation + independent acceptance

Implement only the connection/control delta above against fresh main.

Required before merge:

• exact base/head/diff;
• existing-session control abstraction tests;
• exact target/conversation negative controls;
• reconnect/reopen tests;
• existing admission/task/replay/reconciliation regression;
• OpenCLI downgrade preserved;
• typecheck/build/focused tests/full practical macOS CI;
• independent Candidate acceptance;
• exact-head merge.

Source/test success is not live acceptance.

G1D — exact canary deployment

Deploy exact accepted merged build and bind:

source commit/tree
build ID
server instance ID
state root
host-visible MCP schema
Chrome/browser version
browser-control mechanism + generation
configured project/app identity

G2 — zero-touch create/bind

From Main only, on a fresh Swarm:

runtime_ensure(desiredWorkers=3)

Require:

• exactly 3 healthy logical workers;
• exactly 3 distinct exact ChatGPT conversations;
• each has a distinct current browser target handle when active;
• all map to distinct authenticated peer identities as required by admission;
• manual worker interaction = 0;
• repeat ensure(3) creates 0 new workers/conversations/effects.

G3 — exact targeted execution

Dispatch one bounded targeted task to each worker.

Require:

durable assignment
-> exact conversation resolution
-> current target reuse/reopen
-> exact worker wake
-> next/claim
-> execute
-> submit
-> Main durable collect

Cross-worker attribution = 0; duplicate execution = 0; manual relay = 0.

G4 — recover one worker carrier

Close/lose exactly one worker conversation target, not the whole browser profile.

Require:

• other worker conversations remain untouched;
• exact persisted conversation is reopened/re-resolved;
• target handle may change;
• authenticated peer/logical worker continuity is preserved;
• unknown task effects remain RECONCILE_REQUIRED.

G5 — elastic scale

Prove:

3 -> 5 -> 2

Scale-up adds only missing logical workers/conversations. Scale-down retires only safe idle workers and never evicts busy, targeted, continuation-pending, or reconcile-required workers.

G6 — cold browser/control reconstruction

With durable mappings present:

1. lose/restart the browser control connection or browser generation through the supported path;
2. keep durable Swarm/runtime registry state;
3. reconnect to the authorized Chrome session;
4. call one runtime_ensure(desiredWorkers=<target>);
5. rediscover or reopen exact saved conversations;
6. obtain fresh target handles;
7. prove no duplicate logical workers/conversations and no blind replay of unknown effects.

A full user-profile logout/login cycle is not required for G6 unless the selected supported browser-control mechanism makes it unavoidable.

---

Non-goals

• no Windows AppX/package clone implementation;
• no requirement for one Chrome profile/process per worker without new falsifying evidence;
• no hidden/private OpenAI API emulation;
• no credential/cookie export as product authority;
• no CAPTCHA/rate/quota bypass;
• no multi-account rotation;
• no browser state becoming Swarm/task authority;
• no automatic mutation of Chrome security settings without explicit Owner action/authorization;
• no feat(chat-swarm): add durable worker continuity and conversation rollover #51 Auto Compact or feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover #106 Main rollover closure from this Issue;
• no production/unlimited-concurrency claim from source tests.

---

Execution / review boundary

This is architecture/lifecycle-sensitive P0 work.

claim_mode = MANUAL_DISPATCH
AUTO_CHAIN = false

Implementation must rebind fresh main, current Chrome/browser-control evidence, production DevSpace identity, and overlapping #117 work before mutation.

Candidate implementation cannot self-accept, self-merge, deploy, or close this Issue.

---

Exact next gate

G1_EXISTING_AUTHENTICATED_CHROME_CONTROL_SOURCE_DELTA

Implement the smallest supported connection/control change needed for DevSpace to address exact ChatGPT conversations inside one explicitly authorized existing authenticated Chrome session. Preserve all current Swarm/task authority and use per-worker profile/process isolation only if new live evidence falsifies the Wave 1 target-isolation result.

Claim ceiling

Current maximum claim:

WAVE2_CONTRACT_REBOUND_COMPLETE — MACOS_ZERO_TOUCH_WORKER_RUNTIME_NOT_YET_LIVE_PROVEN

Only after G1 + G1D + G2 + G3 + G4 + G5 + G6 all pass on exact evidence may #117 close with:

MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS

[James3014]

Source correction — there is no literal two-worker source cap

Fresh current-main inspection corrects one statement in the Issue body.

Current source already has:

DEFAULT_CHAT_SWARM_MAX_WORKERS = 16

and chat_swarm_create.workerLimit is bounded by:

config.chatSwarmMaxWorkers

The max=2 surface observed during #49 came from that isolated Canary being intentionally started with DEVSPACE_CHAT_SWARM_MAX_WORKERS=2; it is not a hard-coded source/product ceiling.

Therefore Codex/Luna must not spend a work package replacing a literal 2-worker source limit.

Revised capacity work is only:

• ensure desiredWorkers is bounded by the already-configured chatSwarmMaxWorkers;
• expose/configure an appropriate zero-touch pool default separately from the hard safety maximum;
• keep the source safety bound configurable and tested;
• live G2 may use 3 workers and G5 may use 3 -> 5 -> 2 under a Canary configured with sufficient chatSwarmMaxWorkers;
• preserve all existing capacity/CAS/admission constraints.

This correction reinforces the core problem: the missing product capability is the real runtime carrier adapter + create/restore/autojoin/wake/recover lifecycle, not Swarm's configurable worker-count bound.

[James3014]

Codex/Luna implementation plan — do not stop at another foundation PR

This is the execution order for #117. The Controller should keep sequencing/acceptance; Luna may implement bounded work packages. Do not call the Issue complete merely because another adapter interface or journal table lands.

Fresh source facts to preserve

Current main already shows:

1. config.ts defaults DEFAULT_CHAT_SWARM_MAX_WORKERS = 16; the previous 2-worker limit was isolated-Canary configuration, not a literal source ceiling.
2. chat_swarm_create.workerLimit is bounded by config.chatSwarmMaxWorkers.
3. ChatSwarmCarrierManager.ensure() currently operates only on admittedCarrierWorkers(swarmId). If admitted worker count is below requested capacity it returns/throws ADMISSION_REQUIRED; it does not create a conversation or provision missing workers.
4. ChatSwarmLifecycle constructs ChatSwarmCarrierManager only when carrierAdapter is supplied.
5. current server.ts constructs ChatSwarmLifecycle without carrierAdapter.
6. PR feat: journal injected Chat Swarm carrier operations #116 therefore provides operation journaling and an injectable adapter contract only. No real carrier is wired to the server/tool surface.

These facts define the actual gap.

---

WP0 — G0 physical macOS carrier feasibility (Controller-owned evidence)

Before production mutation, freeze one real carrier mechanism on the target Mac.

Required physical probes, using an inert test/project where possible:

• identify exact browser/runtime executable + version;
• identify bounded automation interface (CDP / supported bridge / equivalent);
• open configured ChatGPT worker Project;
• create a new conversation through normal UI;
• read exact resulting conversation URL/identity;
• reopen that exact conversation from a fresh controlled browser state;
• detect signed-in/composer-ready/generating/interrupted/challenge/quota states;
• establish or select dev-c through normal supported UI and verify a read-only tool call reaches the exact Canary;
• wake/send one harmless turn into an already-existing worker conversation after its prior turn ended;
• prove >=3 managed conversations can coexist without cross-navigation.

Output a small capability matrix. If the chosen mechanism cannot establish the DevSpace app/tool binding or reliably address an exact conversation, stop before pretending it is a real adapter.

G0 claim only:
MACOS_WEB_CARRIER_MECHANISM_FROZEN

---

WP1 — carrier registry + browser-driver abstraction

Implement a transport-neutral local registry and a narrow browser-driver interface.

Suggested ownership:

• extend/new carrier types near src/chat-swarm-carrier.ts;
• new dedicated macOS web carrier module rather than browser logic inside coordinator/store;
• additive SQLite migration for secret-free managed-carrier records where durable storage is required;
• config fields for feature enablement, browser executable/profile/project/control endpoint, pool default/max, deadlines.

Registry must bind at least:

managedCarrierId
swarmId
logicalWorkerId?       # absent until admission completes
runtimeSlot
conversation identity / URL
conversation fingerprint
continuationEpoch
carrierKind
project identity
browser/profile identity
health state
binding state
last operation refs
version/revision

No raw tokens/cookies/session secrets.

Hostile tests: corruption, conflicting slot, duplicate conversation mapping, restart/reopen, wrong swarm/worker mapping.

---

WP2 — managed ensure provisioning transaction

This is the most important authority work.

Do not weaken #108 by auto-approving arbitrary join_requests.

Add a bounded owner-created managed provisioning record for each missing slot:

ensureOperationId
swarmId
runtimeSlot
expected carrier identity once created
expiry
CAS/version
state

The owner call pre-authorizes only that exact missing slot/carrier-generation operation.

Flow:

runtime_ensure(N)
-> inspect healthy bound capacity
-> allocate only missing managed slots
-> persist provisioning intent before external UI effect
-> adapter creates/opens conversation
-> bind observed exact conversation identity back to provisioning record
-> bootstrap peer request from that exact conversation
-> correlate authenticated request with exact provisioning record
-> atomically bind/approve exact worker slot
-> persist final logicalWorkerId + carrier mapping

Knowledge of label/requestId/conversation URL alone must not be sufficient.

Response lost after conversation creation/admission:
reconcile exact provisioning operation before creating another conversation.

Required negative tests:

• unrelated conversation attempts to claim managed slot;
• same label different peer;
• expired provisioning record;
• changed conversation identity under same operation;
• parallel ensure calls race for same slots;
• response lost before/after remote conversation creation;
• response lost before/after admission commit;
• replay returns same worker/carrier, not a duplicate.

---

WP3 — real MacWebChatCarrierAdapter wiring

Implement the #116 adapter methods using WP0's frozen mechanism and extend the lifecycle contract only where necessary for create/recover/park/stop.

Wire the adapter into server.ts when feature/config preflight succeeds.

Do not silently fall back to a fake/manual adapter.

Server/capability identity must expose whether the real runtime manager is:

DISABLED
CONFIGURED_NOT_READY
READY
DEGRADED
RECONCILE_REQUIRED

A browser/tab existing is not enough for READY.

---

WP4 — runtime MCP tool surface

Register first-class tools (names may follow source conventions):

chat_swarm_runtime_status
chat_swarm_runtime_ensure
chat_swarm_runtime_scale
chat_swarm_runtime_recover
chat_swarm_runtime_stop

Requirements:

• capability manifest includes exact schemas;
• lifecycle/drain semantics explicit;
• consequential calls readOnlyHint=false;
• status is bounded/read-only;
• runtime_ensure accepts desiredWorkers and is idempotent;
• no need for James to know slot/conversation/worker IDs during normal use.

Do not expose model-visible credentials.

---

WP5 — app binding + minimal bootstrap

New managed worker conversation must pass these gates before counted healthy:

CARRIER_CREATED
-> HOST_AUTHENTICATED
-> HOST_APP_BINDING_READY
-> PEER_IDENTITY_RESOLVED
-> SWARM_BOUND
-> PARKED/AVAILABLE

Use the smallest supported UI/bootstrap action.

If current ChatGPT requires one-time app consent or login that cannot be safely automated, expose SETUP_REQUIRED and document the one-time setup. After setup, repeated ensure/recover must not require James to operate worker chats.

HOST_APP_DISABLED / stale schema must never be reported as worker/task failure.

---

WP6 — targeted wake / park / recover

Use PR #116's operation journal as the durable external-effect fence.

Dispatch-to-parked-worker path:

canonical task assignment
-> exact WAKE operation persisted
-> adapter wakes exact current carrier epoch
-> worker reads canonical task
-> execution witness/result

Lost acknowledgement:
RECONCILE_REQUIRED, not a second prompt/new attempt.

Recover path uses exact saved conversation mapping first. If replacement conversation is required, stop at #51-compatible continuation rather than silently minting a new logical worker.

---

WP7 — elastic scaling

desiredWorkers uses existing configured chatSwarmMaxWorkers; do not introduce a second conflicting max-worker authority.

Scale up: provision only missing slots.

Scale down refuses workers that are:

• busy/current task;
• targeted by queued tasks;
• continuation pending;
• carrier operation unknown/reconcile-required;
• otherwise protected.

No silent worker renumbering or ownership shuffle.

---

WP8 — source acceptance before PR

Controller independently verifies, not from Luna summary only:

• exact base/head/diff;
• migrations additive/upgrade safe;
• app/browser secrets absent from durable DB/logs;
• focused runtime-pool tests;
• hostile replay/race/restart tests;
• existing admission/task/restart/drain regression;
• typecheck;
• build;
• npm test within practical policy;
• git diff --check;
• package/capability manifest includes runtime tools.

macOS CI is authoritative for this product line. Record other platform failures without allowing unrelated baseline debt to redefine macOS acceptance.

---

WP9 — Canary deployment

Deploy the exact accepted Candidate to isolated 7678 only first.

Bind separately:

source commit
build ID
build/manifest identity
server instance ID
state root
host-visible MCP schema
browser adapter/runtime version

Do not infer live acceptance from merge/deploy.

---

WP10 — zero-touch live acceptance

Start with only Main user-facing. James must not pre-open worker chats.

Gate A

Main -> runtime_ensure(desiredWorkers=3)

Expected:

• 3 managed conversations created/restored automatically;
• 3 distinct logical workers bound;
• all healthy/parked;
• repeat ensure(3) creates 0 new conversations/workers.

Gate B

Main queues 3 targeted tasks. Exact worker carriers wake automatically, execute and submit. Main collects from durable state.

Manual worker interaction count = 0.

Gate C

Close/kill one managed carrier. runtime_recover restores the exact logical worker using saved carrier mapping while other two remain untouched.

Gate D

Scale 3 -> 5 -> 2, respecting protected/busy/targeted/reconcile states.

Gate E

Restart DevSpace / close managed workers; one ensure(desiredWorkers=<target>) reconstructs the pool from durable state.

Only after these gates pass may #117 claim:

MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS

Do not close #51/#106/#104 from this result.

---

Controller/implementer division

Recommended:

Codex Controller:
  architecture freeze
  physical G0 evidence
  bounded work-package dispatch
  independent diff/test review
  PR/CI disposition
  Canary deployment
  live acceptance

Luna:
  bounded source implementation in isolated worktree
  no self-merge / no self-deploy / no self-acceptance

Do not use James as the message bus between worker conversations during implementation or acceptance.

[James3014]

Owner dispatch — continue #117 with Codex CLI / Luna / xhigh

Continue implementation of #117 from current main after PR #116. Do not stop on the fact that ChatGPT account login cannot be fully automated.

Execution identity

• worker: Codex CLI
• model: Luna
• reasoning: xhigh
• repository: James3014/devspace
• target: Issue P0: implement macOS zero-touch ChatGPT worker runtime pool #117
• base: fresh current main at dispatch time; re-read before mutation

Correct blocker interpretation

Automatic OpenAI/ChatGPT account login is not a #117 requirement. Treat first-time login/MFA/consent as a one-time SETUP_REQUIRED environment precondition when the platform requires it.

Do not attempt:

• automatic credential entry;
• cookie/session export or cloning as authority;
• CAPTCHA/challenge bypass;
• hidden/private OpenAI API use;
• account rotation.

The #117 product requirement begins after one-time setup: repeated ensure / scale / recover must be zero-touch.

Immediate next gate — finish G0, then continue to source implementation if supported

Using a dedicated persistent managed browser profile, prove and record separately:

1. AUTH_SESSION_PERSISTENT — after Owner performs one manual login, browser close/reopen retains usable authenticated ChatGPT state.
2. CONVERSATION_CREATE_CONTROL — automatically create a conversation in the configured worker Project.
3. EXACT_CONVERSATION_IDENTITY — read exact conversation URL/bounded identity and reopen that exact conversation.
4. COMPOSER_STATE_OBSERVABLE — distinguish composer-ready / generating / interrupted / signed-out / challenge / quota states.
5. HOST_APP_BINDING — determine whether a new managed conversation can use configured dev-c without Owner touching that worker conversation.
6. MULTI_CARRIER — at least three managed conversations can coexist without cross-navigation or identity confusion.

G0 disposition rules

• If only first-time account login/consent is manual: classify SETUP_REQUIRED, G0 may continue.
• If the profile cannot preserve authenticated state across reopen: blocker = AUTH_SESSION_PERSISTENCE_UNAVAILABLE.
• If exact conversation create/reopen cannot be controlled: blocker = EXACT_CARRIER_CONTROL_UNAVAILABLE.
• If every new worker conversation requires James to manually reselect/reconnect dev-c: blocker = HOST_APP_BINDING_MANUAL_REQUIRED.
• Do not report generic AUTO_LOGIN_UNAVAILABLE as the Issue blocker.

If G0 supports the carrier

Proceed immediately with bounded source implementation rather than stopping at another design/foundation PR:

1. secret-free managed carrier registry + browser-driver abstraction;
2. managed runtime_ensure provisioning transaction with exact slot/carrier/expiry/CAS binding;
3. real MacWebChatCarrierAdapter wired into server.ts behind explicit config/preflight;
4. MCP tools: chat_swarm_runtime_status, chat_swarm_runtime_ensure, chat_swarm_runtime_scale, chat_swarm_runtime_recover, chat_swarm_runtime_stop;
5. host/app binding health state machine;
6. exact wake / park / recover using PR feat: journal injected Chat Swarm carrier operations #116 operation journal and no blind resend;
7. scale semantics bounded by existing config.chatSwarmMaxWorkers — do not recreate a fake literal two-worker-cap fix;
8. hostile replay/race/restart/security tests;
9. typecheck/build/focused tests/full practical macOS acceptance before PR.

Safety / authority

Preserve:

• logical workerId != conversationId != browser tab != MCP session;
• browser/UI state never mints Swarm task authority;
• fix(chat-swarm): add observable, approval-bound native peer admission #108 admission invariants;
• fix(chat-swarm): add durable owner task ledger and queue-safe targeted dispatch #112 durable task truth;
• feat: journal injected Chat Swarm carrier operations #116 carrier-operation journal;
• OUTCOME_UNKNOWN != retry permission;
• no self-merge, no production deployment, no P0: implement macOS zero-touch ChatGPT worker runtime pool #117 closure without independent source + live macOS acceptance.

Required report

Do not return only prose saying login is blocked. Return either:

A. exact G0 capability matrix + a single typed blocker from the rules above; or

B. G0 pass evidence plus source Candidate identity, changed paths, tests, remaining live gates, and PR if source acceptance is ready.

Owner intent: continue toward MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS, not another foundation-only milestone.

[James3014]

Ancillary DevSpace blocker found while attempting Cline + GLM-5.3 fallback

This is not the root cause of #117, but it blocked using Cline as an implementation fallback for the remaining G0 work and should be tracked with this issue until split into its own defect.

Observed behavior

Attempted direct dispatch:

provider = cline
cliProviderId = cline-pass
model = cline-pass/glm-5.3
effort = xhigh

DevSpace fails closed before worker launch with a model-contract/readiness error equivalent to:

Cline model 'cline-pass/glm-5.3' is not established for cliProviderId 'cline-pass'.
Installed Cline runtime does not expose the required provider/model/thinking contract.

Physical evidence

Local Cline runtime exists and is not obviously stale:

binary: /Users/jameschen/.npm-global/lib/node_modules/cline/bin/.cline
version: 3.0.61

However, cline is not available on the shell PATH.

DevSpace already has an execution-side Cline binary resolver that can find the real binary, but the Cline catalog/capability probe uses plain cline --version / cline --help semantics instead of the same resolver. This creates a split-brain condition:

execution binary resolution  -> real Cline binary can be found
catalog/model-contract probe  -> `cline` not found on PATH / contract becomes UNKNOWN
agent admission              -> fail closed before dispatch

Root cause hypothesis

ClineCatalogService / Cline readiness discovery is not using the same canonical executable resolution path as Cline execution.

Required fix

Use one canonical Cline executable resolver for both:

1. catalog/version/help probing;
2. provider/model/thinking capability discovery;
3. actual worker execution.

The probe must not silently fall back to a different executable identity than the execution path.

Acceptance criteria

• A machine where the Cline binary is installed at a non-PATH location but discoverable by DevSpace's Cline resolver is reported as a real Cline runtime, not UNKNOWN solely because cline is absent from PATH.
• Catalog/preflight and execution report the same exact executable identity/version.
• provider=cline, cliProviderId=cline-pass, model=cline-pass/glm-5.3, effort=xhigh reaches provider/model admission when that exact Cline runtime supports the contract.
• Unsupported model/provider/thinking combinations still fail closed.
• Add regression coverage for a Cline binary discoverable only through the resolver, with no cline command on PATH.

Relation to #117

This blocked one fallback implementation route for #117 G0-4..G0-8. It should not be treated as evidence that GLM-5.3 itself is unavailable or incapable, and it should not replace the actual #117 physical acceptance requirements.

[James3014]

Cline catalog/executable resolver blocker — SOURCE FIXED

The ancillary Cline dispatch blocker found while working #117 is now fixed on main via PR #118.

Merged main: 1e0730c596b1a3fea2212359bd1bc8ea6ab4b63b

Root cause was a resolver split-brain:

• Cline execution/provider availability already used resolveClineExecutable() (CLINE_COMMAND -> PATH -> supported fallback locations).
• ClineCatalogService independently defaulted its runtime probe to the literal cline command.
• On the current macOS host Cline 3.0.61 is installed at ~/.npm-global/lib/node_modules/cline/bin/.cline while plain cline is not on PATH, so availability could be true while catalog/preflight failed closed before worker launch.

PR #118 now makes the catalog runtime probe reuse the canonical resolveClineExecutable() path while preserving explicit ClineCatalogOptions.command precedence and existing fail-closed semantics. A regression test covers the shared resolver path.

Verification for PR #118:

• macOS Smoke: PASS — typecheck, full test, build, doctor
• Ubuntu Smoke: PASS — typecheck, full test, build, doctor
• macOS local-agent sessions: PASS
• Windows Smoke: same pre-existing seven carrier-binding.test.ts AUTHORITY_REQUIRED failures already recorded on PR feat: journal injected Chat Swarm carrier operations #116; no Cline-specific regression observed

Disposition: this Cline resolver blocker is source-fixed. This does not close #117 and does not prove cline-pass/glm-5.3 is live in the currently loaded Dev MCP runtime. Source merge != installed/loaded runtime. A fresh DevSpace build/cutover/restart and then live agent_preflight / dispatch are still required before treating Cline GLM 5.3 as runnable for #117 G0 work.

[James3014]

G1 source accepted — clean PR #131

Canonical source integration is now in main.

Exact lineage:

• pre-merge base: 07f5c30a6ec8fcb9bfb511cb2b76ae089d6f6244
• clean PR head: bb06b4df469b8c6d6c47ed894b3d0e97257a137a
• merged PR: feat(chat-swarm): implement macOS zero-touch worker runtime source (#117) #131
• accepted main / merge SHA: da4be27769c72e42ec24882145d8a84a804a4999

Exact-head CI: run Waishnav#234 / 34757239223 on bb06b4df469b8c6d6c47ed894b3d0e97257a137a.

PASS:

• Diff check (PR)
• Local agent sessions (macOS)
• continuation coordinator / retired-carrier / durable-store / aggregate-domain / restart-fence / corruption-fence / terminal-replay (macOS)
• Smoke macOS: Typecheck / Test / Build / Doctor
• Smoke Ubuntu: Typecheck / Test / Build / Doctor

Windows evidence is not represented as PASS: Typecheck passed; Test failed only on the same seven pre-existing src/carrier-binding.test.ts AUTHORITY_REQUIRED: Cutover approval exceeds exact local resource or validity baseline failures. Current Owner acceptance target is macOS.

Accepted source claim:
MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_G1_SOURCE_ACCEPTED

#117 remains OPEN. Source integration does not prove native product acceptance. Still required on an exact installed macOS build:

• G0 real browser/CDP/Project/conversation/app-binding witness
• G2 Main-only zero-touch runtime_ensure(3)
• G3 exact targeted execution/submit/collect
• G4 exact worker recovery
• G5 live 3 -> 5 -> 2 scaling
• G6 DevSpace/browser restart + cold ensure reconstruction

Required post-setup budget remains manualWorkerInteractionCount = 0.

Exact remaining blocker in the current controller environment:
NATIVE_MACOS_CHATGPT_BROWSER_CARRIER_WITNESS_REQUIRED

Do not close #117 from source/CI evidence alone.

[James3014]

Native resume manifest after G1 merge — G0/G2-G6 only

Source integrity is frozen and verified:

• accepted main: da4be27769c72e42ec24882145d8a84a804a4999
• accepted tree: 3f16c263f22a283a71080b29b82f390e634ad459
• clean PR source head: bb06b4df469b8c6d6c47ed894b3d0e97257a137a
• merge commit tree == clean source tree
• source claim: MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_G1_SOURCE_ACCEPTED

Resume only from a conversation/environment that exposes the real macOS DevSpace/dev-c runtime and browser carrier surface. Do not substitute GitHub/source evidence for these gates.

N0 — installed-runtime bind

1. Read cutover_status / equivalent installed identity first.
2. Require exact clean installed source/build identity containing merge da4be277...; record sourceCommit, buildId, serverInstanceId, capabilityManifestSha256.
3. Require normal/non-draining mode, no unresolved cutover/reconciliation, and no dirty source.
4. Require the six P0: implement macOS zero-touch ChatGPT worker runtime pool #117 runtime tools to be exposed by the installed capability surface.
5. If any identity or lifecycle fact is stale/unknown, stop before browser effect.

G0 — real Mac carrier feasibility

On the target Mac, prove and record:

• supported browser executable/version and configured managed profile;
• bounded CDP/control endpoint actually reachable;
• configured ChatGPT Project can be opened;
• a worker conversation can be created and its exact conversation identity/URL read back;
• the exact conversation can be reopened;
• composer/generating/interrupted/login/challenge/disabled-app states are distinguishable;
• configured dev-c/app binding can be established/verified;
• an existing completed conversation can be woken again;
• at least 3 worker conversations coexist without identity collision.

No cookie export, hidden/private OpenAI API, CAPTCHA/rate/quota bypass, or account rotation.

G2 — zero-touch create/bind

Use one fresh bounded live-canary swarm from Main only.

1. runtime_ensure(swarmId, desiredWorkers=3).
2. Require exactly 3 healthy managed logical workers, each with distinct exact carrier identity and correct Swarm binding.
3. Require manualWorkerInteractionCount = 0 after the one-time environment setup boundary.
4. Repeat ensure(3) and require 0 new conversations/workers/operations that create external effects.
5. Any unknown create/bootstrap acknowledgement => RECONCILE_REQUIRED; do not reprovision blindly.

G3 — exact targeted execution

Dispatch three bounded tasks, one to each logical worker.
Require for every task:
durable assignment -> exact carrier wake -> exact worker next/claim -> execute -> submit -> Main collect.
No cross-worker claim, duplicate attempt, manual wake, manual ID/result relay, or model-prose completion inference.

G4 — exact recovery

Induce loss of exactly one managed carrier through the native test surface, leaving the other workers intact.
Require recover/ensure to reopen/reconcile the exact logical worker/conversation mapping without minting a new task attempt. Any unresolved task effect remains RECONCILE_REQUIRED.

G5 — elastic live scaling

From a healthy pool:

• 3 -> 5: add only 2 missing workers;
• 5 -> 2: retire only safe idle tail workers.
  Busy, targeted, continuation-pending, or reconcile-required workers must not be evicted.

G6 — restart / cold ensure

With durable managed mappings present:

1. restart the bounded DevSpace/browser runtime using the normal authorized host lifecycle;
2. fresh-bind the replacement server/build identity;
3. call one runtime_ensure for the desired pool;
4. require per-boot ENSURE_EXISTING health checks to physically revalidate/reconstruct the exact pool;
5. require no duplicate logical workers/conversations and no blind replay of unknown effects.

Terminal claim

Only after G0 + G2 + G3 + G4 + G5 + G6 all have exact native receipts may #117 claim:
MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS

Until then keep #117 open with blocker:
NATIVE_MACOS_CHATGPT_BROWSER_CARRIER_WITNESS_REQUIRED.

[James3014]

Native closure manifest — G0 + G2–G6 only

Canonical source is now merged via clean PR #131:

• source head accepted: bb06b4df469b8c6d6c47ed894b3d0e97257a137a
• main merge: da4be27769c72e42ec24882145d8a84a804a4999
• macOS Smoke: Typecheck/Test/Build/Doctor PASS
• Ubuntu Smoke: PASS
• Windows remains the pre-existing carrier-binding baseline and is outside the Owner macOS acceptance target.

Do not reopen source implementation unless a native witness reproduces a fresh defect.

Required exact installed-runtime preflight

Before G0/G2, bind and record:

• installed sourceCommit = da4be27769c72e42ec24882145d8a84a804a4999 or an explicitly accepted descendant carrying the exact P0: implement macOS zero-touch ChatGPT worker runtime pool #117 source contract;
• buildId / capabilityManifestSha256 / serverInstanceId / state root;
• host-visible MCP schema contains all 21 chat_swarm_* tools, including the six chat_swarm_runtime_* tools;
• DEVSPACE_CHAT_SWARM_RUNTIME=1;
• exact worker Project URL configured;
• CDP/browser profile/binary/app-label values resolved without exposing cookies/tokens/session secrets;
• runtime normal (not drain/reconcile-only) and no unrelated unresolved carrier operation.

Fail closed on dirty/stale source, missing runtime tools, wrong server identity, stale host schema, signed-out/challenge state, or unresolved external effect.

G0 — freeze real macOS carrier mechanism

On the target Mac, prove and record:

1. exact browser executable/version and CDP/control endpoint;
2. signed-in ChatGPT Project opens through the bounded managed profile;
3. create one normal UI conversation and read exact conversation URL/fingerprint;
4. reopen that exact conversation;
5. classify composer-ready / generating / interrupted / signed-out / challenge / quota / disabled-app states;
6. establish/verify configured dev-c app binding with a read-only call reaching this exact Canary;
7. wake one already-existing conversation after its prior turn ends;
8. keep >=3 exact managed conversations addressable without cross-navigation.

Claim only after physical evidence: MACOS_WEB_CARRIER_MECHANISM_FROZEN.

G2 — zero-touch create/bind

Start with Main only. After one-time login/app consent:
chat_swarm_runtime_ensure(swarmId=<owner swarm>, desiredWorkers=3)

Require:

• exactly 3 distinct healthy bound logical workers;
• exact managed conversation mapping for each;
• PARKED/AVAILABLE state;
• repeat ensure(3) creates 0 new conversations/workers;
• manualWorkerInteractionCount=0.

G3 — targeted execution

Dispatch three distinct targeted tasks, one per worker. Require exact carrier wake -> canonical chat_swarm_next -> submit -> Main collect, with:

• cross-worker attribution = 0;
• duplicate wake/execution = 0;
• user transfer of IDs/results = 0;
• manual worker interaction = 0.

G4 — recover one worker

Close/kill exactly one managed carrier. runtime_recover must restore the same logical worker from its persisted exact conversation mapping; the two healthy workers remain untouched. Any unresolved task effect remains RECONCILE_REQUIRED.

G5 — elastic scale

Prove 3 -> 5 -> 2. Busy/current-task, targeted-queued, continuation-pending, or reconciliation-required workers must not be evicted. No duplicate worker IDs, task/result loss, or manual window management.

G6 — restart/cold ensure

Restart DevSpace and/or close managed worker carriers. From Main, one runtime_ensure(desiredWorkers=<target>) must run a fresh per-boot ENSURE_EXISTING physical check and reconstruct/revalidate the desired pool from durable secret-free mappings without recreating task truth or asking the Owner to relabel/rejoin workers.

Final interaction budget

All must be zero after one-time environment setup:

• manual worker window creation
• manual worker dev-c selection
• manual join/invite transfer
• manual workerId/taskId transfer
• manual worker wake
• manual worker result relay

Only after G0 + G2 + G3 + G4 + G5 + G6 pass on the exact installed build may #117 close with:
MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS

Current exact blocker from this controller conversation: NATIVE_MAC_BROWSER_DEV_C_WITNESS_REQUIRED — this conversation exposes GitHub but no DevSpace/dev-c MCP/browser-control connector, and Plugin Directory discovery returned no DevSpace integration. This is a physical acceptance boundary, not a remaining source-design gate.

[James3014]

2026-09-13 live acceptance rebind — source/build current, conversation tool schema stale

Fresh physical evidence from the connected DevSpace control plane:

• dev2 current server identity:
  • sourceCommit = da4be27769c72e42ec24882145d8a84a804a4999
  • buildId = devspace-1.0.7-da4be277
  • serverInstanceId = cbad1224-d199-432d-9858-b06596839f85
  • capabilityManifestSha256 = b5af10e4e4af21cd735a094c3cd0afb31320ea0f473c0819148aa5248bf2c718
  • mode = normal
  • reconciliationRequired = false
• Current source at the exact same da4be277... revision confirms:
  • chatSwarmToolInputShapes() includes ...chatSwarmRuntimeToolInputShapes(config);
  • production server.ts passes the full config into registerChatSwarmTools(...);
  • when stateDir is present, runtime manager/tool registration is the intended production path.
• However, this long-lived ChatGPT conversation still exposes only the pre-P0: implement macOS zero-touch ChatGPT worker runtime pool #117 Chat Swarm tool schema (15 core swarm tools); the 6 chat_swarm_runtime_* tools are not callable from this conversation even though the connected server/build identity is current.

Disposition:

CONVERSATION_TOOL_SCHEMA_REFRESH_REQUIRED

This is not evidence of a #117 source-registration defect and must not reopen G1. The current conversation's connector/tool schema is a stale client-side capability snapshot relative to the already-loaded da4be277... server.

Next native gate:

1. establish a fresh ChatGPT conversation / refreshed DevSpace connector handshake against this same dev2 instance;
2. first verify the host-visible tool catalog contains the six P0: implement macOS zero-touch ChatGPT worker runtime pool #117 runtime tools;
3. then execute G0/G2-G6 from the existing native closure manifest without source mutation;
4. if a fresh handshake still omits the runtime tools, reclassify as a real capability-manifest/runtime-registration defect and return to source.

No G2-G6 PASS is claimed from this observation.

[James3014]

G2 blocker reconciliation — blocked by #15 host catalog projection/rebind

Fresh G2 retry result:

#117 G2 BLOCKED — CHATGPT_APP_CATALOG_NOT_REBOUND

The failure is before Swarm selection/create and before any chat_swarm_runtime_ensure effect.

Bound runtime

• canonical production: devspace / 7677
• sourceCommit: 74c4d623b57117f27968e980427979cf73827c63
• buildId: devspace-1.0.7-74c4d623
• serverInstanceId: 7C4F66DE-651A-4200-83CC-AA3968E392E2
• capabilityManifestSha256: 079cae0c77156f9b5917809c3e1e4f6fc60b12d26b727053f8a6299f66fffb51

Exact blocker

Canonical server publication contains the required chat_swarm_runtime_* capability surface, but the current Main ChatGPT canonical app projection exposes 0/6 required runtime actions. Historical Chat Swarm declarations under retired dev-c are not an allowed substitute; 7678 remains retired/unreachable.

This is now durably owned by #15 G2 (Host discovery/binding reliability), including the explicit convergence chain:

server tools/list
-> workspace-approved / host-admitted action snapshot
-> conversation-visible catalog
-> invocation witness

#117 frontier

#117 G2 is a downstream consumer and must not repair/bypass this inside the worker-runtime implementation.

Hard prerequisite to resume G2:

canonical devspace server: 6/6 chat_swarm_runtime_*
-> canonical ChatGPT host action projection: 6/6
-> fresh Main: 6/6 visible and callable
-> exact calls bind to the current canonical 7677 generation

Until that is proven:

• do not invoke runtime_ensure;
• do not revive/reuse 7678;
• do not route via retired dev-c;
• do not alter P0: implement macOS zero-touch ChatGPT worker runtime pool #117 source merely to bypass host projection;
• do not start G3-G6.

Latest blocked attempt created:

• ensure effects: 0
• new workers: 0
• new carriers: 0
• unresolved effects: 0
• manualWorkerInteractionCount: 0

Disposition: #117 KEEP_OPEN — G2 BLOCKED_BY #15 HOST_CATALOG_PROJECTION_REBIND.

Resume only after #15 supplies the fresh unlock witness above.

[James3014]

2026-09-15 controller handoff — #117 zero-touch macOS ChatGPT worker runtime

This comment preserves the current conversation's durable continuation state. It is a handoff/update, not a claim that #117 is complete.

Current source / production watermark

• devspace/main: 80f4aaff91a34ae11857663348be27a60efb49bd
• tree: 8e9c4ad8d6182076fc719c675f44907bd9b32e2b
• merged PR fix: harden ChatGPT carrier admission #155: fix: harden ChatGPT carrier admission
• production build observed: devspace-1.0.7-80f4aaff
• production server observed: 7C4F66DE-651A-4200-83CC-AA3968E392E2
• production capability manifest observed: 079cae0c77156f9b5917809c3e1e4f6fc60b12d26b727053f8a6299f66fffb51
• cutover mode: normal
• reconciliationRequired=false

These are snapshot facts; rebind before the next mutation.

Settled architecture / do-not-rediscover

1. Current ChatGPT MCP/App name is dev. Do not use historical devspace / dev-c in generated bootstrap prompts. PR fix: harden ChatGPT carrier admission #155 changed the source fallback to dev while preserving env override support.
2. OpenCLI is the primary macOS ChatGPT carrier transport. Use ephemeral + --wait false + exact conversationId; raw CDP remains lifecycle/fallback only. Do not move Chat Swarm authority into OpenCLI or nexus-open-swe-runtime.
3. Dual identity is intentional: transport conversation identity/fingerprint is for carrier addressing; authenticated MCP peer fingerprint is for admission/worker authority. They are not derivable from each other and must not be collapsed.
4. OUTCOME_UNKNOWN != retry permission. Timeout/lost ack requires exact durable/readback reconciliation before any second external effect.
5. UI/model text is not completion truth. Durable Swarm worker/task/operation/result state is the oracle.
6. Low-frequency live testing is required. Same-account host safety/rate behavior is material. Do not burst repeated diagnostic workers or retry safety blocks immediately.
7. PR fix: harden ChatGPT carrier admission #155 hardening is canonical: minimal @dev peer/bootstrap/wake prompts + first-uncertain fail-fast. In ensure(N), once a new carrier enters RECONCILE_REQUIRED/outcome_unknown, the current ensure stops creating further ChatGPT mutations.
8. Do not revive old raw-CDP primary work. It previously hit hidden textarea selection, send-click false positive, conversation identity/readback ambiguity, and UI-vs-remote-effect mismatch.
9. PR test: reproduce runtime bootstrap lease expiry #152 is superseded draft evidence, not a merge candidate. Current main already contains a different lifecycle lease fix; do not merge test: reproduce runtime bootstrap lease expiry #152 as-is.

Proven evidence from this conversation

• OpenCLI live transport can create a Project conversation, return exact conversationId, read it with detail, continue the same conversation, invoke canonical dev MCP, and reconcile a timeout via readback without blind resend.
• Manual-orchestrated feasibility proved 3 distinct OpenCLI ephemeral carrier conversations can map to 3 distinct authenticated worker identities and complete 3 targeted tasks, but that is transport feasibility only, not formal P0: implement macOS zero-touch ChatGPT worker runtime pool #117 G2/G3 acceptance.
• Earlier formal runtime_ensure work exposed and subsequently repaired:
  • raw-CDP send/readback defects;
  • MCP output schema mismatch for controlMechanism=OPENCLI;
  • browser conversation identity vs authenticated MCP peer identity mismatch;
  • provision/bootstrap lease timing mismatch;
  • wrong App label (devspace vs actual dev);
  • mutation amplification after first uncertain carrier.

Latest live accepted witness

Fresh one-worker canary after PR #155 / production convergence:

• swarm: swarm_745aefe15cec446f9870e7070ff7fa5b
• exactly one chat_swarm_runtime_ensure(..., desiredWorkers=1) call
• slot 1: PARKED
• worker: worker_448ad07419ae46a7bd766333f85737aa
• provision op: runtime_provision_93e1caf17bd947958bfc50f729de6d3b
• conversation: 6aa8bbc2-29d4-83ee-83bf-e7d66501922c
• owner-side durable readback showed worker AVAILABLE, pending joins 0, no task state, manual worker interaction 0
• transport fingerprint and authenticated peer fingerprint were distinct, as designed

Maximum live claim from that witness:

LOW_FREQUENCY_OPENCLI_ZERO_TOUCH_ENSURE_1_PASS

The predecessor swarm is owner-bound to its originating Main conversation. A new controller must not try to take it over; create a fresh Swarm for new live acceptance.

#117 gate state

• G0: mechanism largely proven (OpenCLI/project/exact conversation/reopen/dev invocation/multi-carrier/readback). Do not overclaim all hostile classifications closed.
• G1: primary source implementation is on current main.
• G2: NOT COMPLETE. Need fresh owner Swarm -> exactly one low-frequency runtime_ensure(3) -> 3 distinct PARKED workers, then an idempotency witness ensure(3) with 0 new workers/conversations.
• G3: NOT COMPLETE. Need 3 targeted tasks -> exact carrier wake -> worker next/execute/submit -> Main durable collect; manual relay/cross-worker/duplicate execution all 0.
• G4: NOT COMPLETE. Kill/close one managed carrier -> runtime_recover same logical worker, other healthy workers untouched.
• G5: NOT COMPLETE. Prove 3 -> 5 -> 2 without evicting busy/targeted/continuation/reconcile-required workers and without losing queued/result truth.
• G6: NOT COMPLETE. Restart DevSpace and/or close carriers -> one cold ensure reconstructs desired pool from durable mappings without manual rejoin/relabel or recreating task truth.

Only after G0-G6 exact live evidence may #117 claim:

MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS

Exact next live gate

DEVSPACE-117-G2-LOW-FREQUENCY

Arrival sequence for a fresh Main/controller:

1. Rebind devspace/main, P0: implement macOS zero-touch ChatGPT worker runtime pool #117/fix: harden ChatGPT carrier admission #155/test: reproduce runtime bootstrap lease expiry #152, and production runtime identity.
2. Run capability_convergence_status; current handoff observed the primary runtime converged but this request context reported RECONNECT_REQUIRED because no active session-generation snapshot was bound. Reconnect/rebind MCP catalog before consequential mutation.
3. Create a fresh owner-bound Swarm with capacity >=3.
4. Read runtime status.
5. Call exactly one runtime_ensure(desiredWorkers=3).
6. Read durable runtime/roster state only.
7. On any safety block, timeout, partial PARKED set, UNKNOWN, or RECONCILE_REQUIRED: STOP and reconcile; do not immediately retry.
8. If 3/3 PARKED, perform the idempotency witness only when host/rate conditions are calm.

Post-#117 roadmap (do not stop at G6)

#117 is the zero-touch worker-carrier substrate, not the final product goal.

After #117 acceptance, rebind the downstream Issues rather than assuming their current status:

• feat(chat-swarm): add durable worker continuity and conversation rollover #51 — stable worker identity with replaceable carrier, continuation epoch/ticket, bounded capsule, stale-carrier fence, then proactive Worker Auto Compact live witness.
• feat(continuity): add proactive Main ChatGPT checkpoint and conversation rollover #106 — proactive Main checkpoint/conversation rollover while preserving user intent, Swarm/task/attempt lineage, and supported target bind semantics.
• Epic: reconcile DevSpace Ultra parity for GPT peer swarm and conversation continuity #104 — final Ultra-style end-to-end parity closure using evidence from worker lifecycle, worker rollover, and Main rollover.

End-state UX remains: James interacts with Main only; DevSpace owns worker creation/recovery/scale/wake/continuation infrastructure, while durable Swarm truth remains canonical.

Handoff claim ceiling

Current safe claim:

LOW_FREQUENCY_OPENCLI_ZERO_TOUCH_ENSURE_1_PASS

Current execution frontier:

#117 G2 -> G3 -> G4 -> G5 -> G6 -> rebind #51/#106/#104

Do not treat this comment as mutation/merge/release authority or standing provider admission.

[James3014]

Closeout prerequisite reconciliation — do not skip #15 host catalog gate

This delta corrects one ambiguity in the immediately preceding controller handoff comment (issuecomment-5675135122).

Durable prerequisite still in force

#117 previously recorded:

G2 BLOCKED_BY #15 HOST_CATALOG_PROJECTION_REBIND

#15's latest host-projection contract requires the chain:

canonical server tools/list / manifest
-> canonical ChatGPT host-admitted action snapshot
-> fresh Main conversation action catalog
-> consequential invocation witness

with the required runtime actions exposed/callable through the canonical ChatGPT app.

What today's evidence changes — and what it does not

Today's accepted source/runtime evidence is newer than the old #15 observation:

• current devspace/main and production are 80f4aaff91a34ae11857663348be27a60efb49bd / devspace-1.0.7-80f4aaff;
• the canonical ChatGPT App/MCP name is dev;
• the current connector surface in this conversation exposes the six runtime actions (chat_swarm_runtime_status/ensure/scale/recover/stop/bootstrap);
• a fresh low-frequency one-worker runtime_ensure(1) completed zero-touch to PARKED, proving at least one consequential current-generation runtime invocation path works.

However, the current request context subsequently reported sessionConvergence.state=RECONNECT_REQUIRED because no active session-generation snapshot was bound. Therefore the previous #15 requirement for a fresh post-rebind host-action projection witness must not be silently treated as closed by the one-worker canary.

#30 (promotion/runtime lineage drift) is currently closed/completed, so the remaining consumer gate is not "repair #30 again"; it is to rebind the current host/session catalog against the current canonical generation and verify the required #117 runtime actions are present/callable.

Correct next sequence for a new controller

Before a new #117 G2 mutation:

1. Rebind current main / production source-build-manifest identity.
2. Reconnect/rebind the dev MCP session/catalog generation if RECONNECT_REQUIRED.
3. Verify the current canonical dev host surface exposes the six P0: implement macOS zero-touch ChatGPT worker runtime pool #117 runtime actions and at least one stable read-only runtime action is callable against the same generation. Reuse/read Harden Dev MCP reliability across host binding, worker startup, and timeout reconciliation #15's existing G2 contract; do not create another catalog authority.
4. If that projection witness is current, classify the old Harden Dev MCP reliability across host binding, worker startup, and timeout reconciliation #15 prerequisite as PRESERVED_AND_SATISFIED_FOR_THIS_GENERATION and proceed to a fresh owner-bound Swarm for low-frequency P0: implement macOS zero-touch ChatGPT worker runtime pool #117 G2.
5. If the catalog is stale/incomplete/un-callable, stop with CAPABILITY_OR_TRANSPORT_BLOCKED; do not call runtime_ensure and do not fall back to retired 7678/dev-c.

This delta does not revoke the valid LOW_FREQUENCY_OPENCLI_ZERO_TOUCH_ENSURE_1_PASS evidence. It only prevents that narrower witness from being promoted into a blanket #15 host-catalog closure.

Current next gate:

HANDOFF_REBASE -> #15 HOST_CATALOG_PROJECTION_REBIND -> #117 G2 LOW_FREQUENCY

No worker/runtime mutation was performed by this closeout delta.

[James3014]

2026-09-16 fresh native acceptance checkpoint — 7677 catalog converged, G2 blocked at Browser Bridge preflight

Fresh physical readback from the currently authoritative DevSpace production connector:

serverInstanceId = 7C4F66DE-651A-4200-83CC-AA3968E392E2
sourceCommit     = 9e83ad5844ff55d32f495e8aded5a36e8ad91c07
buildId          = devspace-1.0.7-9e83ad58
capabilityManifestSha256 = 573adbf44929ea46ff88749f78e4e8ac8c612932165690828adedd33bcd71082
cutoverMode      = normal
reconciliationRequired = false

Fresh schema discovery in this controller exposed:

• all 15 standard chat_swarm_* tools;
• all 6 chat_swarm_runtime_* tools;
• capability_convergence_status;
• chat_swarm_create.workerLimit max = 16;
• runtime_scale.desiredWorkers max = 16.

capability_convergence_status additionally showed:

multiRoleConvergence.authoritativeRole = primary
multiRoleConvergence.converged = true
nonAuthoritativeRoles = []

and the old migration source is RETIRED_READ_ONLY with routing/OAuth/runtime-owner authority released. A stale topology-manifest freshness attestation remains for retirement bookkeeping, but it is not the runtime-authority blocker for #117.

A fresh #117 Owner swarm was created:

swarmId = swarm_a6e457de4a7a41f987d38c16e97e3eca
workerLimit = 5

First native runtime preflight result:

state = CONFIGURED_NOT_READY
enabled = true
desiredDefault = 5
maxWorkers = 16
adapter.kind = mac_web_chatgpt
adapter.controlMechanism = OPENCLI
adapter.projectConfigured = true
adapter.appBinding = UNKNOWN
blocker.code = BROWSER_CONNECT
blocker.message = Browser Bridge extension not connected
slots = []

Important correction: no chat_swarm_runtime_ensure(3) mutation was actually issued in this checkpoint. The controller performed two read-only runtime_status probes only. Therefore there is no ambiguous provisioning effect and no reconciliation obligation from this checkpoint.

After this probe, the DevSpace connector namespace disappeared from the current ChatGPT session tool registry, so the controller cannot continue native G2 from this session until the exact connector/session is reattached.

Current exact next gate:

ONE_TIME_ENVIRONMENT_SETUP
-> Browser Bridge extension connected + healthy ChatGPT login
-> DevSpace connector reattached / fresh tools
-> runtime_status == READY (or equivalent healthy state)
-> runtime_ensure(swarm_a6e457de4a7a41f987d38c16e97e3eca, desiredWorkers=3)
-> replay ensure(3) => +0 worker / +0 carrier

This remains an allowed one-time setup boundary under #117. Do not downgrade to manual worker-window creation, manual join, or manual ID/result relay.

Disposition:

G1 = PRESERVED
G2 = STARTED / PRE-MUTATION BLOCKED
G3-G6 = NOT_STARTED
MACOS_ZERO_TOUCH_CHATGPT_WORKER_RUNTIME_CANARY_PASS = NOT YET CLAIMABLE