mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-11-08 01:57:31 +01:00
d8078875344e5f8ebcabf7ad1d5afa74645bb583
2
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
 DottaandClaude Opus 5.5
|
d807887534 |
fix(ui): use one status glyph mapping for every task view (#19329)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - Task status is the main signal on every task surface: sidebar rows, the task header, the status menu, lists, the inbox, pills and chat cards. > - One task state rendered different status icons in different views. A blocked task that waits on an active sub-task showed the blue "in queue" glyph in the task header. The status menu, the chat chip and the sidebar rows showed the red "Blocked" glyph for the same task. > - The cause: each view passed its own subset of the presentation fields to `StatusIcon`. Many views dropped `blockerAttention` and some dropped `externalConversationState`. The status menu rendered its current row from the bare status. The summaries API did not return `blockerAttention`, so the recent-task sidebar could not know the state. > - This pull request puts the state-to-glyph/label mapping in one resolver and makes every task view pass all of its fields. > - The benefit is that the same state uses the same icon and label everywhere. ## Linked Issues or Issue Description No public issue. Found in a hands-on onboarding test on a staging cloud workspace. **What happened?** The sidebar and the task pane/status menu showed different status icons for the same state. On the test task (blocked, waiting on an active sub-task), the task header and the status button showed the blue "in queue" glyph. The selected "Blocked" row in the status menu showed the red blocked glyph. The coordinator sidebar "Recents" and project rows also showed the red blocked glyph, and the chat "Subtask created" chip showed a red "Blocked" chip. **Expected behavior** The same underlying state uses the same icon and label everywhere. **Steps to reproduce** 1. Create a task with a sub-task. Block the parent on the sub-task, and let the sub-task's agent run (the parent is "blocked, covered"). 2. Open the parent task. The header shows the blue "in queue" glyph. 3. Open the status menu. The current "Blocked" row shows the red glyph. 4. With the coordinator sidebar on, look at the task in Recents or in its expanded project. It shows the red glyph. **Paperclip version or commit** `master` at |
||
|
DottaandPaperclip
|
909e29dd07 |
fix(ui): show agent-created subtasks inline in the task feed (#18320)
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work. > - The task feed shows agent messages, documents, and artifacts. > - An agent can create a subtask or a separate follow-up task during that work. > - The reader must open the Tasks tab to find the new task. > - This pull request adds a linked task card to the source feed at creation time. > - The card shows the current title, task number, and status. > - The reader can inspect delegated work without searching a second panel. ## Linked Issues or Issue Description **What existing behavior does this improve?** Task creation visibility in the source task feed. Related work: #13823 added ancestor navigation in the Tasks panel. **Current behavior** Agent-created child tasks appear in the Tasks tab. The main feed has no persistent link card for those tasks. **Proposed behavior** Show each agent-created direct child or source-linked follow-up task once in the feed. Keep the card at creation time when status changes. Keep existing chat handoff and accepted suggestion cards without duplicates. **Reason and benefit** Readers can see which work an agent created and open that task from the conversation. **Breaking changes** None. This change uses existing authorized task reads. It does not add API or database fields. ## What Changed - Pass the existing child and source-task reads from task detail to the feed. - Add a task card with a link, wrapping title, task number, and status badge. Use existing design tokens. - Suppress repeated cards and tasks already shown by accepted suggestions or chat handoffs. - Show task-read failures with Retry. Keep the conversation readable during those failures. - Add feed and page regression cases plus desktop, multiple-task, dark, and mobile stories. Update the product description and delegation recipe. - Keep task selection and rendering in the task feed module. Existing issue APIs continue to own access checks and company scope. ## Verification - Passed: 224 focused tests with `pnpm exec vitest run ui/src/components/TaskChatThread.task-creation-order.test.tsx ui/src/pages/IssueDetail.test.tsx ui/src/components/task-detail/TaskDetailTasksPanel.test.tsx --maxWorkers=1`. - Passed: `pnpm --filter @paperclipai/ui typecheck`. - Passed: `pnpm check:token-gates`, `node scripts/check-maps.mjs`, and `node scripts/storybook-catalog.mjs`. - Cases cover creation order, current status, links, company filtering, direct children versus grandchildren, duplicate suppression, and read failure with retry. - Passed: browser render and link assertions for desktop, multiple tasks, dark theme, and mobile at 390px. All four story play phases finished. No page errors or horizontal overflow occurred. Screenshots use fixture task data and the production task feed. They do not prove server persistence or agent execution. - Passed: `pnpm --filter @paperclipai/ui build` after the concurrent memory failure. - The mobile preview frame needed spacing to contain the feed scrollbar gutter. Fixed the frame and repeated the browser checks. - Addressed the first Greptile finding: source-linked follow-ups now load with Streamlined UI off. A regression test covers that setting. - Full local build and typecheck cannot complete because Cargo is absent. The first concurrent UI build and UI typecheck were killed by the workspace memory limit. Both UI commands passed when run separately. The full local test run was stopped to fit that limit. PR CI must supply the full-suite verdict. ## Risks - Low risk. Delayed task reads can insert an older card into a loaded feed. Stable task IDs preserve the card during status updates. - New cards use the same access-checked task data as the Tasks panel. No task mutation or permission change is added. ## Model Used - OpenAI Codex, GPT-6. The runtime does not expose a more specific model ID or context size. Used reasoning, tool calls, code edits, tests, and browser automation. ## 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 - [ ] 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> |
