commanders: the script gathers, the agent judges

The two kinds of work in a commander have opposite economics. A script runs per
event and costs nothing, so volume has no ceiling. An agent runs per batch on
material a script assembled, and costs a turn each time. So the rule for building
any commander is to push as much as possible into the script and let the agent
see only what needs judgement.

The tiers are not fixed, and that is the part that matters. The commander owns
its scripts — they are files in its own directory — so every correction moves
work downward: "this one was missed, it had eight digits" turns a judgement into
a rule. The agent tier thins as the free tier improves.

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
follows from two decisions rather than from hope: the agent owns its scripts, and
corrections arrive through dialogue rather than a ticket to somebody else.
Nothing improves a system it cannot edit.

Records the two requirements that make it safe. A verdict is reproduced rather
than logged, because the input is still on disk and the script is deterministic.
And a change is re-run over the existing corpus before it ships, or the fix for
eight-digit codes quietly starts flagging every order confirmation, unattended,
at three in the morning.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043

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