@djangocfg/widget-chat 0.1.1

package/src/store/use-voice.ts

@@ -0,0 +1,116 @@
+import { useEffect, useMemo, useRef, useState } from "react";
+
+import {
+  VoiceSession,
+  createWebSpeechCapability,
+  type PlayEarcon,
+  type VoiceCapability,
+  type VoiceSnapshot,
+} from "../core";
+
+/**
+ * React binding for `VoiceSession`.
+ *
+ * Deliberately thin, exactly like `useMentions`. Everything with a race in it —
+ * a result arriving after stop, an engine that ends on its own, the interim that
+ * must replace rather than append — lives in `core/voice`, tested without a DOM.
+ * This file only subscribes.
+ */
+
+export interface UseVoiceResult extends VoiceSnapshot {
+  /** Whether a microphone exists at all. `false` ⇒ render no control. */
+  readonly available: boolean;
+  readonly start: () => void;
+  readonly stop: () => void;
+  readonly cancel: () => void;
+  /** Take the dictated text and reset, for handing to the draft. */
+  readonly take: () => string;
+}
+
+const IDLE: VoiceSnapshot = {
+  recording: false,
+  committed: "",
+  interim: "",
+  text: "",
+};
+
+export function useVoice(
+  capability?: VoiceCapability | false,
+  language = "en-US",
+  playEarcon?: PlayEarcon,
+): UseVoiceResult {
+  const [snapshot, setSnapshot] = useState(IDLE);
+
+  // Read through a ref for the same reason the capability is: a host passes an
+  // inline arrow at every realistic call site, so keying the session on it would
+  // rebuild the session mid-sentence and drop the words.
+  const currentEarcon = useRef(playEarcon);
+  currentEarcon.current = playEarcon;
+
+  // The language, readable at START without being a dependency. The default
+  // engine reads it through this function, so changing the language applies to
+  // the NEXT dictation instead of rebuilding the session mid-sentence.
+  const currentLanguage = useRef(language);
+  currentLanguage.current = language;
+
+  // The package's own engine, built at most once. `undefined` on a browser with
+  // no Web Speech, which is what makes "no engine ⇒ no button" hold.
+  const fallback = useMemo(
+    () => createWebSpeechCapability({ language: () => currentLanguage.current }),
+    [],
+  );
+
+  // Absent capability falls back to the browser rather than to nothing — the
+  // one capability where absent does not mean absent. A host that supplies one
+  // overrides the default outright, and `false` refuses the fallback too, which
+  // is the only way to say "no dictation" when absence already means "default".
+  const effective = capability === false ? undefined : (capability ?? fallback);
+
+  // Same reason as `useMentions`: the capability is an object literal at every
+  // realistic call site, so it is a new reference on every parent render.
+  // Keying the session on it would rebuild it mid-sentence and drop the words.
+  const latest = useRef(effective);
+  latest.current = effective;
+
+  const session = useMemo(() => {
+    if (effective === undefined) return null;
+    return new VoiceSession({
+      // Read through the ref so a re-created capability object still routes to
+      // the host's CURRENT engine without rebuilding the session.
+      capability: {
+        start: (onText, signal) => latest.current!.start(onText, signal),
+        stop: () => latest.current!.stop(),
+      },
+      onChange: setSnapshot,
+      // Through the ref, so a host that rebuilds the callback each render still
+      // reaches its CURRENT player without the session being rebuilt.
+      playEarcon: (kind) => currentEarcon.current?.(kind),
+    });
+    // Presence alone rebuilds it. A `VoiceCapability` has no behavioural
+    // primitives to key on — both members are functions, and functions are read
+    // through the ref — so this is the whole dependency. Keyed on the EFFECTIVE
+    // engine: a host capability arriving late must replace the default, and
+    // keying on `capability` alone would leave the browser engine in place.
+  }, [effective === undefined]);
+
+  useEffect(() => () => session?.dispose(), [session]);
+
+  // The ACTIONS memo on `session` alone, never on `snapshot` — the same defect
+  // `use-mentions.ts` guards against. A caller may put `stop` in an effect's
+  // dependency array (stopping dictation when a turn is sent is exactly that
+  // shape); rebuilt on every snapshot, that effect would fire on each interim
+  // result and re-run forever. Nothing about an action depends on the snapshot:
+  // recording does not change what `cancel` does.
+  const actions = useMemo(
+    () => ({
+      available: session !== null,
+      start: () => session?.start(),
+      stop: () => session?.stop(),
+      cancel: () => session?.cancel(),
+      take: () => session?.take() ?? "",
+    }),
+    [session],
+  );
+
+  return useMemo(() => ({ ...snapshot, ...actions }), [snapshot, actions]);
+}

