todo: prompt library, sudo terminal modal, iphone action button
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
This commit is contained in:
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user