The machine forgets
Why this site was built in numbered phases. Not tidiness, memory. A feature that fits in one head has to fit in one context window.
Numbered phases. Phase 12, Phase 13, Phase 17. From the outside that looks like project management, the work of somebody who enjoys a tidy checklist. It isn't. It's memory management.
The work got split this way because the machine forgets.
The harness is a file
There's a file in this repo called context/current-feature.md. One feature at a
time: what's active, what done looks like, what got decided and why it got
decided that way. Every session opens by reading it. Every session closes by
updating it.
Most of the advice going around tells you to manage your context window. Sure. But a window isn't something you manage by being careful. You manage it with a file that outlives the session that wrote it.
Compaction keeps the shape and drops the reasons
Let a session run long enough and the conversation gets summarized to fit. The summary is faithful. It just isn't complete.
It will remember that window state lives in a Zustand store. It won't remember that React context was tried first and re-rendered every open window on every frame of a drag. Decisions survive compaction. The arguments behind them don't, and without the argument a decision is just a rule waiting for someone to come clean it up.
So the reasons go in the file. The file is the part that doesn't rot.
A phase is a unit of forgetting
The scoping rule fell out of that on its own: if a feature doesn't fit in one window, it isn't one feature.
"Retire the Playground app" fits. A registry entry, a route, a component, some CSS nobody had touched in months. "Backdrop system plus four new scenes" doesn't, so it becomes three things: a refactor that changes nothing visually, a menu that grows into a swatch grid, then the scenes. One branch each.
Not because branches are tidy. Because a branch is a boundary context can't leak across. Same reason you hand a subagent the job of reading forty files and bringing back one paragraph. The forty files never enter your window at all.
The rules are all one rule
Branch per feature. Build passes before commit. Ask before committing. Changelog entry while the work is fresh, not on release day.
Written out like that it reads like process for its own sake. It isn't. Every one of those is a checkpoint where state leaves a conversation and enters something that survives it: a branch, a build, a commit message, a line in a file.
The model isn't a junior engineer who needs supervising. It's a very good engineer with no long-term memory. Build the harness for that, and it turns out you were building a decent one for yourself too.