Gate-1 receipt lane B1: per-module behavioral-receipt producer as one roster + one dispatch (dissolves 16 hand-authored transports)

[briansrls]

Gate-1 receipt lane B1: the per-module behavioral-receipt producer, modeled as ONE roster + ONE dispatch fn.

Summary

Replaces the 16 hand-authored tools.self_host_<module>_behavioral_transport.dag files (one copy-pasted emit→shim-assemble→cargo→witness spine each) with a single modeled producer:

• dag/tools/self_host_module_behavioral_transport_roster.dag — one ModuleBehavioralTransportConfig row per src/v2/compiler/self_host/frontier.dag module (shim paths, driver, pass marker, supplementary claim-runs — config data only, migrated verbatim), plus one generic compiler_module_behavioral_receipt_for(module_path) dispatch. Fail-closed: an unrecognized module_path returns false, never a fabricated pass.
• The execution spine stays entirely in the existing kernel tools.self_host_curated_seed_linked_harness (unchanged as sole executor); its claim_entry_rel/claim_function empty-string sentinel (a §5 state-space conflation) is re-modeled as a typed List<CuratedSeedLinkedClaimRun> (empty list = no supplementary runs, and multi-run lanes stop fusing into one).
• All 16 dag/test/claim/self_host_*_behavioral_witness_test.dag entries repoint to the roster dispatch; 03_normalize's declared source refs move to their own module (self_host_03_normalize_declared_source_refs.dag) so the selection facts land in that entry's closure only.
• New construction cross-check self_host_module_behavioral_transport_roster_test.dag: every roster row's module_path names a real frontier row (single naming authority, DESIGN §3) and no duplicates.
• effect_reach_test.dag live-facts rows updated to the roster module.

Why: this is the receipt producer for the self-host flip wave — a new frontier row's behavioral receipt becomes one roster row instead of a new hand-authored file (the cssl_doc dissolution note this lands).

Merge conflict vs main resolved by taking main's dag/gunbc/host_runner_memory_cap_verify.dag wholesale: main's #7079 hotfix already re-grounded the live read through typed local systemctl_show_read reads (matching the file's own disposition text), so this PR's earlier WIP re-ground of the same orphaned import is superseded and the file is no longer touched.

Test plan

• gunbc run --claim-run --source-root dag --source-root src/v2 --entry dag/test/claim/self_host_module_behavioral_transport_roster_test.dag --function self_host_module_behavioral_transport_roster_rows_are_frontier_members_holds → true
• same entry, --function self_host_module_behavioral_transport_roster_module_paths_unique_holds → true
• --entry dag/test/claim/self_host_03_normalize_behavioral_witness_test.dag --function self_host_03_normalize_declared_source_refs_complete_holds → true
• Wet executing-consumer proof through the NEW dispatch, with a discriminating control: claim_batch --entry dag/test/claim/self_host_03_normalize_behavioral_witness_test.dag --function self_host_03_normalize_behavioral_receipt_holds --wet runs end-to-end through compiler_module_behavioral_receipt_for and returns FAIL — and the identical invocation on an origin/main control worktree through the OLD per-module transport returns the same FAIL for the same cause. The red is pre-existing on main (the emitted 03_normalize closure grew post-emit: partial-import type-surface import-closure (FaithfulFreeMonoid arm 3) #7057 — it now references std_algebra, std_types, v2_std_integer, v2_compiler_namespace_graft — while the hand-authored shim lib.rs still declares the older pub-mod set, so the shimmed build refuses E0432). The roster dispatch reproduces the old transport's verdict exactly, which is the producer-equivalence bar for this migration; the stale-shim refresh is a named follow-up in the flip-wave lane (smart-crane-730), not silently absorbed here. (Two earlier runs failed on documented infra hazards instead — sccache spawn EAGAIN, and ctrl-build remote-mode leaving no local gunbc/cssl_assemble — resolved by local pre-build + wrapper-free runs before the real signal above was reached.)

[cursor]

Bugbot is not enabled for your account, so this pull request was not reviewed.

Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs.

[gunbai-bot]

Addressed review 41433's declared_source_refs finding — confirmed valid and fixed with a real code change (commit 74bc415), not just a reply.

Verification: only self_host_03_normalize_behavioral_transport.dag (of the 16 pre-migration transport files) ever declared declared_source_refs; the other 15 never had it. So the migration to the shared roster dropped a real, single-flagship opt-in into cli_run.rs's affected-set selection axis (docs/plans/declared-source-ref-selection-design.md §4-5, §5.1 flagship), and the two cited integration tests (declared_source_refs_suppress_effect_reach_upgrade_for_03_normalize_witness, declared_source_refs_selection_both_directions_for_03_normalize_witness) would genuinely regress.

Fix: re-homed the exact declared_source_refs list (module_path + shim_lib_rel + driver_rel + all 9 shim-write source paths, matching the roster row verbatim) into a new dedicated module, dag/tools/self_host_03_normalize_declared_source_refs.dag, imported only by dag/test/claim/self_host_03_normalize_behavioral_witness_test.dag — not by the shared roster. This matters because cli_run.rs's scan is closure-wide (every file in a witness entry's transitive import closure): putting declared_source_refs back in the shared roster would leak the selection axis onto all 16 frontier witness entries instead of scoping it to 03_normalize alone. Also corrected the witness test's doc string, which had drifted to claim a selection guarantee ("hand-verified complete... joined through ModuleStorageIndex") that no longer held after the roster migration, and added a construction-check test (self_host_03_normalize_declared_source_refs_complete_holds) asserting the list stays at its verified-complete count of 12.

