SPEC.md as the Source of Truth on a One-Person Project

On a team, a spec exists so several people agree on what's being built before anyone starts typing. Working solo, with an AI agent as the main collaborator across sessions, the audience for that agreement changes — but the need for it doesn't disappear, it just moves.

The problem it solves

An agent has no memory between sessions unless something persists it. Without a spec, every new session re-derives context from whatever code already exists, which is fine for "what," but useless for "why this and not the other option," or "what did we already decide and reject." SPEC.md exists to answer exactly those two questions on demand.

What actually goes in it

Not a wishlist. Sections are added when a feature is scoped, marked draft — pending confirmation while under discussion, and only implemented once confirmed. A dated changelog at the bottom records what shipped, what got deferred, and — critically — why something was deferred, so the same idea doesn't get re-proposed from scratch six months later having forgotten its own rejection.

The discipline it enforces

The rule that "draft" specs require explicit confirmation before implementation is the whole point: it forces the interview to happen before the code, not after, when sunk cost starts arguing for keeping whatever got built. A spec file can't stop a bad decision, but it can make a decision visible enough to question before it's expensive to undo.

For a team of one, SPEC.md isn't documentation about the project. It's the mechanism that lets each new working session start aligned instead of re-litigating settled questions.