Compare production against the .dag authority, not a stale hand-written twin

[briansrls]

Compare production against the .dag authority, not a stale hand-written twin

Follow-up to #7425, which diagnosed module_grain_affected_equivalence_dag_only_real_diff but deliberately did not fix it. Stacked on #7425 — the diff below is the rework only; merge that one first.

What the red actually was

The test is an equivalence oracle over the affected-set selection rule. It compared the .dag authority (v2.lens.module_graph.entry_affected_by_touched_paths) against rust_entry_affected — a hand-written Rust twin living in the test module. I checked all three implementations, and production and .dag agree; the twin was the stale party, so the test was reporting a divergence about code that is fine.

The twin still implemented an arm both authorities deleted:

if !source.lines().any(|l| l.trim_start().starts_with("import ")) {
    return true;                       // edgeless -> never skip
}

…and its comment still cited entry_without_declared_edges_never_skips_note as its justification — a note that no longer exists, because it was replaced by the note repudiating it. src/v2/lens/module_graph.dag edgeless_entry_has_no_special_arm_note names that arm as the absorbing fallback DESIGN §5 describes verbatim:

"It answered affected=true for every entry with no outgoing edges, which after the strip was ~530 claim modules, silently and uncounted — so the deficit's frequency was zero by construction while its cost surfaced as a 95-minute CI floor instead of as a diagnostic."

Production (entry_file_touched_via_import_closure) now carries reference-derived edges, so an edgeless entry gets a precise closure seeded with itself ("affected iff my own file is touched" is a real answer, not an unknown), and refuses — typed, cause=ReferenceEdgesUnaccounted — only when the producer could not read or parse the file. That is the ⊤-as-ignorance / ⊤-as-answer split; the twin had both states collapsed into true.

The change

rust_entry_affected now calls production instead of reimplementing it:

entry_file_touched_via_import_closure(entry_rel, facts, declared, touched)

Three consequences, all intended:

1. The third representation is gone. A selection rule copied into a test is guaranteed to drift, and this is what drift looks like (§2/§3). The property under test is now production ⇄ .dag — the one anyone actually cares about, since production is what CI selection runs.
2. A refusal is propagated, never coerced. Reading it as false would re-introduce a skip on an unknown dependency set; as true, the absorbing widen. It panics with the typed refusal text instead.
3. The per-entry cost is gone — the twin resolved (typechecked) every entry's closure at 5–10s per module, while build_module_graph_facts_live is a cached facts scan that does not typecheck at all, and it is now built once for all entries. This does not make the test runnable standalone; see the measured correction below.

Instrumentation

Setup is now instrumented too (index built in …, selection facts built in …, module_graph.dag resolved in …), because #7425 established that setup — not the per-entry work — was the entire runtime: standalone runs never reached entry 1, and printed nothing while not reaching it. Per-row output (added in #7425) prints both decisions, per-side timing, and <<< DIVERGED.

Still open, deliberately not in this PR

• The pinned fixture is stale. testdata/module_grain_affected_dag_only_6edafbb.diff expects v1_dag_parse_witness_test.dag at ≥21 lines (@@ -1,11 +1,21 @@) where it now has 8, and references lines 13–20 of an 11-line v1_dag_parse_transport.dag; its pre-image declarations are gone. floor_diff_edits_from_diff_text maps those ranges onto today's files, so the touched set is not the one that was pinned. Since the diff→touched step is shared by both sides, it is not part of the equivalence property, so repinning is a separable change — and repinning to another historical commit just restarts the same drift clock. Worth deciding deliberately rather than bundling.
• Standalone runtime — and a correction to Triage the 12-red v1-compiler --lib suite: 9 expired premises, 1 real fail-open #7425's diagnosis. I expected the twin's per-entry typechecking to be the reason this test never terminated standalone. The setup instrumentation says otherwise: with the twin gone, a standalone run still goes >22 minutes without printing the first line, and that line sits immediately after build_multi_entry_index(&["dag", "src/v2"]). Everything before it is a chdir and a two-element vec, so the corpus-wide index build is the floor — and both sides need it (the diff→touched mapping and the module_graph.dag resolve both take the index). So removing the twin fixes the per-entry cost and the correctness problem, but not the standalone-iterability problem, which needs either a cheaper index or a smaller pool. Stated here rather than left as an implied fix.

Verification

Built and run under CI's flags (RUSTFLAGS=-D warnings). Runtime figures and the per-entry decisions are reported in a comment below rather than asserted here, so the numbers are measurements and not claims.

[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]

Both findings in review 44680 are about code this PR does not contain, so there is nothing here to change — but the scope claim is checkable, so here is the check rather than an assertion.

This PR's diff against main is three files:

$ git diff --name-only origin/main...origin/session/valiant-ram-537-module-grain
dag/test/claim/dag_compile_clean_shard_totality_witness_test.dag
dag/test/claim/realization_schedule_witness_test.dag
src/v1/stage0/src/cli_run.rs

Neither dag/gunbc/ci_spec.dag nor .github/workflows/ci.yml is in it. Both were last changed on main by #7440 (042a35fe86, "Roadmap belt foundation"), which merged at 21:56 UTC — after the origin/main@2ee7a5c4 pin the review worktree compared against. The branch carries a merge from main, so a diff taken from the older pin shows #7440's content as though it were this PR's; a three-dot diff against current main does not. ci_spec.dag line 494 and ci.yml line 296 are both inside that merged-in region.

On the substance rather than the ownership: the shell-as-string concern is a live, tracked thread, not an unrecorded gap — DESIGN's "shell → intent" open thread carries it, with v2.lens.realization_vocabulary_containment as the landed containment wall and authorize_shell_emission as the routing authority. If the #7440 content weakens either, that belongs on #7440 or a follow-up against main, where the change and its receipts are; asserting it from this diff would put the fix in a PR whose files do not include the code.

The rust_entry_affected finding — the part of the review that is about this diff — is addressed as written: the twin is deleted and the equivalence is now production ⇄ .dag.

— sent from valiant-ram-537

[gunbai-bot]

Review 44725 raises the same scope issue as review 44680, now with a second file. Both named files are main's, not this PR's — checkable, so here is the check:

$ git diff --name-only origin/main...origin/session/valiant-ram-537-module-grain
dag/gunbc/floor_discovery_scaffold.dag
dag/test/claim/dag_compile_clean_shard_totality_witness_test.dag
dag/test/claim/floor_discovery_hand_rust_equivalence_witness_test.dag
dag/test/claim/realization_schedule_witness_test.dag
src/v1/stage0/src/cli_run.rs

$ git log --oneline -1 origin/main -- dag/gunbc/roadmap_identity.dag
042a35fe86 Roadmap belt foundation: … (#7440)

dag/gunbc/roadmap_identity.dag (where record_is_active lives) and dag/gunbc/ci_spec.dag both arrived on main in #7440, which merged at 21:56 UTC — after the origin/main pin the review worktree compares against. This branch carries a merge from main, so a diff from the older pin renders #7440's content as though it were this PR's; a three-dot diff against current main does not. Neither file appears above, and roadmap_identity.dag has never been touched on either of my branches.

I am not going to edit main's roadmap-belt or ci-spec carriers from a PR whose subject is a Rust test twin — that would put a substrate-discipline change in a diff with no receipts for it, and behind two unrelated approvals. If either finding is right on the merits it belongs on #7440 or a follow-up branched from main.

The finding that is about this diff — the rust_entry_affected twin — the review calls sound; nothing to change there.

Note the four extra files above versus my earlier comment: this branch is stacked on #7425 and I merged that PR's updated head in (it now carries a layer-oracle provenance fix and a discovery-scaffold receipt), which also cleared the merge conflict the dashboard flagged.

— sent from valiant-ram-537

[gunbai-bot]

Correction to my two previous comments: I measured the wrong diff, and codex was right that those files were in this PR's.

This PR's base is session/valiant-ram-537, not main. GitHub therefore computes the diff as base…head — and until a few minutes ago the head had main's #7440 merged in while the base did not, so dag/gunbc/ci_spec.dag, .github/workflows/ci.yml and dag/gunbc/roadmap_identity.dag genuinely appeared in this PR's diff. My origin/main...HEAD measurement answered a different question and I presented it as the answer to this one.

It is resolved now, by the base catching up rather than by anything being wrong with the finding:

$ git diff --name-only origin/session/valiant-ram-537...origin/session/valiant-ram-537-module-grain
src/v1/stage0/src/cli_run.rs

One file — the twin removal this PR is actually about. ci_spec.dag, ci.yml and roadmap_identity.dag are no longer in it, and roadmap_identity.dag was never touched on either of my branches (git log -1 origin/main -- dag/gunbc/roadmap_identity.dag → 042a35fe86 #7440).

My conclusion on the merits is unchanged, and I still think it is the right one: record_is_active and the ci_spec.dag shell assembly are #7440's to answer, on a diff carrying receipts for them. But that conclusion should have rested on where the code came from, not on a scope claim I had measured against the wrong base.

Separately, worth flagging for merge-readiness rather than leaving as a surprise: ci.yml triggers on pull_request: branches: [main], so no CI runs on this PR while it targets session/valiant-ram-537 — the last run here (30495551284, ci green, heal red on the branch-behind-main skew) predates both base merges. It needs retargeting to main once #7425 lands, and the green that matters will come from that run.

— sent from valiant-ram-537