@palate/cli 0.0.0-stage → 0.0.1

package/kb/sections/pricing-usage-calculator.md

@@ -0,0 +1,93 @@
+---
+id: pricing-usage-calculator
+name: One plan priced by the product's own unit
+kind: pricing
+shape: split
+layout: "left: one or two inputs in the product's unit (seats, builds, GB, credits); right: the total with its formula and what is included, updating live"
+fits: [saas, developer, ai, b2b, technical, honest, trustworthy, productivity, data-rich]
+avoid: [luxury, fashion, playful-kids, enterprise-compliance, kids, food, portfolio]
+needs: ["a real usage-based price model (unit prices, free quota, tiers)", "the median customer's usage as the default", "one signup or start action"]
+imagery: none
+density: balanced
+moves: [interactive-pricing-calculator]
+effort: m
+---
+
+## When it's right
+
+Price depends on one to three continuous quantities and the bill can be computed in advance: API calls, build minutes, stored GB, seats with volume steps, AI credits. The visitor's real question is "what will I pay?", so the section answers it with their number. Implements the move `interactive-pricing-calculator` as a full section. Not for flat plans (a calculator adds nothing; use `pricing-plans-ledger`) or prices that need negotiation.
+
+## Structure
+
+```
+1440 ─ container 1200, 12-col grid
+┌──────────────────────────────────────────────────────────────────────────┐
+│ H2 "Pay for the builds you run"                                          │
+│ one line: what the unit is and what's free                               │
+│                                                                          │
+│ ┌ inputs (cols 1–6) ───────────────┐  ┌ total (cols 7–12) ─────────────┐ │
+│ │ Builds per month        [ 3,000 ]│  │ $48 / month                    │ │  ← total, display size
+│ │ ●━━━━━━━━━━━━○────────────────── │  │ 3,000 builds × $0.02 = $60     │ │  ← formula, each term
+│ │ 100   1k    10k   100k   1M      │  │ − first 600 free     = −$12    │ │  ← free quota struck as a saving
+│ │                                  │  │ ─────────────────────────────  │ │
+│ │ Team seats              [   5  ] │  │ Included: unlimited projects,  │ │
+│ │ ●━━━━━○───────────────────────── │  │ logs 30 days, email support    │ │
+│ │                                  │  │                                │ │
+│ │ "Typical team: 3k builds, 5 seats"│  │ [ Start with 600 free builds ] │ │  ← primary
+│ └──────────────────────────────────┘  │ Volume price from 50k: $0.015  │ │
+│                                       └────────────────────────────────┘ │
+│ No minimum. Billed monthly in USD, excl. tax. Cancel any time.           │
+└──────────────────────────────────────────────────────────────────────────┘
+```
+
+```
+390 ─ one column
+H2, line
+[ total card: $48 / month, formula ]   ← sticky to the top of the section while the inputs scroll under it
+inputs stacked, each slider full width with its number field on the label row
+included list, primary button full width, footnote
+```
+
+At 390 the total card comes first and is `position: sticky` within the section (top 16px) so the number stays in view while the visitor drags. The ruler labels under each slider thin to three (min, middle, max).
+
+## Finish
+
+- Two columns of equal height; the total sits on a raised surface (`--shadow-1` (resting, `_finish.md`), `--r-lg`), the inputs sit on the page with no box. One container, not two cards (M23).
+- Total: display size of the page's scale (about 48–64px at 1440), weight 600, `tabular-nums`, unit in small size secondary. Formula lines in small size, `tabular-nums`, terms right-aligned in a two-column grid so the numbers stack; the free quota line in the success or accent colour with a minus sign.
+- Inputs: native range + number field per quantity, labelled. Track 4px, thumb 20px with a 44px hit area; filled part of the track in the accent, rest in `--hairline`. Log scale for ranges that span orders of magnitude, snapping to 1/2/5 × 10ⁿ. Ruler labels in small tertiary type.
+- Hairline between formula and "Included" list (see `_finish.md` hairlines). Included list: 3–5 items, body size, no icons or a single check glyph in secondary colour.
+- One primary button, full width of the total surface, label carries the free quota or trial ("Start with 600 free builds"). The page's `.btn-primary`.
+- The tier note ("Volume price from 50k: $0.015") in small secondary type; when the input crosses that tier, the matching formula term gets a 600ms background tint.
+
+## Content
+
+- The unit must be the product's real billing unit, named the way the invoice names it.
+- Default values = the median real customer, written under the inputs as a plain hint ("Typical team: …"), not the cheapest scenario.
+- The formula must match billing exactly: tax, minimums and overage stated in the footnote. If billing and calculator can drift, don't ship the calculator.
+- No invented discounts, no "save 40%" without the arithmetic shown.
+
+## States and motion
+
+- Total updates instantly as inputs move; no count-up, no tween on the digits. Width reserved so it doesn't jump.
+- Zero usage: total reads "$0 / month" with "within the free quota" under it. Maximum: past the self-serve limit, the total is replaced by the stated threshold and a "Talk to us" secondary button, with the reason ("Above 1M builds we set a committed price").
+- `aria-live="polite"` on the total, updated after 400ms of no input. Keyboard steps match the snapping.
+- Optional: inputs written to the URL query so a buyer can share the scenario (numbers only).
+- No-JS: the default scenario is server-rendered with its formula; inputs are hidden.
+
+## Pitfalls
+
+- A slider without an exact number field.
+- Linear slider over 100 to 1M: everything useful in the first 2% of the track.
+- A total without the formula: it looks like a sales trick.
+- "Contact sales" appearing above an unstated threshold.
+- Two bordered cards side by side with a gap: the inputs and their result read as unrelated.
+
+## Floor checks
+
+- Is there a single large total that a visitor can read in one glance?
+- Is the arithmetic behind the total shown, term by term, with numbers aligned?
+- Does each input have both a slider and an exact number field with a visible label?
+- Is the free quota or included amount visible as a saving in the formula?
+- Is there exactly one primary call to action, and does its label say what the visitor starts with?
+- Is there a line stating currency, tax and minimums?
+- At 390, is the total visible while the inputs are being changed?

