No workflow builds or tests the Rust crates — 59 tests have never run in CI

[hyperpolymath]

The finding

No workflow in this repository builds, tests, lints or formats the Rust
crates. A green PR here says nothing whatsoever about the Rust code.

Measured at origin/main:

$ git ls-tree --name-only origin/main .github/workflows/
.github/workflows/codeql.yml
.github/workflows/governance.yml
.github/workflows/hypatia-scan.yml
.github/workflows/label-triage.yml
.github/workflows/labels.yml
.github/workflows/push-email-notify.yml

$ git grep -cE 'cargo (test|build|clippy|nextest|fmt)' origin/main -- .github/workflows/
(no matches)

codeql.yml does not close the gap — its matrix is language: actions only
(codeql.yml:29), so it scans workflow definitions, not Rust.

Why this matters more than "a missing nice-to-have"

The repository already ships 59 #[test] functions across 8 files, and
not one of them has ever run in CI:

file	#[test]
crates/launcher-common/src/deed.rs	21
crates/launcher-common/src/standard.rs	14
crates/launcher-common/src/metadata_block.rs	8
crates/launcher-common/tests/deed_corpus.rs	5
crates/launcher-common/src/config.rs	3
crates/launcher-common/src/integration.rs	3
crates/launcher-common/src/template.rs	3
crates/launcher-common/src/discovery.rs	2

18 .rs files ship unverified by any automated gate. This is the vacuous-gate
pattern at repository scale: the checks list looks substantial, every one of
them is green, and the crate could not compile and nothing would say so.

It also means every Rust PR's evidence has to be pasted in by hand (see #44,
which quotes its local run for exactly this reason) — which works only for as
long as whoever opens the PR remembers to, and is unverifiable by a reviewer.

A second, smaller consequence: cargo fmt --check is already red on main
(rustfmt collapses a five-line app_license insert in
crates/launcher-common/src/template.rs to one line). Nothing detects it, so
any PR that runs cargo fmt --all silently pulls an unrelated file into its
diff.

Acceptance criteria

1. A workflow — name it rust-ci.yml — runs, on pull_request and on
   push: main, at minimum:
   • cargo build --all-targets
   • cargo test --all
   • cargo clippy --all-targets -- -D warnings
2. cargo fmt --check runs too, and the pre-existing template.rs drift
   is fixed in the same PR (or immediately before it) so the gate starts green
   rather than being introduced already red.
3. The job name is static and the job is not matrixed, so the rendered
   check name is stable enough to be made a required context later. If a
   matrix is wanted, do not interpolate it into name: — that suppresses
   GitHub's appended combination suffix and makes the name less stable.
4. Every action is SHA-pinned and .github/workflows/actions.lock is
   regenerated with gh actions-lock --no-narrow. Default fix mode
   de-pins SHA refs to floating tags — a supply-chain regression in a repo
   that pins everything (see gh actions-lock fix mode de-pins SHA-pinned action refs to floating tags — use --no-narrow metadatastician/marid#36). Never hand-edit the
   lockfile.
5. Non-vacuity proof, required before closing: with the workflow in place,
   push a commit that deliberately breaks a test (or introduces a clippy
   warning) and show the job going red; then revert. A green job on a
   healthy tree is not evidence the job would catch anything — a workflow can
   pass by never running the thing it claims to run.
6. cargo test --all reports a non-zero test count in the log, and that
   count is >= 59. A suite that silently collects zero tests exits 0.

Out of scope

Making the new check a required context. That is a ruleset change and
should follow once the workflow has a track record; filing it here would
couple a CI addition to a branch-protection change.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WPSJ7fBhVAMcpSffCBWUDo