@nurix/etna 0.19.49 → 0.19.51

package/data/harnesses/code/skills/design/references/content.md

@@ -4,7 +4,7 @@ Author the demo data **before composing surfaces**. Data credibility is the sing
 
 ## From the corpus
 
-Load the chosen domain's corpus (`data/corpora/<domain>/`): `corpus.md` (vocabulary, number-shape recipes, the invariants block) plus `people.csv` and `companies.csv`.
+Fetch the chosen domain's corpus — `search_catalog` (kind `corpus`) to find it, `get_entry` to load it: the body (vocabulary, number-shape recipes, the invariants block) arrives with its `people` and `companies` rosters in one payload.
 
 - Names come from the corpus roster; emails derive from names; roles are domain-correct.
 - Activity strings use the corpus vocabulary — a CRM logs "Intro call with Elena — pricing discussion", never webhook noise.
@@ -14,15 +14,15 @@ Load the chosen domain's corpus (`data/corpora/<domain>/`): `corpus.md` (vocabul
 
 ## Voice
 
-Load the package-bound voice pack (`data/voices/<id>.md` — the package's §9 names it). All authored strings — buttons, empty states, errors, tooltips, confirmations — speak in that voice, with tone varying by situation per the pack's tone map.
+Fetch the package-bound voice pack — `get_entry` the voice the package's §9 names. All authored strings — buttons, empty states, errors, tooltips, confirmations — speak in that voice, with tone varying by situation per the pack's tone map.
 
 ## Chart choice
 
-Every data-bearing surface consults the chart-selection engine — **one graph question per consult**:
+Every data-bearing surface consults the chart-selection engine — **one graph question per consult**. The census rows the engine evaluates are fetched **once per session** via `get_entry("chart-census")`:
 
-1. Author the data signature (the judgment half): the question, measures, dimensions, semantic flags (temporal, parts-form-whole, target-exists, …), constraints. Decompose multi-question asks first.
+1. Author the data signature (the judgment half): the question, measures, dimensions, semantic flags (temporal, parts-form-whole, target-exists, …), constraints — plus the session's `census` rows. Decompose multi-question asks first.
 2. Run `node scripts/select-chart.mjs <signature.json>` and read the typed output: admissible set, eliminations with reason codes, ranking, recommendation, or a refusal code.
 3. **Honor refusals** — a refusal means the question isn't chartable as posed (often: it's a table). Never invent a measure to force a chart.
-4. Record the pick in one line in `decisions.md`. Taking a non-recommended admissible option needs a reason on that line; taking an eliminated option is out of contract.
+4. `record` the pick in one line. Taking a non-recommended admissible option needs a reason on that line; taking an eliminated option is out of contract.
 
 Chart *styling* is not this step's concern — the package's §8 and the chart-styling axis own it at composition.

package/data/harnesses/code/skills/design/references/existing-apps.md

@@ -4,7 +4,7 @@ The same machinery runs on existing UIs, under a preservation contract.
 
 ## Judge — a user-invoked service
 
-A critique of an existing UI against the brief, the project's `design.md`, the archetype checklists, and `taste.md`, producing a **severity-ranked (never scored) report**. Judge is a service the user asks for — never a self-check the skill runs on its own output. Read the actual rendered state (screenshots the user provides, or captures the user asks for); refuse to critique from source alone when the ask is "does it look right", and never imagine what unrendered code looks like. Each finding: severity, the on-screen element, what's wrong, the exact fix.
+A critique of an existing UI against the brief, the project's `design.md`, the archetype checklists, and the project's taste profile (`get_project`), producing a **severity-ranked (never scored) report**. Judge is a service the user asks for — never a self-check the skill runs on its own output. Read the actual rendered state (screenshots the user provides, or captures the user asks for); refuse to critique from source alone when the ask is "does it look right", and never imagine what unrendered code looks like. Each finding: severity, the on-screen element, what's wrong, the exact fix.
 
 ## Improve — judge + the fix pass
 

package/data/harnesses/code/skills/design/references/intake.md

@@ -2,15 +2,19 @@
 
 Read the brief and choose from the menus: one identity package (the design.md system), any axis overrides the brief demands, layout blueprints per surface, and the product domain for content. Every choice is one recorded line.
 
