Falsifier cold-sweep reds: nfr roster burn-down + apply_role backfill; re-enroll cargo fmt in CI (de-fused from nextest)

[briansrls]

What the falsifier caught

The affected-set-falsifier has been red on every cold sweep since 2026-07-15 04:32 UTC (last green 07-14 23:10, run 29374839251). It was not broken — it was doing its job. Three discovery witnesses returned Bool(false) against the whole corpus, on drift that per-PR affected-set selection had predict-skipped. Bisected to the window c8169ef93b..00aa9ae2ef (15 commits) and attributed each root to its landing PR.

This PR clears the two non_fold_residue reds. The inert_carrier red is left red on purpose — it is a lens-precision question, not a dead scaffold, and papering over it would be the masked-green move. See below.

1. non_fold_residue — 3 stale rows burned down

Roster was 120 unique vs 118 live. Each stale row was checked for why it went stale, because "still wildcard but now lens-invisible" would mean deleting the row silently drops enforcement (the converge_cli_applied_knob_count trap already recorded in this roster):

row	why stale	verdict
nbd_proxy_serve.dag::shell_command_leading_lit_text	fn deleted by #6629 (RawLine body → typed session-lease effect)	genuinely migrated — fired the dissolve-on its row carried
nbd_proxy_serve.dag::shell_rawline_starts_with_tool	same	same
emit_host.dag::run_test_claim_emit_vs_eval_verdict	fn still exists (emit_host.dag:335) but #6650 enumerated its wildcard into 3 explicit constructor arms; no bare _ => remains	genuinely folded — ratchet tightens

2. non_fold_residue — 1 unrostered row backfilled

bash_composition_recognizer.dag::apply_role, landed by #6637. Two-special-variant dispatch over TokenRole's 5 variants (IfFraming/UnmodeledKeyword rebuild ScanState; Separator/JoiningControl/OperandFraming all reduce to the closed run, so enumerating would clone the general arm 3×). Same class as the orch_emit_let_step row directly below it — backfilled with reason + dissolution trigger so the ratchet re-arms (receipt #10).

3. Latent main red: cargo fmt --all --check fails on clean main

Not my lane, fixed because it blocks it. main carries exactly one fmt violation workspace-wide, landed by #6658 (fe6c586988, today 13:29).

RECEIPT: on clean origin/main, cargo fmt --all --check exits 1 with exactly one Diff in hunk; after rustfmt on that one file it exits 0. File is hand-written (a bin declared in gunbc.ci_spec), not generated — a source fix, not a hand-edit of a generated artifact.

Why nothing caught it (corrected — an earlier draft of this body wrongly claimed the CI fmt gate fires on every .rs change; it does not):

