Skip to content

transient-notices

Provenance

  • Source: .spec/spexcode/spec-dashboard/dashboard-ui/ui-primitives/transient-notices/spec.md
  • Source SHA-256: ea59c4be5ffb7aaf6ca8806fcaf85b0c91c71ad2ebc4513b80f349f7a79b8aeb

A write that has already completed needs an acknowledgement, not a new resident panel. Before this node, the Evals and Issues pages each carried a six-second, in-flow message while the session console pinned action outcomes beside or over its controls, sometimes indefinitely. The same product fact then had three visual grammars, and an old failure could keep consuming the active workspace long after it had been read.

One TransientNoticeProvider, mounted at the dashboard root, owns that lifecycle. Any dashboard surface uses its useTransientNotice() hook to publish a short message and semantic tone (success, error, or info); it does not own a timer, viewport, or duplicate rendering component. The provider gives every ordinary notice a five-second default. A caller may explicitly opt into another duration or a persistent notice only when the product contract needs it; silence never means permanent. A notice has a close control, pauses its remaining lifetime while hovered or keyboard-focused, and resumes only when the pointer/focus leaves, so readable copy is not removed while a human is interacting with it. A close or expiry removes only that notice; separate actions remain a compact newest-last stack rather than overwriting one another.

The viewport is fixed to the dashboard edge, above page content and below modal/popup layers. Its calm, single-row Obsidian-like grammar is the existing palette: a small semantic icon, concise text, and a familiar close icon in a lightly raised, theme-native surface. It uses dashboard CSS variables only, including the existing unified type scale; a theme flip reskins it without component logic. On narrow screens it respects the safe edges, uses the available width, and sits above the fixed phone tab bar rather than covering a thumb-reachable navigation control.

This is a completion/failure surface, not a substitute for state. A control that is actively posting keeps its local disabled/busy state, and a form error that a person must repair stays next to that form. Once an operation settles, its compact acknowledgement belongs here. The stack is role=status for ordinary and successful feedback; an error is announced with role=alert. New messages therefore surface to assistive technology without moving keyboard focus or interrupting the current task.