package/src/styles/block.css

@@ -0,0 +1,128 @@
+/**
+ * The rhythm between the block-level parts of one turn.
+ *
+ * A message stacks its parts at a flat 8px, which is right between two
+ * paragraphs and too tight around a BOX: a tool call, an enrichment card, a
+ * picture. At the same gap as prose those boxes touch each other and the
+ * sentence that introduced them, and several in a row read as one striped
+ * slab rather than as separate things.
+ *
+ * Here rather than in a class list because the condition is structural: the
+ * spacing depends on what the PREVIOUS sibling is, which no class on the
+ * element itself can express. The transcript's `gap` cannot express it either —
+ * a gap is uniform by definition, and these parts are not.
+ *
+ * `.chat-tool` and `.chat-block` share every rule. They stay two selectors
+ * because they are two markup contracts (a tool call is rendered by `tool.tsx`,
+ * a card and a picture by `data.tsx` and `media.tsx`), and collapsing them into
+ * one class would mean one renderer silently deciding the other's shape.
+ */
+
+/* A box sits closer to the sentence that introduced it than to the next one, so
+ * it belongs to the text above rather than floating between the two. */
+.chat-tool,
+.chat-block {
+  margin-block-start: 0.875rem;
+}
+
+/* Between two boxes, less: they are peers in one sequence, and at the larger
+ * gap a run of them stops reading as a list. Four bordered boxes at the flat
+ * 4px read as one striped block, which is the shape this pair of rules exists
+ * to prevent — it is spacing WITHIN a message, never the transcript's gap
+ * between messages. */
+.chat-tool + .chat-tool,
+.chat-block + .chat-block,
+.chat-tool + .chat-block,
+.chat-block + .chat-tool {
+  margin-block-start: 0.5rem;
+}
+
+/* The first part of a turn has no neighbour to separate from, and the margin
+ * would push it away from the turn's own top edge. `:first-child` alone is not
+ * enough: a reply commonly opens with a picture the assistant produced, which
+ * is the first RENDERED part while the transcript still gives the row its own
+ * spacing. */
+.chat-tool:first-child,
+.chat-block:first-child {
+  margin-block-start: 0;
+}
+
+/**
+ * A disclosure's own marker, replaced by an icon.
+ *
+ * The native `disclosure-closed` marker renders as a `▶` whose size and colour
+ * the page cannot set — it tracks the platform, not the transcript's type
+ * scale, and stands out against every other chevron in the app. Removing it
+ * needs BOTH rules: `display: list-item` is what draws it, and Safari keeps
+ * drawing it until `::-webkit-details-marker` is hidden too.
+ */
+.chat-disclosure > summary {
+  display: flex;
+  list-style: none;
+}
+
+.chat-disclosure > summary::-webkit-details-marker {
+  display: none;
+}
+
+/* Rotated by the element's own state, so nothing has to mirror `open` in JS.
+ *
+ * The class goes on a SPAN wrapping the icon, never on the `<svg>`: a computed
+ * transform does not take on that node here, so rotating it silently does
+ * nothing while every rule involved still matches. */
+.chat-disclosure-chevron {
+  display: inline-flex;
+  flex-shrink: 0;
+  transition: transform 150ms ease;
+}
+
+.chat-disclosure[open] > summary .chat-disclosure-chevron {
+  transform: rotate(90deg);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  .chat-disclosure-chevron {
+    transition: none;
+  }
+}
+
+/**
+ * An OPEN disclosure is a box; a closed one is a line.
+ *
+ * Only `[open]` carries the frame, and that asymmetry is the decision: closed,
+ * the summary is one muted line among the turn's other chrome, and framing it
+ * would draw a border around every collapsed reply. Open, its body is prose of
+ * the same colour and size as the answer below, so without an edge the reader
+ * cannot tell where the thinking stops and the reply starts.
+ *
+ * `--border` and `--radius`, not literals: the same pair every other box in the
+ * app uses, so this tracks the theme instead of pinning one palette.
+ *
+ * The inline padding is mirrored by a negative margin, so the frame grows
+ * OUTWARD from the text. Padding alone would indent the summary relative to the
+ * lines above it and the reply below, which is the one thing a frame here must
+ * not do — those three all start at the same left edge.
+ */
+.chat-disclosure[open] {
+  border: 1px solid var(--border);
+  border-radius: var(--radius, 0.625rem);
+  padding: 0.5rem 0.625rem;
+  margin-inline: -0.625rem;
+  /* The same edge colour as the composer and every card in the app, not a
+   * louder one: this frames the model's thinking, which must stay quieter than
+   * the answer it sits above. */
+}
+
+/* The frame's bottom edge would otherwise touch the reply, putting a border
+ * against the first line of the answer. Only when open, because a closed
+ * summary is a plain line the turn already spaces. */
+.chat-disclosure[open] {
+  margin-block-end: 0.75rem;
+}
+
+/* Inside the box the summary is a heading over its body, so it needs the gap
+ * the unframed version got from the surrounding flow. `> summary + *` rather
+ * than a class on the body: the body is whatever the renderer put there. */
+.chat-disclosure[open] > summary + * {
+  margin-block-start: 0.375rem;
+}

