platform/todo/file-watchers/watch-a-directory-and-attach-actions-to-what.md

id, title, theme, status, created, date_source, order

id	title	theme	status	created	date_source	order
file-watchers/watch-a-directory-and-attach-actions-to-what	Watch a directory, and attach actions to what lands in it	file-watchers	open	2026-08-21	stated	1

Watch a directory, and attach actions to what lands in it. Wanted 2026-08-21. The owner sets a watcher on a path and configures what happens when a file appears there — the general mechanism, not one hard-coded flow.

The driving use case, end to end: instead of opening a chat, record an audio note; it lands in a watched directory; the existing transcription path turns it into a text file; and on the watch, an agent picks the new files up and files them as todos. So the owner can capture an idea with no session open and no phone unlocked into the right screen.

What it needs, in rough order: a watcher registry (path + what to do), a trigger that fires on file arrival rather than on a clock, and a way to hand the file to an agent turn. The third is no longer missing — see "Speaking into a session from the backend"; the nudger already starts a server-side turn with no browser attached. What is missing here is arrival-triggered firing, since the existing scheduler is a clock tick.

Open, not decided: whether the watcher is a plugin or core; whether "action" is a task, a prompt from the prompt library, or a chat message; and how a file is marked consumed so it is not picked up twice.

The split, settled by the owner 2026-08-21: it is two stages, and only one of them is an agent.

1. Audio lands → transcribe. Purely mechanical: watch the directory, call the transcription service, write the markdown out. A script and a service call, no model anywhere. This is the part that genuinely needs building, and building it as a script is the point — an agent here would be cost and nondeterminism for a job with one correct answer.
2. Markdown appears → read, understand, act. Reading a note and deciding it is a todo (and which one, and where it belongs) is real agent work. This half needs no new infrastructure: a recurring agent job already does it — the same hourly loop that logs a heartbeat can instead be told "look in this folder for new markdown and file what it contains". The prompt is the configuration.

So the watcher to build is the dumb one. What a built-in watcher buys over a standing agent job for stage 2 — arrival-time firing instead of a poll, a UI to manage watchers, working with no session open — is worth re-asking then, not now.

---

Stage 1 is being armed for real, 2026-08-25. A separate session inventoried the voice-memo folder (eight m4a memos, none transcribed), confirmed the existing whisper transcription task handles m4a with language detection, and got the owner's yes to transcribe each new memo as it lands. So the audio-arrival half of this item is live in another agent's hands — check what that session built before writing anything here. Stage 2 — an agent reading the transcripts and filing what they say — is still unbuilt, and is the dispatcher item under mobile-apps/.

Correction the owner made before arming, 2026-08-25: the transcripts go to a CENTRAL place, not into the transcribing commander's own directory. The first draft wrote them to commanders/<id>/transcripts/, which is text only that commander can find — and stage 2 reads the shared inbox, not another agent's private state. The watcher's own good ideas stand: a file counts as arrived when unchanged between two looks (never grab a half-synced file), and done-tracking is keyed on content so a renamed memo is not transcribed twice.