package/kb/sections/printed-menu-card.md

@@ -0,0 +1,110 @@
+---
+id: printed-menu-card
+name: The menu as a printed card
+kind: pricing
+shape: list-ruled
+layout: "the menu set like the card on the counter: a dated paper sheet on the page ground, 2–3 headed groups in columns, each dish a name, one line of what's in it and a price on a dot leader; allergen marks with a key; today's special pinned on as a slip"
+fits: [food, local, warm, crafted, heritage, tactile, retro, honest]
+avoid: [saas, developer, b2b, enterprise, data-dense-tool]
+needs: ["the real menu with real prices: 8–24 items in 2–4 groups", "allergens or dietary marks per dish, from the kitchen", "the date or week the card is for, and one special or seasonal note if there is one"]
+imagery: texture
+density: balanced
+effort: m
+moves: [layered-paper-depth]
+---
+
+## When it's right
+
+The place sells food, and the honest answer to "what can I get and what does it cost?" is the menu itself. A bakery's buns and loaves, a restaurant's weekly card, a café's board: visitors open the site to read it, often on a phone outside the door. Setting it like the printed card on the counter (paper, ruled groups, prices on leaders, a date at the top) makes it feel like the place, not like a shop catalogue, and it is the fastest thing to scan.
+
+This replaces "pricing" for food and hospitality. Not for a shop with hundreds of products and a basket (that is a catalogue), not for menus that are only a PDF link (set the text, link the PDF as well), and not when prices are not published (say "market price" honestly per item rather than hiding the whole card). A plan-style ledger (`pricing-plans-ledger`) is for software; never put dishes in plan columns.
+
+## Structure
+
+```
+1440 ─ container 1240; the card is a sheet ~1000 wide, centred or on cols 2–11, on --paper-2
+┌──────────────────────────────────────────────────────────────────────────────────────────┐
+│ H2 "This week's menu"                                  Pre-order by Thu 9 pm →           │
+│                                                                                          │
+│      ┌ the card: paper sheet, fibre texture, --shadow-1 ──────────────────────────┐      │
+│      │ MABEL'S BAKEHOUSE · Week of 3 November                    ┌ slip, rotated ┐│      │
+│      │ ───────────────────────────────────────────────────────── │ This weekend: ││      │
+│      │ BUNS                               │ BREAD                │ brown butter  ││      │
+│      │ Cardamom bun ............... £3.40 │ Country sourdough .. │ & pear danish ││      │
+│      │ milk dough, cardamom sugar   G D E │ 1 kg, Borders flour  └───────────────┘│      │
+│      │ Cinnamon knot .............. £3.20 │ Seeded rye ......... £6.80             │      │
+│      │ butter, cinnamon, demerara   G D E │ rye, sunflower, flax     G S          │      │
+│      │ Box of 6 buns .............. £18   │                                       │      │
+│      │ ──────────────────────────────────── ──────────────────────────────────── │      │
+│      │ CAKES  (5 days' notice)                                                   │      │
+│      │ Lemon & elderflower .... from £42                                          │      │
+│      │ ───────────────────────────────────────────────────────────────────────── │      │
+│      │ G gluten · D dairy · E egg · N nuts · S sesame.  Ask us about anything.   │      │
+│      └───────────────────────────────────────────────────────────────────────────┘      │
+└──────────────────────────────────────────────────────────────────────────────────────────┘
+  card padding --s-8; groups in 2 columns with a vertical hairline between; dish rows --s-4 apart
+```
+
+```
+390 ─ the card goes full width minus 16; one column
+┌──────────────────────────────┐
+│ H2 "This week's menu"        │
+│ ┌ card ────────────────────┐ │
+│ │ Week of 3 November       │ │
+│ │ ┌ slip: this weekend … ┐ │ │  ← the special sits first, unrotated
+│ │ └──────────────────────┘ │ │
+│ │ BUNS                     │ │
+│ │ Cardamom bun ..... £3.40 │ │
+│ │ milk dough, cardamom  GDE│ │
+│ │ BREAD                    │ │
+│ │ …                        │ │
+│ │ key: G gluten · D dairy  │ │
+│ └──────────────────────────┘ │
+│ [ Pre-order for the weekend ]│
+└──────────────────────────────┘
+```
+
+At 390 the groups stack in one column inside the card, which spans the width minus 16px each side with padding `--s-5`. Dish name and price stay on one line (the leader shrinks; the name wraps before the price ever moves to its own line). The special slip comes first, straight, full width of the card. The action sits under the card, full width.
+
+## Finish
+
+- The card: one sheet on `--paper-2` ground, `--surface` or a warmer paper tone, `--r-sm` (paper has nearly square corners), `--shadow-1`. Paper fibre texture from `_finish.md` at 4–6% so it reads as stock, not as a flat box. One sheet only; not a card per dish (M36).
+- Type: the menu is the place's printed voice. Group heads in caps at `--t-small`, tracking +0.08em, weight 600. Dish names `--t-body` weight 500–600 in the display or text face; the description line `--t-small`, `--ink-2`, italic if the type system has one. Prices `tabular-nums`, right-aligned on one edge per column.
+- Leaders: a dotted leader between name and price (`border-bottom: 1px dotted var(--hairline-strong)` on a flex spacer aligned to the baseline), or no leader with prices in a right-aligned column; pick one for the whole card.
+- Allergen marks: single letters or short words in `--t-caption`, `--ink-2`, after the description, explained in a key at the foot of the card. Never coloured icons or chips.
+- Group rules: a 1px hairline under each group head and a full-width hairline before the key. Columns separated by a vertical hairline or `--s-8` of air, not both.
+- The special: a small slip (`--paper` lighter tone, `--shadow-2`, rotated −2° to 2° at 1440) or a rubber-stamp style line in the accent colour; one per card. Pairs with move `layered-paper-depth` for the slip sitting on the sheet.
+- Date line at the top of the card: the place's name in caps and the week or day the card is for. A menu without a date reads as stale.
+
+## Content
+
+- Every dish, price and allergen from the kitchen's real menu; nothing invented. "from £42" only where the price really varies.
+- One line per dish in the kitchen's own words ("ember-roasted beets, whipped feta, burnt honey"), never marketing adjectives ("delicious", "artisanal").
+- Practical notes where they apply: "until sold out", "5 days' notice", "dietary needs with 48 hours' notice", "12 seats held for walk-ins".
+- The action is the real next step: "Pre-order for the weekend", "Book a table", or none if the place is walk-in only.
+
+## States and motion
+
+- Static. The card is text (selectable, searchable, read by screen readers as headings and lists), never an image of a menu.
+- Sold out or off today: the item stays with a hand-ruled strike (`text-decoration: line-through` in `--ink-3`) and "sold out" in words, not removed.
+- A link "Download the card (PDF)" under it when the kitchen has one.
+- Hover on nothing; no entrance animation. The slip may settle 2° on load below the fold, off under reduced motion.
+
+## Pitfalls
+
+- Dishes as product tiles with photos, "Add to cart" buttons and star ratings: that is a delivery app, not this place's menu.
+- Status pills ("Vegan", "New", "Popular") in coloured capsules: use the allergen key and one plain word.
+- A menu as a JPG or PDF only: unreadable on phone and invisible to search.
+- Prices in a column that does not line up, or price jumping under the name on phone.
+- An undated menu, or last season's dishes still listed.
+- A texture so strong the small description lines lose contrast.
+
+## Floor checks
+
+- Does the menu read as one printed sheet (one card, groups, rules) rather than a grid of product tiles or app cards?
+- Does every dish have a name, a one-line description and a price that line up on a shared right edge?
+- Are allergens or dietary marks shown in plain letters or words with a key, rather than coloured pills or icons?
+- Is the card dated (the day or week it is for)?
+- Is today's special or seasonal note shown once, set apart like a slip or stamp?
+- Is the small description text clearly readable over the paper texture?
+- At 390, is the menu a single column with each price on the same line as its dish and nothing scrolling sideways?

