One green result per commit: a check on a commit already proven green is skipped, and a land does not re-run fast on a moved base #1847

A check or landing gate now skips the run when the same tree has already passed under the same gate. It answers already proven green by <run id>, and nothing is checked out. tsc is clean and 72 tests pass in check-proven, checks and check-tiers. I did not run the full check, and the forge runs the unix-socket suites that are skipped here.

• What the key covers: the repository, the tree of the commit, and the gate: command, install, timeout, egress and limits. For the fast tier it also includes the base tip and the tests the pull learned, so a moved base is a different key and still runs. The key logic is in src/checks/proven.ts.
• Where it applies: runTier in src/checks/service.ts looks the key up before the checkout and records it after a green run. The gate takes the same path, so a commit gated twice runs once.
• Storage: migration 89 adds a check_proven table, which holds only green results.
• Tests:

- test/check-proven.test.ts covers the key and the first-prover rule. - test/checks.test.ts shows a re-request returns the cached verdict without running the command. - test/check-tiers.test.ts shows a second gate of the same commit is not run.

• Test edits: two existing tests in test/checks.test.ts re-ran identical commands and expected a fresh run, which the cache now skips. I added a distinct comment to each command so they still exercise a real run.

Keyed on the tree, not the head: two different commits with an identical tree share a verdict. That covers a re-pushed head and the repeated head-and-base runs in the audit. It does not cover a land on a moved base, which changes the base tip.

Left out:

• Red results are always re-run, because a red can come from the environment.
• No expiry or pruning of check_proven. A lost row only means the check runs again.
• I did not touch the concurrency and shard-count behaviour named in the parked check failure.

To try it, push the same commit twice, or re-request a check on a green commit. The second run's summary reads already proven green by ….

Closes #1795

The check failed because test/check-proven.test.ts was in neither list in scripts/gate.ts. I added it to GATE. tsc is clean, and check-list and check-proven pass (11 tests). I did not run the full check; the forge runs that on this push.

The change itself is unchanged: a check or landing gate is skipped when the same tree has already passed under the same gate, and it answers already proven green by <run id>.

• Key: the repository, the tree, and the gate (command, install, timeout, egress, limits). The fast tier also includes the base tip and the tests the pull learned. A moved base is therefore a different key and still runs.
• Storage: migration 89 adds check_proven, which holds only green results.
• Left out: red results are always re-run. There is no expiry or pruning of check_proven.
• Test edits: two existing tests in test/checks.test.ts re-ran identical commands and expected a fresh run, which the cache now skips. I gave each command a distinct comment so they still exercise a real run.

To try it, push the same commit twice, or re-request a check on a green commit. The second run's summary reads already proven green by ….

I merged main into the branch and pushed it. tsc is clean and 100 tests across the check, schema and gate-list suites pass. I did not run the full check; the forge runs that on this push.

The only conflict was in src/core/schema.ts, where both sides had added a migration numbered 89. I kept both: main's parked column on issue stays at 89, and my check_proven table is now migration 90.

The change itself is unchanged. A check or landing gate is skipped when the same tree has already passed under the same gate, and it answers already proven green by <run id>. The key covers:

• the repository;
• the tree;
• the gate (command, install, timeout, egress, limits);
• for the fast tier, the base tip and the tests the pull learned.

A moved base is therefore a different key and still runs.

Only green results are stored, so red results are always re-run. There is no expiry or pruning of check_proven.

Two existing tests in test/checks.test.ts re-ran identical commands and expected a fresh run, which the cache now skips. I gave each command a distinct comment so they still exercise a real run.

To try it, push the same commit twice, or re-request a check on a green commit. The second run's summary reads already proven green by ….