From 9feabfee4852f3ca6d29295f2cf292a14f6c633c Mon Sep 17 00:00:00 2001 From: Dotta <34892728+cryppadotta@users.noreply.github.com> Date: Fri, 6 Nov 2026 17:26:59 -0600 Subject: [PATCH] fix(ui): use the shared status glyph in inline task links and the live-work strip (#19636) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ## 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, including agent messages and the task chat. > - #19329 put the status-to-glyph mapping in one resolver. Two conversation surfaces did not use all of its inputs. > - Inline task links in a message passed only the bare status. A blocked task that waits on active sub-tasks showed a red glyph there and a blue glyph in the list, breadcrumb and sidebar. > - The "Waiting on live work" strip above the composer drew its own filled and hollow dots, not task glyphs. > - This pull request makes both surfaces resolve through the shared mapping. > - The benefit is that one task state looks the same in every view. ## Linked Issues or Issue Description Refs #19329 **What happened?** In a hands-on onboarding walk, the onboarding task was blocked on four active sub-tasks. The breadcrumb, the sidebar Recents row, the Tasks list and the "Blocked" chip used the blue in-queue glyph. Inline task links in the agent message used the same glyph in red. The "Still waiting on live work" strip showed the same tasks as plain dots. **Expected behavior** The same task state uses the same glyph and colour token in every view, including inline links and the live-work strip. **Steps to reproduce** 1. Create a task with sub-tasks, and block the parent on them while a sub-task runs. 2. Mention the parent in a message (for example "(PAP-1)"). 3. Compare the inline link glyph with the task list glyph. The link is red, the list is blue. 4. Open the parent task. Compare the "Still waiting on live work" strip with the task list. The strip shows dots. **Paperclip version or commit** `master` at e482f0f632. ## What Changed - `MarkdownBody` issue mentions spread `taskStatusIconProps(issue)` into `StatusIcon`. They now pass `blockerAttention`, `displayStatus` and `externalConversationState`. - `TaskChatLiveWorkLinks` draws `StatusIcon` for each task, in place of the private dot glyphs. Relation summaries do not carry blocker attention or the waiting-conversation state, so the strip reads them from the same `/issues/summaries` batch that the sidebar and created-task cards use. Until that loads, it uses the relation status. - `TaskChatThread` passes `companyId` to the strip. - The strip fetches summaries in batches of `ISSUE_SUMMARIES_MAX_IDS` (5), and production-mode "Now running" rows draw the glyph too (Greptile review). - New tests: `TaskChatBlockerLinks.test.tsx` (strip with seven tasks through the real fetch path, both presentation modes, "Now running" row) and a BUG-07 case in `MarkdownBody.test.tsx`. One assertion in `TaskChatThread.test.tsx` now expects the glyph label text. - Storybook: "Same state in conversations" section in Foundations / Status Language shows the list row, inline mentions and the strip side by side. ## Verification Red on master (fix reverted, new tests kept): ``` ❯ src/components/task-chat/TaskChatBlockerLinks.test.tsx (2 tests | 2 failed) × draws each waiting task with the task list's glyph and colour token (streamlined) × draws each waiting task with the task list's glyph and colour token (production) ❯ src/components/MarkdownBody.test.tsx (66 tests | 1 failed | 65 skipped) × draws a blocked task mention with the same glyph and colour token as the task list (BUG-07) AssertionError: expected '