+**Returning project first.** If the repo carries a `projectId`, open with `get_project`: the personality, the taste profile, and the recent decision lines are the session's context — then run the drift check (compare the repo's `design.md` against the server canonical; on mismatch, tell the user which is newer and ask). A returning project re-enters the steps with its identity already chosen; the rules below are for first intake.
+
 ## Rules
 
 - **The brief's own words outrank any database default.** "Beautiful" means the ceiling, not the safe row.
 - **Adjectives become referents.** When the brief speaks in adjectives ("premium", "editorial"), name the 2–3 real products the brief is pointing at and pick the package whose recorded identity sits in that class — unnamed ambition becomes beige.
-- **The index is a retrieval aid, never a router.** Load `design-md/index.csv` whole (it is small), shortlist 2–3 rows by segment/keyword resemblance, read only the shortlisted files' §1 Visual Theme, then choose reading the brief. After the choice, the chosen package's **full design.md enters context and stays in view through step 4**; unchosen candidates are dropped.
-- **The escape hatch fires mechanically.** No index hit, plus a recorded one-line reason why the closest package fails → author a one-off project design.md in the package schema (`design-md/SCHEMA.md`), `tier: project`, validator-checked like any library entry. This path is expected to be common; flag the file as a curation candidate for the roster.
-- **Set the primitives switch** — write one `primitives: nurix | native` line into the project's `design.md`. Default by the probe: the project resolves `@nurix/components` (check package.json / lockfile / node_modules) → `nurix`; otherwise — existing apps, foreign stacks, no library access — → `native`. Set once here; nothing downstream re-asks. Also write `source-package: <id>@<date>` (or `authored` for escape-hatch one-offs).
+- **Search is a retrieval aid, never a router.** `search_catalog` (kind `package`) with the brief's segment/keyword resemblance; shortlist 2–3 results by their head metadata (feel, reads-as, keywords), then choose reading the brief. After the choice, `get_entry` **once**: the chosen package's full design.md enters context and **stays in view through step 4**; unchosen candidates are never fetched.
+- **The escape hatch fires mechanically.** No catalog hit, plus a recorded one-line reason why the closest package fails → author a one-off project design.md in the package schema, `tier: project` — the validator is the schema authority and checks it like any library entry. This path is expected to be common; flag the file as a curation candidate for the roster.
+- **Register the project.** First intake ends with `register_project` — name, the consumer's container if it has one, and `fork: { slug, version }` pinning the chosen package as it was chosen (a copy, never a live read: later catalog edits cannot change a running project's identity). Commit the returned `projectId` to the repo. Escape-hatch one-offs register without a fork; the authored design.md is pushed via `record`.
+- **Axis overrides fetch the same way** — a recorded override names its axis entry; `get_entry` (kind `axis`) fetches exactly that entry.
+- **Set the primitives switch** — write one `primitives: nurix | native` line into the project's `design.md`. Default by the probe: the project resolves `@nurix/components` (check package.json / lockfile / node_modules) → `nurix`; otherwise — existing apps, foreign stacks, no library access — → `native`. Set once here; nothing downstream re-asks. Also write `source-package: <slug>@<version>` (or `authored` for escape-hatch one-offs).
 - **Write or update `product.md`**: users and their jobs, roles/permissions, action frequency, risk level, accessibility commitments, brand anti-references. Package choice, UX decisions, motion intensity, and demo data all cite it.
-- **Consult `taste.md`** — its feel/avoid lines bias every choice; user reactions to shipped output update it in place. Missing file = no bias, never a block.
+- **The taste profile biases every choice** — `get_project` returns it (per-dimension feel/avoid lines); user reactions to shipped output update it via `record`. No profile yet = no bias, never a block.
 - **Stated-choice awareness:** if prior package picks are visible in the workspace, name them and say in one line why this pick repeats or differs — awareness, never forced rotation.
 - **Questions go to the user only when the answer changes the design** (theme, audience, density); everything else is inferred and marked inferred.
 
@@ -26,11 +30,11 @@ Step 1 ends with a preview block:
 - surface map with archetypes
 - planned deviations
 