package/kb/sections/process-happening.md

@@ -0,0 +1,102 @@
+---
+id: process-happening
+name: The process shown happening
+kind: process
+shape: timeline
+layout: "three stages laid along one horizontal track, each a small real product fragment; one item (a card, a file, a request) visibly travels from stage to stage and changes state at each; short stage labels under the track"
+fits: [saas, productivity, developer, ai, b2b, technical, honest, crafted, friendly, education]
+avoid: [luxury, heritage, crisis, low-bandwidth, local, food, nonprofit, portfolio, travel]
+needs: ["a real process with 2–4 stages a user goes through", "one item that changes visibly at each stage (status, shape, content)", "a product fragment for each stage, built in code"]
+imagery: product-ui
+density: balanced
+effort: m
+moves: [code-drawn-diagram, honest-progress-narration, shape-continuity-morph, calm-motion-system]
+---
+
+## When it's right
+
+The page needs a "how it works", and the honest answer is a short process: you connect, it checks, it ships; you upload, it sorts, your team reviews. The median page answers with a row of numbered columns of prose (M22, L14) that nobody reads. This archetype shows the process happening instead: one item enters at the left, moves through three stages built from real product fragments, and comes out changed. The motion is the explanation.
+
+Use it once, in the middle of the page, when the steps are real and few. If the process is the product's whole flow with many beats, use `self-playing-run-demo`; if each step needs a paragraph, use `sticky-feature-narrative`.
+
+Not for processes with five or more steps, or where nothing visibly changes between steps.
+
+## Structure
+
+```
+1440 ─ container 1240; track spans cols 1–12
+┌──────────────────────────────────────────────────────────────────────────────────────┐
+│ H2 h2, one line, left                                    one-line lead, ink-2, right │
+│                                                                                      │
+│ ┌ stage 1 fragment ────┐        ┌ stage 2 fragment ────┐        ┌ stage 3 fragment ─┐│
+│ │ e.g. inbox row       │        │ e.g. checks running  │        │ e.g. live, shared ││
+│ │ ┌──────────┐         │        │  ✓ types   ✓ tests   │        │  ┌──────────┐     ││
+│ │ │ ▣ item   │─────────┼────────┼──▶ ◌ preview         │────────┼─▶│ ▣ item ✓ │     ││
+│ │ └──────────┘         │        │                      │        │  └──────────┘     ││
+│ └──────────────────────┘        └──────────────────────┘        └───────────────────┘│
+│  ────────●──────────────────────────────●─────────────────────────────●───────────── │ ← track: hairline,
+│  Connect                                Check                         Ship           │   filled up to the item
+│  one line, small, ink-2                 one line                      one line       │
+└──────────────────────────────────────────────────────────────────────────────────────┘
+  fragments ~360×240 each, gaps --s-7; the item is one DOM node that moves between them
+```
+
+```
+390 ─ side padding 16; the track turns vertical
+┌──────────────────────────────┐
+│ H2                           │
+│ ● Connect                    │  ← vertical hairline track on the left,
+│ │ ┌ stage 1 fragment ──────┐ │    a dot per stage
+│ │ └────────────────────────┘ │
+│ ● Check                      │
+│ │ ┌ stage 2 fragment ──────┐ │
+│ │ └────────────────────────┘ │
+│ ● Ship                       │
+│   ┌ stage 3 fragment ──────┐ │
+│   └────────────────────────┘ │
+└──────────────────────────────┘
+```
+
+At 390 the track runs down the left edge (a 1px vertical hairline 8px from the gutter, a dot per stage) and the fragments stack at full width minus 24px, each at most 220px tall. The item does not travel between fragments; each fragment shows the item in its state at that stage, and the stage being viewed fills its dot.
+
+## Finish
+
+- Fragments: three small product frames (`_finish.md` product frame, but with `--r-md` and `--shadow-1`: they are supporting pieces, not the hero). Same size, same top edge, each showing only the part of the product that does that stage (L02). Text inside at least 13px.
+- The item: one card-like element (`--surface`, `--r-sm`, `--shadow-2` while moving, `--shadow-1` at rest) that carries real content (a file name, a request title). Its state is visible at a glance: a status chip that changes text and colour, a checkmark, a shape that grows. Use one DOM node moved with a FLIP transform, or the View Transitions API with a shared `view-transition-name` (move `shape-continuity-morph`), so it reads as the same object.
+- Track: 1px `--hairline-strong` under the fragments, filled in `--ink` up to the item's current stage (`transform: scaleX()` on an overlay, origin left). Stage dots 9px, hollow until reached, then filled.
+- Stage labels: one or two words in `--t-body` weight 600, `--ink`, plus one line in `--t-small`, `--ink-2`. Numbering only if the product numbers its steps; otherwise the track's order is enough (M17).
+- Heading row: H2 left, a one-line lead right on the same baseline. Heading to fragments `--s-7`; fragments to track `--s-5`; track to labels `--s-3`.
+- Ground: `--paper` if the previous section was on `--paper-2`, or the reverse; nothing else raised.
+
+## Content
+
+- Three stages (two or four at most), named with the product's own verbs.
+- The item is a real, plausible example in the product's domain ("invoice-0912.pdf", "Fix login timeout"), not "Item 1".
+- Each fragment shows what the product actually does at that stage, with real labels. If a stage takes time in reality, the fragment says so ("usually under a minute").
+- No invented throughput or "instant" claims.
+
+## States and motion
+
+- Server and no-JS: all three fragments shown with the item's state at each stage, the track fully filled. This is also the reduced-motion view.
+- With motion: when the section is well in view, the item starts in stage 1, waits 1.2s, moves to stage 2 (500ms ease-out `cubic-bezier(.23,1,.32,1)` along the track), stage 2's fragment does its work (checks tick, 1–2s), the item moves to stage 3 and lands with its final state. Hold 3s, reset with a 300ms crossfade, loop. Pause off screen and while hovered or focused.
+- Each stage's fragment is quiet until the item arrives (dimmed to 60%, no motion), then active: the eye follows the item.
+- An `aria-live="polite"` sr-only line names the current stage; the fragments are `aria-hidden` with a text summary of the process.
+
+## Pitfalls
+
+- A row of numbered columns with an icon and a paragraph each (M22, M17): documentation, not a demonstration.
+- Fragments that are generic boxes with skeleton bars only, so nothing shows what the stage does.
+- The item teleporting (disappear here, appear there) instead of travelling: the continuity is the point.
+- Five or six stages squeezed into the row.
+- Arrows between stages as the only sign of a process, with no change in the item.
+- At 390, a horizontal track that scrolls sideways or shrinks the fragments to thumbnails.
+
+## Floor checks
+
+- Are there three stages (between two and four), each with a product fragment rather than only an icon and a paragraph?
+- Does the same item appear in each stage, visibly in a different state at each one?
+- Is the order of stages clear from a single track or path connecting them?
+- Is each stage named in one or two words, with at most one line of supporting text?
+- Is the section free of numbered columns of prose (four or more columns of heading plus paragraph)?
+- In a static or reduced-motion screenshot, are all stages filled with their content rather than empty?
+- At 390, are the stages stacked vertically along a visible track, with readable fragments and no sideways scrolling?

