mirror of
https://github.com/paperclipai/paperclip.git
synced 2026-10-08 21:03:51 +02:00
Devin Foley
de9645ab73
## Thinking Path > - Paperclip is the open source app people use to manage AI agents for work > - Runs on sandbox execution targets spend their first minutes in preparation phases — config seed, workspace and skills sync into the sandbox — before the agent CLI produces its first transcript token > - The engine already reports these phases through the runtime-progress mechanism (`onRuntimeProgress` → `recordCurrentHeartbeatRunRuntimeProgress` → `currentStatusMessage` on the live run), and the pre-task-chat issue view surfaced them in its live status line > - The chat-style task view's live tail dropped that affordance: with zero renderable transcript entries it shows an opaque "Waiting for transcript..." for minutes, which reads as a hang (and prompted a real is-this-broken investigation on a healthy run) > - This pull request surfaces the live run's `currentStatusMessage` as the tail's empty-state message, with the generic wait text as fallback > - The benefit is that operators watching a sandbox run see "Syncing workspace to sandbox" instead of wondering whether the run is stuck — for every adapter, with no adapter identities involved ## Linked Issues or Issue Description **What existing behavior does this improve?** The chat-style task view's live transcript tail (`TaskChatThread` → `TaskChatLiveTail`), introduced with the experimental chat-style task view. **Current behavior** While a live run has no renderable transcript entries yet — the normal state for the multi-minute sandbox preparation window — the tail shows a static "Waiting for transcript...". The run's live `currentStatusMessage` (e.g. "Syncing workspace to sandbox", emitted by the sandbox-managed runtime's progress reporting) is available on the same live-run object but unused by this surface, although the earlier issue-chat view did display it. **Proposed behavior** When the tail is streaming a live run and no transcript rows exist yet, the empty-state message prefers the run's `currentStatusMessage`; the generic wait text remains the fallback when no runtime status has been reported (e.g. local runs that produce output immediately, or the brief pre-status window). **Reason and benefit** The preparation phases are real, reportable progress that the engine already emits. Showing them turns a minutes-long apparent hang into a legible status, for every adapter and execution target, using data the view already receives. ## What Changed - `ui/src/components/TaskChatThread.tsx`: the live tail's `emptyMessage` prefers `liveRun.currentStatusMessage` (guarded to the run the tail is actually streaming) over the static "Waiting for transcript..." fallback. Queued runs keep "Waiting to start...". - `ui/src/components/TaskChatThread.test.tsx`: a test covering both branches — a live run with a runtime status shows it (and not the wait text), and a run without one keeps the generic message. ## Verification - `vitest run ui/src/components/TaskChatThread.test.tsx ui/src/components/task-chat/TaskChatLiveTail.test.tsx`: 22/22 pass (including the new test) - `pnpm --filter @paperclipai/ui typecheck`: clean - Reproduced live: a `claude_local` run on a Daytona sandbox environment showed "Waiting for transcript..." for the full sync window; with this change the same window shows the streamed preparation statuses ## Risks - Low: a one-expression change to an empty-state string, active only while a live run has produced no renderable transcript rows. The fallback path is byte-identical to today. - `currentStatusMessage` is truncated/humanized upstream by the runtime-progress reporter; this surface renders it verbatim in the same muted style as the wait text. ## Model Used - Anthropic, **Claude Fable 5** (`claude-fable-5`) via Claude Code, with repository, shell, and Git tooling. It traced the runtime-progress mechanism end-to-end (engine emitter → heartbeat recorder → live-run API → both thread views), identified the dropped affordance in the chat-style view, and wrote the fix and test. ## 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
@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.