commanders: no migration, delete and re-arm

The one commander here is unarmed and has never fired, so a migration would be a
code path that runs once and never again. Deleting it and re-arming on the new
system also exercises the flow the design exists to fix, which a migration would
route around.

Notes the shelf life: free while nothing depends on a commander, not free after.

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

docs/commander-directory.md

@@ -85,14 +85,18 @@ commander's own directory is nearly empty on turn one and the interesting thing
 That guidance has to change with the code, or every new commander will orient on an empty folder and ask
 a worse question than it does today.
 
-## The schema change
+## The schema change, and why there is no migration
 
 `session_id` stops being the commander's identity and becomes a nullable pointer to its current
-conversation. The row gains its own id, its directory, and its reference paths. Existing rows have a
-transcript id and no directory, so a migration has to create one and write a `CLAUDE.md` into it for each.
+conversation. The row gains its own id, its directory, and its reference paths.
 
-There is one commander on this machine and it is not armed, so the migration is cheap today and gets more
-expensive with every commander anybody starts.
+**Nothing is migrated.** The one commander on this machine is deleted and re-armed from scratch on the new
+system — the owner's call, made on 2026-08-24, and the right one: it is unarmed and has never fired, so
+migrating it would mean writing and testing a path that runs exactly once and then never again. Re-arming
+also exercises the flow this design exists to fix, which a migration would route around.
+
+That decision has a shelf life. It is free while one commander exists and unarmed; it stops being free the
+moment somebody is relying on one. Build this before that happens, or write the migration.
 
 ## What this does not decide