qualitylab

Determinism · Feedback latency

One command builds and tests the project from a clean checkout

unmeasured/cost to adopt: low/active

A project where a clean checkout can be built and tested by one documented command has a shorter path to every other control on this site; one where it cannot will silently reintroduce environment drift into every later gate.

Do this firstNothing. This is a place to start.

Not a build system, not a container, not a policy. One command, named in the README, that takes a clean checkout to a green suite on a machine that has never seen this project.

The reason it comes first is that it is the prerequisite that other controls do not know they have. “Run tests on every change” assumes a machine other than yours can run the tests. “Deploy on green” assumes green means the same thing in both places. When those assumptions are false the controls still install fine — they just quietly measure something other than your code, and you find out months later during an incident.

The cost is low and the work is unglamorous: it is usually two afternoons of finding the four things that were only ever installed by hand.

The decoy

A README with twelve numbered setup steps. It looks like documentation of a working process, and it is documentation of a process that only works for people who already know which steps are lying.

What would settle it

A study comparing onboarding-to-first-green time and CI flake rate across projects with and without a single-command bootstrap, controlling for project size and language. Nobody appears to have run it, most likely because the practice is too obviously good to fund a study of — which is not the same as it being measured.

Seen in the wild

Anonymised field observation. Illustration, not evidence — these carry no tier and cannot raise one.

Last reviewed 2026-08-19.