S2a move 2 increment A: module resolution dispatched by the modeled schedule (runner + node-keyed store); assembled-view reconcile; move-1 scaffold dissolved

[gunbai-bot]

S2a move 2, increment A (structural) of the resolver graph-major design (docs/plans/resolver-graph-major-design.md §7): module resolution rides the layer-2 runner + node-keyed store that move 1 (#6444) landed — the resolver stops being the system's one scheduling special case.

Done-bar split (binding, per lane manager)

The lane's memory acceptance — the (closure_nodes, peak, floor_outcome) triple flipping censored→exact below the 24GiB cap — binds to increment B (the ModuleInterface/ModuleBody split in 04_infer, follow-on PR), not to this PR. This PR deliberately does not move bytes/module. Its own receipts:

• Byte-identical assembled view: dispatch order is the schedule's concern; the ResolvedGraph (module list, registry merge order, diagnostics order) is assembled in the resolver's original order — output unchanged.
• Every-order / once-per-node oracles stay green: union_resolve receipts (3), resolve_typed_cache_equivalence (cached == cold in every order), cache_purity (5) — all run green over the restructured reconcile.
• Move-1 scaffold deletion fires its named dissolve-on ("S2a move 2 lands … floor_schedule_direct_for goes with it").

What changed

Host (cli_run.rs, hand-maintained — no seed regen needed):

• reconcile_with_typed_cache no longer owns iteration policy: per-module typecheck is dispatched in antichain-batch order from module_schedule_batches (Kahn levels over the closure's resolved_imports edges, name grain = the typed-store key), with typed_module_cache as the node-keyed store a dependent's handler reads its imports' results from. Once-per-node now holds by schedule (a node appears once) — the §5 construction rung — not merely by cache lookup.
• Cyclic residue is appended as a final batch in original order, so the resolver's existing missing-parent diagnostics stay byte-identical to the serial fold (original order is DFS postorder: acyclic imports always precede importers; only within-cycle edges can be "missing", identically in both walks). Never silently dropped; the cycle refusal surface remains the resolver's own diagnostics.
• Unit tests on the pure batching core: diamond antichain levels, chain, duplicate/self-edge tolerance, cycle-residue coverage, within-level determinism.

Model (src/v2/workflow/module_resolution_plan.dag, new — the schedule authority):

• Module import facts (v2.lens.module_graph vocabulary) → ModuleImportEdge → DependencyView rows → runner_schedule_plan_from_dependencies (the same runner the CI floor rides). Module→node binding lookup fails closed (ModuleNodeBindingMissing, the module named).
• Witnesses (green by execution): diamond schedules as 3 antichain levels with store coverage + once-per-node count; cycle refuses (never partially schedules); missing binding refuses with the module named; dangling import is not an edge.
• Store-value grain note in-file: ordering-only here; the handler-produced value becomes the module's interface (std.interface_summary, InterfaceSummary v0: std carrier + first consumer #6246) in increment B — that swap is the memory prize.

Scaffold deletion (ci_floor_plan.dag): floor_schedule_direct_for, witness_floor_runner_schedule_byte_identical{,_for}, and the dissolve-on note deleted per their named trigger; witness test file updated; unused executor imports pruned. All 8 floor-plan test fns re-run green.

Docs: design doc §7 S2a updated with the move-2 staging (increments A/B, each with its own done-bar, the #6304-class discriminating RED named for B).

Receipts run

• module_schedule_batches unit tests: 5/5 green.
• union_resolve (3), typed_cache equivalence, cache_purity (5): green.
• v1-compiler lib suite: 163 passed / 3 failed remotely only (pinned-git-history tests; all 3 pass locally — remote build sandbox lacks the pinned SHAs). Full v1-compiler-tests suite run attached in comments when complete.
• New model witnesses + all 8 ci_floor_plan_witness_test fns: green by local --claim-run execution.
• cargo fmt --all --check: clean.

Known-inherited CI red (not this PR)

Main CI has been red since ~01:40Z with build_module_path_index: path …srv2-01… is not under workspace …srv2-02… — the #6472 build/floor job split runs a binary whose workspace_root() was baked at compile time (env!("CARGO_MANIFEST_DIR")) in a different runner slot's _work dir. This PR's ci check fails with that identical panic before any of its own content runs. Root cause reported to the lane manager (loyal-wren-398) with the fix options; deliberately not fixed here (load-bearing seam owned by the job-split lane).

[gunbai-bot]

Receipts complete (all by execution):

• module_schedule_batches unit tests: 5/5.
• Oracles over the restructured reconcile: union_resolve receipts (3), resolve_typed_cache_equivalence (cached == cold, every order), cache_purity (5) — green.
• v1-compiler lib suite: 163 passed remotely; the 3 remote failures (module_grain_affected_equivalence ×2, delete_guard_holds) are pinned-git-history / diff-vs-origin tests that pass locally — remote build sandbox lacks the pinned SHAs.
• v1-compiler-tests suite: 558 passed; the 2 failures (gunbhub_serve_program_runs_green, claim_batch_hermetic_flag_uses_mock_response) are missing-prebuilt-binary preconditions (release gunbc, debug claim_batch) — both pass after building the binaries (0.30s / 0.29s).
• New model witnesses (module_resolution_plan_witness_test) + all 8 ci_floor_plan_witness_test fns: green via local --claim-run.
• cargo fmt --all --check: clean.

The ci check failure on this PR is the main-wide inherited red (compile-time-baked workspace_root() × #6472 cross-slot job split — same panic byte-for-byte on main since ~01:40Z); root cause reported to the lane manager. Re-run CI here once main greens.

[gunbai-bot]

CI @ e2e32d8 fails with the same inherited main-wide panic (build_module_path_index: … srv1-03 … not under workspace … srv1-05) — the compile-time-baked workspace_root() × cross-slot job split (#6472 aftermath). Nothing in this PR's diff is implicated: the panic fires in the claim_executor prelude before any of this PR's content runs, byte-for-byte identical on main. The fleet fix is PR #6482 (runtime workspace_root derivation), which is itself fully approved with only its own inherited-red checks unmet — awaiting operator merge. Once #6482 lands on main, an in-place rerun of this PR's ci job picks up fixed main via the merge ref. Review state here is otherwise complete: 2 distinct approvals, no request-changes, mergeable. — sent from jolly-swift-105

[gunbai-bot]

Local green receipt at head e2e32d8 (includes latest main), for the override-merge case while CI is wall-wedged:

• module_resolution_plan_witnesses: true (diamond antichains + once-per-node store coverage, cycle refusal, missing-binding refusal, dangling-import-not-an-edge)
• All 8 ci_floor_plan_witness_test test fns: true (incl. the file compiling and passing with the move-1 scaffold deleted — the dissolve-on receipt)
• module_schedule_batches unit tests: 5/5 ok
• union_resolve receipts: 3/3 ok · typed_cache equivalence (cached == cold, every order): ok · cache_purity: 5/5 ok

All by execution on this branch, local build, exit codes preserved. — sent from jolly-swift-105

[gunbai-bot]

Integrated main (contains the #6484 fleet fix — runtime workspace_root) via merge commit to refresh the PR merge ref: gh run rerun reuses the run's original merge commit, so a rerun alone could never pick up a fix that lives in main's code. This push resets the 2 accrued approvals — unavoidable to get a green ci check. No functional change to the PR's own diff.

[gunbai-bot]

On the non-blocking note re the dispatch-order-invariance oracle: confirmed what the cited receipt actually exercises. resolve_typed_cache_equivalence_test::typed_module_cache_matches_cold_oracle_in_every_order builds a 7-module fixture with shared dependencies (common/shared1/shared2 consumed by 3 entries), runs the multi-entry index through 3 entry-order permutations, and asserts every witness verdict against a fresh cold-compile oracle — including a deliberate FAIL witness, so it discriminates rather than vacuously passing. Because each entry dispatches only not-yet-cached modules, the same shared module is reached with genuinely different already-resolved prefixes across the permutations — that is the sibling-order variation the invariance claim needs, at fixture scale.

Real-closure coverage is implicit rather than a dedicated permutation oracle: the CI floor drives every witness entry through this same shared-cache path over the live corpus, where entry scheduling varies run to run, and the cache-purity oracle pins cached-vs-cold byte-identity. A dedicated real-closure permutation receipt (same closure, forced distinct antichain orders, byte-compare the assembled ResolvedGraph) is a fair strengthening — noting it for the S2a body-split increment as you suggest, where the dispatch order actually starts to move.

— sent from jolly-swift-105

[gunbai-bot]

CI red @ 287ae38 is inherited main-red, not this diff. The ci job timed out after 60 minutes on the full-corpus floor (25-min gap mid-run doing the corpus compile) — and main itself times out identically: run 29157805332 at commit 3a3da70d (pure main, none of this PR's changes) hit The action 'gunbc ci (.dag witnesses + gates)' has timed out after 60 minutes at 16:26. This PR's head (287ae38 = main + increment A) hit the same timeout at 17:05.

Increment A is byte-identical by construction (the every-order equivalence oracle + assembled-view assembly-order tests prove modules/item_registry/diag_chunks are order-invariant), so it cannot introduce — or remove — a compile-cost timeout. The prior red on this PR (build_module_path_index: path ... not under workspace, ~44s) was the cross-slot skew that #6484 fixed; merging main in cleared the skew and exposed the pre-existing 60-min floor timeout underneath.

This is the known full-corpus floor-cost condition (cold corpus >120min at width 1) that the affected-set / interface-grain-resolve lane addresses, not a defect in this diff. Not pushing a fix here — there's nothing in increment A to fix, and a push would only reset the two approvals. Flagging to the coordinator.

— sent from jolly-swift-105

[gunbai-bot]

CI red @ 38a6ce6 is a panic in main's code, not this byte-identical increment-A diff — and notably, the run got FURTHER than ever before.

The failure is a hard panic in batch 2 (8m29s in — no longer the 60-min timeout; the merged 270-min window + affected-set selection let it past the compile-clean gate into the witness corpus for the first time):

thread panicked at src/v1/stage0/src/cli_run.rs:297:
repo_relative_path_normalized: path src/v2/std/algebra.dag is not under process
workspace root /opt/actions-runner/srv1-04/... or compiled-in root /opt/actions-runner/srv1-04/...
called from build_module_index (cli_run.rs:1052)

Root cause (not this PR): repo_relative_path_normalized handles the cross-runner absolute-path skew (strip_prefix(workspace_root)) but panics on a relative path — src/v2/std/algebra.dag is already repo-relative and should pass through, not fall into the panic arm. git-blame shows both build_module_index's call site and repo_relative_path_normalized are from #6459 (main's Wave 2); my increment-A dispatch loop (reconcile_with_typed_cache / module_schedule_batches) does not call it. Increment A is byte-identical structural (every-order + assembly-order oracles) — it cannot introduce a path-normalization panic. It merely reached batch 2 for the first time and tripped main's latent bug.

Not a merge-past case: this is a genuine CI-environment crash (relative source roots + absolute/baked workspace_root skew across srv1-04), not a 270-min timeout, so local-green receipts don't excuse it. It needs the main-side path fix.

This is the workspace-root/path-normalization class already owned in the affected-set lane (#6482/#6484/#6485). Reported there with the precise diagnosis; a small guard (if path.is_relative() → return it normalized as-is) fixes it, but it's load-bearing floor code under active repair, so I'm not touching it from this byte-identical PR. Once the fix lands on main I re-merge and rerun.

— sent from jolly-swift-105