The required Format check has NEVER been able to fail — continue-on-error since v0.1.0

[avrabe]

What

Format is one of seven required status checks on main. Its only
substantive step cannot report failure:

.github/workflows/ci.yml:47-48

      # Pre-existing cFS crates emit rustfmt deltas; v0.1 tolerates
      # them while v0.2 cleans the workspace up.
      - run: cargo fmt --all -- --check
        continue-on-error: true

A failing cargo fmt --check leaves the job conclusion success. The check is
structurally incapable of going red, and it was promoted to a required context
in that state.

The comment says "v0.1 tolerates them while v0.2 cleans the workspace up". We
are at v1.138.0.

Honest scoping — this is potency, not a concealed failure

CI's rustfmt currently finds nothing: the fmt step reports success on every
recent run, so the mask is not hiding a specific live violation. A local
cargo fmt --all -- --check returns rc=1 with ~891 hunks, but that is the
known local-vs-CI rustfmt divergence already recorded for this repo, not
evidence of a hidden CI failure.

The defect is that a required gate has no teeth — not that it is swallowing
something today.

Why it belongs on the "claims vs does" list

Branch protection asserts that seven checks gate main. One of them has never
been able to say no. Anyone reading the protection settings — or an assessor
reading them — would conclude formatting is enforced. It is not, and has not
been since d30a5e3 (2026-05-18, the v0.1.0 release).

Fix

Delete line 48. Expect to reconcile the local-vs-CI rustfmt divergence first, so
do it in a PR and read the CI result rather than a local one — a local cargo fmt on existing crates injects churn CI rejects, which is the documented trap.

Falsification

Wrong if a PR that introduces a rustfmt violation causes the Format check to
report failure on current main.

[avrabe]

Correction: the mask WAS hiding real violations

This issue (and the audit that produced it) said the mask was not concealing a
live failure — that CI's rustfmt "currently finds nothing", on the evidence that
the Format job reported success on every recent run.

That evidence was worthless, and for exactly the reason this issue is about.
continue-on-error: true makes the JOB green while the STEP is red. Reading job
conclusions could never have told us whether the step passed.

Removing the flag (PR #424) failed on the first run, and the step list shows
precisely where:

success  Run actions/checkout@v7
success  Run dtolnay/rust-toolchain@stable
failure  Run cargo fmt --all -- --check

So the gate has been masking real formatting debt for ~137 releases.

A second correction, to my own number. I first reported 891 files, taken
from cargo fmt -- --check | grep 'Diff in'. Those are hunks, each carrying
its own line number, so de-duplicating the paths did not collapse them. The real
figure is 106 files.

cargo fmt --all on those 106 files, cargo check --workspace clean, and CI's
Format check now passes with the flag removed — so the standing warning that
local rustfmt diverges from CI's did not apply here. It was worth testing rather
than assuming, because CI had begun rejecting the tree too.

PR #424 carries both the fix and the reformat as separate commits.

Blocked on #425: the required Kani gate is currently red on main (~14
engines failing in ~11 s each — infrastructure, not proofs), so nothing can
merge until that is fixed.

[avrabe]

Correction to this issue's analysis: the mask was hiding a live violation.

I previously said the Format gate had only lost its potency. I said CI's rustfmt reported success, and that local hunks came from local-vs-CI rustfmt divergence. That was wrong.

• What the log shows. CI's own Format step on main 3ec4a2f (job 104933185124) logged 893 Diff in hunks and Process completed with exit code 1, and the job reported success.
• Why it looked green. The jobs API reports a continue-on-error step as success as well, so only the log tells the truth. Reading the job conclusion as the step result is the confusion the mask produces, and it is the confusion I fell into.
• There is no divergence. The reformat generated with local cargo fmt --all passed fix(ci): the required Format gate has never been able to fail #424's unmasked check, and it passed again when regenerated today on main a1b0e17. The "divergence" belief goes back to June and had the same root.

#424 has been rebuilt with the corrections. The ci.yml comment no longer tells anyone not to run cargo fmt, and the PR body and FV-RELAY-VGATE-004 now state what the log shows, with the error kept on record.

🤖 Generated with Claude Code