@workerdeck/ui 0.16.0 → 0.18.0

package/src/components/terminal/tool-run.ts

@@ -17,6 +17,7 @@
  * `result-preview.ts` exists. Two spellings would be two different heights.
  */
 import type { TranscriptItem } from '@workerdeck/react'
+import { toolInputPreview } from '../../lib/format.ts'
 import { isShellTool } from '../../lib/tool-icon.ts'
 
 type ToolCallItem = Extract<TranscriptItem, { kind: 'tool_call' }>
@@ -89,3 +90,179 @@ export function runSummary(items: readonly ToolCallItem[], busy: boolean): strin
   // read, 1 shell" reads as though the sentence ended and then carried on.
   return `${verb}${n} tool${n === 1 ? '' : 's'} · ${breakdown}${tail}`
 }
+
+/* ── The task block's one line ─────────────────────────────────────────────
+ *
+ * A `Task` call and everything its subagent produced collapse to one row (see
+ * `blocks.ts`), and these are that row's words. Same contract as `runSummary`:
+ * `height.ts` wraps these exact strings to predict the row's pixel height with
+ * no DOM, so the component must render them verbatim — two spellings would be
+ * two different heights.
+ */
+
+const clip = (text: string, max = 80): string =>
+  text.length > max ? text.slice(0, max - 1) + '…' : text
+
+const trimmed = (value: unknown): string | undefined =>
+  typeof value === 'string' && value.trim() !== '' ? value.trim() : undefined
+
+/**
+ * The row's identity half: which task this is.
+ *
+ * The Claude SDK's `Task` input carries `subagent_type` (e.g. "Explore") and a
+ * 3–5 word `description`, and both are worth the line: parallel tasks are the
+ * whole reason the block exists, and two rows both reading `Task(…)` answer
+ * nothing. `Task(Explore · find the auth check)` — falling back to the
+ * ordinary input preview when an engine sends neither, so the header is never
+ * emptier than a plain tool row's.
+ */
+export function taskLabel(task: ToolCallItem): string {
+  return `${task.name}(${taskIdentity(task)})`
+}
+
+/**
+ * The inner half of {@link taskLabel} — `Explore · find the auth check` — without
+ * the `Task(…)` wrapper.
+ *
+ * Split out for the sub-agent takeover's header, which names the agent it is
+ * showing and has no room (or reason) to repeat the tool's own name: the whole
+ * surface *is* that Task. Extracted rather than re-spelled so the header and the
+ * row it was opened from cannot drift, and so both keep matching protocol's
+ * `subagentLabel`, which reads the same two input fields for the sessions list.
+ */
+export function taskIdentity(task: ToolCallItem): string {
+  const input = task.input as { description?: unknown; subagent_type?: unknown } | null
+  const description = trimmed(input?.description)
+  const agent = trimmed(input?.subagent_type)
+  return agent && description
+    ? `${agent} · ${clip(description)}`
+    : (agent ?? (description ? clip(description) : toolInputPreview(task.input)))
+}
+
+/**
+ * **What this agent was actually asked** — the sub-agent's brief, or undefined
+ * when the engine did not give us one.
+ *
+ * Measured against a live session rather than assumed: the Agent SDK's call
+ * carries `{description, subagent_type, run_in_background, prompt}`, and
+ * `prompt` is the instruction.
+ *
+ * **Whether it also arrives in the stream depends on the agent.** A foreground
+ * `Task` forwards its brief as a real nested `user_message` (that is what
+ * `forwardSubagentText` buys and what the reducer stamps a `parentToolUseId`
+ * on), so `subagentItems` picks it up and the frame already has it. A
+ * **background** agent does not: measured on a session with eight of them,
+ * zero items carried a `parentToolUseId` on a `user` kind. Those runs are
+ * exactly the ones you open a takeover on — an agent working while you read
+ * something else — and their brief was nowhere at all.
+ *
+ * So this is the *fallback*, not the source: the callers splice it in only when
+ * the frame carries no brief of its own, or the same instruction would be drawn
+ * twice.
+ *
+ * `description` is deliberately not a fallback: it is the 3–5 word label the
+ * header already prints, and repeating it as a brief would claim we know the
+ * instruction when we do not. **Codex genuinely has none** — its `spawn_agent`
+ * message is an encrypted blob on the wire — so on that engine this is
+ * undefined and the row is not drawn, rather than drawn empty.
+ */
+export function taskBrief(task: ToolCallItem): string | undefined {
+  const input = task.input as { prompt?: unknown } | null
+  return trimmed(input?.prompt)
+}
+
+const callBusy = (call: ToolCallItem): boolean =>
+  call.status === 'running' || call.status === 'pending'
+
+/** Did this one call fail? Both spellings are needed: an out-of-loop execution
+ * failure sets `status` with no `is_error` block to read, and an engine can flag
+ * `is_error` on a call the reducer has not settled yet. */
+export const callFailed = (call: ToolCallItem): boolean =>
+  call.status === 'failed' || call.result?.isError === true
+
+/**
+ * Does a folded run colour red? **Only when its last call failed.**
+ *
+ * It used to be `some`, on the argument that a failure should colour the block
+ * rather than fragment it. The argument was right about not fragmenting and
+ * wrong about `some`: a run is a sequence the model worked through, and a
+ * failure it recovered from two calls later is how work goes — a grep that
+ * matched nothing, a build fixed on the second go. Reddening the whole run for
+ * it means a normal working session is painted red, which spends the colour
+ * that should have been left for the one thing still broken.
+ *
+ * The last call is the run's *outcome*, and an outcome is what a collapsed row
+ * can honestly claim. The failures inside it are not hidden — they are one
+ * press away, each red on its own row, and the recap counts every one. The
+ * **scrubber agrees with this rule** rather than overriding it: it marks a
+ * failed call only when the call is its row's outcome, which for a run is
+ * exactly this one. It used to mark every member on the argument that the
+ * rail asks a different question; against a real session that was nine alarms
+ * on the rail for a transcript reddening one row.
+ */
+export function runFailed(items: readonly ToolCallItem[]): boolean {
+  const last = items[items.length - 1]
+  return last !== undefined && callFailed(last)
+}
+
+/** Is anything inside still going? The call itself, normally — the Task
+ * settles only when its subagent finishes — but a bridged or deferred child
+ * can outlive it, and a pulse that stopped while a child still worked would
+ * read as a hang. */
+export function taskBusy(task: ToolCallItem, children: readonly TranscriptItem[]): boolean {
+  return callBusy(task) || children.some((child) => child.kind === 'tool_call' && callBusy(child))
+}
+
+/**
+ * Does the row colour red? **The task's own outcome, and nothing else.**
+ *
+ * It used to be "or any child call's", which does not survive contact with a
+ * real subagent: an agent that ran a hundred calls, one of them a grep that
+ * matched nothing, came back with a red line saying it had failed. It had not —
+ * it had done exactly what it was asked, and the transcript said otherwise in
+ * the one colour reserved for things that need a human.
+ *
+ * This is the call `SubagentInfo.status` already makes, and it made it for this
+ * reason (see `packages/protocol`): the sub-agent's **own** `tool_result`
+ * `is_error`, deliberately not `taskFailed`. The argument there was that a
+ * nothing-matched grep must not read as a failed run *beside a session name*;
+ * what a hundred-call agent shows is that it must not read that way beside the
+ * `Task` row either. Two surfaces, one rule, one spelling.
+ *
+ * Nothing is concealed by this. A failed child is red on its own row, one press
+ * away, and the recap counts it. The **scrubber follows this rule too** and no
+ * longer marks such a child: a red tick on the rail says precisely what this
+ * row is forbidden from saying. The sub-agent band still says an agent ran
+ * here, and the task's own red tick still says it came back broken — which is
+ * what the two channels are for.
+ */
+export function taskFailed(task: ToolCallItem): boolean {
+  return callFailed(task)
+}
+
+/**
+ * The collapsed task row's one line: identity, then scale.
+ *
+ * `Task(Explore · find the auth check) · 7 tools…` while the subagent works —
+ * the count grows as it does, which is the row's progress reading, and the
+ * trailing ellipsis is the same in-flight signal `runSummary` uses (the pulse
+ * in the gutter carries the beat). Settled, the ellipsis drops:
+ * `… · 7 tools`. "Tools" and not "tool calls" because `runSummary` already
+ * chose that word for the same count one row over.
+ *
+ * The counts are counted from the absorbed children, never read from the
+ * engine's structured Task output — WorkerDeck does not plumb structured tool
+ * results to clients, so a transcript replayed tomorrow must spell the same
+ * line from the same items it holds today.
+ *
+ * With no tool calls yet — the subagent thinking, or only its brief arrived —
+ * the line says `working…`, because `0 tools…` reads as a stall; settled with
+ * none it says `done`.
+ */
+export function taskSummary(task: ToolCallItem, children: readonly TranscriptItem[]): string {
+  const busy = taskBusy(task, children)
+  const calls = children.reduce((n, child) => n + (child.kind === 'tool_call' ? 1 : 0), 0)
+  const label = taskLabel(task)
+  if (calls === 0) return busy ? `${label} · working…` : `${label} · done`
+  return `${label} · ${calls} tool${calls === 1 ? '' : 's'}${busy ? '…' : ''}`
+}

