Dashboard: Transcript viewer using claude-code-query log parsing #353

New issue

Open

opened 2026-04-15 08:44:30 +00:00 by mprihoda · 1 comment

mprihoda commented

2026-04-15 08:44:30 +00:00

(Migrated from github.com)

Layer: 3 — Agent Integration
Parent: #343

Problem

There's no way to see what an agent has been doing without attaching to the tmux session. When managing multiple worktrees, you need to quickly review what happened in a session — what the agent did, what tools it used, what decisions it made.

Solution

Parse Claude Code transcripts using the claude-code-query library (ConversationLogReader, ConversationLogIndex)
Render conversation in the dashboard — show user messages, assistant responses, tool usage, thinking blocks
Session list — show available sessions for a worktree, ordered by recency
Auto-refresh — when viewing a live session, stream new entries as they appear
Collapsible tool use blocks — tool calls can be verbose, show them collapsed by default with expand option

Dependencies

works.iterative:claude-code-query-core_3 for log parsing types
Either claude-code-query-direct or claude-code-query-effectful for reading logs

Key types from claude-code-query

ConversationLogIndex.listSessions(projectPath) — discover sessions
ConversationLogReader.readAll(path) / .stream(path) — read entries
ConversationLogEntry with LogEntryPayload variants (UserLogEntry, AssistantLogEntry, ToolUse, etc.)
LogFileMetadata — session ID, last modified, summary, git branch

**Layer:** 3 — Agent Integration **Parent:** #343 ## Problem There's no way to see what an agent has been doing without attaching to the tmux session. When managing multiple worktrees, you need to quickly review what happened in a session — what the agent did, what tools it used, what decisions it made. ## Solution 1. **Parse Claude Code transcripts** using the `claude-code-query` library (`ConversationLogReader`, `ConversationLogIndex`) 2. **Render conversation in the dashboard** — show user messages, assistant responses, tool usage, thinking blocks 3. **Session list** — show available sessions for a worktree, ordered by recency 4. **Auto-refresh** — when viewing a live session, stream new entries as they appear 5. **Collapsible tool use blocks** — tool calls can be verbose, show them collapsed by default with expand option ## Dependencies - `works.iterative:claude-code-query-core_3` for log parsing types - Either `claude-code-query-direct` or `claude-code-query-effectful` for reading logs ## Key types from claude-code-query - `ConversationLogIndex.listSessions(projectPath)` — discover sessions - `ConversationLogReader.readAll(path)` / `.stream(path)` — read entries - `ConversationLogEntry` with `LogEntryPayload` variants (UserLogEntry, AssistantLogEntry, ToolUse, etc.) - `LogFileMetadata` — session ID, last modified, summary, git branch

claude referenced this issue

2026-10-16 04:45:24 +00:00

Dashboard: Browser-based agent sessions with SSE streaming #355

claude referenced this issue

2026-10-16 04:48:14 +00:00

Dashboard: Send instructions to running agent from browser #354

claude commented

2026-10-16 05:51:55 +00:00

Member

Intake: needs-input
Workflow: waterfall
Reason: G1 (1 CLARIFY marker), G7 (1 [human] finding)
Analysis: project-management/issues/IW-353/analysis.md on branch IW-353

1. Should a live session page follow new entries through the library's chat element over SSE, or by HTMX polling? (G1)

The dashboard stack is fixed as Web Awesome, Tailwind v4, Vite and HTMX 2 on Cask/Scalatags (decision DCP-D1). The effort map gives SSE streaming to the later issue #355 (browser agent sessions). Option a) brings the library's <cc-chat> element and SSE into this issue. See the open question and the follow design.

a) The <cc-chat follow> element and one SSE follow route. The newest-page view loads a 683 KB bundle. Each open follow holds one Cask worker thread. You add a new DCP decision to decisions.md and change the #355 line in map.md to match.
b) HTMX polling every 5 s. The server answers 204 when nothing changed, and a handler in dashboard.js applies the library's tail. No SSE, no new decision, no map change, and phase 3 becomes 4-7 h. But the dashboard then has a second client half of the transcript rendering, which goes against claude-code-query's PRODUCT.md, and its 204 is not the library's heartbeat contract.

