Skip to content

transcript: badge attachments with their type - #34

Open
Mark-Life wants to merge 1 commit into
mainfrom
atm/task-019fe615-eb64-75d9-84dd-262515c84606
Open

transcript: badge attachments with their type#34
Mark-Life wants to merge 1 commit into
mainfrom
atm/task-019fe615-eb64-75d9-84dd-262515c84606

Conversation

@Mark-Life

Copy link
Copy Markdown
Owner

Problem:

Every attachment row in a session transcript badges as attachment, so a skill listing and a file opened in the IDE look identical until you expand them. Both the inspector row (session-history.tsx) and the CLI row (sessions-history.tsx) label the badge e.toolName ?? e.kind, and attachments have no toolName. The transcript already knows the difference: handleAttachment in packages/core/src/services/sessions/parse.ts stores the raw attachment.type on the event as attachmentType, and nothing rendered it.

Solution:

eventBadgeLabel in packages/core/src/services/sessions/labels.ts is the one badge rule for both transcripts: tool name when there is one, else attachmentType with underscores replaced by spaces, else the bare kind. skill_listing becomes skill listing, opened_file_in_ide becomes opened file in ide. The transform is mechanical rather than a lookup table, so a type Claude starts writing tomorrow reads as words on the day it appears. A missing, empty, or whitespace-only type falls back to attachment.

attachmentType joins ROW_FIELDS in apps/inspector/src/lib/transcript-row.ts, so the memo comparison sees a badge that changed.

Badge width in the CLI: unchanged. BADGE_MAX there is 20, not 12, so opened file in ide (18 chars) renders whole — the render test asserts the full string in an 80-cell frame. A future type longer than 20 chars clips, as tool names already do.

The kind filter's Attachments option is untouched and still selects kind === "attachment", which is not broken but is now coarser than the rows beside it. One gap worth a follow-up: history search matches title, which holds the raw skill_listing, so searching the humanised skill listing finds nothing.


Security Impact:

None.


Testing:

packages/core:    5 pass, 0 fail   (test/sessions/labels.test.ts)
apps/inspector:   6 pass, 0 fail
apps/cli:         3 pass, 0 fail   (test/sessions-ui.test.tsx)

The core tests cover skill_listing, opened_file_in_ide, an invented type, and the missing/empty/whitespace fallbacks. The CLI test renders a session of three attachments and asserts the humanised badges appear in the frame. bun run typecheck passes across all 9 packages. Two pre-existing failures in packages/core/test/agents.test.ts are unrelated and fail identically on the base commit. Before, all three rows read attachment; after, only the typeless one does.

Every attachment badged as `attachment`, so a skill listing and a file
opened in the IDE looked identical until expanded. `eventBadgeLabel`
humanises `attachmentType` mechanically, so a type that appears tomorrow
reads as words with no code change.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant