[max-sixty]

status exists to predict run, and the two carried separate copies of the selection pipeline, each annotated as mirroring the other. They had drifted: run listed tests with the caller's build flags, status with none — so on a feature-gated suite the dry run under-reported against what run would actually execute, which is the one direction a dry run must never be wrong in. You act on status by not looking further.

$ cargo affected status                    # the only form that existed
… no mention of test_extra …

$ cargo affected run -- --features extra
    RUNS test_extra                        # ran a test the dry run never named

status now takes the same post--- passthrough as run and collect, and both commands go through a new plan.rs that owns the shared decision: list tests, diff against every reachable collect_sha, apply config rules, select, classify hit-exact vs hit-with-divergence, assemble the report. run.rs and status.rs keep only what differs for real — which stream, which tense, and whether anything gets executed at the end.

The same pass added the gates that would have caught the drift's smaller siblings: cargo fmt --check and a RUSTDOCFLAGS=-D warnings doc build (a broken intra-doc link compiles fine and fails nothing else — this one found two), plus a cargo msrv verify job, because rust-version = "1.94" is a promise to everyone installing from crates.io and nothing in CI built with anything but current stable.

Reading this

Review commit-by-commit. About 450 of the ±lines are mechanical and carry no semantic content: 113 accumulated rustfmt hunks in 2d49d4e, and 221 pub → pub(crate) declarations in bd6f898. The behavior change itself is roughly 30 lines.

commit	what
7d86d3d, fdbf6f0	the substantive refactor — new plan.rs (303 lines), run.rs 373→285, status.rs 279→233
2d49d4e	format the repo, and the fmt/docs gates plus .pre-commit-config.yaml that keep it that way
7e6b4d2	the MSRV job, and tests/CLAUDE.md for the scenario conventions
bd6f898	pub(crate) throughout — nothing here is a library
rest	module docs, one prune_and_report replacing three copies, named CacheStatus arms

Interfaces

cargo affected status [-- <nextest args>] is the only user-visible change, and it is purely additive — every existing invocation behaves as before. The --report-json schema (SCHEMA_VERSION 1), the CI summary line, and the DB schema are untouched, so there is nothing to migrate.

Testing

153 green (112 unit, 41 functional). status_prediction_uses_run_features was verified failing against the old &[] before being kept, per the repo's regression-test rule; status_accepts_explicit_double_dash_separator covers the clap surface. The binary was also driven end-to-end on a scratch crate through collect → status → edit → status -v → run → clean → status/run on both cache-miss paths.

Two gaps worth naming. Nothing asserts that status and run produce the same selection for a given state — the guarantee is structural (one code path) rather than pinned. And the three new CI jobs have never executed on GitHub; cargo fmt --check, the rustdoc gate and cargo +1.94 check were verified locally, but this PR is the first run of the workflow itself.

Known trade-off

status now runs check_shas_reachable — a few git calls, ~50ms — before printing its database inventory, where it used to print first. Accepted, since status then spends seconds in nextest list anyway.

This was written by Claude Code on behalf of max