Recommended: a), because #355 needs this element anyway, so with b) we would discard the follow code one issue later.

2. Transcript images get a 404 on the dashboard. Which fix do you want? (G7)

The library draws each image tool result as <img src="/v1/sessions/<id>/artifact?call=…&part=…">. That address starts at the site root and does not take the worktree prefix of the element. No route in the analysis serves it, so every image breaks, on both the newest and older page views. On this machine, 52 transcripts hold image parts. See the review finding.

a) Serve GET /v1/sessions/:sessionId/artifact through the library's TranscriptHistory.artifactIn. Images work. It is a root route that is not scoped to a worktree, so it must find the session id across all worktrees. This adds one more route and one more lookup to review.
b) Keep the broken images and file a follow-up. No new work now. Each image shows as a broken image until the follow-up is done.
c) Remove or rewrite the img rows in the dashboard before it renders them. No root route, but the dashboard then changes library markup, which the design tries not to do.

Recommended: a), because images are real content in many transcripts, and the library already gives the reader for them.

Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

Intake: needs-input Workflow: waterfall Reason: G1 (1 CLARIFY marker), G7 (1 [human] finding) Analysis: project-management/issues/IW-353/analysis.md on branch IW-353 ### 1. Should a live session page follow new entries through the library's chat element over SSE, or by HTMX polling? (G1) The dashboard stack is fixed as Web Awesome, Tailwind v4, Vite and HTMX 2 on Cask/Scalatags (decision DCP-D1). The effort map gives SSE streaming to the later issue #355 (browser agent sessions). Option a) brings the library's `<cc-chat>` element and SSE into this issue. See the [open question](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-353/project-management/issues/IW-353/analysis.md#L215-L223) and the [follow design](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-353/project-management/issues/IW-353/analysis.md#L30-L35). - **a) The `<cc-chat follow>` element and one SSE follow route.** The newest-page view loads a 683 KB bundle. Each open follow holds one Cask worker thread. You add a new DCP decision to decisions.md and change the #355 line in map.md to match. - **b) HTMX polling every 5 s.** The server answers 204 when nothing changed, and a handler in `dashboard.js` applies the library's tail. No SSE, no new decision, no map change, and phase 3 becomes 4-7 h. But the dashboard then has a second client half of the transcript rendering, which goes against claude-code-query's PRODUCT.md, and its 204 is not the library's heartbeat contract. **Recommended: a)**, because #355 needs this element anyway, so with b) we would discard the follow code one issue later. ### 2. Transcript images get a 404 on the dashboard. Which fix do you want? (G7) The library draws each image tool result as `<img src="/v1/sessions/<id>/artifact?call=…&part=…">`. That address starts at the site root and does not take the worktree prefix of the element. No route in the analysis serves it, so every image breaks, on both the [newest and older page views](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-353/project-management/issues/IW-353/analysis.md#L159-L160). On this machine, 52 transcripts hold image parts. See the [review finding](https://code.iterative.works/iterative-works/iw-cli/src/branch/IW-353/project-management/issues/IW-353/analysis.md#L447). - **a) Serve `GET /v1/sessions/:sessionId/artifact`** through the library's `TranscriptHistory.artifactIn`. Images work. It is a root route that is not scoped to a worktree, so it must find the session id across all worktrees. This adds one more route and one more lookup to review. - **b) Keep the broken images and file a follow-up.** No new work now. Each image shows as a broken image until the follow-up is done. - **c) Remove or rewrite the `img` rows** in the dashboard before it renders them. No root route, but the dashboard then changes library markup, which the design tries not to do. **Recommended: a)**, because images are real content in many transcripts, and the library already gives the reader for them. Answer in a comment on this issue, per number, for example "1: a", or in your own words; intake reads it on its next iteration.

claude added the

needs-input

label

2026-10-16 05:51:55 +00:00