2.8 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| mobile-apps/deep-link-a-todo-notification-to-its-file | Deep-link a todo notification straight to that item's markdown | mobile-apps | open | 2026-08-25 | stated | 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.