• cargo fmt --all --check IS modeled, in tools.rust_gates_ci::run_gates — but fused with cargo nextest run -p v1-compiler-tests in a single ProcessExit.
• That bundle (RustMonolithGate) was removed from CI 2026-07-11 by operator ruling (gunbc.commit_workflow:54), for good reasons that are all about nextest: ~37 GiB (the fleet's largest CI memory job), red on main, non-required → a permanent tolerated red. fmt (4.3s, parse-only, green) was collateral damage of the fusion (§3: two separable facts welded into one row).
• The ruling's declared replacement coverage is the pre-push hook (CommitCargoFmtCheck on GitPrePushHook). That coverage is provably not in effect: core.hooksPath in this worktree points at /home/briansrls/gunbc/.git/hooks, which contains no pre-push hook at all — not the repo's .githooks/ that carries the fmt check. A hook is opt-in per clone, bypassable with --no-verify, and absent in fresh container worktrees — i.e. an escape hatch (§5), and Dissolve the docs-only CI floor shortcut per its named dissolve-on: replace path-prefix skip (ci_spec.dag:344-465, ci.yml:180-199) with affected-set-scoped compile-clean (Ruling 1 path grain). Context: the shortcut's skip class (docs-only diffs) exactly shadows the doc_reachability orphan wall's sub #6658 is the receipt that it failed.

⚠️ This is a live gap, not just one bad file: nothing enforces fmt anywhere today. Raised with the operator; the fix (de-fuse the 4.3s fmt check from the 37 GiB nextest bundle, without re-enrolling RustMonolithGate — which the ruling explicitly rejects) is being decided separately and is not in this PR.

4. cargo fmt re-enrolled in CI, de-fused from the nextest bundle (operator ruling 2026-07-15)

The fix for #3's root cause. Not a RustMonolithGate re-enrollment — that stays rejected, and this doesn't touch it.

• Shape: standalone RunStep, first in the build job — a 4-second violation fails in 4 seconds instead of after the ~33min release build. build isn't protection-required itself, but ci needs:[build], so a red fmt blocks the required job by construction. The toolchain already installs the rustfmt component in ci_prelude_steps, so marginal cost is ~4s and no build.
• Step-budget discipline: gunbc_ci_job_timeout_policy_disposition requires "the backstop is the exact step-sum + prelude". The new step carries the aux cap and gunbc_ci_build_job_backstop_timeout_minutes() gains exactly one aux term (65 → 70). No step uncapped; sum stays exact.
• Authority updated, not left lying: commit_gate_rust_suite_removed_disposition declared "cargo fmt stays enforced by the pre-push hook". That claim is retracted in-row and the fmt half marked reversed. The nextest half and the RustMonolithGate rejection are preserved verbatim.
• ci.yml regenerated through the emit authority (expected_ci_yml), never hand-edited; trailing-newline gotcha handled.

Emitted diff is exactly:

      - name: cargo fmt --all --check (fast gate; fails in seconds, before the release build)
        run: "\"$CARGO_BIN\" fmt --all --check"
        timeout-minutes: 5

Green-by-execution (claim_batch, local)

PASS non_fold_residue_no_unrostered_or_stale (src/v2/lens)
PASS non_fold_residue_clean_holds            (dag/test/claim)
FAIL inert_carrier_no_unrostered_or_stale    <- unchanged, deliberate

Plus, for the fmt gate:

PASS generated_artifact_drift_witnesses   <- the real drift gate; ci.yml byte-exact vs expected_ci_yml
0 FAILs across ci_yaml_serializer / ci_compile_jobs / placement_grain / rust_gates_ci / ci_budget_tree

Discriminating RED controls (both changes):

• nfr: both witnesses were red on this same tree before the roster edit, green after.
• fmt: planted a violation, ran the exact emitted step command → exit 1 (caught); restored tree → exit 0.

No witness, assertion, or scan universe was weakened to get green.

⚠️ Open decision — inert_carrier / LocalAlias (needs a ruling, deliberately NOT resolved here)

The third red is LocalAlias, declared at src/v2/test/claim/resolve/qualified_module_projection_stripped_fixture.dag:5, landed by #6641. The fixture's own note says it best:

"Grammar lane G1 corpus fixture: no import lines … this module is intentionally not a *_test.dag discovery entry."

The inert lens computes is_test_dag(path) = path.ends_with("_test.dag"). The fixture is deliberately not named _test.dag, so it reads as production corpus while its only consumer is a test → "declared once, self-tested, zero non-test consumers" = inert. It is a fixture, not a dead scaffold. Its real consumer is the compile-clean gate.

Two defensible fixes, and I don't think this is mine to pick:

• (a) Roster it. Lowest risk, matches the 10 existing entries mechanically. But: .dag has no comments, so the row would be bare — a silent escape hatch with no reason or trigger, unlike the nfr rows above. It also conflates a fixture with the modeled-ahead-of-consumption carriers the roster is for. And the namespace-only resolution lane is actively producing more stripped fixtures → this recurs forever, and the roster degrades into a fixture registry (§2).
• (b) Fix the lens proxy so fixture modules under a test tree count as test scaffolding. Principled and kills the class — but is_test_dag has 10 call sites incl. the emit audit and the nfr scan, so it is load-bearing and beyond a "falsifier is red" brief.

I lean (b) on the recurrence argument, scoped to the inert lens's universe only. Escalating rather than improvising per the load-bearing bar.

Not in this PR

The live_deploy_apply_srv1_wet failure is a separate issue (srv1 sudoers dropin missing; deploy witnesses assert the decision function against fixture actors + emit shape, never srv1's live grant). Diagnosis reported to the operator; needs root on srv1 + a converge realizer, not a code change here.

[gunbai-bot]

Thanks — flagging the concat(..., "") shape is a fair catch, and I want to be straight that it's valid, not invalid: it is a genuine no-op. ci_release_build_line earns its concat because it folds --bin flags onto a prefix; ci_fmt_gate_line has nothing to fold, so the trailing concat(x, "") is pure noise and the bare literal would be strictly better.

I'm not pushing a fix for it in this PR, on cost grounds rather than disagreement:

• The change is semantically inert — the emitted ci.yml is byte-identical either way (verified: generated_artifact_drift_witnesses passes, and the emitted step is run: "\"$CARGO_BIN\" fmt --all --check" with or without it).
• Pushing now would cancel a release build ~15 minutes into a ~33-minute cold compile, stale both approvals on 153b774f1, and force a fresh ~45-minute CI cycle plus re-reviews — to delete a no-op concat. That's a bad trade against the "don't block on endless polish; substantive follow-ups can land in a new PR" guidance, especially as I've already burned ~30 minutes of runner time on runs my own rapid pushes cancelled.
• It is not a cost-shape defect (evaluated once at emit time), so the standing "bare minimum cost / always fix" rule doesn't bite here.

It rides the same tracked 🟡 dissolve-on already recorded in ci_fmt_gate_note: the hand-spelled argv collapses onto extdeps.cargo_build's typed cargo.Build.Fmt when the ci.yml emit seam can bind a typed cargo operation instead of a shell string — the same de-fork ci_release_build_line is waiting on. The concat disappears with it rather than needing its own trip. If you'd rather it go now regardless of the CI cost, say so and I'll push it.

— sent from swift-owl-116

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