package/src/index.ts

@@ -180,13 +180,32 @@ export {
 export { SessionStatusIcon } from './components/agent/SessionBrowser.tsx'
 // Lifted out of the VS Code sidebar once the dashboard grew a collapsed rail
 // that needs the same glyph — two copies of a trademark set is one too many.
-export { EngineIcon } from './components/agent/EngineIcon.tsx'
+export {
+  EngineIcon,
+  engineMark,
+  vendorMarkClass,
+  vendorTextClass,
+} from './components/agent/EngineIcon.tsx'
+// Lifted out of the sidebar for the same reason: the work under a row is a
+// protocol fact, so every list annotates it with one component.
+export {
+  type Step,
+  StepRow,
+  StepToggle,
+  runningSteps,
+  sessionSteps,
+} from './components/agent/SessionSteps.tsx'
+// The sub-agent takeover's one line. Exported for hosts that draw their own
+// panel chrome; the panel raises it itself.
+export { SubagentStrip } from './components/agent/SubagentStrip.tsx'
+export { ProjectIcon } from './components/agent/ProjectIcon.tsx'
 export {
   SessionEmptyState,
   type SessionEmptyStateProps,
 } from './components/agent/SessionEmptyState.tsx'
 export { PromptTokenText } from './components/agent/PromptTokenText.tsx'
 export { STATUS_META } from './components/agent/status.ts'
+export { ContextRing } from './components/agent/ContextRing.tsx'
 
 // Utilities
 export { cn } from './lib/utils.ts'

package/src/lib/status.ts

@@ -1,4 +1,4 @@
-import type { ContextUsage, ModelOption, RateLimitInfo, SessionStatus } from '@workerdeck/protocol'
+import type { ModelOption, RateLimitInfo, SessionStatus } from '@workerdeck/protocol'
 
 /**
  * How a session's live readings become a status line — the pure half, so every
@@ -174,7 +174,20 @@ export function modelLabel(vitals: ModelReadings | undefined): string {
 }
 
 /** Context percentage as its meter severity — the reading and the colour come
- * from one place so a panel and a status bar never disagree. */
-export function contextSeverity(usage: ContextUsage | undefined): StatusSeverity {
+ * from one place so a panel and a status bar never disagree.
+ *
+ * Takes only the number it reads, so the compact `ContextReading` that rides
+ * the sessions list and the full `ContextUsage` on the event stream are coloured
+ * by one rule rather than two. */
+export function contextSeverity(usage: { percentage: number } | undefined): StatusSeverity {
   return meterSeverity(usage?.percentage)
 }
+
+/** {@link meterSeverity} as a text colour class. Here rather than beside each
+ * meter because the status bar, the context dialog and a sessions-list row all
+ * paint the same reading, and a fourth copy of the thresholds is a fourth
+ * chance for one surface to call 81% orange and another call it grey. */
+export function meterColorClass(pct: number | undefined): string {
+  const severity = meterSeverity(pct)
+  return severity === 'error' ? 'text-danger' : severity === 'warning' ? 'text-warning' : 'text-fg-3'
+}

package/src/styles/terminal.css

@@ -99,6 +99,13 @@
   /* The user's own prompt row. */
   --term-user-bg: rgb(255 255 255 / 0.05);
   --term-row-hover: rgb(255 255 255 / 0.05);
+  /* Behind an OPEN block. Yellow, not neutral, and the theme's one deliberate
+     reuse of that tone for something other than "waiting on you": an open block
+     is a state the reader put the transcript into, and on the phone it wants
+     the same colour as the rail mark that says so. Kept very low — this washes
+     whole regions, and at band strength an opened run would shout louder than
+     anything inside it. */
+  --term-open-wash: rgb(215 186 125 / 0.1);
 }
 
 [data-theme='light'] [data-terminal],
@@ -125,6 +132,7 @@
   --term-band-bg: rgb(0 0 0 / 0.04);
   --term-user-bg: rgb(0 0 0 / 0.05);
   --term-row-hover: rgb(0 0 0 / 0.04);
+  --term-open-wash: rgb(215 186 125 / 0.25);
 }
 
 /* ── Rows ────────────────────────────────────────────────────────────────────
@@ -284,11 +292,30 @@
    stack without a step. (The other half is `useRevealOnOpen`, which brings that
    first line back when it has gone above the fold.) */
 [data-terminal] .term-open {
-  background: var(--term-row-hover);
+  background: var(--term-open-wash);
   margin-inline: calc(-1 * var(--term-bleed, 0px));
   padding-inline: var(--term-bleed, 0px);
 }
 
