A rule is a test
Nine apps shipped with prose that said 'drag the slider' and no slider
Nine learning apps were ported to a new framework in one push. The lesson text said click the button, drag the slider, watch the canvas. The pages had no button, no slider, no canvas.
The area contract said, in plain words, that learning apps embed interactive demos. Nothing enforced it. A rule with no test is a wish.
The incident got a name, the lesson-gutting incident, and it changed how rules are written here. The design rules for the monorepo are now described as rules plus tests, not a framework. Every rule has a test that fails when it is broken, and adding a rule means adding a test.
What the test looks like
For the demos, each learning app keeps a small manifest listing which lessons promise a widget and what DOM selector proves it exists. A test walks the manifest and greps the rendered lesson for the selector. Delete the slider and the build fails with the lesson’s name in the message. This site has such a manifest; the three demos in it cannot vanish silently.
The same shape covers the other rules:
- No hardcoded colors. A grep for hex literals in source CSS, so every color goes through a token and the theme switch keeps working.
- No gradients or shadows. The same grep, on the deployed HTML, across every subdomain, so an outside app cannot drift either.
- Mobile first. A warning on any
max-widthmedia query, because that pattern produces a broken phone every time someone adds a feature and forgets the small branch. - Ports are unique. A check that fails when two manifests claim the same dev port, which is how this site’s scaffold collision was caught in seconds.
Why this matters more with agents
A human who wrote the rule remembers it, roughly, for a while. An agent reads the rule at the start of a session and may or may not weigh it against the forty other things in its context when it is deep in a refactor. A test does not have that problem. It fires regardless of what the agent was thinking about, and its failure message lands in the context at exactly the moment it is needed.
So the practice is: when you find yourself writing a rule into the constitution, ask what command would fail if the rule were broken. If there is no such command, write one. If a command cannot exist, at least write the rule with the incident that produced it, so the agent can reason about it.
Tiers of enforcement
Not everything can be a deterministic check. The content standard here splits into three tiers: things a script can verify every time, such as schema and build correctness; things a rendered screenshot can verify, such as layout at phone width; and things that need judgment, such as “does the translation still mean the same thing”, which get a model-graded pass. What matters is that every tier has a gate. A standard with no gate at any tier is decoration.
The incident was not a missing rule. It was a missing test. Write the test, then the rule is real.