@kitn.ai/ui 0.29.0 → 0.31.0

package/dist/components/builder-layout.d.ts

@@ -0,0 +1,54 @@
+import { JSX } from 'solid-js';
+export type BuilderViewport = 'desktop' | 'tablet' | 'mobile';
+export interface BuilderLayoutProps {
+    /** The construct's display name, shown in the toolbar. */
+    name: string;
+    /** The inspector panel content — typically `<BuilderPanel>`. */
+    panel: JSX.Element;
+    /** The preview content — typically a device frame wrapping `<ChatThread>`.
+     *  Callers that need to reflow their OWN preview at narrower widths (e.g.
+     *  a docked-rail template collapsing to full-bleed on `mobile`, matching
+     *  `ui/dock.tsx`'s own <=480px takeover) should read `viewport`/
+     *  `defaultViewport`/`onViewportChange` below and drive their preview's
+     *  shape from the same signal they hand this component — see
+     *  `builder-in-app-assistant.stories.tsx` and `builder.stories.tsx` for
+     *  the pattern. */
+    preview: JSX.Element;
+    /** Controlled viewport selection. Omit for uncontrolled (internal) state,
+     *  same controlled/uncontrolled convention as `Switch`'s
+     *  `checked`/`defaultChecked` and `ToggleChip`'s `pressed`/
+     *  `defaultPressed`. A caller that needs to reflow its own `preview` JSX
+     *  per viewport (see the doc comment on `preview`) should lift this to a
+     *  signal of its own and pass both this and `onViewportChange`. */
+    viewport?: BuilderViewport;
+    /** Initial viewport when uncontrolled. Defaults to `'desktop'`. */
+    defaultViewport?: BuilderViewport;
+    /** Fires with the next viewport on chip selection (controlled or not). */
+    onViewportChange?: (viewport: BuilderViewport) => void;
+    /** Stub export/save action; the real seam (a file write, per the spike) isn't
+     *  built here. */
+    onSave?: () => void;
+    class?: string;
+}
+/**
+ * `BuilderLayout` — the two-pane builder shell: a fixed-width scrollable
+ * inspector on the left, a live preview on the right over a dotted canvas
+ * background (a deliberate "this is a design tool" cue, not a real device
+ * emulator). A thin toolbar strip carries the construct name, a viewport
+ * toggle, and a stub Export action.
+ *
+ * The viewport toggle (Round A4 — was a round-1 visual stub) constrains the
+ * PREVIEW FRAME's width: `desktop` fills the pane exactly as before (no
+ * wrapper, no width style — the historical "stub" behavior for that one
+ * case); `tablet`/`mobile` wrap `preview` in a centered frame sized to
+ * `FRAME_WIDTH` above (768px / 390px), letting whatever `preview` renders
+ * reflow inside it. This is still not a real device emulator — no bezel,
+ * no user-agent spoofing, no touch simulation — just a width constraint,
+ * consistent with the doc comment this replaced.
+ *
+ * Pure shell: `panel` and `preview` are handed in as JSX so this component
+ * carries no opinion about what fills them; reflowing the CONTENT of
+ * `preview` at a given width (rather than just its outer box) is the
+ * caller's job — see the `preview` prop's own doc comment.
+ */
+export declare function BuilderLayout(props: BuilderLayoutProps): JSX.Element;

package/dist/components/builder-message-actions.d.ts

