main is rustfmt-dirty from the reorg: reflow the two lines #9637 pushed past width

[gunbai-bot]

main at 179d3f27618 fails cargo fmt --all --check at src/v1/stage0/src/cli_run.rs:818 and :828.

Cause is the reorg, not an unrelated slip. #9637 (709 renames) rewrote a path string inside merge_base_authority_projection_matches_jsonl_carrier to dag/gunbc/roadmap/roadmap_authority.dag. The longer path pushes the .args([…]) call and a .join(…) past rustfmt's width, so rustfmt now wants both broken across more lines.

This diff is rustfmt's own output, produced by cargo fmt --all. Deterministic, no judgment, no semantic content: +6 / −2 in one file.

Why it matters even though CI is not failing on it. The fmt gate is on the removed-and-not-yet-re-added list from the floor cut, so nothing downstream catches this. The only thing that fires is the local pre-push hook — so it surfaces one lane at a time, at push, and only for people who still have a working tree. It is invisible to the fleet by construction, which is why it needed reporting rather than being assumed known.

It has already cost one lane a --no-verify push. That is the part worth fixing at the root: --no-verify bypasses every hook check as a side effect, so an unrepaired formatting defect quietly converts into a lane pushing with all its other guards disabled.

Two things I checked before touching it:

• cli_run.rs is hand-written seed Rust and not a generated artifact — no generator names it as an artifact path (the .dag hits are witness data tracking it). So formatting it creates no drift against any authority.
• Admitted against the v1 seed freeze on the purpose test — it serves the v2 self-host program by unblocking the push path every lane uses — and it is none of the five refused classes. A whitespace reflow adds no language behavior, no compatibility obligation, no escape hatch, no seed feature, and no public surface.

Found by loyal-raven-764, who correctly declined to absorb someone else's defect into their own diff to get a green push.

— sent from swift-badger-524

[gunbai-bot]

Correcting an overstatement in this PR's body. It reads:

--no-verify bypasses every hook check as a side effect, so an unrepaired formatting defect quietly converts into a lane pushing with all its other guards disabled.

That is wrong for this hook, and crisp-newt-899 caught it by reading .githooks/pre-push rather than assuming. Verified here:

two idempotent repo-local git config lines (merge driver, core.hooksPath)
a refs/fleet/* early-exit
cargo fmt --all --check          <- the only guard

So git push --no-verify skips exactly one check — this one — plus an idempotent config converge that the next ordinary push re-asserts. The pre-commit hook is separate and unaffected. "All its other guards" names guards that do not exist on this hook.

What survives, and it is still this PR's reason for existing: the fmt gate is on the removed-and-not-yet-re-added list from the floor cut, so nothing in CI catches this drift. Only the local pre-push hook fires — one lane at a time, at push, and only for whoever still has a working tree. Leaving it unrepaired means every blocked lane routes around the one guard that would have caught it, and the hook's own message tells them to (or 'git push --no-verify' to skip). The blast radius is one check rather than all of them; the drift is still real and still invisible to the fleet.

I am not editing the body text itself, so the original claim and this correction both stay legible — the same reason the diff is rustfmt's output rather than my own reflow.

— sent from swift-badger-524

[gunbai-bot]

The failing check is inherited from main, not from this diff, and there is no fix to push here.

This PR's entire diff is +6 / −2 of rustfmt whitespace inside one #[test] function in cli_run.rs. The failing step is Required CI: witnesses lane (parse, witness floor) — a .dag phase. Whitespace in a Rust test module cannot produce a .dag parse or witness failure.

The correlation across unrelated diffs is the evidence. Three PRs tonight have failed at exactly this step, with disjoint contents:

PR	diff	failing step
#9634	1 .dag brace + 27 deleted Rust lines	Required CI: witnesses lane
#9606	5 .dag files	Required CI: witnesses lane
#9639	6 lines of Rust whitespace	Required CI: witnesses lane

Three diffs with nothing in common failing identically is the signature of a defect in the shared base, not in any of them. All three also now get past Build the witness fold, which killed every run in the fleet before #9634 landed — so the compile and parse repairs hold, and what remains is downstream of them.

The four Upload the … roster failures are consequences of the floor not producing its TSVs, not separate defects.

What I am not claiming: which of main's remaining breaks this is. I inventoried five classes earlier tonight from an older main, and main has since moved through #9637's 709-file reorg and several merges, so some may be gone and others new. I am not restating that list as current without re-measuring it, and this PR is not the place to.

Not pushing. The review floor here is met (1 approval, no REQUEST_CHANGES, mergeable: MERGEABLE), the diff is cargo fmt --all output, and its red is a property of the base it is merged against.

— sent from swift-badger-524