feat: give every Ekklesia screen one set of design tokens and elements

Modules have owned their own UI since ADR 0021, but the platform has never
said what that UI should look like. Every screen here — the Dashboard shell,
the display host, the module template — invented its own hex colours, font
stack, spacing, and radii, and they already disagreed. A module author had no
vocabulary for "the ordinary panel background", so the only available answer
was to invent one, and two modules would invent two.

Add `@ekklesia/design-tokens`: one validated, enumerable registry of semantic
tokens. A token declares a name, label, description, and default value; its
category and `--ekklesia-*` identifier are derived from the name, so it can
never claim one category while being named for another. Construction rejects
duplicates, malformed names, unknown categories, empty or overlong text, and
any value that is not a bounded literal — no declaration terminator, rule
block, comment, at-rule, `url(`, `!important`, escape, control character, or
markup. A registry that constructs can therefore be emitted as CSS without
escaping, because nothing needing escaping can be in it. That validation is
also what makes a future theme editor implementable rather than aspirational.

Add `@ekklesia/ui`: button, icon button, text input, select, checkbox, field
wrapper, panel, dialog, tabs, table and list primitives, badge, toast, and
empty/error/loading states — every value a token reference, with real
`:focus-visible` treatment and status that never depends on colour alone.
Deliberately small: an element earns its place when two consumers need it.

The stylesheet is a string rather than a `.css` file so the identical bytes
install into a document or an isolated artifact root, and so hover, disabled,
and focus-visible are real CSS rather than JavaScript approximations of them.

`pnpm boundaries` opens exactly two shared roles to modules, by name — every
other role stays rejected — and pins both design packages to the bottom of the
presentation stack. Both are browser-safe by construction, proven by a real
compile of module-shaped source in which `process.env` must fail to typecheck.

The shell installs the defaults at its document root for the Dashboard and the
display; custom properties inherit into module artifacts, so a module reads
`var(--ekklesia-…)` with nothing to import at run time and nothing for a host
to forget to pass.

Co-Authored-By: Claude Opus 5 <[email protected]>

packages/ui/src/feedback.tsx

@@ -0,0 +1,161 @@
+import type { ReactElement, ReactNode } from "react";
+import { classNames } from "./class-names.js";
+
+/**
+ * How the platform says something is fine, something needs attention, something broke, something is
+ * loading, and there is nothing here yet.
+ *
+ * ## Status never depends on colour alone
+ *
+ * Every status tone renders a symbol beside its label — `✓`, `!`, `✕`, `i` — sourced from the
+ * design-token registry so a theme can change the glyph without a component changing. A screen in a
+ * bright lobby, a projector with a washed-out gamut, and a person who cannot distinguish red from
+ * green all get the same information (WCAG 2.2 §1.4.1). This is a rule of the shared elements, not
+ * an option a caller can turn off.
+ */
+
+export type EkklesiaStatusTone = "neutral" | "info" | "success" | "warning" | "danger";
+
+const statusSymbols: Readonly<Record<EkklesiaStatusTone, string>> = Object.freeze({
+  danger: "✕",
+  info: "i",
+  neutral: "•",
+  success: "✓",
+  warning: "!",
+});
+
+export interface BadgeProps {
+  readonly tone?: EkklesiaStatusTone;
+  readonly className?: string;
+  readonly children?: ReactNode;
+}
+
+/** A compact status indicator: a tone, its symbol, and a label. */
+export function Badge(props: BadgeProps): ReactElement {
+  const tone = props.tone ?? "neutral";
+  return (
+    <span className={classNames("ek-badge", `ek-badge--${tone}`, props.className)}>
+      <span aria-hidden="true" className="ek-badge__symbol">
+        {statusSymbols[tone]}
+      </span>
+      {props.children}
+    </span>
+  );
+}
+
+export interface ToastProps {
+  readonly tone?: EkklesiaStatusTone;
+  readonly title: ReactNode;
+  readonly className?: string;
+  readonly children?: ReactNode;
+}
+
+/**
+ * One notification's presentation — and only its presentation.
+ *
+ * There is deliberately no toast *manager*: no queue, no timeout, no global store, no imperative
+ * `toast()` function. Queuing policy belongs to whichever application is rendering, and a
+ * package-level singleton would be shared mutable state reaching across every isolated artifact on
+ * a page. A caller renders these where it wants them, for as long as it wants them.
+ */
+export function Toast(props: ToastProps): ReactElement {
+  const tone = props.tone ?? "info";
+  return (
+    <div
+      aria-live={tone === "danger" ? "assertive" : "polite"}
+      className={classNames("ek-toast", `ek-toast--${tone}`, props.className)}
+      role="status"
+    >
+      <div className="ek-toast__title">
+        <span aria-hidden="true">{statusSymbols[tone]} </span>
+        {props.title}
+      </div>
+      {props.children === undefined ? undefined : (
+        <div className="ek-toast__body">{props.children}</div>
+      )}
+    </div>
+  );
+}
+
+export interface ToastStackProps {
+  readonly label?: string;
+  readonly className?: string;
+  readonly children?: ReactNode;
+}
+
+export function ToastStack(props: ToastStackProps): ReactElement {
+  return (
+    <section
+      aria-label={props.label ?? "Notifications"}
+      className={classNames("ek-toast__stack", props.className)}
+    >
+      {props.children}
+    </section>
+  );
+}
+
+export interface EmptyStateProps {
+  readonly title: ReactNode;
+  readonly description?: ReactNode;
+  /** The one action that would resolve the emptiness, if there is one. */
+  readonly action?: ReactNode;
+  readonly className?: string;
+}
+
+export function EmptyState(props: EmptyStateProps): ReactElement {
+  return (
+    <div className={classNames("ek-message", props.className)}>
+      <p className="ek-message__title">{props.title}</p>
+      {props.description === undefined ? undefined : (
+        <p className="ek-message__body">{props.description}</p>
+      )}
+      {props.action}
+    </div>
+  );
+}
+
+export interface ErrorStateProps {
+  readonly title: ReactNode;
+  readonly description?: ReactNode;
+  /** A retry control, or whatever else the caller can honestly offer. */
+  readonly action?: ReactNode;
+  readonly className?: string;
+}
+
+/**
+ * The failure a person sees.
+ *
+ * Callers pass a fixed, human message. **Never** pass a caught exception, a stack, a URL, a
+ * filesystem path, or a raw server response: every Ekklesia error boundary is sanitized, and this
+ * component is where that discipline becomes visible to a user.
+ */
+export function ErrorState(props: ErrorStateProps): ReactElement {
+  return (
+    <div className={classNames("ek-message", "ek-message--error", props.className)} role="alert">
+      <p className="ek-message__title">{props.title}</p>
+      {props.description === undefined ? undefined : (
+        <p className="ek-message__body">{props.description}</p>
+      )}
+      {props.action}
+    </div>
+  );
+}
+
+export interface LoadingStateProps {
+  readonly label?: string;
+  readonly className?: string;
+}
+
+export function LoadingState(props: LoadingStateProps): ReactElement {
+  const label = props.label ?? "Loading…";
+  return (
+    <div
+      aria-live="polite"
+      className={classNames("ek-message", "ek-message--loading", props.className)}
+      role="status"
+    >
+      <div aria-hidden="true" className="ek-spinner" />
+      <p className="ek-message__body">{label}</p>
+    </div>
+  );
+}