@@ -0,0 +1,63 @@
+import { JSX, Component } from 'solid-js';
+import { ChatMessageAction } from '../elements/chat-types.js';
+/**
+ * The role-scoped, ordered message-action picker — extracted from
+ * `builder-in-app-assistant.stories.tsx` (Round A3) into this standalone
+ * module during the T-1 build-out so the Assistant and Research templates
+ * (both asked for a "message actions, role-scoped picker, reuse" section)
+ * share one definition instead of forking it. `builder-in-app-assistant.
+ * stories.tsx` was retrofitted to import from here in the same round; its
+ * rendered output and behavior are unchanged — this is a pure extraction.
+ *
+ * Model: `ChatMessage.actions` (`elements/chat-types.ts`) is `(ChatMessage
+ * Action | CustomAction)[]` — an ORDERED array, not a set — and role-scoped
+ * only by caller curation (checked against `message.tsx`/`chat-thread.tsx`:
+ * neither hard-couples any built-in id to a role). This picker enforces
+ * role-appropriateness via two independent catalogs, one per role, each
+ * independently ordered and toggled.
+ *
+ * `'speak'` (read-aloud) is a real `ChatMessageAction` (elements/
+ * chat-actions.ts) backed by the kit's own SpeechSynthesis mechanics
+ * (primitives/speech.ts, shared with `kai-voice-output`) via the shared
+ * action-bar click router (primitives/message-feedback.ts).
+ */
+export type UserActionId = Extract<ChatMessageAction, 'edit' | 'copy'>;
+export type AssistantActionId = ChatMessageAction;
+export interface ActionRowDef<TId extends string> {
+    id: TId;
+    label: string;
+    /** A curated icon — same components `ui/action-icons.ts`'s registry maps
+     *  each built-in id to, so the picker's icons match what the real action
+     *  bar renders. */
+    icon: Component<{
+        class?: string;
+    }>;
+}
+export interface ActionRowState<TId extends string> {
+    id: TId;
+    enabled: boolean;
+}
+export declare const USER_ACTION_CATALOG: readonly ActionRowDef<UserActionId>[];
+export declare const ASSISTANT_ACTION_CATALOG: readonly ActionRowDef<AssistantActionId>[];
+/** Owner defaults (Round A3): "Your messages" starts with only Edit on;
+ *  "Assistant messages" starts with Copy/Like/Dislike on, Regenerate and
+ *  Speak off. Row ORDER here is also the default enabled-action order. */
+export declare const DEFAULT_USER_ACTION_ROWS: ActionRowState<UserActionId>[];
+export declare const DEFAULT_ASSISTANT_ACTION_ROWS: ActionRowState<AssistantActionId>[];
+/**
+ * One role's ordered, toggleable action list — a vertical list of rows
+ * (icon + label + up/down reorder buttons + an enable switch). Row ORDER
+ * is the array order, and doubles
+ * as the enabled-action order once filtered — no separate "priority"
+ * field, because the component tier has no separate concept either.
+ *
+ * Up/down buttons over drag-and-drop: keyboard- and screen-reader-operable
+ * for free, which a bare drag handle is not, without extra work a design
+ * round doesn't need to do to prove the model (T-6).
+ */
+export declare function ActionRowPicker<TId extends string>(props: {
+    legend: string;
+    catalog: readonly ActionRowDef<TId>[];
+    rows: ActionRowState<TId>[];
+    onChange: (next: ActionRowState<TId>[]) => void;
+}): JSX.Element;

package/dist/components/builder-panel-derived.d.ts

@@ -0,0 +1,18 @@
+import { JSX } from 'solid-js';
+import { BuildableTemplate } from '../agent-tooling/construct/templates.js';
+import { Construct, ConstructProblem } from '../agent-tooling/construct/schema.js';
+export interface DerivedBuilderPanelProps {
+    value: Construct;
+    onChange: (next: Construct) => void;
+    template: BuildableTemplate;
+    problems?: readonly ConstructProblem[];
+    class?: string;
+}
+export interface FieldEditorProps {
+    path: string;
+    value: Construct;
+    write: (next: Construct) => void;
+}
+export declare function labelFor(path: string): string;
+export declare const FIELD_OVERRIDES: Record<string, (props: FieldEditorProps) => JSX.Element>;
+export declare function DerivedBuilderPanel(props: DerivedBuilderPanelProps): JSX.Element;

package/dist/components/builder-panel.d.ts

@@ -0,0 +1,240 @@
+import { JSX } from 'solid-js';
+export type BuilderLayoutKind = 'widget' | 'fullscreen' | 'aside' | 'split' | 'custom';
+export type BuilderThemeMode = 'light' | 'dark' | 'system';
+export type BuilderHistoryPersistence = 'none' | 'local' | 'endpoint';
+export interface BuilderHomeLink {
+    label: string;
+    href?: string;
+    description?: string;
+    icon?: string;
+}
+export interface BuilderHome {
+    greeting?: {
+        title?: string;
+        subtitle?: string;
+    };
+    links?: BuilderHomeLink[];
+}
+export interface BuilderCapabilities {
+    starters?: string[];
+    attachments?: {
+        accept?: string[];
+    };
+    history?: {
+        persistence: BuilderHistoryPersistence;
+    };
+    conversations?: boolean;
+}
+export type BuilderWidgetPosition = 'bottom-end' | 'bottom-start' | 'top-end' | 'top-start';
+/** `layout: 'widget'`-scoped FAB chrome — mirrors `construct.v1`'s own
+ *  `widget` block. Meaningless on any other layout, which is exactly why
+ *  the panel section it drives is HIDDEN, not just disabled, on any other
+ *  layout (see the Layout section's own doc comment for that distinction). */
+export interface BuilderWidget {
+    position?: BuilderWidgetPosition;
+    launcherIcon?: string;
+    defaultOpen?: boolean;
+}
+export type BuilderProviderMode = 'mock' | 'endpoint';
+export type BuilderProviderWire = 'openai' | 'anthropic';
+/** Mirrors `construct.v1`'s own `provider` discriminated union
+ *  (`agent-tooling/construct/schema.ts`'s `ProviderSchema`) — `mock` needs
+ *  nothing else; `endpoint` needs the consumer's own chat route + wire
+ *  format. A DISPLAY/edit stub, not a real one: no dev-server exists for
+ *  this design round to actually call, so there's nothing to validate the
+ *  URL against — the field exists so a template's panel shows the whole
+ *  construct shape, not because this round wires it to anything. */
+export interface BuilderProvider {
+    mode: BuilderProviderMode;
+    url?: string;
+    wire?: BuilderProviderWire;
+}
+/** Mirrors `construct.v1`'s own `cards` entry shape (`schema.ts`'s
+ *  `cards` array): a tool-facing `name` plus the kit's card-schema JSON.
+ *  `schema` is `Record<string, unknown>` here too — deep card validation
+ *  (incl. `x-kai-format` mask hints) is the kit's own card contract at
+ *  render time, not this stub panel's job; this stub only ever READS
+ *  `schema.title` for a display label (Round A's read-only Cards section —
+ *  see `BuilderPanelSections.cards`). */
+export interface BuilderCard {
+    name: string;
+    schema?: Record<string, unknown>;
+}
+export interface BuilderConstruct {
+    name: string;
+    layout: BuilderLayoutKind;
+    provider?: BuilderProvider;
+    header?: {
+        title?: string;
+    };
+    theme?: {
+        accent?: string;
+        unreadColor?: string;
+        mode?: BuilderThemeMode;
+    };
+    home?: BuilderHome;
+    capabilities?: BuilderCapabilities;
+    widget?: BuilderWidget;
+    cards?: BuilderCard[];
+}
+/**
+ * A template-scoped section configuration (Round W, T-2/T-6): a template
+ * FIXES its layout internally (no layout radio) and owns which of the
+ * layout-scoped sections apply — a widget template shows Widget chrome
+ * unconditionally (it IS the widget template, not merely "currently set to
+ * widget"), where the old layout-driven panel showed it only when the
+ * layout radio happened to be on "Widget". Omit this prop entirely to get
+ * the original, generic, layout-driven panel (every existing test above
+ * exercises that default) — a template panel opts INTO the narrower set
+ * rather than the generic panel opting out.
+ */
+export interface BuilderPanelSections {
+    /** Show the Layout radio section. Default `true` (the generic panel).
+     *  A template panel sets this `false` — T-2: the template fixes the
+     *  layout, so there is nothing left to choose here. */
+    layout?: boolean;
+    /** The Widget-chrome section's visibility. `'auto'` (default) follows
+     *  `value.layout === 'widget'`, the original cross-field-visibility
+     *  behavior. `'always'` shows it unconditionally — what a Support widget
+     *  template panel wants, since for THAT template the section is never
+     *  conditional, it's simply always this template's own controls.
+     *  `'never'` hides it — what every non-widget template wants once each
+     *  gets its own `Labs/Builder/<Template>` story. */
+    widget?: 'auto' | 'always' | 'never';
+    /** Show the Provider section (mode + endpoint URL/wire when applicable).
+     *  Default `false` — the generic panel predates `provider` existing on
+     *  `BuilderConstruct` at all; a template panel opts in. */
+    provider?: boolean;
+    /** Show the Home section (greeting/links tab). Default `true` (the
+     *  generic panel). A template with no Home concept at all — In-app
+     *  assistant (Round A): widget-only chrome, no Home/Messages tab bar in
+     *  its own construct basis (`fixtures/ops-console.construct.json` has no
+     *  `home` key) — sets this `false` to remove the section outright,
+     *  rather than leaving a switch that would only ever read "off". */
+    home?: boolean;
+    /** Show a READ-ONLY Cards section: the construct's declared card names
+     *  (Round A's `cards` addition to `BuilderConstruct`), with a muted note
+     *  that editing them is a later round. Default `false`. Deliberately not
+     *  an editor — a template whose construct basis carries `cards` (like
+     *  `ops-console.construct.json`'s `deployment_parameters` form) still
+     *  needs the panel to acknowledge them exist rather than silently
+     *  dropping them from view, without this design round faking a card-
+     *  schema editor it doesn't have (decide loudly, per CLAUDE.md). */
+    cards?: boolean;
+}
+export interface BuilderPanelProps {
+    /** The construct being edited. Controlled — the panel never holds its own copy. */
+    value: BuilderConstruct;
+    /** Fires with the next construct on every edit. */
+    onChange: (next: BuilderConstruct) => void;
+    /** Which sections render — see `BuilderPanelSections`. Omit for the
+     *  original generic, layout-driven panel. */
+    sections?: BuilderPanelSections;
+    class?: string;
+}
+/** One "common case" chip for `capabilities.attachments.accept`: a human label
+ *  over one or more raw MIME patterns. Owner feedback (design round 2):
+ *  raw MIME types are hostile to the audience this panel is for, so the
+ *  common cases get a toggle chip and the raw list is a secondary, visible
+ *  ("Advanced") affordance rather than the primary input. */
+export interface AcceptChip {
+    id: string;
+    label: string;
+    patterns: readonly string[];
+}
+/**
+ * The chip → MIME-pattern map for the attachments accept editor below.
+ *
+ * Exported (not module-local) because it's exactly the vocabulary a future
+ * schema-driven wizard or capability menu (RECOMMENDATION.md's "real build")
+ * will also want — one place to widen the common-case list rather than a
+ * second one growing beside it.
+ */
+export declare const ACCEPT_CHIPS: readonly AcceptChip[];
+export declare function Section(props: {
+    title: string;
+    children: JSX.Element;
+}): JSX.Element;
+export declare function Field(props: {
+    label: string;
+    hint?: string;
+    children: JSX.Element;
+}): JSX.Element;
+export declare function Row(props: {
+    label: string;
+    children: JSX.Element;
+    muted?: boolean;
+}): JSX.Element;
+/** A minimal, reusable string-tag editor — the taglist pattern the spike
+ *  proved out (`starters`). `capabilities.attachments.accept` moved to
+ *  `AcceptTypeEditor` below (owner feedback, design round 2): raw MIME
+ *  strings are a bad first surface for this audience. */
+export declare function TagEditor(props: {
+    tags: string[];
+    onChange: (next: string[]) => void;
+    ariaLabel: string;
+    placeholder?: string;
+}): JSX.Element;
+/**
+ * `capabilities.attachments.accept` — chips for the common cases
+ * (`ACCEPT_CHIPS`) over a collapsed "Advanced" raw MIME-list editor.
+ *
+ * A chip lights up (`aria-pressed`) exactly when EVERY one of its patterns is
+ * present in `accept` — toggling it adds/removes that whole pattern group.
+ *
+ * Owner feedback (design round 5): the raw pattern list is no longer shown
+ * under the chips at all — it lives ONLY inside the "Advanced" disclosure,
+ * as an autosizing textarea (one MIME type/glob per line, not a comma
+ * string: each edit adds or removes a LINE rather than reflowing a long
+ * wrapped string, and a list copied from a spec or another tool's `accept`
+ * field is naturally one-per-line already; a pasted comma list still parses
+ * fine, `commitDraft` splits on either). A hand-added entry lives only
+ * there; no chip claims it.
+ */
+export declare function AcceptTypeEditor(props: {
+    accept: string[];
+    onChange: (next: string[]) => void;
+}): JSX.Element;
+/** `home.links` — the array-of-objects hard case (RECOMMENDATION.md), as a
+ *  small labeled-row repeater. Each row explicitly numbered ("Link N") so a
+ *  scanning eye always knows which entry it's looking at. */
+export declare function LinksEditor(props: {
+    links: BuilderHomeLink[];
+    onChange: (next: BuilderHomeLink[]) => void;
+}): JSX.Element;
+/**
+ * `BuilderPanel` — the visual construct builder's inspector: identity, layout,
+ * theme, an optional Home tab, and capabilities. Pure props/callbacks, stub-
+ * friendly (no dev-server seam, no schema derivation) — a STORY-FIRST design
+ * surface for the panel's look, per RECOMMENDATION.md. Composed entirely from
+ * the kit's own controls (`Input`/`Textarea`/`Switch`/`RadioGroup`/`Select`/
+ * `Button`/`ColorField`/`ToggleChip`); no `part=` attributes — this component is not
+ * yet wired to a `kai-*` facade.
+ *
+ * Round W (T-2/T-6) added `sections` (`BuilderPanelSections`): omit it for
+ * the original generic, layout-driven panel this doc comment otherwise
+ * describes unchanged; pass it to scope the panel to ONE template's control
+ * set — no Layout radio, Widget chrome shown unconditionally rather than
+ * `layout`-conditionally, a Provider section — the shape `Labs/Builder/
+ * Support widget` (`src/elements/builder.stories.tsx`) actually uses.
+ *
+ * Three patterns from the spike (plus the owner's own round-8 ruling) get
+ * real design treatment here rather than being hand-waved:
+ *  - **presence-as-boolean**: `home` and `capabilities.attachments` are each
+ *    driven by ONE switch that adds/removes the whole sub-object, with its
+ *    revealed fields directly below (no second "enabled" flag living beside
+ *    the object it toggles).
+ *  - **cross-field visibility, field-level**: `capabilities.conversations`
+ *    requires `capabilities.history.persistence` to be `local`/`endpoint`
+ *    (the schema's own `superRefine` rule) — shown as a disabled switch with
+ *    the reason spelled out in muted text right below it, not a validation
+ *    error surfaced after the fact.
+ *  - **cross-field visibility, section-level**: the whole "Widget" section
+ *    (position/launcher icon/open-by-default) is meaningless outside
+ *    `layout: 'widget'`, and unlike the single Conversations toggle above, a
+ *    disabled-and-explained SECTION would just be three greyed-out rows for
+ *    one sentence's worth of reason — so it's hidden entirely, not disabled,
+ *    whenever `layout` isn't `'widget'` (owner ruling, design round 8; see
+ *    that section's own comment for the full distinction).
+ */
+export declare function BuilderPanel(props: BuilderPanelProps): JSX.Element;

package/dist/components/builder-preview.d.ts

@@ -0,0 +1,11 @@
+import { BuilderConstruct } from './builder-panel.js';
+/**
+ * The inline style object a stub preview's wrapper needs so a construct's
+ * `theme.accent` actually retints its descendants: both the public
+ * (`--kai-color-primary`) and internal (`--color-primary`) tokens, plus
+ * their paired foreground when the accent resolves to concrete RGB — see
+ * the module doc comment above for why both are required. Returns `{}` for
+ * no accent (the kit's own neutral default applies, same as omitting the
+ * property entirely).
+ */
+export declare function resolveAccentWrapperStyle(theme: BuilderConstruct['theme']): Record<string, string>;

package/dist/components/builder-shell-controls.d.ts

@@ -0,0 +1,69 @@
+import { JSX } from 'solid-js';
+/**
+ * "App chrome" — the Command palette and User menu shell knobs (owner
+ * discovery round), factored as a shared module so every shell-bearing
+ * template (`Labs/Builder/Assistant`, `.../Workspace`, `.../Multi-mode`)
+ * reuses the same real pieces instead of forking a fourth copy —
+ * consistent with `builder-composer-triggers.tsx`'s own rule-of-three
+ * extraction earlier this round.
+ *
+ * COMMAND PALETTE: composes the kit's real `CommandList` (`ui/command.tsx`)
+ * — a presentational grouped listbox — inside a hand-built overlay
+ * (backdrop + centered panel + Escape/backdrop-click to close), the SAME
+ * shape `elements/claude-code.stories.tsx`'s own command-center overlay
+ * uses around `kai-command` (read before building this — `CommandList` is
+ * that facade's underlying Solid piece; the facade adds the search input's
+ * filtering behavior itself, which `CommandList` does not own). A plain
+ * `Input` above the list does the filtering here, client-side over a stub
+ * catalog, matching claude-code's own placeholder copy style ("Search
+ * commands...").
+ *
+ * USER MENU: `elements/user-menu.stories.tsx`'s own doc comment states it
+ * plainly — "the user menu is a RECIPE, not an element... kai-menu with a
+ * slotted trigger (kai-avatar + name + plan + a chevron + a kai-status
+ * dot)". Reused here as the Solid-tier equivalent: `Dropdown`/
+ * `DropdownTrigger`/`DropdownContent`/`DropdownItem` (the same primitives
+ * `components/model-switcher.tsx` and the Workspace composer menu already
+ * compose) with an `Avatar` + name/plan trigger.
+ */
+export interface ShellControlsState {
+    commandPalette: boolean;
+    userMenu: boolean;
+}
+/** The command palette overlay — mounted only while `open`. Filters the
+ *  stub catalog client-side; selecting a row or pressing Escape closes it. */
+export declare function CommandPaletteOverlay(props: {
+    open: boolean;
+    onClose: () => void;
+}): JSX.Element;
+/** The command palette's TRIGGER — a plain search-icon button, matching
+ *  claude-code's own rail-header search affordance. Rendering the overlay
+ *  itself is the caller's job (`CommandPaletteOverlay`), so a template can
+ *  place the trigger inside its own rail/header chrome while the overlay
+ *  mounts at the frame root. */
+export declare function CommandPaletteTrigger(props: {
+    onOpen: () => void;
+}): JSX.Element;
+/** The user-menu recipe itself — avatar + name/plan trigger, real Dropdown
+ *  primitives, a stub items list (Settings/Help/Log out). `compact` (owner
+ *  feedback round, Workspace's app-header rework) drops the name/plan text
+ *  entirely, rendering avatar + chevron only — for a header utility cluster
+ *  where the full name/plan reads as too much next to icon-only siblings.
+ *  `name`/`plan` still feed the avatar initials and the accessible name
+ *  (`aria-label`) even when compact, so the control never loses its name to
+ *  assistive tech just because the text is hidden visually. */
+export declare function UserMenu(props: {
+    name: string;
+    plan?: string;
+    class?: string;
+    compact?: boolean;
+}): JSX.Element;
+/** The panel section every shell-bearing template reuses: two toggles,
+ *  "Command palette" and "User menu." Preview-only — see each template's
+ *  own module doc comment for how the toggles wire into ITS OWN chrome
+ *  (the trigger/overlay/menu placement differs per template's real
+ *  anatomy, so this section only owns the on/off state, not the layout). */
+export declare function ShellSection(props: {
+    state: ShellControlsState;
+    onChange: (v: ShellControlsState) => void;
+}): JSX.Element;

package/dist/components/builder-skeleton.d.ts

@@ -0,0 +1,58 @@
+import { JSX } from 'solid-js';
+/**
+ * Shared wordless-skeleton language for `Labs/Builder/<Template>` preview
+ * hosts (docs/superpowers/specs/2026-08-28-template-builder-design.md).
+ *
+ * Extracted from `builder-in-app-assistant.stories.tsx` (Round A2) into this
+ * standalone module during the T-1 build-out (Assistant/Research/Workspace/
+ * Voice) so every template's "the rest of your app" skeleton chrome shares
+ * one definition instead of four copies drifting apart — the cross-cutting
+ * mandate the design spec's Process step names ("as shared needs emerge,
+ * refactor the shared components ONCE"). `builder-in-app-assistant.stories.tsx`
+ * was retrofitted to import from here in the same round; nothing about its
+ * rendered output changed.
+ *
+ * PLAIN inline CSS (`color-mix`), not a Tailwind opacity-modifier class
+ * on a color utility or an arbitrary-bracket width value — see the
+ * original Round A2 note in git blame: this Storybook dev server's
+ * Tailwind JIT pass proved non-deterministic for FRESH combinations
+ * introduced by a single file (a class would show correctly in the rendered
+ * `className` while `getComputedStyle` reported the rule simply wasn't
+ * compiled). `color-mix()` is real CSS with no compile step to race, and
+ * matches what Tailwind's own `/NN` opacity modifier generates.
+ */
+export declare function mix(colorVar: string, pct: number): string;
+/** One skeleton bar/pill. `widthClass` for a standard-scale Tailwind width
+ *  utility (proven reliable); `width` for an inline CSS width (a
+ *  percentage, or anything arbitrary); `flex` to grow and fill instead of
+ *  taking either. Height is always a standard-scale utility unless
+ *  overridden. */
+export declare function SkeletonBar(props: {
+    widthClass?: string;
+    width?: string;
+    heightClass?: string;
+    pct: number;
+    flex?: boolean;
+}): JSX.Element;
+/** A grayscale/muted skeleton stat tile: a label bar over a bigger number
+ *  bar. Deliberately toneless (muted-foreground tints only, never
+ *  `bg-primary`/accent) so the host reads as chrome around the product
+ *  rather than product itself. */
+export declare function StubStatTile(props: {
+    class?: string;
+}): JSX.Element;
+/** A single stub nav-rail row: an icon-ish dot plus a label bar. `active`
+ *  lights the row the way a real nav's current-page item would. */
+export declare function StubNavRow(props: {
+    active?: boolean;
+}): JSX.Element;
+/** A single stub table row: a handful of column bars at staggered widths,
+ *  so the row reads as data rather than one flat block. */
+export declare function StubTableRow(): JSX.Element;
+/** A wordless skeleton code/text block: a stack of bars at staggered
+ *  widths, monospace rhythm (shorter, denser bars) rather than prose
+ *  rhythm — for the Workspace template's artifact/code pane. */
+export declare function StubCodeBlock(props: {
+    lines?: number;
+    class?: string;
+}): JSX.Element;

package/dist/components/builder-start.d.ts

@@ -0,0 +1,79 @@
+import { JSX } from 'solid-js';
+import { TemplateId } from '../agent-tooling/construct/templates.js';
+export type BuilderTemplateId = TemplateId | 'scratch';
+/** The template ids that DO have a card — every registry id. */
+export type BuilderCardTemplateId = TemplateId;
+export interface BuilderTemplate {
+    id: BuilderCardTemplateId;
+    name: string;
+    description: string;
+}
+/** All six cards, DERIVED from the template registry (B-17b) — id, name and
+ *  one-liner are the registry's own; this module adds only the
+ *  illustrations, which stay component-side keyed by id (SVGs are not
+ *  registry data). The Labs story renders all six (T-1a); a real product
+ *  surface renders BUILDABLE_BUILDER_TEMPLATES instead (menu-honesty). */
+export declare const BUILDER_TEMPLATES: readonly BuilderTemplate[];
+export declare const BUILDABLE_BUILDER_TEMPLATES: readonly BuilderTemplate[];
+export interface BuilderStartProps {
+    /** The currently selected template id, or unset for none yet. Controlled —
+     *  this component holds no selection state of its own. */
+    value?: BuilderTemplateId;
+    /**
+     * Fires with a template's id when its card is chosen. Click-to-advance
+     * (design choice, this round): T-7 says "selection advances to that
+     * template's builder", and there is nothing a second "Continue" step
+     * would add here that the click itself doesn't already mean — a
+     * disambiguating confirm step belongs to T-2's SWITCHING-template case
+     * (control set changes, so a re-pick needs a confirm), not to picking a
+     * template for the first time. So `onSelect` fires on the same click that
+     * shows the selected ring; the story's Continue readout below just proves
+     * the callback fired, since there's no template builder screen yet to
+     * navigate to.
+     */
+    onSelect: (id: BuilderTemplateId) => void;
+    /** Which cards to render. Defaults to BUILDABLE_BUILDER_TEMPLATES
+     *  (menu-honest by default). The Labs story passes BUILDER_TEMPLATES (all
+     *  six) explicitly to show the full catalog. */
+    templates?: readonly BuilderTemplate[];
+    class?: string;
+}
+export declare const BLUEPRINT_BG: {
+    readonly 'background-image': "radial-gradient(circle, var(--color-border) 1px, transparent 1px)";
+    readonly 'background-size': "14px 14px";
+};
+/**
+ * `BuilderStart` — the builder's opening screen: six selectable template
+ * cards (T-7, grown from four in Round P2). Each card is a real
+ * `ui/card.tsx` `Card` (`clickable`,
+ * `media` for the illustration, `header` for the name), not a hand-rolled
+ * button — the kit's own primitive already gives a `role="button"` with
+ * Enter/Space activation, which settles this screen's keyboard-semantics
+ * question: a `radiogroup` was the other defensible reading (this IS a
+ * single choice among six), but `Card` already implements exactly the
+ * button-per-card pattern with no extra wiring, and reusing it beats
+ * building a second selection primitive for one screen.
+ *
+ * Brand alignment (T-7): the kit's own tokens throughout — no new color, no
+ * new radius, no new type stack. The illustrations are the one genuinely new
+ * visual element this round adds; see `TEMPLATE_ILLUSTRATIONS` below for
+ * their shared style rules.
+ */
+export declare function BuilderStart(props: BuilderStartProps): JSX.Element;
+export declare const STROKE = 1.5;
+export declare const LINE: {
+    stroke: string;
+    fill: string;
+};
+export declare const BORDER: {
+    stroke: string;
+    fill: string;
+};
+export declare const ACCENT: {
+    stroke: string;
+    fill: string;
+};
+export declare const ACCENT_FILL: {
+    stroke: string;
+    fill: string;
+};

package/dist/components/builder-workspace-variants.d.ts

@@ -0,0 +1,23 @@
+import { JSX } from 'solid-js';
+export type WorkspaceVariantId = 'artifactPreview' | 'appPreview';
+export interface WorkspaceVariant {
+    id: WorkspaceVariantId;
+    name: string;
+    description: string;
+}
+export declare const WORKSPACE_VARIANTS: readonly WorkspaceVariant[];
+export interface WorkspaceVariantPickerProps {
+    value?: WorkspaceVariantId;
+    onSelect: (id: WorkspaceVariantId) => void;
+    onBack: () => void;
+    class?: string;
+}
+/**
+ * `WorkspaceVariantPicker` — the Workspace family's second screen: two
+ * function-named variant cards (smaller-scale `Card`s, reusing `Builder
+ * Start`'s own pattern) plus a back affordance to the template picker.
+ * Selection fires `onSelect` with the variant id the same click-to-advance
+ * shape `BuilderStart` itself uses (T-7's own reasoning: nothing a second
+ * "Continue" step would add here that the click doesn't already mean).
+ */
+export declare function WorkspaceVariantPicker(props: WorkspaceVariantPickerProps): JSX.Element;