Repository navigation
P0: Prevent live Dev MCP runtime lineage drift and capability regression #30
Description
Owner scope amendment — macOS only (2026-09-11)
依 Owner 最新裁決,本工作線相關功能設計、實作、交付與驗收 只處理 macOS。本裁決取代下文較早的跨平台/三平台要求。
- Windows、Linux 支援、移植、修復與平台驗證不在本次工作範圍;不再以三平台全綠作為本工作線的 acceptance criterion。
- 驗收保留 macOS 上必要的 source tests、獨立 package/install、真實呼叫入口、operation/副作用/讀回及適用的恢復與終態證據;ownership、lease、CAS、安全與獨立審查要求保持有效。
- 下方歷史測試、PR、平台結果與問題紀錄保留作為歷史證據,不代表目前仍有跨平台交付承諾。後續設計及驗收計畫以此 macOS-only 範圍為準。
- 本次更新僅修正 Issue 與規劃範圍;實作、部署與重啟仍依 Owner 的暫停指令保持暫停。
- 此文字更新不會自行修改 GitHub CI 設定或 branch protection;既有檢查設定如與新範圍不符,須另行明確調整,不得假稱已通過或繞過保護。
Status
READY_NOW for bounded implementation after fresh source/runtime rebind.
Priority
P0 — current live runtime is not the canonical main lineage and has already regressed previously verified MCP capability.
Fresh evidence boundary — 2026-09-03
- GitHub
James3014/devspacedefault branch:main - observed
mainHEAD:458bb443f7c983dccd89b1b8428e9bd22004eb9c - observed live Dev MCP source/build:
1f6268137e2fd406a57c4a7a01a3eeca734ed9fd/devspace-1.0.7-1f626813 mainand live source are diverged, not one linear promotion lineage.maincontains the G9 Nexus execution-grant bridge via24cfc855... -> 5212252... -> 458bb443....- the current live
1f626813...recovery-staging lineage was created from an older base and does not expose the previously verifiedagent_start.authorityMode/nexusGrantseam.
This means the historical G9/G10 verification was real, but a later recovery deployment replaced the live runtime with a branch that did not preserve all loaded capabilities.
Goal
Make Dev MCP deployment/promotion fail closed when a candidate does not descend from, or explicitly preserve, the currently canonical/live capability lineage.
A recovery task must never be able to stage and activate an older-base runtime that silently removes capabilities already verified and promoted.
Required behavior
- Bind every promotion/cutover to exact candidate commit, canonical remote/main commit, current live source/build/server instance, and capability/schema fingerprint.
- Reject promotion when the candidate is based on a stale/diverged ancestor unless an explicit reconciliation proves preservation of all currently loaded required capabilities.
- Add a machine-checkable loaded-capability/schema manifest or equivalent fingerprint sufficient to detect removal of
agent_startcontract fields/actions across promotion. - Recovery staging must branch/rebase from the current canonical lineage rather than from a historical implementation base.
- Post-cutover verification must compare source, installed artifact, live server identity, and host-visible tool/schema identity before declaring success.
- A deployment that removes a previously required MCP action/schema field must require an explicit contract delta, not happen as an incidental recovery effect.
Acceptance criteria
- reproduce the current
458bb443...vs1f626813...divergence and demonstrate the old promotion path would have allowed the regression; - add a negative test that rejects a stale/diverged candidate which omits a currently required tool/schema capability;
- add a positive test for a recovery candidate based on current canonical main with preserved capabilities;
- verify the promoted live runtime exposes the expected current
agent_startauthority contract after repair; - exact source/build/server-instance/tool-schema evidence is captured post-cutover;
- no generic shell/deployment authority is added.
Non-goals
- redesigning Nexus authority semantics;
- changing G9/G10 contracts themselves;
- broadening recovery manager permissions;
- treating GitHub branch ancestry alone as sufficient if artifact/schema preservation is not proven.
Relationship
Follow-up/focused child of #15. This Issue owns promotion lineage and loaded-capability preservation only.
Claim ceiling
Until post-cutover verification passes, only claim: promotion-lineage repair implemented/candidate verified; do not claim live Dev MCP reliability restored.
Activity
James3014 commentedon Sep 3, 2026
Source integration receipt — runtime closure still pending
3ec38efefb3c752a1c870623f348a8e5bf9d528e..4c764fae999583368443af1f6c6e3dc0731cad8d35a955e90bb7722e53e8e80538e585c21d90b837NO_BLOCKING_FINDINGS.mainis now merge commitb84c2f4ea6c4b54e101ee6e138c6c67666151492.35a955e90bb7722e53e8e80538e585c21d90b837, identical to the independently accepted Candidate tree. Therefore the merge introduced no source-byte delta relative to the accepted Candidate.b84c2f4e...; do not claim post-merge CI evidence that does not exist.Current claim: #30 source repair is integrated on canonical main with tree-equivalence to the accepted Candidate.
Still unproven: loaded live Dev MCP source/build/server-instance/tool-schema identity after controlled cutover.
Issue remains open by design until that runtime gate passes.
James3014 commentedon Sep 4, 2026
Source-complete / live-verification pending — 2026-09-04
Current canonical
mainisf36bade85002ca253808f4641a122543823ed358(tree73b3b75cf4cfe4c04872518c47cb83a841c1c407). PR #39 merged the promotion-lineage repair; the later R4–R6 stack preserved that source tree lineage and passed fresh post-merge acceptance from a clean clone, including the capability-manifest/schema witnesses, server suite, typecheck, and production build.The live service on
127.0.0.1:7677is stillsourceCommit=1f6268137e2fd406a57c4a7a01a3eeca734ed9fd,buildId=devspace-1.0.7-1f626813, so the Issue's own post-cutover acceptance criterion has not yet been satisfied. R8 is now the exact next gate: activate an accepted current-main artifact through a controlled cutover, then re-read source/build/server-instance/capability evidence from the loaded runtime.Do not close #30 yet. Maximum current claim remains
promotion-lineage repair implemented and current source accepted; live lineage restoration is pending R8.James3014 commentedon Sep 4, 2026
2026-09-04 live runtime / host-schema reconciliation
Fresh evidence changes the remaining #30 gap materially.
Canonical source
main:296a3066fc620169f23beeeb5c9c41d9c9370d754d47c8e5e58b8302c076c1b97c990c4005b11843Loaded Dev MCP runtime
Fresh
open_workspacefrom the currently connected ChatGPT Dev MCP reports:serverInstanceId=b5a25a86-30d7-4bce-bd10-1c7e417cc025buildId=devspace-1.0.7-296a3066sourceCommit=296a3066fc620169f23beeeb5c9c41d9c9370d75Therefore the earlier
mainvs loaded-runtime source drift is no longer the current blocker: source/build identity now binds to canonical main.Remaining mismatch: ChatGPT host-visible tool schema
Fresh ChatGPT-side Dev MCP tool discovery still exposes an older
agent_start.executionContractsurface. In particular the host-visible schema currently lacks source-defined fields such as:authorityModenexusGrantidleTimeoutModeand still describes
idleTimeoutMsusing the older observational/non-enforced wording.But canonical
src/server.tsat exact296a3066...registers:authorityMode: OWNER_DIRECT | NEXUS_GOVERNEDnexusGrantidleTimeoutMode: EXPLICIT_OVERRIDEidleTimeoutMsas an explicit hard no-provider-activity override requiringidleTimeoutMode=EXPLICIT_OVERRIDEThis means the current remaining #30 problem is now narrowed to host action/tool-schema binding freshness, not another source implementation or backend deployment repair.
Current disposition
#30 = KEEP_OPEN / HOST_SCHEMA_REFRESH_AND_BINDING_CLOSURE_REQUIREDExact next gate
agent_startschema contains the exact required current fields/descriptions from296a3066....Do not redeploy or rewrite the already-current backend merely to fix a host catalog/cache problem unless fresh evidence proves the loaded server moved again.
James3014 commentedon Sep 4, 2026
2026-09-04 host-catalog closure path confirmed from current OpenAI Business docs
Current OpenAI documentation confirms the remaining behavior is a ChatGPT workspace app snapshot issue, not a DevSpace backend behavior to repair:
Refreshaction-control path, but that must not be assumed available on Business.Official reference (checked 2026-09-04):
https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt-beta
This exactly matches the current physical evidence: loaded Dev MCP source/build is
296a3066..., while this ChatGPT binding still exposes an older frozenagent_startschema.Execution boundary reached in this controller
The connected ChatGPT tool surface available to this conversation does not expose a supported action to recreate/republish the current Business custom MCP app snapshot. Plugin-management discovery found a user-scoped directory entry named
DevSpace Local ngrok Canary, but it is not proven to be the exact currently bound Dev MCP app and must not be installed/replaced automatically as a workaround.Therefore do not redeploy DevSpace, modify
server.ts, or install a similarly named app to solve #30.Exact remaining owner/admin action
On ChatGPT web as Business admin/owner:
agent_startcontract matches296a3066..., includingauthorityMode,nexusGrant,idleTimeoutMode, and current enforced-idle description;open_workspaceruntime identity and capability evidence before closing P0: Prevent live Dev MCP runtime lineage drift and capability regression #30.Disposition
#30 = BLOCKED_ON_CHATGPT_BUSINESS_ADMIN_REPUBLISH.Backend source/runtime convergence is already proven for the currently loaded Dev MCP; only the frozen ChatGPT app/tool snapshot remains unresolved.
James3014 commentedon Sep 4, 2026
Reconciliation — remaining closure is host-schema binding, not source implementation (2026-09-04)
Current canonical
main:296a3066fc620169f23beeeb5c9c41d9c9370d75/ tree4d47c8e5e58b8302c076c1b97c990c4005b11843.Fresh prior runtime evidence already narrowed #30: loaded Dev MCP source/build matched canonical
296a3066..., but ChatGPT host-visibleagent_startschema still lagged source and omitted current fields such asauthorityMode,nexusGrant, andidleTimeoutModewhile retaining stale idle-timeout wording.Current classification
KEEP_OPEN — HOST_SCHEMA_REFRESH_AND_BINDING_CLOSURE_REQUIREDParallel prerequisite / coordination
Remaining acceptance
agent_startschema contains the exact current source-required authority and idle-policy fields/descriptions.Terminal condition
Close #30 only when host-visible schema freshness and backend source/build/server/capability identity agree on the same current runtime generation.
Future work for this gap must begin from #30. Do not create chat-only replacement gates or redeployments without reconciling this Issue first.
James3014 commentedon Sep 4, 2026
Host-schema freshness — server-side gap closed (R8 cutover)
Bindings captured live from the loaded runtime via MCP
tools/list(127.0.0.1:7677):b5a25a86-30d7-4bce-bd10-1c7e417cc025, sourceCommit296a3066, buildIddevspace-1.0.7-296a3066, capabilityManifestSha256b2968680...The host-visible
agent_starttool now exposes the full expected transport contract:authorityModeenum["OWNER_DIRECT","NEXUS_GOVERNED"]✅nexusGrantstructured object,repositoryconstJames3014/Nexus-new✅idleTimeoutModeconst"EXPLICIT_OVERRIDE"✅idleTimeoutMsenforced wording ✅Raw tools/list capture saved to evidence:
R8_HOST_SCHEMA_TOOLS_LIST_RAW.jsonl(campaign dirr8-r10-cutover-20260904), plusR8_HOST_SCHEMA_FRESHNESS_RECEIPT.md.No DevSpace redeploy,
server.tsedit, or app re-install performed for this portion (per issue constraint). The only remaining host-visible item is the ChatGPT Business frozen admin-side app snapshot — a ChatGPT Business publisher action (recreate/republish the custom MCP app) not reachable from the DevSpace backend.James3014 commentedon Sep 8, 2026
Fresh P0 host-schema/backend mismatch — 2026-09-08
Same-contract evidence; keep #30 open. This is NOT a claim that the historical #31 cutover failed, and #31 remains closed/completed.
Bound identity: GitHub main and Dev MCP build receipt both name
e9942d2a598866e8f8c091304b1700065791091c/devspace-1.0.7-e9942d2a; observed server0e2be1ab-a4b3-482b-a78a-ade05f58b96d.ChatGPT's discovered
dev.agent_preflightschema advertises optional profile OR direct provider/model/effort. Actual read-only call with{workspaceId, provider:'opencode', model:'opencode/muse-spark-1.3-contributor-free'}returns:MCP error -32602: Input validation error: Invalid arguments for tool agent_preflight: Invalid input: expected string, received undefined at profileA profile-based preflight for
opencode-mimo-free-implementsucceeds and correctly reports dispatchState UNKNOWN, authReady/providerReachable unknown, local capacity 0/4. Thus this is reproducible contract mismatch before model dispatch, not model quality, quota or authentication evidence.Canonical
src/server.tsat e9942d2 requires profile in agent_preflight (around 3464). The existing dirty shared checkout has direct dispatch schema/handlers, among a mixed 15-file diff spanning durable recovery and local agents. No open PR was returned by current GitHub PR search. Those dirty bytes were inspected read-only, not consumed, reverted, staged or deployed.Required bounded next gate:
Dependencies: #58 owns OpenCode catalog truth/freshness; source work may proceed independently but live claims require this gate. Do not infer all providers enabled: this runtime advertises only OpenCode and Cline as configured, while Agy/Codex/OMP profiles report provider_disabled.
James3014 commentedon Sep 9, 2026
2026-09-09 接手更新:已安裝 ≠ 工具已投影 ≠ 原生可用
本次透過 plugin registry 實際確認
dev已安裝且 ENABLED;因此先前交接的「GPT 沒有安裝 Dev MCP」不是可繼續沿用的當前結論。但本對話對dev及 registry 回傳名稱做 action discovery 均無可呼叫 Dev namespace。只支持 installed-but-action-surface-unavailable,尚不能定位為 host cache、權限、endpoint、服務或模型故障;未執行原生 Dev action,不算功能驗收。GitHub fresh main 仍為 e9942d2;PR #60 head489ad06c、#61 head97fbefc0 仍 OPEN。兩個 exact heads 的 check-runs 均 total_count=0,PR-triggered workflow_runs 也為空;
mergeable=true不代表 CI 已過。Fork UI 未啟用是 handoff evidence,本次未重新操作 UI。最小下一步
Transport候選的主張限制
Handoff 回報45f52173四檔候選測試40/40且typecheck/diff-check通過,本次未讀回本機log。整合前綁定exact diff/base/tests,再以跨OAuth client借session被403、同client更新token可續用、unknown/pending-close拒絕做 production-path 驗證。OAuth client≠conversation;不重新發明要求上游簽章的身份方案。
總交付 route/next gates 見 #15 的
devspace-odw-replan-20260909-v1;#63是輸出流稽核,不是未經重現便加入的 deployment blocker。本次沒有啟用CI、merge、安裝、restart或執行native canary。James3014 commentedon Sep 11, 2026
2026-09-11 conversation reconciliation — keep runtime/deployment convergence owned here
A fresh audit of the DevSpace follow-up work found that the remaining approved-build → installed artifact → live runtime / host binding convergence concern is already within #30's ownership. Do not create a duplicate deployment/version-convergence Issue from the chat history.
Fresh repository watermark
James3014/devspacedefault branch:mainmain:d39dae00c0be4c21b505bd77821680786c02db286735dc0148b5b541fc6aca7de56c813c334442b4This comment does not assert that the live runtime is stale merely because
mainadvanced. Before any further deployment action, rebind and distinguish these separate identities:remoteMainacceptedDeployment/ approved deployment targetinstalledBuildrunningBuild+serverInstanceIdremote main != automatic deployment authorityremains the rule. A mismatch is only a defect after proving the accepted deployment target should have converged and did not.Required operational classification
Any continuation of #30 should resolve to one of:
INTENTIONALLY_PINNEDDEPLOYMENT_DRIFTACTIVATION_PENDINGHOST_BINDING_STALERECONCILIATION_REQUIREDCONVERGEDFor a real approved deployment, the target terminal evidence should be:
or one exact
BLOCKEDreason.Scope clarification
main.bfbf997elineage) is being tracked independently and must not be pushed into P0: Prevent live Dev MCP runtime lineage drift and capability regression #30 or used as a deployment source without reconciliation.This comment is a durable owner/coordination anchor for the conversation's runtime-convergence follow-up; #30 remains the canonical Issue for that concern.
feat(deployment): prevent runtime lineage drift and capability regres…
James3014 commentedon Sep 11, 2026
Delivery & Convergence Summary
Closed as completed via PR #103 (merged).
Summary of Improvements
src/deployment-convergence.ts):remoteMain,acceptedDeployment,installedBuild,runningBuild,hostBinding) into the 6 canonical states:INTENTIONALLY_PINNEDDEPLOYMENT_DRIFTACTIVATION_PENDINGHOST_BINDING_STALERECONCILIATION_REQUIREDCONVERGEDassertDeploymentCandidateValid):agent_start.executionContract.authorityMode,idleTimeoutMs,nexusGrant, etc.).458bb443vs1f626813divergence.src/deployment-convergence.test.tscovering all convergence states, negative candidate rejection, and positive canonical main acceptance.James3014 commentedon Oct 6, 2026
REGRESSION REOPEN — fresh #1452 loaded-runtime lineage/capability evidence (2026-10-06).
Current canonical DevSpace main:
6fe39fdd90305722b82fc688168e1da020a6a075Current JamesdeMac-mini.local launchd service source:
8e9afd80c0f93103cdda5947fe276fae4a5fa57eGit ancestry:
8e9afd80...is an ancestor of6fe39fdd...;Current ChatGPT callable mutation schemas are consistent with the old generation: write/edit/bash do not expose the merged resumable-work admission pointer. Therefore loaded runtime is stale and the newly required capability is physically absent from the live service.
This violates #30's post-cutover invariant that loaded source/build/tool schema preserve current canonical capability lineage. Reopen until the canonical cutover activates current main and exact loaded source/build/schema identity is read back. Do not use raw restart bypass.
James3014 commentedon Oct 6, 2026
CORRECTION — the 2026-10-06 #1452 evidence does not establish a canonical Dev MCP runtime-lineage regression.
The earlier
8e9afd80...readback came from a separate JamesdeMac-mini launchd service role observed through RDC. Fresh identity binding through the actually connectedmcp__dev.open_workspaceproves the current canonical Dev MCP serving this ChatGPT conversation is already:6fe39fdd90305722b82fc688168e1da020a6a075devspace-1.0.7-6fe39fdd70c249de-db7f-4bde-854a-5fceae2206f2That source contains the merged enrolled-repository admission implementation.
Fresh live negative canary on an enrolled #1418 worktree:
32f30f900dcec8294d12063f5199681b46566f0ecodex-gpt-5-6-sol-implementP0_WRITER_ADMISSION_FAILED: [NEXUS_ADMISSION_REQUIRED] ... requires a current resumableWork pointer ... before the first effect.Therefore loaded runtime admission capability is current and fail-closed. Remaining defect is outer ChatGPT tool projection (producer/consumer schema for resumable-work admission), owned by #163, not #30.