diff --git a/docs/commander-directory.md b/docs/commander-directory.md
index 21ea65c6..ecdb95de 100644
--- a/docs/commander-directory.md
+++ b/docs/commander-directory.md
@@ -1,6 +1,12 @@
 # A commander is a directory, not a session
 
-**Status: designed, not built.**
+**Status: phase 1 built 2026-08-24** — schema, directory creation, `CLAUDE.md` at creation, the inverted
+`POST /commanders` → start-turn → point-at-transcript order, `resolveChatCwd` resolving server-side, and the
+frontend composer split (`NewCommanderSetup` → `ActiveNewCommander`) in `src/servers/api/command-hq/` and
+`src/workspaces/officerdev/src/apps/CommandHQ/CommandHqDetail.tsx`. `bunx tsgo`/`./node_modules/.bin/tsgo`
+clean, suite green. **`bun db:push` has not been run** — the owner reviews and runs the database work
+separately; see the schema section below for what changed and why nothing here is a migration. Phase 2
+(a commander becomes a git repository) is still not built.
 
 ## What is wrong now
 
@@ -76,6 +82,48 @@ front gets a worse answer than asking later.
 watch memos, scans and a mailbox. So this is a list on the row, seeded with one, and the commander writes
 additions into its own `CLAUDE.md` as they are agreed.
 
+## The two tiers, and why a commander should get cheaper
+
+This is the point of the whole design, and it generalises past any particular commander.
+
+**The script gathers. The agent judges.**
+
+A commander has two kinds of work and they have opposite economics. A script runs per event — every email,
+every voice memo — and costs nothing, so there is no ceiling on volume. An agent runs per batch, on
+material a script already assembled, and costs a turn every time it wakes. So the rule for building any
+commander is: push as much as possible down into the script, and let the agent see only what actually
+needs judgement.
+
+Detecting a one-time code in an email is a script. Reading fifty messages and deciding which of them the
+owner would want to know about is an agent. A watcher that transcribes a recording is a script; deciding
+what a week of transcripts means is an agent.
+
+**And the tiers are not fixed, which is the part that matters.**
+
+Because the commander owns its own scripts — they are files in its directory, and it can edit them — every
+correction moves work downward. The owner says "this one was missed, it had eight digits rather than six",
+and a decision that required judgement becomes a rule that does not. The agent tier gets thinner; the free
+tier gets better.
+
+**A commander that runs for six months should cost less per event than it did in week one, not more.**
+
+That is the opposite of how automation usually ages, and it is a direct consequence of two decisions made
+here rather than a hope: the agent owns its scripts, and the corrections arrive through dialogue rather
+than through a ticket to somebody else. Nothing improves a system it cannot edit.
+
+Two things this requires, and both are cheap if done from the start:
+
+- **The script's verdict must be reproducible.** Not logged — RE-RUN. The input is still in the mailbox or
+  the folder, and the script is deterministic, so diagnosing a miss is running it again and watching. A
+  log would be a second copy of something already on disk.
+- **A change is checked against what came before.** The corpus already exists — the last few hundred
+  messages, the transcripts so far. Re-run the old script and the new one over it and compare; anything
+  whose verdict changed is either the bug just fixed or one just introduced. Without that, the fix for
+  eight-digit codes quietly starts flagging every order confirmation, unattended, at three in the morning.
+
+`capabilities/skills/commander/SKILL.md` should teach this. Somebody building the fourth commander needs
+the rule more than they need the worked example.
+
 ## What the directory holds: definition versus state
 
 Two kinds of thing live in there and they must not mix, because one of them travels and the other must