feat(storage): add the live managed materialization boundary (#2052 Stack B2)

[Jurij89]

Summary

Stack B2 of #2052: the live managed materialization boundary. Default-unused — no producer, provider, requester, protocol handler, advertisement or activation is registered here, and nothing in this PR performs store, epoch, queue, permit or scheduler work unless a daemon supervisor hands over a live ownership lease.

Stacked on #2103 (feat/2052-system-record-core), which is still open. Base will move to testnet-canary once #2103 merges.

This PR does not close #2052. Per the plan's ownership table, closure needs Stacks C–F plus the loaded r26/r27 regression.

Scope note — read this first

B2 as specified in the Revision 17 plan is very large. This PR delivers the ownership, capability and lifecycle boundary plus its live evidence, and deliberately stops short of the full-state CAS transaction. Concretely:

• SparqlHttpStore.executeSystemRecordApply() currently returns a typed deferred and dispatches nothing. The lane can be discovered, opened, sealed, disabled and shut down; it cannot yet apply a record.
• That is fail-closed by construction rather than a stub that silently no-ops: no unproven write is ever dispatched.
• The composition is live: with the supervisor handoff wired, the real daemon store advertises the lane, and a session opened against a proven-ownership generation restarts the owned child under a real scheduler barrier. Only the apply itself defers.

The verified-replacement command construction, bounded inspectAppliedState, and the exact prior/next subject-union transaction are the next PR in the stack. Splitting here keeps both halves reviewable; the alternative was one PR nobody could review carefully.

How it fits together

Capability travels by identity, not by config. Nothing below is reachable from a persisted file.

flowchart LR
    subgraph daemon["CLI daemon"]
        SUP["startOxigraphServer\n(lifecycle mutex + state machine)"]
        CHILD["owned oxigraph child\nPID + listen socket"]
        SUP -->|"spawn / SIGTERM,\nprove listener owner"| CHILD
    end

    subgraph storage["storage package"]
        CTRL["ownership controller\n(module-private WeakMap)"]
        LEASE(["lease handle\ndata-less, unique symbol"])
        ADAPTER["SparqlHttpStore"]
        LANE["system-record lane\nsession state machine"]
        SCHED["StorePriorityScheduler\ncontrol barrier"]
        POOL["OwnedManagedHttpClient\n(node:http.Agent)"]
    end

    SUP --- CTRL
    CTRL -->|"mints"| LEASE
    LEASE -->|"symbol-keyed option"| ADAPTER
    SUP -->|"supervisorHandoff"| ADAPTER
    ADAPTER -->|"advertises IFF lease live\nAND handoff present\nAND snapshot ready"| LANE
    LANE -->|"every lifecycle transition"| SCHED
    LANE -->|"apply (deferred in this PR)"| POOL
    POOL --> CHILD
    ADAPTER --> CHILD

Loading

The lease carries no data at all — its meaning lives in a module-private WeakMap keyed by identity — and travels under a unique symbol, which object spread copies (so it survives resolveAdapterOptions' rewrite) but JSON cannot produce or round-trip. Mutation authority is a separate controller the supervisor never hands out.

The generation handoff, as it now runs

sequenceDiagram
    participant Q as Ordinary store traffic
    participant S as StorePriorityScheduler
    participant L as System-record lane
    participant A as SparqlHttpStore
    participant O as Oxigraph supervisor
    participant X as Owned child

    Q->>S: run() — admitted, in flight
    L->>S: runControlBarrier(store, "system-record.enable", gen)
    S->>S: seal store; HOLD new tagged run() off-queue
    Q-->>S: in-flight work completes
    S->>S: quiesced (untagged 0, tagged-for-store 0)
    S->>L: transition starts in the reserved controller slot
    L->>A: destroyClient() — retire the owned pool
    L->>O: stopAndProveOwnedChildDead()
    O-->>X: SIGTERM, then prove the PORT released
    L->>A: awaitRetiredWork() — drain the retired pool
    L->>O: startAndProveCleanGeneration()
    O->>X: spawn; bind generation ONLY once the child is the proven listener
    L->>A: rotateMaterializationEpoch()
    L->>S: transition returns; seal commits
    S-->>Q: held work resumes against the replacement generation

Loading

The order is load-bearing and asserted step by step, not merely as a set: a replacement started before the old child is proven dead would let a request issued over the retired pool reach the new listener.

What lands

Reserved graph policy (internal-graph-policy.ts). B2's persistent graphs deliberately reuse the urn:dkg:internal:atomic-graph-replace: prefix, because all nine existing filter sites already hide it — predecessors get the downgrade property with no change on their side. That makes "internal" mean two things with opposite lifetimes, so reserved names match exactly, staging names match a canonical UUID shape, and generic mutation refuses everything else in the namespace. The module imports nothing from the system-record barrel because index.ts is on every process's startup path; a test imports the barrel and asserts the literals agree.

Unforgeable ownership lease (managed-oxigraph-ownership-v1-internal.ts). Every signal available today is forgeable from persisted config: managedByDkg is operator-writable and resolveAdapterOptions actively rewrites it to false, while atomicUpdates is synthesized as true by that same function. Hence the data-less, symbol-transported handle described above.

Lane session state machine (system-record-materializer-v1.ts). Owns lifecycle and policy but no bytes; the transaction is performed by an injected executor, which is what makes the plan's pure reference-model fault matrix possible without a live child. Every lifecycle transition runs inside a scheduler control barrier, supplied as a required dependency.

Always-on mutation denial. No always-on guard existed — the changelog's is gated on enabled, which is default-off. The guard now lives on the adapter, the only always-on choke point, and is checked before the atomicUpdates capability refusal since that flag is synthesized from config.

Owned connection pool (managed-http-client.ts). SparqlHttpStore dispatches through global fetch, whose sockets belong to Node's process-wide dispatcher, so "destroy the retired generation's client" was unimplementable. node:http.Agent gives the managed lane a pool it owns; undici is not a dependency here and does not resolve.

Explicit per-decorator capability discovery, in all four places — the two storage decorators, the changelog, and the agent's hand-rolled forwarder. Structural .innerStore walking would reach past a wrapper whose cache the lane must invalidate, and past the changelog's denial.

Scheduler admission (store-priority-scheduler.ts): generation permits, ordering domains, and one coalesced reserved control barrier — all strictly opt-in, with the existing run() signature unchanged and every pre-existing test passing unmodified. The hard constraint was the old behaviour: this scheduler is process-global and sits on every store operation, and its admission decision is deliberately entry-independent (canStart reads four integers and never inspects a queued entry). The entire extension therefore hangs off one integer comparison — while taggedQueuedCount is zero, nextRunnable() takes the original unconditional queue.shift(). That fast path has a witness rather than a comment: admissionEvaluations increments before the untagged early return, so it rises if selection ever walks entries the guard should have kept it away from, and a test asserts it stays at zero.

Managed child ownership (daemon/oxigraph-server.ts, oxigraph-managed.ts): one lifecycle mutex and explicit state machine replacing three unlocked closure booleans; a generation bound only after the spawned child is the proven listener owner, never at spawn. Three pre-existing defects fixed on the way — killSync() poisoned stop() so it never escalated to SIGKILL; the auto-revive timer handle was never stored and so could not be cancelled; and stop() resolved on the child's exit event without proving the port was released. A bind still served after the child exited now burns the lease terminal (port-release-unproven) rather than letting a replacement bind over a listener we do not own. Kills still go only through the tracked ChildProcess, so a foreign listener is never signalled.

Live conformance gate (devnet/issue-2052-managed-ownership/, .github/workflows/system-record-managed-ownership.yml, pnpm test:live:system-record-managed-ownership). Drives one real generation handoff end to end plus the capability, socket-ownership and predecessor matrices — see below.

Two defects this work caught

1. ChangelogStore silently swallowed reserved writes. Its insert()/delete() strip reserved-graph quads rather than refusing them, so with the changelog enabled a reserved write returned a resolved promise for a write that never happened — a lost update with no signal. Stripping stays correct for the changelog plane and ephemeral staging graphs; persistent state now denies.

2. The live gate failed on a real socket leak in this PR's own code. OwnedManagedHttpClient reported one live socket after destroyAndSettle(), because Agent.destroy() tears sockets down asynchronously. Returning there would have let a replacement child bind while a retired keep-alive socket was still open — precisely the stale-generation window the design exists to close. It now polls to zero under a bounded deadline and treats failure as terminal.

Merge-readiness review — all six findings addressed

Reviewed at b1c1bdf6d; fixes at d8b2a2d02. Every finding was validated against the code before being fixed, and every fix is mutation-proven rather than merely green.

#	Finding	Fix	Kill proof
1	BLOCKER — the live handoff bypassed the scheduler control barrier	barrier is a required dep on the lane; enable/disable/shutdown each open a named section; the adapter supplies one backed by runControlBarrier	adapter barrier → pass-through reproduces the reviewer's exact symptom; the live gate fails 3 of 20 checks
2	BLOCKER — a generation-raced success returned indeterminate without sealing	the final outcome is derived first and the seal keyed on it; attribution widened from a generation-string compare to the whole ownership snapshot	regression test: readiness lost with the generation string unchanged must still be indeterminate
3	HIGH — concurrent shutdowns each ran a teardown	runShutdown is no longer async, so this.transition is assigned synchronously before any await	removing the synchronous assignment reddens all three shutdown tests
4	HIGH — unknown names in the internal namespace were writable but hidden	generic mutation refuses the whole namespace except canonical UUID staging graphs	near-miss and future-name negative tests
5	MEDIUM — the live gate did not exercise what it claimed	the gate now drives the real supervisor, child and barrier; the workflow header enumerates what is and is not proven	see below
6	LOW — source encoding damage	repaired to clean UTF-8, verified byte-identical to base on pre-existing lines	git diff against base

Finding 1 in detail

runControlBarrier and sealStoreGeneration shipped in this stack exported, documented and covered by 25 unit tests, with zero production callers. The lane stopped the owned child, asserted its port free and bound a replacement while ordinary requests were still in flight on the retired generation.

The materializer stays store-agnostic — it takes an exclusive-section runner, not a scheduler — and the adapter supplies one using this as the opaque store identity, re-reading the lease snapshot's generation per transition rather than capturing the one observed at construction (the lane outlives any single child).

Shutdown under a barrier that cannot be acquired does not run the teardown, and that is the safe side: the lane still reaches terminal so nothing writes through it again, while the child is left alive under the supervisor that still owns it and stops it at process exit. Stopping the child outside a section is the hazard; "could not quiesce" is not a reason to do it anyway. The error propagates, because a shutdown that could not quiesce the store is not a clean one.

Unit tests bracket each transition and assert every child-touching step ran inside the section — but they inject a pass-through stand-in, so they cannot show that asking for a section does anything. All 41 of them stay green under the pass-through mutant. system-record-control-barrier-integration-v1.test.ts is the one that fails: real adapter, real process-global scheduler, real handoff composition, genuinely held-open ordinary request.

The live gate now discriminates

The gate previously minted ownership by hand and injected no-op supervisor methods, so it never restarted a child, never opened a lane and never ran a barrier — which is exactly why finding 1 passed it. Of the two directions the review offered (narrow the claims, or drive the real thing), this takes the second: narrowing alone would have left the gate structurally unable to catch a regression of the defect it is named after.

It now runs one real handoff first — startOxigraphServer owns and spawns the child, its lease and supervisorHandoff travel to the adapter under the symbol key exactly as the daemon composes them — against a 60,000-quad ordinary insert as the probe workload (one scheduler admission, one HTTP request over the store's own path). Ten measured checks: the write was still running when the lane opened; zero store requests inflight at the instant the child was stopped; the write survived; the generation advanced; a second OS process was spawned, the first PID is dead and the last alive; the replacement serves the same 60,000 quads; the store resumed against it; the lane reports enabled.

Proven to fail, not merely to pass. Built with the adapter's barrier replaced by a pass-through and re-run end to end:

childStoppedOnlyAfterOrdinaryWorkDrained: 1 store request(s) inflight
inflightOrdinaryWriteSurvivedTheHandoff: fetch failed
replacementServesTheSameData: 0/0 quads
-> FAILED (3 of 20 checks)

With the barrier restored: PASS: 20 checks, 3 predecessor entries. That negative control was not constructed — the first run of the new section hit a stale dist/ predating the fix and reproduced the reviewer's finding unprompted.

One measurement was reworked rather than tuned. The first shape compared wall-clock "stop happened after the write settled", which is subtly wrong: the scheduler releases admission when the store work resolves, and the caller's promise settles a few microtasks later, so a correct handoff measured as 0.09 ms too early. The pre-fix build read −49 ms, so any tolerance would have been chosen to sit between two numbers rather than to mean anything. Reading the scheduler's own inflight count at the instant of the stop has no such boundary — it is the quantity the barrier waits on.

Correction to an earlier revision of this description

A previous revision claimed a barrier asymmetry — a generation-scoped drain against a generation-blind hold — and warned that a future fix must be an allow-list. Re-read at this head, that description was wrong: isBarrierReady() waits on this store's whole taggedInflight, and the hold is seals > 0. Both are generation-blind, deliberately, because the transition is a child-process restart and the child it stops serves every generation. runningPermits feeds admissionGenerationsInflight and the timeout blocker report; the seal's generation is a diagnostic label, not an enforcement key. Narrowing either to the sealed generation would be strictly weaker and — generations being decimal counters — trivially bypassable. The scheduler's own docstring said "waits for the sealed generation's execution permits to drain", which is where the claim came from; it is corrected in this PR.

The related re-entry note also needs restating now that the barrier has production callers: a transition still must not re-enter run(), and the three that exist do not — they make supervisor calls, drain the adapter's owned pool, and invalidate a cache synchronously. The bound remains in place for the caller who gets it wrong.

Independent review — four earlier tracks

Every finding below was raised by an independent reviewer working read-only in its own worktree pinned to a specific commit, and each is fixed in this branch.

Protocol/safety. Two BLOCKERs, both demonstrated by an executed exploit rather than argued: shutdown superseded nothing while a transition was in flight, so a stalled enable resumed afterwards and started a replacement child after shutdown had proved the old one dead; and an open() that joined a shutdown never re-checked terminal state, so a shut-down lane revived and dispatched a record write to the executor. Both fixed and mutation-proven. The same track attempted eight forgery attacks on the ownership lease — structuredClone, spread, Object.assign, JSON.parse reviver, same-prototype, Proxy, and two more — and all were rejected; dual-package and worker-thread cases fail closed.

Execution/QA. The gate reported "PASS: 18 checks" while 13 were assertions over constants the generator hardcoded to zero. Deleted; it then reported 10, all measured, and now reports 20. leakedOwnedSockets was 0-or-throw by construction and is now a before/after pair. The manifest carried a fabricated commit SHA published as CI evidence — fixed, with a git cat-file -e check proven to catch it. Mutation-testing that fix surfaced a further hole: a crashed run left the previous PASS artifact verifiable, so run.ts now clears artifacts first.

Resource/operations. destroyAndSettle awaited before destroying, so its timeoutMs did not bound the phase it named (measured 3831 ms; no return at all within 8 s against a dribbling server) — now 5 ms. The negative capability memo latched permanently in 3 of 4 layers, so one probe inside a 1 s restart would have disabled the lane for the process lifetime. awaitRetiredWork was a structural no-op. A control barrier did not stop untagged traffic (20 ops started mid-transition → 0), and held calls were unbounded, rejecting 190/200 callers after they had waited out the seal → 0.

Supervisor handoff (036efc6b3). All remediated:

• BLOCKER — child_process.spawn throws synchronously for EACCES/EFTYPE/E2BIG/EINVAL. The .once('error') handler catches only async failures, so the throw escaped startCleanGenerationLocked and bypassed the only code that clears handoffPhase and re-arms backoff. Measured: 30 backoff periods later, still one spawn, port unserved, self-heal refusing — and terminal: false, so the lease reported "momentarily not ready" indefinitely rather than failing closed.
• HIGH — the port-release proof accepted a probe timeout as evidence of release. endpointAnswers() collapsed ECONNREFUSED (real evidence) and TimeoutError (no evidence) into one false.
• HIGH — nothing bounded the retired phase, and runShutdown() reached the first half without the second, parking the supervisor there indefinitely.
• MAJOR — a failed retire left the supervisor open and childless while ordinary store traffic still targeted the listener it could not account for; and the handoffPhase === 'retired' clause in scheduleRevive was inert (deleting it changed 0 of 57 test statuses).

The inert guard produced a standard now applied to this branch: every new guard ships with a test that fails when only that guard is removed. It was removed rather than papered over, and a second proposed guard was declined for the same reason. Later in the branch a shutdownWork coalescing field was added, its mutant survived twice, and it was deleted on the same standard.

One proposed fix was rejected as worse than the bug. The review (and I) initially proposed making a teardown-retire terminal for the supervisor. That would have been a serious regression: the managed child is the daemon's entire triple store, so disabling the system-record lane would have permanently killed node storage until restart. The phase is bounded instead — fail-closed for the lane, alive for every other consumer.

Measured, not asserted

Default-path cost of the scheduler admission work, re-measured independently after the fix:

variant	ns/op (median, 200k untagged ops)
base	3530.4
this PR (pre-fix)	3462.8
this PR (post-fix)	3462.9

+0.003% versus pre-fix, against ±10–20% within-variant spread — three orders of magnitude below the noise floor. admissionEvaluations = 0 on a pure untagged workload held across every round.

One number in an earlier revision of this description was wrong and is corrected here: a claimed heap-delta improvement of 19.2 → 13.1 MB was a GC-timing artifact (heapUsed sampled without forcing GC), not allocation volume. Re-measured as GC count the reduction is real and stable (307 → 260 → 223) but pause time is identical across all three, so the practical benefit is nil.

Known deferral

After a retire whose port-release proof fails, the supervisor terminates and cannot spawn again — but ordinary store traffic never consults the ownership lease, so the daemon keeps issuing SPARQL to an endpoint served by a process it could not account for. A FATAL log names the condition and tells the operator to restart.

Closing this properly needs an adapter-side kill switch, deliberately not in this PR: refusing all store traffic is a large change to the daemon's hot path and deserves its own review rather than riding in on a default-unused change.

A failed retire has three causes, and they want different answers:

• (a) something genuinely serves the bind — a leaked descendant of our own child, so the same RocksDB, and writes still land in the right store;
• (b) a foreign process took the port — the dangerous case;
• (c) the probes were merely inconclusive while nothing was on the port at all.

(c) is a direct consequence of the HIGH fix above. Once "no evidence" stops counting as "evidence of absence", an inconclusive probe is no longer treated as release. A closed loopback port normally RSTs immediately, so this needs the connect or its abort to lose a >1.5 s race under event-loop starvation — and AbortSignal.timeout fires from that same starved loop, so starvation often self-cancels. Plausible rather than likely. But #2052 is a store-pressure issue, so the one condition that produces (c) is the condition this feature exists for, and in (c) the FATAL-log-and-restart guidance is telling an operator to restart a node whose port was fine.

The coupling underneath it

A failed retire leaves the daemon storeless regardless of any kill switch, and closing the supervisor is not what causes it: bindReadyGeneration() throws on a terminal lease, so once the lease is terminal no generation can ever bind again. Without the close the supervisor is equally childless, merely less honest about it.

That is the same coupling rejected above, surfacing elsewhere: the lease is a lane capability, the child is the daemon's store, and today they share a fate. Burning the lease on an unproven release is correct and should stay irreversible; killing the daemon's storage as a side effect of it is not.

Attempting a revive after a failed retire would in fact be safe — if something really is on the port, the respawned child dies on EADDRINUSE and the ownership proof refuses to adopt the listener, which is an existing, tested guard. So the fix is decoupling lease-terminality from supervisor-liveness, not weakening any guard. The kill switch alone leaves the node storeless; the decoupling alone leaves bad traffic flowing. They want fixing together, and that is a larger design change than this PR.

Test plan

pnpm --filter @origintrail-official/dkg-storage exec vitest run \
  test/internal-graph-policy.test.ts \
  test/managed-oxigraph-ownership-v1.test.ts \
  test/reserved-internal-graph-mutation-guard.test.ts \
  test/system-record-materializer-lifecycle-v1.test.ts \
  test/system-record-control-barrier-integration-v1.test.ts \
  test/system-record-capability-discovery-v1.test.ts \
  test/store-priority-scheduler.test.ts \
  test/store-scheduler-system-record-admission.test.ts

pnpm --filter @origintrail-official/dkg-storage build
pnpm --filter @origintrail-official/dkg-core test
pnpm test:live:system-record-managed-ownership

Guards are mutation-proven rather than merely green. Beyond the barrier proofs above: forcing the lease identity check to true kills exactly the two identity-forgery tests; relaxing the reserved-name check to a prefix match kills the near-miss test. Every mutant was verified applied by grep and then reverted.

⚠️ Full CI is NOT running on this PR yet — do not read the green ticks as full validation

.github/workflows/ci.yml triggers on pull_request: branches: [main, testnet-canary, release/rc.12, rc17-vm-wip]. This PR is stacked on feat/2052-system-record-core, which is not in that list, so the root pnpm test lanes do not run here. The checks currently green are only the path-filtered workflows: protocol evidence, SPARQL scalability lint, the managed-ownership live gate, and the RFC-64 Windows gate.

That is expected for a stacked PR and not a defect, but it is a merge gate, not a footnote:

• Do not merge this while it is based on feat/2052-system-record-core.
• Once feat(core): add bounded system-record V1 contracts #2103 merges, rebase only the B2 commits onto updated testnet-canary, inspect git range-diff, change this PR's base to testnet-canary, and let the full CI lanes run.
• Root pnpm test must be green there before merge, per the Revision 17 plan's Full Validation Gate.

Known environment caveats

• packages/cli/test/oxigraph-*.test.ts is effectively POSIX-only. On Windows it fails for environmental reasons (spawn EFTYPE on the extension-less Node stand-in; No prebuilt Oxigraph 0.5.8 binary for freebsd-x64, which those tests force deliberately; one systemd/uid-only case). Verified on Linux CI only.
• The plan's own CLI gate command does not work as written. pnpm --filter @origintrail-official/dkg exec vitest run test/oxigraph-managed.test.ts test/oxigraph-server.test.ts reports "No test files found" with two files but runs fine with one; npx vitest from packages/cli runs both. Flagging rather than silently substituting.
• packages/storage full-suite failures are load-dependent on Windows, always confined to the embedded oxigraph-worker path, which V1 leaves legacy. Established by measurement: the same files fail on main with none of this stack present (8 of 11 red in oxigraph-worker-resilience.test.ts), and they fail worse in isolation than in the full run — 5 s test timeouts against ~70 s of import cost. Linux CI is the gate.
• The CLI ownership work was likewise A/B-verified: control 16 failed / 24 passed, with changes 16 failed / 36 passed — identical failure set, 12 new passing tests, zero regressions.
• packages/core/test/system-record-golden-v1 fails on a Windows CRLF checkout (core.autocrlf=true, no .gitattributes) because the generator byte-compares against LF. Not a code defect; Linux CI is green.

Related

• Issue Reconnect-triggered background sync amplification can starve foreground catch-up #2052 (open, not closed by this PR)
• Stack B1 feat(core): add bounded system-record V1 contracts #2103 (open — temporary base)
• refactor(core): split System Record V1 protocol ownership modules #2104 — B1 decomposition follow-up; this PR imports only the frozen @origintrail-official/dkg-core/system-record-v1 barrel so that refactor stays independent
• fix(sync): converge public SWM catch-up across bounded repeat passes (#2050) #2076 — independent SWM regression surface, not a branch dependency

🤖 Generated with Claude Code

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[Jurij89]

Merge-readiness review

Reviewed commit: b1c1bdf6dfda2a615f0be3ee13758dcbba86d583

Verdict: not ready to merge. The ownership, capability-discovery, and reserved-state foundations are directionally sound, and the focused suite is green, but the production composition currently advertises an openable live lane without routing the child handoff through the store control barrier. I also reproduced three independent state-machine/policy defects. The first four findings should be fixed before merge.

1. BLOCKER: the live handoff bypasses the scheduler control barrier

runEnable() destroys the client and stops/restarts the owned Oxigraph child directly. buildChildHandoff() delegates directly to the supervisor. The scheduler provides runControlBarrier(), but there are no production callers of it (or sealStoreGeneration) outside the scheduler itself.

I reproduced this with the real SparqlHttpStore: hold an ordinary request unresolved, open the advertised lane, and observe the supervisor's stop step execute while that request is still in flight (stopWhileOrdinaryStoreRequestInflight: true). This violates ADR-0002's admission-seal/drain requirement and can turn valid store traffic into transport failures or allow stale-generation work across the restart boundary.

Current behavior:

sequenceDiagram
    participant Q as Ordinary request
    participant S as Store scheduler
    participant L as System-record lane
    participant O as Oxigraph supervisor
    participant X as Oxigraph child
    Q->>S: start request
    S->>X: request remains in flight
    L->>O: stop child (no barrier)
    O-xX: terminate
    X--xQ: transport failure / ambiguous result

Loading

Required behavior:

sequenceDiagram
    participant Q as Store traffic
    participant S as Store scheduler
    participant L as System-record lane
    participant O as Oxigraph supervisor
    L->>S: runControlBarrier(storeId, generation)
    S-->>L: admission sealed; tagged and untagged work drained
    L->>O: stop and prove release
    L->>O: start and prove replacement
    L->>S: commit generation/epoch transition
    S-->>Q: resume against replacement generation

Loading

Fix direction: route every enable/disable/shutdown lifecycle transition that can invalidate the client/child through externalStorePriorityScheduler.runControlBarrier() using the adapter's stable store identity and generation. Add an integration test with a real adapter/supervisor and an in-flight ordinary request. If that wiring is intentionally deferred to the CAS follow-up, keep this capability unadvertised/fail-closed until the barrier-safe composition lands.

2. BLOCKER: a generation-raced success returns indeterminate without sealing admission

In applyVerified(), the lane moves to reconciling only when the executor itself returns indeterminate. If the executor returns applied/already-applied and the post-read detects a generation change, the method synthesizes indeterminate and returns it while leaving the lane enabled.

Executable reproduction on this head:

{"first":{"outcome":"indeterminate","recoveryGeneration":"2"},"stateAfterFirst":"enabled","second":{"outcome":"indeterminate","recoveryGeneration":"3"},"calls":2,"stateAfterSecond":"enabled"}

The second dispatch should never have been admitted after an ambiguous first write.

Fix direction: derive the final outcome first, then transition to reconciling for every final indeterminate result, including locally synthesized outcomes. Treat loss of ready/valid ownership as part of the same post-dispatch attribution check, not only a changed generation string. Add a regression test asserting that a second apply is deferred and the executor call count remains one.

3. HIGH: concurrent shutdown callers can execute teardown twice

runShutdown() checks for an existing shutdown only before awaiting an in-flight open/disable. Multiple shutdown callers can therefore wait on the same transition, resume together, each create a teardown, and overwrite this.transition.

With a stalled/released open followed by two concurrent shutdowns, I observed:

{"destroy":4,"stop":4,"start":2,"state":"shutdown"}

Only three destroy/stop calls are expected in that scenario (the preceding lifecycle work plus one coalesced shutdown). Double stop/release proof is not a harmless idempotency assumption at a process-ownership boundary.

Fix direction: establish shutdown intent synchronously before the first await, or serialize lifecycle intents through a single transition loop/mutex. After every awaited transition, re-read and coalesce/preempt the current transition again. Add concurrent-shutdown and disable-vs-shutdown tests behind a deliberately stalled open.

4. HIGH: unknown names in the internal namespace are writable but permanently hidden

The policy states that an unrecognized internal name is neither sweepable nor writable (internal-graph-policy.ts). However, assertNotReservedInternalGraphV1() rejects only the two known persistent names. Generic adapter mutations therefore accept a future/near-miss name under urn:dkg:internal:atomic-graph-replace:, while prefix-wide enumeration filtering hides it.

I confirmed a graph named urn:dkg:internal:atomic-graph-replace:system-record-v1:future-reserved was admitted and dispatched once. This creates invisible durable state and leaves future namespace takeover/confusion risk.

Fix direction: generic graph mutations should reject every graph in the internal prefix except canonical UUID-shaped ephemeral staging graphs where that internal operation explicitly requires them. Add negative insert/delete/drop/replace tests for unknown and near-miss internal names while retaining the intended UUID staging lifecycle.

5. MEDIUM: the “live managed ownership” gate does not exercise the behavior it claims

The workflow says it proves properties of the separate process and listen socket (workflow lines 3-7), but the gate manually mints ownership and injects no-op supervisor handoff methods (run.ts lines 234-240). Its own model notes that it never restarts a child, opens a lane, or runs a barrier (model.ts lines 29-44). This is why finding 1 passes the advertised live CI gate.

Fix direction: either narrow the workflow/name/PR claims to endpoint and capability-policy evidence, or preferably drive startManagedOxigraph/the real supervisor, open the lane with active ordinary work, and assert drain, restart, generation, port-release, and socket facts.

6. LOW: source encoding damage should be cleaned up

packages/storage/src/adapters/sparql-http.ts contains a UTF-8 BOM and multiple mojibake comments (—, §, …); the devnet runner also contains a replacement character. Runtime strings do not appear affected, but this should be restored to clean UTF-8 to avoid permanent diff/readability noise.

Verification performed

• git diff --check: pass.
• Storage dependency-closure build: pass.
• Focused storage suite: 7 files / 129 tests passed (system-record-materializer-lifecycle-v1, scheduler admission, managed ownership/client, reserved mutation guard, capability discovery, internal graph policy).
• Managed-ownership devnet typecheck: pass.
• Four executable behavioral probes reproduced findings 1-4 on the reviewed head.
• Current GitHub checks are green, but only the path-selected gates ran. Full CI still needs to run after the stacked base is merged/retargeted.
• A CLI dependency-closure build was attempted, but two concurrent Hardhat compiler processes stalled in the pre-existing EVM-module build and were stopped; this is not counted as a PR failure.

Merge gates

1. Resolve findings 1-4 and add the missing concurrency/live-boundary regressions.
2. Make the live evidence gate exercise the real handoff/barrier, or accurately narrow its stated proof.
3. Merge PR feat(core): add bounded system-record V1 contracts #2103, then rebase/retarget this PR to testnet-canary and run the full CI matrix.
4. Refresh the PR description: its barrier asymmetry/re-entry notes are stale relative to this head, and the required architecture diagrams are missing.

The structure is promising, but advertising a live lane before the scheduler barrier and terminal-state semantics are correct would introduce exactly the restart/backpressure ambiguity this stack is intended to remove.

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[Jurij89]

Review addressed — all six findings

Reviewed head b1c1bdf6d → now 8447314c1. Every finding was reproduced against the code before being fixed, and every fix carries a kill proof. All six confirmed; none disputed.

#	Commit	Kill proof
1 BLOCKER — handoff bypassed the barrier	1784b8c8d	pass-through mutant reproduces your exact symptom; live gate fails 3 of 20
2 BLOCKER — raced success returned indeterminate unsealed	29dc6b1bd	regression test: readiness lost, generation string unchanged, must still be indeterminate
3 HIGH — concurrent shutdowns ran teardown twice	29dc6b1bd	removing the synchronous assignment reddens all three shutdown tests
4 HIGH — unknown internal names writable but hidden	29dc6b1bd	near-miss and future-name negative tests
5 MEDIUM — live gate did not exercise its claims	d8b2a2d02	gate FAILS 3 of 20 checks against a build without the barrier
6 LOW — encoding damage	29dc6b1bd	repaired; pre-existing lines byte-identical to base

1 — the barrier

Confirmed exactly as reported: runControlBarrier/sealStoreGeneration shipped exported, documented and covered by 25 unit tests with zero production callers.

SystemRecordLaneControllerDepsV1.barrier is now required, not optional. An optional barrier is one that gets forgotten, which is this defect; making it mandatory means a future construction site cannot omit it silently. Enable, disable and shutdown each open their own named section. The materializer stays store-agnostic — it takes an exclusive-section runner, not a scheduler — and the adapter supplies one using this as the opaque store identity, re-reading the lease snapshot's generation per transition rather than capturing the construction-time one (the lane outlives any single child).

One decision worth flagging, since it is not what your fix direction implies: shutdown under an unacquirable barrier does not run the teardown. The lane still reaches terminal so nothing writes through it again, and the child is left alive under the supervisor that still owns it and stops it at process exit. Stopping the child outside a section is the hazard; "could not quiesce" is not a reason to do it anyway. The error propagates, because a shutdown that could not quiesce the store is not a clean one.

The integration test you asked for is packages/storage/test/system-record-control-barrier-integration-v1.test.ts. Note what it demonstrates about the unit tests: all 41 of them stay green under the pass-through mutant, because they inject a stand-in barrier. Only the integration test fails, with ['stop','start'] observed while the request is outstanding.

5 — the gate now discriminates

You offered two directions; this takes the second. Narrowing the claims alone would have left the gate structurally unable to catch a regression of the defect it is named after.

The gate drives startOxigraphServer, its real child, and the real barrier, against a 60,000-quad ordinary insert. Ten measured checks, including: zero store requests inflight at the instant the child was stopped; a second OS process spawned with the first PID dead and the last alive; the replacement serving the same 60,000 quads. Built with the barrier replaced by a pass-through:

childStoppedOnlyAfterOrdinaryWorkDrained: 1 store request(s) inflight
inflightOrdinaryWriteSurvivedTheHandoff: fetch failed
replacementServesTheSameData: 0/0 quads
-> FAILED (3 of 20 checks)

That negative control was not constructed. The first run of the new section hit a stale dist/ predating the fix and reproduced your finding unprompted.

The workflow header now enumerates what is proven and what is not — predecessor entries run against the current binary rather than each pinned commit, and no verified apply is dispatched until the CAS lands.

3 — how the fix was reached, because the first attempt was wrong

I first added a separate shutdownWork coalescing field. Its mutant survived twice, including against your exact stalled-open shape: it never changed an outcome, because making runShutdown non-async already coalesces. It was deleted rather than kept — an inert guard reads as protection and is worse than none. Removing the synchronous assignment instead reddens all three shutdown tests, which is what identifies it as the load-bearing change.

A stale claim in my own PR description, now corrected

The description carried a "known asymmetry the CAS PR must resolve" section: a generation-scoped drain against a generation-blind hold. Re-read at this head, that was wrong. isBarrierReady() waits on this store's whole taggedInflight and the hold is seals > 0 — both generation-blind, deliberately, because the transition is a child-process restart and the child it stops serves every generation.

It came from the scheduler's own docstring, which claimed the barrier "waits for the sealed generation's execution permits to drain". Corrected in 8447314c1, because left in place it invited someone to narrow the drain to restore a symmetry that already exists — strictly weaker, and (generations being decimal counters) trivially bypassable.

Merge gates

gate	status
1. Findings 1–4 + regressions	done — 90/90 across the B2 storage files, plus the new integration suite
2. Live gate exercises the real handoff	done — PASS: 20 checks, 3 predecessor entries, proven to fail without the barrier
3. Merge #2103, rebase, retarget, full CI	blocked — #2103 is still open. Unchanged: do not merge this while it is based on feat/2052-system-record-core
4. Refresh the PR description	done — stale barrier/re-entry notes corrected, architecture and handoff diagrams added

On the storage full-suite failures in your verification notes: the oxigraph-worker files fail on main with none of this stack present (8 of 11 red in oxigraph-worker-resilience.test.ts), and fail worse in isolation than in the full run — 5 s test timeouts against ~70 s of import cost. Box contention, not this change. Linux CI is the gate.

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[Jurij89]

CI follow-up — the gate went red on its own harness closure, now green

My previous comment reported the live gate passing. It passed locally and then failed in CI on the first run at 8447314c1, so the record needs correcting: it was red for about fifteen minutes.

Cause, and it is worth stating because it is the same class as the finding above. run.ts now imports daemon/oxigraph-server by relative source path (the CLI exports no such subpath), and that module imports ./routes/status.js, which reaches dkg-agent, dkg-node-ui, dkg-publisher, dkg-chain, dkg-mcp and both adapters. tsc follows all of it, so every one of those needs real dist/ types — and the workflow's build step only built storage's closure. On my box they were all present from earlier builds, which is exactly why it passed here and only here.

Reproduced before fixing rather than reasoned about: renaming packages/agent/dist out of the way reproduces the same TS2307 class locally, restoring it clears them. The build filter now matches what the generate script already runs, which is the point rather than a convenience — a typecheck over a narrower closure than the run uses can only produce a false result in one direction or the other. No added cost; the generate step was running the same wide build seconds later anyway.

Fixed in e8788a840. Current state at that head:

check	result
Managed Oxigraph ownership (live)	pass — PASS: 20 checks, 3 predecessor entries, real handoff included
Storage unit conformance (inside that job)	pass — 7 files, incl. system-record-control-barrier-integration-v1
Protocol evidence	pass
SPARQL scalability lint	pass
SQLite lifecycle (Windows)	pending

Merge gate 3 is unchanged and still blocking: #2103 is open, so the full CI matrix has not run. Do not merge while this is based on feat/2052-system-record-core.

[Jurij89]

Merge-readiness review — round 2

Reviewed commit: e8788a840bbea5ab53aa231874e5394e14a4dc0f

Verdict: not ready to merge; one lifecycle blocker remains. Findings 1, 2, 4, 5, and 6 from the previous review are materially addressed: production lifecycle calls now use the real scheduler barrier, synthesized indeterminate outcomes seal admission, the internal namespace guard is prefix-wide, the live gate drives a real child handoff, and the encoding damage is repaired. The shutdown fix narrows finding 3, but an older transition can still erase the shutdown intent and allow a later transition to revive the terminal session.

1. BLOCKER: a superseded open() can erase shutdown intent and let disable revive the terminal session

The new synchronous assignment in runShutdown() correctly coalesces callers that arrive while this.transition still points at shutdown. However, an older open() still clears this.transition unconditionally in its finally, even after shutdown has replaced that pointer. close('disable') has the same unconditional cleanup pattern (lines 371-377).

I reproduced this against the real StorePriorityScheduler, not a pass-through barrier:

1. Open, disable, then begin a re-open stalled in startAndProveCleanGeneration.
2. Request shutdown; it synchronously installs the shutdown transition and waits for the re-open.
3. Release the re-open. Its older finally clears the shutdown transition while the shutdown handoff is stalled in stopAndProveOwnedChildDead.
4. Request disable. Because the shutdown pointer is gone and state is still enabled, disable is admitted and queues behind the real shutdown barrier.
5. Release shutdown. Shutdown sets state to shutdown and releases the process-global registration; then the queued disable runs and overwrites state to disabled.

Executed result:

expected session.state: shutdown
received session.state: disabled

This breaks the terminal-state and single-controller invariants: the old controller is nonterminal again after its registration has been released, so it can coexist with a replacement controller and may be reopened in a later stack.

The race is:

sequenceDiagram
    participant O as Older open caller
    participant S as Shutdown caller
    participant D as Disable caller
    participant B as Scheduler barrier
    O->>B: enable transition (stalled)
    S->>S: install shutdown intent
    S->>O: await older open
    O-->>S: enable completes
    O->>S: finally clears transition (erases shutdown)
    S->>B: shutdown barrier / teardown
    D->>B: disable admitted behind shutdown
    B-->>S: shutdown completes; state=shutdown
    B-->>D: disable runs; state=disabled

Loading

Fix direction: do not let a transition clear a successor it does not own (if (this.transition?.work === work) ...), but do not stop there. Both open() and close('disable') resume after awaits using stale intent and must loop/re-read transition precedence before installing new work. A dedicated synchronous terminal/shutdown latch or a single serialized lifecycle-intent loop is safer than relying on a replaceable promise pointer. Release registeredController only once shutdown remains authoritative after every superseded continuation has settled. Add the exact real-scheduler regression above, plus trailing open and already-waiting disable variants; assert terminal state, one teardown, no post-shutdown barrier, and no second live controller.

2. MEDIUM: the live gate has no failure-safe process cleanup

measureLiveHandoff() stops the session/store/supervisor and removes the location only on the success tail. Any exception after startOxigraphServer() and before that tail can leave a live Oxigraph child and temporary store behind. That is particularly likely when the gate is doing its job and detects a broken handoff.

Fix direction: wrap the acquired handle/store/session/location in try/finally, preserve the original test failure, and independently attempt session.close, store.close, handle.stop, and rm. A deliberately failing handoff should exit promptly with no surviving child/listener.

3. LOW: the live workload uses a timing assumption instead of observing admission

The gate sleeps a fixed 250 ms before checking whether the 60,000-quad write is still active (run.ts lines 260-268). On a sufficiently fast runner, correct code can fail because the write completed before the sleep; on a slow runner it adds a fixed delay and a large payload merely to create overlap.

Fix direction: poll the scheduler snapshot until the write is observed in flight, then request the lane open immediately. Fail with a bounded diagnostic if the probe cannot be observed; optionally retry with a larger workload. This preserves the non-vacuous proof without tying it to machine speed.

Validation

• Incremental diff from b1c1bdf6d inspected; git diff --check passes.
• Storage dependency-closure build passes.
• Focused suite: 8 files / 142 tests passed, including the new real control-barrier integration test.
• A temporary real-scheduler regression test reproduced finding 1 and was removed after the run; the review worktree is clean.
• Current GitHub checks are green, including the revised live managed-ownership gate. The full matrix still has to run after PR feat(core): add bounded system-record V1 contracts #2103 merges and this PR is retargeted to testnet-canary.
• The local gate typecheck was not counted because its new CLI source import requires the full CLI build closure; the current CI job builds that closure and passes.

Once finding 1 is fixed and the lifecycle test matrix covers stale-transition cleanup, the architecture is substantially closer to merge-ready. Findings 2 and 3 are gate robustness improvements; they do not change the runtime lane semantics, but fixing cleanup in this PR is strongly recommended because this PR introduces the live process gate.

[otReviewAgent]

Operational Notice: Review Agent could not complete this review.

Business logic reviewer failed: WARNING: failed to clean up stale arg0 temp dirs: Permission denied (os error 13)

[Jurij89]

Round 2 addressed — all three findings, plus the class under finding 1

e8788a840 → 91d38870e. All three confirmed; one part of the round-1 fix direction is refuted with evidence, below.

#	Finding	Commit
1 BLOCKER	superseded transition erases shutdown intent	d5240115f
2 MEDIUM	live gate has no failure-safe cleanup	91d38870e
3 LOW	fixed sleep instead of observing admission	91d38870e

1 — confirmed, and worse than reported

Reproduced against the real StorePriorityScheduler, with adapter-exact wiring. Your expected shutdown, received disabled reproduces exactly. Downstream of it, measured:

• controller.open() then RESOLVES, spawning a fresh child after shutdown had proved the old one dead and asserted its port released, and applyVerified dispatches and returns applied — the round-1 hazard reachable again by a different route;
• a second close('shutdown') runs a second full teardown, 4 destroy / 4 stop for one session;
• the mirror through close('disable')'s own finally is equally real.

Negative control, which is what rules out a harness artifact: issuing the disable one step earlier — while the shutdown pointer is still live — ends correctly at shutdown. The erased pointer is the sole cause.

I did not patch the pointer a third time. Rounds 1 and 2 are the same root: seven of the nine writes to this.current happen after an await and none re-validated that it was still the authoritative transition, so terminality was asserted by readers and enforced by no writer. And shutdown had no representation before it committed — runEnable/runDisable publish enabling/disabling synchronously, but runShutdown wrote current only in its finally, so for the whole teardown the lane still read enabled.

Shutdown now commits current = 'shutdown' synchronously at intent, and every other write goes through commitState, which refuses to move off a terminal state. That is a change of carrier, not a third patch — and it is why applyVerified needed no admission change: a dispatch during the teardown now sees a terminal lane and returns capability-lost.

Three guards were deleted because the latch makes each one a branch that can no longer change an outcome: close's kind === 'shutdown' join, the current = 'shutdown' write in the teardown's finally, and if (readState() === 'shutdown') return inside the teardown — that last one is now always true and would have skipped every teardown.

One part of your fix direction does not ship, and I want to be explicit rather than quietly omit it. "Release registeredController only once shutdown remains authoritative after every superseded continuation has settled" is inert and harmful. Inert: runShutdown already joins the in-flight transition before the teardown starts, so any continuation that existed has fully settled, and with the install-guard none can install afterwards. Harmful: the finally is currently four await-free statements, so the terminal commit and the release are atomic; deferring the release opens a window in which the lane is terminal but the slot is still held, and a probe landing there hits the factory throw that sparql-http catches and memoizes as null for the store's lifetime — reintroducing a weaker form of the failure the release exists to prevent.

Relatedly, the write-order premise is inverted: the finally writes current = 'shutdown' before releasing the registration, atomically. The real ordering defect is the reverse direction — runDisable/runEnable writing current as their last statements after the terminal commit — which is what the latch and commitState fix.

Evidence. 41/41 pre-existing tests pass with zero assertion changes. 12 new interleaving tests; 7 fail against the shipped model, the other 5 are regression pins (I am not claiming 12 discriminators). Solo-mutant sweep: 11 of 11 guards killed. The 11th was earned — assertNotTerminal()'s post-join mutant SURVIVED the first sweep with all 52 green, while without it a superseded open() ran a full destroy/stop/start handoff on an already-terminal lane. The guard was load-bearing and the suite could not see the path; the test that kills it is the last one added.

The harness needed upgrading first: StallingHandoff can pause exactly one step, which is why the suite could express "shutdown behind a stalled open" but not "a caller arrives while the TEARDOWN is stalled" — and that second shape is where both rounds found their blockers.

2 and 3 — fixed, and the gate now catches finding 1

Cleanup is a resource stack unwound in a single finally, newest-first, each step caught independently and never masking the original error. I enumerated six throw sites in the unguarded window; the dominant one is lane.open(), so the leak was most likely exactly when the gate was detecting a broken handoff.

The sleep is replaced by polling getPressureSnapshot() until the write is observed in flight. Measured: the 60k-quad write commits in ~2.1–2.3 s, so 250 ms held with ~8x margin — but that was an accident of payload size, and at 10k quads the sample already reads false. The witness was also on the wrong side of the microtask boundary this file documents elsewhere, so both halves of the pair could have been green and vacuous at once.

The part worth your attention: my first attempt wrapped terminal-lifecycle checks around a sequential close('shutdown'). I built the pre-fix materializer into dist/ and re-ran — all 27 checks still passed. A sequential shutdown on a quiesced lane is correct even in the broken model, so those checks were regression pins, not discriminators: the same defect you found in the gate, one level up.

The gate now drives the interleaving instead — hold a re-open inside the supervisor's start step, request shutdown, release, then issue a disable into that window. Against the pre-fix build:

laneIsTerminalAfterShutdown: disabled
secondShutdownRanNoSecondTeardown: 2 child stop(s) across both calls
-> FAILED (2 of 27 checks)

disabled is your exact symptom, produced by the real supervisor, real child and real scheduler. With the fix: PASS: 27 checks.

Four checks that could not fail, found while verifying the above

1. Capability matrix ordering. Probing full registers the process-global controller; every later probe reaching the factory then gets a duplicate-registration refusal the adapter reports as undefined. So capabilityDeniedByEnabledChangelog and capabilityAbsentOnTerminalOwnership were satisfied by that backstop, not by the guards they name — deleting either guard would not have reddened them. Negatives are now probed with an empty registry and full goes last.
2. The deletion detector was one-shot. Entry 1's dropGraph either failed (as it must) or emptied the graph; entries 2 and 3 then read before=0/after=0 and passed. Reserved state is re-seeded per entry.
3. Enumeration was doubly shadowed — measured only on the graph-set-index composition, where two independent filters hide the prefix. It now also enumerates on the index-free store.
4. verify.ts would certify any artifact it found — no schemaVersion check, and sourceCommit stamped from current HEAD rather than recorded by the generator. Verify alone, or a CI cache restoring artifacts/, re-certified old bytes. Both are now bound.

Plus: the pinned-server temp store was never removed (12 had accumulated locally; a PID collision would seed on top of leftover quads and fail every predecessor row with a misleading seed incomplete), and predecessor rows now carry executedAgainst: 'current-binary' — the caveat previously lived only in prose the uploaded evidence does not carry.

Merge gates

gate	status
1. Findings + concurrency regressions	done — 124/124 across the B2 storage files; 11/11 solo mutants killed
2. Live gate exercises the real behaviour	done — 27 checks, proven to fail on the pre-fix model
3. Merge #2103, rebase, retarget, full CI	blocked — #2103 still open
4. PR description	refreshed last round; I will fold the terminality change in once CI on this head reports

Still standing: do not merge while this is based on feat/2052-system-record-core.

[Jurij89]

CI note at 91d38870e — the gate is green; two checks are being cancelled by the platform

Managed Oxigraph ownership (live): pass — PASS: 27 checks, 3 predecessor entries, and its storage unit step is 149/149 across 7 files. That is the check that actually exercises this change, including the new terminal-lifecycle interleaving.

Protocol evidence: pass.

The other two are not content failures, and I want the record straight rather than "CI is red":

• SPARQL scalability lint — its own scan step passed on every attempt (sparql-scale-lint: 0 new blocking, 0 acknowledged, 2 grandfathered, self-test 37/37), and the job was then cancelled during cleanup. The last attempt was cancelled before recording a single step.
• SQLite lifecycle (Windows) — first attempt died in Set up job with Failed to resolve action download info. Error: Service Unavailable, before any repository code ran; the next was cancelled mid-step.
• The live gate itself failed the same way once (Service Unavailable in Set up job) and passed on re-run with no code change.

That is a GitHub Actions degradation window, not this branch. I have re-run each several times; the conclusions are cancelled, not failure, and no step of ours reported an error. Worth a fresh re-run before anyone reads the ticks — I have stopped burning job minutes on it.

Merge gate 3 is unchanged and still blocking: #2103 is open, so the full matrix has not run. Do not merge while this is based on feat/2052-system-record-core.