Skip to content

P0: Prevent live Dev MCP runtime lineage drift and capability regression #30

Closed

Description

@James3014

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/devspace default branch: main
  • observed main HEAD: 458bb443f7c983dccd89b1b8428e9bd22004eb9c
  • observed live Dev MCP source/build: 1f6268137e2fd406a57c4a7a01a3eeca734ed9fd / devspace-1.0.7-1f626813
  • main and live source are diverged, not one linear promotion lineage.
  • main contains the G9 Nexus execution-grant bridge via 24cfc855... -> 5212252... -> 458bb443....
  • the current live 1f626813... recovery-staging lineage was created from an older base and does not expose the previously verified agent_start.authorityMode / nexusGrant seam.

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

  1. Bind every promotion/cutover to exact candidate commit, canonical remote/main commit, current live source/build/server instance, and capability/schema fingerprint.
  2. Reject promotion when the candidate is based on a stale/diverged ancestor unless an explicit reconciliation proves preservation of all currently loaded required capabilities.
  3. Add a machine-checkable loaded-capability/schema manifest or equivalent fingerprint sufficient to detect removal of agent_start contract fields/actions across promotion.
  4. Recovery staging must branch/rebase from the current canonical lineage rather than from a historical implementation base.
  5. Post-cutover verification must compare source, installed artifact, live server identity, and host-visible tool/schema identity before declaring success.
  6. 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... vs 1f626813... 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_start authority 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

  1. James3014 commented on Sep 3, 2026

    @James3014
    OwnerAuthor

    Source integration receipt — runtime closure still pending

    • Accepted Candidate range: 3ec38efefb3c752a1c870623f348a8e5bf9d528e..4c764fae999583368443af1f6c6e3dc0731cad8d
    • Accepted final tree: 35a955e90bb7722e53e8e80538e585c21d90b837
    • Independent Candidate evidence: typecheck PASS; capability manifest 2/2; promotion integration 29/29 including stale identity/capability-unbound/remote-drift/non-default-upstream negatives; server 30/30; heartbeat adapter/ACP checks PASS; build + diff-check PASS; independent Agy NO_BLOCKING_FINDINGS.
    • Integrated by PR fix(git): bind promotion to canonical runtime lineage #38. Canonical main is now merge commit b84c2f4ea6c4b54e101ee6e138c6c67666151492.
    • The merge commit tree is exactly 35a955e90bb7722e53e8e80538e585c21d90b837, identical to the independently accepted Candidate tree. Therefore the merge introduced no source-byte delta relative to the accepted Candidate.
    • GitHub currently reports no workflow runs and no commit statuses for 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.

  2. James3014 commented on Sep 4, 2026

    @James3014
    OwnerAuthor

    Source-complete / live-verification pending — 2026-09-04

    Current canonical main is f36bade85002ca253808f4641a122543823ed358 (tree 73b3b75cf4cfe4c04872518c47cb83a841c1c407). 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:7677 is still sourceCommit=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.

  3. James3014 commented on Sep 4, 2026

    @James3014
    OwnerAuthor

    2026-09-04 live runtime / host-schema reconciliation

    Fresh evidence changes the remaining #30 gap materially.

    Canonical source

    • GitHub main: 296a3066fc620169f23beeeb5c9c41d9c9370d75
    • tree: 4d47c8e5e58b8302c076c1b97c990c4005b11843

    Loaded Dev MCP runtime

    Fresh open_workspace from the currently connected ChatGPT Dev MCP reports:

    • serverInstanceId=b5a25a86-30d7-4bce-bd10-1c7e417cc025
    • buildId=devspace-1.0.7-296a3066
    • sourceCommit=296a3066fc620169f23beeeb5c9c41d9c9370d75

    Therefore the earlier main vs 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.executionContract surface. In particular the host-visible schema currently lacks source-defined fields such as:

    • authorityMode
    • nexusGrant
    • idleTimeoutMode

    and still describes idleTimeoutMs using the older observational/non-enforced wording.

    But canonical src/server.ts at exact 296a3066... registers:

    • authorityMode: OWNER_DIRECT | NEXUS_GOVERNED
    • nexusGrant
    • idleTimeoutMode: EXPLICIT_OVERRIDE
    • idleTimeoutMs as an explicit hard no-provider-activity override requiring idleTimeoutMode=EXPLICIT_OVERRIDE

    This 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_REQUIRED

    Exact next gate

    1. Refresh/reconnect/republish the Dev MCP app/tool catalog on the ChatGPT host using the supported app lifecycle.
    2. Re-discover tools from a fresh ChatGPT binding.
    3. Prove host-visible agent_start schema contains the exact required current fields/descriptions from 296a3066....
    4. Reconfirm source/build/server-instance/capability-manifest identity after refresh.
    5. Only then close P0: Prevent live Dev MCP runtime lineage drift and capability regression #30.

    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.

  4. James3014 commented on Sep 4, 2026

    @James3014
    OwnerAuthor

    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:

    • after an MCP app is approved/published, ChatGPT uses a frozen snapshot of its tools and inputs;
    • later MCP server tool/schema changes do not automatically update that workspace snapshot;
    • on ChatGPT Business, published custom apps currently cannot be updated in place; changing tools/metadata requires recreating and republishing the app;
    • Enterprise/Edu have a Refresh action-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 frozen agent_start schema.

    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:

    1. recreate the DevSpace custom MCP app from the currently intended MCP endpoint/configuration;
    2. review the freshly discovered action/tool definitions;
    3. publish the recreated app;
    4. open a fresh ChatGPT chat/binding using that app;
    5. verify the host-visible agent_start contract matches 296a3066..., including authorityMode, nexusGrant, idleTimeoutMode, and current enforced-idle description;
    6. re-read open_workspace runtime 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.

  5. James3014 commented on Sep 4, 2026

    @James3014
    OwnerAuthor

    Reconciliation — remaining closure is host-schema binding, not source implementation (2026-09-04)

    Current canonical main: 296a3066fc620169f23beeeb5c9c41d9c9370d75 / tree 4d47c8e5e58b8302c076c1b97c990c4005b11843.

    Fresh prior runtime evidence already narrowed #30: loaded Dev MCP source/build matched canonical 296a3066..., but ChatGPT host-visible agent_start schema still lagged source and omitted current fields such as authorityMode, nexusGrant, and idleTimeoutMode while retaining stale idle-timeout wording.

    Current classification

    KEEP_OPEN — HOST_SCHEMA_REFRESH_AND_BINDING_CLOSURE_REQUIRED

    Parallel prerequisite / coordination

    Remaining acceptance

    1. Use the supported ChatGPT app/MCP lifecycle to refresh/reconnect/republish the Dev MCP tool catalog.
    2. From a fresh ChatGPT binding, re-discover the tool surface.
    3. Prove the host-visible agent_start schema contains the exact current source-required authority and idle-policy fields/descriptions.
    4. Re-read loaded source commit, build ID, server instance, and capability/schema identity after refresh.
    5. Prove host-visible tool/schema and loaded backend identity are attributable to the same current deployment.

    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.

  6. James3014 commented on Sep 4, 2026

    @James3014
    OwnerAuthor

    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):

    • server instance b5a25a86-30d7-4bce-bd10-1c7e417cc025, sourceCommit 296a3066, buildId devspace-1.0.7-296a3066, capabilityManifestSha256 b2968680...
    • /healthz: phase=closed, mode=normal

    The host-visible agent_start tool now exposes the full expected transport contract:

    • authorityMode enum ["OWNER_DIRECT","NEXUS_GOVERNED"] ✅
    • nexusGrant structured object, repository const James3014/Nexus-new ✅
    • idleTimeoutMode const "EXPLICIT_OVERRIDE" ✅
    • idleTimeoutMs enforced wording ✅

    Raw tools/list capture saved to evidence: R8_HOST_SCHEMA_TOOLS_LIST_RAW.jsonl (campaign dir r8-r10-cutover-20260904), plus R8_HOST_SCHEMA_FRESHNESS_RECEIPT.md.

    No DevSpace redeploy, server.ts edit, 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.

  7. James3014 commented on Sep 8, 2026

    @James3014
    OwnerAuthor

    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 server 0e2be1ab-a4b3-482b-a78a-ade05f58b96d.

    ChatGPT's discovered dev.agent_preflight schema 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 profile

    A profile-based preflight for opencode-mimo-free-implement succeeds 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.ts at 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:

    1. Preserve the shared dirty work; isolate and independently reconcile the intended direct-dispatch slice against fresh James3014 main. Do not merge the mixed recovery batch as a shortcut.
    2. Verify profile XOR explicit provider+model (reject neither/both, empty model, disabled provider, mismatched effort) through production registration and handler tests.
    3. Bind the capability manifest to actual registered schema including optional/required fields, not only tool names/build labels. Host/cache attribution remains unresolved until exact host/runtime fingerprints are reconciled.
    4. Publish only accepted source, then use P0: Bound MCP session lifecycle and make Dev MCP cutovers multi-session safe #31 cutover protocol and refresh host binding. No restart was attempted in this audit.
    5. Re-run the exact profile and direct read-only preflight invocations from ChatGPT; require discovery and actual invocation to agree. Only then run bounded exact-model dispatch canaries under Harden Dev MCP reliability across host binding, worker startup, and timeout reconciliation #15.

    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.

  8. James3014 commented on Sep 9, 2026

    @James3014
    OwnerAuthor

    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。

    最小下一步

    1. Native discovery/read-only invocation:確認對本次 conversation 實際投影的 Dev 工具、OAuth resource/endpoint、server instance、build/source、schema manifest。讀不到不能改用 Nexus 工具或本機 SDK 冒充 native。
    2. 在 GitHub 檢查 fork Actions enablement,使用已授權途徑恢復真正 runs。觀測 ci.yml 只有 pull_request 與 main push,沒有 workflow_dispatch;不要對不存在的 run 做 rerun,也不要把 API enabled 或空 checks 當完成。這些環境準備可與 feat: enforce cross-conversation resource ownership and evidence-bound delivery #62 domain 工作分開,不互相製造等待。
    3. fix: bind dispatch to fresh catalogs and verified provider results #60 → feat: add opt-in durable ChatGPT peer swarm #61 依序審查/CI/整合;feat: add opt-in durable ChatGPT peer swarm #61 在 fix: bind dispatch to fresh catalogs and verified provider results #60 合併後核對新的 base、exact diff/test subject。transport45f52173 與 feat: enforce cross-conversation resource ownership and evidence-bound delivery #62 為分開 reviewed deltas,不能吸收共享 checkout 的15檔dirty batch。
    4. 從最終 accepted integration SHA 重新 clean build/pack,在隔離安裝環境核對 packaged entrypoints 與 schemas。借鏡 ODW 的 package-level acceptance;源碼測試及舊09402 tgz都不能替代。
    5. 依現有 P0: Bound MCP session lifecycle and make Dev MCP cutovers multi-session safe #31 cutover lease/drain/reconcile 協議做受控切換,記錄 old/new server、source/build/manifest、active work 與 reconnect。unknown restart 不做第二次盲踢;P0: Bound MCP session lifecycle and make Dev MCP cutovers multi-session safe #31 已完成契約不重開。
    6. 原生 profile 與 direct provider/model preflight 都要和實際註冊 schema 一致,再完成 Harden Dev MCP reliability across host binding, worker startup, and timeout reconciliation #15 單 worker驗收。保留原 Harden Dev MCP reliability across host binding, worker startup, and timeout reconciliation #15 所需連續唯讀呼叫/reconnect 的觀測,不能用 discovery成功代替 invocation成功。

    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。

  9. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    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/devspace default branch: main
    • current GitHub main: d39dae00c0be4c21b505bd77821680786c02db28
    • current tree: 6735dc0148b5b541fc6aca7de56c813c334442b4

    This comment does not assert that the live runtime is stale merely because main advanced. Before any further deployment action, rebind and distinguish these separate identities:

    1. remoteMain
    2. acceptedDeployment / approved deployment target
    3. installedBuild
    4. runningBuild + serverInstanceId
    5. host-visible tool/schema binding

    remote main != automatic deployment authority remains 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_PINNED
    • DEPLOYMENT_DRIFT
    • ACTIVATION_PENDING
    • HOST_BINDING_STALE
    • RECONCILIATION_REQUIRED
    • CONVERGED

    For a real approved deployment, the target terminal evidence should be:

    accepted target == installed artifact == running runtime
    + post-start source/build/manifest readback
    + current host-visible schema binding
    + reconciliation complete
    

    or one exact BLOCKED reason.

    Scope clarification

    This comment is a durable owner/coordination anchor for the conversation's runtime-convergence follow-up; #30 remains the canonical Issue for that concern.

  10. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    Delivery & Convergence Summary

    Closed as completed via PR #103 (merged).

    Summary of Improvements

    1. Convergence State Machine (src/deployment-convergence.ts):
      • Classifies the 5 identities (remoteMain, acceptedDeployment, installedBuild, runningBuild, hostBinding) into the 6 canonical states:
        • INTENTIONALLY_PINNED
        • DEPLOYMENT_DRIFT
        • ACTIVATION_PENDING
        • HOST_BINDING_STALE
        • RECONCILIATION_REQUIRED
        • CONVERGED
    2. Capability Regression Prevention (assertDeploymentCandidateValid):
      • Rejects candidate builds that do not descend from canonical main or drop required MCP contract capabilities (agent_start.executionContract.authorityMode, idleTimeoutMs, nexusGrant, etc.).
      • Reproduces and enforces negative protection against the historical 458bb443 vs 1f626813 divergence.
    3. Automated Verification:
      • 8 unit tests in src/deployment-convergence.test.ts covering all convergence states, negative candidate rejection, and positive canonical main acceptance.
  11. James3014 commented on Oct 6, 2026

    @James3014
    OwnerAuthor

    REGRESSION REOPEN — fresh #1452 loaded-runtime lineage/capability evidence (2026-10-06).

    Current canonical DevSpace main:
    6fe39fdd90305722b82fc688168e1da020a6a075

    Current JamesdeMac-mini.local launchd service source:
    8e9afd80c0f93103cdda5947fe276fae4a5fa57e

    Git ancestry:

    • 8e9afd80... is an ancestor of 6fe39fdd...;
    • current main is exactly 4 commits ahead;
    • those 4 commits include enrolled-repository first-write admission, managed-agent/command nexus-certify PATH exposure, and trusted Core-gate changes.

    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.

  12. James3014 commented on Oct 6, 2026

    @James3014
    OwnerAuthor

    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 connected mcp__dev.open_workspace proves the current canonical Dev MCP serving this ChatGPT conversation is already:

    • sourceCommit: 6fe39fdd90305722b82fc688168e1da020a6a075
    • buildId: devspace-1.0.7-6fe39fdd
    • serverInstanceId: 70c249de-db7f-4bde-854a-5fceae2206f2

    That source contains the merged enrolled-repository admission implementation.

    Fresh live negative canary on an enrolled #1418 worktree:

    • exact workspace HEAD: 32f30f900dcec8294d12063f5199681b46566f0e
    • write-capable profile: codex-gpt-5-6-sol-implement
    • no resumable-work admission pointer supplied
    • result before provider launch:
      P0_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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions