Audit the materialization-kernel closing frontier

[gunbai-bot]

Summary

Lane F (brief from parent session still-bat-561, subject "Lane F — materialization closing contract, NO second cache"): this PR is an audit, not a closing contract. It records, per obligation in the brief's seven-step sequence, whether PR #7534's delivered v1-materialization-kernel machinery satisfies that obligation — Delivered / PartiallyDelivered / NotDelivered, each with a named reason citing an executing witness or the concrete blocking symbol.

This does NOT bind or accept v1-materialization-kernel. gunbc.materialization_kernel_closing_frontier_audit (dag/gunbc/materialization_kernel_closing_frontier_audit.dag) says so explicitly in its header note: the module's Delivered/PartiallyDelivered/NotDelivered verdicts are authored findings from an investigation, not execution-derived observations — a genuine closing contract would need each clause to carry a typed ExecutedPass/ExecutedRefusal/Unavailable observation with the verdict derived from it, and that machinery does not exist here. The AND-fold summary (materialization_kernel_all_clauses_delivered) is a derived summary over the audited rows for readability, not a roadmap execution contract, and the roadmap node's own red control/handback is not satisfied by anything in this PR.

No second cache mechanism was built; this is model + audit only.

Where the kernel's own closing contract actually lives: #7717 (merged to main) is the closing-contract statement for the dag/std/materialization_provider.dag door itself — four independent review passes closed every known forgery/omission path on the contract shape, and it's tracked at duplicate-work-graph-lens-design.md §11. This PR is the adjacent, narrower thing: whether the parent brief's seven per-clause obligations for the v1-materialization-kernel roadmap node are discharged by execution. Checked both directions after merging main: #7717 doesn't resolve or contradict any verdict below (it documents which of 7 consumer targets call the door, not whether resolved_graph_cache_id's warm hit is proven-by-execution to skip semantic recompute — a strictly narrower claim this PR's PartiallyDelivered verdict is about), and nothing here restates or duplicates #7717's contract-shape claim.

Status as of 2026-08-03 ~04:15 UTC (operator winding down — this is the state to merge from)

DONE, green by execution:

• The audit module and its 7 FrontierClause rows (dag/gunbc/materialization_kernel_closing_frontier_audit.dag).
• 11 witness tests, all PASS, incl. an expect-red AND-fold control (materialization_kernel_closing_frontier_audit_witness_test.dag).
• 4/7 clauses verdict Delivered: contract-exists-and-can-fail, corruption/wrong-identity/incomplete-content/over-cap refuse, bounded-eviction-and-full-store, hand-Rust-growth-tracked-live.
• Merged current main into this branch (post-Materialization provider kernel: closing contract + delivered-vs-not audit #7717/Record the native-at-small-scale status once, in one typed receipt #7718/Retry model + attempt lineage + legacy-attempt supersede (operator P3, re-dispatch of wedged item): StartNewAttempt{supersedes} clears the live srv1 legacy refusal walls; RetryMechanism/ResumeAttempt/WorkerTurn; legacy rows present as supersedable, not belt faults #7715/v1 emitter: extend Clone-bound WF propagation to FN/IMPL emission #7708/Run merge admission as ordered CI success stages #7522), regenerated DESIGN.md from source (tools.generated_artifact_gate::main_wet, exit success), and verified the merge did not silently drop any row two independent ways beyond the initial grep check: (1) git diff origin/main...HEAD -- dag/gunbc/design_document.dag DESIGN.md shows exactly one intentional hunk per file (the OOM entry insertion); (2) a byte-level oracle (strip common prefix/suffix lines, then common prefix/suffix characters within the changed middle) run against both files reports removed=0ch on both — pure insertion, zero bytes removed or altered anywhere else in either file.
• Content-checked Materialization provider kernel: closing contract + delivered-vs-not audit #7717 against this PR's 7 verdicts after main merged in (see paragraph above) — no contradiction, no staleness.
• Both required distinct-provider dashboard approvals in place at the current head 580e0357ae07c95c49d93c99e8d6f1d0a35d9fc3: claude (review 47751, opus-4-7) and cursor (review 47755, composer-2.5), 0 REQUEST_CHANGES outstanding.
• Dispatched the OOM root-cause as its own, separate work item (adhoc-44fb018f-81d, worker crisp-boar-681) rather than inside this audit — that worker now has its own draft PR Root-cause disk-tier repeat-resolve memory growth (>8GiB OOM on second resolve through v1 disk cache seam) #7728 open with the diagnosis handed off in full (defect location, repro via ulimit -v, sibling-test zero-diff-vs-main confirmation, candidate root causes). Nothing further owed here from that thread.

IN FLIGHT:

• CI run 30781126269 at the current head, pull_request event, started 2026-08-03T03:10Z — build and regen jobs already green; the ci job (historically ~41-42 min) is still running as of this update. This is the sole remaining item on dashboard-ops reviews 7686's merge_criteria.requirements: everything else (approvals, request_changes, active_reviews, open, draft) reports ok:true; only checks (pending) and mergeable (UNKNOWN, which historically resolves once checks finish) are outstanding. No further action from me is needed here beyond waiting for this run to finish — nothing to fix unless it goes red.

BLOCKED: nothing, on anyone. This PR does not depend on the OOM root-cause work (#7728) landing first — the PartiallyDelivered verdict on warm-hit-skips-semantic-recompute already correctly names the OOM defect as its blocking evidence and does not assume a fix.

NOT ATTEMPTED (by design, not oversight):

• lookup-ahead-of-index-construction — NotDelivered, correctly gated on the warm-hit clause above per the brief's own sequencing (can't validate ahead of construction until the warm-hit clause itself clears).
• real-production-invocation — NotDelivered; opt-in env var wiring exists but is explicitly not "production invocation" per the brief's bar, so no attempt was made to claim it.

If continued, next step would be: once CI goes green and mergeable resolves to MERGEABLE/CLEAN, this PR is merge-ready as-is (an audit-only artifact; nothing here is blocked on the OOM fix). No further code changes are anticipated from this session unless CI surfaces a genuine failure.

Update 2026-08-03 ~04:20 UTC — OOM root-caused and fixed (not by this PR, not merged yet): crisp-boar-681 (work item adhoc-44fb018f-81d) root-caused and fixed the disk-tier repeat-resolve OOM in draft PR #7728. Recorded here rather than only in a message thread, per the operator's "nothing may exist only in one session" directive:

• Actual cause: the resolved-graph seam suppressed provider routing on the PROBE direction only; the STORE direction never consulted the same suppression flag, so the provider bootstrap resolve reached the store branch and demanded materialization_provider_ctx while its memo slot was still empty (written only after the cold build returns) — triggering unbounded re-entrant rebuild, ~1 GiB of resolved graph per recursion level.
• My two candidate hypotheses in this PR's evidence field were REFUTED by execution — for the record, not to be re-derived: NOT the decode path (decode_v3_payload_from_file probes never fired — decode is never reached), NOT structural non-sharing across MultiEntryIndex instances, NOT install_cross_process_materialization_hit (a plain memo-insert, never reached). Also refuted: growth is entirely inside the FIRST resolve, not triggered by the second index as I'd framed it — the second index is only where a reader notices.
• Fix: store direction now honors the same suppression (skip counted, so the bounded bootstrap window stays observable), and re-entrant provider-ctx construction is now a typed located refusal rather than merely avoided per-seam.
• Verified (by crisp-boar-681, not by me): same_subject_resolves_share_one_graph_store_hits_v2_disk reproduces the SIGKILL on unmodified origin/main and passes with the fix (41.73s).
• Side finding, not fixed there either: a 34-module closure resolve costs ~1.05 GiB RSS at one level — the known per-module env-duplication cost, and what turned this recursion fatal within two levels rather than merely slow.
• What this means for this PR: once Root-cause disk-tier repeat-resolve memory growth (>8GiB OOM on second resolve through v1 disk cache seam) #7728 merges, the warm-hit-skips-semantic-recompute clause (currently PartiallyDelivered here) can be re-attempted — the previously-blocked discriminating witness should no longer OOM the runner. That re-attempt is explicitly not done in this PR (start-nothing-new during wind-down); it is the next lane's work, not mine tonight. This PR's verdicts stand as audited above and do not change until that re-attempt actually runs.

What's in it

• dag/gunbc/materialization_kernel_closing_frontier_audit.dag — the audit: 7 FrontierClause rows against the brief's sequence.
• dag/test/claim/materialization_kernel_closing_frontier_audit_witness_test.dag — 11 tests, incl. an expect-red AND-fold control per DESIGN §4b so a future silent regression from Delivered back to NotDelivered flips a real assertion.

Repeat-resolve OOM finding — one durable home

Investigating the warm-hit-skips-semantic-recompute clause surfaced a pre-existing, unrelated defect: a second real resolve through the v1 disk-tier cache seam in the same process reliably OOMs the process (measured: ulimit -v 6000000, allocation failure at 632 bytes, exit 134/core dump, growth from ~175MB baseline to >8GB RSS within seconds). This is not introduced by this PR — it reproduces on an already-merged, unmodified sibling test (same_subject_resolves_share_one_graph_store_hits_v2_disk in src/v1/tests/src/resolve_cross_process_cache_test.rs) with zero diff to the touched files versus main.

The full diagnosis, reproduction steps, and next trigger live in exactly one place: DESIGN.md Open Threads, "disk-tier repeat-resolve memory growth". The audit clause's evidence field and a one-line comment in resolve_cross_process_cache_test.rs both cite that entry rather than restating it — collapsed from three copies of the same diagnosis to one, per DESIGN §2/§3 (the exact class this audit checks for). Root-cause work is now tracked separately: work item adhoc-44fb018f-81d, worker crisp-boar-681, draft PR #7728 — not this PR's scope.

Host-boundary Rust test disposition (per still-bat-561's Lane D inflow measurement)

No new Rust tests were added by this PR — the audit examines PR #7534's existing Rust surface rather than adding to it. resolve_cross_process_cache_test.rs and materialization_provider_resolved_graph_consumer_test.rs are host-boundary by nature and not expressible as .dag floor witnesses (real subprocess spawn, byte-level on-disk cache corruption, concurrent-write races) — this paragraph is their stated disposition.

Test plan

• target/release/claim_batch --source-root dag --source-root src/v2 --entry dag/test/claim/materialization_kernel_closing_frontier_audit_witness_test.dag --functions <all 11> — all PASS.
• Merged current main (post-Materialization provider kernel: closing contract + delivered-vs-not audit #7717/Record the native-at-small-scale status once, in one typed receipt #7718/Retry model + attempt lineage + legacy-attempt supersede (operator P3, re-dispatch of wedged item): StartNewAttempt{supersedes} clears the live srv1 legacy refusal walls; RetryMechanism/ResumeAttempt/WorkerTurn; legacy rows present as supersedable, not belt faults #7715/v1 emitter: extend Clone-bound WF propagation to FN/IMPL emission #7708/Run merge admission as ordered CI success stages #7522) into this branch, confirmed by two independent content-level checks (three-dot diff + byte-level removed/inserted oracle, both detailed above) that no row was silently dropped, regenerated DESIGN.md from that authority, and reran the build/checks at the resulting head — CI run 30781126269 in flight as of this writing, build/regen green, ci job running.
• No Rust tests changed by this PR beyond the one-line comment collapse noted above.

[gunbai-bot]

Fixed (499978c): the disk-tier Open Threads entry was genuinely dropped from DESIGN.md — not by anything in this diff, but by the auto-merge/auto-heal commits (66d1cf4 merging main, 520e604 auto-heal) that landed on this branch after my last push, which reconciled the adjacent "five-minute CI gate" entry and lost this entry as a casualty. Restored it verbatim so the audit clause evidence and the Rust test comment both cite something real again (review 47584).

On review 47578's non-blocking == 7 observation: leaving it as-is — the test's own materialization_kernel_progress_pin_note already explains the identity-join rationale for the other count-avoidance decisions, and == 7 here is a guardrail against silent unaudited-clause addition, not a duplicated measurement of the same fact the per-id tests establish (those cover which seven, not that seven). Not worth a further edit.

— sent from quick-swift-501

[gunbai-bot]

Re review 47584: confirmed and fixed, correcting my earlier claim.

My first fix (499978c) directly re-added the disk-tier entry to DESIGN.md. That was insufficient and got silently reverted a second time by the ci-auto-heal drift regeneration (9d81fd2) — DESIGN.md's Open Threads section is a generated projection of dag/gunbc/design_document.dag's open_threads_blocks() fn, so a direct markdown edit with no backing .dag source entry doesn't survive the next auto-heal cycle. My earlier "Fixed (499978c)" claim on this thread was therefore stale by the time it posted.

The durable fix (674e625) adds the entry as a new li(text: "...") row inside open_threads_blocks() in design_document.dag, then regenerates DESIGN.md via gunbc run --source-root dag --source-root src/v2 --entry dag/tools/generated_artifact_gate.dag --function main_wet (the documented regen command) rather than hand-editing the markdown. Verified: rg -c "disk-tier repeat-resolve" now returns 1 for all four sites — design_document.dag, DESIGN.md, the audit clause (materialization_kernel_closing_frontier_audit.dag), and the Rust test comment (resolve_cross_process_cache_test.rs) — so the evidence claim is now true and, being generated from source, will regenerate correctly on any future auto-heal pass instead of being stripped by one.

— sent from quick-swift-501