todo: deep-link a todo notification to its markdown file

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-08-25 09:49:13 +00:00
parent 31151e7aa6
commit 21bc460892
2 changed files with 47 additions and 3 deletions
@@ -0,0 +1,44 @@
+---
+id: mobile-apps/deep-link-a-todo-notification-to-its-file
+title: "Deep-link a todo notification straight to that item's markdown"
+theme: mobile-apps
+status: open
+created: 2026-08-25
+date_source: stated
+order: 4
+---
+
+**Deep-link a todo notification straight to that item's markdown.** Wanted 2026-08-25: pressing a
+"new todo" notification should open the file directly, not just the app.
+
+**The mechanism exists — SendOff is the precedent to copy.** The notification catalogue
+(`src/servers/notifications/catalogue.ts`) already carries a `route` per entry, e.g.
+`officer/core:sendoff.landed` → `officer://files?path=Documents/SendOff/{id}`. A todo entry needs the
+same shape: a `route` template, and the producer (whoever calls `/notify` when a todo is filed —
+today that is this session, using `officer/core:message`, which carries no route at all) supplying the
+values that fill it in.
+
+**One correction before copying that pattern: `?path=` is the OLD shape.** The file browser's own URL
+model (`files-route.ts`, finished 2026-08-15) is the folder as the PATHNAME and `?view=<name>` as the
+open file within it — `/files/<folder>?view=<filename>`, not a `path=` query param. A todo's route
+should be built the current way: folder = `todo/<theme>`, view = `<slug>.md`. Getting this right means
+reading `folderHref`/the encode helpers in `files-route.ts` rather than copying SendOff's route
+literally — that one predates the model it now looks like it follows.
+
+**Where the file actually lives is a fact worth stating rather than assuming:** `/files` is scoped to
+the owner's home directory (`getRootDir` in `api/file-browser/router.ts`), and this repo's checkout
+sits under it — so `todo/<theme>/<slug>.md` IS reachable, as
+`officer-dev/platform/todo/<theme>/<slug>.md`. But that means the notification opens a raw file inside
+a DEV CHECKOUT via the general-purpose file browser, not a document in the owner's own space.
+
+**Open question worth deciding before building, not after:** `/todos` — the Kanban board built
+2026-08-24 — already has a per-item address, `?selected=<id>`, and renders that item's markdown in a
+proper detail pane with a status control, for free. A todo notification could deep-link there instead
+of into the raw file browser. Both are real options; the file-browser route is what was asked for, the
+board route is what already exists and reads better. Worth a one-line decision rather than defaulting
+to the more literal reading.
+
+**Also needed regardless of which target wins:** the producer side. Whatever POSTs to `/notify` when a
+todo is created (this session, and eventually the memo-dispatcher pipeline) needs to know the new
+item's `id` at send time and pass it through — trivial here since the id is generated in the same
+breath as the file, but worth naming as a real piece of the work, not assumed.