@montytools/cli 0.5.4 → 0.5.6

package/skills/monty-build/SKILL.md

@@ -1,126 +1,113 @@
 ---
 name: monty-build
-description: Build, run, and save Monty workspace apps. Use whenever the task involves a Monty app, monty.config.ts, the monty CLI (create/dev/logs/save/add), the @montytools/sdk, or a prompt mentioning usemonty.dev. Covers folder discipline, the build loop, data/auth rules, and error handling.
+description: Build, run, and save Monty workspace apps. Use whenever the task involves a Monty app, its schema (monty schema / src/monty.gen.ts), the monty CLI (create/connect/dev/logs/save), the @montytools/sdk, or a prompt mentioning usemonty.dev. Covers folder discipline, the build loop, data/auth rules, and error handling.
 ---
 
 # Building Monty apps
 
-Monty is a work OS: teams get internal apps built by coding agents. You write
-product logic only — data, auth, tenancy, deployment, and embedding are the
-platform's job. The complete contract lives in the app's own `AGENTS.md`
-(nearest-file-wins — read it before writing code). This skill is the map, not
-the territory.
+Monty is a work OS. Teams get internal apps built by coding agents. You write
+product logic only. Data, auth, tenancy, deployment, and embedding are the
+platform's job. The full contract is in the app's own `AGENTS.md`
+(nearest file wins). Read it before writing code.
 
