Nothing in this workflow ever enabled the `crdt` feature, so every
`#[cfg(feature = "crdt")]` test was NOT COMPILED — not skipped, not
filtered, not reported. Measured at 4223dd3: 3,467 tests under the
`test` job's flags versus 3,746 with `crdt`. 279 tests had never
executed in CI, and 186 of them are in the library, whose
`cargo test --lib --features crdt` invocation CLAUDE.md lists as a
REQUIRED pre-PR gate. CI had never run a required gate.
Eight test binaries also contained zero tests under the old flags. They
built, ran, and reported `ok` with nothing in them.
This job recovers 275 of the 279. The other four are excluded on
purpose, each for a stated reason rather than left as residue: three are
m10_11_acceptance's PTY-doubled tests, marked "operator-invoked before
tagging, not CI-default", and one is the #157 CRDT undo repro, an
#[ignore]d marker for a known open defect whose arming belongs to that
defect's lane. Seven of the 275 arrive via m10-perf-gates in the
previous commit; this job carries the remaining 268.
ONE JOB, NOT TWO. The shape recorded in docs/active-work.md put the
GPU-requiring suites onto `gpu-render` "which already has lavapipe and
PMACS_REQUIRE_GPU". That job runs `cargo test -p pmacs-gpu` — a
DIFFERENT PACKAGE from the four root-package suites that would move
there, so co-locating them would mean adding a whole new invocation
rather than extending an existing one. Splitting also requires
enumerating which suites are GPU-requiring, and a suite added later
would silently land in the job that needs no GPU and skip there forever.
Running the whole corpus in one place with a working adapter cannot
develop that hole.
PMACS_REQUIRE_GPU is set because these suites do not fail without an
adapter — a37 and its siblings eprintln a skip and return `ok`, measured
at 9/9 in 0.17s versus ~4s for a real run. The build is --workspace
rather than root-only because those suites locate the `pmacs-gpu` binary
beside `pmacs`, and its absence is the documented cause of twelve
gpu_invocation_acceptance failures on a crdt sweep.
The external-tool install block from the `test` job is deliberately not
duplicated. It gates m4_acceptance, m6_5_repl_acceptance and
m6_8_multi_repl_acceptance, and none of those has a single dark test —
measured, not assumed. Installing clangd/zsh/fish/lua/rust-analyzer/
gopls/npm servers again would cost minutes to change nothing. The only
tool-gated code in the dark set is src/process.rs, whose two variables
need no install and are set.
Clippy for the crdt targets runs HERE rather than in the `clippy` job.
Clearing those lints once is not enough: the `clippy` job matrixes over
Lua flavor and never enables `crdt`, so without this step the targets
drift straight back out of compliance and the next job to compile them
is red on arrival — the exact state this lane found. One job now owns
"crdt compiles, lints, and passes."
Verified locally at the exact commands this job runs: clippy green,
doc tests green, and the full serialized sweep with PMACS_REQUIRE_GPU=1
at 3,715 passed / 0 failed / 30 ignored in 366s — identical to the
pre-change sweep, so the lint commit changed no behavior. The 35-minute
ceiling is justified in the job comment against that measurement plus
lavapipe and cold-cache headroom.
This job has NOT yet been proven non-vacuous. That is the next commit:
break a crdt-gated test, confirm this job goes red, revert. A leg added
to a corpus that is already green locally cannot otherwise be
distinguished from a leg that compiles nothing.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Levi Neuwirth
7a8746defc