@nurix/etna 0.19.49 → 0.19.51

package/data/harnesses/code/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/code/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/code/skills/design/data/chart-styling/Readme.md

@@ -1,33 +0,0 @@
----
-id: chart-styling-conventions
-class: a7
-sourced: 2026-07-12
-source: "Distilled from the A7 Phase-1 chart-styling sweep's cross-cutting tells (docs/research/design-skill-phase1/a7-chart-styling.md) — Datawrapper's gray-hierarchy and confetti-spaghetti posts, NYT/Economist chrome-restraint practice"
-license: open
-feel: "quiet chrome, loud data — the axis never competes with the series it's measuring"
----
-Landing page for the A7 chart-styling database — one entry per named chrome + ramp recipe under `data/chart-styling/<id>.md`. Every entry specs axis/gridline/tooltip/legend chrome plus the three data ramps (categorical, sequential, diverging), and **every value is a token-role reference** (`chart-1`…`chart-5`, `muted`, `muted-foreground`, `border`, `surface-overlay`, `surface-raised`, `card`, `popover`, `success`, `destructive`, `warning`, `foreground`) — an entry never carries a color literal. The active identity package resolves the actual OKLCH/hex values; these recipes only say which role plays which chrome or ramp job. Chart *form* selection (bar vs. line vs. scatter) is a separate decision layer (B1) upstream of this one — A7 is styling only.
-
-## Cross-cutting tells (apply across every recipe below)
-
-- **Rainbow categorical soup** — too many saturated hues in one legend reads as "confetti spaghetti" (Datawrapper's term). Prefer running a family of related series in shades of two or three hues over reaching for a fifth or sixth chart token.
-- **Heavy black axes** — keep axis lines thin-to-absent; let the gridline (or the label alone) carry structure instead of a bold ruled line.
-- **Gridlines darker than data** — the three-tier gray hierarchy is a hard rule, not a preference: gridline contrast < label contrast < title contrast, always. A gridline that out-contrasts a data stroke has failed — lighten the gridline token, never darken the data.
-
-## Index
-
-| id | register | when to use |
-| --- | --- | --- |
-| `econ-red-rule-horizontal` | editorial, print/slide | single-message hero charts, one accent rule, everything else recedes |
-| `nyt-ghost-grid-direct-label` | editorial, narrative | line/area charts where the series shape is the story; direct end-of-line labels |
-| `ft-vocabulary-ranked-muted` | editorial/financial | a family of related chart types in one story needing shared chrome |
-| `plot-currentcolor-inherit` | embedded/inline | charts dropped into prose or docs, inheriting the page's ink color |
-| `datawrapper-tiered-gray-hierarchy` | editorial default | general-purpose; the three-gray-tier ordering rule |
-| `grafana-dark-threshold-bands` | ops/monitoring | dark-first always-on dashboards; threshold bands carry the alert signal |
-| `datadog-classic-six-aligned` | ops/monitoring | multi-panel monitoring grids needing consistent series identity |
-| `carbon-accessible-alert-semantic` | enterprise/accessibility | dense dashboards under a WCAG contrast mandate |
-| `carbon-monochrome-sequential-trend` | analytics | single-metric trend/heatmap charts, one hue's lightness ramp |
-| `shadcn-composable-css-vars` | product analytics | modern Recharts-via-shadcn UI, chart-N vars feed chrome directly |
-| `material-rounded-explicit-label` | consumer analytics | Material-flavored product, never color-alone encoding |
-| `saas-gradient-glow-area` | growth/marketing | usage charts, upgrade nudges — warmth over analytical density |
-| `financial-diverging-threshold-overlay` | finance/ops | P&L, budget-vs-actual, SLA burn-down — zero-baseline deviation reads |

package/data/harnesses/code/skills/design/data/chart-styling/carbon-accessible-alert-semantic.md

@@ -1,19 +0,0 @@
----
-id: carbon-accessible-alert-semantic
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Carbon Design System's data-visualization color-palettes page and its accessibility Medium write-up — WCAG 3.5:1 categorical contrast, fixed alert semantics"
-license: open
-feel: "WCAG-contrast categorical rotation plus fixed alert semantics — red/orange/yellow/green always mean the same severity"
----
-Use for dense enterprise dashboards under an accessibility mandate. The categorical sequence is curated for maximum contrast between *neighbors*, not picked for hue variety — and alert colors are never repurposed for plain categorical use. Avoid a gradient standing in for a sequential ramp; use the dedicated sequential pair instead.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 11px, WCAG AA contrast minimum", ticks: minimal }
-gridlines: { direction: both, stroke: border, style: solid }
-tooltip: { surface: card, numerals: sans, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: destructive, mid: muted, positive: success }
-```

package/data/harnesses/code/skills/design/data/chart-styling/carbon-monochrome-sequential-trend.md

@@ -1,19 +0,0 @@
----
-id: carbon-monochrome-sequential-trend
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Carbon Design System's monochromatic-palette guidance for relationship/trend charts"
-license: open
-feel: "single-hue lightness ramp for one series over time — depth of one color doing the work, no categorical distraction"
----
-Use for single-metric trend charts, heatmap cells, or relationship charts where only magnitude matters. Avoid introducing a second hue even for a comparison band — step lightness/opacity of the same chart token instead of reaching for chart-2. Primarily a sequential recipe; the diverging slot below is rarely invoked in practice.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 10px sans", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: card, numerals: mono, border: border }
-legend: { position: none, style: swatch }
-categorical: [chart-1, muted, muted, muted, muted]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: muted, mid: border, positive: chart-1 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/datadog-classic-six-aligned.md

@@ -1,19 +0,0 @@
----
-id: datadog-classic-six-aligned
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Datadog's 'Selecting the right colors for your graphs' doc and effective-dashboards guidelines — Classic 6-color rotation, aligned x-axes"
-license: open
-feel: "six-color classic rotation with x-axes locked across every panel — the legend shows up only when there's room"
----
-Use for multi-panel monitoring grids where series identity must stay recognizable panel-to-panel. Keep a fixed categorical count before repeating (Datadog's own is 6; an identity package with 5 chart tokens should cycle back to chart-1 for the 6th series, not introduce a 6th ad hoc hue). Never let one panel show a legend while its row neighbor hides one — it breaks x-axis alignment.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 9-10px, aligned across all panels in a row", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: popover, numerals: mono, border: border }
-legend: { position: right, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: muted, to: chart-2 }
-diverging: { negative: chart-4, mid: muted, positive: chart-3 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/datawrapper-tiered-gray-hierarchy.md

@@ -1,19 +0,0 @@
----
-id: datawrapper-tiered-gray-hierarchy
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Datawrapper Academy's chart-customization articles and its 'colors for data vis style guides' post — the three-gray-tier rule"
-license: open
-feel: "three deliberate grays — gridline lightest, label mid, title darkest — hierarchy reads before you even look at the data"
----
-General-purpose editorial default. The reusable insight is the *order*, not any single value: gridline contrast < label contrast < title contrast, always. Hard rule baked in — a gridline must never out-contrast a data stroke; if it does, lighten the gridline token, don't darken the data.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 10px sans, mid gray tier", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: card, numerals: sans, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: chart-4, mid: muted, positive: chart-2 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/econ-red-rule-horizontal.md

@@ -1,19 +0,0 @@
----
-id: econ-red-rule-horizontal
-class: a7
-sourced: 2026-07-12
-source: "Distilled from The Economist's chart style guide PDF (v1.2) and Fountn's summary — horizontal-only gridlines, right-side labels, top accent rule"
-license: open
-feel: "one loud accent rule over quiet gray charts — one chart, one message, everything else recedes"
----
-Use for single-message editorial charts (reports, decks, one-pagers) where a single series or moment must land instantly. Light theme, low density, print/slide scale — the top rule is a masthead device, not a repeatable UI motif, so reserve it for hero charts, not dashboard grids.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 11px right-aligned y-axis, no vertical axis line drawn", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: card, numerals: sans, border: none }
-legend: { position: inline, style: line }
-categorical: [chart-1, muted, muted, muted, muted]
-sequential: { from: muted, to: chart-1 }
-diverging: { negative: chart-4, mid: muted, positive: chart-1 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/financial-diverging-threshold-overlay.md

@@ -1,19 +0,0 @@
----
-id: financial-diverging-threshold-overlay
-class: a7
-sourced: 2026-07-12
-source: "Distilled by combining FT's deviation-chart form (Visual Vocabulary), Grafana's threshold-band rendering, and Datadog's cool/warm diverging guidance for a finance/trading-ops use case"
-license: open
-feel: "diverging above/below-baseline color with a threshold-band overlay — reads deviation at a glance, dense enough for a trading-floor wall"
----
-Use for finance/ops hybrids: P&L, budget-vs-actual, SLA burn-down — anywhere a zero-baseline or target line matters more than the raw series. Tooltip numerals are always monospace/tabular so figures align column-to-column across rows; the baseline gridline is dashed and visually distinct from the regular gridline set.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 10px mono, tabular-nums", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: dashed }
-tooltip: { surface: popover, numerals: mono, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: muted, to: chart-2 }
-diverging: { negative: destructive, mid: border, positive: success }
-```

package/data/harnesses/code/skills/design/data/chart-styling/ft-vocabulary-ranked-muted.md

@@ -1,19 +0,0 @@
----
-id: ft-vocabulary-ranked-muted
-class: a7
-sourced: 2026-07-12
-source: "Distilled from FT's Visual Vocabulary poster/site (chart-doctor README, ft-interactive.github.io) — one shared chrome recipe across a chart family in a story"
-license: open
-feel: "consistent, muted chrome built to repeat across a whole family of ranking/deviation/correlation charts in one piece"
----
-Use when a single story needs several related chart types (ranking, deviation, correlation) to feel like one system rather than one-offs — the win is chrome consistency across the set, not any single chart's flourish. Works for both editorial and financial-story contexts.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 11px, left-aligned tick labels", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: card, numerals: mono, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: chart-4, mid: muted, positive: chart-2 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/grafana-dark-threshold-bands.md

@@ -1,19 +0,0 @@
----
-id: grafana-dark-threshold-bands
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Grafana's threshold-configuration docs and internal theme style guide — dark-first monitoring canvas, colored threshold bands/lines"
-license: open
-feel: "dark-first monitoring wall where colored threshold bands do the alerting instead of the gridlines"
----
-Use for always-on ops dashboards viewed for hours at a stretch. The default 3-step threshold model (calm base, escalation step, critical step) should carry the alert signal; gridlines stay dense but low-contrast on the dark surface so they never compete with a threshold color for attention.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 10px mono for numeric ticks", ticks: minimal }
-gridlines: { direction: both, stroke: border, style: dashed }
-tooltip: { surface: popover, numerals: mono, border: border }
-legend: { position: right, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: success, to: destructive }
-diverging: { negative: destructive, mid: warning, positive: success }
-```

package/data/harnesses/code/skills/design/data/chart-styling/material-rounded-explicit-label.md

@@ -1,19 +0,0 @@
----
-id: material-rounded-explicit-label
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Material Design's data-visualization accessibility blog post and its M2 data-visualization communication guidance — rounded bar terminals, never color-alone encoding"
-license: open
-feel: "rounded bar terminals and always-explicit labels — meaning never depends on color perception alone"
----
-Use for consumer-facing analytics in a Material-flavored product. Every legend swatch, axis, and mark gets a paired text label so meaning survives color-blindness or grayscale printing; series spacing runs tighter than a stock default for a friendlier, less clinical density. Good playful-SaaS anchor alongside the shadcn and gradient-area candidates.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 12px, always paired with a text label near the mark", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: card, numerals: sans, border: none }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: destructive, mid: muted, positive: success }
-```

package/data/harnesses/code/skills/design/data/chart-styling/nyt-ghost-grid-direct-label.md

@@ -1,19 +0,0 @@
----
-id: nyt-ghost-grid-direct-label
-class: a7
-sourced: 2026-07-12
-source: "Distilled from storytellingwithdata's NYT-graphics analysis and an NYT-in-Keynote design breakdown — near-invisible gridlines, direct end-of-line labeling"
-license: open
-feel: "chrome so quiet it disappears — labels sit at the line's end instead of a legend box"
----
-Use for narrative line/area charts where the story is the shape of the series, not the axis. Direct-label every series at its terminus rather than building a legend; keep at most two hero hues, everything else recedes to neutral so the reader never round-trips to a key.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 10-11px sans, no bold weight", ticks: minimal }
-gridlines: { direction: horizontal, stroke: border, style: solid }
-tooltip: { surface: popover, numerals: sans, border: none }
-legend: { position: inline, style: line }
-categorical: [chart-1, chart-2, muted, muted, muted]
-sequential: { from: muted, to: chart-2 }
-diverging: { negative: chart-4, mid: border, positive: chart-2 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/plot-currentcolor-inherit.md

@@ -1,19 +0,0 @@
----
-id: plot-currentcolor-inherit
-class: a7
-sourced: 2026-07-12
-source: "Distilled from Observable Plot's axis and grid mark docs — currentColor inheritance, 0.1 default gridline opacity, tabular-nums ticks"
-license: open
-feel: "chrome that vanishes into whatever text color already surrounds it — the leanest possible embedded-chart default"
----
-Use for charts embedded inline in prose, notebooks, or docs, where the chart should inherit the surrounding page's ink color rather than carry its own theme. The distinctive move: gridlines aren't a separate lighter token, they're the same ink at ~10% opacity — worth noting for identity packages that only expose discrete token roles rather than an opacity primitive.
-
-```yaml values
-axes: { stroke: foreground, labels: "foreground via currentColor inheritance, tabular-nums for quantitative ticks", ticks: on }
-gridlines: { direction: both, stroke: foreground, style: solid }
-tooltip: { surface: popover, numerals: mono, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: muted, to: chart-1 }
-diverging: { negative: chart-4, mid: border, positive: chart-2 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/saas-gradient-glow-area.md

@@ -1,19 +0,0 @@
----
-id: saas-gradient-glow-area
-class: a7
-sourced: 2026-07-12
-source: "Distilled from shadcn/ui chart composition patterns and Observable Plot's underused-options gradient-fill notes — a common modern growth-analytics convention"
-license: open
-feel: "soft gradient-filled area glowing under a bright line, floating rounded tooltip — approachable, marketing-adjacent SaaS analytics"
----
-Use for growth or marketing-facing surfaces (usage charts, upgrade nudges, onboarding stats) that want visual warmth over analytical density. Gridlines are minimal-to-none since the gradient fill itself supplies the visual weight; pair with an elevated surface token for the tooltip so it reads as floating, not flush.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 11px, ticks hidden except first/last", ticks: off }
-gridlines: { direction: none, stroke: border, style: solid }
-tooltip: { surface: surface-overlay, numerals: sans, border: none }
-legend: { position: inline, style: line }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: surface-raised, to: chart-1 }
-diverging: { negative: chart-4, mid: muted, positive: chart-1 }
-```

package/data/harnesses/code/skills/design/data/chart-styling/shadcn-composable-css-vars.md

@@ -1,19 +0,0 @@
----
-id: shadcn-composable-css-vars
-class: a7
-sourced: 2026-07-12
-source: "Distilled from shadcn/ui's chart and tooltip docs — `--chart-1`…`--chart-5` CSS-variable tokens feeding composable tooltip/legend primitives"
-license: open
-feel: "CSS-variable chart tokens wired straight into composable tooltip/legend parts — horizontal-only grid, no vertical clutter"
----
-Use for modern product-analytics UI built on Recharts-via-shadcn. Grid is horizontal-only with vertical lines switched off; tooltip and legend read color from the same chart-N variables as the marks themselves, so recoloring the identity package recolors the whole chart system at once, chrome included.
-
-```yaml values
-axes: { stroke: border, labels: "muted-foreground, 12px, tickLine off, ~10px tick margin", ticks: off }
-gridlines: { direction: horizontal, stroke: border, style: dashed }
-tooltip: { surface: popover, numerals: sans, border: border }
-legend: { position: top, style: swatch }
-categorical: [chart-1, chart-2, chart-3, chart-4, chart-5]
-sequential: { from: muted, to: chart-1 }
-diverging: { negative: chart-4, mid: border, positive: chart-1 }
-```

package/data/harnesses/code/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/code/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/code/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/code/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/code/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/code/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/code/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/code/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.