@workerdeck/ui 0.13.0 → 0.16.0

package/src/styles/terminal.css

@@ -0,0 +1,1011 @@
+/*
+ * The terminal theme's geometry and palette.
+ *
+ * Plain CSS classes rather than Tailwind utilities, and deliberately. This is a
+ * *renderer*: every row it draws lands on the same character cell, and a grid
+ * that has to be reassembled from `gap-2 pl-[calc(...)] -mx-1` at each call site
+ * is a grid that drifts the first time someone edits one row. The components in
+ * `components/terminal/` are therefore thin — they choose a class and a tone,
+ * and the geometry lives here in one place where it can be read as a whole.
+ *
+ * It also means an embedder gets the geometry without configuring Tailwind's
+ * `@source` scanning: these class names exist whether or not the scanner found
+ * the components that use them.
+ *
+ * ── The two rules everything else follows ────────────────────────────────────
+ *
+ * 1. **Horizontal measures are `ch`, never px or rem.** `1ch` in a monospace
+ *    face is exactly one cell, so a gutter is `2ch` and an indent level is
+ *    `2ch`, and text lands on a column rather than near one. A wrapped line
+ *    hangs under its own first character because the body is its own grid
+ *    column — not because a padding and a negative text-indent were tuned
+ *    against each other.
+ * 2. **Vertical measures are whole multiples of `--term-line`, never padding.**
+ *    Blank space between blocks is a *blank line* (an empty row), the way it is
+ *    in a terminal. Nothing has margins, so no two blocks can disagree about
+ *    the rhythm, and a row's height is always an integer number of lines — the
+ *    thing that keeps text off half-pixels and out of the blur.
+ *
+ * `--term-font-size` and `--term-line` must both be whole pixels. A line height
+ * of `1.5 × 13px` is 19.5px, and every second row of a long transcript then
+ * renders on a half-pixel: the text visibly softens and hard-edged backgrounds
+ * (the diff bands) show a seam. Integers are not a preference here.
+ */
+
+[data-terminal] {
+  /* Metrics. Overridable per host — VS Code hands its editor font down, and a
+     phone wants a larger cell — but always in whole pixels. */
+  --term-font-size: 13px;
+  --term-line: 18px;
+  /* One indent level, and the width of a gutter. The same value on purpose:
+     a child row's marker sits exactly where its parent's text began. */
+  --term-cell: 2ch;
+
+  font-family: var(--cw-font-mono);
+  font-size: var(--term-font-size);
+  line-height: var(--term-line);
+  color: var(--term-fg);
+  /* Ligatures turn `=>` and `!=` into glyphs that no longer occupy the cells
+     they were measured as. A grid renderer cannot have that. */
+  font-variant-ligatures: none;
+  font-feature-settings: 'liga' 0, 'calt' 0;
+  /* `ch` is the advance of `0`, so tabular figures keep digit columns — the
+     diff's line numbers — genuinely aligned. */
+  font-variant-numeric: tabular-nums;
+  -webkit-font-smoothing: antialiased;
+  tab-size: 2;
+}
+
+/* ── Palette ─────────────────────────────────────────────────────────────────
+ *
+ * The terminal's own colours, not the app's. `--accent` is VS Code blue because
+ * WorkerDeck's chrome shares an editor's visual language; a terminal shares a
+ * terminal's, and the two must not be forced to agree. Anything reading a
+ * `--term-*` token therefore keeps its colour when the surrounding app is
+ * re-themed, which is the point: the transcript looks like the CLI wherever it
+ * is embedded.
+ *
+ * Values are read off the Claude Code CLI on a dark terminal: body text is a
+ * light grey rather than white (white is reserved for emphasis, so bold has
+ * somewhere to go), meta lines are one step down again, and the working mark is
+ * the product's coral.
+ */
+[data-terminal] {
+  --term-fg: #d4d4d4;
+  --term-bright: #ffffff;
+  --term-dim: #8a8a8a;
+  --term-faint: #6a6a6a;
+
+  --term-mark: #d97757;
+  --term-blue: #afb9fe;
+  --term-green: #4ec9a0;
+  --term-red: #f14c4c;
+  --term-yellow: #d7ba7d;
+  --term-magenta: #c586c0;
+
+  /* Diff bands. Full-bleed backgrounds, so they are tuned to sit under body
+     text rather than to be looked at: the CLI's added block is a dark green
+     wash the text stays legible on, not a highlight. */
+  --term-add-fg: #b5e8a9;
+  --term-add-bg: #16301a;
+  --term-del-fg: #f0a6a6;
+  --term-del-bg: #3a1518;
+  /* The unchanged context inside a diff, and the line-number column. */
+  --term-diff-fg: #9a9a9a;
+  --term-diff-num: #5a5a5a;
+
+  /* A band of code or output. Barely there — one step off the canvas. */
+  --term-band-bg: rgb(255 255 255 / 0.04);
+  /* The user's own prompt row. */
+  --term-user-bg: rgb(255 255 255 / 0.05);
+  --term-row-hover: rgb(255 255 255 / 0.05);
+}
+
+[data-theme='light'] [data-terminal],
+[data-terminal][data-theme='light'] {
+  --term-fg: #2f2f2f;
+  --term-bright: #000000;
+  --term-dim: #6b6b6b;
+  --term-faint: #8d8d8d;
+
+  --term-mark: #bf5b3d;
+  --term-blue: #0a66c2;
+  --term-green: #16794a;
+  --term-red: #c62828;
+  --term-yellow: #8a6d00;
+  --term-magenta: #8b3a8b;
+
+  --term-add-fg: #12492a;
+  --term-add-bg: #e2f6e5;
+  --term-del-fg: #7a1f24;
+  --term-del-bg: #fbe6e7;
+  --term-diff-fg: #4a4a4a;
+  --term-diff-num: #9a9a9a;
+
+  --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);
+}
+
+/* ── Rows ────────────────────────────────────────────────────────────────────
+ *
+ * One row = a gutter cell and a body cell. The gutter holds the marker (`●`,
+ * `⎿`, `>`) or nothing at all; the body holds the text and wraps inside its own
+ * column, which is what gives every row its hanging indent for free.
+ */
+.term-row {
+  display: grid;
+  grid-template-columns: var(--term-cell) minmax(0, 1fr);
+  align-items: start;
+  min-height: var(--term-line);
+}
+
+/* Indent levels. A nested row steps one cell per level — the same 2 columns a
+   marker occupies, so a child's marker sits under its parent's first letter. */
+.term-row[data-indent='1'] { padding-left: var(--term-cell); }
+.term-row[data-indent='2'] { padding-left: calc(2 * var(--term-cell)); }
+.term-row[data-indent='3'] { padding-left: calc(3 * var(--term-cell)); }
+
+.term-gutter {
+  /* `pre` so a space-only gutter keeps its cell — an unmarked row must still
+     start its text on the same column as a marked one. */
+  white-space: pre;
+  user-select: none;
+  color: var(--term-dim);
+}
+
+.term-body {
+  min-width: 0;
+  /* Preserve the run's own spacing, wrap at the viewport edge. `break-word`
+     rather than `anywhere`: a long path should wrap, a sentence should not be
+     chopped mid-word when a shorter break exists. */
+  white-space: pre-wrap;
+  overflow-wrap: break-word;
+}
+
+/* A blank line — the only vertical spacing in the theme. Exactly one row tall
+   and holding nothing, which is what a terminal's blank line is. */
+.term-blank {
+  height: var(--term-line);
+}
+
+/* A row `scrollIntoView`ed lands one line below the top edge rather than flush
+   against it, so the target reads as the start of something rather than as
+   content cut off by the frame. Only the recap's `'center'` jump still goes
+   through scrollIntoView — the scrubber's `'start'` jumps compute their own
+   offset (a sticky row's rect is wherever it is pinned) and land the line at
+   exactly the top edge. */
+[data-terminal] [data-slot='transcript-rows'] [data-index] {
+  scroll-margin-block-start: var(--term-line);
+}
+
+/* The same blank line, as padding on a virtualized row's measured wrapper.
+   Identical height, and it must be padding there rather than a `<Blank/>`: the
+   virtualizer measures one element per item, so space between two items has to
+   be part of one of them or it is not measured at all. */
+[data-terminal] .term-row-gap {
+  padding-top: var(--term-line);
+}
+
+/* ── Bands ───────────────────────────────────────────────────────────────────
+ *
+ * A run of rows carrying a background: a code block, a command's output, a diff
+ * hunk. Full-bleed — the wash reaches the scroller's edges rather than stopping
+ * at a content gutter, because in a terminal the line *is* the full width.
+ * `--term-bleed` is how far out that is; the transcript sets it to its own
+ * padding and the band cancels it with matched negative margin and padding.
+ */
+.term-band {
+  background: var(--term-band-bg);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  padding-inline: var(--term-bleed, 0px);
+}
+
+/* ── Tones ───────────────────────────────────────────────────────────────────
+ *
+ * Colour as an attribute rather than a class per palette entry: a row component
+ * takes `tone` and passes it straight through, so adding a colour is one line
+ * here and nothing in the components.
+ */
+[data-terminal] [data-tone='fg'] { color: var(--term-fg); }
+[data-terminal] [data-tone='bright'] { color: var(--term-bright); }
+[data-terminal] [data-tone='dim'] { color: var(--term-dim); }
+[data-terminal] [data-tone='faint'] { color: var(--term-faint); }
+[data-terminal] [data-tone='mark'] { color: var(--term-mark); }
+[data-terminal] [data-tone='blue'] { color: var(--term-blue); }
+[data-terminal] [data-tone='green'] { color: var(--term-green); }
+[data-terminal] [data-tone='red'] { color: var(--term-red); }
+[data-terminal] [data-tone='yellow'] { color: var(--term-yellow); }
+[data-terminal] [data-tone='magenta'] { color: var(--term-magenta); }
+
+/* Weight is the only other axis. A terminal has one type size, so emphasis has
+   to be carried by weight and colour — never by a larger glyph. */
+[data-terminal] [data-weight='bold'] { font-weight: 600; }
+
+/* The scroller. Its horizontal padding IS `--term-bleed` — that is the whole
+   contract a full-bleed band relies on — and its vertical padding is a line, so
+   the first row starts one blank line down like every other block. */
+[data-terminal].term-transcript {
+  padding-inline: var(--term-bleed, 0px);
+  padding-block: var(--term-line);
+}
+
+/* ── Interaction ─────────────────────────────────────────────────────────────
+ *
+ * A terminal has no buttons, but a transcript does have things you can open. The
+ * affordance is the hover fill on the row itself — nothing gains a border, a
+ * radius or a focus box that would take it off the grid.
+ */
+[data-terminal] .term-press {
+  display: block;
+  width: 100%;
+  margin: 0;
+  padding: 0;
+  border: 0;
+  background: none;
+  font: inherit;
+  color: inherit;
+  text-align: left;
+  cursor: pointer;
+  /* A transcript is read far more often than it is opened, so a pressable row
+     still has to be text you can drag a selection out of. The other half of
+     this is in `press.tsx`: the click that ends such a drag is refused. */
+  user-select: text;
+}
+/* The hover fill lives with the other affordances below — it is one, and it is
+   switchable for the same reason. */
+[data-terminal] .term-press:focus-visible {
+  outline: none;
+}
+
+/* ── Affordances ─────────────────────────────────────────────────────────────
+ *
+ * What a real terminal cannot do. Every one of these costs **no layout** — a
+ * fill is a background, an action is an absolutely positioned overlay one line
+ * tall — so switching them off leaves every glyph on the cell it was already on.
+ * See `components/terminal/affordances.tsx`.
+ */
+
+/* The hover fill, gated on the surface's declaration. Without `hover` in the
+   list the selector never matches and a pressable row is inert to the pointer,
+   which is what a host projecting to a real terminal wants. */
+[data-terminal][data-affordances~='hover'] .term-press:hover > .term-row,
+[data-terminal][data-affordances~='hover'] .term-press:focus-visible > .term-row {
+  background: var(--term-row-hover);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  padding-inline: var(--term-bleed, 0px);
+}
+
+/* An opened block keeps the fill the pointer gave it, for the whole of what it
+   opened. Eighty lines of output pushes its own first line off the top of the
+   screen, and without a wash there is nothing to say where the thing you
+   expanded began — or that these rows are one block at all. Full-bleed, like
+   every other wash; the hover fill inside it reaches the same edge, so the two
+   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);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  padding-inline: var(--term-bleed, 0px);
+}
+
+.term-hoverable {
+  position: relative;
+}
+/* Pinned to the block's first line at its right edge. Absolute, so the rows
+   below are exactly where they would have been without it. */
+[data-terminal] .term-actions {
+  position: absolute;
+  top: 0;
+  right: 0;
+  height: var(--term-line);
+  display: flex;
+  gap: 1ch;
+  padding-inline: 1ch;
+  background: var(--bg, transparent);
+  opacity: 0;
+  transition: opacity var(--motion-fast, 120ms);
+}
+[data-terminal] .term-hoverable:hover .term-actions,
+[data-terminal] .term-hoverable:focus-within .term-actions {
+  opacity: 1;
+}
+@media (hover: none) {
+  /* No pointer to hover with: showing them always is the only way they exist at
+     all, and a phone has the room. */
+  [data-terminal] .term-actions {
+    opacity: 1;
+  }
+}
+[data-terminal] .term-action {
+  font: inherit;
+  line-height: var(--term-line);
+  color: var(--term-dim);
+  background: none;
+  border: 0;
+  padding: 0;
+  cursor: pointer;
+}
+[data-terminal] .term-action:hover {
+  color: var(--term-fg);
+}
+
+/* What you typed, on a band of its own — the CLI's own treatment. */
+[data-terminal] .term-user {
+  background: var(--term-user-bg);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  padding-inline: var(--term-bleed, 0px);
+}
+
+[data-terminal] .term-link {
+  text-decoration: underline;
+  text-underline-offset: 2px;
+}
+
+/* A file path, while the modifier that would open it is held.
+ *
+ * Only then, and that is the point: a path *is* clickable but only under
+ * Cmd/Ctrl, so it should only look clickable then — an always-underlined path
+ * promises a plain click that does nothing. Applied by `usePathLinks` using the
+ * same test the click itself makes, so nothing lights up that a click ignores.
+ * Outside `[data-terminal]` too, since a cards transcript names files as well. */
+.wd-path-link {
+  text-decoration: underline;
+  text-underline-offset: 2px;
+  cursor: pointer;
+}
+
+/* A status-line reading that leads somewhere. Inline and unstyled until hovered
+   — the line is meant to be quiet, and five underlined segments would make it
+   the loudest row on screen. */
+[data-terminal] .term-reading {
+  font: inherit;
+  color: inherit;
+  background: none;
+  border: 0;
+  padding: 0;
+  cursor: pointer;
+}
+[data-terminal][data-affordances~='hover'] .term-reading:hover {
+  text-decoration: underline;
+  text-underline-offset: 2px;
+}
+
+/* ── Prompts ─────────────────────────────────────────────────────────────────
+ *
+ * The affordances a form needs, drawn without a single box or border that would
+ * take a row off the grid. Strokes are backgrounds (zero layout), the focused
+ * row is a fill, and the only "control" is a row you can press a number on.
+ */
+
+/* One line tall with the stroke through its middle, full-bleed — the boundary
+   between the run and the decision. */
+[data-terminal] .term-rule-row {
+  height: var(--term-line);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  background: linear-gradient(var(--term-dim), var(--term-dim)) left center / 100% 1px no-repeat;
+}
+/* Dashed, for a boundary *within* a prompt. A repeating gradient rather than a
+   dashed border, for the same no-layout reason. */
+[data-terminal] .term-rule-dashed {
+  background: repeating-linear-gradient(
+      to right,
+      var(--term-faint) 0 4px,
+      transparent 4px 8px
+    )
+    left center / 100% 1px no-repeat;
+}
+
+/* The focused option. A fill, never an outline: an outline is 2px of layout the
+   row does not have, and the browser's own focus ring would land between cells. */
+[data-terminal] .term-row[data-focused] {
+  background: var(--term-row-hover);
+  margin-inline: calc(-1 * var(--term-bleed, 0px));
+  padding-inline: var(--term-bleed, 0px);
+}
+
+/* An option's expanded detail (a preview, a reason field) lines up with the
+   option's own text — one gutter in, so it reads as belonging to that row. */
+[data-terminal] .term-detail {
+  padding-left: 5ch;
+}
+
+/* A framed payload: four 1px strokes as backgrounds, so the frame costs no
+   layout and the text inside stays on the cell it would have been on. */
+[data-terminal] .term-box {
+  padding-inline: var(--term-cell);
+  /* Sized to its content, never to the viewport: a preview is a sample, and a
+     frame stretched across a wide screen reads as a panel the reader is meant
+     to work in. */
+  width: max-content;
+  max-width: 100%;
+  background:
+    linear-gradient(var(--term-faint), var(--term-faint)) top left / 100% 1px no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) bottom left / 100% 1px no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) top left / 1px 100% no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) top right / 1px 100% no-repeat;
+}
+
+/* A question chip. Inline so the strip is one row; the active one is filled the
+   way the CLI fills it. */
+[data-terminal] .term-tab {
+  font: inherit;
+  color: inherit;
+  background: none;
+  border: 0;
+  padding: 0 1ch;
+  margin: 0;
+  cursor: pointer;
+}
+[data-terminal] .term-tab-active {
+  background: var(--term-blue);
+  color: var(--bg, #000);
+}
+
+/* The bare text field — a caret and a rule, no box. */
+[data-terminal] .term-input {
+  width: 100%;
+  min-width: 0;
+  font: inherit;
+  color: var(--term-fg);
+  background: none;
+  border: 0;
+  padding: 0;
+  outline: none;
+  /* The terminal's own caret: a filled cell, not a hairline. It is the last
+     thing in the theme still drawn the way the web draws it, and it is the one
+     the eye is always on. `caret-animation: manual` hands the blink to the
+     author and we then decline to animate it, so the block sits steady — a
+     blinking block is a strobe at this size, where a blinking hairline was
+     merely a caret. Both are ignored where unsupported, which is exactly the
+     right failure: a thin blinking caret is a plain caret, not a broken one. */
+  caret-shape: block;
+  caret-animation: manual;
+  background: linear-gradient(var(--term-faint), var(--term-faint)) bottom left / 100% 1px no-repeat;
+}
+[data-terminal] .term-input:focus {
+  background-image: linear-gradient(var(--term-blue), var(--term-blue));
+}
+[data-terminal] .term-input::placeholder {
+  color: var(--term-faint);
+}
+
+/* ── Sticky prompt ───────────────────────────────────────────────────────────
+ *
+ * The pinned prompt is the prompt's **first line**, and the pin is the
+ * browser's, not script's. `TranscriptRows` renders each prompt inside a lane
+ * spanning its turn; a one-line `sticky` **head** — the same row rendered
+ * again, clipped by height — leads the lane with its flow footprint cancelled
+ * (the negative bottom margin), so in flow it lies exactly over the real
+ * row's first line and is invisible. The compositor pins it (no per-scroll
+ * JS, no frame lag) and the lane's bottom edge pushes it off when the next
+ * prompt arrives. One line and not the row, because a pasted twenty-line
+ * prompt pinned whole covers the very answer being read.
+ *
+ * The head's visible line docks flush to the top edge of the scroller. Its
+ * inter-row gap is padding on the head (matching the row it overlays), so a
+ * gap-carrying head is one line taller and pins one line negative: the
+ * padding parks above the viewport edge and the line starts at zero — which
+ * is also what makes the pin engage exactly when the line itself reaches the
+ * top, not a line early.
+ *
+ * The lane spans the whole turn and the head is an overlay, so both are
+ * transparent to the pointer — the real row beneath owns interaction, and
+ * the head is `aria-hidden` in the markup. The z-index is on the lane —
+ * every row wrapper is its own stacking context (they are transformed), so
+ * the head's own z-index could never beat a later sibling.
+ *
+ * `--bg` is the panel's own ground, the same token the hover-revealed row
+ * actions cover themselves with — the user band is translucent by design, so
+ * without a ground the rows passing beneath would show straight through the
+ * pinned head. Opaque always, which is invisible in flow: the ground behind
+ * it is the same `--bg`, and the row it covers is its own content.
+ */
+[data-terminal] [data-slot='transcript-rows'] > [data-sticky-lane] {
+  z-index: 3;
+  pointer-events: none;
+}
+
+/* The head's own strip: the full lane, out of flow, so the head needs no
+   footprint-cancelling margin — sticky confinement clamps the margin box, and
+   a negative margin shrinks it to nothing, letting the head overshoot the
+   lane's end by its own height (two pinned prompts on screen at once). */
+[data-terminal] [data-sticky-lane] > [data-sticky-headlane] {
+  position: absolute;
+  inset: 0;
+  pointer-events: none;
+}
+
+/* Hidden until actually stuck (`data-stuck`, set by the lane's sentinel
+   observer): an overlay visible in flow sits on the real row's first line and
+   swallows its selection highlight — the line reads as unselectable. */
+[data-terminal] [data-sticky-headlane] > [data-sticky-head] {
+  position: sticky;
+  top: 0;
+  height: var(--term-line);
+  overflow: hidden;
+  background: var(--bg, transparent);
+  user-select: none;
+  visibility: hidden;
+}
+
+[data-terminal] [data-sticky-headlane] > [data-sticky-head][data-stuck] {
+  visibility: visible;
+}
+
+[data-terminal] [data-sticky-headlane] > [data-sticky-head].term-row-gap {
+  top: calc(-1 * var(--term-line));
+  height: calc(2 * var(--term-line));
+}
+
+/* ── Composer ────────────────────────────────────────────────────────────────
+ *
+ * The foot of the panel, and a *row* like every other: `>` in the gutter cell,
+ * the caret on the body column. That is the whole design — a typed line and a
+ * rendered one start on the same character, which no chat composer does and
+ * every terminal does for free.
+ *
+ * Docked rather than floating: no radius, no shadow, and a rule along the top
+ * *and* the bottom, both turning accent while anything inside has focus. Those
+ * two rules are the CLI's own frame for its prompt, and they are the only
+ * affordance — which is what the transcript above (no boxes anywhere) asks for.
+ * They also do the work a box would: the field reads as its own strip of the
+ * panel rather than as the last row of the transcript, without a border on the
+ * sides that would take the `❯` off the column the rows start on.
+ *
+ * The bottom rule is why the status bar under it draws none of its own — see
+ * `StatusBar.tsx`. Two adjacent 1px rules is a 2px rule with a seam in it.
+ */
+[data-terminal].term-composer {
+  border-top: 1px solid var(--term-faint);
+  border-bottom: 1px solid var(--term-faint);
+  transition: border-color 120ms;
+}
+/* The bar spans the panel; its contents sit in the transcript's own column, so
+   the `>` lands on the column the rows above it start on. Two elements because
+   those are two different widths — a rule that stopped at the content column
+   would read as a card, which is the one thing this theme has none of. */
+[data-terminal] .term-composer-body {
+  margin-inline: auto;
+  width: 100%;
+  max-width: var(--wd-content-max-w, 48rem);
+  padding-inline: var(--term-bleed, 0px);
+  /* Air on each side of the prompt, and a plain pixel value rather than a
+     fraction of `--term-line`: this is chrome between two rules, not a
+     transcript row, and the whole-multiple rule governs rows — a computed
+     half-line would be exactly the fractional metric that rule exists to
+     forbid. */
+  padding-block: 8px;
+}
+[data-terminal].term-composer:focus-within,
+[data-terminal].term-composer[data-dragging] {
+  border-color: var(--term-blue);
+}
+
+/* The contentEditable field. `font: inherit` is what makes it the cell — the
+   surface above already carries the size and the line height, and anything that
+   restates them here can disagree with the rows. */
+[data-terminal] .term-composer-field {
+  font: inherit;
+  color: var(--term-fg);
+  outline: none;
+  /* The steady block caret, same as the prompt fields. See `.term-input`. */
+  caret-shape: block;
+  caret-animation: manual;
+}
+
+/* Staged attachments, above the prompt.
+ *
+ * The card form wraps each thumbnail in a rounded box and hangs a round `✕`
+ * badge outside its top-right corner, over a strip with its own bottom rule.
+ * None of that survives here: this theme has no rounded corners and no badges
+ * floating off an edge, and the strip sits *inside* the composer's frame, which
+ * already draws the only rule there is — a second one directly above the field
+ * reads as the box this theme exists not to have.
+ *
+ * So the thumbnail is a plain 1px cell, and the remove control is tucked into
+ * its top-right corner with two rules of its own, which is how a terminal draws
+ * a control inside a frame rather than on top of one. `1px` rather than `0`
+ * puts it just inside the thumbnail's border instead of straddling it.
+ *
+ * The strip's only spacing is the 8px the composer already uses above and below
+ * its prompt — a plain pixel value, and deliberately, for the reason given
+ * there: this is chrome between rules, not a transcript row, so the
+ * whole-multiple-of-`--term-line` rule does not govern it. No side padding: the
+ * strip is already inside the body column, so padding here would step it in
+ * from the column every row above it starts on. */
+[data-terminal] .term-attachments {
+  padding: 0 0 8px 0;
+}
+[data-terminal] .term-attachment {
+  border: 1px solid var(--term-faint);
+}
+/* A refused upload, in the terminal's own red. This needs to be said here
+   rather than left to the card form's `border-danger/50`: the rule above sets
+   the `border` shorthand, colour included, and outranks a utility class — so
+   without this the one state that must stand out is the one that looks
+   ordinary. */
+[data-terminal] .term-attachment[data-failed] {
+  border-color: var(--term-red);
+}
+[data-terminal] .term-attachment-remove {
+  top: 1px;
+  right: 1px;
+  border-left: 1px solid var(--term-faint);
+  border-bottom: 1px solid var(--term-faint);
+}
+
+/* A composer action as a character: one cell wide, one line tall, so pressing
+   it costs no width and removing it would move nothing. Dim until you reach for
+   it — the same restraint the row actions show. */
+[data-terminal] .term-glyph {
+  flex: none;
+  width: var(--term-cell);
+  height: var(--term-line);
+  font: inherit;
+  line-height: var(--term-line);
+  text-align: center;
+  background: none;
+  border: 0;
+  padding: 0;
+  outline: none;
+  user-select: none;
+  cursor: pointer;
+}
+/* A glyph standing in the **gutter cell** is a marker, so it aligns like one.
+   The cell is 2ch and a character is 1ch, so `text-align: center` — right for a
+   standalone control at the row's trailing edge — lands the glyph half a cell
+   (≈3.9px at 13px/JetBrains Mono) to the right of the column every `❯` and `●`
+   in the transcript starts on. `start` is what `.term-gutter` uses, and on this
+   grid "nearly the same column" is just the wrong column. */
+[data-terminal] .term-glyph[data-gutter] {
+  text-align: start;
+}
+
+/* `:not([data-tone])` because the tone rules and this one have the same
+   specificity and this one is further down the file: without it, a toned glyph
+   (the lit `↵`) would silently lose its colour to the default. */
+[data-terminal] .term-glyph:not([data-tone]) {
+  color: var(--term-dim);
+}
+[data-terminal] .term-glyph:hover:not(:disabled),
+[data-terminal] .term-glyph:focus-visible:not(:disabled) {
+  color: var(--term-bright);
+}
+[data-terminal] .term-glyph:disabled {
+  opacity: 0.4;
+  cursor: default;
+}
+
+/* ── Diff ────────────────────────────────────────────────────────────────────
+ *
+ * An added or removed line is a **band**, not coloured text: the wash runs the
+ * full width of the screen, the way it does in a terminal, so the shape of a
+ * change is readable from the scrollbar without reading a word of it. The line
+ * numbers ride inside the wash — they are part of the changed line.
+ */
+/* A diff belongs to the call above it, so it steps in one cell like any other
+   tool output. */
+[data-terminal] .term-diff {
+  padding-left: var(--term-cell);
+}
+
+/* The wash bleeds **right** only. Left it stops at the diff's own edge, because
+   that edge is the line-number column and a band running past it would swallow
+   the indent that says which tool call this diff belongs to. Right there is
+   nothing to preserve, and stopping at the longest line would make the shape of
+   the change depend on its text. */
+[data-terminal] .term-diff .term-row[data-diff='add'],
+[data-terminal] .term-diff .term-row[data-diff='remove'] {
+  margin-right: calc(-1 * var(--term-bleed, 0px));
+  padding-right: var(--term-bleed, 0px);
+}
+[data-terminal] .term-diff .term-row[data-diff='add'] {
+  background: var(--term-add-bg);
+  color: var(--term-add-fg);
+}
+[data-terminal] .term-diff .term-row[data-diff='remove'] {
+  background: var(--term-del-bg);
+  color: var(--term-del-fg);
+}
+[data-terminal] .term-diff .term-row[data-diff='context'] {
+  color: var(--term-diff-fg);
+}
+/* The number column is dimmer than the line it belongs to in every case — it is
+   an address, not content. `.term-gutter`'s own colour would flatten all three
+   to one grey, so each state dims its own. */
+[data-terminal] .term-diff .term-row > .term-gutter {
+  color: var(--term-diff-num);
+}
+[data-terminal] .term-diff .term-row[data-diff='add'] > .term-gutter {
+  color: color-mix(in srgb, var(--term-add-fg) 65%, transparent);
+}
+[data-terminal] .term-diff .term-row[data-diff='remove'] > .term-gutter {
+  color: color-mix(in srgb, var(--term-del-fg) 65%, transparent);
+}
+
+/* ── Markdown ────────────────────────────────────────────────────────────────
+ *
+ * The element map is in `components/terminal/markdown.tsx`; this is the little
+ * CSS it needs. Nothing here is an override — the renderer is told what to emit,
+ * so there is no default to undo and no `!important` anywhere in the theme.
+ */
+
+/* react-markdown emits the source's newlines as text nodes between blocks. The
+   surrounding rows are `pre-wrap` (a plain line of output must keep its own
+   spacing), which would render every one of those as a visible blank line — so
+   markdown bodies opt back out, and only a fenced block opts back in. */
+.term-md {
+  white-space: normal;
+}
+
+/* And it has to reach `.term-body` explicitly, because a list item *is* a Row
+   and Rows carry `pre-wrap` (a plain line of tool output must keep its own
+   spacing). Inherited, that turns every newline react-markdown emits between an
+   item's block children into a visible empty line — a nested list drew k+2
+   phantom blanks, so a two-line nested item was 72px of 18px rows. Models nest
+   lists constantly, and the grid audit cannot see it: the phantoms are whole
+   lines, so every row still lands on the grid. Fenced code opts back in for
+   itself (`.term-pre`), which is the only markdown that wants its own
+   whitespace. */
+.term-md .term-body {
+  white-space: normal;
+}
+
+/* The one vertical rule: consecutive blocks are one blank line apart. A margin
+   rather than an inserted row, because this row list belongs to the markdown
+   renderer — but it is exactly one line, so the grid holds. */
+.term-md .term-block + .term-block {
+  margin-top: var(--term-line);
+}
+
+.term-md .term-list {
+  list-style: none;
+  margin: 0;
+  padding: 0;
+}
+.term-md .term-list-ordered {
+  counter-reset: term-ol;
+}
+/* Markers live in the row's gutter cell, so they cost columns rather than a
+   typographic indent: `- ` is two, `1. ` is three. */
+.term-md .term-li > .term-gutter::before {
+  content: '-';
+}
+.term-md .term-list-ordered > .term-li {
+  --term-cell: 3ch;
+  counter-increment: term-ol;
+}
+.term-md .term-list-ordered > .term-li > .term-gutter::before {
+  content: counter(term-ol) '.';
+}
+
+/* A quote's rule is a background, not a border: a 1px border would push the
+   text 1px off the column it shares with every other line. */
+.term-md .term-quote {
+  padding-left: var(--term-cell);
+  background: linear-gradient(var(--term-faint), var(--term-faint)) left / 1px 100% no-repeat;
+}
+
+/* A horizontal rule is one line tall with the rule through its middle — the row
+   it occupies is a whole line either way. */
+.term-md .term-rule {
+  height: var(--term-line);
+  background: linear-gradient(var(--term-faint), var(--term-faint)) left center / 100% 1px no-repeat;
+}
+
+.term-md .term-pre {
+  margin: 0;
+  font: inherit;
+  white-space: pre-wrap;
+  overflow-wrap: break-word;
+  color: var(--term-dim);
+}
+
+.term-md .term-inline-code {
+  font: inherit;
+  background: none;
+  padding: 0;
+}
+
+.term-md .term-em {
+  font-style: italic;
+}
+
+.term-md .term-table-wrap {
+  overflow-x: auto;
+}
+.term-md .term-table {
+  border-collapse: collapse;
+  /* `max-content` and **no** `max-width`. A cap of `100%` looks like the
+     defensive choice and is the opposite: it clamps a wide table below its
+     natural width, so the cells wrap and a 14-row table becomes 19 lines tall —
+     which breaks the theme's premise (a row is a line) and with it the height
+     calculator, whose table model counts rows. It also silently disables the
+     wrapper's own `overflow-x`, since a table that shrinks never overflows.
+     Letting it reach `max-content` puts every row back on one line and hands the
+     scrolling to `.term-table-wrap`, which exists for exactly that. */
+  width: max-content;
+}
+.term-md .term-table :is(th, td) {
+  /* Columns are cells, rows are lines. No vertical padding, ever. */
+  padding: 0 var(--term-cell) 0 0;
+  text-align: left;
+  vertical-align: top;
+}
+.term-md .term-thead {
+  /* The header rule, again as a shadow so it costs no layout. */
+  box-shadow: inset 0 -1px var(--term-diff-num);
+}
+
+/* ── Scrubber ────────────────────────────────────────────────────────────────
+ *
+ * The overview ruler (`components/terminal/scrubber.tsx`): a 12px rail of marks
+ * over the scroller's right edge — VS Code's strip beside the minimap, with
+ * this transcript's semantics. It is *chrome*, not rows: absolutely positioned
+ * over the scroll container so the transcript's grid is untouched, and drawn
+ * entirely from --term-* tokens so it follows the theme wherever the panel is
+ * embedded. Its width is the one deliberate exception to the theme's `ch` rule
+ * — see the note on `.term-scrubber` below.
+ *
+ * Interactivity is an affordance. Without `data-interactive` the rail is
+ * passive paint with pointer events off — and the native scrollbar, which
+ * stays in that mode, keeps working straight through it.
+ */
+[data-terminal].term-scrubber {
+  position: absolute;
+  top: 0;
+  right: 0;
+  bottom: 0;
+  /* Exactly 12px, and this is the one place the theme's `ch` rule is set aside
+     on purpose: the rail is chrome beside the grid rather than part of it, and
+     its width is a *hit target* (two 6px lanes) rather than a column of text.
+     A `ch` measure drifts with the font, which would make the lanes different
+     again in the VS Code dock. */
+  width: 12px;
+  z-index: 10;
+  pointer-events: none;
+}
+[data-terminal].term-scrubber[data-interactive] {
+  pointer-events: auto;
+}
+.term-scrubber .term-scrubber-body {
+  position: absolute;
+  inset: 0;
+  touch-action: none;
+}
+
+/* The viewport band — where you are: a faint wash with a hairline frame,
+   floated over the marks (z-index) so the framed region reads as a window
+   onto the rail rather than a stripe behind it. `--term-faint` at 25% rather
+   than a literal, so the light palette re-tints it. */
+.term-scrubber .term-scrub-band {
+  position: absolute;
+  left: 0;
+  right: 0;
+  background: color-mix(in srgb, var(--term-faint) 25%, transparent);
+  box-shadow: 0 0 0 1px var(--term-faint) inset;
+  pointer-events: none;
+  z-index: 1;
+}
+
+/* There is no separate cursor line. The band above answers "where am I" on its
+   own — it is outlined, so its top edge already reads as an edge — and a 2px
+   blue rule laid over it was a second indicator of the same fact, in the
+   loudest colour the rail has. */
+
+.term-scrubber .term-scrub-mark {
+  position: absolute;
+  min-height: 2px;
+}
+.term-scrubber[data-interactive] .term-scrub-mark {
+  cursor: pointer;
+}
+.term-scrubber[data-interactive] .term-scrub-mark:hover {
+  outline: 1px solid color-mix(in srgb, var(--term-bright) 40%, transparent);
+}
+
+/* Two lanes of 8px — what you asked, and what came back — and 'f', the
+   full-width lane for annotations *about* the run (an error, an approval, a
+   bookmark, the catch-up seam) rather than steps through it. Pixels, not
+   percentages: the whole point of the 16px rail is that a lane is a reliable
+   8px target, and a percentage would reintroduce the drift the fixed width was
+   chosen to remove. */
+.term-scrubber .term-scrub-mark[data-lane='l'] { left: 0; width: 6px; }
+.term-scrubber .term-scrub-mark[data-lane='r'] { left: 6px; width: 6px; }
+.term-scrubber .term-scrub-mark[data-lane='f'] { left: 0; width: 12px; }
+
+/* Lane marks are two-tone: the first 2px — the mark's own anchor — at full
+   strength, the rest of the row's extent a 25% tail, so a long answer reads
+   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. */
+.term-scrubber .term-scrub-mark[data-kind='user'] {
+  background: linear-gradient(
+    to bottom,
+    var(--term-blue) 0 2px,
+    color-mix(in srgb, var(--term-blue) 25%, transparent) 2px
+  );
+}
+.term-scrubber .term-scrub-mark[data-kind='turn'] {
+  background: linear-gradient(
+    to bottom,
+    var(--term-fg) 0 2px,
+    color-mix(in srgb, var(--term-fg) 25%, transparent) 2px
+  );
+}
+.term-scrubber .term-scrub-mark[data-kind='turnFailed'] {
+  background: linear-gradient(
+    to bottom,
+    var(--term-red) 0 2px,
+    color-mix(in srgb, var(--term-red) 25%, transparent) 2px
+  );
+}
+.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
+   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
+   the two errors that actually ended something stop standing out. Dimmer reads
+   as the same class of thing, one rank quieter — which is exactly its rank in
+   LOUDNESS. */
+.term-scrubber .term-scrub-mark[data-kind='toolFailed'] {
+  background: color-mix(in srgb, var(--term-red) 55%, transparent);
+}
+.term-scrubber .term-scrub-mark[data-kind='bookmark'] { background: var(--term-magenta); }
+.term-scrubber .term-scrub-mark[data-kind='approval'] {
+  background: var(--term-yellow);
+  animation: term-scrub-pulse 1.2s infinite;
+}
+/* The catch-up boundary: a dashed hairline centered in its 3px hit box. */
+.term-scrubber .term-scrub-mark[data-kind='recap'] {
+  background: repeating-linear-gradient(to right, var(--term-faint) 0 3px, transparent 3px 6px)
+    left center / 100% 1px no-repeat;
+}
+@keyframes term-scrub-pulse {
+  50% { opacity: 0.3; }
+}
+@media (prefers-reduced-motion: reduce) {
+  .term-scrubber .term-scrub-mark[data-kind='approval'] {
+    animation: none;
+  }
+}
+
+/* The peek. Rendered from transcript state — the row it describes is usually
+   unmounted — and framed the theme's way: strokes as backgrounds, no border.
+   pointer-events: none, so it can never trap the pointer that revealed it. */
+.term-scrubber .term-scrub-peek {
+  position: absolute;
+  right: calc(100% + 1ch);
+  width: 44ch;
+  max-width: 60vw;
+  padding: var(--term-line) 2ch;
+  background:
+    linear-gradient(var(--term-faint), var(--term-faint)) top left / 100% 1px no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) bottom left / 100% 1px no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) top left / 1px 100% no-repeat,
+    linear-gradient(var(--term-faint), var(--term-faint)) top right / 1px 100% no-repeat,
+    var(--bg-elevated, #1f1f1f);
+  pointer-events: none;
+  z-index: 11;
+}
+.term-scrubber .term-scrub-ex {
+  display: -webkit-box;
+  -webkit-line-clamp: 4;
+  -webkit-box-orient: vertical;
+  overflow: hidden;
+}
+
+/* While an interactive scrubber is mounted it IS the scrollbar; the transcript
+   stamps this attribute on the scroll element. A passive rail leaves the
+   native scrollbar alone — pointer-events: none above is what keeps that
+   scrollbar reachable through the paint. */
+[data-term-scrubber-host] {
+  scrollbar-width: none;
+}
+[data-term-scrubber-host]::-webkit-scrollbar {
+  display: none;
+}