todo: one file per item, grouped by theme, with a generated index

TODO.md had reached 1050 lines and 72 open items across 28 sections, read mostly
on a phone. It is now a directory: todo/<theme>/<item>.md, one card per file, with
frontmatter carrying id, status, created date and order, and the prose body copied
across verbatim. TODO.md becomes a generated index (bun run todo:index).

Dates: where an item's prose stated one it is used; otherwise its old section's;
otherwise 2026-08-20, floored at the day before the split rather than invented.
date_source records which.

Shaped for a two-way Kanban board, filed as todo/tooling — a card is a file, id is
the identity, frontmatter is the machine's half and the body is the owner's.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

todo/mobile-apps/_index.md

@@ -0,0 +1,5 @@
+---
+theme: mobile-apps
+heading: "Mobile apps"
+kind: theme
+---

todo/mobile-apps/iphone-action-button-run-an-officer-task-from.md

@@ -0,0 +1,20 @@
+---
+id: mobile-apps/iphone-action-button-run-an-officer-task-from
+title: "iPhone Action Button → run an Officer task from a locked phone"
+theme: mobile-apps
+status: open
+created: 2026-08-21
+date_source: stated
+order: 1
+---
+
+**iPhone Action Button → run an Officer task from a locked phone.** Wanted 2026-08-21. The
+driving use case: an idea arrives, press the Action Button, an audio recorder opens immediately —
+even on the lock screen — and the recording goes straight into an Officer chat session, without
+unlocking, opening the app and navigating there.
+Shape (assumed, not verified): the Action Button runs a Shortcut, and a Shortcut runs an App
+Intent the Officer app exports — so the work is shipping App Intents ("record to chat", and
+task-running more generally). **The load-bearing unknown is the lock-screen constraint**: what an
+App Intent may do while the phone is locked (microphone access, network, whether iOS forces an
+unlock prompt) decides whether this is the feature as imagined or a compromise. Settle that
+first, on a real device.

todo/mobile-apps/the-mobile-recorder-app-and-the-dispatcher.md

@@ -0,0 +1,34 @@
+---
+id: mobile-apps/the-mobile-recorder-app-and-the-dispatcher
+title: "The mobile recorder app, and the dispatcher agent behind it"
+theme: mobile-apps
+status: open
+created: 2026-08-21
+date_source: stated
+order: 2
+---
+
+**The mobile recorder app, and the dispatcher agent behind it.** Wanted 2026-08-21. The owner is
+building a recorder for the phone. **Every audio lands in one central place** — one inbox, not a
+folder per purpose — and a **dispatcher agent** decides where each one goes.
+
+Routing has two modes and both are wanted:
+
+- **Told.** The recording opens with the destination — "send this to my todo guy", or just
+  "todo" — and the dispatcher obeys. An explicit address always wins.
+- **Inferred.** Nothing is named, and the dispatcher works it out from the content. This is the
+  one that makes the app worth using: the ideal is that most notes need no prefix at all.
+
+What this implies: **destinations must be addressable and speakable.** "My todo guy" is a name for
+a standing agent session, so the dispatcher needs a registry of destinations with names a person
+would actually say. Command HQ is already most of that registry — `command_hq_sessions` names
+commanders and keys them on Claude's own transcript uuid. Delivery into a session exists too; see
+"Speaking into a session from the backend".
+
+Fits with the rest rather than duplicating it: the **File watchers** split applies unchanged —
+a script transcribes on arrival, the dispatcher is the agent stage — and the **iPhone Action
+Button** item is how a recording starts without unlocking the phone.
+
+Open: whether the dispatcher is one long-lived session or spawned per note; what it does when
+inference is uncertain (ask back, or file into an inbox for review); and whether a routing rule
+is a prompt from the prompt library.