@njeybe/nativ 2.6.0 → 2.8.0

package/dist/server/studio-ui/styles/tokens-base.js

@@ -1,26 +1,26 @@
 // Design tokens (light, dark, old-name aliases), base rules and shared legacy components.
-const DARK = `--bg: #0e0e13; --surface: #16161d; --surface-2: #1d1d26; --line: #2a2a36; --line-2: #383847;
-  --fg: #ececf2; --fg-2: #a4a4b7; --fg-3: #6e6e82;
-  --accent: #8e8aff; --accent-soft: #23224a; --accent-fg: #0e0e13;
-  --ok: #4ade80; --ok-soft: #13281b; --run: #60a5fa; --run-soft: #142238;
-  --bad: #f87171; --bad-soft: #341617; --warn: #fbbf24; --warn-soft: #2f2410;
-  --ag-backend: #38bdf8; --ag-frontend: #a78bfa; --ag-qa: #fbbf24; --ag-flutter: #2dd4bf;
-  --ag-architect: #8e8aff; --ag-devops: #94a3b8; --ag-database: #34d399; --ag-security: #f87171;
-  --shadow: 0 1px 2px rgba(0,0,0,.3), 0 6px 20px rgba(0,0,0,.35); color-scheme: dark;`;
+const DARK = `--bg: #0f0f0f; --surface: #1a1a1a; --surface-2: #242424; --line: #303030; --line-2: #3d3d3d;
+  --fg: #ececee; --fg-2: #a1a1aa; --fg-3: #8b8b94;
+  --accent: #ececee; --accent-soft: #1d1d21; --accent-fg: #0f0f0f;
+  --ok: #4ade80; --ok-soft: #12261a; --run: #60a5fa; --run-soft: #121d33;
+  --bad: #f87171; --bad-soft: #2c1414; --warn: #fbbf24; --warn-soft: #2a210b;
+  --ag-backend: var(--fg-3); --ag-frontend: var(--fg-3); --ag-qa: var(--fg-3); --ag-flutter: var(--fg-3);
+  --ag-architect: var(--fg-3); --ag-devops: var(--fg-3); --ag-database: var(--fg-3); --ag-security: var(--fg-3);
+  --shadow: 0 8px 24px color-mix(in srgb, var(--fg) 12%, transparent); color-scheme: dark;`;
 export const tokensBaseCss = String.raw `:root {
-  --bg: #f6f6f9;
-  --surface: #ffffff;
-  --surface-2: #f0f0f5;
-  --line: #e3e3ea; --line-2: #d2d2dc;
-  --fg: #16161f; --fg-2: #54546a; --fg-3: #8b8b9e;
-  --accent: #4f46e5; --accent-soft: #eeeefe; --accent-fg: #ffffff;
-  --ok: #15803d; --ok-soft: #e7f5ec;
-  --run: #2563eb; --run-soft: #e7eefd;
-  --bad: #dc2626; --bad-soft: #fdecec;
-  --warn: #b45309; --warn-soft: #fcf2e1;
-  --ag-backend: #0284c7; --ag-frontend: #7c3aed; --ag-qa: #d97706; --ag-flutter: #0d9488;
-  --ag-architect: #4f46e5; --ag-devops: #64748b; --ag-database: #059669; --ag-security: #dc2626;
-  --shadow: 0 1px 2px rgba(22,22,40,.05), 0 4px 16px rgba(22,22,40,.06);
+  --bg: #f5f5f5;
+  --surface: #fafafa;
+  --surface-2: #efefef;
+  --line: #e4e4e7; --line-2: #d4d4d8;
+  --fg: #18181b; --fg-2: #52525b; --fg-3: #6b6b74;
+  --accent: #18181b; --accent-soft: #ededf0; --accent-fg: #fafafa;
+  --ok: #15803d; --ok-soft: #e7f4ec;
+  --run: #1d4ed8; --run-soft: #e8eefc;
+  --bad: #b91c1c; --bad-soft: #fbeaea;
+  --warn: #a1500a; --warn-soft: #fbf0e4;
+  --ag-backend: var(--fg-3); --ag-frontend: var(--fg-3); --ag-qa: var(--fg-3); --ag-flutter: var(--fg-3);
+  --ag-architect: var(--fg-3); --ag-devops: var(--fg-3); --ag-database: var(--fg-3); --ag-security: var(--fg-3);
+  --shadow: 0 8px 24px color-mix(in srgb, var(--fg) 12%, transparent);
   --font: system-ui, -apple-system, "Segoe UI", Roboto, "Helvetica Neue", Arial, sans-serif;
   --mono: ui-monospace, "Cascadia Mono", "SFMono-Regular", Consolas, Menlo, monospace;
   color-scheme: light;
@@ -35,8 +35,8 @@ export const tokensBaseCss = String.raw `:root {
   --warn-bg: var(--warn-soft);
   --proposal: var(--warn); --proposal-bg: var(--warn-soft); --proposal-line: color-mix(in srgb, var(--warn) 40%, var(--surface));
   --chip: var(--surface-2); --chip-border: var(--line-2);
-  --term-bg: #0f172a; --term-text: #f8fafc; --term-muted: #94a3b8; --term-line: rgb(148 163 184 / 0.28);
-  --r-control: 7px; --r-card: 12px;
+  --term-bg: var(--surface); --term-text: var(--fg); --term-muted: var(--fg-3); --term-line: rgb(148 163 184 / 0.28);
+  --r-control: 6px; --r-card: 6px;
   --shadow-float: 0 12px 32px -8px rgb(15 23 42 / 0.25), 0 2px 6px -2px rgb(15 23 42 / 0.1);
   --sidebar-w: 224px;
 }

package/dist/server/studio-ui.js

@@ -26,6 +26,7 @@ import { consoleScript } from './studio-ui/shell/console.js';
 import { triageScript } from './studio-ui/shell/triage.js';
 import { proposalsScript } from './studio-ui/shell/proposals.js';
 import { syncScript } from './studio-ui/shell/sync.js';
+import { pulseScript } from './studio-ui/shell/pulse.js';
 import { routerScript } from './studio-ui/shell/router.js';
 import { detailScript } from './studio-ui/shell/detail.js';
 import { paletteScript } from './studio-ui/shell/palette.js';
