## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Tasks can depend on other tasks. A task detail shows its blockers in the properties panel and in a "Still blocked by" notice. > - The task detail response embeds a summary of each blocker, including its status. > - Live updates refresh only the changed task's own cached detail. They do not refresh other cached tasks that embed it. > - So when a user marks a blocker done, an open dependent task keeps the old blocker status. The "Blocked by" chip shows "blocked" while the Subtasks chip shows "done". The page looks stuck until a reload or until a run starts. > - This pull request refreshes every cached task detail that embeds the changed task in `blockedBy` or `blocks`. > - The benefit is that dependent tasks show the current blocker status immediately. ## Linked Issues or Issue Description **What happened?** A user marked a blocker task done by hand. The dependent task page still showed the blocker with a "blocked" icon and a "Still blocked by" notice. The same blocker showed as "done" in the Subtasks row of the same panel. The server had already resolved the dependency and woke the dependent task. Only the open page was stale. **Steps to reproduce** 1. Open task A, which is blocked by its subtask B. 2. In another view, mark B done. 3. Go back to A without a reload. "Blocked by" still shows B as blocked, and the notice says "Still blocked by B". "Subtasks" shows B as done. **Expected behavior** The "Blocked by" chip and the notice update when B changes, the same as the Subtasks row. ## What Changed - `LiveUpdatesProvider`: when activity changes a task's status, retry or recovery fields, invalidate every cached `issues.detail` query whose `blockedBy` or `blocks` summaries contain that task. The match uses the UUID or the identifier, because authenticated events can omit the identifier. - Add a regression test for this in `LiveUpdatesProvider.test.ts`. ## Verification - Red: the new test failed before the fix. The dependent detail was not invalidated. - Green: `pnpm vitest run src/context/` in `ui` passes (311 tests). - `pnpm verify` passes (549 selected test files). - `tsc -p ui --noEmit` shows no new errors. Existing errors in `ui/storybook/support/feature-map` are unrelated. - Staging data check: the server returned the blocker as `done` in the dependent's `blockedBy`. The stale display came only from the client cache. ## Risks Low risk. The predicate scans only cached task details. It refetches only details that embed the changed task. Refetches use the existing invalidation batcher. The list of actions excludes comments and document edits, so busy tasks do not cause extra refetches of their dependents. > For core feature work, check [`ROADMAP.md`](ROADMAP.md) first and discuss it in `#dev` before opening the PR. Feature PRs that overlap with planned core work may need to be redirected — check the roadmap first. See `CONTRIBUTING.md`. ## Model Used - Claude Opus 5.5 (`claude-opus-5-5`) in Claude Code, with tool use and code execution. ## 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 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
@paperclipai/ui
Published static assets for the Paperclip board UI.
What gets published
The npm package contains the production build under dist/. It does not ship the UI source tree or workspace-only dependencies.
Storybook
Storybook config, stories, and fixtures live under ui/storybook/.
pnpm --filter @paperclipai/ui storybook
pnpm --filter @paperclipai/ui build-storybook
Typical use
Install the package, then serve or copy the built files from node_modules/@paperclipai/ui/dist.
Editor dependency identity
Keep the root and workspace overrides for @codemirror/state,
@codemirror/view, and @lezer/common aligned. CodeMirror requires shared
extension identity, while Lezer parsers and syntax highlighters require shared
NodeProp IDs. Multiple Lezer copies can crash code-block highlighting with
tags is not iterable. src/lib/codemirror-single-instance.test.ts checks the
installed dependency graph and highlights sample code through the editor's real
language dependencies. GitHub Actions owns regeneration of pnpm-lock.yaml.