P1 Core Envelope: add durable Core-bound mutation sessions and sink admission

[James3014]

Parent / dependency

Parent umbrella: James3014/Nexus-new#957.

Depends on the stable public contract produced by James3014/nexus-core#28.

Current source fence at child creation:

main@e6f8a218c5a71efd02e15603d2bed9e98e1e0374

DevSpace remains execution/control transport only. This Issue must not create route, Planner, Workforce, verifier, Completion, Candidate-acceptance, merge, release or deployment authority.

Problem

DevSpace already has reusable mutation-control primitives:

• workspace/worktree identity;
• durable agent/process/session identity;
• expected-HEAD and foreign-mutation checks;
• capability-discovery pre-mutation gate for write-capable agent_start;
• durable continuation/reconciliation;
• typed Git/Candidate operations.

But current mutation sinks are not Core-bound. A write-capable agent or direct DevSpace mutation can act without one immutable AcceptanceContract binding, and shell/PTY/raw processes retain OS filesystem authority.

Target design

Use one immutable durable Core-bound mutation session per logical bounded mutation attempt, then require all supported mutation sinks to validate that same binding immediately before effect.

Do not create one Core contract per sink and do not create a second workspace/session authority.

Session binding

Consume the frozen nexus.repository_mutation_binding.v1 projection from Nexus-new#957. Persist at minimum:

• binding id/hash;
• exact repository/origin identity;
• exact source commit/tree;
• workspace identity/mode;
• execution lane + existing authority reference/hash as opaque metadata;
• capability-discovery identity when required;
• canonical Core AcceptanceContract + hash;
• operation id / attempt id;
• freshness/rebind state.

DevSpace validates/carries this projection but does not decide lane/route or mint Core truth.

Commitment point

For write-capable paths, binding must be valid after lane/capability/authority resolution and before the first write-capable process/tool receives mutation authority.

Read-only operations stay usable without fake Completion subjects.

Supported sink families

Inventory current source again at implementation time, then cover every supported sink in these families where present:

• direct structured file write/edit/apply operations;
• agent_start / delegated worker start;
• agent_continue / resume;
• managed Codex goal start/continue where mutation-capable;
• exec_command/shell/PTY and write_stdin lifecycle;
• Git commit / publication preparation;
• Candidate formation/integration preparation.

Do not claim a sink is covered because only agent_start was gated.

Structured writes vs unrestricted processes

Structured write sinks may claim pre-write machine enforcement only when the actual effect is bounded by the sink and binding.

For unrestricted shell/PTY/raw processes, unless a proven filesystem sandbox already exists:

CORE_BOUND_SESSION_REQUIRED
PATH_LEVEL_PREWRITE_CONTAINMENT_NOT_PROVEN

Do not expand this Issue into a new OS sandbox project. Physical changed paths are still checked post-effect and scope escape blocks trusted completion.

Continuation / replay / reconcile

• same logical operation reuses the same immutable binding;
• continue/resume/write_stdin requires the exact original valid binding;
• changed/broadened binding after possible effect => conflict;
• base drift before first effect => rebind required / block;
• timeout/unknown outcome => reconcile same operation, never create a new binding or blind resend;
• provider/model/session identity is execution attestation only, not Core authority.

Physical ChangeSet export

After mutation, expose enough physical state for the consumer/Nexus layer to construct the Core subject:

• source commit/tree;
• target commit when one exists, otherwise deterministic target Git tree;
• actual changed/deleted paths;
• canonical change-manifest inputs / object identities;
• operation/attempt/workspace/binding provenance.

Do not trust worker prose as physical ChangeSet truth.

Acceptance criteria

• Write-capable supported start without a required valid Core binding fails before mutation authority.
• Read-only start remains available without fake AcceptanceContract/ChangeSet.
• Exact binding is durably persisted with workspace/session/operation identity.
• agent_continue/resume rejects missing, changed, stale or broadened binding.
• Worker cannot widen allowed paths, required verifier IDs or deletion policy by returning a broader contract.
• Existing capability-discovery gate is reused/composed rather than replaced by a parallel authority.
• Structured direct writes check the same session binding before effect.
• Managed Git/Candidate publication carries Core binding provenance.
• Shell/PTY is labeled honestly and cannot claim path-level containment without an actual sandbox.
• Physical reconciliation can produce the exact post-effect subject/provenance needed by Core verification.
• Timeout/restart does not create retry permission or a second logical mutation attempt silently.
• Existing session/conversation collision and capability-generation protections remain intact.

Negative controls