-There is ONE copy of every app: **Live**, the cloud copy the team uses
-(`monty save` updates it). While a dev **session** runs (a dev shell on
-the app's LIVE records, often already started for you by the Monty desktop),
-workspace admins see the session's version automatically — no publish, no
-channel switch. "dev"/"prod" mean platform environments, never app states.
+Every app has ONE copy: **Live**, the cloud copy the team uses. `monty save`
+updates it. While a dev **session** runs (often already started for you by
+the Monty desktop), workspace admins see the session's version automatically.
+There is no publish step. "dev" and "prod" name platform environments, never
+app states.
 
 ## Rules
 
-1. **Folders are managed.** Apps live in `~/.monty/apps/<id>` (a server-issued
-   id, minted when `monty create` registers the app — so create needs
-   `monty login` first). `monty current` tells you where you are;
-   `cd "$(monty select <slug>)"` jumps to an app; `monty apps` lists local
-   ones. Never mkdir app folders by hand, and never edit the `id:` line in
-   `monty.config.ts`. The folder IS the app's source: every file in it
-   rides the source snapshot on `monty save`, so never leave scratch files
-   here (manifest edits, notes, one-off scripts). Work in the OS temp dir
-   instead, or pipe — `monty schema | <edit> | monty schema set -` needs
-   no file at all — and delete anything temporary before saving.
-2. **The loop:** `monty create <slug> --name "Name" --icon <tabler-icon>` →
-   (if the prompt includes a `build id`, pass it: `--build <id>` — the
-   workspace's New app screen tracks your progress live) →
-   `monty install` → shape the schema through `monty schema` /
-   `monty schema set` (a brand-new app's very first session lands its
-   monty.config.ts once; after that the workspace owns the schema) + edit
-   `src/routes/` →
-   verify in the session: run `monty dev` once — if the dev shell is already
-   running (the Monty desktop usually runs it for you) it prints the status,
-   app URL, and recent log lines, then **exits immediately**; if nothing
-   is running it starts the shell (start it in the background and move on).
-   Then iterate: edit code → vite hot-reloads → `monty logs -n 50` shows
-   whether it compiled and any browser errors. Re-running `monty dev` is
-   always safe — it attaches, prints status, and exits. Never try to run a
-   second dev *server* for the same app (attach handles this for you) and
-   never kill a dev shell you didn't start; `monty dev --takeover` is the
-   only sanctioned restart when a session is wedged. **You are not done
-   until you've saved: once the work is verified in the session, run
-   `monty save "<what changed>"`** — it builds, typechecks, and pushes the
-   working copy to the cloud copy, like `git push main`. Save after every
-   meaningful change, not just at the end; unsaved work exists only on this
+1. **Respect the folder.** `monty create` scaffolds new apps;
+   `monty connect <slug> [dir]` puts a copy of an existing app in any
+   folder you choose. Never mkdir an app folder by hand and never edit
+   `.monty/app.json` (the identity stamp). `monty current` says which app folder
+   you are in. Every file in the folder rides the source snapshot on
+   `monty save`, so keep scratch files out. Use the OS temp dir, or pipe
+   (`monty schema | <edit> | monty schema set -` needs no file), and delete
+   anything temporary before saving.
+2. **The loop.** `monty create <slug> --name "Name" --icon <tabler-icon>`
+   (pass `--build <id>` when the prompt includes one), then `monty install`.
+   Shape the schema with `monty schema` and `monty schema set`; edit
+   `src/routes/`. Run `monty dev` once. If a shell is already running it
+   prints status and exits; otherwise start it in the background. Then
+   iterate: edit, vite hot-reloads, `monty logs -n 50` shows compile and
+   browser errors. Re-running `monty dev` is always safe. Never start a
+   second dev server for the same app and never kill a shell you didn't
+   start; `monty dev --takeover` is the one sanctioned restart.
+   **You are not done until you've saved.** `monty save "<what changed>"`
+   builds, typechecks, and pushes to the cloud copy, like `git push main`.
+   Save after every meaningful change. Unsaved work exists only on this
    machine.
 3. **Everything through the CLI.** `monty install`, `monty build`,
-   `monty typecheck`, `monty dev`, `monty save` — never run vite, tsc,
-   pnpm, or npm scripts directly. `monty dev` auto-picks a free port and
-   prints it; `monty typecheck` builds first when needed. `monty logs`
-   (add `-f` to follow) is how you read the dev shell's output — vite build
-   errors, browser errors, and save results all land there.
-4. **One import surface:** `@montytools/sdk` (`defineApp`, zod) and
-   `@montytools/sdk/react` (hooks: `useList`, `useInsert`, …). Never import
-   Clerk or Convex directly; never fetch external APIs from app code — the
-   platform CSP blocks them. Open external HTTPS pages with
-   `openExternal(url)` from `@montytools/sdk`, called synchronously from the
-   click or key handler; `window.open` and `target="_blank"` are blocked by
-   the app iframe.
-5. **The data schema lives in the WORKSPACE, not in code.** Read it with
-   `monty schema` (JSON on stdout); change it by editing that JSON and
-   running `monty schema set <file>` — validated server-side, additive by
-   default. On workspace-owned apps, `monty.config.ts` edits do NOT change
-   the schema. Give every field a `description` and every enum/multiSelect
-   a `valueDescriptions` map saying WHEN each option applies — that's the
-   guidance later record-writing agents follow. Declare a page in the
-   manifest BEFORE shipping its route — a save with an undeclared route
-   refuses with the fix. Field names `_*`, `updatedAt`, `createdBy` are
-   reserved.
-6. **Prefer a saved view for filtered tables.** If the request is
-   one table with different filters, sorting, or hidden columns, use
-   `monty views set <table> <name> ...`. For example, an evaluation queue is
+   `monty typecheck`, `monty dev`, `monty save`. Never run vite, tsc, pnpm,
+   or npm scripts directly. `monty logs` (add `-f` to follow) is where vite
+   errors, browser errors, and save results land.
+4. **Import only the SDK.** `@montytools/sdk` (`defineApp`, zod) and
+   `@montytools/sdk/react` (hooks: `useList`, `useInsert`, ...). Never
+   import Clerk or Convex; never fetch external APIs from app code, the CSP
+   blocks them. Open external pages with `openExternal(url)` from the SDK,
+   called synchronously from the click handler. `window.open` and
+   `target="_blank"` are blocked in the app iframe.
+5. **The schema lives in the workspace, not in code.** Read it with
+   `monty schema` (JSON on stdout), change it with
+   `monty schema set '<json>'` — the whole config as one JSON argument, or
+   piped: `monty schema | <edit> | monty schema set -` (validated
+   server-side, additive by default). `src/monty.gen.ts` is the GENERATED
+   mirror of that config — import `{ app }` from it for typed hooks, never
+   edit it (it regenerates within a heartbeat of any change while
+   `monty dev` runs). Give every field a
+   `description` and every enum a `valueDescriptions` map saying when each
+   option applies; record-writing agents follow that guidance later.
+   Declare a page before shipping its route (`monty page add <name>` does
+   both); a save with an undeclared route refuses. Field names `_*`,
+   `updatedAt`, `createdBy` are reserved.
+6. **Prefer a saved view for filtered tables.** One table with different
+   filters, sorting, or hidden columns is `monty views set <table> <name>`.
+   An evaluation queue:
    `monty views set leads "Evaluate" --filter '{"pipelineId":null}'`.
-   Change selected properties or rename it later with
-   `monty views update <table> <name> ...`; omitted properties stay unchanged.
-   If that table needs actions, compose `RecordPage` from
-   `@montytools/sdk/react` and add typed row/header/selection/record actions
-   with the controls from `@montytools/sdk/ui`. Write the whole page yourself
-   only when the shared components no longer fit. Custom pages remain the
-   escape hatch.
-7. **UI is stock shadcn** (preset already wired). Add curated components with
-   `monty add <name>`; browse with `monty components` / `monty docs <name>`.
-   How pages should LOOK — Lyra surfaces, dark-only, the chart language — is
-   the `monty-design` skill; read it before styling any page.
+   A board: `--kanban <select-field>` lanes records by that field
+   (`monty views set deals "Pipeline" --kanban stage`). Update later with
+   `monty views update`; omitted properties stay unchanged. If the table
+   needs actions, compose `RecordPage` from `@montytools/sdk/react` with
+   controls from `@montytools/sdk/ui`. Write a whole custom page only when
+   the shared components no longer fit.
+7. **UI is stock shadcn** (preset already wired). Install curated components
+   with `monty components add <name>`; `monty components [query]` lists the
+   catalog, `monty components docs <name>` prints one's source. How pages
+   should look is the `monty-design` skill; read it before styling.
 8. **Errors are instructions.** Every failure prints
-   `[MontyError CODE] Fix: …` — do exactly what the Fix says; don't guess.
-   Typecheck failures block the save by design.
+   `[MontyError CODE] Fix: ...`. Do what the Fix says. Typecheck failures
+   block the save by design.
 9. **Edits are real.** The dev shell reads and writes the app's LIVE
-   records — there is one set of data, and every write journals into the
-   app's Activity. Exercise the app for real; clean up test rows you
-   create; never seed junk into a team's working tables.
+   records, and every write journals into the app's Activity. Exercise the
+   app for real, clean up test rows, never seed junk into a team's tables.
 10. **Report platform failures when sharing is enabled.** `monty support
-   status` shows whether a workspace admin has allowed agent support
-   reports. If enabled, submit one report when a Monty platform error still
-   blocks the task after you followed its `Fix` and retried, or when the
-   requested work needs a missing Monty platform feature. Summarize the
-   thread. State the observed problem, expected behavior, attempted fixes,
-   and exact error. Do not paste the full conversation. If sharing is off,
-   ask the user before running `monty support enable --yes`; never grant
-   consent yourself. Do not file reports for ordinary app-code bugs or send
-   duplicates for the same incident.
+   status` shows whether an admin allowed agent reports. If enabled, submit
+   one report when a platform error still blocks you after following its
+   Fix, or when the task needs a missing platform feature. State the
+   problem, expected behavior, attempted fixes, and exact error. Don't
+   paste the conversation. If sharing is off, ask the user before running
+   `monty support enable --yes`. No reports for ordinary app-code bugs, no
+   duplicates.
 
 ## CLI reference
 
 | command | purpose |
 |---|---|
-| `monty login` | browser sign-in (loopback authorize), once per machine |
-| `monty create <slug>` | register the app in the workspace + stamp it into `~/.monty/apps/<id>` (needs login) |
-| `monty current` / `select` / `apps` | where am I / jump to app / list local |
-| `monty install` / `build` / `typecheck` | full lifecycle via the CLI — no raw pnpm/vite/tsc |
-| `monty dev` | run the app's session, or attach to an already-running one (auto-port, live data, auto-auth) |
-| `monty logs [-n N] [-f]` | read/follow the dev shell log — the debugging window after every edit |
-| `monty add <name…>` | install curated shadcn components |
-| `monty schema [slug]` | print the app's stored manifest (tables, pages, metrics) as JSON |
-| `monty schema set <file\|->` | write an edited manifest back (validated, CAS, additive by default) |
-| `monty views <list\|set\|update\|remove> <table>` | manage the shared saved views on a system record page |
-| `monty save ["what changed"]` | push the working copy to the cloud copy, like `git push main` (build + typecheck gate it) |
-| `monty support <status\|enable\|disable\|submit>` | manage consent and send a bounded agent-authored platform report |
-| `monty skills` | (re)install this skill for your agent |
+| `monty login` | browser sign-in, once per machine |
+| `monty connect <slug> [dir]` | pull an existing app into any folder, ready for `monty dev` |
+| `monty create <slug>` | register a new app and scaffold it (needs login) |
+| `monty current` / `select` / `apps` | where am I / jump to app / list local copies |
+| `monty install` / `build` / `typecheck` | lifecycle, no raw pnpm/vite/tsc |
+| `monty dev` | run the app's session, or attach to a running one |
+| `monty logs [-n N] [-f]` | read/follow the session log |
+| `monty save ["what changed"]` | push the working copy to the cloud copy (build + typecheck gate it) |
+| `monty history [slug]` | saved-version history, one row per save |
+| `monty schema [slug]` | print the app's config (stored in the workspace) as JSON |
+| `monty schema set '<json>'` (or `set -` piped) | write the edited config back (validated, CAS) |
+| `monty views <list\|set\|update\|remove> <table>` | manage shared saved views |
+| `monty page add <name>` | declare + scaffold a custom page |
+| `monty components add <name...>` | install curated shadcn components |
+| `monty support <status\|enable\|disable\|submit>` | consent + platform reports |
+| `monty skills` | (re)install this skill |

package/skills/monty-design/SKILL.md

@@ -1,45 +1,92 @@
 ---
 name: monty-design
-description: Design Monty app pages — Lyra shadcn styling (borderless, sharp-cornered, stock components only), dark-only theming, and the Monty chart language (square marks on real axes). Use whenever building or restyling UI in a Monty app; pages, dashboards, charts, stat tiles, KPI rows, tables, or any prompt about how a Monty app should look.
+description: Design Monty app pages — the Monty design tokens (type ladder, radius policy, elevation), Lyra shadcn styling (sharp surfaces, stock components only), dark-only theming, and the Monty chart language (square marks on real axes). Use whenever building or restyling UI in a Monty app; pages, dashboards, charts, stat tiles, KPI rows, tables, or any prompt about how a Monty app should look.
 ---
 
 # Designing Monty pages
 
 Monty is a B2B work OS. Apps render inside the platform shell, so a page is
-"designed" when it looks native to Monty: quiet, rectilinear, data-forward.
-The design system is already installed — your job is to NOT fight it.
-
-## The one law: stock Lyra, nothing invented
-
-Every app ships shadcn preset `radix-lyra` (see `components.json`). Lyra
-surfaces are **borderless and sharp-cornered**: `Card` is `rounded-none`,
-no border, a `bg-card` fill with a hairline `ring-1 ring-foreground/10`.
-
-- Use the components as they come: `Card`/`CardHeader`/`CardTitle`/
-  `CardDescription`/`CardContent`, `Table`, `Badge`, … Never rebuild a
-  surface as a styled `div` — a hand-rolled `rounded-xl border bg-…` card is
-  the canonical mistake.
-- Never invent tokens or raw colors. Semantic tokens only (`bg-background`,
-  `text-muted-foreground`, `border-border`, `var(--chart-2)`, …).
-- Sanctioned overrides are content-level only: e.g. `text-2xl tabular-nums`
-  on a stat value, a width on a label column. If an override styles a
+"designed" when it is indistinguishable from the shell around it: quiet,
+rectilinear, data-forward. The design system is already installed — the shell
+and every app share ONE token sheet (`@montytools/sdk/tokens.css`, imported
+by `src/index.css`) and one component surface. Your job is to NOT fight it.
+
+## The one law: tokens and stock components, nothing invented
+
+- Use components as they come: `Card`/`CardHeader`/`CardTitle`/
+  `CardDescription`/`CardContent`, `Table`, `Badge`, `Button`, … Never
+  rebuild a surface as a styled `div` — a hand-rolled `rounded-xl border`
+  card is the canonical mistake.
+- Never write a raw value the tokens already name: no hex/oklch colors, no
+  `text-[13px]`, no `rounded-[10px]`, no hand-written `shadow-[…]`.
+  Semantic utilities only (`bg-background`, `text-muted-foreground`,
+  `var(--chart-2)`, `shadow-control`, …).
+- Sanctioned overrides are content-level only: `tabular-nums` on values, a
+  width on a label column, `capitalize` on an enum. If an override styles a
   SURFACE, you are off the system.
 
+## The type ladder — six styles, and fewer is better
+
+One class per role; each carries its size, line-height, weight, and
+tracking. **Hierarchy comes from weight and ink, never from inventing
+sizes.**
+
+| Class | Size | Use |
+|---|---|---|
+| `text-tick` | 10/12 | chart axis ticks ONLY |
+| `text-meta` | 12/16 | column headers, chips, captions, timestamps, secondary values |
+| `text-body` | 13/20 | THE DEFAULT — content, controls, table cells (already on `body`) |
+| `text-title` | 14/20 · 500 | card titles, page-header titles, nav rows |
+| `text-heading` | 18/24 · 600 | page-level headings (rare — `PageHeader` owns page tops) |
+| `text-stat` | 24/32 · 600 | stat-tile values, always with `tabular-nums` |
+
+A typical page uses three: `text-body` (inherited — write nothing),
+`text-meta` for secondary lines, `text-stat` on tile values. Reach for the
+others only when the role in the table matches. Weights: default 400,
+`font-medium` for titled/interactive text; 600 arrives only via
+`text-heading`/`text-stat`. Never `font-bold`, never `text-xs/sm/lg/2xl` —
+those sizes exist for legacy chrome, not for pages.
+
+## Radius policy — sharp, everywhere
+
+Lyra is rectilinear: surfaces, controls, and overlays are ALL square-
+cornered. Cards/tables/tiles/chips are `rounded-none` with `bg-card ring-1
+ring-foreground/10` hairlines, never borders; buttons, inputs, dialogs, and
+popovers come sharp from the stock components. Elevation and hierarchy come
+from hairlines and the three shadows, never from softened corners.
+`rounded-full` (avatars, status dots) is the ONE exception — write no other
+`rounded-*` class yourself; the semantic names the chrome uses
+(`rounded-control`, `rounded-overlay`) resolve to 0 by policy.
+
+## Color and status
+
+The palette is the platform's; you never pick colors. Ground `bg-background`,
+surface `bg-card`, ink `text-foreground`/`text-muted-foreground`, quiet fill
+`bg-accent`, the one accent `bg-primary`, links `text-link`. Status is a
+**dot + muted text**, never a colored pill: `text-success`, `text-warning`,
+`text-destructive` for the dot/figure, label in `text-muted-foreground`.
+Elevation: `shadow-control` on rest-state controls, `shadow-btn-primary` on
+the one primary action, `shadow-menu` on overlays — never `shadow-md/lg/xl`.
+
+## Spacing — the 4px grid, three names
+
+Page bodies are `p-page` (24px); cards pad themselves; card grids are
+`gap-3` (12px); control rows `gap-2`. Stay on the default Tailwind steps
+(`p-1`…`p-6`); if you're typing an arbitrary value like `p-[18px]`, the
+layout is wrong, not the scale.
+
 ## Dark-only, in the shell's palette
 
-The Monty shell is dark-only; a light page inside it reads as broken. The
-app theme's `.dark` tokens mirror the shell palette (#101112 ground,
-#17181A cards, #266DF0 primary) so embedded pages are seamless — never
-retheme or hand-pick your own dark colors. Until
-the template ships dark by default: `class="dark"` on `<html>` in
-`index.html`, and any boot-splash background set to the dark `--background`
-value. Verify your page against the shell, not in isolation.
+Monty is dark-only; the tokens ship the shell palette (#101112 ground) and
+`index.html` carries `class="dark"` plus the dark boot splash. Never
+retheme, never hand-pick a dark color, and verify your page against the
+shell (`/apps/<slug>/…`), not the bare dev port.
 
 ## Page anatomy
 
 Every page opens with the platform chrome from `@montytools/sdk/ui` — the
-SAME components the shell renders system table views with, so a custom page
-is indistinguishable from a record page. Never hand-roll the header bar.
+SAME components the shell renders system table views with. Never hand-roll
+the header bar.
 
 ```tsx
 import { PageHeader, PageHeaderButton } from "@montytools/sdk/ui";
@@ -50,7 +97,7 @@ import { PageHeader, PageHeaderButton } from "@montytools/sdk/ui";
     <PageHeaderButton primary onClick={main}><Plus className="size-3.5" /> New</PageHeaderButton>
   </PageHeader>
   <div className="min-h-0 flex-1 overflow-auto">
-    <div className="flex flex-col gap-3 p-6 pt-4">
+    <div className="flex flex-col gap-3 p-page pt-4">
       {/* KPI row */}
       <div className="grid grid-cols-[repeat(auto-fill,minmax(14rem,1fr))] gap-3">…</div>
       {/* section cards */}
@@ -72,36 +119,35 @@ A stat tile is a stock Card, nothing more:
 <Card size="sm">
   <CardHeader>
     <CardDescription>Leads added</CardDescription>
-    <CardTitle className="text-2xl tabular-nums">{value}</CardTitle>
-    <div className="text-xs text-muted-foreground">{delta or context}</div>
+    <CardTitle className="text-stat tabular-nums">{value}</CardTitle>
+    <div className="text-meta text-muted-foreground">{delta or context}</div>
   </CardHeader>
 </Card>
 ```
 
 ## Charts: sharp marks on real axes
 
-Chart marks are **sharp rectangles — no rounded corners, ever** (matches the
-Lyra rectilinear look). The three failure modes to avoid: pill "track+fill"
-bars (read as progress bars), rounded caps (misstate where a value ends),
-and floating bars with no axis (nothing anchors the eye).
+Chart marks are **sharp rectangles — no rounded corners, ever**. The three
+failure modes to avoid: pill "track+fill" bars (read as progress bars),
+rounded caps (misstate where a value ends), and floating bars with no axis
+(nothing anchors the eye).
 
 - **Horizontal bars**: grow from a left hairline baseline
   (`border-l border-foreground/25`) over quarter gridlines
   (`absolute left-1/4|1/2|3/4 border-l border-foreground/10` —
   foreground-alpha so hairlines read on any surface), bar `h-4`,
-  fill `var(--chart-2)`. Label left in `text-muted-foreground`
-  (fixed-width, truncate); count right in `font-medium tabular-nums`,
-  zero values muted with no fill.
+  fill `var(--chart-2)`. Label left in `text-body text-muted-foreground`
+  (fixed-width, truncate); count right in `text-body font-medium
+  tabular-nums`, zero values muted with no fill.
 - **Columns**: a value axis with a baseline (`border-foreground/25`) plus
-  hairline gridlines (`border-foreground/10`) and tiny tabular tick labels (10px, muted,
-  right-aligned in a left gutter). Round the axis top to a "nice" integer
-  (≤4 exact; else the next multiple of 5/10/50) so ticks stay honest.
-  Direct value labels above non-zero columns.
-- **Color**: one accent ramp from the Monty palette — `var(--chart-2)` for
-  the emphasized series (today, the selection), `var(--chart-5)` for
-  context. The values are the platform's (Attio-blue family, matching the
-  shell); never restate them as hex, never a hue per category, and text
-  never wears the data color.
+  hairline gridlines (`border-foreground/10`) and `text-tick` tabular tick
+  labels (muted, right-aligned in a left gutter). Round the axis top to a
+  "nice" integer (≤4 exact; else the next multiple of 5/10/50) so ticks
+  stay honest. Direct `text-tick` value labels above non-zero columns.
+- **Color**: one accent ramp — `var(--chart-2)` for the emphasized series
+  (today, the selection), `var(--chart-5)` for context. Never restate the
+  values as hex, never a hue per category, and text never wears the data
+  color.
 - **Numbers**: `tabular-nums` everywhere values align; money via
   `toLocaleString(undefined, { style: "currency", currency: "USD" })`
   (compact notation on tiles, full in tables).
@@ -109,15 +155,18 @@ and floating bars with no axis (nothing anchors the eye).
   muted line ("No activity logged on this day.") — structure stays, zeros
   carry meaning.
 
-Reference implementations: `ColumnChart` and `BarRow` in
-`demos/crm/src/routes/stats.tsx` (day-selector columns, status bars) and
-`demos/crm-v2/src/routes/stats.tsx` (money detail on bars, top-deals table).
+Reference implementations: `demos/crm-v2/src/routes/stats.tsx` (KPI tiles,
+day-selector columns, status bars, top-deals table) and
+`demos/crm-v2/src/routes/reports.tsx` (stat tiles over live records).
 
 ## Checklist before you call a page done
 
-1. No `border`/`rounded-*` on any surface you authored — surfaces are stock
-   Lyra components.
-2. No rounded corners on any chart mark; every bar/column sits on an axis.
-3. Dark: the page blends into the shell with no light seams.
-4. Values in tabular figures; labels in text tokens; one accent hue.
-5. Screenshot it inside the shell (`/apps/<slug>/…`), not just the dev port.
+1. No `border`/`rounded-*` anywhere you authored (`rounded-full` on dots
+   and avatars is the one exception) — surfaces and controls are stock
+   components, sharp by policy.
+2. No text class outside the six ladder styles; no arbitrary values
+   (`text-[…]`, `bg-[#…]`, `rounded-[…]`, `shadow-[…]`).
+3. No rounded corners on any chart mark; every bar/column sits on an axis.
+4. Dark: the page blends into the shell with no light seams.
+5. Values in tabular figures; status as dot + muted text, never a pill.
+6. Screenshot it inside the shell (`/apps/<slug>/…`), not just the dev port.