The bar everything is built to

The other Build modules teach you how to make each kind of part — a skill, a rule, a hook, a command, a connection to an outside system.

This one is the standard underneath all of them.

The golden rule — four words, in order

One standard runs across the whole system, called the golden rule.

It’s encoded, so I know it by name and hold every part I build to it.

Four words, and the order is the priority: simple, predictable, systematic, complete.

Simple.

The straightforward thing that works every time beats the clever thing that works most of the time.

Someone who has never seen the part should follow it on first read — a part nobody else can read is a part only you can extend.

Predictable.

The same input gives the same result through the same steps, every run.

A part that behaves differently day to day is broken even when it never throws an error, and you find out downstream, when output you trusted turns out to have drifted.

Systematic.

The part fits the patterns the system already uses instead of inventing its own.

It lives where its kind lives, it’s named the way its kind is named, and it reuses what’s already shared.

Complete.

The part runs, it survives a restart, it works for the real person, it has a spec, and the rest of the system knows it exists.

Four-fifths done is not done — the five questions below are how you check the last fifth instead of assuming it.

To put any part through the rule, name it and ask for the rule by name:

"Hold this to the golden rule — is it simple, predictable, systematic, and complete?"

Nothing ships without a spec, and the spec is the test

Before a part gets built, I write a short doc that says what correct looks like.

The system calls that doc a spec: it’s saved alongside the part, and every kind of part is expected to have one.

The spec does two jobs.

• Up front, it’s the contract — the agreed definition of what this part does, written before the work so we build toward the same target.
• At the end, it’s the test — you read the finished part against the spec line by line, and every gap is a bug to fix, not a variation to accept.

The build is the attempt to meet the spec, and the gap between the two is the work that’s left.

When you start something real, ask for the spec first:

"Write the spec for this before you build it — what it does, and how we’ll know it’s right."

Whether it's done comes down to five questions

"I think so" fails every one of these.

A verified yes to all five is done.

Anything softer isn’t.

• Does it run? — you’ve seen it execute and produce output, not read code that should work.
• Does it survive a restart? — it still works after the machine reboots, so it’s persistent, not held up by something in memory that vanishes.
• Will it work for the real person? — for the actual user with their actual data, not an idealized one you imagined while building.
• Is there a spec, and does it meet that spec? — both halves; a spec the part fails is not a pass.
• Is the rest of the system updated to know it exists? — the registries, the catalog, the cross-references all point at it, so it’s findable instead of orphaned.

To close a part out cleanly, ask me to run the gate:

"Run the five completion questions on this and show me each answer."

These three aren’t in one file — they’re encoded across the system’s standards, and I read the relevant one every time I build: the golden rule sits in the workspace’s golden rules, the spec discipline in the plugin-organization rule and the architecture rule, and the five done-questions in the completion standard at the top of the same workspace file.

The one thing to remember

The golden rule is the bar — simple, predictable, systematic, complete — and the spec is how you prove a part clears it: the contract before the build, the test after.

A part is done when five checked-yes answers say so, and never on "I think so."

Next: standing up a whole new domain of the system.