DottaandPaperclip
45862dd210
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Its user journeys span tasks, agents, projects, connected apps, governance, and CLI operations. > - Existing tests do not provide a shared index of entry points and verification steps. > - Contributors need to see which surfaces a change affects and what evidence exists. > - This pull request adds an optional product feature map with recipes and explicit coverage gaps. > - The map adds no CI checks or required maintenance for future pull requests. > - Contributors can use it to find verification steps and state what they checked. ## Linked Issues or Issue Description **Issue type** Missing documentation. **Where is the issue?** User-journey verification guidance in AGENTS.md and doc/DEVELOPING.md. **What's wrong?** There is no shared index of product features, user entry points, available test evidence, and remaining coverage gaps. Shared components can hide differences between their hosts. **Suggested fix** Add a documentation-only capability index and verification recipes. The format takes inspiration from [Omnigent's feature map](https://github.com/omnigent-ai/omnigent/tree/91acfbbb59f6fc210ff95a9e9428aadd62e06582/feature-map). The recipes describe Paperclip's own behavior and tests. Searched GitHub PRs and issues for `feature map` and `feature-map`. No duplicate change was found. Checked ROADMAP.md. This PR documents existing capabilities. ## What Changed - Added 35 feature recipes, 171 named sub-features, and 91 entry points across product, CLI, operator, and developer surfaces. - Each recipe describes setup, expected results, existing automated evidence, manual verification, and coverage gaps. - Added a dated source snapshot of 185 non-test page TSX modules in 15 areas. The snapshot describes documentation coverage, not runtime health. - Included entry points within existing pages, CLI/API operations, and experimental surfaces. Identified helper-only test evidence where a rendered journey has no automated proof. - Linked the map from AGENTS.md and doc/DEVELOPING.md as an optional reference. - The final diff contains only Markdown and the inventory JSON. It adds no checker, tests, package commands, workflows, dependencies, scheduled work, or mandatory inventory updates. ## Verification - PASS: local documentation links resolve and the inventory JSON parses. Confirmed the final PR diff contains only 39 documentation files. - PASS: `node --test '.github/scripts/tests/*.test.mjs'` — 381 existing tests after removal of the feature-map tests. - PASS: `git diff --check`. - Earlier local build and typecheck passed. The full local test run was stopped after 26 minutes with failures in unchanged chat-channel and native-runner integration tests. It did not complete. These application checks were not repeated for the documentation-only removal. - [CI on the preceding head](https://github.com/paperclipai/paperclip/actions/runs/37398407523) passed all applicable checks. Checks on the final documentation-only head are pending. - PASS: Greptile review on final head `45c4b0aeb26540324825da43e81bee2336ad1c1f` is 5/5. There are no unresolved findings. - Live product/provider journeys were not run to author the map. The recipes identify available evidence and manual steps, not new qualification results. ## Risks Low product risk: the PR changes documentation only. Recipes and the source snapshot can become stale. Maintenance is optional and based on review. Linked tests do not prove that every documented journey works. The map states remaining coverage gaps. ## Model Used OpenAI Codex, GPT-6 family, with repository inspection, reasoning, tool use, and code execution. The exact serving model ID and context window were not exposed in this session. ## Checklist - [x] I have included a thinking path that traces from project context to this change - [x] I have specified the model used (with version and capability details) - [x] I have checked ROADMAP.md and confirmed this PR does not duplicate planned core work - [x] I have searched GitHub for duplicate or related PRs and linked them above - [x] I have either (a) linked existing issues with `Fixes: #` / `Closes #` / `Refs #` OR (b) described the issue in-PR following the relevant issue template - [x] I have not referenced internal/instance-local Paperclip issues or links (only public GitHub `#NNN` / `github.com/paperclipai/paperclip` URLs) - [x] My branch name describes the change (e.g. `docs/...`, `fix/...`) and contains no internal Paperclip ticket id or instance-derived details - [x] I have run tests locally and they pass - [x] I have added or updated tests where applicable - [x] I have updated relevant documentation to reflect my changes - [x] I have considered and documented any risks above - [ ] All Paperclip CI gates are green - [x] Greptile is 5/5 with no open P2s, recommendations, or follow-ups - [x] I will address all Greptile and reviewer comments before requesting merge --------- Co-authored-by: Paperclip <noreply@paperclip.ing>
6.9 KiB
Steering and queued messages
People can send follow-ups while an agent works, manage saved messages that have not been consumed, and choose when to steer or interrupt. Stopping a run and pausing a task are separate controls. The UI must preserve the message, explain why it is waiting, and only claim delivery after an authoritative acknowledgement.
Sub-features
queue: a busy task saves follow-ups and shows their order and wait reason.edit-order-discard: edit full Markdown, reorder, and discard eligible saved messages; ownership, revision conflicts, and already-dispatched states matter.steer: explicit user action sends a queued message into a compatible active run; unavailable capabilities and provider rejection remain visible.interrupt: stop the current execution and carry accepted follow-ups into the eligible continuation without delivering them twice.stop-and-pause: distinguish stop-in-flight, confirmed stop, task/ancestor pause, agent pause, and budget hold. Resume must respect the actual gate.drafts: switching tasks, reloading, and uncertain submission retain the correct task's draft and attachment receipts.approval-queue: answered questions and accepted approvals have durable delivery distinct from editable ordinary comments.
How to get to it (user POV)
task-composer
Open an assigned task (/issues/:issueId). Start work, then send follow-ups while
the agent runs. Use the queued-message controls to edit, reorder, discard,
steer, or interrupt when offered. Use the composer stop/pause control separately.
Both task presentations need attention when changing their shared behavior.
agent-chat
Enable Agent Chat and open an agent conversation. Send another message during
a reply and inspect the shared queue. /new starts fresh provider context in
the same conversation; it is an ordered boundary, not a normal model prompt.
request-response
Answer an earlier question or accept a confirmation while successor work is active on the task. Inspect the resulting queued response and its available steer/interrupt control instead of assuming acceptance interrupted execution.
external-channel
Send a follow-up from a linked external chat conversation while its task is running. Use that provider's supported stop/control affordance where available; inspect the resulting task and run in Paperclip.
Driving it
Preconditions: follow the baseline. Use an agent that stays busy long enough to inspect the queue. Record the adapter, native/legacy mode, and advertised steering capability. Test supported and unsupported steering without treating an absent capability as a product failure.
task-composer
Automated: queued-message UI covers order, failure restoration, unavailable steering, stale revisions, and discard acknowledgements. Queue routes cover durable ordering, authorization, steering acknowledgements, interrupt recovery, and concurrent dispatch. Composer covers drafts and uncertain saves.
pnpm exec vitest run ui/src/components/task-chat/TaskChatQueuedMessages.test.tsx server/src/__tests__/issue-queued-comments-routes.test.ts
Automated stop coverage is separate: composer stop with its configuration and ACP stop/continuation. Inspect their fixture and opt-in prerequisites; skipped native cases are not native proof.
Manual: queue three distinguishable messages. Edit one, reorder them, reload, and confirm the saved order. Discard one and confirm it never reaches execution. Steer one while busy and verify the agent receives that exact message once. Repeat with a rejected steer and a stale second-tab edit; the UI must preserve retryable content and explain the conflict. On a fresh run, interrupt with a queued follow-up and verify confirmed stop followed by one continuation. Pause the task (and separately its ancestor), preserve a draft, then resume the actual hold; no hidden send should occur while paused. Check both task presentations when available; the named component tests do not prove every host integration.
agent-chat
Automated: agent chat sessions covers persistent conversation/session behavior with deterministic harness fixtures; shared composer tests cover the controls. These do not qualify live steering for every harness.
Manual: queue two follow-ups while the conversation replies. Reload, edit or
discard one, then let the other run. Verify one reply and unchanged conversation
identity. Send /new, then a new prompt; old history remains visible, and the
new turn uses fresh provider context. Verify a useful answer rather than only
the session-divider UI. Repeat the queue operations with a live capable harness
when the change touches delivery.
request-response
Automated: response delivery proves queueing/coalescing and retry-safe receipts. The queue-route suite tests separate comment and approval queues, explicit steering, and fresh-session restrictions on plan approvals.
Manual: answer an old question during a new run, confirm that it is saved and queued, and let the active run end. Verify exactly one continuation with the answer. Repeat an eligible approval with explicit steer; another approval that requires a fresh session must not offer same-turn delivery. Do not edit an approval outcome through an ordinary queued-message editor.
external-channel
Automated: chat interaction arbitration covers backend arbitration with simulated requests. It is not a provider UI test.
Manual: send two distinguishable messages through one disposable linked conversation while busy. Inspect their saved task order, run delivery, and external reply. Check a duplicate provider event and unauthorized sender. Provider-specific control semantics and real transport timing remain a manual gap; do not assume browser queue controls are available in every channel.
Gotchas
- Paperclip's queue is server-owned once saved; it is not Omnigent's unsent browser draft buffer. A stale edit must not overwrite a consumed message.
- Steer availability depends on the active runtime's capability, not its brand name. A UI row disappearing optimistically does not prove provider receipt.
- Interrupt, stop, task pause, agent pause, and budget pause have different effects. A running indicator disappearing does not prove remote work stopped.
- An interrupted run may need verified cleanup before a saved follow-up can start. Preserve and inspect the wait reason; see recovery.
- A healthy idle Agent Chat is waiting for input, not stranded unfinished work.