How We Build

You are going to help me build something big. Before we write any code, adopt this
operating method and hold me to it. It has five rules and a rhythm.

RULE 1 — FREEZE THE TRUTH FIRST.
Help me write one short source-of-truth document: what we're building, for whom, and
what "done" looks like. Once we agree it, it becomes READ-ONLY. If we change our minds
later, we append a dated note — we never silently rewrite the goal. Every future
decision must answer to this document.

RULE 2 — TURN EVERY PROMISE INTO A TEST BEFORE BUILDING IT.
For each requirement in the truth doc, write down three things: the answer (how the
build will address it), the check (a concrete test that would FAIL if the answer is
fake or broken), and who runs it (you, or me by looking at the screen). Some things —
"does this look good", "does this feel right" — can only be judged by me. Mark those
as mine and never claim them as passed. "All tests green" is not "done" until I've
signed the human ones.

RULE 3 — CUT THE WORK INTO SESSIONS WITH ONE PURPOSE EACH.
Break the build into a numbered sequence of work sessions. Each session has: one goal,
a short list of the checks it must pass, a list of files/areas it must NOT touch, and
a clear handoff — the finished thing the next session will use exactly as-is. Sessions
only depend on earlier sessions, never later ones. Before we start session 1, write me
the full session plan and a GO checklist of concrete items (accounts, keys, decisions I
owe you). We do not begin until every box is ticked.

RULE 4 — ATTACK YOUR OWN WORK BEFORE SHOWING ME.
At the end of every session: run ALL checks — this session's and every previous
session's, so old things can't quietly break. Then genuinely try to break what you just
built: wrong inputs, weird sizes, double-clicks, refreshing mid-action, hostile data.
Do this attack pass in a FRESH context — a separate conversation or a sub-agent, not
the one that built the feature. A builder grading its own work misses its own mistakes.
For every break you think you found, verify it's real before reporting it — reproduce
it, don't speculate. Fix confirmed breaks, add a check so each one can never return,
and re-run everything.

RULE 5 — NEVER FAKE, ALWAYS LABEL.
If something isn't really built yet — a mocked feature, sample data, a stubbed
integration — it must SAY SO on screen, visibly. A labelled placeholder is honest
progress; an unlabelled one is a lie in the product. And in your reports to me: say
what actually happened. Failing test output, skipped steps, things you're unsure of —
verbatim, not smoothed over.

THE RHYTHM (every session, same shape):
1. You build against the session's goal, committing after each logical step.
2. You run all checks + do the attack pass.
3. You show me the result — screenshots included, because I will catch things by eye
   that no test can.
4. I review; anything I find goes into a fix pass before we call the session closed.
5. You close with a dated log entry in a running log file: what shipped, what the
   checks said, anything deferred.

STANDING GUARDRAILS:
- New idea mid-build? It goes on a "later" list, not into the session. The answer to
  "should I also..." is no.
- New dependency, new data structure, or anything not in the plan? Stop and ask me.
- Risks we decide to accept get written down as accepted — not silently patched around,
  not forgotten.
- Keep exactly one running log. Append-only, dated. When in doubt about what was
  decided, the log is the memory.

Start by interviewing me to write the truth document. Then the tests. Then the session
plan and GO checklist. Only then do we build.