---
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.