Context
Operator follow-up on the merged onboarding conductor (PR #14965): the FM registry + cockpit UI offer five harness families (claude-code, claude-desktop, codex, antigravity, native-neo), but the launch seam (deriveHarnessLaunchSpec, PR #14918) templates only TWO (claude-code, codex) — and the conductor's CURATED_HARNESS_TYPES mirrors that subset. Selecting claude-desktop or antigravity in the UI today dead-ends at resolveLaunch's "no launch template" refusal. Unticketed gap until now (live sweep 2026-07-10T13:35Z: no equivalent open ticket; #13796 is the adjacent generic-adapter philosophy, not this coverage gap).
The 2026 reality sharpens it: Claude Desktop bundles Claude Code — the operator's live manual workflow is open -n -a Claude --args --user-data-dir=~/.claude-instances/<peer>, i.e. real peers ALREADY run under claude-desktop, just unsupervised and outside the FM.
The Problem
PR #14918 deliberately excluded GUI launches from the supervised class ("open detaches, so FM could never supervise the actual harness — only directly-spawnable CLI binaries are templated") — a reviewed, sound decision for the SUPERVISED lifecycle. But two of the five registry families are GUI-first, so the exclusion leaves them permanently unlaunchable by the FM, while the UI keeps offering them. Either they get a launch path or the UI/registry must surface the honest "not launchable yet" state.
The Fix (ordered — cheapest truth first)
- Bundled-binary probe (do this before any design work): this session's precedent is load-bearing — the codex CLI ships INSIDE
ChatGPT.app/Contents/Resources/codex and is directly spawnable + supervisable. Probe Claude.app and the Antigravity app bundle for equivalent directly-spawnable entrypoints (with per-instance home/profile env or flags). If found → extend HARNESS_HOME_ENV_VARS/HARNESS_MODE_ARGS templates exactly like #14918's two families (long-lived mode args, held-stdin liveness probe on the exact binaries) + widen the conductor's CURATED_HARNESS_TYPES. Done, no new lifecycle class.
- If (and only if) a family is GUI-only: design the detached launch class explicitly —
open -n -a <App> --args --user-data-dir=<instance home>, with honest supervision semantics: state: 'detached' (never running), no pid/stop/isRunning claims, authRequired unknown. This REVISES the #14918 exclusion for a distinct class rather than weakening the supervised one — @neo-gpt authored that exclusion's review rationale and gets the design loop-in before implementation.
Vocabulary honesty in the cockpit MOVED → #14987 (see Rescope below).native-neo disposition: explicitly defer (it is the future in-engine harness, not a launchable binary today) — one sentence in the template JSDoc so the gap is named, not silent.
Rescope (2026-07-10 — from the PR #14977 cross-family review close-target audit)
This ticket is now the fully-delivered Brain-side launch-coverage leaf: probe receipts, both app-bundle templates (argv-isolation axis + per-family version-probe policy + in-app auth mode), conductor widening, native-neo deferral. The probe falsified the detached-class premise (both bundles expose directly-spawnable MAIN binaries — fix-step 2 is a documented negative, no class built).
The original fix-step 3 / AC-3 second half — cockpit/projection honest-launchability rendering — moves to its named successor leaf #14987 (projection launchability enrichment: launchable + authMode on the registry/roster projections, self-assigned, consumer: the #13015 start-from-UI control). Per the seam ruling (@neo-opus-vega): launchability is Brain-side runtime truth riding the projection, never a flag in the shared display seam.
Contract Ledger
| Target Surface |
Source of Authority |
Proposed Behavior |
Fallback |
Docs |
Evidence |
deriveHarnessLaunchSpec templates |
the #14918 curated-intent design + exact-binary liveness probes |
new families added ONLY with probed long-lived spawn tuples |
un-probed family stays refused with the named setLaunchOverride pointer |
template JSDoc |
held-stdin liveness probes on the exact bundled binaries |
| detached class (conditional) |
this ticket's design loop-in (@neo-gpt) |
state: 'detached', no supervision claims |
not built unless a family is proven GUI-only |
lifecycle JSDoc |
live detached-launch receipt |
conductor CURATED_HARNESS_TYPES |
subset-of-templated invariant (documented in onboardPeer.mjs) |
widens in lockstep with the template table |
early named refusal (current behavior) |
conductor JSDoc |
spec update |
Acceptance Criteria
Out of Scope
The generic-by-default adapter refactor (#13796 — this ticket adds coverage inside today's per-family shape); cockpit Add-Peer UI implementation (#14807, consumes the widened vocabulary); projection/cockpit launchability rendering (#14987, the named successor).
Related
Parent: #13015 · launch seam: #14914 (PR #14918) · conductor: #14937 (PR #14965, merged) · UI honesty precedent: #14643 (PR #14952) · adjacent philosophy: #13796 · successor: #14987.
Live latest-open sweep: antigravity / claude-desktop harness / launch template harness searches at 2026-07-10T13:35Z — no equivalent found.
Origin Session ID: b956ba53-01ed-4ea6-a1e5-62969f887bc3
Retrieval Hint: query_raw_memories("fleet launch coverage claude-desktop antigravity bundled binary probe detached GUI class")
Context
Operator follow-up on the merged onboarding conductor (PR #14965): the FM registry + cockpit UI offer five harness families (
claude-code,claude-desktop,codex,antigravity,native-neo), but the launch seam (deriveHarnessLaunchSpec, PR #14918) templates only TWO (claude-code,codex) — and the conductor'sCURATED_HARNESS_TYPESmirrors that subset. Selectingclaude-desktoporantigravityin the UI today dead-ends atresolveLaunch's "no launch template" refusal. Unticketed gap until now (live sweep 2026-07-10T13:35Z: no equivalent open ticket; #13796 is the adjacent generic-adapter philosophy, not this coverage gap).The 2026 reality sharpens it: Claude Desktop bundles Claude Code — the operator's live manual workflow is
open -n -a Claude --args --user-data-dir=~/.claude-instances/<peer>, i.e. real peers ALREADY run under claude-desktop, just unsupervised and outside the FM.The Problem
PR #14918 deliberately excluded GUI launches from the supervised class ("
opendetaches, so FM could never supervise the actual harness — only directly-spawnable CLI binaries are templated") — a reviewed, sound decision for the SUPERVISED lifecycle. But two of the five registry families are GUI-first, so the exclusion leaves them permanently unlaunchable by the FM, while the UI keeps offering them. Either they get a launch path or the UI/registry must surface the honest "not launchable yet" state.The Fix (ordered — cheapest truth first)
ChatGPT.app/Contents/Resources/codexand is directly spawnable + supervisable. ProbeClaude.appand the Antigravity app bundle for equivalent directly-spawnable entrypoints (with per-instance home/profile env or flags). If found → extendHARNESS_HOME_ENV_VARS/HARNESS_MODE_ARGStemplates exactly like #14918's two families (long-lived mode args, held-stdin liveness probe on the exact binaries) + widen the conductor'sCURATED_HARNESS_TYPES. Done, no new lifecycle class.open -n -a <App> --args --user-data-dir=<instance home>, with honest supervision semantics:state: 'detached'(neverrunning), no pid/stop/isRunning claims,authRequiredunknown. This REVISES the #14918 exclusion for a distinct class rather than weakening the supervised one — @neo-gpt authored that exclusion's review rationale and gets the design loop-in before implementation.Vocabulary honesty in the cockpitMOVED → #14987 (see Rescope below).native-neodisposition: explicitly defer (it is the future in-engine harness, not a launchable binary today) — one sentence in the template JSDoc so the gap is named, not silent.Rescope (2026-07-10 — from the PR #14977 cross-family review close-target audit)
This ticket is now the fully-delivered Brain-side launch-coverage leaf: probe receipts, both app-bundle templates (argv-isolation axis + per-family version-probe policy + in-app auth mode), conductor widening,
native-neodeferral. The probe falsified the detached-class premise (both bundles expose directly-spawnable MAIN binaries — fix-step 2 is a documented negative, no class built).The original fix-step 3 / AC-3 second half — cockpit/projection honest-launchability rendering — moves to its named successor leaf #14987 (projection launchability enrichment:
launchable+authModeon the registry/roster projections, self-assigned, consumer: the #13015 start-from-UI control). Per the seam ruling (@neo-opus-vega): launchability is Brain-side runtime truth riding the projection, never a flag in the shared display seam.Contract Ledger
deriveHarnessLaunchSpectemplatessetLaunchOverridepointerstate: 'detached', no supervision claimsCURATED_HARNESS_TYPESonboardPeer.mjs)Acceptance Criteria
Claude.app+ Antigravity bundles (spawnable binary + per-instance isolation env/flag, or a documented negative)registry/UI honest-unlaunchable renderingMOVED → #14987native-neodeferral named in the template JSDocOut of Scope
The generic-by-default adapter refactor (#13796 — this ticket adds coverage inside today's per-family shape); cockpit Add-Peer UI implementation (#14807, consumes the widened vocabulary); projection/cockpit launchability rendering (#14987, the named successor).
Related
Parent: #13015 · launch seam: #14914 (PR #14918) · conductor: #14937 (PR #14965, merged) · UI honesty precedent: #14643 (PR #14952) · adjacent philosophy: #13796 · successor: #14987.
Live latest-open sweep:
antigravity/claude-desktop harness/launch template harnesssearches at 2026-07-10T13:35Z — no equivalent found.Origin Session ID: b956ba53-01ed-4ea6-a1e5-62969f887bc3
Retrieval Hint:
query_raw_memories("fleet launch coverage claude-desktop antigravity bundled binary probe detached GUI class")