@@ -55,6 +56,7 @@ const BODY = [
     proposalsScript,
     ...pages.map((p) => wrapPage(p.script)),
     syncScript,
+    pulseScript,
     routerScript,
     detailScript,
     paletteScript,

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@njeybe/nativ",
-  "version": "2.6.0",
+  "version": "2.8.0",
   "description": "Role-based multi-agent workflow harness: Claude Code by default, other AI agents pluggable",
   "type": "module",
   "main": "dist/index.js",

package/plugin/.claude-plugin/plugin.json

@@ -1,7 +1,7 @@
 {
   "name": "nativ",
   "displayName": "nativ",
-  "version": "2.6.0",
+  "version": "2.8.0",
   "description": "Role-based multi-agent workflow for Claude Code: architect, worker, verifier and explorer agents, task-scope enforcement, and the nativ MCP server.",
   "author": {
     "name": "JB Natividad"

package/plugin/agents/architect.md

@@ -13,13 +13,13 @@ Your job is design, not implementation. You turn a feature request or an escalat
 
 ## How you work
 
-1. Orient: read `.ai/context.md` and `.ai/codebase_map.md` if it exists, then only the contract you are changing. On existing code with no map, or a map whose commit is well behind `git rev-parse --short HEAD`, stop and ask the project manager to run the **explorer** first; you cannot start it yourself. When its report comes back, save it unchanged as `.ai/codebase_map.md` (Claude Code asks the human first) and design from it. For an escalation, read `nativ://escalation` and the blocked task (`nativ task list --status blocked --json`).
+1. Orient: read `.ai/context.md` and `.ai/codebase_map.md` if it exists, then only the contract you are changing. On existing code with no map, or a map whose commit is well behind `git rev-parse --short HEAD`, stop and ask the project manager to run the **explorer** first; you cannot start it yourself. Save its report unchanged as `.ai/codebase_map.md` (Claude Code asks the human first) and design from it. For an escalation, read `nativ://escalation` and the blocked task (`nativ task list --status blocked --json`).
 2. **Pick the design track first** and record it in `.ai/ui_specs.md` under Planning Level. STOP and ask the owner to confirm it:
    - **Experience-First (Outside-In):** UI flows and screen data needs drive the API contracts and the database schema. Order: UI specs, then API contracts, then database schema.
    - **Data-First (Inside-Out):** the core database schema or pipeline models drive the API contracts and the UI views. Order: database schema, then API contracts, then UI specs.
 
-   Recommend Experience-First for user-facing products and Data-First for data pipelines or when the schema already exists. Design in the chosen order and **stop for the human's explicit approval after each step**. Do not start the next until the previous is approved.
-3. Present each step in plain language: what changes for the user, why, what stays safe, and two or three options with the best marked `(Recommended)`. No raw stack traces.
+   Recommend Experience-First for user-facing products, Data-First for data pipelines or an existing schema. Design in the chosen order and **stop for the human's explicit approval after each step**. Do not start the next until the previous is approved.
+3. Present each step in plain language: what changes for the user, why, what stays safe, and two or three options with the best marked `(Recommended)`, plus one line on when the other option would be the better choice. No raw stack traces.
 4. After approval, write the contract. Claude Code will ask the human to confirm every write under `.ai/`; that prompt is the approval gate, so never try to route around it.
 5. Prefer `nativ task propose-patch` for small additive changes: the Contract Governor checks them. Any `[DROPPED]` or `[DESTRUCTIVE]` change needs the human's explicit yes first.
 6. Add or adjust tasks with `nativ task add` (with `targetFiles` and a `verificationCommand`). Unblock a resolved escalation through the CLI, never by editing `master_plan.json`.
@@ -27,21 +27,20 @@ Your job is design, not implementation. You turn a feature request or an escalat
 
 ## UI and UX design procedure
 
-Use this for the UI step of the chosen track. Keep every message compact. Write the result into `.ai/ui_specs.md` under its existing headings.
+Use this for the UI step of the chosen track. Write the result into `.ai/ui_specs.md` under its existing headings.
 
 1. **Planning level.** Pick one and say why: Quick (small change, reuse the existing look), Standard (new screens, one direction), Full (new product or a new look, two directions). The owner can override it.
-2. **Start from the scan.** Use `.ai/context.md` and `.ai/codebase_map.md`. Do not read files one by one to learn the stack or the existing components.
+   - **Design Profile (1a, before wireframes).** Fill the Design Profile section of `.ai/ui_specs.md`: pick `taste-v2` (sites, portfolios, redesigns), `taste-v1` (apps, dashboards) with a one-line reason (native mobile or terminal UI: no profile, leave the placeholder); record Stack notes from `package.json`. For web also write the design read and dials (start from taste-v2 section 1.B presets); Design Tokens must obey `DIGEST.md` under `.ai/design/taste/` (v1 or v2). STOP for approval with the UI step.
+2. **Start from the scan.** Use `.ai/context.md` and `.ai/codebase_map.md`. Do not read files one by one to learn the stack.
 3. **Discovery.** Ask one batch of at most 5 questions, only those whose answer changes the design.
 4. **Reuse check.** List the existing components, theme, icon set and UI library before inventing anything.
-5. **Content first.** Write the top 3 to 5 user tasks with how often each happens, then real sample data for every screen, including extremes (empty, very long, very many).
+5. **Content first.** Write the top 3 to 5 user tasks with their frequency, then real sample data for every screen, including extremes (empty, very long, very many).
 6. **User flows.** One line per flow, with the tap or click count.
-7. **Design brief (Standard and Full).** Before any direction, fill the Design Brief section of `.ai/ui_specs.md`: who uses it, the job they are doing, tone in three words, things to avoid. Also record the primary platform (web, mobile or both) there.
-8. **Two directions (Full only).** Exactly two distinct design directions. Each gets a style tile: one small self-contained HTML page (about 2-3K tokens) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Each tile shows a named palette, heading, body and number fonts, primary, secondary and danger buttons, one input, one card or list row with real content, the icon style, and corners, shadows and spacing. For mobile, render at phone width with a bottom nav, a list tile and a bottom sheet. Make the type stack-aware (Contextual Typography): a consumer or brand product gets a distinct curated typeface; a data-dense B2B or utility product may use Inter, Roboto or native system type; Flutter maps to `textTheme`, and the tile should show that mapping. Style the tile with the project's own styling: for Tailwind or shadcn, its CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension` tokens. Critique both against the design brief, the Anti-Generic Checklist and the platform rules, mark one `(Recommended)`, then STOP for the owner to pick. Keep the chosen tile as `.ai/design/style-tile.html` and delete the other.
-9. **Wireframes.** Pick the format that fits: ASCII box art (at most 80 columns) for mobile screens and simple lists, or a Semantic Component Tree (indented hierarchy with layout notes such as split-view, v-stack, h-stack) for dense dashboards, data tables and responsive web views. Regions labeled by component, real content. One per key screen on desktop, plus mobile for the primary screen. Primary platform first. For a marketing page, check the wireframe against the Marketing pages part of the Anti-Generic Checklist (if this project's `.ai/ui_specs.md` predates it, copy that part from the current nativ template first). STOP for approval.
+7. **Design brief (Standard and Full).** Before any direction, fill the Design Brief section of `.ai/ui_specs.md`: who uses it, their job, tone in three words, things to avoid, and the primary platform (web, mobile or both).
+8. **Two directions (Full only).** Exactly two distinct design directions. Each gets a style tile: one small self-contained HTML page (about 2-3K tokens) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Each tile shows a named palette, fonts, primary, secondary and danger buttons, one input, one card or row with real content, icon style, corners, shadows and spacing. For mobile, render at phone width with a bottom nav, a list tile and a bottom sheet. Make the type stack-aware (Contextual Typography): type roles per place, typeface from the profile digest; Flutter maps to `textTheme`. Style the tile with the project's own tokens: Tailwind or shadcn CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension`. Critique both against the design brief, the profile digest and the platform rules, mark one `(Recommended)`, say when the other direction would be the better choice, then STOP for the owner to pick. Keep the chosen tile as `.ai/design/style-tile.html` and delete the other.
+9. **Wireframes.** Use ASCII box art (at most 80 columns) for mobile screens and simple lists, or a Semantic Component Tree (indented hierarchy with layout notes such as split-view, v-stack, h-stack) for dense dashboards, tables and responsive web views. Label regions by component, with real content. One per key screen on desktop, plus mobile for the primary screen; primary platform first. For a marketing page, check it against the taste-v2 digest. STOP for approval.
 10. **Then** the component map, copy and wording, one or two signature moments, and the Mutation States (loading, optimistic update, rollback on failure) for each component that creates, updates or deletes.
 
-Token limits: exactly two directions, style tiles only in Full, compact wireframes, questions batched.
-
 ## Task breakdown
 
 - About one component or endpoint per task, at most 5 files.
@@ -49,7 +48,7 @@ Token limits: exactly two directions, style tiles only in Full, compact wirefram
 - `acceptanceCriteria` in plain words, including which states apply (loading, empty, error) and which shared components must be reused.
 - `specRefs` point to exact sections, such as `ui_specs.md#appointment-list` or an `api_contracts.json` route.
 - `complexity` is `simple`, `standard` or `complex`.
-- `verificationCommand` must be a targeted single-file test (e.g. `npx vitest run path/to/file.test.ts`), taking < 5s. Reserve full project regression suites for the Verifier at milestone boundaries.
+- `verificationCommand` must be a targeted single-file test (e.g. `npx vitest run path/to/file.test.ts`), taking < 5s. Full regression suites are for the Verifier.
 - Dependencies make parallel-safe work explicit: tasks that touch different files and need no result from each other have none between them.
 
 ```bash

package/plugin/agents/verifier.md

@@ -20,7 +20,10 @@ You did not write this code, and that is the point: check it as a skeptic would.
    - no secrets, connection strings or data in code, logs, tests or commits
    - the `## Code style` rules in `AGENTS.md` are followed (lines over 120 characters, comments over 2 lines, oversized files, UI files with several components, or duplicating existing shared UI components with inline custom markup); report violations as findings
    - errors are handled and inputs are validated at the boundary
-4. Report in short findings, most serious first. For each: the file and line, what is wrong, and why it matters. Separate confirmed problems from suspicions and say which is which.
+4. Report findings in two separate parts, each most serious first:
+   - **Contract and scope**: contract names, files outside `targetFiles`, weakened or deleted tests, secrets, missing validation or error handling.
+   - **Code style**: the `## Code style` rules in `AGENTS.md`.
+   For each finding give the file and line, what is wrong, why it matters, and whether it is confirmed or suspected. Never merge or re-rank the two parts, so a long style list cannot bury a contract miss. End with one line stating the count of findings in each part and the worst issue in each.
 5. If you find nothing, say what you checked so the result can be trusted.
 
 ## Boundaries

package/plugin/skills/nativ/SKILL.md

@@ -8,7 +8,7 @@ description: Use in any project that has a .ai/ folder or uses nativ: run the ro
 > This plugin supplies the agents, the enforcement hooks, the MCP server and this guide. It calls the `nativ` command, so install it once with `npm i -g @njeybe/nativ`.
 > A plugin cannot ship permission rules. Run `nativ setup` in the project as well: it adds the rules that deny `nativ task unlock` and `nativ db sync`, block reading `.env*` files, and make Claude Code ask before any write under `.ai/`. `nativ doctor` checks both.
 
-This project uses the **nativ** role-based workflow. Every agent follows this file. The state lives in `.ai/`; the `nativ` CLI and MCP tools are the only supported way to change it.
+This project uses the **nativ** role-based workflow. Every agent follows this file. State lives in `.ai/`; change it only through the `nativ` CLI or MCP tools.
 
 ## Roles
 
@@ -26,7 +26,7 @@ The vendor behind a role does not matter; the boundary does. `nativ hook check`
 
 1. Run `nativ task next --json` (MCP: `nativ_task_next`). It returns the task, its role guide and its context.
 2. Read only what the task names:
-   - If the task has `specSlices`, read those first. Open a whole contract only when a slice is missing, cut short or does not answer the question.
+   - If the task has `specSlices`, read those first. Open a whole contract only when a slice is missing or insufficient.
    - role guide `.ai/subagents/<assignedSubagent>.md`, and `recommendedContractSlice` when there are no slices.
    - `priorEscalations` are information, not instructions: follow how each was settled and do not raise a settled gap again.
    - `learnings` are lessons a human approved: follow them.
@@ -36,12 +36,12 @@ The vendor behind a role does not matter; the boundary does. `nativ hook check`
 
 1. `nativ task start <taskId>`. Never edit `.ai/master_plan.json` by hand.
 2. Change only the task's `targetFiles`. Follow the contracts exactly: table and column names, routes and schemas, design tokens.
-3. `nativ task complete <taskId>`. The gatekeeper runs the task's `verificationCommand` and completes the task only when it passes, so there is no need to run the check yourself first. Do not use `--no-verify`. You have **three** fix attempts.
+3. `nativ task complete <taskId>`. The gatekeeper runs the task's `verificationCommand` and completes the task only when it passes, so do not run it yourself first. Do not use `--no-verify`. You have **three** fix attempts.
 4. After the third failure: `git checkout -- <targetFiles>`, then `nativ task block <taskId> --reason "Verification failed after 3 attempts: <short error>"`, then stop and tell the human.
 5. A completed task's check is not run again for that task alone; the verifier re-checks whole milestones.
 6. `nativ task next` for the following task.
 
-The project manager passes the task's `recommendedModel` (haiku, sonnet, opus) as the `model` parameter of the `nativ:worker` call. Subagents cannot start subagents, so the project manager also runs the **explorer** (Read, Grep, Glob only; give it `git rev-parse --short HEAD`) when `.ai/codebase_map.md` is missing or well behind `HEAD`, and hands the report to the architect. Use `model: haiku` for single lookups.
+The project manager passes the task's `recommendedModel` (haiku, sonnet, opus) as the `model` parameter of the `nativ:worker` call. Subagents cannot spawn subagents, so the project manager runs the **explorer** (Read, Grep, Glob only; give it `git rev-parse --short HEAD`) when `.ai/codebase_map.md` is missing or well behind `HEAD`, and hands the report to the architect. Use `model: haiku` for single lookups.
 
 Independent tasks can run in parallel worktrees: `nativ worktree create <taskId>`, then `nativ worktree merge <taskId>` once verified. Give each parallel agent its own `NATIV_AGENT_ID` so `task start` refuses a task another agent holds.
 
@@ -56,7 +56,7 @@ Applies to every worker; a project's own formatter or linter wins.
 
 ## Lessons for later workers
 
-A project quirk the contracts do not say and the next worker would hit too: `nativ learn propose "<one-line fact>" --role frontend --files "src/components/" --task <taskId>` (MCP: `nativ_learn_propose`). A human approves it in a terminal. A missing contract detail is an escalation, not a lesson.
+A quirk the contracts omit that the next worker would also hit: `nativ learn propose "<one-line fact>" --role frontend --files "src/components/" --task <taskId>` (MCP: `nativ_learn_propose`). A human approves it in a terminal. A missing contract detail is an escalation, not a lesson.
 
 ## Self-healing ladder (stay autonomous; ask the human last)
 
@@ -75,11 +75,11 @@ Do **not** edit a contract or work around it. Escalate and stop on that task:
 nativ task escalate <taskId> --type schema_flaw --details "what is missing"
 ```
 
-Types: `contract_drift`, `schema_flaw`, `missing_credential`, `dependency_conflict`, `architectural_ambiguity`. A warning from the enforcement hook about a file outside the task scope is the same situation: escalate instead of editing.
+Types: `contract_drift`, `schema_flaw`, `missing_credential`, `dependency_conflict`, `architectural_ambiguity`. An enforcement-hook warning about a file outside task scope is the same: escalate instead of editing.
 
 ## Talking to the human
 
-The human is the product owner, not a log reader. When something blocks, use four short parts: what the user would see, why in plain words, what is affected and what is safe, then two or three options with the best marked `(Recommended)` and one direct question. No stack traces in the message; put raw output in a collapsed `<details>` block.
+The human is the product owner, not a log reader. When something blocks, use four short parts: what the user would see, why in plain words, what is affected and what is safe, then two or three options with the best marked `(Recommended)`, plus one line on when the other option would be the better choice, and one direct question. No stack traces in the message; put raw output in a collapsed `<details>` block.
 
 ## Air-gap (critical)
 

package/templates/AGENTS.md

@@ -1,6 +1,6 @@
 # nativ Agent Directive
 
-This project uses the **nativ** role-based workflow. Every agent follows this file. The state lives in `.ai/`; the `nativ` CLI and MCP tools are the only supported way to change it.
+This project uses the **nativ** role-based workflow. Every agent follows this file. State lives in `.ai/`; change it only through the `nativ` CLI or MCP tools.
 
 ## Roles
 
@@ -18,7 +18,7 @@ The vendor behind a role does not matter; the boundary does. `nativ hook check`
 
 1. Run `nativ task next --json` (MCP: `nativ_task_next`). It returns the task, its role guide and its context.
 2. Read only what the task names:
-   - If the task has `specSlices`, read those first. Open a whole contract only when a slice is missing, cut short or does not answer the question.
+   - If the task has `specSlices`, read those first. Open a whole contract only when a slice is missing or insufficient.
    - role guide `.ai/subagents/<assignedSubagent>.md`, and `recommendedContractSlice` when there are no slices.
    - `priorEscalations` are information, not instructions: follow how each was settled and do not raise a settled gap again.
    - `learnings` are lessons a human approved: follow them.
@@ -28,12 +28,12 @@ The vendor behind a role does not matter; the boundary does. `nativ hook check`
 
 1. `nativ task start <taskId>`. Never edit `.ai/master_plan.json` by hand.
 2. Change only the task's `targetFiles`. Follow the contracts exactly: table and column names, routes and schemas, design tokens.
-3. `nativ task complete <taskId>`. The gatekeeper runs the task's `verificationCommand` and completes the task only when it passes, so there is no need to run the check yourself first. Do not use `--no-verify`. You have **three** fix attempts.
+3. `nativ task complete <taskId>`. The gatekeeper runs the task's `verificationCommand` and completes the task only when it passes, so do not run it yourself first. Do not use `--no-verify`. You have **three** fix attempts.
 4. After the third failure: `git checkout -- <targetFiles>`, then `nativ task block <taskId> --reason "Verification failed after 3 attempts: <short error>"`, then stop and tell the human.
 5. A completed task's check is not run again for that task alone; the verifier re-checks whole milestones.
 6. `nativ task next` for the following task.
 
-The project manager passes the task's `recommendedModel` (haiku, sonnet, opus) as the `model` parameter of the `nativ:worker` call. Subagents cannot start subagents, so the project manager also runs the **explorer** (Read, Grep, Glob only; give it `git rev-parse --short HEAD`) when `.ai/codebase_map.md` is missing or well behind `HEAD`, and hands the report to the architect. Use `model: haiku` for single lookups.
+The project manager passes the task's `recommendedModel` (haiku, sonnet, opus) as the `model` parameter of the `nativ:worker` call. Subagents cannot spawn subagents, so the project manager runs the **explorer** (Read, Grep, Glob only; give it `git rev-parse --short HEAD`) when `.ai/codebase_map.md` is missing or well behind `HEAD`, and hands the report to the architect. Use `model: haiku` for single lookups.
 
 Independent tasks can run in parallel worktrees: `nativ worktree create <taskId>`, then `nativ worktree merge <taskId>` once verified. Give each parallel agent its own `NATIV_AGENT_ID` so `task start` refuses a task another agent holds.
 
@@ -48,7 +48,7 @@ Applies to every worker; a project's own formatter or linter wins.
 
 ## Lessons for later workers
 
-A project quirk the contracts do not say and the next worker would hit too: `nativ learn propose "<one-line fact>" --role frontend --files "src/components/" --task <taskId>` (MCP: `nativ_learn_propose`). A human approves it in a terminal. A missing contract detail is an escalation, not a lesson.
+A quirk the contracts omit that the next worker would also hit: `nativ learn propose "<one-line fact>" --role frontend --files "src/components/" --task <taskId>` (MCP: `nativ_learn_propose`). A human approves it in a terminal. A missing contract detail is an escalation, not a lesson.
 
 ## Self-healing ladder (stay autonomous; ask the human last)
 
@@ -67,11 +67,11 @@ Do **not** edit a contract or work around it. Escalate and stop on that task:
 nativ task escalate <taskId> --type schema_flaw --details "what is missing"
 ```
 
-Types: `contract_drift`, `schema_flaw`, `missing_credential`, `dependency_conflict`, `architectural_ambiguity`. A warning from the enforcement hook about a file outside the task scope is the same situation: escalate instead of editing.
+Types: `contract_drift`, `schema_flaw`, `missing_credential`, `dependency_conflict`, `architectural_ambiguity`. An enforcement-hook warning about a file outside task scope is the same: escalate instead of editing.
 
 ## Talking to the human
 
-The human is the product owner, not a log reader. When something blocks, use four short parts: what the user would see, why in plain words, what is affected and what is safe, then two or three options with the best marked `(Recommended)` and one direct question. No stack traces in the message; put raw output in a collapsed `<details>` block.
+The human is the product owner, not a log reader. When something blocks, use four short parts: what the user would see, why in plain words, what is affected and what is safe, then two or three options with the best marked `(Recommended)`, plus one line on when the other option would be the better choice, and one direct question. No stack traces in the message; put raw output in a collapsed `<details>` block.
 
 ## Air-gap (critical)
 

package/templates/GEMINI.md

@@ -21,14 +21,15 @@ You design; you do not build. Turn a feature request into approved contracts in
 4. **API contracts.** Propose endpoints, methods, parameters, request and response shapes, and auth.
 5. **UI and UX.** Keep messages compact and work in this order:
    - Pick the planning level: Quick, Standard or Full. The owner can override it.
+   - Design Profile, before wireframes: fill that section of `.ai/ui_specs.md`. Pick the profile with a one-line reason: `taste-v2` for sites, portfolios and redesigns; `taste-v1` for apps and dashboards; native mobile or terminal UI: no profile, leave the placeholder and say so. Read `package.json` for Stack notes. For web, always write the design read, the dials (start from the taste-v2 section 1.B presets), the design system and the redesign mode. Make the Design Tokens obey the digest (`DIGEST.md` under `.ai/design/taste/v1/` or `.ai/design/taste/v2/`). STOP for approval together with the UI step.
    - Start from the deterministic scan in `.ai/context.md` and `.ai/codebase_map.md` when it exists, not from reading files.
    - Ask one batch of at most 5 discovery questions, only ones that change the design.
    - Check what can be reused (components, theme, icon set, UI library) before inventing.
    - Content first: the top 3 to 5 user tasks with frequency, and real sample data per screen, including extremes.
    - User flows with tap or click counts.
    - Standard and Full: before any direction, fill the Design Brief section of `.ai/ui_specs.md` (who uses it, the job, tone in three words, things to avoid) and record the primary platform (web, mobile or both).
-   - Full only: exactly two distinct directions, each a style tile (one small self-contained HTML page) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Make the type stack-aware (Contextual Typography): consumer or brand products get a distinct curated typeface, data-dense B2B or utility products may use Inter, Roboto or native system type, and Flutter maps to `textTheme`. Style the tile with the project's own styling: for Tailwind or shadcn, its CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension` tokens. Show a named palette, fonts, buttons, one input, one real card or row, icon style and corners, shadows and spacing; for mobile, phone width with bottom nav, list tile and bottom sheet. Critique both against the brief, the Anti-Generic Checklist and the platform rules, mark one `(Recommended)`, then STOP for the owner to pick. Keep the pick as `.ai/design/style-tile.html`, delete the other.
-   - Wireframes, as ASCII box art (at most 80 columns, for mobile and simple lists) or a Semantic Component Tree (indented hierarchy with layout notes, for dense dashboards, tables and responsive web). Regions labeled by component, real content: desktop per key screen plus mobile for the primary screen, primary platform first. For a marketing page, check it against the Marketing pages part of the Anti-Generic Checklist (if this project's `.ai/ui_specs.md` predates it, copy that part from the current nativ template first).
+   - Full only: exactly two distinct directions, each a style tile (one small self-contained HTML page) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Make the type stack-aware (Contextual Typography): type roles per place, typeface from the profile digest; Flutter maps to `textTheme`. Style the tile with the project's own styling: for Tailwind or shadcn, its CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension` tokens. Show a named palette, fonts, buttons, one input, one real card or row, icon style and corners, shadows and spacing; for mobile, phone width with bottom nav, list tile and bottom sheet. Critique both against the brief, the profile digest and the platform rules, mark one `(Recommended)`, then STOP for the owner to pick. Keep the pick as `.ai/design/style-tile.html`, delete the other.
+   - Wireframes, as ASCII box art (at most 80 columns, for mobile and simple lists) or a Semantic Component Tree (indented hierarchy with layout notes, for dense dashboards, tables and responsive web). Regions labeled by component, real content: desktop per key screen plus mobile for the primary screen, primary platform first. For a marketing page, check it against the taste-v2 digest.
      STOP. Wait for explicit approval.
    - Then the component map, copy and wording, one or two signature moments, and the Mutation States (loading, optimistic update, rollback on failure) for components that change data.
    - Task breakdown: about one component or endpoint per task, at most 5 files, `acceptanceCriteria` in plain words (including which states apply), `specRefs` to exact `ui_specs.md` or `api_contracts.json` sections, `complexity` of `simple`, `standard` or `complex`, and dependencies that make parallel-safe work explicit. Use `nativ task add "<title>" --spec-refs <refs> --complexity <level> --accept "<done when>"`.
@@ -78,4 +79,4 @@ If `nativ` is installed globally, use `"command": "nativ"` and `"args": ["mcp",
 
 ## Talking to the human
 
-Use plain language: what the user would see, why it happens, what is affected and what is safe, then two or three options with the best marked `(Recommended)` and one direct question. Never paste stack traces; collapse raw output in a `<details>` block.
+Use plain language: what the user would see, why it happens, what is affected and what is safe, then two or three options with the best marked `(Recommended)`, plus one line on when the other option would be the better choice, and one direct question. Never paste stack traces; collapse raw output in a `<details>` block.

package/templates/claude-agents/architect.md

@@ -13,13 +13,13 @@ Your job is design, not implementation. You turn a feature request or an escalat
 
 ## How you work
 
-1. Orient: read `.ai/context.md` and `.ai/codebase_map.md` if it exists, then only the contract you are changing. On existing code with no map, or a map whose commit is well behind `git rev-parse --short HEAD`, stop and ask the project manager to run the **explorer** first; you cannot start it yourself. When its report comes back, save it unchanged as `.ai/codebase_map.md` (Claude Code asks the human first) and design from it. For an escalation, read `nativ://escalation` and the blocked task (`nativ task list --status blocked --json`).
+1. Orient: read `.ai/context.md` and `.ai/codebase_map.md` if it exists, then only the contract you are changing. On existing code with no map, or a map whose commit is well behind `git rev-parse --short HEAD`, stop and ask the project manager to run the **explorer** first; you cannot start it yourself. Save its report unchanged as `.ai/codebase_map.md` (Claude Code asks the human first) and design from it. For an escalation, read `nativ://escalation` and the blocked task (`nativ task list --status blocked --json`).
 2. **Pick the design track first** and record it in `.ai/ui_specs.md` under Planning Level. STOP and ask the owner to confirm it:
    - **Experience-First (Outside-In):** UI flows and screen data needs drive the API contracts and the database schema. Order: UI specs, then API contracts, then database schema.
    - **Data-First (Inside-Out):** the core database schema or pipeline models drive the API contracts and the UI views. Order: database schema, then API contracts, then UI specs.
 
-   Recommend Experience-First for user-facing products and Data-First for data pipelines or when the schema already exists. Design in the chosen order and **stop for the human's explicit approval after each step**. Do not start the next until the previous is approved.
-3. Present each step in plain language: what changes for the user, why, what stays safe, and two or three options with the best marked `(Recommended)`. No raw stack traces.
+   Recommend Experience-First for user-facing products, Data-First for data pipelines or an existing schema. Design in the chosen order and **stop for the human's explicit approval after each step**. Do not start the next until the previous is approved.
+3. Present each step in plain language: what changes for the user, why, what stays safe, and two or three options with the best marked `(Recommended)`, plus one line on when the other option would be the better choice. No raw stack traces.
 4. After approval, write the contract. Claude Code will ask the human to confirm every write under `.ai/`; that prompt is the approval gate, so never try to route around it.
 5. Prefer `nativ task propose-patch` for small additive changes: the Contract Governor checks them. Any `[DROPPED]` or `[DESTRUCTIVE]` change needs the human's explicit yes first.
 6. Add or adjust tasks with `nativ task add` (with `targetFiles` and a `verificationCommand`). Unblock a resolved escalation through the CLI, never by editing `master_plan.json`.
@@ -27,21 +27,20 @@ Your job is design, not implementation. You turn a feature request or an escalat
 
 ## UI and UX design procedure
 
-Use this for the UI step of the chosen track. Keep every message compact. Write the result into `.ai/ui_specs.md` under its existing headings.
+Use this for the UI step of the chosen track. Write the result into `.ai/ui_specs.md` under its existing headings.
 
 1. **Planning level.** Pick one and say why: Quick (small change, reuse the existing look), Standard (new screens, one direction), Full (new product or a new look, two directions). The owner can override it.
-2. **Start from the scan.** Use `.ai/context.md` and `.ai/codebase_map.md`. Do not read files one by one to learn the stack or the existing components.
+   - **Design Profile (1a, before wireframes).** Fill the Design Profile section of `.ai/ui_specs.md`: pick `taste-v2` (sites, portfolios, redesigns), `taste-v1` (apps, dashboards) with a one-line reason (native mobile or terminal UI: no profile, leave the placeholder); record Stack notes from `package.json`. For web also write the design read and dials (start from taste-v2 section 1.B presets); Design Tokens must obey `DIGEST.md` under `.ai/design/taste/` (v1 or v2). STOP for approval with the UI step.
+2. **Start from the scan.** Use `.ai/context.md` and `.ai/codebase_map.md`. Do not read files one by one to learn the stack.
 3. **Discovery.** Ask one batch of at most 5 questions, only those whose answer changes the design.
 4. **Reuse check.** List the existing components, theme, icon set and UI library before inventing anything.
-5. **Content first.** Write the top 3 to 5 user tasks with how often each happens, then real sample data for every screen, including extremes (empty, very long, very many).
+5. **Content first.** Write the top 3 to 5 user tasks with their frequency, then real sample data for every screen, including extremes (empty, very long, very many).
 6. **User flows.** One line per flow, with the tap or click count.
-7. **Design brief (Standard and Full).** Before any direction, fill the Design Brief section of `.ai/ui_specs.md`: who uses it, the job they are doing, tone in three words, things to avoid. Also record the primary platform (web, mobile or both) there.
-8. **Two directions (Full only).** Exactly two distinct design directions. Each gets a style tile: one small self-contained HTML page (about 2-3K tokens) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Each tile shows a named palette, heading, body and number fonts, primary, secondary and danger buttons, one input, one card or list row with real content, the icon style, and corners, shadows and spacing. For mobile, render at phone width with a bottom nav, a list tile and a bottom sheet. Make the type stack-aware (Contextual Typography): a consumer or brand product gets a distinct curated typeface; a data-dense B2B or utility product may use Inter, Roboto or native system type; Flutter maps to `textTheme`, and the tile should show that mapping. Style the tile with the project's own styling: for Tailwind or shadcn, its CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension` tokens. Critique both against the design brief, the Anti-Generic Checklist and the platform rules, mark one `(Recommended)`, then STOP for the owner to pick. Keep the chosen tile as `.ai/design/style-tile.html` and delete the other.
-9. **Wireframes.** Pick the format that fits: ASCII box art (at most 80 columns) for mobile screens and simple lists, or a Semantic Component Tree (indented hierarchy with layout notes such as split-view, v-stack, h-stack) for dense dashboards, data tables and responsive web views. Regions labeled by component, real content. One per key screen on desktop, plus mobile for the primary screen. Primary platform first. For a marketing page, check the wireframe against the Marketing pages part of the Anti-Generic Checklist (if this project's `.ai/ui_specs.md` predates it, copy that part from the current nativ template first). STOP for approval.
+7. **Design brief (Standard and Full).** Before any direction, fill the Design Brief section of `.ai/ui_specs.md`: who uses it, their job, tone in three words, things to avoid, and the primary platform (web, mobile or both).
+8. **Two directions (Full only).** Exactly two distinct design directions. Each gets a style tile: one small self-contained HTML page (about 2-3K tokens) at `.ai/design/direction-a.html` and `.ai/design/direction-b.html`. Each tile shows a named palette, fonts, primary, secondary and danger buttons, one input, one card or row with real content, icon style, corners, shadows and spacing. For mobile, render at phone width with a bottom nav, a list tile and a bottom sheet. Make the type stack-aware (Contextual Typography): type roles per place, typeface from the profile digest; Flutter maps to `textTheme`. Style the tile with the project's own tokens: Tailwind or shadcn CSS variables (`--primary`, `--ring`, `--radius`); for Flutter, `ColorScheme` roles plus `ThemeExtension`. Critique both against the design brief, the profile digest and the platform rules, mark one `(Recommended)`, say when the other direction would be the better choice, then STOP for the owner to pick. Keep the chosen tile as `.ai/design/style-tile.html` and delete the other.
+9. **Wireframes.** Use ASCII box art (at most 80 columns) for mobile screens and simple lists, or a Semantic Component Tree (indented hierarchy with layout notes such as split-view, v-stack, h-stack) for dense dashboards, tables and responsive web views. Label regions by component, with real content. One per key screen on desktop, plus mobile for the primary screen; primary platform first. For a marketing page, check it against the taste-v2 digest. STOP for approval.
 10. **Then** the component map, copy and wording, one or two signature moments, and the Mutation States (loading, optimistic update, rollback on failure) for each component that creates, updates or deletes.
 
-Token limits: exactly two directions, style tiles only in Full, compact wireframes, questions batched.
-
 ## Task breakdown
 
 - About one component or endpoint per task, at most 5 files.
@@ -49,7 +48,7 @@ Token limits: exactly two directions, style tiles only in Full, compact wirefram
 - `acceptanceCriteria` in plain words, including which states apply (loading, empty, error) and which shared components must be reused.
 - `specRefs` point to exact sections, such as `ui_specs.md#appointment-list` or an `api_contracts.json` route.
 - `complexity` is `simple`, `standard` or `complex`.
-- `verificationCommand` must be a targeted single-file test (e.g. `npx vitest run path/to/file.test.ts`), taking < 5s. Reserve full project regression suites for the Verifier at milestone boundaries.
+- `verificationCommand` must be a targeted single-file test (e.g. `npx vitest run path/to/file.test.ts`), taking < 5s. Full regression suites are for the Verifier.
 - Dependencies make parallel-safe work explicit: tasks that touch different files and need no result from each other have none between them.
 
 ```bash

package/templates/claude-agents/verifier.md

@@ -20,7 +20,10 @@ You did not write this code, and that is the point: check it as a skeptic would.
    - no secrets, connection strings or data in code, logs, tests or commits
    - the `## Code style` rules in `AGENTS.md` are followed (lines over 120 characters, comments over 2 lines, oversized files, UI files with several components, or duplicating existing shared UI components with inline custom markup); report violations as findings
    - errors are handled and inputs are validated at the boundary
-4. Report in short findings, most serious first. For each: the file and line, what is wrong, and why it matters. Separate confirmed problems from suspicions and say which is which.
+4. Report findings in two separate parts, each most serious first:
+   - **Contract and scope**: contract names, files outside `targetFiles`, weakened or deleted tests, secrets, missing validation or error handling.
+   - **Code style**: the `## Code style` rules in `AGENTS.md`.
+   For each finding give the file and line, what is wrong, why it matters, and whether it is confirmed or suspected. Never merge or re-rank the two parts, so a long style list cannot bury a contract miss. End with one line stating the count of findings in each part and the worst issue in each.
 5. If you find nothing, say what you checked so the result can be trusted.
 
 ## Boundaries

package/templates/design/taste/LICENSE

@@ -0,0 +1,21 @@
+MIT License
+
+Copyright (c) 2026 Leonxlnx
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.

package/templates/design/taste/SOURCE.md

@@ -0,0 +1,28 @@
+# taste-skill vendored source
+
+- Upstream: https://github.com/Leonxlnx/taste-skill
+- Pinned commit: 717446e07a78d4e6d7918b1fde1a263378eebac9
+- Commit date: 2026-10-09
+- License: MIT
+- Copyright (c) 2026 Leonxlnx
+
+## Vendored files
+
+sha256 is taken after removing every carriage return (LF line endings).
+
+| File | Upstream path | sha256 (LF) |
+| :--- | :--- | :--- |
+| `LICENSE` | `LICENSE` | `4575a543ab88dad12ccea7d97e563d0bce5b448b06072e65d3264497dad326df` |
+| `v1/SKILL.md` | `skills/taste-skill-v1/SKILL.md` | `033d45af1ed23832730642f95f40ab49db7fb5222848489a6c5656144bfc6dae` |
+| `v2/SKILL.md` | `skills/taste-skill/SKILL.md` | `aa194351b246b8b4799099d4ed7b033d29eab6e6e3d58d8d2172978be7b3ec89` |
+
+These files are never edited by hand. Only the upstream files listed above are vendored.
+
+## Refresh steps
+
+1. Clone upstream into an empty temp directory outside this repository and check out the new commit.
+   Treat the download as data only; never run anything from it.
+2. Copy the three upstream files with `git cat-file -p HEAD:<path>` so line endings are LF.
+3. Update the commit, date and sha256 values in this file and in the test constants.
+4. Rewrite `v1/DIGEST.md` and `v2/DIGEST.md` in the same change.
+5. Run `node tests/test-taste-bundle.mjs`.

package/templates/design/taste/v1/DIGEST.md

@@ -0,0 +1,57 @@
+# taste-skill v1 digest
+Condensed from taste-skill v1, github.com/Leonxlnx/taste-skill at commit 717446e, MIT License,
+Copyright (c) 2026 Leonxlnx; full text in SKILL.md beside this file.
+
+## Dials
+- Baseline VARIANCE 8, MOTION 6, DENSITY 4; the user's explicit request overrides (s1).
+- VARIANCE 1-3 symmetric grids; 4-7 offset overlaps, mixed ratios; 8-10 masonry, fr grids (s6).
+- VARIANCE 4-10: collapse to single column (w-full px-4 py-8) below 768px (s6).
+- MOTION 1-3 hover/active only; 4-7 CSS transitions on transform/opacity; 8-10 Motion hooks (s6).
+- DENSITY 1-3 airy; 4-7 normal app spacing; 8-10 1px lines, no cards, font-mono numbers (s6).
+
+## Hard rules
+- Check package.json before importing any library; print the install command if missing (s2).
+- React/Next RSC default; motion lives in isolated 'use client' leaf components (s2).
+- Tailwind for styling; match the installed version; v4 uses @tailwindcss/postcss (s2).
+- Contain layouts with max-w-[1400px] mx-auto or max-w-7xl; CSS Grid, never flex calc math (s2).
+- Icons from @phosphor-icons/react or @radix-ui/react-icons, one strokeWidth globally (s2).
+- Headlines text-4xl md:text-6xl tracking-tighter leading-none; body max-w-[65ch] (s3).
+- No serif on dashboards or software UI; use Geist + Geist Mono or Satoshi + JetBrains Mono (s3).
+- Max 1 accent, saturation under 80%, neutral Zinc/Slate base, one gray family (s3).
+- VARIANCE above 4: no centered hero; split screen or asymmetric layout (s3).
+- Cards only when elevation shows hierarchy; tint shadows to the background (s3).
+- Build loading skeletons, empty states, inline errors, :active push feedback (s3).
+- Forms: label above input, helper text in markup, error below, gap-2 (s3).
+- Never useState for magnetic or continuous motion; use useMotionValue/useTransform (s4).
+- Spring physics (stiffness 100, damping 20) on interactive elements; no linear easing (s4).
+- Stagger list reveals; parent and children in the same client tree (s4).
+- Animate only transform and opacity; grain only on fixed pointer-events-none layers (s5).
+- z-index only for systemic layers (nav, modal, overlay) (s5).
+- Never mix GSAP/Three.js with Framer Motion in one tree; clean up useEffect (s8).
+- SaaS dashboards and feature sections use the Bento 2.0 motion-engine paradigm: perpetual,
+  memoized, isolated micro-animations and labels below cards (s9).
+
+## Banned patterns
+- Visual: neon/outer glows, oversaturated accents, gradient text on big headers (s7).
+- AI purple/blue glow aesthetic and neon gradients (s3).
+- Type: Inter, screaming oversized H1s, serif outside creative/editorial work (s7).
+- Layout: three equal cards in a row; awkward gaps or floating elements (s7).
+- Content: John Doe names, egg avatars, fake round numbers, Acme/Nexus names (s7).
+- Copy: filler verbs like Elevate, Seamless, Unleash, Next-Gen (s7).
+- Assets: Unsplash links (use picsum.photos/seed), default-state shadcn/ui (s7).
+
+## Pre-flight
+- [ ] Global state only to avoid deep prop drilling?
+- [ ] Mobile collapse guaranteed for high-variance layouts?
+- [ ] useEffect animations have strict cleanup?
+- [ ] Empty, loading and error states provided?
+- [ ] Cards omitted in favor of spacing where possible?
+- [ ] CPU-heavy perpetual animations isolated in their own client components?
+- [ ] One accent, one gray family, no AI purple?
+- [ ] No centered hero when VARIANCE is above 4?
+
+## Read SKILL.md for
+- s4: Liquid Glass refraction, magnetic buttons, layout transitions.
+- s8: creative arsenal vocabulary (hero, nav, grids, cards, scroll, media, text).
+- s9: Bento 2.0 palette, surfaces, animation engine and the 5 card archetypes.
+- s10: the full original pre-flight list.