+/* Another frame of reference: the rows a subagent produced, inside the `Task`
+   that spawned them.
+
+   Two cells of indent, whole — the theme's rule is that horizontal measures are
+   `ch`, and these rows carry markers in a gutter that has to keep landing on the
+   grid the rows above it use. The rule itself is drawn *inside* that padding
+   with an inset shadow rather than as a border, which is what makes the 2ch
+   exact: a 1px border is layout, and would put every nested glyph one pixel off
+   the column for the sake of chrome.
+
+   `--term-faint` rather than the cards `--border` token, and that is the whole
+   reason this class exists: the nested block sits on the *open* block's wash,
+   and a border colour tuned for the base ground resolved to rgb(31,31,31) on it
+   — a rule nobody could see. The same trap `row-hover` is alpha to avoid. */
+[data-terminal] .term-nested {
+  padding-left: 2ch;
+  box-shadow: inset 1px 0 0 var(--term-faint);
+}
+
 .term-hoverable {
   position: relative;
 }
@@ -920,8 +947,8 @@
    as long without a tall solid bar shouting over the rail. A minimum-height
    mark shows only the solid segment, so short and long marks need no separate
    rules; the *lane* stays the pointer's target, so a 2px mark is still
-   findable. Full-width annotations (error, approval) stay solid: they are
-   alarms, not extents. */
+   findable. The alarms (error, approval) stay solid: they are alarms, not
+   extents. */
 .term-scrubber .term-scrub-mark[data-kind='user'] {
   background: linear-gradient(
     to bottom,
@@ -929,6 +956,19 @@
     color-mix(in srgb, var(--term-blue) 25%, transparent) 2px
   );
 }
