The measure

“Could you build this from it, without asking the designer?”

Asked of the engineer. Every “no, I’d still need…” is a line missing from the rule.

One file, five fields

  • Rule — what applies, in one sentence.
  • Rationale — what defends it in a review.
  • Edge cases — what saves the engineer a question.
  • Provenance — who decided, when, on what basis.
  • Open questions — what nobody has decided. Named, never invented.

Change the parameter and the prototype, the text, the snippet, the markdown and the tests all follow. There is no second place to keep in sync.

It holds, or the build goes red

✔ selection/control-type — decides every case as recorded
✔ selection/control-type — every outcome in contract.returns is reachable
✔ selection/control-type — the switch happens at threshold = 5, not after it
✖ selection/control-type — the built component follows the rule

  AssertionError: 2 options: the component did not do what the rule says
  'select' !== 'radio'

The cases come out of the rule. The last one runs them against what was actually built — reading the answer out of the rendered result, never asking the component what it thinks it did.

Next to your code

npm i -D waitingroom

npx waitingroom init     scaffold a rules folder, a config and the skills
npx waitingroom docs     write the markdown
npx waitingroom test     write the tests
npx waitingroom check    all of the above, verified rather than written

The rules stay in your repository. The generated tests run under node --test with nothing installed — the tool writes them and is never needed to run them.

A working sketch, not production code. Synthetic examples throughout — an invented registration office.

Handover concept · A working sketch of how behaviour rules travel from specification to implementation. Synthetic examples throughout. · Dominik Heilig — aisu.studio, 2026