package/src/styles/composer.css

@@ -0,0 +1,449 @@
+/**
+ * The composer's structural rules.
+ *
+ * Here rather than as Tailwind variants because each needs a selector a class
+ * list cannot express: `:has()` looking DOWN at a descendant and acting on a
+ * different child, and "every button except one" on the queued row. Written as
+ * variants these become strings no reviewer can read a mistake out of.
+ */
+
+/**
+ * A composer whose draft has outgrown one line gives the field the whole row,
+ * and the controls take their own line beneath it.
+ *
+ * A STAGED TOOL does the same, unconditionally: a chip sits between `+` and the
+ * text, so the field starts mid-row and the little that is left is squeezed
+ * against the send button. Two independent reasons to expand, one layout — the
+ * text no longer fits BESIDE things, whether because of its own length or
+ * because of what shares its line.
+ *
+ * `:has()` is load-bearing twice over. The condition lives on a DESCENDANT —
+ * the textarea reports its own rendered height as `data-multiline`, which is
+ * the only element that can know it — and the effect lands on a DIFFERENT
+ * child, the field's wrapper. Descendant-to-sibling is the one direction a
+ * selector can look, and this is why the rule cannot be a Tailwind variant.
+ *
+ * `flex-basis`, never `width`: the wrapper is a flex item, so the basis is what
+ * the algorithm distributes from and a `width` is ignored outright. Measured —
+ * with `width: 100%` the rule matched, loaded, and changed nothing.
+ */
+.composer-box:has(textarea[data-multiline]) > *:has(> textarea),
+.composer-box:has(.tool-chips > *) > *:has(> textarea) {
+  flex-basis: 100%;
+}
+
+/**
+ * A wrapped draft sends the `+` DOWN with the trailing controls, not up.
+ *
+ * Ordering alone cannot do it: `+` leads the shared line, so it also leads the
+ * wrap and lands on a line of its own ABOVE the text — measured as three rows,
+ * `+` over the draft and the other controls under it. Raising its order past
+ * the field's only while the field owns the row puts both halves on the line
+ * beneath, `+` still at their left edge.
+ */
+.composer-box:has(textarea[data-multiline]) > .composer-lead,
+.composer-box:has(.tool-chips > *) > .composer-lead {
+  order: 3;
+}
+
+/* The `+` sits `inset-y` from the left edge, matching the send button's gap to
+ * the right and the bottom. The box's horizontal inset is breathing room for
+ * the TEXT and is wider, so the difference is given back here — the same
+ * correction `.composer-controls` makes at the other end. */
+.composer-lead {
+  margin-inline-start: calc(var(--chat-composer-inset-y) - var(--chat-composer-inset-x));
+}
+
+/**
+ * The control row reaches past the box's TEXT inset, at both ends.
+ *
+ * On the row rather than on the box: the field above it must still start flush
+ * with the text, and a box-level inset would move both.
+ */
+.composer-controls {
+  /* The row's own gap to the edge must EQUAL the vertical one, and the box's
+   * horizontal inset is wider — that width is breathing room for the TEXT, not
+   * for a control. Given back at BOTH ends, so the leading `+` and the trailing
+   * send button each sit the same distance from their side as from the bottom.
+   *
+   * `width: auto` is what makes the negative margin WIDEN the row. The class
+   * list's `w-full` pins it to 100% of the content box, so the margin only slid
+   * it left and the send button kept the full text inset on the right — a gap
+   * measured at 21px against the intended 9px. */
+  width: auto;
+  margin-inline: calc(var(--chat-composer-inset-y) - var(--chat-composer-inset-x));
+}
+
+/**
+ * A staged tool: a capsule, matching the controls it sits between.
+ *
+ * `--radius-full`, not a rounded rectangle. The `+` to its left is a circle and
+ * the send button to its right is a capsule, so a 4px corner reads as a control
+ * from a different set. No border for the same reason — neither neighbour has
+ * one, and an outline around a soft ground draws a box the row does not need.
+ */
+.tool-chip {
+  border-radius: var(--radius-full, 9999px);
+  padding-inline: 0.5rem;
+  font-size: 0.75rem;
+  background: color-mix(in oklab, var(--muted) 70%, transparent);
+  color: var(--muted-foreground);
+  transition: background 120ms ease, color 120ms ease;
+}
+
+.tool-chip:hover {
+  background: var(--muted);
+  color: var(--foreground);
+}
+
+/**
+ * The remove control appears on approach, and holds its column regardless.
+ *
+ * `opacity`, never `display`: removing it from layout would resize the chip
+ * under the pointer, moving the target the user is reaching for. Revealed on
+ * `focus-within` too, or it is unreachable without a mouse.
+ */
+.tool-chip > button {
+  opacity: 0;
+  transition: opacity 120ms ease;
+}
+
+.tool-chip:hover > button,
+.tool-chip:focus-within > button {
+  opacity: 0.6;
+}
+
+.tool-chip > button:hover,
+.tool-chip > button:focus-visible {
+  opacity: 1;
+}
+
+/**
+ * The staged row scrolls without a visible scrollbar, fading at each edge.
+ *
+ * A MASK rather than a gradient overlay: a gradient must name a colour, so it
+ * needs one declaration per theme and breaks over any other ground. A mask
+ * removes the paint itself, which is correct on every background from one rule.
+ *
+ * Both edges are declared, but each only bites when there is something to
+ * scroll — `animation-timeline: scroll()` drives them from the row's own scroll
+ * position, so a row that fits shows no fade at all. Where that timeline is
+ * unsupported the row simply scrolls with no fade, which is the pre-existing
+ * behaviour and not a regression.
+ */
+/* Registered, or the keyframes below step between values instead of easing:
+   an unregistered custom property has no type, so it cannot interpolate. */
+@property --tool-chips-fade-start {
+  syntax: "<length>";
+  inherits: false;
+  initial-value: 0px;
+}
+
+@property --tool-chips-fade-end {
+  syntax: "<length>";
+  inherits: false;
+  initial-value: 0px;
+}
+
+.tool-chips {
+  scrollbar-width: none;
+  --tool-chips-fade-start: 0px;
+  --tool-chips-fade-end: 0px;
+  mask-image: linear-gradient(
+    to right,
+    transparent 0,
+    #000 var(--tool-chips-fade-start),
+    #000 calc(100% - var(--tool-chips-fade-end)),
+    transparent 100%
+  );
+  animation: tool-chips-fade linear both;
+  animation-timeline: scroll(self inline);
+}
+
+.tool-chips::-webkit-scrollbar {
+  display: none;
+}
+
+/**
+ * Start and end fades, driven by scroll position rather than by a listener.
+ *
+ * At the very start there is nothing hidden to the left, so only the right edge
+ * fades; at the end the reverse. The middle keyframe fades both, which is the
+ * only moment content is cut off on each side.
+ */
+@keyframes tool-chips-fade {
+  from {
+    --tool-chips-fade-start: 0px;
+    --tool-chips-fade-end: 1.5rem;
+  }
+  50% {
+    --tool-chips-fade-start: 1.5rem;
+    --tool-chips-fade-end: 1.5rem;
+  }
+  to {
+    --tool-chips-fade-start: 1.5rem;
+    --tool-chips-fade-end: 0px;
+  }
+}
+
+/**
+ * The field sets its own tracking, because what a host supplies is a CONTROL's.
+ *
+ * A design system's negative tracking is tuned for labels — a chip, a menu row,
+ * something taken in at a glance, where tightening buys density. This field is
+ * prose: it holds the same sentences the transcript renders, at the transcript's
+ * size, so it must match the transcript exactly. A composer and a transcript
+ * that disagree about tracking read as two different conversations, and the
+ * disagreement is most visible at the moment it matters — the line you typed
+ * sitting directly above the reply to it.
+ *
+ * `normal` is therefore not "no decision"; it is the same decision the reading
+ * surface makes, restated here because the host's `--letter-spacing-base` is
+ * declared once high up on a control-sized ancestor and would otherwise arrive
+ * as fixed pixels computed for a size this field does not use.
+ */
+.composer-box textarea {
+  letter-spacing: normal;
+}
+
+/**
+ * The ring OUTSIDE the border — two lines, one box.
+ *
+ * `box-shadow`, not a second border or an outline: a border would change the
+ * box and push every control 2px inward, and an outline cannot be given the
+ * card's radius on every engine. A spread-only shadow paints outside the edge
+ * and costs no layout, so the field keeps the geometry the buttons align to.
+ *
+ * The colour is the BORDER's until focus, so the ring reads as depth rather
+ * than as a permanent highlight; on focus both lines move to `--ring` together,
+ * because two rings in disagreeing colours read as an error state.
+ *
+ * The radius is DERIVED, never chosen. Two rounded shapes look parallel only
+ * when the outer radius equals the inner one plus the gap between them —
+ * otherwise the corners converge or splay while the straight edges stay even,
+ * which reads as sloppiness without naming its cause.
+ *
+ * The controls are circles (`rounded-full`), so their radius is half their
+ * height, and the gap the corner has to clear is the vertical inset. That sum
+ * comes out at exactly half the composer's own height — a capsule. Which is the
+ * point: a capsule is what concentric-with-a-circle MEANS, not a style choice,
+ * and it stays correct if the height changes for any reason.
+ *
+ * The single-line height is what this must follow, never the box's own height:
+ * a multi-line draft grows the box, and a capsule at that height would balloon
+ * into an oval while the buttons stayed the same circles.
+ */
+.composer-box {
+  /* Two axes, because they answer to different things. The vertical inset is
+   * structural — it plus the 32px control row IS the composer's height. The
+   * horizontal one is breathing room, free to be wider, and it alone decides
+   * the corner: a rounded rectangle turns along its SIDES, so the horizontal
+   * inset is the distance a corner arc has to clear. */
+  --chat-composer-inset-y: 0.5rem;
+  --chat-composer-inset-x: 0.875rem;
+  --chat-composer-control-h: calc(var(--chat-text, 1rem) * var(--chat-leading, 1.65) + 8px);
+  /* CONCENTRIC with the controls: their radius plus the inset that clears them.
+   * Derived rather than a second token, so a control radius change moves both
+   * arcs together and the corners cannot stop running parallel. */
+  border-radius: calc(var(--radius-control, 0.625rem) + var(--chat-composer-inset-y));
+  /* The horizontal inset is the TEXT's breathing room and is deliberately wider
+   * than the vertical one. The control row gives that difference back on both
+   * ends (`.composer-controls`), so a corner button keeps an equal gap to the
+   * bottom and the side while the field still starts clear of the edge. */
+  padding: var(--chat-composer-inset-y) var(--chat-composer-inset-x);
+  box-shadow: 0 0 0 2px color-mix(in oklab, var(--border) 55%, transparent);
+  transition: box-shadow 120ms ease;
+}
+
+.composer-box:focus-within {
+  box-shadow: 0 0 0 2px color-mix(in oklab, var(--ring) 40%, transparent);
+}
+
+
+/**
+ * A queued prompt: its text is the edit control, its icons appear on approach.
+ *
+ * Written as CSS rather than a class list because the row needs two structural
+ * selectors — "every button EXCEPT the text one" and a reveal driven by the
+ * row's own hover — and as Tailwind variants that becomes a string no reviewer
+ * can read a mistake out of.
+ *
+ * The text button carries no visible affordance on purpose. It fills the row,
+ * so a background or an underline would draw a second box inside a box the
+ * queue already frames; the pointer and the tooltip are the invitation.
+ */
+.queued-row {
+  display: flex;
+  gap: 0.25rem;
+  border-radius: var(--radius-lg, 0.5rem);
+  padding-block: 0.375rem;
+  padding-inline: 0.625rem 0.25rem;
+  font-size: 0.875rem;
+  line-height: 1.25rem;
+  background: color-mix(in oklab, var(--muted) 60%, transparent);
+  color: var(--muted-foreground);
+}
+
+/**
+ * The prompt text, which IS the edit control.
+ *
+ * Capped and scrollable rather than truncated: a queued prompt is a message the
+ * user has not seen sent, so hiding part of it is the failure the strip exists
+ * to prevent. The composer sits at the bottom of the transcript, so an
+ * uncapped one would grow upward into it.
+ */
+.queued-row > button[data-action="edit"] {
+  min-width: 0;
+  flex: 1;
+  cursor: text;
+  text-align: start;
+}
+
+.queued-row > button[data-action="edit"] span {
+  display: block;
+  max-height: 5rem;
+  overflow-y: auto;
+  white-space: pre-line;
+  overflow-wrap: break-word;
+}
+
+.queued-row > button:not([data-action="edit"]) {
+  display: grid;
+  place-items: center;
+  block-size: 1.5rem;
+  inline-size: 1.5rem;
+  flex-shrink: 0;
+  border-radius: var(--radius-control, 0.375rem);
+}
+
+.queued-row > button:not([data-action="edit"]):hover {
+  background: var(--muted);
+  color: var(--foreground);
+}
+
+/**
+ * Aligned to the FIRST line, not to the row.
+ *
+ * `center` would float the icons into the middle of a wrapped prompt, away from
+ * the line they read as belonging to; the prompt is capped and scrolls, so the
+ * row's height is not the text's. `flex-start` plus a small negative offset
+ * puts the 24px button's centre on the 20px first line, which is right whether
+ * the prompt takes one line or ten.
+ */
+.queued-row {
+  align-items: flex-start;
+}
+
+/**
+ * Revealed on hover AND on keyboard focus. Without `focus-within` the controls
+ * are unreachable without a mouse; `opacity` rather than `display` so the row
+ * does not reflow and shift the text under the pointer as they appear.
+ */
+.queued-row > button:not([data-action="edit"]) {
+  margin-block-start: -2px;
+  opacity: 0;
+  transition: opacity 120ms ease;
+}
+
+.queued-row:hover > button:not([data-action="edit"]),
+.queued-row:focus-within > button:not([data-action="edit"]) {
+  opacity: 1;
+}
+
+/**
+ * Dictation, while the microphone is open.
+ *
+ * The BUTTON is the indicator. A separate badge or a bar above the composer
+ * would be a second place to look for one fact, and the control the user just
+ * pressed is where they are already looking.
+ *
+ * The GLYPH tumbles, reusing `turn-mark-tumble` — the same motion the reasoning
+ * marker uses in the transcript, so one vocabulary covers both places this
+ * app says "still going". A pulse was tried first and is the wrong answer
+ * for the reason `turn-mark.css` already gives: every spinner on the web says
+ * "busy", while rotation has a direction, so a glance separates live from
+ * stalled.
+ *
+ * Only the icon turns, never the button: rotating the hit target would spin its
+ * focus ring and its hover plate with it.
+ */
+.composer-mic[data-recording] > svg {
+  animation: turn-mark-tumble 1.6s linear infinite;
+  /* The glyph's own box, so the rotation is about its centre rather than about
+   * a corner of the grid cell. */
+  transform-origin: 50% 50%;
+}
+
+/**
+ * Recording OUTRANKS hover, and gets an edge of its own.
+ *
+ * `ComposerButton`'s neutral tone carries `hover:text-foreground`, which ties
+ * with `aria-pressed:text-destructive` on specificity — so source order decides
+ * and the glyph turns white under the pointer. The pointer is over this button
+ * almost by definition: the user just clicked it to start.
+ *
+ * Here rather than in the button's own tone string, which is shared by four
+ * controls across three packages. Red is not a hover state; it says the
+ * microphone is open, and that fact does not depend on where the pointer is.
+ *
+ * The RING bounds the spinning glyph. Recording swaps the mic for a 14px filled
+ * square, and a small square turning in open space reads as a loose fragment
+ * rather than as a control — the ring is what it turns inside. Static, because
+ * the glyph already carries the motion and a second moving element would say
+ * the same thing twice.
+ *
+ * `inset` so it paints inside the button's own box: an outward ring would sit
+ * on the neighbouring controls at this spacing, and `box-shadow` keeps it out
+ * of layout either way, so the row does not shift when recording starts.
+ */
+.composer-mic[data-recording],
+.composer-mic[data-recording]:hover {
+  color: var(--destructive, hsl(0 67% 60%));
+  box-shadow: inset 0 0 0 1.5px color-mix(in oklab, var(--destructive, hsl(0 67% 60%)) 45%, transparent);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  /* Still, but not invisible: recording is the one state here with a privacy
+   * cost, and `--destructive` on the glyph carries it once motion is off — the
+   * same fallback the turn mark takes. */
+  .composer-mic[data-recording] > svg {
+    animation: none;
+  }
+}
+
+/* The tool sheet's rows.
+ *
+ * Keyboard and pointer converge on ONE cursor: arrow keys set `data-active`,
+ * and hovering a row adopts it, so the sheet never shows two highlights at
+ * once. `:hover` is not a second rule here for that reason — the component
+ * reports the hover upward and the same attribute paints it.
+ */
+.composer-tool-row[data-active] {
+  background: var(--accent);
+  color: var(--accent-foreground);
+}
+
+/* The forget control shares the check's column, so a row never grows or
+ * reflows when it appears. Hidden until the row is hovered or the control
+ * itself is focused: keyboard-only users cannot hover, and a control that Tab
+ * can reach but the eye cannot find is worse than an absent one. */
+.composer-tool-forget {
+  opacity: 0;
+  color: var(--muted-foreground);
+  transition: opacity 120ms ease-out;
+}
+
+.composer-tool-row:hover .composer-tool-forget,
+.composer-tool-forget:focus-visible {
+  opacity: 1;
+}
+
+.composer-tool-forget:hover {
+  color: var(--foreground);
+}
+
+@media (prefers-reduced-motion: reduce) {
+  .composer-tool-forget {
+    transition: none;
+  }
+}