From 2e76cabf4f79982ab73ec0c5d89db5911468c64a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andr=C3=A9=20Padez?= Date: Fri, 21 Aug 2026 04:51:18 +0000 Subject: [PATCH] todo: prompt library, sudo terminal modal, iphone action button Co-Authored-By: Claude Fable 5 --- TODO.md | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/TODO.md b/TODO.md index 7d6790fb..cec5e3d8 100644 --- a/TODO.md +++ b/TODO.md @@ -36,6 +36,21 @@ the owner's OS user and can never be granted. Indirection there really is accide generating" was once treated as permission and started a second agent in a repository another was building in. Whatever shape this takes, it inherits those three refusals. +## Prompt library + +- [ ] **A store of ready-made prompts, versioned, categorized and tagged.** Wanted 2026-08-21. The owner + keeps prompts he reuses; today they live nowhere. What it needs: + - **Database rows** with the usual fields (`createdAt`, `modifiedAt`, …), one **category** each and + **multiple tags** per prompt. + - **Versioning by row, not update-in-place.** Editing a prompt inserts a new row with a bumped + version. The UI shows the latest version unless asked otherwise, with copy-to-use as the primary + action. + - **Categories do double duty:** they catalogue, and they decide where a prompt appears (or does + not) in the workspace/page-layout routing system. + - **Open question, deliberately deferred:** a separate `kind` alongside `category` — e.g. + background-job prompt, image-generation prompt. Unclear whether both fields earn their keep; + keep both in the design and decide when building. + ## Notifications - [ ] **A push payload does not say which server sent it**, which is fine for one and breaks three things @@ -66,6 +81,31 @@ the owner's OS user and can never be granted. Indirection there really is accide "this client renders images" behaves differently from one told nothing, and a THIRD state, "you were told not to", is a different thing again. +## Mobile apps + +- [ ] **iPhone Action Button → run an Officer task from a locked phone.** Wanted 2026-08-21. The + driving use case: an idea arrives, press the Action Button, an audio recorder opens immediately — + even on the lock screen — and the recording goes straight into an Officer chat session, without + unlocking, opening the app and navigating there. + Shape (assumed, not verified): the Action Button runs a Shortcut, and a Shortcut runs an App + Intent the Officer app exports — so the work is shipping App Intents ("record to chat", and + task-running more generally). **The load-bearing unknown is the lock-screen constraint**: what an + App Intent may do while the phone is locked (microphone access, network, whether iOS forces an + unlock prompt) decides whether this is the feature as imagined or a compromise. Settle that + first, on a real device. + +## Sudo terminal modal + +- [ ] **A modal carrying a terminal emulator, for anything that needs `sudo`.** Wanted 2026-08-21. + Anywhere a command needs `sudo`, the modal opens with a live terminal session, the command runs + in it, and the user types his password into the terminal himself — the password goes to the pty, + never through the platform or an agent. Plumbing exists: the pty sidecar already serves ad-hoc + sessions, and xterm.js is already in the terminal panel; the new part is the modal surface and + an entry point ("run this with sudo") that other surfaces can invoke. + **Needs an affordance** (`capabilities/affordances/`) so chat agents know the mechanism exists + and reach for it instead of attempting `sudo` non-interactively or asking the owner to paste a + command. + ## Plugin infrastructure - [ ] **A plugin cannot claim a WebSocket provider.** `pluginPermissions` in mount.ts sets `api` and