A check never redoes work whose inputs did not change: results are kept per t… #12224

A fast check now skips a selected test file when a default-branch run already proved it green on the same inputs. This is the first half of step 2 only. I ran bun scripts/gate.ts (clean), tsc --noEmit and the tests that cover this change, and all pass. I did not run the full suite, and nothing has been tried against a real forge check yet.

What changed

• src/checks/kept.ts is new and holds the pure part:

- Key: the Bun version, platform, test file, the src/ files its impact entry names, the files it imports, and package.json, bun.lock, bunfig.toml and tsconfig.json. The base tip is not in it. - File format: it parses, formats and bounds the kept-results file. - Split:** it decides which selected tests are already answered.

• scripts/kept-input.ts is new and hashes those inputs from the checkout.
• src/checks/kept-store.ts is new and works like the impact-map store. The forge seeds each check's checkout with .forge-kept.json (named by FORGE_CHECK_KEPT). It takes the file back only from the default branch's own measuring run (keepImpact), so a pull's code never fills results another check reads.
• scripts/test-shards.ts:

- After a green coverage run on main: it records each green file under its key. - In the fast tier: it drops selected files whose key is kept and logs test/x.test.ts: kept from <commit>: nothing it reads changed. If every file is kept, it exits green.

• seedKept is added to ALLOWED_REMOVALS in src/kernel/destroy_reach.ts, exactly as seedImpact is, and docs/DEVELOP.md has a short note.
• test/check-kept.test.ts covers the key, the split, the file format, the bound, the store and the input hashing.

Never kept

• A test with no impact entry.
• A test or helper that reads the tree or starts processes: readFileSync, Bun.spawn, import.meta.dir and the like.
• A test whose src file finds its own place in the tree.
• Any test in the full tier, so the gate that lands a change still runs every test.

What I did not do

• Step 1, the measurement. I could not run it: it needs a copy of production's database (the last 500 run rows and their logs), which this sandbox cannot read. There is no repeat-rate number to put on the issue yet.
• The whole-check key in proven.ts. I left it alone. Its key includes the merged tree's hash, so it changes whenever main moves, and tsc and gate.ts genuinely read the whole tree. The saving here is in the tests, which are the expensive part.
• Steps 3 to 5. There is no sampled audit yet, no tsc or install sharing, and no "ran because…" line on the pull page.
• Flaky tests. A test that passed only on a retry is not excluded from being kept. That is a gap until the audit exists.

To try it

1. Let a green run of the default branch's verify tier finish. It logs kept results kept: N tests and test-shards: kept N green results.
2. Push any pull. Its fast-tier log should show kept results: N tests…, then kept from <commit> lines and N of M files kept, K to run.

Closes #12178

This pull makes the fast tier skip a selected test file when a default-branch measuring run already proved it green on the same inputs. Its key is the Bun, the tooling files, the test, the files its impact entry names and its imports. A skipped file is logged as kept from <commit>. The gate, tsc and test/check-kept.test.ts (plus check-tiers, run before the last two comment-wrapping commits) are green here. The forge's fast check will run the whole suite on this push. No real check has run with the kept results yet, so none of this has been seen on a real log.

Changes for @juniper's review:

1. Direction: I did not reorder the work. Whether this pull goes before #6534, #6611, #5276, #3316, #6217, #6428, #1242 and #1073 is the owner's call, and nothing in this pull needs it to go first. It touches only the check's fast tier, so if the owner wants it after them, it can wait unchanged.
2. Safety:

- A file that needed a retry is never kept. That covers the crash re-run, the alone re-run after a red and the beside-others re-run. A retried flag on each shard result carries this to the keeping step. - One kept file in ten (SAMPLE_EVERY) is run anyway. The choice is a hash of the commit and the file, so it is deterministic per commit and changes at the next one. This stays until an audit of kept results exists.

1. One file per shard: a measuring run puts one file in each process (covDir and measured both rely on slice.length === 1). So the files.length === 1 condition in the keeping step never drops a measured file. The keeping step and the split are now freshKept and answerKept in scripts/kept-input.ts. A test covers each one on a temporary tree.
2. Tests:

- New tests: a green first-try file is kept and answers the next run. A changed input runs. A retried, red, multi-file or unmeasured file is not kept. The sample is deterministic, and the tooling files are in the key. .gitignore lists both handed-over files. - keepKept now takes byDefaultBranch, and the test shows a pull's run hands nothing back. - keyOfTest takes a root, so the test no longer calls process.chdir. - Not covered: the process.exit(0) when every file is kept is a one-line branch in test-shards.ts, and no test runs the script itself.

1. Key gaps: KEPT_TOOLING now also holds forge.json, test/helpers/preload.ts, scripts/test-shards.ts, scripts/kept-input.ts, scripts/tier-input.ts and src/checks/kept.ts.
2. Docs: the sentence in docs/DEVELOP.md is restored. The kept-results note is its own paragraph.
3. Ignore: .forge-impact.json was not ignored before. Both it and .forge-kept.json are in .gitignore now.

I also rewrapped a comment line in src/checks/kept.ts that the gate flagged.