package/kb/sections/project-index-ruled.md

@@ -0,0 +1,106 @@
+---
+id: project-index-ruled
+name: Ruled project index with a peek image
+kind: gallery
+shape: list-ruled
+layout: "a ruled list of every project or commission, one row each: year, project, client, place, discipline, set in columns like a catalogue raisonné; hovering or focusing a row shows its picture pinned beside the list; selected rows carry a small thumbnail on phone"
+fits: [portfolio, agency, editorial, minimal, quiet, crafted, publishing, artsy]
+avoid: [saas, developer, b2b, playful-kids, gaming]
+needs: ["12–60 real projects with year, name, client or subject, place and discipline", "one picture per project (or for the ones that have one)", "a page or anchor for each project, or at least the selected ones"]
+imagery: photo
+density: balanced
+effort: m
+moves: [link-preview-peek]
+---
+
+## When it's right
+
+A studio or practice with a body of work too large for a gallery and too serious to be cropped into tiles: an architecture office with 64 completed buildings, a sound studio with 120 credits, a print studio with years of commissions, a type foundry's custom work. The index says "this is everything, in order", which is the strongest proof a practice can give: range, consistency and time. The peek image keeps it visual without making it a wall of thumbnails.
+
+Pair it with one `case-study-band` or the `gallery-first-hero` above it: the hero shows the best, the index shows the whole. Not for fewer than 12 projects (use `masonry-real-work` or two `case-study-band`s) and not when the projects have no facts to put in the columns.
+
+## Structure
+
+```
+1440 ─ container 1240; list in cols 1–8, peek pinned in cols 9–12
+┌──────────────────────────────────────────────────────────────────────────────────────────┐
+│ Projects 2012–2026                                   [All] [Schools] [Houses] [Cabins]   │ ← H2 small, filters as words
+│ 64 completed, 11 in construction                                                         │
+│ ─────────────────────────────────────────────────────── ┌ peek, cols 9–12, sticky ─────┐ │
+│ 2026  Ilsvika Housing        32 flats    Trondheim   In c│                               │ │
+│ ─────────────────────────────────────────────────────── │   picture of the hovered      │ │
+│ 2024  Lia Skole ▸            School      Malvik      5,90│   row at its own ratio        │ │ ← the hovered row: ink, arrow,
+│ ─────────────────────────────────────────────────────── │                               │ │   others stay ink-2
+│ 2022  Hus Fjæra              House       Hitra       180 │                               │ │
+│ ─────────────────────────────────────────────────────── └───────────────────────────────┘ │
+│ 2021  Bakkeløkka Cabins      6 cabins    Oppdal      —   │ Lia Skole, Malvik, 2024        │ ← peek caption
+│ ─────────────────────────────────────────────────────── │                                 │
+│ 2020  …                                                                                  │
+│ ─────────────────────────────────────────────────────────────────────────────────────────│
+│ Showing 24 of 64 · Show all projects ↓                                                   │
+└──────────────────────────────────────────────────────────────────────────────────────────┘
+  columns: year 64px · project flex · discipline 140 · place 140 · size/credit 120, right-aligned figures
+```
+
+```
+390 ─ two-line rows; selected projects carry a thumbnail
+┌──────────────────────────────┐
+│ Projects 2012–2026           │
+│ [All][Schools][Houses] → ⇢   │ ← filters scroll inside their row
+│ ──────────────────────────── │
+│ ┌────┐ Lia Skole             │ ← 64×80 thumbnail for selected
+│ │    │ 2024 · School · Malvik│   projects only
+│ └────┘                       │
+│ ──────────────────────────── │
+│ Hus Fjæra                    │
+│ 2022 · House · Hitra         │
+│ ──────────────────────────── │
+│ Show all projects ↓          │
+└──────────────────────────────┘
+```
+
+At 390 each row becomes two lines: the project name in `--t-body` weight 600, then year · discipline · place in `--t-small`, `--ink-2`. The peek is gone (hover doesn't exist); projects that have a page carry a 64×80 thumbnail at the left. Rows are at least 56px tall and the whole row is the tap target.
+
+## Finish
+
+- Rows: 52–56px tall at 1440, 1px `--hairline` between rows (`_finish.md` hairlines), one `--hairline-strong` above the first. No zebra, no row backgrounds, no vertical rules. Columns share x positions down the whole list (P01).
+- Type: year in `--t-small` `tabular-nums`, `--ink-2`; project name in `--t-body` weight 500, `--ink`; the other columns `--t-small`, `--ink-2`; sizes and counts right-aligned with `tabular-nums` and their unit ("5,900 m²", "3 h of music").
+- Hover/focus row: the project name and the row's facts go to `--ink`, a small arrow (▸ or →) slides in 4px after the name over 160ms, and the peek shows that row's picture. No row highlight block.
+- The peek: `position: sticky; top: 20svh` in cols 9–12, picture at its own ratio within a 4:5 maximum box, no card, no shadow, radius `--r-sm` or none; caption under it in `--t-caption`. With move `link-preview-peek`, the picture crossfades (120ms) between rows. When nothing is hovered, the peek shows the most recent or a chosen project, never an empty box.
+- Filters: words, not pills: `--t-small`, `--ink-2`, the active one in `--ink` with an underline 2px below the baseline. Changing a filter crossfades the list (150ms).
+- Ground: `--paper`; the index is the quiet section after the hero's pictures.
+- "Show all" reveals the rest in place (a `<details>` or a button that expands), so the page never paginates.
+
+## Content
+
+- Every row is a real project with facts the practice can stand behind. Columns are chosen per practice: architecture (year, project, type, place, area), sound (year, title, medium, director or studio, role), print (year, job, client, run, colours).
+- "In construction", "in production" are words in the right column, not badges.
+- Order by year, newest first, unless the practice files them another way. Do not reorder to hide quiet years.
+- Project names link to their page where one exists; rows without a page are not links and don't pretend to be (no arrow).
+- The count line under the heading ("64 completed, 11 in construction") is true and matches the list.
+
+## States and motion
+
+- No-JS and reduced motion: the full list is server-rendered (first 24 shown, the rest inside an open-able `<details>`), the peek shows one fixed picture, filters are links to filtered anchors or hidden.
+- Keyboard: rows are links in reading order; focusing a row updates the peek exactly as hover does; the focus ring spans the row.
+- Peek pictures preload lazily after the section enters view (the next 6 rows' pictures), each with its dominant colour as background so the swap never flashes white.
+- Empty filter: one line ("No cabins yet.") and a link back to All.
+
+## Pitfalls
+
+- A grid of identical thumbnails pretending to be an index, losing every fact.
+- Tag pills for disciplines, status badges for "In construction": app chrome where words belong.
+- A peek that follows the cursor and covers the next rows.
+- Columns that drift (right-aligned figures in one row, left in the next).
+- A tiny 12px grey list that fails contrast because "it's minimal".
+- At 390, the desktop columns squeezed into one line and truncated to "Lia S… 2024 Sch…".
+
+## Floor checks
+
+- Is the work presented as a ruled list with consistent columns (year, project, client or type, place) rather than a grid of tiles?
+- Do the columns line up down the whole list, with figures right-aligned and in tabular numerals?
+- On desktop, is there a picture beside the list showing a project (not an empty box), so the index stays visual?
+- Are disciplines and statuses written as words rather than coloured pills or badges?
+- Is the list long enough to show range (12 or more real projects), with a way to see all of them?
+- Is all text in the list clearly readable, including the secondary columns?
+- At 390, does each project become a readable two-line row with no truncated columns and no sideways scrolling?

package/kb/sections/proof-logo-cloud-with-reasons.md

@@ -0,0 +1,82 @@
+---
+id: proof-logo-cloud-with-reasons
+name: Customer logos with presence and a reason
+kind: proof
+shape: cards-row
+layout: "6–8 real customers in a grid; each shows its mark in brand colour at 32–40px, the company name, and one line on what they use the product for"
+fits: [saas, b2b, enterprise, developer, trustworthy, honest, technical, ai, finance]
+avoid: [luxury, artsy, portfolio, playful-kids, crisis]
+needs: ["6–8 real customers who agreed to be named", "their marks as SVG", "one true sentence per customer on what they use it for"]
+imagery: none
+density: balanced
+effort: s
+---
+
+## When it's right
+
+The product has recognisable customers who have agreed to be shown. The usual logo strip (faint grey wordmarks, M46) proves little because visitors can't tell what the companies do with the product. This version gives each customer presence: their mark in colour, their name in text, and one line on the job they use it for. Only if real; with no named customers, use `proof-output-wall` or `proof-measured-numbers`.
+
+## Structure
+
+```
+1440 ─ container 1200, 4 columns × 2 rows
+┌──────────────────────────────────────────────────────────────────────────┐
+│ H2 "Who runs on it"                                 Read their stories → │
+│ ┌──────────────────┬──────────────────┬──────────────────┬──────────────┐ │
+│ │ ◆ Northwind      │ ● Halcyon Labs   │ ▲ Pallet & Co    │ ■ Fieldnote  │ │  ← mark 36px + name, same row
+│ │ Deploys 140 sites│ Runs nightly eval│ Ships the store  │ Previews every│ │  ← one line, what for
+│ │ for clients      │ suites           │ front end        │ PR            │ │
+│ ├──────────────────┼──────────────────┼──────────────────┼──────────────┤ │
+│ │ ◆ …              │ ● …              │ ▲ …              │ ■ …          │ │
+│ └──────────────────┴──────────────────┴──────────────────┴──────────────┘ │
+│ cells divided by hairlines, not boxed; a cell with a story links to it    │
+└──────────────────────────────────────────────────────────────────────────┘
+```
+
+```
+390 ─ 2 columns × 4 rows
+mark 32 + name on one line (name wraps under if long)
+one line, small, up to 2 lines
+```
+
+At 390, two columns; the reason line clamps to two lines. If there are 8 customers, all stay visible (no carousel).
+
+## Finish
+
+- Grid of cells divided by hairlines (inner borders only, `_finish.md` hairlines); no card boxes, no shadows. Cell padding 24 at 1440, 16 at 390.
+- Mark: the customer's symbol or compact mark in its brand colour at 32–40px (square-ish marks 36px; long wordmarks sized by area per D34, never taller than 24px). One treatment for all: every mark in colour (D33); if any customer forbids colour, every mark goes mono at ≥ 3:1 contrast (D35).
+- Name: body size, 600, primary colour, next to the mark on its vertical centre, 12px gap. The name is text even if the wordmark already says it, so it reads and translates.
+- Reason: small size, secondary colour, one line (two at most), 8px under the name.
+- A cell with a case study: the whole cell is a link with a quiet hover (background tint one step, arrow appears); others are not links.
+- Heading left, "Read their stories" text link on the same baseline right.
+
+## Content
+
+- Only customers who agreed, in writing, to be shown. Record it.
+- The reason line is specific and true ("Deploys 140 client sites"), checked with the customer. Numbers in it must be theirs.
+- 6–8 entries. Fewer than 4: use a quote (`proof-single-honest-quote`) instead. More than 8: pick the most relevant to the page's audience.
+- Never logos of companies whose employees merely signed up, never "as seen in" without the article.
+
+## States and motion
+
+- Static. No marquee: the reason lines need reading.
+- Hover and focus on linked cells only; focus ring inside the cell.
+- Marks are `<img alt="">` or inline SVG `aria-hidden` because the name is text beside them.
+- Dark mode: marks that disappear on dark (black wordmarks) use the customer's approved light version.
+
+## Pitfalls
+
+- Grey logos at 40% opacity in a single strip (M46).
+- Mixed colour and mono marks in one grid.
+- Every wordmark at the same height, so long names dominate.
+- Reason lines that are slogans ("Loves our platform").
+- Logos with no consent.
+
+## Floor checks
+
+- Is every customer shown with its name as readable text next to its mark?
+- Does every customer have a line saying what they use the product for?
+- Are the marks all in one treatment (all colour or all mono) and clearly visible, not faint?
+- Are marks visually balanced in size so no long wordmark dominates?
+- Is the grid divided by quiet hairlines rather than heavy boxed cards?
+- At 390, are all customers still shown without a carousel?

package/kb/sections/proof-measured-numbers.md

@@ -0,0 +1,88 @@
+---
+id: proof-measured-numbers
+name: Numbers measured from the product itself
+kind: proof
+shape: list-ruled
+layout: "three or four numbers the product measures about itself, each in a ruled row with how it was measured, when, and a small trace of the data behind it"
+fits: [developer, technical, honest, data-rich, scientific, saas, ai, b2b, hardware, trustworthy, sustainability]
+avoid: [luxury, fashion, playful-kids, kids, crisis]
+needs: ["3–4 numbers the product or team actually measured", "for each: the method, the sample size or period, and the date", "the underlying series or distribution for a small trace (optional)"]
+imagery: none
+density: balanced
+moves: [inline-sparklines-in-copy]
+effort: m
+---
+
+## When it's right
+
+The product's best proof is a number it produces about itself: median build time, uptime from the status page, the share of checks that passed, the size of the bundle, the count of real outputs. Unlike a stat banner (M11), each number here carries its method and date, so it reads as evidence, not filler. Good for developer and technical products before they have quotable customers. Not when the numbers would be estimates, round guesses, or vanity counts with no method.
+
+## Structure
+
+```
+1440 ─ container 1200
+┌──────────────────────────────────────────────────────────────────────────┐
+│ H2 "What we measure, and how"                                            │
+│ one line: where these numbers come from, link to the raw data            │
+│ ────────────────────────────────────────────────────────────────────────  │
+│ 9.4 s        median time from push to live URL     ▁▂▃▅▇▅▃▂▁  (dist.)    │  ← number | meaning + method | trace
+│              12,480 deploys, 1–30 Sep 2026, all regions                   │
+│ ────────────────────────────────────────────────────────────────────────  │
+│ 99.98 %      uptime of the build API, last 90 days  ▇▇▇▇▇▇▇▆▇▇  (daily)   │
+│              from our public status page ↗                                │
+│ ────────────────────────────────────────────────────────────────────────  │
+│ 41 KB        JavaScript this page ships, gzipped    [measured on load]    │  ← can be computed live
+│              measured in your browser just now                            │
+│ ────────────────────────────────────────────────────────────────────────  │
+└──────────────────────────────────────────────────────────────────────────┘
+cols: number 1–3 | meaning + method 4–9 | trace 10–12
+```
+
+```
+390 ─ stacked rows
+9.4 s
+median time from push to live URL
+12,480 deploys, 1–30 Sep 2026
+▁▂▃▅▇▅▃▂▁   (full width, 32px tall)
+──────────
+```
+
+At 390 each row stacks: number, meaning, method, then the trace at full content width. Hairlines stay between rows.
+
+## Finish
+
+- Rows separated by full-width hairlines in `--hairline` (`_finish.md` hairlines); 32px vertical padding per row at 1440, 24 at 390.
+- Number: between `--t-h2` and `--t-display` (48–64px at 1440), weight 500–600, `tabular-nums`, unit in a smaller size on the same baseline (P25). Number column left-aligned so units align.
+- Meaning: body size, primary colour, one line. Method: small size, secondary colour, with sample size, period and a source link.
+- Trace: a sparkline or tiny distribution drawn in SVG from the real data, 120–200px wide, 32–40px tall, stroke 1.5px in the accent for the series and `--hairline` for the axis baseline (see `inline-sparklines-in-copy`). `aria-hidden`; the number is the text.
+- No icons, no cards, no count-up.
+- One live row is optional and strong: a number measured on the visitor's own load (page weight, time to interactive), computed client-side and labelled "measured in your browser just now".
+
+## Content
+
+- Each number: what it means in plain words, how it was measured, when, from what sample. If any of the three is missing, cut the number.
+- Prefer medians and percentiles to averages; say which.
+- Link to the source where public (status page, benchmark repo, changelog).
+- Three or four numbers; never pad to four with a weak one. No "10x", "50k+ users" or rounded marketing figures.
+
+## States and motion
+
+- Numbers show their final value immediately (M11). The trace may draw once on entering view (stroke-dashoffset, 600ms) and is drawn in full under reduced motion or with no JS.
+- The live row shows "measuring…" for under a second, then the value; if the browser API is missing, the row shows the last measured lab value with its date.
+- Source links have hover and focus states.
+
+## Pitfalls
+
+- A row of four giant numbers with no methods: that's M11 again.
+- Numbers from a one-off benchmark presented as typical.
+- Sparklines invented to decorate rather than drawn from the data.
+- Mixing units and precisions ("99.98 %" next to "10k+").
+
+## Floor checks
+
+- Does every number say how and when it was measured?
+- Are the numbers specific (not rounded to "10x", "50k+", "99%") and in tabular figures?
+- Does each number have a plain-words meaning next to it?
+- Is there a source link or a pointer to where the data lives?
+- Is every number visible in its final value without waiting for an animation?
+- Are rows separated by consistent hairlines with aligned columns?