Test what the change reaches, by measured coverage, not by guessing: a per-test impact map from the full run drives the fast tier #1279

The owner, 2026-10-13: "could we only test paths that are changed? like is there something we can do that's not an optimization but is just doing something more correct?"

Yes. The fast tier (#1198) picks tests by static imports within two hops, by name, and by what a red land taught: a guess, bounded by a budget. The correct version is measured: every test file's coverage, recorded once by the full run, says exactly which source files it executes; a pull's diff intersected with that map is the set of tests the change can reach. Nothing reached is skipped, nothing unreachable is run. The full gate on land stays as the proof for what the map cannot see (dynamic imports, routes bound by string, forge.json commands, environment).

Done looks like:

• [ ] The full gate (on land and nightly) runs with Bun's coverage per test file and writes scripts/test-impact.json: for each test/.test.ts, the set of src/* files it executed. Committed by the release like test-times.json.
• [ ] scripts/test-shards.ts --tier fast uses the impact map first: tests whose executed files intersect the diff, plus tests whose own file changed, plus the learned set; the import-hop guess is kept only for test files the map has never seen (new tests).
• [ ] A changed file that no test executes is said in the check line: 3 changed files reach 14 tests; src/web/x.ts reaches none — that is a coverage gap, filed by the sentinel.
• [ ] A changed forge.json, package.json, scripts/ or anything under src/kernel/ runs the full tier on push (the map cannot bound them).
• [ ] test/check-tiers.test.ts: with a seeded impact map, a diff to one source file picks exactly its tests; an unmapped new test is picked by the hop rule; a kernel change runs full.

Target: a one-file change runs its tests in under a minute, and the set is correct by construction, not by budget.

Bun-native flags that bear on this (from the research brief on #1242): --parallel[=N] with BUN_TEST_WORKER_ID, --shard=i/n --timings=<file> --update-timings balanced by recorded duration, --randomize --seed --rerun-each N for the flake hunt, --coverage-reporter=lcov one file at a time for the impact map. Prefer them to our own sharding where they fit.

Evidence from the first real fast check after 0.7.69 (#1280, run 01m4v94pk641ne5hzw5cntvwr1, 21:25Z): fast tier, 160 of 195 files for 12 changed (expected 27m04s, over the 5m budget). 146 of the 160 were chosen for one reason: imports src/http/server.ts. The import graph makes every page or route change the whole suite, so the fast tier is fast only for leaf changes. This is the case for a measured map: which tests actually execute a changed file, not which ones can reach it through the server hub. Acceptance to add here: a change to one page in src/web/pages runs the tests that executed that file, and the plan line says N of 195 files for M changed, by coverage.

Parked by the crew: the check failed ("the gate's list > every test/*.test.ts is in exactly one list, and every entry exists") and the decider saw no point in another try (pull #1281 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.