@nurix/etna 0.19.66 → 0.19.68

package/data/harnesses/apollo/skills/design/components/typography.md

@@ -1,46 +0,0 @@
-# Typography Components
-
-> Generated reference (regen-owned; see [index.md](index.md)). Binds only under `primitives: nurix`.
-
-Import each from its kebab-case subpath, e.g. `import { Badge } from "@nurix/components/badge"`.
-
-## Text
-
-Inline editable text using native `contentEditable` — plain text that grows a focus border and becomes editable on click, no controlled-input plumbing required.
-
-**Props:** `value`, `defaultValue`, `placeholder`, `disabled`, `readOnly`, `onSave`, `validator`, `onValidationError`, `hideHoverEffect`
-
-Enter or blur commits via `onSave` (skipped if unchanged); Escape reverts to the pre-edit value. A `validator` regex blocks the commit and reports via `onValidationError` instead.
-
-```tsx
-<Text
-  defaultValue={title}
-  placeholder="Untitled"
-  onSave={saveTitle}
-  validator={/^.{1,80}$/}
-/>
-```
-
-## SecureText
-
-Masked display for sensitive values (passwords, API keys, card numbers) with an optional reveal toggle.
-
-**Props:** `value`, `revealable` (default true), `defaultRevealed`, `revealed`/`onRevealedChange` (controlled), `variant` [default|mono], `size` [sm|default|lg], `maskOptions` (`{ maskChar, unmaskedStart, unmaskedEnd, preserveSpacing, grouping, showLength }`)
-
-```tsx
-<SecureText
-  value={apiKey}
-  variant="mono"
-  maskOptions={{ unmaskedStart: 4, unmaskedEnd: 4, grouping: 4 }}
-/>
-```
-
-## Other Components
-
-- `badge` — `Badge`: `variant` [default|secondary|destructive|outline|ghost|link], `asChild`
-- `chip` — `Chip`: removable tag; `variant` [default|secondary|outline|muted], `size` [sm|default|lg], `onRemove`, `disabled`
-- `code` — `Code`: inline `<code>` or a `block` (renders `<pre>`); `variant` [default|ghost|muted], `size` [sm|default|lg], `block`
-- `kbd` — `Kbd`: keycap; `variant` [default|outline], `size` [sm|default|lg]
-- `label` — `Label`: Radix `Label.Root`, tracks a peer/group's `disabled` state automatically
-- `link` — `Link`: `variant` [default|muted|plain|underline], `size` [sm|default|lg], `asChild`, `external` (forces `target="_blank"` + a trailing icon; also auto-detects `target="_blank"`)
-- `markdown` — `Markdown`: GFM `react-markdown` + `remark-gfm` render with a full element map (headings, lists, code, blockquote, tables) styled on the library's own tokens — no `@tailwindcss/typography` plugin needed; safe to re-render incrementally while streaming. **Props:** `children` (markdown string), `className`

package/data/harnesses/apollo/skills/design/components/utils.md

@@ -1,37 +0,0 @@
-# Utils
-
-> Generated reference (regen-owned; see [index.md](index.md)). Binds only under `primitives: nurix`.
-
-Low-level utilities and shared types, each published as its own subpath under `@nurix/components/<subpath>`.
-
-## cn
-
-`cn(...inputs)` (from `utils`) — `clsx` + `tailwind-merge`; the class-merge used throughout the library. Same subpath also exports `isMobileDevice()` (UA-sniffing boolean, prefer `useIsMobile` in components).
-
-```tsx
-<div className={cn("rounded-md", isActive && "bg-primary", className)} />
-```
-
-## formatDate
-
-`formatDate(date, opts?)` (from `format`) — Intl-based date formatting; returns `""` on a missing/invalid input instead of throwing. Defaults to `{ month: "long", day: "numeric", year: "numeric" }`, overridable via `opts`.
-
-## generateId
-
-`generateId(prefixOrOptions?, options?)` (from `id`) — nanoid-based alphanumeric ID; `{ length = 12, separator = "_" }`. Accepts a prefix key as the first argument (prepended with `separator`) or an options object directly.
-
-## getErrorMessage
-
-`getErrorMessage(err)` (from `handle-error`) — normalizes an unknown error into a display string: joins `ZodError` issue messages with newlines, passes through a plain `Error.message`, else a generic fallback.
-
-## getStrictContext
-
-`getStrictContext<T>(name?)` (from `get-strict-context`) — returns a `[Provider, useSafeContext]` pair; the hook throws (`useContext must be used within <name>`) when read outside its `Provider`, instead of silently returning `undefined`.
-
-## composeRefs
-
-`composeRefs(...refs)` / `useComposedRefs(...refs)` (from `compose-refs`) — merges multiple callback refs and `RefObject`s (including React 19 ref-cleanup returns) into one callback ref.
-
----
-
-Two further subpaths are non-UI escape hatches, not composable concepts: `types` (a barrel of public component prop types — `InputProps`, `SelectProps`, `CellProps`, …) and `node-catalog` (runtime node definitions for the NuStack Plan engine — data, not UI).

package/data/harnesses/apollo/skills/design/data/blueprints/browse.md

