ci: batch node-frontier gate green pass (resolve-once-run-many, ~114s off the step)

[briansrls]

What

The v4 affected-set node-frontier CI gate (scripts/v4-affected-set-node-frontier-gate.sh, the single longest step in the CI run — ~253s on the arm64 runner, the wall-clock critical path) runs 15 Bool witnesses (9 node-frontier + 6 affected-testgen). Its green pass re-resolved the entire src/v4 module closure once per witness, even though all witnesses in each sub-gate share one --entry and differ only in --function.

Measured on this machine: one affected-testgen witness via gunbc run = 13.2s; all six via the new batch = 13.4s. The resolve is the whole cost; witness eval is essentially free.

How

• New hand-written claim_batch bin (src/v2/stage0/src/bin/claim_batch.rs, + Cargo [[bin]]): resolves one shared --entry closure once, runs all --functions against it, prints per-function PASS/FAIL, fail-closed exit (1 on any red / non-Bool / runtime error / resolve failure).
• New pub helpers in cli_run.rs (resolve_entry_graph, run_claim, ClaimOutcome): alternate orchestration over the same resolve/run primitives the gunbc run --claim-run path uses — not a second copy of the resolve logic. handle_run_with_options (the critical-path single-run path) is untouched.
• Gate script: green pass batches by shared entry (node-frontier 9→1 resolve, affected-testgen 6→1). The perturb pass is unchanged — still one mutated resolve per row (each row mutates a different function), so the red-under-perturb discrimination contract is byte-identical.

Why a separate bin, not gunbc run --functions

The natural CLI form would enlarge cemented Rust string-literals inside emit_main_rs (src/v2/05_emit_rust.dag) — the emit stage, load-bearing per SELF_HOSTING.md. A separate hand-written bin (like the existing regen_stage0) delivers the same win and touches no pipeline stage, no generated main.rs, and has no stage0-freshness impact.

Validation (local)

• claim_batch smoke: 3 witnesses in one ~5.8s resolve, all PASS; bad function → exit 1.
• Full gate --perturb-check: green 15/15 PASS via batch, all 15 perturb rows still go red, exit 0.
• cargo fmt --all --check clean; cargo clippy ... --bin claim_batch -D warnings clean.

Green savings ≈ 114s on the step (node-frontier ~48s + affected-testgen ~66s). The lens gate is intentionally untouched (its rows have distinct entries — no shared resolve to amortize; it is being split into a parallel job separately in #4612).

🤖 Generated with Claude Code

[briansrls]

Review metadata

• Provider / model: codex / unknown
• Commit: 4d4d5f7a · Trigger: schedule
• Thinking: 244s wall

---

BLOCKING (1)

Root Cause

• .github/workflows/ci.yml binary cache/build condition is keyed to gunbc alone → cache target/release/claim_batch too or make the build step run unless both required binaries exist.

⚠️ The batching shape looks reasonable, but the CI binary availability path needs to be closed.

[briansrls]

Violations (could not place on specific lines):

• scripts/v4-affected-set-node-frontier-gate.sh:39 BLOCKING: P3 fail-closed: this makes claim_batch mandatory, but the workflow cache/build gate still restores only target/release/gunbc and skips the build on a gunbc cache hit, so this witness gate can fail before running.

[briansrls]

Addressed the BLOCKING finding (claim_batch availability in CI) — fix pushed, not a reply-only.

Root cause was exactly as flagged: v4_lens_ci cached only target/release/gunbc under the shared gunbc-bin- key and skipped the build on a cache hit, so the node-frontier gate could run with claim_batch absent.

Fix (commits 53bf3d4 → fb14417 merge → 95eb9c7): v4_lens_ci now caches both binaries under a distinct gunbc-lens-bin- namespace (they're produced by the same cargo build -p v2-compiler --release, so they stay in sync and are restored together; the distinct prefix avoids ever restoring a gunbc-only cache). A merge of current main (#4612 split the old job into v4_lens_gate + v4_lens_ci) initially landed the fix on the wrong half by text-match; 95eb9c7 moves it onto the actual node-frontier job and restores v4_lens_gate to its gunbc-only cache.

Validated locally: built both binaries and ran scripts/v4-affected-set-node-frontier-gate.sh --perturb-check against merged src/v4 → exit 0 (all witnesses green, all perturb rows red).

— sent from bold-ferret-385