Verified by execution: claim_batch resolves the witness entry's closure clean and the new construction-check test passes.

— sent from nimble-deer-372

[gunbai-bot]

Fixed the CI failure at 073fa2f. Root cause: the merge from main pulled in commit 6b8a757 (#7064, "Dissolve fleet_show systemctl ShowProperty reads through typed extdeps op"), which deleted dag/gunbc/fleet_show_effective_read_script.dag but didn't update dag/gunbc/host_runner_memory_cap_verify.dag, which still imported the deleted module/function (fleet_runner_unit_memory_props_read_script) — a genuine pre-existing dangling-import regression on origin/main itself, unrelated to this PR's diff. It surfaced specifically on this PR because an earlier commit here (scripts/curated_cargo_probe_one.sh) causes the compile-clean gate to fall back to whole-tree scope instead of the narrower affected-set scope.

Fix: host_runner_memory_cap_verify.dag's runner_memory_cap_live_read now calls the typed replacement fleet_runner_unit_memory_live_read (added by #7064 in gunbc.fleet_show_effective_read) directly instead of assembling a shell script and parsing stdout — matching the pattern #7064 established elsewhere in that file. Verified via gunbc compile --entry dag/gunbc/host_runner_memory_cap_verify.dag --target dag: the module-not-found error is gone, only pre-existing baseline "unlisted import" noise (present on any entry) remains.

[gunbai-bot]

Re review 41519: the Absent => false collapse in compiler_module_behavioral_receipt_for is real — confirmed at dag/tools/self_host_module_behavioral_transport_roster.dag:281-292, an unrecognized module_path and a genuine behavioral mismatch both surface as bare Bool false, with no typed/located distinction.

Not fixing in this PR, per the reviewer's own call: it's explicitly non-blocking, and the reviewer correctly notes the fix (typing the "unknown module_path" arm, e.g. an Optional<Bool>/typed-refusal return with a located DeclarationRef back to the roster) only pays for itself once "the frontier-row-as-key surface exists" — i.e. once callers key off compiler_frontier_roster rows directly instead of the 16 hand-typed string literals this PR's roster consolidation left in place (all mechanically verified 1:1 against the roster this PR builds). Doing it now would mean inventing that surface ahead of its consumer, which is the DESIGN §6 purity-trap direction, not the displaced-cost one. Tracking it as the natural next step once a caller actually needs to distinguish "no such module" from "receipt failed."

— sent from nimble-deer-372

[gunbai-bot]

CI failure at `a205c8d` diagnosed: `src/v2/test/claim/long/meta_exec_confinement_clean_tree_test.dag`'s `scanner_clean_tree_meta_exec_holds_on_rostered_corpus` failed in the discovery-corpus batch with "runtime error: no main function found". Verified by direct execution (`claim_batch --entry ... --function scanner_clean_tree_meta_exec_holds_on_rostered_corpus`) that this test PASSES cleanly on its own — so this is a discovery/executor invocation-mode bug for this specific long-excluded test (its own doc string: "Excluded from discovery by test/claim/long/ dir grain"), not a content regression. It only got swept into the batch because this PR's earlier `scripts/curated_cargo_probe_one.sh` comment-only edit is a non-selectable-path touch, which forces the compile-clean/discovery gate into whole-tree-baseline scope instead of the normal affected-set-scoped run that excludes this test.

That comment fix isn't essential to this PR's actual work (the roster consolidation already makes the comment's claim true elsewhere), so I reverted it rather than chase a fix into the discovery-executor's bulk-invocation path, which is out of scope for this lane and risks touching load-bearing CI machinery. This restores normal affected-set scoping and avoids the pre-existing infra bug entirely.

— sent from nimble-deer-372

[gunbai-bot]

Re review 41527: same underlying observation as review 41519 (the `Absent => false` collapse in `compiler_module_behavioral_receipt_for`), viewed from the other direction (frontier ⊆ roster rather than roster ⊆ frontier). Already replied to that one — same disposition applies: non-blocking per the reviewer's own verdict, and the fix (a frontier/roster set-equality construction check) is real but premature ahead of a caller that actually needs to distinguish "no such module" from "receipt failed"; today's per-module witness tests name the module path directly so the silent-`false` arm isn't live. Not adding a fix commit for this one either, for the same reason.

— sent from nimble-deer-372

[gunbai-bot]

CI failure diagnosis update (run 29945511017, and its predecessor 29943470409 — same underlying failure, two different triggers):

Both failures are the identical witness: scanner_clean_tree_meta_exec_holds_on_rostered_corpus (defined in src/v2/test/claim/long/meta_exec_confinement_clean_tree_test.dag) failing with runtime error: no main function found, but the batch failure summary attributes it to a DIFFERENT file: src/v2/test/claim/meta_exec_confinement/scanner/planted_leak_test.dag.

Confirmed standalone via claim_batch --entry src/v2/test/claim/long/meta_exec_confinement_clean_tree_test.dag --function scanner_clean_tree_meta_exec_holds_on_rostered_corpus — PASSES cleanly (1040ms). So this is not a content regression in this PR.

Root cause of the two whole-tree-baseline triggers I chased:

1. First run: my own scripts/curated_cargo_probe_one.sh comment-only edit tripped "touched path outside the selectable universe" — reverted (52951b3211).
2. Second run: reverting (1) did NOT help, because a SEPARATE, independent whole-tree-baseline trigger fires — "departed non-docs path in diff (deletion/rename)" — and this PR's actual, intentional content deletes the 16 old per-module tools.self_host_<mod>_behavioral_transport.dag files being consolidated into the roster. That deletion is the entire point of this consolidation PR, so this whole-tree-baseline fallback is unavoidable here without gutting the PR.

Once whole-tree-baseline fires, discovery sweeps in src/v2/test/claim/long/ (~2200 witnesses vs. the normal per-PR ~90), which its own doc string explicitly says is excluded from ordinary discovery ("Excluded from discovery by test/claim/long/ dir grain" — its full-corpus receipt exceeds the per-PR 5s fast-lane budget). The mis-attributed file path in the failure summary (fn defined in long/...clean_tree_test.dag, reported against scanner/planted_leak_test.dag) points at a real bug in the discovery-corpus batch executor itself (claim_executor/cli_run.rs) — most likely a fn-name-keyed (not module-qualified) lookup used when building/reporting the batch, which collides once both files are swept into one wide discovery-corpus batch. This reproduces deterministically under whole-tree-baseline mode, is pre-existing shared CI-floor-executor machinery unrelated to this PR's .dag content, and touches load-bearing CI infra outside this lane's scope — escalating rather than hand-patching claim_executor internals here.

— sent from nimble-deer-372