Skip to content

feat: enforce cross-conversation resource ownership and evidence-bound delivery #62

Closed as not planned

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 範圍為準。
  • Owner 已於本 Codex task 明確指示「繼續未完成的工作」:feat: enforce cross-conversation resource ownership and evidence-bound delivery #62 主線恢復,維持 macOS-only;必要受控更新及真實入口驗收依既有授權與 overlap/驗證 gate 執行。其他 Issue 不因本註記取得新的派工。
  • 此文字更新不會自行修改 GitHub CI 設定或 branch protection;既有檢查設定如與新範圍不符,須另行明確調整,不得假稱已通過或繞過保護。

Implement the Owner's cross-conversation delivery contract: freeze base/PR/write scope before delegation, give shared resources one explicit owner, and distinguish source verification from deployed/native acceptance. Existing #33 checkout isolation, Swarm task ownership and cutover fences remain intact; they do not yet cover branch/issue/deployment/grant overlap between operations.

The first bounded slice is a non-authorizing ownership/handoff/matrix domain on frozen base 97fbefc (dependent on #61). Lease records bind resource, authenticated owner thread, operation, scope, base revision, expiry, terminal state and CAS version. Grant evidence is indexed by repository + goal + coordinator thread and must be validated through an existing authoritative reader; storing a receipt must never issue or widen a grant.

Acceptance requires two-process overlap rejection, deterministic replay, stale-version rejection, expired unresolved operations requiring reconciliation, immutable atomic handoff, old-owner rejection, restart recovery and a versioned Current Completion Matrix. Revisions are opaque identities, not sortable timestamps. Unresolved external effects must remain unknown and must not be silently retried or transferred.

Domain tests alone do not close this issue. A later reviewed integration must enforce the lease immediately before actual mutation, preserve ownership while effects remain in flight, and prove rejection through real cutover/durable-operation/host-coordinator consumer paths. Raw Git/UI/other conversations that do not participate in the guard are outside any claimed enforcement until integrated; do not advertise global protection from a table or cooperative receipt alone.

Pregate and Postgate evidence must map every criterion to a positive witness and relevant negative controls. Freeze each candidate before tests. The Current Completion Matrix is only a projection of authoritative revision-bound evidence and cannot grant authority or infer completion from code, PR merge, package existence or a passing subset.

No Nexus workforce/Planner mutation, new permission grant, cleanup of unrelated state or automatic scaling is included. PR #60/#61 and their live #49/#51 gates remain separate deliverables.

Activity

  1. James3014 commented on Sep 8, 2026

    @James3014
    OwnerAuthor

    2026-09-09 接手契約與執行切片:續作既有候選,不另造協作引擎

    總路線已寫回 #15;輸出/observer 有界化另由 #63 先稽核。本 issue 仍只擁有 cross-conversation resource ownership、handoff、completion projection 及實際 consumer enforcement。ODW 是 pattern reference,不是 dependency 或 authority。

    接手證據分層

    以下取自 Owner 提供的交接,本回合未能透過 Dev 工具重新讀取 Mac:

    • Domain worktree /private/tmp/devspace-coordination-domain-20260909,HEAD 51f57f0c142cf50e5627764a576b416ece1a7766,原主控回報三套 tests 17/17。
    • src/control-plane-ownership.ts 有未提交 renew/reconcile diff;worker 已暫停。17/17 不覆蓋這份未凍結 diff。
    • node_modules 為依賴 symlink,不提交。
    • Transport worktree /private/tmp/devspace-transport-principal-20260909,base 97fbefc041b7b60876d1dbbe45ae7c10617a61f0,HEAD 45f52173f43f855c1148762a438ebfab5da1e778;原主控回報 40/40、typecheck、diff-check 通過且乾淨。此為不同的四檔候選,不能混成六檔 domain 已完成。
    • 唯一 Matrix /Users/jameschen/Documents/Codex/2026-09-08/devspace-reliability/CURRENT-COMPLETION-MATRIX.json 尚未收錄上述最後驗證;接手需讀證據再更新,不以本段摘要當驗證收據。

    C0 — 保存與界定

    先讀 objective、DevSpace AGENTS、這兩個 worktree 的 exact HEAD/tree/status/full diff 與 tests/log,確認沒有仍在執行的舊 writer。不要直接恢復舊 agent handle,也不要另外派 worker 覆蓋 dirty ownership.ts。保留共享 checkout 的原 15 個 dirty files,不 reset/stash/clean/吸收。

    Domain slice 維持六檔:control-plane-ownership.ts/.test.ts、control-plane-handoff.ts/.test.ts、current-completion-matrix.ts/.test.ts。超出這六檔的 production consumer wiring 必須形成下一個明確切片,不默默擴張正在進行中的修正。

    C1 — renew/reconcile 凍結及獨立驗收

    Luna 先理解現有 dirty diff,再完成:

    • renew 僅同 owner、current grant hash/version、exact lease CAS、未過期、有限 TTL;scope/base/resource 不可被續租改寫。
    • grant ABA h1→h2→h1 不能復活舊 lease;舊 schema grant_version=0 保持 unbound/fail-closed,不猜成1。
    • 過期且操作可能已開始,保留 ownership/reconcile-required;不因 TTL、process death、查無 local session 就釋放/偷取。
    • reconcile 由可信 consumer/verifier 注入證據,核對 exact lease、owner/handle、operation、base、CAS version、current authority 及可支持的終態;caller 自填 terminal/verified 不可採信。
    • active、unknown、wrong handle、stale CAS、撤銷/不相符授權全部拒絕;不能為解除卡住而自行創造授權。
    • receipt 與終態改動同 transaction;失敗回滾;exact duplicate idempotency 與 changed-payload conflict 分開。
    • reconcile 是核對同一 effect,絕不重跑外部操作。

    驗證必須涵蓋成功、全部上述拒絕情境、two-process race、SQLite close/reopen、transaction rollback;先 freeze diff,再由主控獨立驗證。測試通過只建立此 slice 的 source evidence。

    C2 — handoff、resource identity 與持久化完整性

    Handoff receipt 至少能核對 old/new coordinator binding、repo/goal/resource、scope、base、grant hash/version、lease id/version、pinned operation/handle、exact checkpoint/evidence reference 及交接 CAS。欄位名稱重用已接受契約,不另建授權庫。

    移交不可讓未解副作用成為新 attempt;old owner 不能在交接後提交/解鎖,雙 owner 不得同时有效。錯 receipt、錯 operation、重播 ticket/receipt、version drift 與跨 scope 移交要 fail closed。

    Path/resource 檢查要用實際 identity,不只字串 prefix:根目錄/尾斜線、/tmp 與 /private/tmp、symlink 指向相同 resource、linked worktrees 共用 Git metadata、同一 branch/PR/deployment 的不同 resource 名稱都需明確分類。不存在/无法安全 canonicalize 的路徑不可默默變成另一個無衝突資源。不得用新 allow-root 或廣域掃描當解法。

    Malformed persisted enum/JSON/lease/grant binding 不可 reset 成空表或 queued;需帶原因拒絕並保留 evidence。

    C3 — 接到真正的副作用入口

    先列 consumer coverage 表:resource、實際 entrypoint、authenticated identity source、shared-state location、pre-effect fence、in-flight pin、terminal/reconcile path、哪些外部入口未受控。

    • 同一 host 的參與 consumer 使用一個經核對的 canonical ownership store;不能每個 worktree 各自建一份鎖後宣稱互斥。
    • 先保護本次確實使用的 durable-operation/cutover/host-coordinator 路徑;若 branch/Issue/PR 寫入由其他工具完成,明示它是 cooperative boundary,除非接線和實測證明已受相同 fence 控制。
    • 在實際 effect 前核對 lease/current grant/CAS;effect 可能在進行時 pin 不可消失。超時和 transport loss 必須能核對同一 operation,而不是允許另一 controller 重做。
    • 使用兩個獨立 processes/clients 通過 production consumers 競爭同一 resource,证明只有一方可開始;這項測試不能只調 domain helper。
    • 不參與 guard 的 raw Git、UI 或其他 conversations 不受此模組全面攔截,不得宣稱已建立整台 Mac 的全域鎖。

    C4 — 可重建的完成投影與接手配方

    借鏡 ODW Ultra Loop 的 essential-criteria checkpoint,但保留本 issue 的 SQLite/CAS 和 evidence authority;不搬範例的 JSON load/save + separate ledger append。

    Matrix 是唯一 current view,不是另一個執行狀態權威。每條原始 requirement/AC 固定 ID,引用 source revision、candidate、verification subject、命令結果、artifact digest、environment/native surface、verifier、已知限制及下一個 gate。至少分離 SOURCE/CI/PACKAGE/DEPLOYMENT/NATIVE_SINGLE/NATIVE_SWARM/CONTINUITY;空 criteria、缺 evidence、stale subject、selected subset PASS 都不可得出 aggregate COMPLETE。

    先前結果保持歷史身份:HANDOFF_REPORTED 不得變 INDEPENDENTLY_VERIFIED;未提交 diff 不繼承 predecessor tests;opaque SHA 不作時間排序;source變更後只重用有明確等價/影響證據的檢查。既有 durable record 是 authoritative input,Matrix只能投影/查缺,不能解鎖 lease、核發 grant 或授權 retry。

    接手 packet 保持短而完整:goal/AC、exact repo/base、current scope、已凍結 Candidate、未提交差異、active/unknown operation、evidence refs、remaining gate。不要再複製整段聊天或建立另一份 CURRENT 檔。

    身分與權限邊界維持不變

    OAuth clientId/resource 是 transport principal;不等於 ChatGPT conversation。保留 authenticated host + optional host conversation metadata assertion;不把 metadata 說成上游 cryptographic attestation,也不擅增簽章 API/scoped capability 當新 blocker。Grant reader 仍來自既有可信 consumer,不能由 caller 欄位合成。

    完成判定

    C0–C4 都有 exact evidence、reviewed integration 與實際 consumer witness 才可關閉 #62。Domain 17/17、transport40/40、CI green、Matrix更新,各自都不足。整體專案仍需 #15 原生單 worker、#49 兩個真實 conversations 20/20、#51 rollover;#31 保持完成,Nexus-new 不修改。

  2. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    2026-09-11 dependency/base reconciliation — #60/#61 merged; preserve the unfinished ownership diff before rebasing

    Fresh GitHub state materially supersedes the original frozen dependency snapshot in this Issue:

    The handoff-reported worktree /private/tmp/devspace-coordination-domain-20260909 and its uncommitted src/control-plane-ownership.ts renew/reconcile bytes remain a preservation obligation until physically rebound. Do not reset/stash/clean/overwrite them merely because the upstream dependencies have merged.

    C0 current entry contract

    Before any new Luna mutation:

    1. physically read the old domain worktree HEAD/tree/status/full dirty diff and confirm no old writer is running;
    2. preserve/hash the uncommitted renew/reconcile bytes and classify which portions are still needed against current main;
    3. rebind accepted fix: bind dispatch to fresh catalogs and verified provider results #60/feat: add opt-in durable ChatGPT peer swarm #61 source contracts and current AGENTS/CONTRIBUTING rules;
    4. create a fresh isolated successor only after the dirty bytes are accounted for; do not treat predecessor 17/17 as verification of the dirty diff or of a rebased result;
    5. keep the six-file domain slice distinct from the four-file transport principal Candidate and from later C3 production-consumer wiring.

    Dependency consequence

    #61 being merged satisfies a source dependency only; it does not close #62 and does not prove consumer enforcement. C1/C2 still require exact source evidence for renew/reconcile/handoff/resource identity. C3 still needs a separately frozen production-entrypoint slice and two-process/client contention through real consumers. C4 Matrix remains a projection only.

    Do not use current-main advancement as permission to discard historical bytes or to infer that the reported 17/17 / 40/40 evidence applies to a new subject.

  3. James3014 commented on Sep 11, 2026

    @James3014
    OwnerAuthor

    Cross-repository repair reconciliation: safety source is in PR #110 and host-operation source in PR #111. Neither closes this native gate. The last authenticated DevSpace runtime readback remains source 1c0dacc; current transport did not supply an approved paired coordination carrier. Required remaining evidence: formal exact carrier pairing, two real controllers competing with one operation start, and restart/reconnect reconciliation of that same operation. No carrier approval was self-created and no runtime restart was performed.

  4. James3014 commented on Oct 2, 2026

    @James3014
    OwnerAuthor

    Nexus-new #98 cross-entrypoint first-effect hook reconciliation

    Fresh consumer-side review of James3014/Nexus-new#98 / PR #1324 identified a same-contract external enforcement gap that belongs to this existing DevSpace ownership line rather than a new duplicate Issue.

    Proven current boundary

    Nexus-new #1324 can build a fail-closed canonical writer inventory and enforce it before Nexus-new/self-hosted Target lease, worker invocation, and candidate finalization.

    However, #1266 only supplies trusted readback/provenance for Dev MCP direct and RDC delegated attempts. It does not make those external mutation starts consume #98 conflict admission atomically before their own first effect.

    Therefore this unsafe race is not yet globally closed:

    external writer A / DevSpace-capable mutation start
        scans/registers independently
    external writer B / Nexus Target or another external path
        scans a prior snapshot
    both can enter an overlapping physical mutation domain
    

    A read-only inventory cannot by itself make cross-entrypoint admission atomic.

    Durable-home decision

    Reuse devspace#62 C3 production-consumer enforcement for the DevSpace-owned side. Do not create a new DevSpace child.

    The next bounded C3 delta should compose, not replace, existing #62/#135 controls and prove at the real write-capable DevSpace entrypoints:

    1. exact repository + normalized mutation-domain identity is bound before first effect;
    2. the shared ownership/admission surface rejects an overlapping current writer before mutation authority is granted;
    3. an already-active Nexus-new Dev MCP: add explicit OWNER_DIRECT host-operation execution contract #98 writer/claim projection can be consumed without turning DevSpace into Nexus routing/Planner/Workforce authority;
    4. concurrent contenders cannot both observe an old empty snapshot and proceed;
    5. timeout/process death/missing readback remain reconcile-required, never implicit release;
    6. disjoint domains may proceed only from a fresh atomic admission;
    7. two real clients/processes through production consumers prove one overlapping writer starts and the loser has zero mutation effects.

    Keep #135 Core-bound session/sink admission orthogonal: Core binding proves the mutation contract/provenance; #98/#62 physical conflict admission proves competing writers do not overlap.

    Raw RDC/UI/other mutation paths that do not participate in this guard remain outside the DevSpace enforcement claim and must stay explicit in Nexus-new #98 until their owning first-effect surface is identified and bound.

    This comment authorizes no DevSpace source mutation, retry, merge, release, or deployment. It is durable contract reconciliation only.

    AUTO_CHAIN=false.

  5. James3014 commented on Oct 2, 2026

    @James3014
    OwnerAuthor

    C3 continuation — existing Candidate reconciled; client reconnect gate

    Durable continuation state for the Nexus-new #98 / devspace #62 C3 production-consumer first-effect work.

    Current disposition

    • Nexus-new Dev MCP: add explicit OWNER_DIRECT host-operation execution contract #98 workflow doctor: SAFE / CONTINUE_BOUNDED_ISSUE_WORK.
    • Cross-session disposition on the DevSpace implementation: RECONCILE_EXISTING_ATTEMPT; an existing isolated Candidate already owns this slice, so no replacement attempt was started.
    • DevSpace current GitHub main: 7ce3c40c958e9f4750eb0f62b4c036b4dad1538c.
    • Existing Candidate base: 4fef445fa217a51794f13ac641a6b991db5d54ec.
    • Main-movement requalification found no changes on the Candidate's three paths between those revisions. The active P0: interrupted-turn resume/dedup and worktree writer lease #328 worktree touches only migration/work-resume paths and is disjoint from this C3 slice.

    Existing Core-bound Candidate

    • workspace: ws_fc2db89d9e
    • Core session: cms_b61034535a2e41ea87e1fbf495cf6308
    • binding hash: sha256:cbadc006c641775484790e1c738509c1055fa937909db99647f7acfa31c6f080
    • operation: devspace-62-c3-host-first-effect
    • attempt: issue62-c3-direct-v1
    • Core state: ACTIVE / FRESH / BOUND_CURRENT
    • writer state: OUTCOME_UNKNOWN
    • writer domains: [PROCESS]

    Current physical snapshot is bounded to the frozen three-file contract, with no deletions or scope escape:

    • src/control-plane-ownership.ts
    • src/host-operations.ts
    • src/host-operations.test.ts
    • target tree: git-tree:290e3b714497fde6a114b88ff3bd3fe4f974a8d0
    • diff hash: sha256:04dae1c5a64db37e882e292433a33bc69008f01a6e6e6c308518ddd0a0fdb64c
    • changed paths: exactly the three paths above
    • deleted paths: []
    • scope escape: []

    Material review finding

    The current three-file implementation is not acceptable as final C3 enforcement.

    It correctly demonstrates atomic overlap/disjoint behavior through HostOperationRegistrar, including two real OS processes, and preserves an OUTCOME_UNKNOWN conflict across a replacement registrar. However, the registrar currently derives its own startup-policy grant/evidence and inserts that grant into the shared ownership store before acquiring the lease.

    That would let a participating consumer manufacture the authority it is supposed to consume. It conflicts with #62's existing contract that grant evidence is validated through an existing authoritative reader and must not be issued or widened by the consumer. The corrected design remains:

    existing exact carrier authority -> prepareEffect/shared ownership lease -> durable operation + pin -> physical effect

    Known terminal state may clear the pin. OUTCOME_UNKNOWN must retain it. No second routing/Planner/Workforce/approval authority is introduced.

    The proper repair requires extending the existing carrier/consumer contract for a path-bounded host_operation effect rather than self-minting a host grant. That likely expands the frozen source scope, so it must happen only after the current Core PROCESS writer is reconciled and a new exact binding is frozen.

    Exact recovery blocker

    The live DevSpace server already advertises the canonical action core_mutation_session_recover_orphaned_process, but this ChatGPT client's current tool projection does not contain it.

    capability_convergence_status reports:

    • client state: SERVER_AHEAD_OF_CLIENT
    • controller disposition: STALE_RECONNECT_REQUIRED
    • missing action includes core_mutation_session_recover_orphaned_process
    • refresh was already attempted for this conversation/catalog generation
    • next action: RECONNECT_REQUIRED

    No CLI/SQLite mutation bypass, effect replay, new attempt, or scope widening was performed.

    Exact owner-recovery evidence is already frozen for the next connected client:

    • expected original actor: openai:2c29cf122d3e227d0c4160ce8db3e1f3075a9cba0cc8536aec98a9ffbde1f7ea
    • expected source head: 4fef445fa217a51794f13ac641a6b991db5d54ec
    • expected source tree: 2f02f055ff688da8a5ae853c21101ad5199f78a5
    • expected current head: 4fef445fa217a51794f13ac641a6b991db5d54ec
    • expected target tree: git-tree:290e3b714497fde6a114b88ff3bd3fe4f974a8d0
    • expected diff hash: sha256:04dae1c5a64db37e882e292433a33bc69008f01a6e6e6c308518ddd0a0fdb64c
    • expected changed paths: the exact three paths listed above
    • expected deleted paths: []

    Next gate after MCP reconnect:

    C3_ORPHAN_PROCESS_RECONCILE -> read back Core writer CLEAR -> freeze new carrier-based C3 binding/scope -> continue bounded implementation + two-client overlap/disjoint verification

    AUTO_CHAIN=false.

  6. James3014 commented on Oct 2, 2026

    @James3014
    OwnerAuthor

    C3 recurrence — blocked only by ChatGPT host action projection

    Fresh continuation on current DevSpace main bd3fa9b2b2354c01ce812b8c5f88a7fa7afd4609 reconfirmed the exact existing C3 recovery blocker.

    • Core session: cms_b61034535a2e41ea87e1fbf495cf6308
    • workspace: ws_fc2db89d9e
    • operation: devspace-62-c3-host-first-effect
    • attempt: issue62-c3-direct-v1
    • durable state: ACTIVE / FRESH / BOUND_CURRENT
    • writer state: OUTCOME_UNKNOWN
    • writer domains: [PROCESS]
    • old process: no longer live; physical dirty bytes still match the frozen three-file evidence
    • Gemini 3.8 correctly stopped with RECOVERY_NOT_CLEARED; zero source/state mutation and no bypass occurred.

    Live M5 DevSpace server is converged on bd3fa9b2 and its server catalog advertises core_mutation_session_recover_orphaned_process. The current ChatGPT callable projection still does not expose that action. capability_convergence_status(... requestRefresh=true) reports SERVER_AHEAD_OF_CLIENT; same-session refresh was requested, but the callable namespace did not hot-add the recovery action.

    No official DevSpace CLI equivalent exists for this Core orphan recovery path. Per #240, do not use shell/raw-MCP/SQLite/state-file substitutes.

    Exact next gate:

    1. ChatGPT Plugins -> DevSpace Mini M5 Pro -> Refresh/reconnect.
    2. Start a new ChatGPT conversation after refresh.
    3. Verify core_mutation_session_recover_orphaned_process is actually callable.
    4. Recover the exact orphan PROCESS effect for the session above using the frozen physical evidence.
    5. Require writer state CLEAR, then rebind/freeze the successor carrier-based C3 scope.
    6. Resume one Gemini 3.8 bounded implementation through tests, two-process contention witness, Candidate commit, branch publication and PR-ready; no merge/deploy/auto-chain.

    Transport/projection ownership remains devspace#240. C3 implementation ownership remains this Issue. Do not redispatch implementation before recovery is CLEAR.

    AUTO_CHAIN=false.

  7. James3014 commented on Oct 3, 2026

    @James3014
    OwnerAuthor

    C3 continuation 2026-10-04 — recovery callable is now projected; blocker narrowed to owner OAuth continuity

    Fresh continuation for the Nexus-new #98 / devspace #62 C3 first-effect work.

    Cross-session reconciliation

    The existing Core-bound Candidate remains the canonical attempt; no replacement attempt was started.

    • workspace: ws_fc2db89d9e
    • worktree: /Users/james/.devspace/worktrees/devspace-623b3bd6
    • Core session: cms_b61034535a2e41ea87e1fbf495cf6308
    • binding: sha256:cbadc006c641775484790e1c738509c1055fa937909db99647f7acfa31c6f080
    • operation: devspace-62-c3-host-first-effect
    • attempt: issue62-c3-direct-v1
    • source HEAD/tree: 4fef445fa217a51794f13ac641a6b991db5d54ec / 2f02f055ff688da8a5ae853c21101ad5199f78a5
    • durable session state remains ACTIVE / FRESH / BOUND_CURRENT
    • writer state remains OUTCOME_UNKNOWN
    • writer domains: [PROCESS]
    • physical dirty scope remains exactly:
      • src/control-plane-ownership.ts
      • src/host-operations.ts
      • src/host-operations.test.ts
    • no deletions / no additional dirty paths were observed.

    Current GitHub devspace/main observed in this continuation: 79c59fea72e2a3f56cfe9fee3915686c73de684a.

    Important blocker change

    The prior client-projection blocker is no longer the immediate failure in this session.

    The ChatGPT callable projection now includes:

    core_mutation_session_recover_orphaned_process

    A direct invocation was made using the exact frozen recovery evidence already recorded in this Issue. The server rejected it with:

    CORE_MUTATION_RECOVERY_OWNER_REQUIRED: Exact configured OAuth owner client identity is required for Core orphan recovery.

    Therefore the blocker is now:

    OWNER_OAUTH_CONTINUITY / RECOVERY_OWNER_IDENTITY_MISMATCH

    not MISSING_RECOVERY_TOOL.

    The recovery action correctly granted zero retry, mutation, completion, publication, merge, release, or runtime authority.

    Why no fallback/retry was attempted

    • core_mutation_session_rebind is not a workaround: its own contract requires unresolved writer effects to be reconciled first.
    • the current caller cannot run workspace commands inside the active Core session; DevSpace correctly rejects them with CORE_MUTATION_ACTOR_MISMATCH.
    • no raw CLI, SQLite mutation, state-file edit, alternate state root, shell recovery, new writer, or blind redispatch was used.
    • read-only physical inspection only confirmed the frozen three-file Candidate still exists.

    Existing Candidate remains semantically unaccepted

    Fresh physical readback reconfirms the known review finding: the three-file Candidate still makes HostOperationRegistrar derive and insert its own startup-policy grant/evidence before ownership acquisition. That is a consumer self-minting the authority it is supposed to consume, so the Candidate must not be committed or published as final C3 enforcement.

    The corrected successor design remains:

    existing exact carrier authority -> prepareEffect/shared ownership lease -> durable operation + pin -> physical first effect

    with known terminal release and OUTCOME_UNKNOWN retention.

    Exact next gate

    C3_OWNER_AUTH_RECOVERY -> writer CLEAR -> exact caller rebind/takeover as allowed -> freeze successor carrier-based C3 scope -> bounded repair -> two-client overlap/disjoint witness -> Candidate/PR-ready

    This continuation reached the authoritative recovery boundary and stopped. No new implementation effect was started.

    AUTO_CHAIN=false.

  8. James3014 commented on Oct 4, 2026

    @James3014
    OwnerAuthor

    CONTRACT_DELTA — broad C3 ownership is not a direct-dispatch prerequisite

    Owner decision on 2026-10-05 establishes #350 as the single P0 for ordinary ChatGPT -> Dev MCP worker dispatch.

    #62 remains the home for its broader cross-conversation/resource ownership contract. It must not become a hard prerequisite for #350.

    The direct-dispatch path may reuse only already-proven execution-safety mechanics required to prevent conflicting physical writers / duplicate effects. Closed #328 is the preferred donor for resumable identity, duplicate suppression, writer fencing, reconnect and restart behavior.

    Do not require #350 to complete #62's wider branch/Issue/deployment/grant/Completion-Matrix governance before a normal OWNER_DIRECT worker can start.

    DIRECT_DISPATCH_HARD_DEPENDENCY_ON_62 = NO
    AUTO_CHAIN=false

  9. James3014 commented on Oct 5, 2026

    @James3014
    OwnerAuthor

    OWNER RECONCILIATION — split physical safety from semantic control-plane ownership

    This Issue mixed two different concerns.

    DevSpace-owned execution safety remains valid and is already available through proven primitives such as isolated workspaces/worktrees, resumable attempt identity, duplicate suppression, physical writer/conflict fencing, CAS and reconciliation (#328/#350 lineage).

    The broader C3 contract — repository/goal/coordinator grants, branch/Issue/deployment ownership, completion matrix, semantic handoff authority — is governance/control-plane state. Under Nexus-new#1349 it must not become a second authority inside DevSpace. Nexus-side path/conflict semantics already have durable context in Nexus-new#98.

    Disposition:

    • retain only reusable physical lease/conflict primitives as non-authorizing execution mechanics;
    • do not continue C3 as a broad DevSpace governance subsystem;
    • semantic ownership/grant/completion responsibility returns to Nexus.

    Closure classification: SUPERSEDED / SPLIT_OWNERSHIP / NOT_PLANNED_AS_DEVSPACE_CONTROL_PLANE.
    AUTO_CHAIN=false.

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