The ToolCard sandbox (?mode=tool-sandbox, shipped in #TODO) established a pattern: dev-only route, fixture-driven, renders real components via Vite HMR, gated by import.meta.env.DEV so prod tree-shakes it.
Several other UI surfaces in the renderer would benefit from the same treatment — they're either hard to exercise in live sessions, have many state variants that need visual polish, or are easy to regress when adding themes/variants. Candidates:
- ChatView / AssistantTurnBubble sandbox — full turn rendering (user bubble → assistant text → tool cards → footer metadata) with fixtures covering normal completion, non-
end_turn stop reasons, extended-thinking heartbeats, and interrupt markers. Lets us iterate on turn-level layout without needing a live Claude Code session.
- AttentionBanner sandbox — one panel per state (
awaiting-input, shell-idle, error, stuck, session-died). Currently only reachable by waiting for the PTY classifier to trip, which is slow and fragile.
- Permission flow sandbox — tool cards in
awaiting-approval with Yes/No/Always buttons. Hard to reproduce live on demand; easy to regress when touching the hook relay.
- StatusBar widget sandbox — every widget in every state (announcement present/absent/expired, sync warnings of each code, tool-use counter, attention dot colors, etc.). Useful when theming or reworking the status strip.
- Overlay layer sandbox — mount
Scrim + OverlayPanel at L1-L4 with and without destructive variant, under glassmorphism on/off, across every theme. Catches scrim/blur/shadow regressions when a theme is added or the token system changes.
- Theme gallery — render a representative slice of components (bubble, card, panel, input, status chip) under every installed theme side-by-side. Currently the only visual regression check is switching themes manually in the live app.
Shape of the work (per sandbox):
- New route under
dev/ (e.g. ?mode=chat-sandbox, ?mode=overlay-sandbox) behind the existing DEV gate
- Fixture corpus seeded from real transcripts / hook events where possible
- HMR-friendly render of real components with mocked context where needed
Why this is worth tracking:
Every one of the view experiments we want to run on ToolCard (Skill-as-pill, Agent compact, MCP compact views) has counterparts elsewhere in the UI. The pattern amortizes well — each new sandbox takes a morning and permanently speeds up the next five iterations on its surface.
Not urgent. Track as backlog, open fresh issues or PRs when a specific sandbox is needed for upcoming work. This issue is the umbrella so we don't re-derive the idea each time.
The ToolCard sandbox (
?mode=tool-sandbox, shipped in #TODO) established a pattern: dev-only route, fixture-driven, renders real components via Vite HMR, gated byimport.meta.env.DEVso prod tree-shakes it.Several other UI surfaces in the renderer would benefit from the same treatment — they're either hard to exercise in live sessions, have many state variants that need visual polish, or are easy to regress when adding themes/variants. Candidates:
end_turnstop reasons, extended-thinking heartbeats, and interrupt markers. Lets us iterate on turn-level layout without needing a live Claude Code session.awaiting-input,shell-idle,error,stuck,session-died). Currently only reachable by waiting for the PTY classifier to trip, which is slow and fragile.awaiting-approvalwith Yes/No/Always buttons. Hard to reproduce live on demand; easy to regress when touching the hook relay.Scrim+OverlayPanelat L1-L4 with and without destructive variant, under glassmorphism on/off, across every theme. Catches scrim/blur/shadow regressions when a theme is added or the token system changes.Shape of the work (per sandbox):
dev/(e.g.?mode=chat-sandbox,?mode=overlay-sandbox) behind the existing DEV gateWhy this is worth tracking:
Every one of the view experiments we want to run on ToolCard (Skill-as-pill, Agent compact, MCP compact views) has counterparts elsewhere in the UI. The pattern amortizes well — each new sandbox takes a morning and permanently speeds up the next five iterations on its surface.
Not urgent. Track as backlog, open fresh issues or PRs when a specific sandbox is needed for upcoming work. This issue is the umbrella so we don't re-derive the idea each time.