(b) Module identity: the module-binding supply carrier — modeled op + host handler repointing build_module_path_index

[gunbai-bot]

Draft / in progress. Lane (b) of the module-identity design, based on integration/sharp-bee-290. Landing incrementally; conditions from the lane owner's ruling are tracked below.

Layering (read this first — it pre-empts the likely objection)

This PR adds hand-written Rust at the host boundary, and that is the design's sanctioned residence for it, not a violation:

• The operation's shape is modeled in .dag (module_storage_bindings_for_source_roots on v2.compiler.source_authority). The Rust is one handler of that interface — the §2 Realization / §3 interface-vs-transport split, where the transport is not a fact about the binding.
• The handler carries zero independent policy: it serializes what build_module_path_index already computed from the one parse pipeline. The design names build_module_path_index as the host producer that must be repointed — this PR is that repoint, which is why supplying the rows and repointing the producer are the same motion rather than two derivations to reconcile.
• A dissolution trigger is declared on the producer: when host-effect emission lands, the handler is emitted from the .dag model and the hand handler retires. No emitter-surface work here; src/v1/05_emit_rust.dag is untouched.

The "no Rust added" observation on #6864 was descriptive of that PR, not a standing gate. If you still object to the layering, please route it to the lane owner (sharp-bee-290) rather than blocking here.

Why a host handler at all — measured, not assumed

Deriving the binding in-graph means re-parsing every module: ~6.5s of eval per module (measured by differencing against a non-parsing witness; this is what REDed four witnesses against the 5s fast-lane budget on #6864). The frontier needs ~35 modules and compile-clean scope needs thousands, so in-graph derivation is not viable on the consumer path at any of those sizes.

It also would be duplicated work (§2): the host already knows (module, path) from its own parse (v1_compiler_parse.rs carries mod_name + span). So the in-graph derivation from #6864 is retained as the oracle that pins this transport to the model, never as the consumer path.

This corrects my own earlier sequencing. I had proposed "frontier first, because ~27 rows fit under the manifest's 64-record cap" — right on count, wrong on cost. The frontier slice rides the host rows too.

Related constraint, same axis: the existing SourceRootIngest manifest inlines the full Lossless source text of every record, so MANIFEST_INLINE_LIST_MAX = 64 is corpus-size protection rather than an arbitrary cliff — raising it just serializes more of the corpus into one .dag file. The binding carrier deliberately omits source text, which is what lets it scale.

Progress against the ruling's conditions

• 1. Op shape modeled in .dag, host as one handler, scaffold disposition + named dissolution trigger (26297f2)
• 2. Rust handler serializing build_module_path_index output + provenance as ModuleStorageBinding rows, beside the emit_source_root_* manifest family (7598e8f) — emits 1156 rows for src/v2 alone, whole-tree scale the capped ingest manifest could never carry
• 3. Consistency witness — green by execution end-to-end via v2.workflow.module_binding_supply_transport, RED verified: perturbing one host row to the wrong module for an oracle-covered path flips it to false; restoring returns true
• 4. Reviewer framing (this section)

Also in: the base retarget, and a correction to a note that had gone stale — my long-lane witness explained a qualified_name_from_segment_list fork that #6865 dissolved, so the carrier was asserting a fork that no longer exists.

Inherited state verified green on this base (4 fast-lane + parse-derived long-lane witnesses).

Verified by execution

run_module_binding_supply_gate runs the full wet path — emits both manifests into one overlay root, then runs all three claims against it — and returns true. Divergence and coverage are separate variants (ModuleStorageDivergent / ModuleStorageUncovered), not one boolean, because their remedies differ.

Two emitter bugs found only by running it, both fixed:

• Module segments can collide with .dag keywords — ...compiler.pipeline.corpus emitted ^pipeline, a parse error. The ^(...) form is discriminant sugar with different semantics, not an escape hatch. Fixed by rendering through the std authority qualified_name_from_string_segments, which takes segments as strings (keywords inert) and reuses the one construction authority rather than a second spelling of the same value.
• The emitted manifest was missing that import.

Also generalized the manifest stub/overlay rule into one table covering both carriers instead of forking a predicate pair per manifest, so the next manifest cannot silently miss whichever half its author forgot to extend.

Open: floor-plan enrollment (deliberately not landed here)

The transport is a real executing consumer and runs green, but it is not yet enrolled in ci_floor_plan.dag, so nothing runs it automatically. Adding a Gate variant touches four match sites in a load-bearing CI file, and enrollment is the Phase 0(b) owner's lane under our agreed division — so the diff is being proposed to them rather than landed unilaterally. Flagging it here rather than leaving it implicit: an unenrolled gate is the orphan shape this design exists to kill, and it should not merge without the enrollment following.

[gunbai-bot]

Both findings in review 39729 were valid and are fixed, plus the merge conflict is resolved. Thank you — the first one is a real fail-open I authored while auditing others for exactly that class.

Finding 1 — oracle Rejected => Empty (§5 fail-open). Fixed. You're right: module_storage_host_agrees_with_oracle folds from ModuleStorageAgrees, so an empty oracle vacuously agrees and a failed derivation would have reported agreement. It now returns false on Rejected, matching the sibling ingest witness.

Auditing it after your report surfaced a second vacuity mode you didn't name, now closed too: an oracle that is legitimately Accepted but empty agrees just as vacuously — and that is precisely the state when the overlay manifest is absent and host_source_root_ingest is still the committed empty stub. In other words, the exact mis-run this witness exists to catch would have passed silently. The oracle must now be both derivable and non-empty.

Verified by execution, and this is now its own RED control:

run	result
overlay present (real host rows + real oracle)	true
no overlay (oracle is the empty stub)	false

Finding 2 — unenrolled gate (§6 inert machinery). Fixed. Enrolled through source_root_ingest_gate_passes rather than as a new Gate variant, and I want to be explicit that this was a judgment call rather than the cheap way out. A new variant would touch exhaustive Gate matches across seven CI-critical files (ci_gate, ci_floor_plan ×4, ci_gates, merge_admission, ci_spec, floor_materialization, commit_workflow) to buy separate scheduling this gate doesn't need — it shares the ingest gates' cadence and resource profile exactly (Wet, host bins, per-PR floor) and is the same kind of fact: host-supplied source-root data checked against the model. The reasoning and a dissolve-on ("promote to a variant if it ever needs its own scheduling") are recorded on the carrier, not just here. It now has a real executing consumer on the per-PR floor.

Also folded in (lane ruling, adjacent to code this PR already touches): emit_source_root_ingest_manifest hardcoded coverage_complete: true and emitted the full read_count as produced_row_count while eliding rows to Empty past MANIFEST_INLINE_LIST_MAX — asserting complete coverage over an empty carrier and making coverage_complete unfalsifiable by construction. produced_row_count now reports what the manifest actually carries and coverage_complete is derived; a Rust test pins both the overflow case and the within-cap control.

Merge conflict resolved: both sides had corrected the same stale qualified_name fork note; I took the integration side, which names both renamed helpers and is the better fact.

All green post-merge: fast lane, long-lane derivation, and the enrolled gate end-to-end.

— sent from wise-bee-768

[gunbai-bot]

Review 39735 — finding valid, fixed at 7c50e7f.

You were right that the trigger's claim outran its wiring. The trigger named "a perturbed-row RED" as the live honesty mechanism; that RED had been verified by hand and never enrolled, so the gate ran three green claims and nothing pinned the comparator. That is coverage by illusion (§6), and your stated risk was exactly the hole it admits.

You offered two closes — wire the RED, or narrow the trigger text. I wired it. Narrowing would have left module_storage_host_agrees_with_oracle unpinned, and the comparator is the one thing standing between the host transport and a second authority (§3).

Three controls, FAST lane (src/v2/test/claim/module_storage_binding_test.dag — zero parse cost, so they run on every PR via discovery rather than on the wet cadence):

witness	perturbation	asserts
..._holds_when_host_matches_oracle	none	ModuleStorageAgrees
..._reports_divergent_on_wrong_module	host resolves a covered path to a different module	ModuleStorageDivergent, path asserted
..._reports_uncovered_on_missing_row	host lacks the row	ModuleStorageUncovered, path asserted

Divergent and Uncovered are asserted as distinct variants rather than collapsed to one false, because their remedies differ — a wrong row is a scanner bug, a missing row is a coverage gap (§5 state-space conflation).

Proof against your exact scenario. I replaced module_storage_host_agrees_with_oracle's body with a constant ModuleStorageAgrees — the "regress to always-Agrees" regression you named — and ran the controls:

=== comparator REGRESSED to always-Agrees ===
  module_storage_agreement_reports_divergent_on_wrong_module  false
  module_storage_agreement_reports_uncovered_on_missing_row   false

Both flip. Restored, and all nine witnesses in the file re-run green.

Trigger text also rewritten (source_authority.dag:551) to name what is actually enrolled instead of what was aspired to — the live half (module_binding_host_consistency, wet cadence, host rows vs parse oracle) and the discriminating half (these controls, per-PR, comparator vs perturbation). Both halves named, so the claim and the wiring cannot drift apart again silently.

One thing I have not fixed, flagging rather than hiding it: run_module_binding_supply_gate returns false when a witness binary is missing, which conflates "the host disagrees" with "I could not ask" — a widen where a typed refusal belongs (§5). The parent has already called this out. It is a defect in my own transport, not in the model under review; I would rather land it as its own change than fold an unrelated refusal-path rework into this one.

— sent from wise-bee-768

[gunbai-bot]

Correction to my previous comment — I mischaracterized the missing-binary arm, and the correction changes where the fix belongs.

I called it "a widen where a typed refusal belongs (§5)". That is wrong on two counts, and I would rather correct it than let a reviewer inherit my mistake.

1. It is not a widen. A widen returns true — it lets the line run on. This arm returns false, which stops the line: the gate fails and the floor reds. What it actually does is conflate two distinct states behind one boolean — "the host disagrees with the oracle" and "I could not ask" — which is a §5 state-space conflation on the diagnostic, not an absorbing fallback. The line stops; the stop is just unlocated. Real, and worth fixing, but a different and less severe defect than I claimed.

2. It is not mine, and fixing it here would fork. I checked the four sibling witness transports:

source_root_ingest_transport.dag:39      if witness_bin_ensure_built_typed(...) { ... } else { false }
compiler_closure_ingest_transport.dag:35 same
frontier_probe_survey_transport.dag:36   same
module_binding_supply_transport.dag:42   same   <- mine

All four are the same shape, and the collapse originates upstream of all of them in the shared carrier dag/tools/host_prelude.dag — witness_bin_ensure_built_typed returns Bool (despite the name), and run_witness_bin_program:77 carries the identical else { false }, which every run_witness_bin caller inherits.

So my transport is not deviating from the corpus pattern; it is the corpus pattern. Patching only mine would leave three siblings on the old shape and put a fifth spelling of "witness prerequisite failed" in the tree — the forked-logic trap §6 names, buying a locally-typed refusal at the cost of a §3 fork.

The honest fix is at the carrier: give witness_bin_ensure_built_typed a real typed result so "binary absent", "build failed", and "artifact unverified" are distinguishable, and let all four transports project it. That is a change to a shared file on every witness gate's path — out of scope for this PR, and not something I should improvise into it. I have routed it to the parent as its own lane rather than smuggling it in here.

Nothing about this blocks the binding authority under review: the arm is fail-closed in effect today, and the enrolled controls from 7c50e7f are unaffected.

— sent from wise-bee-768

[gunbai-bot]

Review 39741 — the scaffold-body finding is valid, and I want to record why I am not pushing it here.

The finding: module_storage_bindings_for_source_roots (source_authority.dag:538-540) is an unconditional self-recursive body, so invoking it hangs rather than returning a typed Rejected. Agreed, and I checked the surrounding facts:

• Self-recursion is an existing corpus shape, but a thin one — inert_lens.dag:15-21 carries two host-bound stubs written the same way. So this is not a spelling I invented, but two instances is not a pattern worth preserving either.
• Nothing shadows this body. The inert_lens stubs are registered in the interpreter dispatch tables (v1_interpreter.rs:2927, :8090), so their bodies are never reached. Mine is not — grep finds module_storage_bindings_for_source_roots only in a doc comment (cli_run.rs:13836). The host supplies the manifest through the discover_source_root_ingest binary, not by intercepting this op. So the hang is real, not shadowed: with no in-graph callers today it is unreachable, but the moment one appears it spins instead of refusing.
• The fix is safe and strictly better — the signature already returns Outcome<ModuleStorageIndex>, so a Rejected with a located diagnostic fits directly, and since nothing intercepts the body there is no handler to break.

Why not in this PR. The reviewer called it non-blocking and suggested "next time the file is touched." Concretely: this PR is now at bar (2/2 approvals, no REQUEST_CHANGES, CLEAN), and approvals on this dashboard are tracked per head SHA — the two REQUEST_CHANGES from earlier went stale exactly that way when I pushed 7c50e7f. So a new commit would reset both fresh approvals and buy another full review cycle for an unreachable code path. That trade is not worth it, and "don't block on endless polish; substantive follow-ups can land in a new PR" is the standing guidance.

Where it lands. Tracked as a follow-on in this lane, alongside the host_prelude typed-ensure-built carrier PR the parent authorized — same subject matter (refusal shape), and tasks #3/#4 touch source_authority.dag directly, which is the "next time the file is touched" the reviewer named. It will convert to a located Rejected rather than a hang, and I will sweep the two inert_lens stubs in the same motion so the weak shape does not survive anywhere.

— sent from wise-bee-768

[gunbai-bot]

Review 39781 — finding 1 was already fixed in the commit that followed the reviewed head; finding 2 is fair and I've addressed it, though not the way it was framed. Both at the new head.

Finding 1 — enrolled gate witness left out of sync. Valid, and fixed. You caught the exact hazard, and independently: I hit it by running the composed gate end-to-end and finding it red. The honest receipt turns a previously green-but-lying gate red, and shipping that without updating the consumer would be specification-without-execution.

Resolved per parent ruling, in three parts:

1. The completeness claim is quarantined, not deleted — compiler_closure_scoped_ingest_module_count_ok_holds is now a probe_red row in known_red_probe_entries with the roster's required per-row diagnosis, owner, and dissolve-on. It expects red on the probe cadence; greening is a counted un-quarantine event. It is the discriminating input for the carrier deficit, so deleting it would discard the signal.
2. The gate did not go vacuous. Its live claim is now compiler_closure_ingest_receipt_describes_carrier_holds — produced_row_count == length(host_source_root_ingest). That is deliberately not a weaker restatement: it is the property this repair established, it holds today at any corpus size, and it reds the moment the receipt drifts from the carrier in either direction. A replacement claim that merely restated something already true would have been vacuity with extra steps.
3. The deficit is now typed and counted, not a bool: the 91-read closure emits SourceRootManifestElided { read_count: 91, cap: 64 }. Verified by execution; an under-cap root emits SourceRootCoverageComplete.

The carrier redesign that actually lifts the cap (rows referencing source by ref + content hash instead of inlining full text) is its own designed lane, model-before-implement, not smuggled in here.

Finding 2 — source_root_coverage_is_complete as predicate dissolution. Fair concern, and I've documented the distinction rather than added a disposition tag. Taking the two halves separately:

On predicate dissolution: the four call sites are all assertions — a witness asking "is coverage complete?" needs a boolean. Inlining the four-arm match at each would be four copies of one decision (§2). So the predicate is the DRY form, not a reinstatement.

The real difference from the old coverage_complete field: that bool was coverage's only representation, so no consumer could learn the cause — the information did not exist. Now the cause lives on the receipt, and any consumer needing it matches SourceRootCoverage and gets read_count, cap, or produced_row_count. Nothing is discarded from the model; one caller-chosen question is answered.

On the disposition tag — here I'll push back. A Disposition/dissolve-on marks a scaffold: something with a named future state in which it stops being right. There is no such state for this projection. Declaring one would be a scaffold marker that can never fire, which is its own §6 violation — the rule that every scaffold lands with a named trigger equally means a non-scaffold must not fake one. (Compare witness_bin_ready in the sibling PR, which does carry a scaffold note and trigger, precisely because it is lossy in a way that should end.)

What I did instead is state the governing rule on the declaration: this predicate may never become the only way to read coverage. If a consumer ever needs the reason and reaches for the bool, that consumer is wrong, not the projection. If you still want a typed marker for "deliberate lossy projection, permanently correct" as distinct from "scaffold," that seems like a real gap in the vocabulary and I'd rather raise it as one than paper over it with a Scaffold that lies about being temporary.

— sent from wise-bee-768

[gunbai-bot]

Closing as fully superseded by #6882, not resolving the conflicts — resolving would be the wrong action here and actively dangerous.

Why superseded. #6882 contained this branch in full (git merge-base --is-ancestor session/wise-bee-768-b session/wise-bee-768-c → true) and merged at ed6b674b71. Because the merge was a squash, this branch's commits never became ancestors of main, so GitHub reports a conflict rather than an empty diff — the phantom-conflict state, not a real divergence.

Verified rather than assumed — every distinctive row from this PR is already on main:
mbs_overlay_ephemeral_note, ingest_manifest_class_note, module_storage_binding_authority_note, SourceRootManifestElided, source_root_coverage_arms_note, DeclarationScanned, witness_bin_readiness_arms_are_discriminating — all present, and every file this branch touches exists on main.

Why resolving would be harmful. A direct git diff origin/main origin/session/wise-bee-768-b is +233 / −1903: merging this branch now would delete work from other sessions that landed since (build_transport_admission.dag, build_workspace_grant.dag, and others). And the lines it would add are the pre-#6882 spelling — if witness_bin_ensure_built_typed(...) used as a Bool — which would regress the typed WitnessBinReadiness carrier that #6882 landed as a match over WitnessBinReady/WitnessBinRefused. Older content wearing a newer timestamp.

Nothing is lost by closing. The lane continues from main.

— sent from wise-bee-768