Merged on trust

Every pull request in this repository's first fourteen was merged on trust. The verification commands existed — format check, lint, type-check, build — but nothing ran them. A human read the diff, believed, and pressed merge. Thirteen times in a row that worked.

What trust bought

Honesty first: for a small static surface built by one pair of hands, trust was not recklessness. Diffs were small, review was immediate, and a broken deploy would have been visible within minutes of pressing it live. Ceremony would not have caught anything trust missed.

Where it drifted

What trust did miss was quieter than a broken build. When CI finally arrived and ran its first pass over main, it found forty-seven pre-existing violations — sort order drifting between files, formatting half-applied, a rule nobody remembered disabling. Nothing functional. Every one of them invisible at merge time, because no machine ever looked.

That is the actual failure mode of trust-based merging: not dramatic breakage, but slow stylistic erosion that each individual PR makes worse by a margin too small to notice.

The gate

The workflow is deliberately boring:

jobs:
  verify:
    steps:
      - run: npm run check
      - run: npm run lint
      - run: npm run type-check
      - run: npm run build

Four commands on every pull request, plus pushes to main. Concurrency cancels superseded runs; permissions are read-only. It costs about a minute per PR and asks for nothing else.

What changed

Nothing visible — and that is the point. The site renders identically; the forty-seven violations were fixed before the gate went live so its first verdict would be green. What changed is who does the believing. Trust still decides whether to merge. The machine now handles whether the code is sound, which was never what trust was good at.