-When a user is present, pause here **once** for confirm-or-redirect — a wrong pick costs one message now instead of a full build. Autonomous runs proceed. Either way the block becomes the durable header of this run's dated section in `decisions.md`.
+When a user is present, pause here **once** for confirm-or-redirect — a wrong pick costs one message now instead of a full build. Autonomous runs proceed. Either way the block goes to project memory — `record` it as decision lines heading this run's choices.
 
 ## Outputs
 
 - `design.md` (project fork: chosen package + switch line + provenance + brief bindings; deviations accrue as they are recorded)
-- `product.md` written/updated; `taste.md` consulted
-- the preview block, appended to `decisions.md`
+- `product.md` written/updated
+- the project registered (or resumed) — `projectId` in the repo, the identity pin and the preview block recorded
 - the chosen package's full design.md held in context

package/data/harnesses/code/skills/design/references/object-pass.md

@@ -15,7 +15,7 @@ Derive the object model and surface map using the UX-pattern decision layer (`re
 11. `state-matrix` — loading, the three empties (first-use, no-results, cleared), degraded, stale — per surface
 12. `standard-pages` / `ai-layer` / `dashboards` / `settings` — when the brief has them
 
-Each pass file carries its rule as prose plus a machine-readable decision table; **follow the table's answer**. Disagreement is legitimate craft only when recorded — one line in `decisions.md` naming the pass, the table's answer, yours, and why. An unrecorded divergence is the violation.
+Each pass file carries its rule as prose; the current machine-readable decision table is the pass's catalog entry — `get_entry` the pass's ux-pass id when the step-2 decision needs it (curation edits the tables between skill releases; the served table is the authority) — and **follow the table's answer**. Disagreement is legitimate craft only when recorded — one `record` line naming the pass, the table's answer, yours, and why. An unrecorded divergence is the violation.
 
 When a pass fires a clarification code (an input the table needs that the brief doesn't give), resolve it: infer-and-mark when the answer doesn't change the design, ask when it does.
 

package/data/harnesses/code/skills/design/references/ship-gate.md

@@ -1,6 +1,6 @@
 # Step 5 — The ship gate
 
-The project ships with its four project-local artifacts — `design.md` (the resolved fork, with provenance line, brief bindings, recorded deviations), `product.md`, `taste.md`, and `decisions.md`. The gate has two tiers, both objective: this is the only runtime check the skill performs, permitted precisely because it is automated and needs no judgment. Nothing here grades taste — anything that needs grading was the build-time harness's burden, not the run's.
+The project ships with its project-local artifacts — `design.md` (the resolved fork, with provenance line, brief bindings, recorded deviations), its derived `design.tokens.css`, and `product.md` — and its memory server-side. The gate has two tiers, both objective: this is the only runtime check the skill performs, permitted precisely because it is automated and needs no judgment. Nothing here grades taste — anything that needs grading was the build-time harness's burden, not the run's.
 
 ## Tier 1 — fails closed
 
@@ -22,8 +22,8 @@ A Tier-1 failure blocks the ship; fix and re-run. Binary phrasing is the contrac
 
 ## Tier 2 — flags, never gates
 
-Sweep `data/tells.csv` (the operator tell list) plus the motion tells (`transition: all`; `ease-in` on an entrance; animation attached to a keyboard-triggered action). Flags cannot fail the build and trigger no in-run judging: each is **fixed or dismissed with one recorded line** in `decisions.md`, and every flag appears in the ship report for the human's eyes — numbers point eyes; they do not replace them. The validator may run this sweep warn-only after compose-step edits; nothing new ever fails the build mid-composition.
+Sweep the operator tell list — fetched via `get_entry("tells")`, at this step only — plus the motion tells (`transition: all`; `ease-in` on an entrance; animation attached to a keyboard-triggered action). Flags cannot fail the build and trigger no in-run judging: each is **fixed or dismissed with one recorded line** through `record`, and every flag appears in the ship report for the human's eyes — numbers point eyes; they do not replace them. The validator may run this sweep warn-only after compose-step edits; nothing new ever fails the build mid-composition.
 
 ## The ship report
 
-Close the run with a compact report: surfaces shipped, the recorded choices (from the run's `decisions.md` section), Tier-1 results, every Tier-2 flag with its disposition, and the validator's warn list. No scores, no self-grades.
+Close the run with a compact report: surfaces shipped, the recorded choices, Tier-1 results, every Tier-2 flag with its disposition, and the validator's warn list. No scores, no self-grades. Write it to memory — `record` with `report: { kind: "gate", summary }` — and, if the run's surviving edits changed the project's `design.md`, push the new text in the same `record` so the server canonical stays current.

package/data/harnesses/code/skills/design/scripts/select-chart.mjs

@@ -2,8 +2,10 @@
 //
 // One graph question per call. The model authors the data-signature JSON (the judgment
 // half); this script computes elimination, scoring, ranking, and refusal (the mechanical
-// half) over the chart-leaf census at ../data/charts/census.csv. Deterministic: same
-// signature in, same output out. No network, stdlib only.
+// half) over the chart-leaf census rows the caller supplies — fetched once per session
+// via the design-mcp entry "chart-census" and passed in the signature's `census` array
+// (engines local, knowledge served). Deterministic: same signature + census in, same
+// output out. No network, stdlib only.
 //
 // OUTPUT CONTRACT (docs/features/design-skill/07-evaluation-integrity.md §B1 — exact):
 //   {
@@ -277,9 +279,27 @@ export function parseCensusCsv(text) {
   });
 }
 
-export function loadDefaultCensus() {
-  const censusPath = path.join(path.dirname(fileURLToPath(import.meta.url)), '..', 'data', 'charts', 'census.csv');
-  return parseCensusCsv(fs.readFileSync(censusPath, 'utf8'));
+// Accepts census rows as served by design-mcp's "chart-census" entry (slug/ord, flags as
+// pipe-joined strings) or already in the engine's leaf shape, and normalizes onto it.
+export function normalizeCensusRows(rows) {
+  if (!Array.isArray(rows) || rows.length === 0) {
+    throw new Error('census rows are required — fetch them once per session via the design-mcp entry "chart-census" and pass them in the signature\'s `census` array');
+  }
+  const toFlagList = (value) =>
+    Array.isArray(value) ? value : value == null || value === '' ? [] : String(value).split('|').map((f) => f.trim());
+  return rows.map((row, index) => ({
+    id: row.id ?? row.slug,
+    family: row.family,
+    minMeasures: Number(row.minMeasures ?? row.min_measures),
+    maxMeasures: Number(row.maxMeasures ?? row.max_measures),
+    minDims: Number(row.minDims ?? row.min_dims),
+    maxDims: Number(row.maxDims ?? row.max_dims),
+    requiresFlags: toFlagList(row.requiresFlags ?? row.requires_flags),
+    excludesFlags: toFlagList(row.excludesFlags ?? row.excludes_flags),
+    viewportMin: row.viewportMin ?? row.viewport_min ?? 'mobile',
+    notes: row.notes ?? '',
+    order: row.order ?? row.ord ?? index,
+  }));
 }
 
 // Normalizes loose dimension-kind aliases onto the N/O/Q/T backbone.
@@ -527,7 +547,7 @@ export function selectChart(input, censusRows) {
   if (input == null || typeof input !== 'object' || Array.isArray(input)) {
     throw new Error('selectChart: input must be a data-signature object');
   }
-  const census = censusRows ?? loadDefaultCensus();
+  const census = normalizeCensusRows(censusRows ?? input.census);
   const { flags, structure } = deriveFlags(input);
 
   const refusal = deriveRefusal(input, structure);

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "@nurix/etna",
-    "version": "0.19.49",
+    "version": "0.19.51",
     "description": "Bootstrap a project with a Nurix harness — copies the harness's CLAUDE.md, skills, agents, rules, and hooks directly into the project from a bundled payload (no marketplace fetch, no network).",
     "type": "module",
     "bin": {
@@ -42,5 +42,5 @@
         "agent",
         "plugin"
     ],
-    "etnaFingerprint": "889424d916fc"
+    "etnaFingerprint": "add8db2442a5"
 }

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/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/apollo/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/apollo/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/apollo/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/apollo/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/apollo/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 }
-```