The laws of building

These are the principles that survive even if you remove every specific project from the story. They are the spine of everything that follows. Each one was learned the expensive way.

Law 1. A rule is written with its incident

A rule with no story gets bypassed. A rule that carries the date, the cost, and the failure that created it does not, because the reader can see exactly what they're buying by ignoring it.

So when you write a rule, write the failure next to it. And the test: if you can't find a failure behind your rule, it's probably a preference, not a rule. Preferences are fine. Just don't defend them like laws.

Law 2. An exception is documented like a rule

The normal reflex is to tolerate an exception quietly, which is exactly how exceptions multiply. Do the opposite. An exception is written with four things: the general rule, restated and explicitly protected; the cumulative criteria that allow the exception; the named list of every instance that currently uses it; and the condition under which it returns to the general rule.

"If a single criterion drops, this goes back under the general rule." That one line keeps an exception from quietly becoming the new norm.

Law 3. A rejected decision is worth as much as a chosen one

Keep a "rejected alternative" next to every real decision. It's what stops someone, six months later, from re-proposing an option you already killed, with the same arguments, because they weren't in the room the first time.

Corollary: an obsolete plan is not deleted. It's struck through and dated, with a pointer to the living decision. Deleting it just means you'll rebuild it from scratch and rediscover why it was wrong.

Law 4. A verification you didn't run is worse than none

This is the most expensive anti-pattern there is. Picture a note that says "checked: returns the right result," presented as proof, where the check was never actually run. It doesn't just fail to protect you. It closes the subject, so nobody looks again. On one project, a "verification" that was written but never executed let a batch of internal files sit exposed in public for months.

So the correct shape of a fix is never "check that it works." It's the exact command to run, and the regression criterion: the precise signal that would tell you the bug is back.

Law 5. A green gate is worth nothing until you've seen it go red

Before you trust any automatic check on new ground, make it fail on purpose. If it doesn't go red when you break the thing, it will never protect you, it will just reassure you.

There are many ways an automatic check quietly lies: it doesn't scan the area you care about; it only sees files already saved to version control, so it says "all clear" on brand-new code; its search pattern misses the real shape of the code; the target sits outside its scope; the runner counts "found nothing to do" as a pass. Real example of the last trap: a test suite existed, over a hundred assertions, and it was wired to run nowhere. It passed by never running.

The discipline: calibrate every lock against one known-good case and one known-bad case frozen as a test. Without that, nothing tells "working" apart from "inert." And remember the human side: a lock that cries wolf gets switched off.

Law 6. A mass change is proven by an invariant, never by a re-read

When you change a thousand things at once, you cannot eyeball it. You prove it with an invariant, a fact that must hold. Three that work in practice.

Set equality: after replacing something across N pages, check that the count carrying the new version equals the count that carried the old one, and that zero of the old remain. A half-finished bump desyncs everything while looking fine.

Fingerprint the lines that must not move: before and after a big migration, prove that the specific lines you weren't supposed to touch are byte-for-byte identical. You don't just avoid touching them, you prove you didn't.

The quantified delta in production: not "the test is green," but "these exact numbers moved from X to Y on the real data, and zero items ended up misclassified." A delta beats a green checkmark.

Law 7. The name lies, the proof is the usage

Names drift from meaning. On one app, an object called "Company" actually meant a parent group, not a single site. A relationship built on the resemblance of names, rather than the reality of the data, rejected nearly eight rows out of ten. The names agreed. The data didn't.

The hardest and most useful extension: this applies to your own documents too. A doc you wrote yourself is not a source of truth, it's a dated hypothesis. Verify it against the real thing before you trust it. Two corollaries: disabled code is often richer than the live code (it tells you what was tried), and a component named in a comment is a component worth opening.

Law 8. What isn't wired to a mechanical check doesn't exist

And its twin: what isn't written in a file doesn't exist. A conversation is not a memory system.

The proof is boring and universal: of five points raised out loud in a review, four got written down somewhere, one didn't. The one that vanished was a legal line shown to users at the exact moment of their consent, and it had quietly become false. Spoken agreements evaporate. If it matters, it lives in a file or in an automatic check, or it does not really exist.

Law 9. The real fix is to remove the shared space

When two people (or two AI sessions) working in parallel keep colliding over the same shared resource, the instinct is to add a better check. Often the better move is to remove the shared thing entirely.

The classic case: parallel work kept grabbing "the next number" for a change, without seeing each other, and collided again and again. No pre-check could work, because looking at "the last number used" looks at a world where the sibling change doesn't exist yet. The fix wasn't a smarter check. It was switching to a timestamp, so there's no shared counter left to consult. Two timestamps don't collide. When a lock can't hold a shared resource, ask whether the resource should be shared at all.

Law 10. Memory has a budget and tends toward empty

Your project memory (the file that keeps the context an AI or a teammate needs) has a budget. Past it, you don't add, you distill. A good memory file is designed to shrink over time, not grow: each entry is distilled or deleted when its chapter closes.

The deeper version: a lesson written six times, each time as if it were new, is not six lessons. It's one law that never had a home. When you catch yourself relearning the same thing, don't add a seventh note. Give the law a home, and every future occurrence just points there.