• missing contract -> supported write blocked;
• forged contract hash -> blocked;
• stale base -> blocked/rebind;
• same session continued with changed binding -> conflict;
• worker adds a path/verifier/deletion permission -> rejected;
• admitted shell writes outside contract and still reports machine-contained -> FAIL;
• historical unbound session is continued as Core-bound -> FAIL;
• uncertain process outcome starts replacement attempt instead of reconcile -> FAIL;
• provider/model identity is treated as lane/Core authority -> FAIL.

Non-goals

• implementing Core canonical hashing/verification itself;
• choosing DIRECT_CANONICAL, DIRECT_DELEGATED, or GOVERNED;
• model routing/admission;
• general filesystem sandbox;
• Candidate acceptance / merge / deploy.

Claim ceiling

Completion may claim only:

DEVSPACE_CORE_BOUND_MUTATION_SESSION_SOURCE_VERIFIED

No claim that Nexus-new completion gates or resident Open SWE are live until their own consumers are integrated and canaried.

Stop boundary

Implement and test in DevSpace only after the Core public protocol dependency is stable. Produce a bounded Candidate/PR; do not auto-modify Nexus-new or Open SWE.

AUTO_CHAIN=false.

[James3014]

Implementation progress / current transport blocker

A bounded implementation was started against exact source fence:

devspace main@e6f8a218c5a71efd02e15603d2bed9e98e1e0374

The intended implementation reuses existing workspace/session/capability-discovery control primitives and pins the provisional consumer contract to Core draft Candidate James3014/nexus-core#29@aabf2d4d00be4a3a357646be97b4d784d486ccb4.

Work completed in the isolated local checkout before the control-plane outage includes a draft of:

• durable core_mutation_sessions persistence/migration;
• strict nexus.repository_mutation_binding.v1 parsing and canonical hashing;
• exact clean source HEAD/tree/origin admission so pre-existing raw diffs cannot receive retroactive Core provenance;
• one active immutable Core mutation session per workspace;
• exact caller/session/binding replay fences;
• AcceptanceContract path/deletion admission;
• deterministic physical target-tree materialization via an isolated temporary Git index (without modifying caller index/HEAD/files);
• Core-compatible source-tree→target-tree manifest/diff hash projection;
• bounded MCP session open/status/snapshot/close surface;
• preliminary structured write/edit/apply-patch and write-capable agent/process/Codex-goal admission wiring.

This work is not a Candidate and is not claimed verified. Several remaining seams still require physical reconciliation and tests, including exact agent_continue, Git commit/push/Candidate provenance, workspace-identity validation, capability-discovery cross-binding at session-open, structured-output schema compatibility, and full negative-control coverage.

Blocker

The connected DevSpace control plane began returning persistent HTTP 502 across unrelated calls (bash, workspace_inspect, cutover_status, dev-c), not only one mutation action. A separately authorized Remote Desktop path was unavailable because no device was connected, and current Nexus gateway exposes no alternate typed source-write action.

Per no-blind-retry / exact-effect rules, uncertain edits were reconciled when possible and were not blindly replayed. No branch/commit/PR was published from this partial checkout.

Current state:

DEVSPACE_135_IMPLEMENTATION = PARTIAL_LOCAL_DRAFT
DEVSPACE_135_CANDIDATE = NOT_CREATED
BLOCKER = CONTROL_PLANE_TRANSPORT_UNAVAILABLE

Resume gate: restore a supported source-mutation control plane, first read exact physical worktree state, then finish/test from that single checkout before any Candidate publication.

[James3014]

2026-09-15 current-main rebind

Fresh canonical readback before resuming this child:

• devspace main@3880352ee1a307f1ac1264bdd498ae5c048f105b
• prior Issue creation fence e6f8a218c5a71efd02e15603d2bed9e98e1e0374 is historical only
• DevSpace development-boundary Wave 2 is already integrated in main (PR refactor(architecture): resolve DevSpace boundary debt #149 lineage), so current durable control / provider-carrier-strategy dependency direction must be preserved by this child
• parent Nexus-new#957 remains the umbrella authority
• required Core public protocol is still not canonical main: nexus-core#29 exact Candidate aabf2d4d00be4a3a357646be97b4d784d486ccb4 is source/CI verified but awaiting distinct independent review/acceptance before merge

The earlier local PARTIAL_LOCAL_DRAFT recorded against e6f8a218... must not be treated as a current Candidate or blindly replayed onto main. Resume only by first reconciling that physical checkout, then rebasing/re-deriving the minimum delta against 3880352e... after Core #29 becomes a stable canonical dependency.

Current gate:

DEVSPACE_135 = REBIND_COMPLETE / IMPLEMENTATION_BLOCKED_ON_CORE_28_CANONICAL_PROTOCOL

No mutation authority, Completion authority, or second control plane is added by this rebind.

[James3014]

2026-09-15 current-main mutation-sink inventory refresh

Read-only localization against exact devspace main@3880352ee1a307f1ac1264bdd498ae5c048f105b is complete. This refresh does not begin implementation; it freezes the actual current sink families so the Core consumer wiring can start immediately after nexus-core#28/#29 becomes canonical.

A. Structured workspace writes — MACHINE_ENFORCEMENT_AVAILABLE_NOT_WIRED

Current source exposes bounded write surfaces through server.ts:

• non-Codex tool mode: write, edit;
• Codex tool mode: apply_patch (add/overwrite/update/delete/move);
• conditional artifact path: download_artifact in artifact-tools.ts writes a new workspace-relative file when artifact support is enabled/supported.

These are real repository mutation sinks. They already have workspace/path mechanics, but none currently consumes the immutable Core mutation-session binding required by #957/#135.

download_artifact was not called out explicitly in the original #135 sink list and is now added to the implementation inventory so an attachment/native-file write cannot bypass the common envelope merely because it is not an agent path.

B. Delegated worker start/continue — MACHINE_ENFORCEMENT_AVAILABLE_NOT_WIRED

• agent_start already requires current capability-discovery evidence for write-capable delegated execution and carries expectedHead, writePaths, maxFiles through the execution contract.
• agent_continue resumes the exact durable worker/session.

This is the correct donor seam. Add Core binding to the existing admission/continuation contract; do not create a second preflight authority. Exact replay must retain the same binding and a worker may not widen path/verifier/deletion scope.

C. Managed Codex goal — MACHINE_ENFORCEMENT_AVAILABLE_NOT_WIRED / PATH_CONTAINMENT_NOT_PROVEN

• codex_goal_start launches a real interactive Codex CLI PTY, requires clean Git state + expectedHead, and allows one active goal per workspace.
• codex_goal_continue writes follow-up input to that exact process.

This has a clean managed commitment point for requiring the Core session before launch/continuation, but the child must preserve the frozen #957 claim ceiling: admitting the PTY does not prove path-level pre-write filesystem containment.

D. Generic process surfaces — BYPASSABLE_RAW_MUTATION for path containment

• non-Codex: bash;
• Codex mode: exec_command + write_stdin.

The tool descriptions instruct these surfaces not to create/modify project files where applicable, but a real shell/PTY retains OS filesystem authority. Therefore #135 must require the same Core-bound session before supported write-capable use while reporting:

CORE_BOUND_SESSION_REQUIRED / PATH_LEVEL_PREWRITE_CONTAINMENT_NOT_PROVEN

Post-effect physical ChangeSet verification remains mandatory. Do not claim prompt/tool-description policy as a sandbox.

E. Candidate / Git mutation and publication — MACHINE_ENFORCEMENT_AVAILABLE_NOT_WIRED

Current source exposes:

• git_commit — scoped Candidate commit from exact paths;
• git_push — publish Candidate HEAD to a non-default branch;
• candidate_integrate — apply one exact immutable Candidate range to a destination checkout when confirmApply=true, with existing identity/HEAD/dirty-overlap/effect-reconciliation gates.

Core provenance must be carried/checked at these mutation/publication seams. The Core binding does not grant Candidate acceptance, integration, push, merge, release or deployment authority; existing authorities/gates stay separate.

candidate_integration_readiness is read-only and must not be forced to manufacture a fake Completion subject.

F. Explicitly out of this repository-mutation envelope

Host activation, browser/ChatGPT carrier effects, service restart/cutover and other typed host/external effects retain their existing operation/reconciliation authority. Only any repository mutation component is in #135/#957 scope.

Current implementation seam

Use one durable nexus.repository_mutation_binding.v1 session keyed to exact workspace/operation/attempt. The same guard should be callable immediately before each structured effect and before launching/continuing write-capable processes. Do not mint one AcceptanceContract per sink.

Updated current gate

DEVSPACE_135_CURRENT_SINK_INVENTORY = FROZEN_AT_3880352e
DEVSPACE_135_IMPLEMENTATION = BLOCKED_ON_CANONICAL_CORE_28_PROTOCOL

The previously recorded partial local draft remains historical/non-Candidate and must be reconciled, not blindly replayed.

[James3014]

2026-09-15 executable acceptance matrix freeze

Dependency remains canonical nexus-core#28/#29. This comment freezes implementation tests only; it does not authorize source mutation before the Core public protocol is canonical.

Positive matrix

1. read_only_without_core_binding
   • read-only tool/session remains usable;
   • no fake AcceptanceContract/ChangeSet is created.
2. structured_write_with_exact_binding
   • one valid nexus.repository_mutation_binding.v1 is admitted;
   • write/edit/apply_patch/supported download_artifact check the same binding immediately before effect.
3. delegated_start_and_continue_same_binding
   • agent_start composes the existing capability-discovery gate with Core-binding validation;
   • agent_continue reuses the exact persisted binding, operation and workspace identity.
4. managed_goal_same_binding
   • codex_goal_start / continuation carry exact binding identity;
   • claim remains CORE_BOUND_SESSION_REQUIRED / PATH_LEVEL_PREWRITE_CONTAINMENT_NOT_PROVEN for PTY filesystem authority.
5. git_candidate_provenance
   • git_commit, git_push, candidate_integrate carry/check the same Core provenance while preserving their existing Candidate/integration authorities.
6. physical_subject_projection
   • source commit/tree + deterministic target tree/commit + actual changed/deleted paths + canonical manifest object identities can be exported for Core generic verification.

Mandatory fail-closed matrix

• write-capable structured sink + missing binding => reject before effect;
• malformed/forged binding_hash or AcceptanceContract hash => reject;
• source HEAD/tree/workspace identity drift before first effect => REBIND_REQUIRED / reject;
• same session/operation continued with another binding => conflict;
• worker/session attempts broader path set => reject;
• broader verifier set or weaker deletion policy => reject;
• historical unbound session presented as Core-bound => reject;
• download_artifact writes outside bound paths => reject before supported file write;
• shell/PTY admitted under binding then changes out-of-scope path => physical reconciliation reports escape; no machine-contained/trusted completion claim;
• uncertain process outcome => reconcile same operation; no replacement binding/automatic second send;
• provider/model/session identity used as lane/Core authority => reject/assertion failure;
• Candidate push/integration is rejected if Core provenance is missing/mismatched, but Core VERIFIED alone must not grant Candidate acceptance, merge, release or deploy authority.

Boundary regression matrix

Existing protections must remain green:

• capability-generation/current discovery receipt checks;
• workspace/worktree ownership and expected-HEAD fences;
• session/conversation collision and continuation identity;
• durable operation/effect reconciliation;
• DevSpace development-boundary fence from Architecture: resolve second-wave DevSpace development-boundary debt #148/refactor(architecture): resolve DevSpace boundary debt #149;
• current OpenCLI carrier coexistence.

Core conformance dependency

Consumer implementation must use the canonical Core descriptor/vector contract rather than reimplementing Core truth. At minimum TypeScript-side tests must consume/check:

• AcceptanceContract canonical hash equivalence;
• normalized text / UTF-8 byte constraints;
• path/verifier ordering equivalence;
• invalid path/hash/deletion policy/duplicate-ID negative vectors;
• typed git-commit: / git-tree: revision refs;
• canonical change-manifest/diff hash.

DEVSPACE_135_ACCEPTANCE_MATRIX = FROZEN
DEVSPACE_135_SOURCE_MUTATION = WAIT_CANONICAL_CORE_29

[James3014]

2026-09-16 Wave A current-state reconciliation

This comment reconciles Nexus-new#957 Wave A against current DevSpace source. It does not start new source mutation.

Fresh evidence

• current devspace main@0678354da8ea8f48e6b70b81ad6407c3da04ed72
• PR feat: bind mutation sessions to Nexus Core #172 feat: bind mutation sessions to Nexus Core is merged; merge commit 9e83ad5844ff55d32f495e8aded5a36e8ad91c07
• current main still contains src/core-mutation-session.ts with nexus.repository_mutation_binding.v1, Core mutation-session identity and physical-subject projection primitives
• PR feat: bind mutation sessions to Nexus Core #172 changed the expected mutation-control surfaces including core-mutation-session*, core-mutation-tools.ts, local-agent-contract.ts, process-sessions*, codex-goal-sessions*, git-candidate*, git-integration.ts, server.ts, and related tests

Ownership decision

devspace#135 remains the existing exact durable home for DevSpace-side Core-bound mutation sessions, supported sink admission, managed agent/process/Codex-goal propagation, Git/Candidate provenance and physical ChangeSet export.

Do not create another DevSpace child for Ambient Core / managed local-agent binding at Wave A. Any later DevSpace delta must first be reconciled against #135 and current main; a new child is justified only for a proven distinct contract outside #135.

This does not claim #135 is terminally complete merely because PR #172 merged. Issue closure, runtime/load evidence, and full acceptance remain separate reconciliation questions.

WAVE_A_DEVSPACE_CHILD_DECISION = REUSE_DEVSPACE_135
NEW_DEVSPACE_CHILD_REQUIRED = NO_CURRENT_EVIDENCE
AUTO_CHAIN = false

[James3014]

2026-09-16 runtime finding — synchronous Git admission can remain unreconciled on pre-commit generic error

A bounded Wave B1 Runtime Candidate exercise exposed a DevSpace error-path reconciliation defect in the current loaded Dev MCP service. This comment records the finding only; no DevSpace source repair is authorized by the Runtime Wave B1 task.

Loaded service evidence

Observed DevSpace build during reproduction:

• source commit: 03841ac7ab8abda1b54b9235f2fffe9d18404047
• build id: devspace-1.0.7-03841ac7

Reproduction

With an active Core-bound managed worktree session:

1. git_commit calls Core admission with synchronousPostEffectCheck: true.
2. Core marks the writer domain SYNCHRONOUS_GIT / reconciliation state OUTCOME_UNKNOWN.
3. Before commitCandidate(...), git_commit snapshots the workspace and validates that the requested path set includes every Core-bound changed path.
4. If that validation raises the generic error CORE_CANDIDATE_PATH_SET_INCOMPLETE, the catch path wraps it as GIT_EXECUTION_ERROR but does not call reconcileSynchronousEffect(...) because the special reconciliation branch handles GitCandidateError, not this generic pre-commit error.
5. The physical repository has not committed anything, but the durable Core session remains with unresolved SYNCHRONOUS_GIT.
6. The next mutation admission fails with CORE_MUTATION_RECONCILE_REQUIRED.

Confirmed reproduced session:

• workspace: ws_b20ed3853c
• session: cms_9b2aafab7e424affbac9e51847d825ff
• terminal observation: writerReconciliationState=OUTCOME_UNKNOWN, writer domains included SYNCHRONOUS_GIT

A follow-up attempt to use the exposed core_mutation_session_snapshot action returned Cannot read properties of undefined (reading '_zod'), so the current MCP tool surface did not provide a successful caller-accessible reconciliation path for that stuck session.

Source localization

Current server.ts ordering is effectively:

admit(synchronousPostEffectCheck=true)
→ snapshot()
→ candidate path-set completeness check
→ commitCandidate(...)
→ reconcileSynchronousEffect(...)

The normal success path reconciles correctly. The defect is specifically the generic error path between synchronous admission and commitCandidate(...).

Expected invariant

Any path that sets SYNCHRONOUS_GIT must deterministically clear/reconcile that writer domain when the physical effect is proven absent or fully observed, including errors raised after admission but before the Git mutation is attempted.

A pre-commit validation failure must not strand the session in OUTCOME_UNKNOWN.

Scope boundary

This did not invalidate the Runtime Wave B1 Candidate. That Candidate was rebuilt in a fresh managed worktree under a fresh Core session and successfully closed with writer reconciliation CLEAR.

No repair is claimed here.

DEVSPACE_135_RESIDUAL = PRE_COMMIT_SYNCHRONOUS_GIT_RECONCILIATION_GAP
REPAIR = NOT_STARTED
RUNTIME_WAVE_B1 = NOT_BLOCKED_BY_FINAL_CANDIDATE

[James3014]

Acceptance blocker discovered from real Wave B1 Candidate — cross-language manifest sort mismatch

A real nexus-runtime#27 Candidate exercised the #135 Core-bound Candidate path and exposed a protocol-conformance blocker. This comment records the finding only; it does not authorize a DevSpace repair in the Runtime acceptance task.

Exact physical witness

Candidate:

• source commit/tree: 68dbd468a311f6cc5d7633348d8c404d95ffd5c1 / 48939297956a71c57c0edb1ef43050663b288d9b
• target commit/tree: b13b622894dddd276fdfc8ebd5a171bcd7863716 / 51a1fae7fc230e09d88324c1ce10182958d02e3c
• no deletions; seven modified paths

The durable core_mutation_candidates row stores the exact correct Git object IDs/modes, but its manifest entry order begins:

1. docs/current-source-ownership.json
2. docs/EXTRACTION_STATUS.md
3. README.md

That row records:

• diff_hash/change_manifest_hash = sha256:79a46805a22f2b587edf643ee34b46cfdde933e684b47201a8222543d9bc1471
• change_set_hash = sha256:a08eb986318a4124daf126378ba0c21b59fe43876cdae47296a051d944e9e450

Canonical Nexus Core generic-verification sorts the same manifest entries lexicographically by path. For these bytes the canonical order begins README.md, docs/EXTRACTION_STATUS.md, docs/current-source-ownership.json, yielding:

• Core manifest hash sha256:a313f0d82fbb51ee373b6b63932cc8ebd506912916ed4c327d146f1144f4dba0
• Core ChangeSet hash sha256:12168e006ba26855cbdc3d8078748a6a0562e001fcd48417408e334c1a43d5ce

AcceptanceContract hashing is unaffected and matches Core exactly (sha256:0e83df036cb9307a6b17fc61afb72b8fcc32a61215042fcda586447f3019958b).

Root cause localization

Current canonical GitHub devspace main@0890f77e1f061511b2a48d5cab6aec0b18f735a7 still has:

entries.sort((left, right) => left.path.localeCompare(right.path));

in src/core-mutation-session.ts.

Canonical Core product/protocol/generic_verification.py uses deterministic Python lexical sorting:

entries = sorted(value["entries"], key=lambda row: row["path"])

localeCompare() is locale/collation-sensitive and is not equivalent to the protocol's deterministic cross-language lexicographic ordering. README.md versus lowercase docs/... is a concrete counterexample.

Impact

• DevSpace can form and close a physical Candidate as COMPLETED, while its persisted diff_hash / change_set_hash are not acceptable under canonical Core generic-verification for the same physical Git objects.
• Therefore COMPLETED must continue to remain below VERIFIED; the current Wave B1 Candidate correctly failed closed at independent acceptance.
• This is a real cross-language conformance failure, not a Runtime Candidate source regression.

Required repair proof

Repair should remain inside #135 ownership and prove at minimum:

1. TypeScript manifest ordering is byte-for-byte equivalent to Core protocol canonical ordering, without locale dependence.
2. Existing cross-language conformance vectors include a mixed-case path witness (README.md + docs/...).
3. Recomputed DevSpace manifest/change-set hashes equal Core hashes for the exact witness above.
4. Existing Candidate/session provenance, scope/deletion gates, and no-retroactive-binding rules remain intact.
5. After repair, reconcile whether the immutable Runtime Candidate can receive a corrected Core-compatible verification receipt without rewriting Candidate source commits or laundering the historical mismatched provenance.

DEVSPACE_135_NEW_FINDING = CROSS_LANGUAGE_CHANGE_MANIFEST_CANONICALIZATION_MISMATCH
TRUSTED_COMPLETION_IMPACT = BLOCKING
AUTO_CHAIN = false

[James3014]

Wave B1 acceptance reconciliation — producer mismatch isolated, repair still open

Follow-up from the real nexus-runtime#27 Wave B1 Candidate.

The exact physical source/target Git objects were re-projected with canonical nexus-core/main@fde015797672b0aac5dca7b41c7e5a0b901698d4 ordering and submitted with fresh verifier evidence. Core returned:

• verification = VERIFIED
• integrity = VALID
• certification = null
• canonical manifest hash: sha256:a313f0d82fbb51ee373b6b63932cc8ebd506912916ed4c327d146f1144f4dba0
• canonical ChangeSet hash: sha256:12168e006ba26855cbdc3d8078748a6a0562e001fcd48417408e334c1a43d5ce

The historical DevSpace durable row for the same physical objects still contains the different localeCompare-derived manifest hash sha256:79a46805a22f2b587edf643ee34b46cfdde933e684b47201a8222543d9bc1471. That historical evidence is preserved; it was not rewritten.

Therefore the earlier finding remains valid:

DEVSPACE_CROSS_LANGUAGE_MANIFEST_CANONICALIZATION = DEFECT_CONFIRMED
REPAIR = NOT_STARTED_BY_RUNTIME_ACCEPTANCE

But this producer defect is no longer the final Wave B1 acceptance blocker: canonical Core could verify the exact Candidate from physical Git objects. Independent Runtime acceptance subsequently rejected that Candidate for two separate Runtime semantic failures (recovery preparation-lineage revalidation and deadline recheck after preparation).

No #135 implementation, source mutation, Candidate, merge, or authority change is authorized by this comment.