62 lines
3.6 KiB
Markdown
62 lines
3.6 KiB
Markdown
---
|
|
id: file-watchers/watch-a-directory-and-attach-actions-to-what
|
|
title: "Watch a directory, and attach actions to what lands in it"
|
|
theme: file-watchers
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 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.
|