@@ -1,38 +0,0 @@
----
-id: browse
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Salesforce list views, GitHub search/Explore, Retool templates, Zendesk views, Notion gallery view, Airtable interfaces, Linear command menu"
-license: open
----
-Composition shapes for the browse archetype — unordered lookup across a record catalog. View-types (table, cards, board) are projections that may appear inside any shape.
-
-## Shape: Filter Rail Browse
-Regions: search/sort bar (full-width, top) / filter rail (left, fixed ~20%, checkboxes and facets) / result area (remaining ~80%, table or card grid) / optional saved-view tabs above the results.
-The eye lands on: the result count and the first few rows or cards immediately right of the rail.
-When to use: users know roughly what they want and need to narrow a large catalog by attributes before picking one.
-Seen in: Salesforce list views with filter tabs, GitHub code/issue search with its left filter sidebar, Retool admin-panel search-and-table patterns.
-
-## Shape: Topic Shelf Browse
-Regions: search bar (top, secondary) / stacked horizontal shelves (full-width, each a named topic or collection) / each shelf scrolls independently left-right.
-The eye lands on: the first shelf's title and its lead card — curation, not a filter control, drives attention.
-When to use: the goal is inspiration or discovery across a broad catalog rather than narrowing toward a known target.
-Seen in: GitHub Explore (Trending repositories, Topics, Collections), Retool's template gallery landing page.
-
-## Shape: Faceted Table Browse
-Regions: saved-view tab strip (top, full-width) / facet and group controls (top-right, compact) / dense table body (full-width, below) with grouped row headers.
-The eye lands on: the active view's name and its row count in the tab strip, then the grouped section headers.
-When to use: the same underlying record set is browsed through several standing, shareable slices rather than one ad hoc filter.
-Seen in: Salesforce list views (Table/Split/Kanban toggle on one saved view), Zendesk ticket views grouped and ordered by field.
-
-## Shape: Gallery Card Browse
-Regions: toolbar (top, thin) / uniform card grid (full-width, cover-forward cards with a small property strip beneath each) / no persistent side rail.
-The eye lands on: the cover or lead property of the first card, not on chrome or filters.
-When to use: the records are visually distinguishable (people, assets, campaigns) and recognition beats reading fields.
-Seen in: Notion gallery view, Airtable's gallery-style interface layouts.
-
-## Shape: Command-First Browse
-Regions: a single centered search/command input (top, dominant) that expands into a ranked result list beneath it as the user types / no visible content before a query.
-The eye lands on: the input caret, then the top-ranked result as it appears.
-When to use: the catalog is too large or too varied to shelf or facet usefully, and users already have a query in mind.
-Seen in: GitHub's global search entry point, Linear's Cmd+K command menu used as a navigation-and-discovery surface.

package/data/harnesses/apollo/skills/design/data/blueprints/creation-flow.md

