Public: anyone can read this; the crew can change it.
Pipeline: approval → live in minutes, robustness kept: gate on impact, parallel lanes, fewer reds, input-addressed results, flags, blue/green #6014
Check · Review · Land · Live done — Landed and live in production.
This pull lands one small piece of #6001, the Bun-version part of lever 4. The other five levers are not started.
shipped production is serving it deploy 058b6cf
This pull lands one small piece of #6001, the Bun-version part of lever 4. The other five levers are not started.
What changed: the key that remembers a green check (src/checks/proven.ts) now includes the Bun version that ran it. Before this, a Bun upgrade could reuse a proof the old Bun produced. After it, one pass of checks re-runs once under the new Bun. test/check-proven.test.ts has a case that fails without the change. That test file and the type check pass. I did not run the rest of bun test.
Lever 4 was mostly there already. The key already covered repository, tree OID (the lockfile is part of it), command, install step, timeout, egress and limits. The gate already skips a tree it has proven green (src/checks/service.ts). I did not add the shard count to the key, because the check service never uses it.
What I left out:
- Lever 3, fewer reds: one file per registry entry, naming the failing test on every red, and bisecting in halves. Not started.
- Lever 1, gate on impact: running only impacted tests in the gate, with the full suite on main after landing and an auto-revert. It loosens the vision's "the gate runs every test", so it needs a person's decision and a capacity switch first. It also depends on the auto-revert work in #5994. Not started.
- Lever 2, parallel lanes: gating pulls with non-overlapping test sets in parallel. Not started.
- Lever 5, flags: landing unfinished work dark behind declared flags, with a debt gate. Not started.
- Lever 6, blue/green and canary: deploying each landing to a green slot with a staged rollout. Not started.
- KPIs: none of them are measured.
Each remaining lever needs its own issue, with levers 3 and 1 first as the issue orders them. I did not split them or link any dependencies. This was the only work that fit this run's budget.
To try it: bun test test/check-proven.test.ts.
This pull still contains only the Bun-version part of lever 4. The triage note asks for no code change, so I made none and pushed nothing new.
What changed: the key that remembers a green check (src/checks/proven.ts) now includes the Bun version that ran it. A Bun upgrade therefore never reuses a proof the old Bun produced. test/check-proven.test.ts has a case that fails without it. That file and the type check pass. I did not run the rest of bun test.
Triage: the note says #6001 has no pillar and waits behind the Later gate. Naming a pillar is a person's call, so I left it. The Trust pillar is the closest fit I can see, because several levers change what the gate runs. The pillar is not something this pull can set.
What I left out: levers 1, 2, 3, 5 and 6 and the /flow KPIs.
- Lever 1 (gating on impact) loosens "the gate runs every test" and depends on #5994's auto-revert.
- Lever 2 is parallel lanes.
- Lever 3 is one file per registry entry, a named test on every red, and bisecting in halves.
- Lever 5 is flags.
- Lever 6 is blue/green with canary.
Each needs its own issue, linked as the map describes. I split none off here.
To try it: run bun test test/check-proven.test.ts.
Small, correct slice of #6001 lever 4: the proven-green key now includes the Bun version, so a Bun upgrade cannot reuse an old proof. The change is two source lines and the test case fails without it. No new dependency, no security surface, and nothing for a phone or screen reader to see. Two things I would do next: (1) update the header comment in src/checks/proven.ts to list the Bun version among the key inputs, and either have src/checks/service.ts pass the Bun the cell actually runs, or drop the optional bun field, since nothing passes it today and only the default is exercised. (2) Open separate single-purpose issues for levers 3 and 1 in the order #6001 gives, linked on the map. Lever 1 needs a person to decide on loosening the gate and depends on #5994.
This pull lands one small piece of #6001, the Bun-version part of lever 4. The other five levers are not started.
What changed: the key that remembers a green check (
src/checks/proven.ts) now includes the Bun version that ran it. Before this, a Bun upgrade could reuse a proof the old Bun produced. After it, one pass of checks re-runs once under the new Bun.test/check-proven.test.tshas a case that fails without the change. That test file and the type check pass. I did not run the rest ofbun test.Lever 4 was mostly there already. The key already covered repository, tree OID (the lockfile is part of it), command, install step, timeout, egress and limits. The gate already skips a tree it has proven green (
src/checks/service.ts). I did not add the shard count to the key, because the check service never uses it.What I left out:
Each remaining lever needs its own issue, with levers 3 and 1 first as the issue orders them. I did not split them or link any dependencies. This was the only work that fit this run's budget.
To try it:
bun test test/check-proven.test.ts.Closes #6001