+/* A sub-agent's stretch of the transcript, in the input lane: green, because
+   every other colour on this rail is already spoken for and none of them means
+   "somebody else's working" — blue is you, white is the answer, red is an
+   alarm, magenta is your bookmark, yellow is the session waiting on you. Drawn
+   as an extent (2px head, 25% tail) like the two marks it shares its geometry
+   with: collapsed it is a tick, expanded it is the band the sub-agent covers. */
+.term-scrubber .term-scrub-mark[data-kind='subagent'] {
+  background: linear-gradient(
+    to bottom,
+    var(--term-green) 0 2px,
+    color-mix(in srgb, var(--term-green) 25%, transparent) 2px
+  );
+}
 .term-scrubber .term-scrub-mark[data-kind='turn'] {
   background: linear-gradient(
     to bottom,
@@ -944,8 +984,8 @@
   );
 }
 .term-scrubber .term-scrub-mark[data-kind='error'] { background: var(--term-red); }
-/* A failed tool call is an alarm, so it is full-width and solid like the rest of
-   them — but at 55%, which is the one thing keeping the rail readable. A session
+/* A failed tool call is an alarm, so it is solid like the rest of them — in the
+   response lane, since it is something the run produced — but at 55%, which is the one thing keeping the rail readable. A session
    error is rare and a turn failure rarer; a tool that failed and was recovered
    from is routine (a grep that matched nothing, a build fixed on the second go),
    and at full strength a normal working session paints the rail solid red and
@@ -992,6 +1032,16 @@
   pointer-events: none;
   z-index: 11;
 }
+/* The sub-agent's brief, collapsed: clipped on the same wrapped lines
+   `briefPx` counts, so the height the virtualizer reserved and the height the
+   row draws cannot disagree. The count itself comes from the component
+   (`BRIEF_LINES`), one number rather than one here and one there. */
+.term-brief-clip {
+  display: -webkit-box;
+  -webkit-box-orient: vertical;
+  overflow: hidden;
+}
+
 .term-scrubber .term-scrub-ex {
   display: -webkit-box;
   -webkit-line-clamp: 4;
@@ -1009,3 +1059,33 @@
 [data-term-scrubber-host]::-webkit-scrollbar {
   display: none;
 }
+
+/* ── Images ──────────────────────────────────────────────────────────────────
+ *
+ * A picture a tool returned, drawn in a box of whole lines (`IMAGE_BOX_LINES`,
+ * set inline by `TerminalImage` so the constant has one spelling across the
+ * renderer and the height calculator). The height is on the element and nothing
+ * here may add to it: no margin, no border, no padding — a box that is not
+ * exactly N lines is a row the virtualizer was told the wrong size for.
+ *
+ * `object-fit: contain` with a top-left origin rather than a centred one: the
+ * grid's origin is the top-left of the body cell, and a screenshot floating in
+ * the middle of its box reads as a figure in a document instead of output on a
+ * line. */
+.term-image {
+  display: block;
+  overflow: hidden;
+}
+.term-image > img {
+  max-width: 100%;
+  height: 100%;
+  object-fit: contain;
+  object-position: left top;
+}
+/* The wash is the placeholder's whole visual: it says "something is reserved
+   here" for as long as the bytes are in flight, and it says it at the same
+   height the picture will occupy. */
+.term-image[data-state='pending'],
+.term-image[data-state='failed'] {
+  background: var(--term-band-bg);
+}

package/src/styles/theme.css

@@ -51,6 +51,37 @@
   --fg-4: #a1a1a1;
   --fg-disabled: #c9c9c9;
 
+  /* ---------- Vendor ----------
+   * The engine's own colour, worn by its mark and (where the brand allows) by
+   * the model name beside it in a sessions list. Nowhere else.
+   *
+   * This is the one place a brand colour is allowed in the product, and it earns
+   * it by doing a job nothing else on the row does: the list already spends blue
+   * on running, amber on waiting, red on failed and muted on idle, so none of
+   * those can also say *whose engine this is* — and the mark alone is a 12px
+   * silhouette.
+   *
+   * Two values per vendor, because that glyph has to hold against both grounds:
+   * the dark-ground value is lifted and the light-ground one darkened.
+   *
+   * **OpenAI's is monochrome, and that is their rule rather than our taste**:
+   * their guidelines forbid adding colour to the mark, so it is pure white on
+   * dark and a near-black on light — both sanctioned, and the only kind of pair
+   * legible on both grounds. A green was tried first and is wrong, however well
+   * it reads. Near-black rather than `#000` because pure black would sit *harder*
+   * than the session title above it, so the mark would out-weigh the name it is
+   * labelling.
+   *
+   * That makes the two vendors asymmetric, which is the honest outcome: coral is
+   * Anthropic's brand and monochrome is OpenAI's, so a rule that gave both an
+   * accent would misrepresent one of them. It also means OpenAI's token is at
+   * full contrast, which is why only the **mark** wears it — see
+   * `vendorTextClass` in `EngineIcon.tsx`.
+   *
+   * A third vendor is two declarations here and one map entry there. */
+  --vendor-claude: #b3573a;
+  --vendor-openai: #373737;
+
   /* ---------- Accent ----------
    * VS Code blue (`#0078d4`) — the product's primary. It is the *same* hue in
    * both themes rather than the inverse of the canvas: a primary that flips
@@ -122,6 +153,10 @@
   --fg-4: #6e6e6e;
   --fg-disabled: #454545;
 
+  /* ---------- Vendor ---------- (see the light block for the whole argument) */
+  --vendor-claude: #cc7c5e;
+  --vendor-openai: #ffffff;
+
   /* ---------- Accent ----------
    * The same blue as light. `--accent` stays `#0078d4` because it is a *fill*
    * carrying white text (4.6:1) — the brighter `#3794ff` would drop that to
@@ -275,6 +310,13 @@
   --color-info: var(--info);
   --color-info-bg: var(--info-bg);
 
+  /* Vendor colours as real utilities (`text-vendor-claude`), not hand-written
+     classes: `cn`'s tailwind-merge only knows to *replace* a colour it can parse,
+     and `EngineIcon` ships its own `text-fg-3` that the vendor class has to win
+     against rather than merely follow in source order. */
+  --color-vendor-claude: var(--vendor-claude);
+  --color-vendor-openai: var(--vendor-openai);
+
   /* Stock-name bridge → utilities (bg-primary / text-muted-foreground / ...). */
   --color-primary: var(--primary);
   --color-primary-foreground: var(--primary-foreground);