@@ -1,38 +0,0 @@
----
-id: creation-flow
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Stripe Connect onboarding, Linear issue creation, GitHub new-repository page, Retool App IDE, Airtable Interface Designer, wizard-pattern references"
-license: open
----
-Composition shapes for the creation-flow archetype — how a new object enters the system. The object's field count, orderedness, and context-sensitivity pick the shape.
-
-## Shape: Linear Stepper Wizard
-Regions: step rail (left or top, numbered, shows progress and lets users jump to completed steps) / one focused form panel per step (center, only the current step's fields are visible) / persistent progress indicator.
-The eye lands on: the current step's label, highlighted in the rail.
-When to use: creation requires many required fields best collected in a specific order, especially with validation or document upload between groups.
-Seen in: Stripe's hosted/embedded Connect account onboarding, generic SaaS setup wizards built around a stepper.
-
-## Shape: Slide-Over Quick Create
-Regions: a right-hand panel or modal (slides over the current screen, ~⅓–½ width) capturing a minimal field set / the underlying list or board stays visible and dimmed behind it.
-The eye lands on: the title/name field, auto-focused at the top of the slide-over.
-When to use: the object being created is simple enough not to need its own page, and preserving the user's current context matters more than a guided sequence.
-Seen in: Linear's issue-creation modal (triggered by `C` or `Cmd+K`, preserves a draft if dismissed).
-
-## Shape: Single-Page Form
-Regions: one dedicated page (full-width, no steps) with fields grouped into clearly labeled sections top to bottom / primary submit action at the bottom of the page.
-The eye lands on: the first required field at the top of the page (commonly a name field).
-When to use: the object has a small, fixed set of fields that don't benefit from being split across steps.
-Seen in: GitHub's "Create a new repository" page (name, description, visibility, template, initialization options all on one page).
-
-## Shape: Builder Canvas Creation
-Regions: component/element palette (left, narrow) / live authoring canvas (center, widest, shows the artifact being built and previewed simultaneously) / property inspector (right, contextual to whatever is selected).
-The eye lands on: whatever element on the canvas was most recently added or selected.
-When to use: the thing being created is itself a visual composition (an app, a page, an interface) rather than a record with fixed fields.
-Seen in: Retool's App IDE; Airtable's Interface Designer when building a new interface from scratch.
-
-## Shape: Guided Checklist Launcher
-Regions: a persistent checklist/progress tracker (top or side, shows completion percentage) / each checklist item expands into its own focused step or opens a separate flow / dismissible and resumable at any time.
-The eye lands on: the next incomplete checklist item, usually highlighted or bolded.
-When to use: setup spans many optional or asynchronous sub-tasks (some requiring external verification) that shouldn't block each other.
-Seen in: Stripe's embedded onboarding requirements flow, generic SaaS account-setup checklists.

package/data/harnesses/apollo/skills/design/data/blueprints/dashboard.md

@@ -1,38 +0,0 @@
----
-id: dashboard
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Stripe Dashboard home, Datadog dashboards and Dependency Map Navigator, Airtable Interface Designer, network-operations-center layout conventions, BI single-metric report layouts"
-license: open
----
-Composition shapes for the dashboard archetype — many signals summarized for scan or narrative. Which shape fits follows from whether the audience scans for anomalies or reads for a story.
-
-## Shape: KPI Strip + Chart Grid
-Regions: KPI strip (full-width, top, 4–6 tiles each with a value, delta, and inline sparkline) / flexible chart-and-table grid beneath, arranged in a 12-column layout.
-The eye lands on: the single largest number in the leftmost KPI tile.
-When to use: a general operator or executive audience needs the headline health of the business before anything else.
-Seen in: Stripe Dashboard's home page ("Your overview" widgets).
-
-## Shape: Dense Monitoring Grid
-Regions: named tabs (top, grouping widgets into sections) / a 12-column responsive grid packed edge-to-edge with many small, same-scale widgets (graphs, single-value tiles, status lists).
-The eye lands on: whichever widget is currently in an alert/error color state, not a fixed position.
-When to use: the goal is at-a-glance anomaly-spotting across many signals at once, not narrative or storytelling.
-Seen in: Datadog dashboards in high-density mode.
-
-## Shape: Freeform Canvas Dashboard
-Regions: an unconstrained drag-anywhere canvas mixing number tiles, charts, filtered record lists, and text blocks, each element independently sourced from a different underlying table.
-The eye lands on: whichever element the dashboard's author placed largest or first — no default focal convention.
-When to use: the dashboard's authors need full control over juxtaposing heterogeneous content (not just uniform charts) for a specific audience.
-Seen in: Airtable's Interface Designer dashboard layout.
-
-## Shape: Command-Center Split
-Regions: relationship/topology map or geographic overview (left or center, dominant, ~⅔) / live list or table of affected entities (right, ~⅓, sorted by severity, updates in real time).
-The eye lands on: whatever node or row is currently flagged in an alert color.
-When to use: operators must go from "something is wrong somewhere" to "which specific thing" without leaving one screen.
-Seen in: Datadog's Dependency Map Navigator; the video-wall convention of a dominant overview display paired with secondary alert panels used in network operations centers.
-
-## Shape: Narrative Single-Column Report
-Regions: one hero chart or metric (top, full-width) / supporting breakdown tables and secondary charts stacked below it in reading order / minimal or no side chrome.
-The eye lands on: the hero chart's headline trend line.
-When to use: the dashboard is meant to be read top-to-bottom like a report, telling one story, rather than scanned for many independent signals.
-Seen in: single-metric deep-dive report layouts common to BI tools built around one hero visualization followed by supporting cuts of the same data.

package/data/harnesses/apollo/skills/design/data/blueprints/grid.md

@@ -1,38 +0,0 @@
----
-id: grid
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Airtable grid view and grouped views, Notion table side peek, Retool App IDE and admin templates, spreadsheet-style admin tables"
-license: open
----
-Composition shapes for the grid archetype — many records edited or scanned across many fields at once, spreadsheet-fashion.
-
-## Shape: Frozen-Header Spreadsheet
-Regions: toolbar (top, view switch / row-height / filter controls) / grid body (full-width, first column(s) frozen while scrolling horizontally) / add-row affordance pinned to the bottom edge.
-The eye lands on: the frozen leftmost column, which anchors every row as the grid scrolls.
-When to use: users need to scan and bulk-edit many records across many fields the way they would in a spreadsheet.
-Seen in: Airtable grid view, Google-Sheets-style admin data tables.
-
-## Shape: Grid + Side Peek
-Regions: grid (majority of width, ~70–80%) / record detail panel (right, slides in on row selection, ~20–30%, doesn't navigate away from the grid).
-The eye lands on: the selected row's highlighted state in the grid, then the panel that opens beside it.
-When to use: editing one record's full detail is common but shouldn't cost the user their place in the larger table.
-Seen in: Airtable's expand-record-from-grid interaction, Notion's table view opening records in a side peek.
-
-## Shape: Grouped Grid with Subtotals
-Regions: grid body (full-width) organized into collapsible group bands, each with a header row carrying aggregate stats (count, sum, average) for that group.
-The eye lands on: the group header's aggregate figure, before any individual row.
-When to use: the grid's job is roll-up reporting on structured data, not just record-by-record editing.
-Seen in: Airtable's grouped grid view with per-group summary bars.
-
-## Shape: Builder Canvas Grid
-Regions: component palette (left, narrow, categorized list) / authoring canvas (center, widest, a 12-column grid used to place UI components rather than data rows) / inspector (right, contextual to the selected component).
-The eye lands on: the component currently selected on the canvas, highlighted against the grid.
-When to use: the "grid" is the structural device for assembling an interface or app, not for displaying records.
-Seen in: Retool's App IDE (canvas + component tree + Inspector panel).
-
-## Shape: Bulk-Action Grid
-Regions: search/filter bar (top) / grid with a persistent selection checkbox column (left edge) / sticky bulk-action toolbar that appears above the grid only once rows are selected.
-The eye lands on: the selection-count indicator in the bulk-action toolbar once it appears.
-When to use: the primary job is applying one action to many rows at once (delete, export, reassign), not editing cells individually.
-Seen in: Retool admin-panel table/search/form templates built for internal operators.

package/data/harnesses/apollo/skills/design/data/blueprints/queue.md

@@ -1,38 +0,0 @@
----
-id: queue
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Zendesk Agent Workspace, Salesforce Split View, Intercom inbox, Superhuman Split Inbox, Gmail preview pane, Jira-style backlog tables"
-license: open
----
-Composition shapes for the queue archetype — prioritized, claimable work processed toward empty. The list order is the product; view-types are projections.
-
-## Shape: Split Triage
-Regions: item list (left, ~⅓, one row per item, unread/priority state visible) / reading pane (right, ~⅔, shows the selected item in full) / action bar pinned to the reading pane's top edge.
-The eye lands on: the subject or title of the item open in the reading pane.
-When to use: operators process items one at a time but need the surrounding list visible to keep their place and jump ahead.
-Seen in: Gmail's preview-pane layout, Salesforce Split View, Intercom's conversation table with a preview panel.
-
-## Shape: Three-Column Context Triage
-Regions: ticket properties (left, narrow, editable fields) / conversation thread (center, widest, scrolls independently) / context panel (right, collapsible, customer/account data pulled from other systems).
-The eye lands on: the newest message in the center conversation thread.
-When to use: resolving one item requires both editing structured fields and reading unstructured context side by side.
-Seen in: Zendesk Agent Workspace's ticket interface.
-
-## Shape: Card-Stack Triage
-Regions: a single focal card (center, dominant, full item detail) with decision controls (approve/reject/skip) directly beneath it / no persistent list visible at all.
-The eye lands on: the one card currently in front of the operator.
-When to use: throughput and low cognitive load matter more than seeing what's next or re-ordering the queue.
-Seen in: moderation/review-queue patterns built around one-decision-at-a-time keyboard flows (the pattern Superhuman's and Zendesk's triage conventions both borrow from).
-
-## Shape: Grouped Table Queue
-Regions: standing view tabs (top, each a saved filter) / dense table (full-width, grouped by a status or priority field with collapsible group headers) / row click opens detail rather than a separate pane.
-The eye lands on: the group header counts, which signal where backlog is piling up.
-When to use: triage is about prioritizing across the whole backlog first, and deep work on one item happens after selection, not alongside it.
-Seen in: Zendesk's saved Views grouped and ordered by field, Jira-style backlog triage tables.
-
-## Shape: Zero-Chrome Queue
-Regions: a single wide column (full-width, no folders/menus/sidebar) listing items as compact single-line rows / a shortcuts overlay appears on demand rather than living in permanent chrome.
-The eye lands on: the top unprocessed row.
-When to use: expert operators triage at very high volume and any persistent chrome would slow them down.
-Seen in: Superhuman's Split Inbox list view.

package/data/harnesses/apollo/skills/design/data/blueprints/record-detail.md

@@ -1,38 +0,0 @@
----
-id: record-detail
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from Salesforce Lightning record pages, HubSpot record layout, Stripe customer detail, GitHub pull-request Files changed, Datadog Service Page"
-license: open
----
-Composition shapes for the record-detail archetype — one entity, its fields, its history, and its relationships on a single page.
-
-## Shape: Highlights + Related Tabs
-Regions: highlights band (top, full-width, up to ~7 key fields drawn from a compact layout) / horizontal tab strip (below highlights) switching between Related, Details, and Activity panels beneath.
-The eye lands on: the first field in the highlights band (typically the record's name/status).
-When to use: one record has many categories of related information that don't need to be visible simultaneously.
-Seen in: Salesforce Lightning record pages (highlights panel driven by compact layout + related-list cards).
-
-## Shape: Three-Column CRM Record
-Regions: property sidebar (left, ~25%, "About" fields) / activity timeline (center, ~50%, chronological log) / associated-records rail (right, ~25%, previews of linked deals/tickets/companies).
-The eye lands on: the most recent entry at the top of the center timeline.
-When to use: the record's story (what happened, in order) matters as much as its current field values or its relationships.
-Seen in: HubSpot's contact/company/deal record layout.
-
-## Shape: Hero Header + Tab Strip
-Regions: hero header (top, full-width, entity name plus top-line stats) / horizontal tab strip immediately below (Payments / Subscriptions / Invoices / Events) / one table per tab filling the rest of the page.
-The eye lands on: the top-line stat in the hero header (balance, lifetime value, status).
-When to use: one entity has several large, independently-scrollable tables of history that shouldn't compete for space at once.
-Seen in: Stripe's customer detail page.
-
-## Shape: Conversation + Docked Panels
-Regions: resizable file/change tree (left, collapsible) / conversation or diff thread (center, dominant, scrolls independently) / docked overview and comments panels (right, toggled on demand, don't require navigating away).
-The eye lands on: the active file or comment thread being discussed in the center pane.
-When to use: reviewing a change requires holding structure (what changed), discussion (what people said), and description (why) in view together.
-Seen in: GitHub's redesigned pull request "Files changed" page.
-
-## Shape: Dependency-Map Record
-Regions: relationship graph/map (left or center, dominant canvas showing the entity's upstream/downstream connections) / metrics table (docked right or bottom, request/error/latency figures per connection).
-The eye lands on: the node representing the record itself, at the center of its dependency graph.
-When to use: the entity's identity is defined by its relationships to other entities, and those relationships are the diagnostic surface.
-Seen in: Datadog's Service Page (dependency map paired with a request/error-rate/latency table).

package/data/harnesses/apollo/skills/design/data/blueprints/settings.md

@@ -1,38 +0,0 @@
----
-id: settings
-class: d3
-sourced: 2026-07-12
-source: "design-skill-phase1 D3 sweep — distilled from GitHub repository settings, Slack admin console, Stripe Dashboard settings, Salesforce Setup Quick Find, common SaaS account-settings patterns"
-license: open
----
-Composition shapes for the settings archetype — configuration surfaces organized by scope, subject, and risk. The size and depth of the settings surface picks the shape.
-
-## Shape: Left Category Nav + Detail Pane
-Regions: left navigation (fixed width, expandable category tree) / detail pane (remaining width, shows the form or table for the selected category only).
-The eye lands on: the highlighted item in the left nav, then the pane's section heading.
-When to use: settings span many unrelated categories that users navigate between rather than read straight through.
-Seen in: GitHub repository settings, Slack's admin console left-nav category tree.
-
-## Shape: Top Tab Strip Sections
-Regions: horizontal tab strip (top, full-width, a handful of top-level categories) / one scrollable panel per tab filling the rest of the page.
-The eye lands on: the active tab label.
-When to use: the number of top-level categories is small enough to stay visible at once without a side nav's real estate cost.
-Seen in: Stripe Dashboard settings, split into Personal / Account / Product tabs.
-
-## Shape: Search-Driven Settings
-Regions: a quick-find search box (top, prominent) over an otherwise large, unbrowsed index of setting pages / results filter the index live as the user types.
-The eye lands on: the search box itself before any content.
-When to use: the settings surface is too large or too deep to browse by category reliably, and users usually know the setting's name.
-Seen in: Salesforce's Setup home with Quick Find search over the full Setup/Object Manager index.
-
-## Shape: Long Scrolling Anchored Page
-Regions: a single continuous page (full-width, no separate nav pane or tabs) with settings grouped into vertically stacked sections / optional anchor links jump to a section.
-The eye lands on: whichever section heading is nearest the top of the current scroll position.
-When to use: the total settings surface is modest enough that scrolling beats clicking between categories.
-Seen in: common single-page "Account settings" patterns across SaaS admin surfaces (the pattern GitHub and Stripe both fall back to for smaller settings areas nested inside their larger nav/tab shells).
-
-## Shape: Master-Detail Settings List
-Regions: a table of configuration records (full-width or left-majority — API keys, webhooks, members, roles) with an "add" action above it / clicking a row opens that record's own edit form, inline or in a panel.
-The eye lands on: the most recently created or most active row in the table.
-When to use: the "setting" is really a collection of independent records (keys, integrations, members) rather than a single configuration object.
-Seen in: Stripe's API keys and webhooks pages, GitHub's collaborators and webhooks settings pages.

package/data/harnesses/apollo/skills/design/data/charts/census.csv

@@ -1,58 +0,0 @@
-id,family,min_measures,max_measures,min_dims,max_dims,requires_flags,excludes_flags,viewport_min,notes
-bar,bar,1,1,1,1,,,mobile,zero-anchored value axis; one value per category; comfort cap 12 categories (K2)
-grouped-bar,bar,1,1,2,2,,,tablet,series cap 4 (K7); cross-group comparison of non-adjacent bars is hard
-stacked-bar,bar,1,1,2,2,parts-form-whole,negative-values,mobile,additive parts of one total; totals cap 10 (K4); middle segments lack a shared baseline
-diverging-bar,bar,1,1,1,2,negative-values,,mobile,meaningful zero or midpoint; Likert and population pyramid fold here
-lollipop,bar,1,1,1,1,,,mobile,less ink than a bar; right when values are large and similar
-dot-plot,bar,1,2,1,1,,mixed-units,mobile,common scale required; the no-zero-baseline escape
-dumbbell,bar,2,2,1,1,,mixed-units,mobile,exactly two points per category; start and end must share a unit
-pictogram,bar,1,1,1,1,whole-units,negative-values,tablet,one icon equals k units; stated unit scale; decorative
-line-basic,line,1,1,1,1,temporal|ordered-progression,,mobile,one series over ordered axis
-line-multi,line,1,1,2,2,temporal|ordered-progression,,mobile,series cap 6 (K3); beyond cap facet into small multiples
-line-with-target,line,2,2,1,1,temporal|ordered-progression|target-exists,mixed-units,mobile,series + target band
-area,line,1,1,1,1,temporal,negative-values|irregular-temporal,mobile,zero baseline; magnitude emphasis
-stacked-area,line,1,1,2,2,temporal|parts-form-whole,negative-values|irregular-temporal,tablet,additive parts over time; middle-layer trends unreadable
-streamgraph,line,1,1,2,2,temporal,negative-values|irregular-temporal,desktop,pattern only; wants many smooth series; no precise reading
-slope,line,1,1,2,2,temporal|ordered-progression,,mobile,exactly 2 or 3 x positions; rank-change emphasis
-bump,line,1,1,2,2,temporal|ordered-progression,,tablet,plots rank not value; series cap 12
-sparkline,line,1,1,1,1,temporal,,mobile,inline miniature; needs an adjacent number for scale
-pie,part-to-whole,1,1,1,1,parts-form-whole,temporal|negative-values,desktop,max 6 slices
-waffle,part-to-whole,1,1,1,1,parts-form-whole,negative-values,tablet,10x10 grid (K8); whole-cell rounding drops sub-1% parts
-treemap,part-to-whole,1,1,1,2,parts-form-whole,negative-values,tablet,children sum to parents; a flat one-level list degenerates fine
-sunburst,part-to-whole,1,1,0,2,tree|parts-form-whole,negative-values,desktop,hierarchy on concentric rings; outer-ring distortion caveat
-marimekko,part-to-whole,1,2,2,2,parts-form-whole,negative-values|mixed-units,desktop,two area dimensions; expert audiences
-funnel,part-to-whole,1,1,1,1,ordered-progression,negative-values,mobile,genuine ordered pipeline only; typically monotone decreasing
-histogram,distribution,1,1,0,1,raw-observations,,mobile,bins derived not supplied; never category-value pairs
-density,distribution,1,1,0,1,raw-observations,,tablet,KDE; bandwidth can oversmooth; needs large n
-box-plot,distribution,1,1,0,1,raw-observations,,mobile,five-number summary; hides multimodality
-violin,distribution,1,1,0,1,raw-observations,,tablet,mirrored KDE; needs enough n per group
-strip-plot,distribution,1,1,0,1,raw-observations,,mobile,every point drawn; jitter for ties; moderate n
-scatter,correlation,2,2,0,1,,,mobile,point-level rows; overplotting escape to hexbin at scale (K5)
-bubble,correlation,3,3,0,1,,,tablet,size maps to area never radius; size measure non-negative
-hexbin,correlation,2,2,0,1,raw-observations,,tablet,the overplotting escape; binned 2D density
-splom,correlation,3,8,0,1,raw-observations,,desktop,pairwise panels grow O(k^2); variable cap 8 (K9)
-parallel-coordinates,correlation,3,12,0,1,,,desktop,axes normalized individually; axis order changes visible structure
-radar,correlation,3,8,0,1,,mixed-units,tablet,shared or normalized axes; spurious area reading; entity cap 3
-ordered-bar,ranking,1,1,1,1,,,mobile,sorted by value not label; inherits bar constraints (K2)
-pareto,ranking,1,1,1,1,parts-form-whole,negative-values,desktop,descending bars + cumulative percent line; additive counts only
-sankey,flow,1,1,2,2,edges|ordered-progression,negative-values,desktop,conservation reads best; no cycles; stage-ordered nodes
-chord,flow,1,1,2,2,edges|matrix,negative-values,desktop,pairwise flows; dense matrices become ribbon spaghetti
-waterfall,flow,1,1,1,1,ordered-progression,,tablet,ordered decomposition start to end; signed contributions welcome
-network-graph,network,0,1,2,2,edges,,desktop,visible-node cap ~300 (K10); beyond that use an adjacency matrix
-tree-diagram,network,0,1,0,2,tree,,tablet,parent-child hierarchy; dendrogram adds merge height
-choropleth,geo,1,1,1,1,geo,no-color-encoding,tablet,rates never raw totals
-symbol-map,geo,1,1,1,1,geo,negative-values,tablet,totals; size to area; complement of choropleth
-flow-map,geo,0,1,2,2,geo,,desktop,origin-destination movement across geography
-point-map,geo,0,0,1,2,geo,,mobile,position only; no value encoding
-gantt,temporal-event,0,1,1,2,interval,,desktop,true start AND end per row
-event-timeline,temporal-event,0,0,1,2,temporal,,mobile,point events not intervals; labels not measures; optional track dimension
-calendar-heatmap,temporal-event,1,1,1,1,temporal,no-color-encoding,tablet,daily grain on a calendar grid; pattern over precision
-kpi-card,kpi,1,2,0,0,,,mobile,needs comparison context; delta or target welcome
-gauge,kpi,1,1,0,0,target-exists,,tablet,defined domain required; space-hungry; decorative
-progress-bar,kpi,1,1,0,0,target-exists,negative-values,mobile,one part-versus-whole fact; meaningless without a goal
-bullet,kpi,1,2,0,1,target-exists,mixed-units,mobile,target marker + qualitative bands; compact gauge replacement
-heatmap,matrix,1,1,2,2,,no-color-encoding,tablet,one value per cell; aggregate first; replaces spaghetti lines at high series counts
-table,table,0,99,0,99,,,mobile,universal fallback; exact values over comparison
-table-hybrid,table,1,99,0,99,,,tablet,data bars; cell heat; inline sparklines; the bridge leaf
-candlestick,specialized,4,4,1,1,temporal,irregular-temporal,desktop,strict OHLC tuple per period
-error-bands,specialized,1,3,0,2,uncertainty,,mobile,composite overlay; attaches to line or bar or scatter; never standalone

package/data/harnesses/apollo/skills/design/data/checklists/browse.md

@@ -1,21 +0,0 @@
----
-id: browse
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (page archetypes, table mechanics, state matrix chapters)"
-license: open
----
-Positive obligations for a browse surface — what every good instance has, each checkable from a rendered screen.
-
-- A visible result count adjacent to the search/filter controls that reflects the active filter set ("1–50 of 1,204").
-- Every active filter rendered as a dismissible chip or token near the results, so the current slice is readable at a glance.
-- A search or quick-filter input whose placeholder names what is searchable ("Search by name, email, or ID…").
-- Saved or standing views surfaced as named tabs or a view switcher, with the active view visibly marked.
-- Real pagination or an explicit total with position — never an unbounded, unlabeled scroll.
-- Sort state visible on the sorted column or control (direction indicator on the header).
-- Status values rendered as colored chips or badges, one distinct color per state, consistent everywhere the status appears.
-- Table columns aligned by type: numbers right-aligned in tabular figures, text left-aligned, dates in one consistent format.
-- Each result row or card leads with the record's human identity (name/title), not its internal ID.
-- Row or card hover affordance: a background shift, revealed actions, or both, on every result.
-- A designed zero-results state that names the active filters and offers a one-click clear-filters action.
-- A designed true-empty state (no records exist yet) distinct from zero-results, with a path to create or import.

package/data/harnesses/apollo/skills/design/data/checklists/creation-flow.md

@@ -1,20 +0,0 @@
----
-id: creation-flow
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (creation-path catalog, modes, state matrix chapters)"
-license: open
----
-Positive obligations for a creation-flow surface — what every good instance has, each checkable from a rendered screen.
-
-- The first input focused on entry (visible focus ring), with field order matching reading order.
-- Required and optional fields visibly distinguished — one convention, applied to every field.
-- A progress indicator whenever the flow has steps: current step named, completed steps visually distinct, completed steps re-enterable.
-- Fields grouped into labeled sections rather than one undifferentiated column.
-- Sensible defaults pre-filled wherever one exists (owner = current user, date = today, visible and editable).
-- Inline validation rendered beside the offending field, with a message that names the fix ("Must be a work email"), not just an error color.
-- The primary action labeled verb + object ("Create ticket", "Invite member") — never a bare "Submit".
-- A visible cancel or close path, with draft preservation signaled when the flow is dismissed mid-entry.
-- On failed submit, an error summary that names each problem and points (link or scroll) to its field.
-- Helper text under any field whose format or effect isn't self-evident.
-- Success hands the user the created object: navigation to it or a named link, with confirmation copy naming what was created.

package/data/harnesses/apollo/skills/design/data/checklists/dashboard.md

@@ -1,21 +0,0 @@
----
-id: dashboard
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (dashboards chapter: every tile is number + comparison + trend + state + door)"
-license: open
----
-Positive obligations for a dashboard surface — what every good instance has, each checkable from a rendered screen.
-
-- Every KPI tile carries all five parts: the number, a comparison (vs. prior period or target), a trend (sparkline or delta), a state (good/warn/bad treatment), and a door (a click-through to the detail behind it).
-- Numbers formatted for scanning: tabular figures, thousands separators, units or currency attached, consistent decimal places across tiles.
-- Deltas signed and colored by meaning — down can be green when down is good — never colored by direction alone.
-- One time-range control visible and visibly applied to every widget it scopes ("Last 30 days" readable on the surface).
-- Every chart titled with the measure and dimension in plain words ("Revenue by region"), not an internal metric name.
-- Chart axes labeled or self-evident, with an honest baseline on value axes.
-- A legend wherever more than one series shares a plot, with legend colors matching the marks.
-- Data freshness stamped somewhere fixed ("Updated 4 min ago" / "As of 09:00").
-- Any metric in a breach or alert state visibly different at a glance — the surface points the eye at what's wrong.
-- Widgets aligned to a shared grid with consistent gutters; region edges line up across the page.
-- Each widget owning a designed loading state (skeleton in the widget's own footprint) and a designed empty state naming what's missing.
-- Every table or list widget cut to a readable size with a door to the full view ("View all 214").

package/data/harnesses/apollo/skills/design/data/checklists/grid.md

@@ -1,21 +0,0 @@
----
-id: grid
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (table mechanics, container choice, state matrix chapters)"
-license: open
----
-Positive obligations for a grid surface — what every good instance has, each checkable from a rendered screen.
-
-- An identity column (or columns) frozen against horizontal scroll, anchoring every row.
-- Column headers sticky against vertical scroll, so field names never leave the screen.
-- Cell rendering differentiated by type: numbers right-aligned in tabular figures, dates in one format, enums as chips, booleans as checks — never everything as plain left-aligned text.
-- A selection checkbox column with a select-all control in the header.
-- A bulk-action bar that appears with a visible selection count once rows are selected, naming the actions it applies.
-- An add-record affordance pinned to a fixed location (bottom edge or toolbar), visible without scrolling.
-- Group headers carrying aggregates (count, sum, or average) whenever grouping is active.
-- A visible cell focus state distinct from row hover, so the editing target is unambiguous.
-- A density or row-height control in the toolbar.
-- The total record count visible somewhere fixed (toolbar or footer).
-- Inline save-state feedback on edited cells: saving, saved, or error, each visually distinct.
-- A designed empty state for a grid with no rows, with a create or import path — never a bare header row over whitespace.

package/data/harnesses/apollo/skills/design/data/checklists/queue.md

@@ -1,21 +0,0 @@
----
-id: queue
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (page archetypes, verbs, state matrix chapters)"
-license: open
----
-Positive obligations for a queue surface — what every good instance has, each checkable from a rendered screen.
-
-- The queue's ordering key (priority, age, SLA) readable from the first screen — the operator can say why the top item is on top.
-- Claim/ownership state on every item: an assignee avatar or name, or an explicit unclaimed marker.
-- An aging or SLA indicator per item (time in queue, due-in countdown) whose color shifts as the deadline degrades.
-- Visible keyboard affordances for advancing: shortcut hints on the primary actions or a reachable shortcuts overlay (J/K-style next/previous).
-- Item counts visible per view or group, so backlog size is readable without scrolling.
-- Unprocessed items visually distinct from processed ones (weight, dot, or background — more than color alone).
-- The selected item highlighted in the list while its detail is open, so the operator keeps their place.
-- The primary triage verbs (resolve, approve, reassign, escalate) reachable from the item without leaving the queue — a pinned action bar, not a buried menu.
-- Item status rendered as a colored chip, consistent with the same status colors used elsewhere in the product.
-- Priority or escalation markers visually ranked — urgent reads heavier than high, high heavier than normal.
-- A designed queue-cleared state (celebratory or calm, but authored) distinct from a zero-results filter state.
-- A designed degraded state when items fail to load, with a retry affordance.

package/data/harnesses/apollo/skills/design/data/checklists/record-detail.md

@@ -1,21 +0,0 @@
----
-id: record-detail
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (attributes/lifecycle/history, verbs, standard pages chapters)"
-license: open
----
-Positive obligations for a record-detail surface — what every good instance has, each checkable from a rendered screen.
-
-- The record's human identity (name/title) and its lifecycle status both visible in the header without scrolling.
-- A highlights band carrying the 3–7 most-referenced fields at the top of the page.
-- The primary verbs for the record's current state rendered as visible buttons in the header — the top actions are not buried in an overflow menu.
-- An activity or history timeline where every entry carries an actor and a timestamp.
-- Related records surfaced (rail, tabs, or cards) with a count per relationship type.
-- A tab strip or section navigation when content exceeds one screen, with the active section visibly marked.
-- Every field value paired with a visible label — no orphan values the reader must guess at.
-- Empty fields rendered as a designed "not set" affordance (muted dash or add prompt), never blank space.
-- Editable fields showing an edit affordance on hover or focus.
-- Timestamps rendered consistently, with relative age ("2h ago") where recency drives decisions.
-- The status chip using the same color and label the collection view uses for that state.
-- A breadcrumb or back affordance naming the collection this record came from.

package/data/harnesses/apollo/skills/design/data/checklists/settings.md

@@ -1,21 +0,0 @@
----
-id: settings
-class: e2
-sourced: 2026-07-12
-source: "derived from the D3 blueprint sweep + the b2b-ux-patterns distillation (settings chapter: scope → subject → risk)"
-license: open
----
-Positive obligations for a settings surface — what every good instance has, each checkable from a rendered screen.
-
-- The scope visibly labeled on every page: whether these settings apply to the person, the workspace, or the organization.
-- A navigation surface (category nav, tab strip, or quick-find) with the active category visibly marked.
-- Every setting carrying a label and a one-line description of its effect — the control alone never has to explain itself.
-- Current values readable without entering an edit mode.
-- Save semantics explicit: a save bar that enables on change, or per-control auto-save with a visible saved confirmation — one convention for the whole surface.
-- Toggle and radio states distinguishable by more than color alone (position, label, or icon).
-- Risky settings preceded by a consequence note ("Applies to all 34 members") before the control.
-- Destructive actions isolated in a visually distinct danger zone, each gated by a confirmation that requires intent (typing the name, not just OK).
-- Collection-type settings (API keys, webhooks, members, roles) rendered as a table with a labeled add action and per-row management.
-- Secrets shown masked, with reveal and copy affordances.
-- A quick-find search over settings when the category list exceeds one viewport.
-- Settings the viewer cannot change shown disabled with a note naming who can — not silently hidden.