{"ok":true,"protocol":"aimeat","version":"v1","node":"aimeat-finland-001-genesis","timestamp":"2026-11-04T10:17:02.789Z","request_id":"req-4847817c","data":{"id":"build-app-atelier","name":"Build an AIMEAT app on the Atelier track","description":"The Atelier track's build spec: the served component kit, the look presets, the imagery pipeline and the track rules. Separate from /v1/prompts/build-app on purpose — two tracks, two guides.","mode":"new","lang":"en","prompt":"## First, a short interview\n\nUnless you are Claude Opus or Claude Fable, open that message with one sentence: apps built with Claude Opus or Claude Fable turn out noticeably better, and they can switch now or go on with you.\nAsk, in one message, and wait for answers:\n1. What should the app do, in one or two sentences?\n2. Who uses it — just you, or others too (shared data)?\n3. How should it look and FEEL? (Map the answer to a look from the table below.)\n4. Which languages should it speak?\n5. Anything it must NOT do?\n\nBEFORE YOU SEND THESE QUESTIONS, start the app's structure page: call `aimeat_app_manage` action `structure_set` with a `filename`, `name`, `purpose` and `proposals.layout`, two or three layouts you drew for this app. Give `page_url` from its answer in one sentence and point question 3 there: the person sees the steps and picks a layout and a look by seeing them, or says \"you decide\". Do not list the steps in the chat; the page shows them. After the answers, read action `structure`: a choice with `\"state\": \"waiting\"` is theirs. Section \"The structure page\" (part `libraries`) has the rest.\n\n**Then the data map: three more questions, before any code.** Ask them with the questions above, in plain words. Skipped, an app goes wrong unnoticed: a company asked for ONE shared list of candidates and got an app where every person keeps their own.\n(a) Who opens the app: just you, your organisation (which organisation?), or anyone?\n(b) For each kind of data the app keeps (name each one from the idea): whose is it? PERSONAL (each person their own), SHARED BY THE TEAM (one common set that everybody in the organisation reads and edits), or PUBLIC (anyone may see it)?\n(c) Who may change the shared data: everyone in the team, or only some roles?\n**Then confirm with a scenario, and wait for a yes.** Before you build, write back in the person's own language two or three sentences drawn from THEIR idea, with named people, for example: \"So I understood: when Teemu adds a candidate, Maija sees them at once in the same list. When Maija marks a candidate as a favourite, only Maija sees the mark. Nobody outside the company can open the app. Is that right?\" Build only after they say yes. If they correct you, write the scenario again with the correction.\n\n## The structure page: the person follows the build\n\nEvery app has a structure page: the steps the app goes through (purpose, data, layout, look, build, builders, visibility, requirements), what is done and what is open, and a place where the person can pick a layout and a look by seeing them. Using it is the person's choice, and your work goes on whether they open it or not.\n- As soon as you know the app's name and purpose, call `aimeat_app_manage` action `structure_set` with `filename`, `name` and `purpose` (over HTTP: PUT /v1/apps/me//structure). Give the person `page_url` from the answer in one sentence: they can follow the app there and choose a layout and a look if they want to. The page shows the steps, so leave them out of the chat and ask there only what needs words; the person picks the layout, the look and who sees the app on the page too.\n- In the same first call, draw two or three layouts for THIS app in `proposals.layout`, each with an `id`, a `name`, a `note` on what it gives the person and a `sketch`: rows top to bottom, each `{ \"height\": \"s\" | \"m\" | \"l\", \"cells\": [{ \"w\": \"full\" | \"main\" | \"side\" | \"half\" | \"tiny\", \"label\": \"...\", \"tone\": \"ink\" | \"sun\" }] }`, labels in the person's language. Make them differ in what matters for this app (for a game: the board alone, the board with a side panel, the board with its layers beside it). The page shows them first and the node's presets after them, so the person picks by seeing; `proposals.nav` works the same way when the way between views is a real choice. When the person picks one, the choice's value is its id, and a note on it is what they want changed.\n- After the data map questions, write `data`: `{ \"summary\": \"what the app keeps and whose it is\", \"personalData\": \"yes\" | \"no\" | \"unstated\" }`. While you build, write `now`, one line on what you are doing; the page shows it live.\n- Before you build the screens, and whenever the person says they chose something, read action `structure`. A choice with `\"state\": \"waiting\"` is the person's: build it, then write the same value with `\"state\": \"done\"`.\n- When the person leaves the choice to you, choose `layout` (one of your proposals or a preset), `nav` and `look` from `values` in the structure answer, and write each with `note`, one sentence on why. Until a choice is made, leave it unset: the page then says the AI decides. A genre you fork from is `genre`, its Design Book id. When the person says who may see the app, write `visibility` (listed, community or unlisted).\n\n## Then propose, and wait for the answer\n\nBefore any code, show the owner what you are about to build, in their words, and wait. They decide from this; they must not find out what you chose by looking at the result.\n\n- **FIRST, THE LEVEL. It is the owner's choice and never yours; ask it in these words or plainer ones, and say what each one gets them.** (1) **A quick prototype**: a working draft to try one idea, the kit's components as they come, no styling. Fast, and plain to look at. (2) **An ordinary page**: works and looks tidy, with a ready layout and a ready look from the Design Book, following their light and dark theme. Not distinctive. (3) **The finest**: a committed look forked from a genre, proven parts from the Design Book, components of its own where the book has none. It takes the longest and is the one worth showing. All three are built the same way underneath, in two languages, with the data kept on their node, so a prototype can be raised to the finest later without starting over: say that, because it is what makes the quick one a safe choice. If they do not answer, recommend one and say why; never pick a lower one silently because it is less work. The page states the level: ``, `\"plain\"` or `\"fine\"`. On `proto` and `plain` the rest of this list shrinks to the languages, who signs in and the first screen: no genre is forked, the page starts from the Atelier shell (`aimeat_app_template_get { id: \"shell-atelier\" }`), the publish asks for no register, and nothing is styled by hand (a publish warns when such a page carries a sheet of styles of its own). On `fine`, everything below applies, and so does writing down why you took, passed over and made each thing (the build notes, part `book`). A page that states no level is held to `fine`.\n- **Two or three genres, named, each with one sentence on why it fits THIS app** and what the first screen would look like in it. Get them from the genre list (part `genre`, or `aimeat_designbook_search { kind: \"genre\" }`), and look at the owner's own apps first (`aimeat_app_list`): the ones already on Atelier show what they like. Say which one you would take. A look preset with components stacked in it is not on this list: that is the default page every app looks like, and it is what gets sent back.\n- **Fixed colours or following their theme?** Ask it, or recommend one and say why. A fixed genre keeps its own colours in light and dark; a following page changes with the person's theme and palette. Part `genre` says which each genre is and gives an address for each (`See it`), and the whole shelf is one link: send the owner the links so they choose by looking. If they want a genre that is fixed and want it to follow the theme, say that it means moving its colours to the theme's tokens, and that you will show it in both modes before they decide.\n- **What you take from the Design Book.** Look before you make (`aimeat_designbook_search`, part `book`): layouts, fills, looks, motion, ambients and effects that each passed their own bench, adopted in one call. The working screen of the app is a mosaic inside the genre, and its arrangement is where a fill from the book lands (part `book` shows how). THIS LINE IS OWED IN EVERY PROPOSAL, word for word in its shape: \"From the Design Book I take: \", or \"From the Design Book I take nothing, because \". Taking nothing is allowed; taking nothing in silence is not. What you have to make because the book lacks it is written down with its reason in the page's build notes; it is offered to the book when the owner is satisfied with the app, and not because the build is finished.\n- **The languages: English and Finnish, unless they say otherwise.** Two languages is the default on this node. The language you are talking in is not the app's language list. Building for one language is the owner's decision, so ask it as a question if you think one is right, and do not decide it.\n- **Who signs in**, and what is kept for them. An app nobody signs in to says so here.\n- **The data map, and the confirmed scenario.** For each kind of data: personal, shared by the team or public, who may change the shared data, and who opens the app. Repeat the scenario they said yes to; without that yes, ask it now.\n- **The first screen in one or two sentences**: what the person sees and does first. If that sentence is \"a header and some cards\", you have not designed it yet.\n\nOffer it as choices the owner can answer with a word. If they said \"just build it\", still say in one line which genre and which languages you are taking, so they can stop you. Then build on the Atelier track:\n\n## The Atelier track\n\nYou are building on the ATELIER track. Its guide is THIS document and the `node:aimeat-app-builder-atelier` skill — never the standard build spec at /v1/prompts/build-app, whose vocabulary (daisyUI classes, hand-written boilerplate) does not apply here. The app declares `` so a later session loads the right guide.\n\nTHE FIRST MOVE OF THE BUILD IS THE GENRE FORK. An app here starts from a committed register, never from the bare shell: list the genres with `GET https://aimeat.io/v1/designbook?kind=genre`, fork the one that carries the page's register with `GET https://aimeat.io/v1/app-templates/genre-`, and swap the words, sources and images (the genre section below has the menu). Every Atelier app declares the register it committed to — `\">`, which every genre already carries, or `custom:` for a page that commits to a look of its own — and the publish REFUSES an Atelier app that names none.\n\nThe shell is the frame the genres are built on — fetch it to learn the structure, never invent it:\n\n```\nGET https://aimeat.io/v1/app-templates/shell-atelier\n```\n\nIt carries a REPLACE-ME register line on purpose, so published as it is served it is refused: the shell is a frame, not a page. A GAME starts from the game shell instead: the same frame with a Phaser canvas, a title menu, pause, settings and a leaderboard already wired through aimeat-phaser, and its register is the canvas (`custom:game`):\n\n```\nGET https://aimeat.io/v1/app-templates/shell-phaser-game\n```\n\nThe head is eight lines and stays that way: the ceremony (theme restore, login boot, mobile guards, designed states, accessibility wiring, motion) lives in the served kit, not in your file. Every byte you add is a byte you re-read on every edit.\n\n## The components (`AIMEAT.atelier`)\n\nEvery component takes a spec and returns `{ el, set(patch), destroy() }`. Copying an example below yields a finished, beautiful, accessible piece — that is the paved path.\n\n- `app` — The shell that carries the whole ceremony: login pill + boot, language re-render, designed loading/empty/error/sign-in states, the only scrolling region, the bottom chrome reserve, and the ambient layer behind the frame (the look decides; `ambient` names a preset, `{ preset, alpha, speed }`, or `false`). Fill handle.main; switch states with handle.status().\n ```js\n var a = AIMEAT.atelier.app({ title: 'Errands', look: 'vivid', onReady: function (s) { render(a, s); } });\n ```\n- `hero` — The ONE focal band a screen gets (two heroes is shouting, zero is flat). With no image it paints a designed gradient mesh; with an image the text sits on a mode-following scrim. data: URIs are refused — upload to storage and pass the URL.\n ```js\n AIMEAT.atelier.hero({ target: a.main, title: 'Errands', sub: '3 open', actions: [{ id: 'add', label: 'Add', kind: 'primary', onClick: addOne }] });\n ```\n- `statRow` — The KPI strip. On set(), a changed figure counts up — the state-change motion arrives with the data.\n ```js\n var kpis = AIMEAT.atelier.statRow({ target: a.main, tiles: [{ id: 'open', label: 'Open', value: 3 }] }); kpis.set({ tiles: [{ id: 'open', label: 'Open', value: 4 }] });\n ```\n- `list` — Rows keyed by id: set() adds (slides in), removes and updates (flashes) instead of rebuilding. Rows are real buttons when onPick exists; an empty list renders the designed empty state.\n ```js\n var l = AIMEAT.atelier.list({ target: a.main, items: [], onPick: open, empty: { title: 'No errands yet', action: { label: 'Add one', onClick: addOne } } }); l.set({ items: rows });\n ```\n- `listDetail` — The list beside a detail pane, split by a container query: a narrow box shows one pane at a time with a back affordance. You render the detail; select() drives it.\n ```js\n var ld = AIMEAT.atelier.listDetail({ target: a.main, items: rows, renderDetail: function (item, body) { body.textContent = item.title; } });\n ```\n- `cardGrid` — The browsing grid. Every card has an art area with zero images: deterministic monogram washes keep a pictureless grid designed, never grey.\n ```js\n AIMEAT.atelier.cardGrid({ target: a.main, items: products, onPick: openProduct });\n ```\n- `mediaCard` — One card on its own — a feature, a highlight — with an optional action row.\n ```js\n AIMEAT.atelier.mediaCard({ target: a.main, item: { id: 'p1', title: 'Featured' }, actions: [{ id: 'go', label: 'Open', kind: 'primary', onClick: go }] });\n ```\n- `form` — Fields declared as data, accessibility wired for you (labels, hints, worded inline errors, focus to the first problem). Throw { field, message } from onSubmit and the form places your rule like its own. NEVER hand-roll inputs or ARIA.\n ```js\n AIMEAT.atelier.form({ target: dlg, fields: [{ name: 'title', label: 'What', required: true }, { name: 'due', label: 'When', type: 'date' }], onSubmit: save });\n ```\n- `table` — Real table semantics that scroll INSIDE THEIR OWN BOX (the page never widens), sortable headers with aria-sort, tabular numerals.\n ```js\n AIMEAT.atelier.table({ target: a.main, columns: [{ key: 'name', label: 'Name', sortable: true }, { key: 'n', label: 'Count', align: 'right' }], rows: rows });\n ```\n- `searchBar` — Debounced search that reports the query; what it means is your business.\n ```js\n AIMEAT.atelier.searchBar({ target: a.main, onChange: function (q) { l.set({ items: filter(rows, q) }); } });\n ```\n- `timeline` — Events on the vertical line every history and activity view shares.\n ```js\n AIMEAT.atelier.timeline({ target: a.main, items: [{ id: 'e1', ts: Date.now(), title: 'Published', tone: 'ok' }] });\n ```\n- `tabs` — A tab row that reports the pick; you swap the view.\n ```js\n AIMEAT.atelier.tabs({ target: a.main, items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }], onChange: show });\n ```\n- `figure` — The data IS the hero: one giant numeral with its label and context line, counting up on change — use it when a single number is what the person came to see.\n ```js\n AIMEAT.atelier.figure({ target: a.main, value: 48, label: 'Combined storage', sub: 'Monday looks like the wettest day.', delta: '-19% vs last year' });\n ```\n- `section` — The titled card AND the escape hatch: markup the catalogue cannot express goes inside a section body, so custom work keeps the surface, the measure and the entrance. This is the ONLY place raw HTML belongs.\n ```js\n var s = AIMEAT.atelier.section({ target: a.main, title: 'Custom' }); s.body.appendChild(myOwnMarkup);\n ```\n- `emptyState` — The designed empty/error/notice card — spot mark, title, hint, action. Never ship a bare string or a grey box.\n ```js\n AIMEAT.atelier.emptyState({ target: host, title: 'Nothing matched', hint: 'Try another word.' });\n ```\n- `skeleton` — Loading placeholder rows the real content replaces; the shimmer is finite.\n ```js\n var sk = AIMEAT.atelier.skeleton({ target: a.main, rows: 3 }); load().then(function (rows) { sk.destroy(); l.set({ items: rows }); });\n ```\n- `sideNav` — The left column of a working tool: entries with a count and a tone dot, under group headings. Usually through app({ nav: 'side', navItems }), which also folds it into the bottom bar on a phone; handle.nav.set({ value, items }) moves the mark and the counts.\n ```js\n var a = AIMEAT.atelier.app({ title: 'Mail', logo: LOGO_URL, look: 'workbench', nav: 'side', navItems: [{ id: 'setup', label: 'Setup', count: '5/5', tone: 'ok', onPick: show }, { id: 'unclear', label: 'Unclear', count: 1, tone: 'warn', group: 'Waiting for you', onPick: show }] });\n ```\n- `statusBand` — A page's opening card: where things stand (title + one sentence), a progress bar, one primary action. Its body takes a checkGrid.\n ```js\n var b = AIMEAT.atelier.statusBand({ target: a.main, title: 'Ready', text: 'Five of five done.', progress: { value: 5, total: 5 }, action: { label: 'Run a batch', onClick: run } });\n ```\n- `checkGrid` — Readiness tiles: ok, todo (needs the person, click to fix), optional, fail, wait. One line under each title.\n ```js\n AIMEAT.atelier.checkGrid({ target: b.body, items: [{ id: 'mail', state: 'ok', title: 'Mailbox', sub: 'Gmail' }, { id: 'send', state: 'optional', title: 'Forwarding', sub: 'Not in use' }], onPick: fix });\n ```\n- `choiceCards` — Two to four ways to do one thing as a radio group of cards, and a panel under them the app fills for the chosen one.\n ```js\n AIMEAT.atelier.choiceCards({ target: s.body, items: [{ id: 'chat', kicker: 'Your own AI', title: 'Interview me', text: '…' }, { id: 'agent', kicker: 'Connected', title: 'Let an agent do it' }], renderPanel: function (item, host) { host.textContent = item.title; } });\n ```\n- `settingsGroup` — One group of settings: heading and one sentence on the left, the controls on the right capped at a measure; folds to one column on a narrow box. Give each form field a `width` (short, date, medium, long).\n ```js\n var g = AIMEAT.atelier.settingsGroup({ target: a.main, title: 'Batch', hint: 'How much mail one run reads.' }); AIMEAT.atelier.form({ target: g.body, fields: [{ name: 'size', label: 'Messages per batch', type: 'number', width: 'short' }], onSubmit: save });\n ```\n- `progressFigure` — A batch while it runs: \"3 / 10\" as the largest thing, the bar, the item being worked on with step chips, toned tallies. set() counts up.\n ```js\n var p = AIMEAT.atelier.progressFigure({ target: a.main, label: 'Processing', value: 3, total: 10, now: subject, steps: [{ label: 'read', state: 'done' }, { label: 'extract', state: 'now' }], counts: [{ id: 'ok', label: 'Clear', value: 2, tone: 'ok' }] });\n ```\n- `promptPanel` — The person's own AI helps: copy the prompt, paste the answer; expect \"json\" hands onResult the parsed object.\n ```js\n AIMEAT.atelier.promptPanel({ target: panel, prompt: setupPrompt, expect: 'json', onResult: preview });\n ```\n- `queueRow` — A queue item's content (who, when, subject, chips, why it waits), as a list row part.\n ```js\n parts: { row: function (r) { return AIMEAT.atelier.queueRow({ who: r.from, when: r.at, title: r.subject, chips: [{ text: r.klass }] }); } }\n ```\n- `callout` — A tinted note with a tone (info, ok, warn, err) that says why: why an item is unclear, what failed, what to do.\n ```js\n AIMEAT.atelier.callout({ target: detail, tone: 'warn', title: 'Why this is unclear', text: reason });\n ```\n- `margins` — Wide screens: the sides wear the home margin figure.\n ```js\n AIMEAT.atelier.margins(AIMEAT.atelier.marginsOf(prefs));\n ```\n\n## A COMPONENT THAT IS NEARLY RIGHT IS CUSTOMISED, NEVER COPIED\n\nFour doors, the same four on every component; `AIMEAT.atelier.describe(\"list\")` tells you which ones a component has, and `describe()` names every component that answers.\n\n1. **Named parts.** Every element the kit builds carries `data-ak-part=\"\"`; your own CSS reaches it by name — `[data-ak-part=\"aside\"] { … }` — so the rule keeps working when the markup around it changes, which a selector written by DOM depth does not.\n2. **Slots.** `parts: { : value }` on the spec; a value is a string, a DOM node, an array of those, or a function of the row returning one of those. `extra`, `aside`, `before` and `after` are rendered EMPTY and appear the moment you fill them, so a row that needs a third line and a value on the right is `AIMEAT.atelier.list({ items, onPick, parts: { extra: function (r) { return r.note; }, aside: function (r) { return r.amount; } } })` and nothing more. A slot returning `null` removes that part. `parts.row` (`item` on timeline, `card` on kanban) replaces the whole row, and it is still keyed, entered and picked.\n3. **Variants.** `variant: \"dense\"` stamps `data-ak-variant` and the stylesheet reads it, so you PICK a legitimate shape: `dense` and `plain` on list, listDetail, table, timeline, cardGrid, mediaCard, queue, health, kanban, section, searchBar and shelf; `numbered` on list and listDetail; `wide` on cardGrid; `lined` on table; `tall`, `compact` and `center` on hero; `compact`, `trend` and `plain` on statRow; `compact` and `center` on figure; `compact` on rating, aiTask, aiChat and requestPanel; `plain` on doc and board; `fill` on board; `dense` on tabs, bottomNav, segmented, members, workspacePicker, workflowInput and handbook; `dense` and `plain` on fingerprint; `pill` on tabs; `quiet` on section; `ghost` on stateButton; `table` on members and workspaceTeam. An unknown name is refused with a console line naming the real ones.\n4. **Per-component tokens.** `--ak-list-aside-size`, `--ak-stat-figure-size`, `--ak-card-aspect`, `--ak-hero-title-size` and seventy-five more, each defaulting to the value the component already had. Set one on YOUR OWN element and exactly that part changes, in every look and both modes.\n\nA statRow tile and a figure also take `unit` (what the number is measured in) and `direction: \"up\"|\"down\"|\"flat\"` with `delta` (how far it went, in your own words).\n\nEVERYTHING CUSTOMISED STILL MOVES: a slot fills the row the kit already built and keyed, so the entrance, the glide, the exit, the pick and the selection mark are unchanged.\n\nStyle through those four doors and the app keeps every later fix: leave the `.ak-*` selectors to the kit, and put the piece you would have bolted on with wrapper markup into the slot that is waiting for it.\n\nFORK ONLY AS A LAST RESORT: copy the component's markup out of its module and its `.ak-*` rules out of `/lib/aimeat-atelier/*.css`. You keep the tokens, the look and the motion helpers; you give up the keyed reconcile, the designed empty state, the accessibility wiring and every later fix. `describe(id).fork` says what that one costs. The dialog family stays whole whatever happens — the focus trap, Escape and focus return are the browser's through native `` — so your own markup goes in its `body(host)`.\n\n## A LIVING DOCUMENT: A SHEET WHOSE NUMBERS STAND ON EACH OTHER IS A RECORD\n\nWhen what the person asked for is a calculation sheet, a survey, a dosing record, a reading log or a spec that recomputes — anything where moving one number should move the rest — the arithmetic belongs in the document. Fork the genre with `GET https://aimeat.io/v1/app-templates/genre-living` and write ONE JSON record on `aimeat-living`: `{ v: 1, register, look, layout, model }`, where `layout` is an ordinary mosaic arrangement (the same blocks and spans you already write, and the person can rearrange them) and `model.nodes` is one dependency graph. `AIMEAT.living.mount(host, record)` is the only line of code on the page.\n\nASK THE LIBRARY, RATHER THAN TRUSTING ANY LIST. `AIMEAT.living.describe()` names every node type and `AIMEAT.living.describe(\"formula\")` gives its inputs, outputs, options and a worked example, read out of the node modules' own source so it says what this build does. `AIMEAT.living.validate(record)` reads a document WITHOUT running it and answers with every refusal in words — an unknown node, a circle naming the two ids, a unit that will not add, a block that is not there. Call it before you save.\n\nTHE NINE NODE TYPES, one line each so you know what to ask about: `value` (a named quantity, the writable ground the rest stands on), `formula` (a spreadsheet expression over other node ids, worked out with its units and printed as mathematics), `control` (a slider, toggle, pick, number or text field on ONE value), `binding` (one block prop reads one node), `text` (a sentence that changes when the numbers do), `machine` (a statechart in XState's vocabulary, whose output is the state it is in), `source` (a live value from a memory key or from an address), `trigger` (when a machine transitions, the document tells an address or one of the owner's own agents) and `decide` (the decision model reads a text and moves a machine by its own events above a threshold; below it, a person decides; the page then also loads aimeat-decide.js and the app asks for ai:use).\n\nWHERE A NODE LANDS ON THE SCREEN, two roads: a `binding` feeds a kit component — a figure's value, a gauge's reading, a chart's series — and the refresh goes through the mosaic's own door, so the count-up and the glide run for you; and a `block` field on a control, formula, text, machine or value node draws it into a `section` block of the same arrangement, which is where a node goes when the kit has no component for it.\n\nA DOCUMENT CAN ALSO REACH OUT, AND ONLY THROUGH ONE DOOR. A `trigger` fires when a machine TRANSITIONS — not on every recompute — and sends one message carrying the whole state: the document, the time, which machine moved from where to where on which event, every value with its unit and its label, and every machine's state. Its target is a url or one of the owner's agents, and an agent target becomes a task titled with the crossing. A `source` reads the other way, off an address, with a path into the answer and an `every` in seconds; a read that fails keeps the last value and writes the refusal into the node's `stale` output. Both go through the node's `living-hooks` extension as the signed-in caller, so the owner's allowlist decides which hosts may be reached — never the record, and never the browser calling a third party directly. A guest sees both roads disabled with words. Two switches are the owner's: `hooks: { enabled: false }` on the document stops every trigger, and `enabled` on a trigger stops that one. An address that wants a key gets it by NAME: a trigger's or a source's `headers` may carry `{{secret:NAME}}`, which the node fills from the signed-in owner's vault on the way out, so the record holds the placeholder and never the key. The gear dialogs offer the owner's stored names to pick from; a name the owner has not stored fails by name, and the words to give the person are \"store it as NAME on your Access page, section 04 Secrets, or ask your AI\".\n\nTHREE THINGS THAT KEEP IT A DOCUMENT. The arithmetic lives in a formula node, so the person changes what the sheet works out by asking their own AI to edit the record. It computes in the browser and persists as the record, which is a memory key — a slider moves faster than a request returns. And the record names a register the same as any other Atelier page, so the sheet arrives wearing a look somebody designed.\n\nONE LINE IN THE HEAD DECIDES WHETHER THE READER MAY CHANGE THE LIGHT. A genre that hardcodes its palette carries `` beside its register line, and the login pill's light/dark control stands down there rather than doing nothing; a fork inherits that line, so DELETE it (or write `content=\"follows\"`, which genre-living does) as soon as your page's colours are `--ak-*` tokens and it follows the theme — otherwise the switch is dead and the reader's operating system decides light or dark for them.\n\nA LABEL IS A LANGUAGE MAP. Any human-facing string in the record may be written as `{ \"fi\": \"Ilma ovella\", \"en\": \"Air at the door\" }` rather than as a plain string — a label, a hint, a pick's option, a text node's whole template, the words a machine's entry action writes, and a layout block's `title`, `sub` or `caption` — so ONE record is the document in every language it was written for. The page's language decides which is read (the login pill sets it), the record's own `lang` is the fallback and the map's first key the last resort; `describe(\"control\").languages` names the fields a given type takes as a map. Write each language as itself rather than translating one into the other, and give a sentence the SAME `{{ }}` holes in every language — validate() refuses one that reads a node in Finnish and not in English, and refuses a map with no language keys, naming both. Changing language moves the words only: the value a person moved stays where they left it and the machine stays in the state it reached.\n\nTWO SPELLINGS THAT DECIDE WHETHER THE NUMBERS COME OUT RIGHT. A PERCENTAGE IS A LABEL ON A FACE NUMBER: `{ value: 72, unit: \"%\" }` computes as 72, so `rh / 100` is 0.72 and `ln(rh)` is the logarithm of 72, and the two conversions are asked for out loud — `fraction(rh)` gives 0.72 and `percent(x)` gives a hundred times x. A reading in something the library has no unit for is happiest as a plain number with what it is measured in written into its `label`. And `°C` and `°F` are SCALES WITH AN OFFSET, so multiplying one gives a plain number and the formula's own `unit` names the result, which is what makes `{ expr: \"t * 9/5 + 32\", unit: \"°F\" }` mean what its author meant; `convert(t, \"K\")` is how a real conversion is written. Where a statechart stands at the moment it mounts moved between builds, so `AIMEAT.living.version` and `describe(\"machine\")` are the answer for the library THIS node serves.\n\n## Six patterns to copy\n\nEach of these runs as written against the kit this node serves. Copy one, change the words and the data, and the screen it makes is finished.\n\nA LIST THAT ARRIVES — keyed rows, a pick that opens the detail beside them:\n\n```js\nvar jobs = AIMEAT.atelier.listDetail({\n target: a.main,\n items: [],\n empty: { title: 'No jobs yet', hint: 'They appear here as they are booked.' },\n renderDetail: function (item, body) { body.textContent = item.sub; },\n});\nloadJobs().then(function (rows) { jobs.set({ items: rows }); });\n// The rows rise in, keyed by id. On the next set() a new row rises, a gone row fades\n// where it stood, a moved row glides, and a picked row crosses into the detail pane.\n```\n\nA PANEL THAT CHANGES — numbers that count to their new value, with what they are measured in and which way they went:\n\n```js\nvar kpis = AIMEAT.atelier.statRow({ target: a.main, variant: 'trend', tiles: [\n { id: 'booked', label: 'Booked', value: 12480, unit: '€', direction: 'up', delta: '+8%',\n trend: [8, 9, 9, 11, 10, 12] },\n { id: 'due', label: 'Overdue', value: 3, unit: 'jobs', direction: 'down', delta: '-2' },\n] });\nkpis.set({ tiles: [\n { id: 'booked', label: 'Booked', value: 13120, unit: '€', direction: 'up', delta: '+13%',\n trend: [8, 9, 9, 11, 10, 12, 13] },\n { id: 'due', label: 'Overdue', value: 1, unit: 'jobs', direction: 'down', delta: '-2' },\n] }); // each changed figure counts up on its own\n```\n\nA SCREEN THAT SWITCHES — two units of work under one tab row, the crossing already wired:\n\n```js\nvar pane = AIMEAT.atelier.section({ target: a.main, title: 'Open' });\nvar rows = AIMEAT.atelier.list({ target: pane.body, items: open });\nAIMEAT.atelier.tabs({\n target: a.main,\n items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }],\n value: 'open',\n onChange: function (id) {\n rows.set({ items: id === 'open' ? open : done }); // the swap runs inside the kit's\n }, // own screen transition\n});\n```\n\nA FORM THAT LANDS — the confirmation as a toast, the refusal as a dialog, the field rule as a throw:\n\n```js\nAIMEAT.atelier.form({\n target: pane.body,\n fields: [{ name: 'title', label: 'What', required: true },\n { name: 'due', label: 'When', type: 'date' }],\n submitLabel: 'Add job',\n onSubmit: function (values) {\n if (values.title.length < 3) throw { field: 'title', message: 'Give it a few more words.' };\n return save(values).then(function () {\n AIMEAT.atelier.toast({ title: 'Job added', sub: values.title, tone: 'ok' });\n }, function (err) {\n AIMEAT.atelier.dialog({\n title: 'That did not save', text: String(err.message || err), tone: 'danger',\n actions: [{ id: 'ok', label: 'Close', tone: 'primary' }],\n });\n });\n },\n});\n```\n\nA NEARLY-RIGHT ROW — the third line and the right-hand figure the list leaves empty, filled from the row itself:\n\n```js\nAIMEAT.atelier.list({\n target: pane.body,\n items: rows,\n onPick: open,\n parts: {\n extra: function (r) { return r.note; }, // the third line, rendered empty until now\n aside: function (r) { return r.amount; }, // the value on the right\n },\n});\n```\n\nA SHEET THAT RECOMPUTES — the whole page as one record: the slider moves the wall, and the figure, the printed maths, the sentence and the state all follow it:\n\n```js\nvar sheet = {\n v: 1, register: 'genre-living', look: 'vivid',\n layout: { v: 1, nav: 'stack', blocks: [\n { id: 'controls', component: 'section', span: 'full', props: { title: 'The wall' } },\n { id: 'tin', component: 'figure', span: 'half', props: { title: 'Litres of paint' } },\n { id: 'maths', component: 'section', span: 'half', props: { title: 'How it is worked out' } },\n { id: 'note', component: 'section', span: 'full', props: { title: 'What that means' } },\n { id: 'stock', component: 'section', span: 'full', props: { title: 'Tins' } },\n ] },\n model: { nodes: {\n area: { type: 'value', value: 24, unit: 'm^2', min: 2, max: 120, step: 0.5, label: 'Wall area' },\n coats: { type: 'value', value: 2, label: 'Coats' },\n spread: { type: 'value', value: 10, unit: 'm^2/L', label: 'Spread rate' },\n wall: { type: 'control', kind: 'slider', target: 'area', block: 'controls' },\n paint: { type: 'formula', expr: 'area * coats / spread', unit: 'L',\n label: 'Paint needed', block: 'maths' },\n litres: { type: 'binding', block: 'tin', prop: 'value', from: 'paint' },\n advice: { type: 'text', block: 'note', template:\n '{{ area | 1 }} m2 in {{ coats }} coats takes {{ paint | 1 }} litres. '\n + '{{ if paint > 5 }}Buy two tins.{{ else }}One 5 litre tin covers it.{{ end }}' },\n tins: { type: 'machine', block: 'stock', initial: 'one',\n states: { one: { on: { SECOND: 'two' } }, two: { on: { ENOUGH: 'one' } } },\n when: [{ expr: 'paint > 5', send: 'SECOND' },\n { expr: 'paint <= 5', send: 'ENOUGH' }] },\n } },\n};\nAIMEAT.living.validate(sheet); // every refusal in words, before anything is drawn\nAIMEAT.living.mount(a.main, sheet); // the only line of code this page runs\n// m^2 divided by m^2/L is litres, so the unit on `paint` is checked rather than decorative;\n// move `area` to 40 and paint passes 5 L, the sentence changes and the machine goes to two.\n// A bound figure prints a WHOLE number (it counts up to it, and rounds), so the exact\n// reading is the formula's own printout and the sentence: 5 in the tile, 4.8 in the words.\n```\n\n## The mosaic: the arrangement lives outside your file\n\nRender the screen through `AIMEAT.atelier.mosaic(...)` instead of appending components by hand. You declare WHAT the app has — one resolver per data source name, an `onPick`, a `fallback` layout of blocks — and the ARRANGEMENT (order, look, navigation mode) is a stored record the owner's AI can change later with one `aimeat_app_manage` call (action `ui_set`), no republish. Source names are the binding contract: keep them stable across edits. Block ids are part of the same contract: the stored arrangement keeps the old ids after a publish, so a fill for a renamed block never runs. When a version renames or removes a block, replace the arrangement with `aimeat_app_manage` action `ui_set` in the same change, and read `layout: \"kept-existing\"` in the publish answer as that warning.\n\n```js\nvar m = AIMEAT.atelier.mosaic({\n app: a,\n sources: { 'errands.': loadErrandRows }, // name → rows (or a Promise of rows)\n live: { 'errands.': { keyPrefix: 'errands.' } }, // see below — optional\n onPick: function (blockId, item) { open(item); },\n fallback: { v: 1, blocks: [\n { id: 'top', component: 'hero', props: { title: 'Errands' } },\n { id: 'main', component: 'list', props: { source: 'errands.' } },\n ] },\n});\nm.refresh('errands.'); // after your data changed — the change paints with motion\n```\n\nLIVE BY DECLARATION: load `https://aimeat.io/v1/libs/aimeat-live.js` beside the kit and give the mosaic a `live` map — source name → { keyPrefix } naming the memory keys whose change means that source moved. When anything writes those keys (the owner's agent, another device, a schedule), the source re-resolves and the screen repaints with the components' own motion — you never poll, never open a socket, never write a listener. The wiring refuses a memory subscription without a keyPrefix (that would re-fetch on every write anyone makes) and never fires more often than every few seconds. Without the live library on the page the declaration is inert, so it is always safe to write.\n\nEVENTS FIRST, A TIMER LAST. Data that lives on the node reaches the screen because the node said it changed. Before you write `setInterval` around a read, name the event that says this data moved. The owner's records: the `live` map above with a `keyPrefix`. Work an agent does for the app (each stage line of a task, done, failed, a task a schedule created): `live: { jobs: { domains: ['agent-tasks'] } }`, which needs no prefix, and for one task `AIMEAT.agents.watch(agent, taskId, onUpdate)`. The domains an app may hear, each with the permission that opens it: `memory` (memory:read), `agent-tasks` (task:read), `files` (storage:read), `organisms` (organism:read), `workflows` and `scheduler` (workflow:read), `messages` (messages:read), `boards` and `realtime-rooms` (social:read), `wallet` (wallet:read), `knowledge` and `packages` (knowledge:read). `realtime-rooms` says the realtime room list moved: a room opened or closed, a player came or went. Outside a mosaic the same thing is `AIMEAT.live.subscribe(['agent-tasks'], reload, { minIntervalMs: 3000 })`. An event names the domain and never the record, so every change in that domain on the account wakes the page: read while your app has something under way, and re-read the one source that moved. A delete emits its domain as a write does; the aimeat-live description names the few that emit nothing. A timer is right in three cases, and each gets a comment saying which one it is: the data has no event (a public record a signed-out visitor reads, since the stream opens for a signed-in person; an answer from a service outside the node); the text depends on the clock itself (a countdown, \"starts in 5 min\"), which is a repaint and makes no request; one slow read, every ten minutes, that reconciles after a stream that was down. Check it the way a person meets it: start the work and watch the screen follow each stage within a few seconds.\n\nThe layout's `nav` field projects the same blocks as stacked sections, a tab row, a bottom bar, a swipeable deck, a step-by-step flow, a pan-zoom canvas, a desktop-grade left rail (`rail`) or a full-screen menu in display type (`overlay`) — all of them work on every screen size, so never build navigation by hand. On the stacked grid, blocks below the fold reveal as the person scrolls; that too is the kit's, never yours to code.\n\nTwo more one-field decisions, both data and both optional. `choreography: \"cinema\"` makes scroll the camera: the opening band recedes as the person leaves it and each section rises to meet them — right for a front, a story or a report, wrong for a tool someone lives in, and free at idle because it is pure CSS scroll timelines. And a chart block may carry `presentation: \"mural\"`: the chart stops living in a tile and becomes the section's full-bleed ground — the data as the decor, one mural per screen.\n\nTHE MACHINE ROOM IS AN ARRANGEMENT, NOT APP CODE. Four blocks make any admin or monitoring screen: `health` (one row per watched thing — lamp, name, latest reading), `queue` (work items with states, counted in a strip), `gauge` (ONE value on a dial, bands turning the tone) and `console` (the log vane — monospace, capped, follows the tail only while the reader is at the tail). Their tones ride the theme's ok/warn/err colours, so a status screen reads at a glance in every look and mode.\n\nCHARTS ARE A FAMILY on one block: `chart` with `kind: \"axes\"` (bars, lines and filled areas — a series may be kind \"area\"; `stacked: true` piles the bars into one column per label, `horizontal: true` turns ranked things sideways, and a `note` puts a one-line story bubble on the point that matters — every axes chart answers touch with a tooltip on its own), `\"donut\"` (parts of a whole — the total in the middle, and a `delta` puts its change there too), `\"calendar\"` (a stretch of days as a heat grid, months named) or `\"scatter\"` (points on two measures with an honest trend line), `\"funnel\"` (stages losing people — the survival rate written at each step), `\"treemap\"` (shares as area when the donut's slices would not fit), `\"flow\"` (where the quantity went — ribbons as wide as their sums) or `\"radar\"` (profiles on spokes — one polygon per series, for \"strong where, weak where\"). A statRow tile carrying `trend: [numbers]` draws its short history as a filled sparkline under the figure.\n\nWORK AGAINST PEOPLE AND TIME is its own family: `kanban` (work as columns by state — queue shows the same work as a list, this is the board, and with onMove wired the cards actually move), `plan` (stretches on a shared time axis with today drawn as a line — timeline tells what happened, this tells what is running) and `schedule` (a week as a grid, bookings as blocks — chart kind \"calendar\" is the year at a distance, this is next week). And two small truth-tellers: `steps` (where a process stands — done behind, current lit, the rest ahead) and `rating` (a score as stars, display only — collecting one is a form's job).\n\nWHEN THE OWNER SAYS \"A MAP\", THEY MEAN THE REAL ONE: the `map` block is Leaflet over OpenStreetMap street tiles — pins with popups at real addresses, the view framing the markers on its own, the licence's attribution built in, dark mode re-toning the tiles. The `atlas` block is the different, narrower thing: an offline choropleth of countries for data-by-country, no streets on it. Reaching for atlas when the owner asked for a map is a wrong answer with a confident face.\n\nAnd when a screen has earned a SHOWPIECE, the `scene3d` block gives it real depth: `kind: \"orb\"` (a signature object turning under the hand), `\"sky\"` (a procedural atmosphere band), `\"bars\"` (the bound rows stand up as a field of columns — the 3D chart), `\"model\"` (a .glb/.gltf by URL, fitted, grounded and studio-lit like a product shot) or `\"globe\"` (the earth — places as dots, data travelling between them as lifted arcs). One per layout, loaded lazily, colours from the look's tokens, and the render loop stops at rest so an idle scene costs nothing. It is a statement, not a default: most screens want a chart, not a scene.\n\nCOMPOSE, do not pile: a block may carry `span` — `full` (default), `main` + `side` for the asymmetric editorial split, or `half` — and the screen becomes a laid-out page instead of a column of cards. Narrow screens fold every span to one column on their own.\n\nA SETTINGS PAGE AND A QUEUE PAGE HAVE RULES, and a wide screen is where they break. The kit's form fills its container and the page is as wide as the screen, so on a desktop every field becomes a line across the room. Twelve rules, each from a design system or a usability study: (1) no input fills a wide page: a form field's `width` is short (a number), date, medium (a name or email) or long (a URL or a line of text, 32rem), full width only on a phone; (2) help text is at most 60ch per line; (3) one column, the label above its field, and only short related fields share a row; (4) every group of settings is a `settingsGroup` with a heading and ONE sentence of help, and no field stands outside a group; (5) from 840 px the group puts its help in a left column beside the controls, below that above them, and the groups of one page share ONE card divided by hairlines (target them into `
`), each control saving on change; (6) a tool with more than two screens uses `app({ nav: 'side' })`: the pages in a left column, the content capped at 65rem; (7) advanced settings go behind ONE closed disclosure (`reveal`); (8) the primary button aligns left with the inputs, says its verb and spans the width on a phone; (9) a setup screen opens with a `statusBand` (\"5 of 5 done\" and a bar) holding a `checkGrid`, and each missing step is one tile with one fix a tap away; (10) a batch of ten seconds or more is a `progressFigure`: \"3 / 10\", the item being worked on and its steps; (11) a number that changed flashes in place without moving (`attention(el, \"flash\")`); (12) every item an AI classified offers \"Why?\" (a `callout` with the answer, the reason and the data it saw) and \"Correct\", which says what it changes and from when. A work queue is `listDetail`, its queues listed in the side column with counts. THE WHOLE SHAPE IS READY: the look `workbench` and the genre `workbench` (setup, queue, processing and settings screens with sample data) are this design finished; fork the genre rather than drawing it again. AND WHEN THE OWNER APPROVED A DRAWN DESIGN OF THEIR OWN, the order is fixed: the drawing becomes a GENRE first (the drawing's screens as one page on sample data), the owner looks at it running and approves it, and only then is the app forked from that genre. An app built straight from a drawing out of kit parts drifts from it screen by screen, and the owner finds every difference himself (Postinjalostamo, 2026-09-28: three rounds).\n\nTHE FIRST MOVE IS A PRESET, not a blank page: `GET https://aimeat.io/v1/apps/ui/catalogue` carries `layouts` — finished, fillable shapes (cover, dashboard, browse, work-queue, story-deck, guided-flow). Pick the one nearest the app, replace every value with the app's own words and source names, and use it as the fallback — and as the first stored layout when the owner wants one.\n\n## Start from a GENRE — a complete committed register, and the register is required\n\nEvery Atelier app names the register it committed to, and the publish refuses one that does not: `\">` is in every genre's head already, so a fork carries it; a page that commits to a look of its own declares `\">`, where the name says what the register is (custom:game, custom:ledger) and is never \"default\". The bare shell carries a REPLACE-ME line in that place, and the gate refuses it as served: the shell is a frame, not a page.\n\nWhatever the app is — a poster, a console, a departure board, a ledger — do not assemble blocks: FORK A GENRE. Each genre is a finished free-composition page in a committed register; fetch it with `GET https://aimeat.io/v1/app-templates/`, swap the words, sources and images for the app at hand, and KEEP THE PHYSICS (finite entrances, motion only under the hand or the scroll, zero idle repaints — the look's ambient layer is the one declared exception — reduced-motion honesty). The kit's scenic props (`flapify`, `ransom`, `vu`, `typeout`, `dealIn`, the `.ak-stamp` / `.ak-ticker` / `.ak-torn` / `.ak-polaroid` family), the MATERIALS (one class per surface: `.ak-mat--glass`, `--aurora`, `--grain`, `--ink`, `--signal`, `--ring`, `--spot`) and the MOTION RECIPES (`.ak-move--magnet`, `--sheen`, `--deal` as classes; `spotlight`, `tilt`, `sheen`, `odometer`, `thumb`, `deal` as calls — every one answers the hand or a change and rests, none loops), the kit's own MOTION PRIMITIVES (`spring`, `stagger`, `inView`, `scrollLink`, `drag` — Web Animations API, no dependency, finite, a no-op under reduced motion; reach for these before a library) and the pattern shelf below carry the shared stagecraft. When an app needs a full animation library, the node serves three as packs — Motion (`motion`), anime.js (`anime`) and Lenis (`lenis`) — read the pack's doc before writing a line, because every one of them changed its API after the version you know.\n\nORNAMENTS: `AIMEAT.atelier.ornament(el, id, { speed, delay, leaves })` grows an engraved or living SVG figure round ONE element, in the look's colours, once, then holds still: `frame` (block), `vine-border` (block), `rope` (block), `jugend` (block), `guilloche-band` (block), `wreath` (badge), `guilloche` (badge), `vine-bar` (bar), `wrap` (bar), `divider` (rule), `vine-rail` (rule), `braid` (rule), `cord` (rule), `guilloche-strip` (rule), `fleuron` (rule), `dinkus` (rule), `flourish` (heading), `swash` (heading), `dropcap` (text), `ribbon` (heading), `bullets` (list), `ivy` (column), `brackets` (button). The word in brackets is the element it was drawn for. One or two per screen, on what matters: a frame round the card, a vine round the progress bar, flourishes beside the title. Never draw an ornament of your own. See each: https://aimeat.io/v1/designbook/ornament-/preview\nORNAMENT SETS, five figures in one style: `AIMEAT.atelier.ornamentSet(set, { frame: card, rule: emptyEl, bar: progressbar, bullets: ul, strip: emptyEl }, { value })`, any role left out: `modern`, `futuristic`, `cyberpunk`, `vibrant`, `emotional`, `dramatic`, `symmetrical`, `chaotic`, `velocity`, `art-deco`, `crystal`. One set per screen, in the app's mood. See each: https://aimeat.io/v1/designbook/ornament-set-/preview\n\n- `genre-pressdrop` — **The poster drop**: A full-page poster: image and giant type share the same space, duotone washes reveal true colour on hover, tilted stamps, a torn edge, a scroll-driven ticker, a sideways filmstrip with real scale contrast, one loud slab, the wordmark running off the page. For launches, drops, campaigns. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressdrop/preview\n- `genre-nightfloor` — **The night floor**: An ops room at 03:12: one number the size of the room (counts up once), glass panels floating deliberately unaligned that lean toward the pointer, a duotone camera feed with scanlines, a diagonal floor cut, a log rail whose newest line glows. For dashboards that watch one operation. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightfloor/preview\n- `genre-pressctl` — **The console**: The whole page is a terminal: a boot log that types itself once, a phosphor masthead glowing through scanlines, a mono queue table with status bars, gauges in ruled cells, a sticky F-key command bar. For queues, consoles and anything an operator lives in. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressctl/preview\n- `genre-pressindex` — **The index**: Type IS the interface: five giant outline rows are the whole navigation — hover floods the word solid and lights a full-page image behind everything. For fronts and site indexes with few doors. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressindex/preview\n- `genre-quarterly` — **The broadsheet**: A typeset newspaper front page: double-rule masthead, justified columns with a column rule, a red drop cap, a pull quote that breaks the column, a captioned figure, an IN BRIEF rail with numbers, a footer figures grid. For editorial fronts, reports and periodicals. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-quarterly/preview\n- `genre-thewall` — **The gallery corridor**: The page scrolls SIDEWAYS: you walk past framed works hung at their own heights under their own spotlight cones, each with a brass plaque; the wheel walks the corridor and a HUD shows how far. For portfolios and collections. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-thewall/preview\n- `genre-almanac` — **The almanac**: A Swiss data poster: a strict ruled grid, one red, numerals the size of weather, the season as moon dots, a week strip with one burning day. No texture, no tilt, no shadow — the discipline is the style. For stats pages and summaries. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-almanac/preview\n- `genre-blueprint` — **The blueprint**: A cyanotype: white line-work on process blue over grid paper — an SVG floor plan with dimension arrows, dashed callout notes pinned around it, one hot-yellow zone, and a proper title block with a rotated AS BUILT stamp. The light choice gives the whiteprint (blue lines on white paper, red for the hot zone); put running text on whiteprint blocks, because white text on the blue is hard for some eyes to read. For plans, maps and technical overviews. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-blueprint/preview\n- `genre-nightradio` — **The radio**: A valve set on walnut dark: a long tuning dial you drag (the needle springs to the frequency), programme rows that retune it and swap NOW PLAYING, VU bars drawn once per pick, an ON AIR lamp. For players, programmes and schedules. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightradio/preview\n- `genre-receipt` — **The receipt**: The whole page is one object: a giant thermal till roll on a dark counter — perforated tears, dashed rules, dotted leader fills, a VOID line, a rotated PAID stamp in multiply, a barcode — and it prints itself downward once. For confirmations, summaries and orders. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-receipt/preview\n- `genre-fanzine` — **The fanzine**: A photocopied punk collage: a ransom-note headline cut from six sheets, a staple, torn strips carrying shouted paragraphs, taped polaroids thrown on the desk (hover straightens one), xerox noise, a shouty two-line footer. For bulletins, community pages and anything with elbows. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-fanzine/preview\n- `genre-departures` — **The departure board**: A split-flap hall board: every character in its own flap cell, amber on black with green BOARDING and red DELAYED rows, and the whole board flips itself legible once, row by row. A LAST CALL strip below. For schedules, statuses and queues. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-departures/preview\n- `genre-patterndept` — **The specimen sheet**: A pattern specimen page: a zone-pattern banner with the title punched through, swatch cards on springs, a words-on-a-whisper proof card, a loud divider, rule cards. For style guides, catalogues and departments of anything. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-patterndept/preview\n- `genre-nightwatch` — **The night watch**: A small power station's wall at 02:40, all phosphor: the water route drawn as one glowing schematic with the kit's gauge bolted onto it, lamp-lit system cabinets, the watch log in tones, night orders signed on paper, the river's name burning off the page. For plants, fleets and anything one person keeps alive at night. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightwatch/preview\n- `genre-crossing` — **The crossing**: A ferry line's night board: the kit's real map framed to the strait, the route inked across it with the ship mid-water, tonight's sailings ruled like the harbour office copy, a torn boarding stub with a stamped corner. For routes, logistics and anything that moves between two shores. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-crossing/preview\n- `genre-orchard` — **The season book**: A family orchard's year printed as a keepsake: the kit's calendar heat wall hung as a framed print (the story readable in its shape), the harvest weighed in a ruled grid, the split as a ring with a jam-lid badge, torn diary strips taped down crooked. For seasons, logs and any year worth keeping. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-orchard/preview\n- `genre-mtv` — **Music television**: 1980s music TV at night: a broadcast ident bar, a block logo with a sprayed tag, a CRT set whose credits box carries the provenance (maker · machine · human share), countdown rows with outlined numerals lit by their channel colour, neon channel chips, a cassette submission band and a yellow news strip at the floor. Proven live in an AI music chart. For charts, players, countdowns and anything that is ON AIR. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-mtv/preview\n- `genre-nighttrain` — **The night train**: A scroll STORY on the kit's director: one journey, Helsinki to Rovaniemi, told chapter by chapter under Lenis. The platform board and its lamps, a carriage of berths that light as a wave, the stations passing SIDEWAYS under vertical scroll, the aurora as three parallax layers behind a window, the route drawing itself with the distance filling a ring, and the doors opening at the end. The rail marks the chapter, the arrow keys move, the scroll snaps to a chapter start when the hand lets go. Fork it for anything told in order: a product launch, a year in review, a route, a recipe, an onboarding. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nighttrain/preview\n- `genre-platformer` — **Ridge Run**: A GAME: a night patrol on a ridge as a platformer on aimeat-phaser. Three nights as levels the save unlocks, coins as lamps, spikes, a fox on patrol, the cairn as the goal; title and level-select scenes, pause, a settings panel, the synth for coin, hit and win. Around the canvas: a conditions board, the ledger of the three nights, the patrol log. For any platformer. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-platformer/preview\n- `genre-shooter` — **Harbour Watch**: A GAME: a top-down shooter on aimeat-phaser. A launch on dark water, stick or WASD to steer, the pointer to aim, drifting mines to clear and lanterns to collect, waves that grow, the best wave saved; title, game over from menuItems, pause, settings, gamepad on. For any twin-stick or arena shooter. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-shooter/preview\n- `genre-match` — **Market Stall**: A GAME: a match-three puzzle on aimeat-phaser, the light page. A 7 x 7 crate of produce, swap by pointer or keys, cascades, a hands counter and a target per crate, three crates, the best saved; title, pause, settings, the synth for a match. For any tile puzzle. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-match/preview\n- `genre-runner` — **Night Courier**: A GAME: an endless runner on aimeat-phaser. One button, a seeded roof pattern that always stays jumpable, vents to hop and gaps to clear, speed that rises, distance as the score, a parallax skyline from generated textures; title, game over, pause, settings, gamepad on. For any one-button runner. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-runner/preview\n- `genre-living` — **The record sheet**: A LIVING DOCUMENT: a nursery's growing record for one glasshouse block, and the whole sheet is one JSON record on aimeat-living. Two readings are entered by hand; the conversion, the dew point set as mathematics beside its answer, the wall number, the dial, the day's four bars, the sentence that changes at 30 °C and the standing order a statechart writes are all worked out from them, and the chain of who feeds whom is drawn in the margin and lights along the path a change travelled. Numbered fields, a filing head, a rubber stamp for the state, and every colour off the tokens, so it prints in either theme. Fork it for anything whose numbers stand on each other: a calculation sheet, a survey, a dosing record, a spec you can move. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-living/preview\n- `genre-workbench` — **The workbench**: A TOOL someone works in every day, on the kit's own workbench pieces and the workbench look: the app's mark and name in a solid bar, the pages in a left column with counts and tone dots, a status band with readiness tiles, three ways to let AI help, a queue as list and detail with a reason callout, a batch as \"3 / 10\" with its tallies, and settings with the help beside controls sized to their content. For intake, review and admin tools. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-workbench/preview\n\nFIXED OR FOLLOWING is the owner's choice, and both are right. A FIXED genre is a finished object with its own colours: it looks the same at noon and at night, and the sign-in bar's light/dark control stands down on it. A FOLLOWING page is drawn in the theme's `--ak-*` tokens and changes with the person's light/dark and palette, which is what a tool people work in all day usually wants. Following today: `genre-blueprint`, `genre-living`, `genre-workbench`; every other genre is fixed. A fixed genre becomes a following one by replacing its hardcoded colours with `--ak-*` tokens and changing `` to `follows`: keep the composition, the type and the physics, and check it in BOTH modes beside the original, because a palette that was tuned for one ground rarely survives the other untouched. Every picture of a genre is one address away (`See it`), and the whole shelf is https://aimeat.io/v1/design-book; give the owner the links, do not describe a look in words when they can look.\n\nTHE TRAP THIS SECTION EXISTS TO STOP: a mosaic block stack wearing a look is a tool screen, never a statement — assembling components and applying a world reads as \"the same dashboard in new paint\" no matter which world. When a page must IMPRESS, start from the SUBJECT (whose page is this, what does it say), fork the genre that carries that register, and let the components serve the page — they mount in any element, so a free-composed page can still carry a live gauge or a map. If you cannot name what the page is about beyond \"it shows the blocks\", you are building a demo, and a demo never looks designed.\n\n## A fork people sign in to, in two languages\n\nA genre is a finished page with no sign-in, no language switch and its words in one language. Your fork adds all three, the same way every time. Do not write a header or a sign-in control of your own: the bar below is the node's, it carries the language switch and the light and dark control, and a hand-made one is the first thing a review sends back.\n\n**Two languages is the default: `en fi`.** Keep both unless the owner asked for one. Every word the page shows goes through a dictionary; a string typed into the markup is a string that cannot change language, and a page where the bar is Finnish and the content English is refused at review.\n\n```html\n\n\n\n\n\n
\n

\n\n\n\n\n```\n\nThe switch must keep what the person was doing: a conversation, a half-filled form and the settings survive it, because `paint()` changes words and nothing else. Numbers, dates and money follow the language too (`toLocaleString(i18n.lang())`). Languages of speech recognition or of an AI answer are separate settings; do not tie them to this switch unless the owner asks.\n\nAn app nobody signs in to still mounts the bar when it has two languages, because the switch lives there. Before you call it done, press the switch: English to Finnish and back, in the middle of using the app, and read every screen in both.\n\n**What the genre does not have, the kit has, and it wears the genre.** A form, a dialog, an empty state, a toast, a chart or a gauge comes from `AIMEAT.atelier`, never from your own markup. Every fixed-colour genre carries a block marked THE BRIDGE after its `:root`, which hands the kit the genre's ground, ink, one accent, corners and faces, so a kit component mounted into the page looks like part of it. When you change a colour of the genre, change it in the bridge with it. Mount a component ON the genre's own ground (the paper of a receipt, the panel of a board), where its ink is readable.\n\n## The node's libraries: read this list before you write a mechanism\n\nSpeech, audio, files, live updates, notifications, printing, calendars, decisions, payments and agents are already written, served by this node and kept in step with it. Before you write a mechanism of your own, find it here. An app that runs its own speech loop, its own socket or its own `fetch` to `/v1/memory` works on the day it ships and stops following the platform afterwards, and the publish says so (`app_hints`, pitfall `hand-rolled`).\n\nLoad with `\n\n\n
\n\n```\n\nTHE FILL COMES FROM THE BOOK: pick one from the list at the end of this part, read it with `aimeat_designbook_get { id }`, replace every value with this app's words and source names, take its `look` line out (in a genre the genre is the look, and the bridge makes every block wear it), and put it in the `#aimeat-layout` block. THE PUBLISH DOES THE REST, so there is nothing to call afterwards: it counts each part the meta names as used (once per app), and on the app's FIRST publish it stores the `#aimeat-layout` block as the app's arrangement, so from then on the owner's AI rearranges the screen with `aimeat_app_manage` action `ui_set` and no republish; a later publish never writes over what they arranged. The answer's `next_steps.design_book_parts` says what was counted, what it does not hold, and whether the layout was stored. Compose blocks of your own only where no fill is near.\n\nWhat stays hand-made in a genre fork is what the genre itself is made of: a figure only this page has, the masthead, a game board. Everything a mosaic block can show is a block.\n\nCOMPONENTS: WHAT ANOTHER APP MADE BY HAND. The list at the end of this part has a COMPONENTS group: pieces of page an earlier builder made because the Book had nothing, from apps whose owner was satisfied. Take one with `aimeat_designbook_adopt { id, filename }`, before your app exists: it answers `snippet` { html, css, use, prefix }, which you build into the page as they are. A component carries NO script, so you wire its behaviour as `use` says, and it reads the page's tokens, so inside a genre it wears the genre. Look there before you make a grid, a strip, a dial or a board of your own.\n\nWHEN YOU DO MAKE SOMETHING BY HAND, MAKE IT SO IT CAN BE OFFERED LATER, which costs nothing now: give it ONE class prefix of its own (`wkgrid`, `wkgrid-cell`), take every colour from a `var(--ak-…)` token and never a literal, and keep its behaviour in your script, reading `data-` attributes on the markup. That is exactly the shape the Book takes a component in, so when the owner says the app turned out well it goes onto the shelf as it is.\n\nWRITE DOWN WHY, AS YOU CHOOSE. A count says an AI reached for a part; it does not say the part is any good, and nobody can improve the Book from a number. So the page carries your reasons, one sentence each, in a third block beside the two above:\n\n```html\n\n```\n\n`took` is a part that is in this page and what made it fit (a part named here needs no `aimeat-book-parts` meta). `passed` is a part you looked at and left, and what made it NOT fit: it is the only place a part's weakness is ever written down, so it is the most useful of the three. `made` is what you built by hand because the Book had nothing, and why it had nothing. Write the true reason, including \"the name matched and I did not look further\": a reason that sounds good and is not why you chose teaches the Book the wrong thing. The publish keeps these with the version they belong to. NOTHING GOES INTO THE BOOK BECAUSE A BUILD IS FINISHED. An app is often rebuilt twice before its owner likes it, and a version that was thrown away must not teach the Book anything. Tell the owner, in one line when you hand the app over, that when they are happy with it they can say so; that is recorded with `aimeat_designbook_keep { filename }`, by whichever AI they say it to, and it is the moment what this app took and made starts to count.\n\n## AI inside the app\n\nThe `aide` block puts an AI panel on the screen whose tools are the app's OWN declarations: hand the mosaic spec your `sources` and an `actions` list ({ id, summary, params?, run }) and the aide can read what the screen reads and PROPOSE what the buttons do — a person confirms every run, the platform AI notice and provenance labels are built in, and it runs on the owner's own key (it sleeps politely when no key is set). A model answer may be a small mosaic panel rendered inline over the same sources — arrangement from the closed vocabulary, never markup. Two more affordances every mosaic carries: `m.explain()` renders \"what this screen holds\" from the declarations (never hand-write a help text that will drift), and `m.setOverlay({ hidden, order, nav })` applies THIS VIEWER'S own arrangement over the owner's page — store it in the viewer's own memory (`atelier.overlay.`), never in the owner's layout.\n\n## Data, in short\n\nLogin and data come from `aimeat-auth` and `aimeat-data` exactly as on the rest of the platform: the shell hands you the session in `onReady`; private data is `AIMEAT.data.set/get` with a `.`-prefixed key; one key holds one record a user opens as a unit, never one key per field; read back after writing. Declare the scopes the app uses in ``.\n\n**How the data map answers steer the build** (the three questions of the interview). SHARED BY THE TEAM: ONE organism workspace that every member reads and writes, through `AIMEAT.organism` (read, writeDraft, publish); `AIMEAT.atelier.workspacePicker({ target, app, onReady })` picks or creates it on the first run. Never per-user memory for team data. PERSONAL: `AIMEAT.data.set/get`, private to each person. PUBLIC: a record with `visibility: public`. WHO OPENS IT: the app's `open_to` setting, set when you publish (`anyone`, `signed-in`, or `organism:` for one organisation's members) with `aimeat_app_manage` action `settings` or PATCH /v1/apps/:filename; the data map's `form` says the same (`group` or `organism-workspace` for a team app). THE TRAP: a team app built on per-user memory gives every person an empty copy of their own, and nobody sees what a colleague added.\n\n## Finishing\n\nBefore you call it done: open the app at 390×844, 1280×900 and 1280×460 in BOTH themes; `document.body.scrollWidth === document.documentElement.clientWidth` at every width; every state (loading, empty, error, signed-out) reached through `a.status(...)`; no console errors. Publish with `aimeat_app_publish` and pass `spec_token: atelier-b982bcc761d3` — the digest of this document — so the node can tell the app was built against the spec in force.\n\n## What the review always catches\n\n- A form that switches into edit mode says so: retitle it and its primary action (\"Edit entry\" / \"Save changes\"), and the row being edited stays visibly selected. A form still headed \"Log an entry\" while it edits reads as adding a duplicate.\n- Counters and the lists beside them read from the SAME data, computed in one place. A screen whose numbers disagree with its rows reads as broken even when both are defensible.\n- Say a number ONCE. The same three counts as a stat row, as tab labels, as chips and again in a heading is the most common defect the review finds — pick the one place the number earns, and delete the echoes.\n- The content people came for comes BEFORE the form that adds to it. In a journal, reading is the daily act; a full-height form above the entries buries the product under its input.\n- Master-detail is ALWAYS listDetail, never a hand-rolled pick panel: the component carries the selection mark, the row-to-detail morph and the narrow-screen fold, and a hand-rolled panel loses all three.\n- The shell's bar is the ONLY top bar. Building a second header of your own puts two bars and the account pill in a fight for the same edge.\n- A filter applies WHEN IT CHANGES. A separate Show/Apply button beside a dropdown is a second step nobody expects of a filter.\n- Give the shell a `tagline` (one line on what the app IS): the sign-in screen presents the app with it, so a first visitor learns what they are looking at before they log in.\n- Storage internals never reach the person: \"under keys that start with standup.\" is a sentence for a developer, not for a screen.\n\n## Never\n\n- daisyUI/Tailwind classes outside a `section` body — the kit is the vocabulary.\n- Hand-written ARIA, focus management or animation code — the components carry them.\n- A theme, palette or language control — the login pill owns all three.\n- An invented script/style URL — everything the app loads is named in the shell.\n- The Classic build spec — two tracks, two guides, no mixing.\n","system_prompt":"## First, a short interview\n\nUnless you are Claude Opus or Claude Fable, open that message with one sentence: apps built with Claude Opus or Claude Fable turn out noticeably better, and they can switch now or go on with you.\nAsk, in one message, and wait for answers:\n1. What should the app do, in one or two sentences?\n2. Who uses it — just you, or others too (shared data)?\n3. How should it look and FEEL? (Map the answer to a look from the table below.)\n4. Which languages should it speak?\n5. Anything it must NOT do?\n\nBEFORE YOU SEND THESE QUESTIONS, start the app's structure page: call `aimeat_app_manage` action `structure_set` with a `filename`, `name`, `purpose` and `proposals.layout`, two or three layouts you drew for this app. Give `page_url` from its answer in one sentence and point question 3 there: the person sees the steps and picks a layout and a look by seeing them, or says \"you decide\". Do not list the steps in the chat; the page shows them. After the answers, read action `structure`: a choice with `\"state\": \"waiting\"` is theirs. Section \"The structure page\" (part `libraries`) has the rest.\n\n**Then the data map: three more questions, before any code.** Ask them with the questions above, in plain words. Skipped, an app goes wrong unnoticed: a company asked for ONE shared list of candidates and got an app where every person keeps their own.\n(a) Who opens the app: just you, your organisation (which organisation?), or anyone?\n(b) For each kind of data the app keeps (name each one from the idea): whose is it? PERSONAL (each person their own), SHARED BY THE TEAM (one common set that everybody in the organisation reads and edits), or PUBLIC (anyone may see it)?\n(c) Who may change the shared data: everyone in the team, or only some roles?\n**Then confirm with a scenario, and wait for a yes.** Before you build, write back in the person's own language two or three sentences drawn from THEIR idea, with named people, for example: \"So I understood: when Teemu adds a candidate, Maija sees them at once in the same list. When Maija marks a candidate as a favourite, only Maija sees the mark. Nobody outside the company can open the app. Is that right?\" Build only after they say yes. If they correct you, write the scenario again with the correction.\n\n## The structure page: the person follows the build\n\nEvery app has a structure page: the steps the app goes through (purpose, data, layout, look, build, builders, visibility, requirements), what is done and what is open, and a place where the person can pick a layout and a look by seeing them. Using it is the person's choice, and your work goes on whether they open it or not.\n- As soon as you know the app's name and purpose, call `aimeat_app_manage` action `structure_set` with `filename`, `name` and `purpose` (over HTTP: PUT /v1/apps/me//structure). Give the person `page_url` from the answer in one sentence: they can follow the app there and choose a layout and a look if they want to. The page shows the steps, so leave them out of the chat and ask there only what needs words; the person picks the layout, the look and who sees the app on the page too.\n- In the same first call, draw two or three layouts for THIS app in `proposals.layout`, each with an `id`, a `name`, a `note` on what it gives the person and a `sketch`: rows top to bottom, each `{ \"height\": \"s\" | \"m\" | \"l\", \"cells\": [{ \"w\": \"full\" | \"main\" | \"side\" | \"half\" | \"tiny\", \"label\": \"...\", \"tone\": \"ink\" | \"sun\" }] }`, labels in the person's language. Make them differ in what matters for this app (for a game: the board alone, the board with a side panel, the board with its layers beside it). The page shows them first and the node's presets after them, so the person picks by seeing; `proposals.nav` works the same way when the way between views is a real choice. When the person picks one, the choice's value is its id, and a note on it is what they want changed.\n- After the data map questions, write `data`: `{ \"summary\": \"what the app keeps and whose it is\", \"personalData\": \"yes\" | \"no\" | \"unstated\" }`. While you build, write `now`, one line on what you are doing; the page shows it live.\n- Before you build the screens, and whenever the person says they chose something, read action `structure`. A choice with `\"state\": \"waiting\"` is the person's: build it, then write the same value with `\"state\": \"done\"`.\n- When the person leaves the choice to you, choose `layout` (one of your proposals or a preset), `nav` and `look` from `values` in the structure answer, and write each with `note`, one sentence on why. Until a choice is made, leave it unset: the page then says the AI decides. A genre you fork from is `genre`, its Design Book id. When the person says who may see the app, write `visibility` (listed, community or unlisted).\n\n## Then propose, and wait for the answer\n\nBefore any code, show the owner what you are about to build, in their words, and wait. They decide from this; they must not find out what you chose by looking at the result.\n\n- **FIRST, THE LEVEL. It is the owner's choice and never yours; ask it in these words or plainer ones, and say what each one gets them.** (1) **A quick prototype**: a working draft to try one idea, the kit's components as they come, no styling. Fast, and plain to look at. (2) **An ordinary page**: works and looks tidy, with a ready layout and a ready look from the Design Book, following their light and dark theme. Not distinctive. (3) **The finest**: a committed look forked from a genre, proven parts from the Design Book, components of its own where the book has none. It takes the longest and is the one worth showing. All three are built the same way underneath, in two languages, with the data kept on their node, so a prototype can be raised to the finest later without starting over: say that, because it is what makes the quick one a safe choice. If they do not answer, recommend one and say why; never pick a lower one silently because it is less work. The page states the level: ``, `\"plain\"` or `\"fine\"`. On `proto` and `plain` the rest of this list shrinks to the languages, who signs in and the first screen: no genre is forked, the page starts from the Atelier shell (`aimeat_app_template_get { id: \"shell-atelier\" }`), the publish asks for no register, and nothing is styled by hand (a publish warns when such a page carries a sheet of styles of its own). On `fine`, everything below applies, and so does writing down why you took, passed over and made each thing (the build notes, part `book`). A page that states no level is held to `fine`.\n- **Two or three genres, named, each with one sentence on why it fits THIS app** and what the first screen would look like in it. Get them from the genre list (part `genre`, or `aimeat_designbook_search { kind: \"genre\" }`), and look at the owner's own apps first (`aimeat_app_list`): the ones already on Atelier show what they like. Say which one you would take. A look preset with components stacked in it is not on this list: that is the default page every app looks like, and it is what gets sent back.\n- **Fixed colours or following their theme?** Ask it, or recommend one and say why. A fixed genre keeps its own colours in light and dark; a following page changes with the person's theme and palette. Part `genre` says which each genre is and gives an address for each (`See it`), and the whole shelf is one link: send the owner the links so they choose by looking. If they want a genre that is fixed and want it to follow the theme, say that it means moving its colours to the theme's tokens, and that you will show it in both modes before they decide.\n- **What you take from the Design Book.** Look before you make (`aimeat_designbook_search`, part `book`): layouts, fills, looks, motion, ambients and effects that each passed their own bench, adopted in one call. The working screen of the app is a mosaic inside the genre, and its arrangement is where a fill from the book lands (part `book` shows how). THIS LINE IS OWED IN EVERY PROPOSAL, word for word in its shape: \"From the Design Book I take: \", or \"From the Design Book I take nothing, because \". Taking nothing is allowed; taking nothing in silence is not. What you have to make because the book lacks it is written down with its reason in the page's build notes; it is offered to the book when the owner is satisfied with the app, and not because the build is finished.\n- **The languages: English and Finnish, unless they say otherwise.** Two languages is the default on this node. The language you are talking in is not the app's language list. Building for one language is the owner's decision, so ask it as a question if you think one is right, and do not decide it.\n- **Who signs in**, and what is kept for them. An app nobody signs in to says so here.\n- **The data map, and the confirmed scenario.** For each kind of data: personal, shared by the team or public, who may change the shared data, and who opens the app. Repeat the scenario they said yes to; without that yes, ask it now.\n- **The first screen in one or two sentences**: what the person sees and does first. If that sentence is \"a header and some cards\", you have not designed it yet.\n\nOffer it as choices the owner can answer with a word. If they said \"just build it\", still say in one line which genre and which languages you are taking, so they can stop you. Then build on the Atelier track:\n\n## The Atelier track\n\nYou are building on the ATELIER track. Its guide is THIS document and the `node:aimeat-app-builder-atelier` skill — never the standard build spec at /v1/prompts/build-app, whose vocabulary (daisyUI classes, hand-written boilerplate) does not apply here. The app declares `` so a later session loads the right guide.\n\nTHE FIRST MOVE OF THE BUILD IS THE GENRE FORK. An app here starts from a committed register, never from the bare shell: list the genres with `GET https://aimeat.io/v1/designbook?kind=genre`, fork the one that carries the page's register with `GET https://aimeat.io/v1/app-templates/genre-`, and swap the words, sources and images (the genre section below has the menu). Every Atelier app declares the register it committed to — `\">`, which every genre already carries, or `custom:` for a page that commits to a look of its own — and the publish REFUSES an Atelier app that names none.\n\nThe shell is the frame the genres are built on — fetch it to learn the structure, never invent it:\n\n```\nGET https://aimeat.io/v1/app-templates/shell-atelier\n```\n\nIt carries a REPLACE-ME register line on purpose, so published as it is served it is refused: the shell is a frame, not a page. A GAME starts from the game shell instead: the same frame with a Phaser canvas, a title menu, pause, settings and a leaderboard already wired through aimeat-phaser, and its register is the canvas (`custom:game`):\n\n```\nGET https://aimeat.io/v1/app-templates/shell-phaser-game\n```\n\nThe head is eight lines and stays that way: the ceremony (theme restore, login boot, mobile guards, designed states, accessibility wiring, motion) lives in the served kit, not in your file. Every byte you add is a byte you re-read on every edit.\n\n## The components (`AIMEAT.atelier`)\n\nEvery component takes a spec and returns `{ el, set(patch), destroy() }`. Copying an example below yields a finished, beautiful, accessible piece — that is the paved path.\n\n- `app` — The shell that carries the whole ceremony: login pill + boot, language re-render, designed loading/empty/error/sign-in states, the only scrolling region, the bottom chrome reserve, and the ambient layer behind the frame (the look decides; `ambient` names a preset, `{ preset, alpha, speed }`, or `false`). Fill handle.main; switch states with handle.status().\n ```js\n var a = AIMEAT.atelier.app({ title: 'Errands', look: 'vivid', onReady: function (s) { render(a, s); } });\n ```\n- `hero` — The ONE focal band a screen gets (two heroes is shouting, zero is flat). With no image it paints a designed gradient mesh; with an image the text sits on a mode-following scrim. data: URIs are refused — upload to storage and pass the URL.\n ```js\n AIMEAT.atelier.hero({ target: a.main, title: 'Errands', sub: '3 open', actions: [{ id: 'add', label: 'Add', kind: 'primary', onClick: addOne }] });\n ```\n- `statRow` — The KPI strip. On set(), a changed figure counts up — the state-change motion arrives with the data.\n ```js\n var kpis = AIMEAT.atelier.statRow({ target: a.main, tiles: [{ id: 'open', label: 'Open', value: 3 }] }); kpis.set({ tiles: [{ id: 'open', label: 'Open', value: 4 }] });\n ```\n- `list` — Rows keyed by id: set() adds (slides in), removes and updates (flashes) instead of rebuilding. Rows are real buttons when onPick exists; an empty list renders the designed empty state.\n ```js\n var l = AIMEAT.atelier.list({ target: a.main, items: [], onPick: open, empty: { title: 'No errands yet', action: { label: 'Add one', onClick: addOne } } }); l.set({ items: rows });\n ```\n- `listDetail` — The list beside a detail pane, split by a container query: a narrow box shows one pane at a time with a back affordance. You render the detail; select() drives it.\n ```js\n var ld = AIMEAT.atelier.listDetail({ target: a.main, items: rows, renderDetail: function (item, body) { body.textContent = item.title; } });\n ```\n- `cardGrid` — The browsing grid. Every card has an art area with zero images: deterministic monogram washes keep a pictureless grid designed, never grey.\n ```js\n AIMEAT.atelier.cardGrid({ target: a.main, items: products, onPick: openProduct });\n ```\n- `mediaCard` — One card on its own — a feature, a highlight — with an optional action row.\n ```js\n AIMEAT.atelier.mediaCard({ target: a.main, item: { id: 'p1', title: 'Featured' }, actions: [{ id: 'go', label: 'Open', kind: 'primary', onClick: go }] });\n ```\n- `form` — Fields declared as data, accessibility wired for you (labels, hints, worded inline errors, focus to the first problem). Throw { field, message } from onSubmit and the form places your rule like its own. NEVER hand-roll inputs or ARIA.\n ```js\n AIMEAT.atelier.form({ target: dlg, fields: [{ name: 'title', label: 'What', required: true }, { name: 'due', label: 'When', type: 'date' }], onSubmit: save });\n ```\n- `table` — Real table semantics that scroll INSIDE THEIR OWN BOX (the page never widens), sortable headers with aria-sort, tabular numerals.\n ```js\n AIMEAT.atelier.table({ target: a.main, columns: [{ key: 'name', label: 'Name', sortable: true }, { key: 'n', label: 'Count', align: 'right' }], rows: rows });\n ```\n- `searchBar` — Debounced search that reports the query; what it means is your business.\n ```js\n AIMEAT.atelier.searchBar({ target: a.main, onChange: function (q) { l.set({ items: filter(rows, q) }); } });\n ```\n- `timeline` — Events on the vertical line every history and activity view shares.\n ```js\n AIMEAT.atelier.timeline({ target: a.main, items: [{ id: 'e1', ts: Date.now(), title: 'Published', tone: 'ok' }] });\n ```\n- `tabs` — A tab row that reports the pick; you swap the view.\n ```js\n AIMEAT.atelier.tabs({ target: a.main, items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }], onChange: show });\n ```\n- `figure` — The data IS the hero: one giant numeral with its label and context line, counting up on change — use it when a single number is what the person came to see.\n ```js\n AIMEAT.atelier.figure({ target: a.main, value: 48, label: 'Combined storage', sub: 'Monday looks like the wettest day.', delta: '-19% vs last year' });\n ```\n- `section` — The titled card AND the escape hatch: markup the catalogue cannot express goes inside a section body, so custom work keeps the surface, the measure and the entrance. This is the ONLY place raw HTML belongs.\n ```js\n var s = AIMEAT.atelier.section({ target: a.main, title: 'Custom' }); s.body.appendChild(myOwnMarkup);\n ```\n- `emptyState` — The designed empty/error/notice card — spot mark, title, hint, action. Never ship a bare string or a grey box.\n ```js\n AIMEAT.atelier.emptyState({ target: host, title: 'Nothing matched', hint: 'Try another word.' });\n ```\n- `skeleton` — Loading placeholder rows the real content replaces; the shimmer is finite.\n ```js\n var sk = AIMEAT.atelier.skeleton({ target: a.main, rows: 3 }); load().then(function (rows) { sk.destroy(); l.set({ items: rows }); });\n ```\n- `sideNav` — The left column of a working tool: entries with a count and a tone dot, under group headings. Usually through app({ nav: 'side', navItems }), which also folds it into the bottom bar on a phone; handle.nav.set({ value, items }) moves the mark and the counts.\n ```js\n var a = AIMEAT.atelier.app({ title: 'Mail', logo: LOGO_URL, look: 'workbench', nav: 'side', navItems: [{ id: 'setup', label: 'Setup', count: '5/5', tone: 'ok', onPick: show }, { id: 'unclear', label: 'Unclear', count: 1, tone: 'warn', group: 'Waiting for you', onPick: show }] });\n ```\n- `statusBand` — A page's opening card: where things stand (title + one sentence), a progress bar, one primary action. Its body takes a checkGrid.\n ```js\n var b = AIMEAT.atelier.statusBand({ target: a.main, title: 'Ready', text: 'Five of five done.', progress: { value: 5, total: 5 }, action: { label: 'Run a batch', onClick: run } });\n ```\n- `checkGrid` — Readiness tiles: ok, todo (needs the person, click to fix), optional, fail, wait. One line under each title.\n ```js\n AIMEAT.atelier.checkGrid({ target: b.body, items: [{ id: 'mail', state: 'ok', title: 'Mailbox', sub: 'Gmail' }, { id: 'send', state: 'optional', title: 'Forwarding', sub: 'Not in use' }], onPick: fix });\n ```\n- `choiceCards` — Two to four ways to do one thing as a radio group of cards, and a panel under them the app fills for the chosen one.\n ```js\n AIMEAT.atelier.choiceCards({ target: s.body, items: [{ id: 'chat', kicker: 'Your own AI', title: 'Interview me', text: '…' }, { id: 'agent', kicker: 'Connected', title: 'Let an agent do it' }], renderPanel: function (item, host) { host.textContent = item.title; } });\n ```\n- `settingsGroup` — One group of settings: heading and one sentence on the left, the controls on the right capped at a measure; folds to one column on a narrow box. Give each form field a `width` (short, date, medium, long).\n ```js\n var g = AIMEAT.atelier.settingsGroup({ target: a.main, title: 'Batch', hint: 'How much mail one run reads.' }); AIMEAT.atelier.form({ target: g.body, fields: [{ name: 'size', label: 'Messages per batch', type: 'number', width: 'short' }], onSubmit: save });\n ```\n- `progressFigure` — A batch while it runs: \"3 / 10\" as the largest thing, the bar, the item being worked on with step chips, toned tallies. set() counts up.\n ```js\n var p = AIMEAT.atelier.progressFigure({ target: a.main, label: 'Processing', value: 3, total: 10, now: subject, steps: [{ label: 'read', state: 'done' }, { label: 'extract', state: 'now' }], counts: [{ id: 'ok', label: 'Clear', value: 2, tone: 'ok' }] });\n ```\n- `promptPanel` — The person's own AI helps: copy the prompt, paste the answer; expect \"json\" hands onResult the parsed object.\n ```js\n AIMEAT.atelier.promptPanel({ target: panel, prompt: setupPrompt, expect: 'json', onResult: preview });\n ```\n- `queueRow` — A queue item's content (who, when, subject, chips, why it waits), as a list row part.\n ```js\n parts: { row: function (r) { return AIMEAT.atelier.queueRow({ who: r.from, when: r.at, title: r.subject, chips: [{ text: r.klass }] }); } }\n ```\n- `callout` — A tinted note with a tone (info, ok, warn, err) that says why: why an item is unclear, what failed, what to do.\n ```js\n AIMEAT.atelier.callout({ target: detail, tone: 'warn', title: 'Why this is unclear', text: reason });\n ```\n- `margins` — Wide screens: the sides wear the home margin figure.\n ```js\n AIMEAT.atelier.margins(AIMEAT.atelier.marginsOf(prefs));\n ```\n\n## A COMPONENT THAT IS NEARLY RIGHT IS CUSTOMISED, NEVER COPIED\n\nFour doors, the same four on every component; `AIMEAT.atelier.describe(\"list\")` tells you which ones a component has, and `describe()` names every component that answers.\n\n1. **Named parts.** Every element the kit builds carries `data-ak-part=\"\"`; your own CSS reaches it by name — `[data-ak-part=\"aside\"] { … }` — so the rule keeps working when the markup around it changes, which a selector written by DOM depth does not.\n2. **Slots.** `parts: { : value }` on the spec; a value is a string, a DOM node, an array of those, or a function of the row returning one of those. `extra`, `aside`, `before` and `after` are rendered EMPTY and appear the moment you fill them, so a row that needs a third line and a value on the right is `AIMEAT.atelier.list({ items, onPick, parts: { extra: function (r) { return r.note; }, aside: function (r) { return r.amount; } } })` and nothing more. A slot returning `null` removes that part. `parts.row` (`item` on timeline, `card` on kanban) replaces the whole row, and it is still keyed, entered and picked.\n3. **Variants.** `variant: \"dense\"` stamps `data-ak-variant` and the stylesheet reads it, so you PICK a legitimate shape: `dense` and `plain` on list, listDetail, table, timeline, cardGrid, mediaCard, queue, health, kanban, section, searchBar and shelf; `numbered` on list and listDetail; `wide` on cardGrid; `lined` on table; `tall`, `compact` and `center` on hero; `compact`, `trend` and `plain` on statRow; `compact` and `center` on figure; `compact` on rating, aiTask, aiChat and requestPanel; `plain` on doc and board; `fill` on board; `dense` on tabs, bottomNav, segmented, members, workspacePicker, workflowInput and handbook; `dense` and `plain` on fingerprint; `pill` on tabs; `quiet` on section; `ghost` on stateButton; `table` on members and workspaceTeam. An unknown name is refused with a console line naming the real ones.\n4. **Per-component tokens.** `--ak-list-aside-size`, `--ak-stat-figure-size`, `--ak-card-aspect`, `--ak-hero-title-size` and seventy-five more, each defaulting to the value the component already had. Set one on YOUR OWN element and exactly that part changes, in every look and both modes.\n\nA statRow tile and a figure also take `unit` (what the number is measured in) and `direction: \"up\"|\"down\"|\"flat\"` with `delta` (how far it went, in your own words).\n\nEVERYTHING CUSTOMISED STILL MOVES: a slot fills the row the kit already built and keyed, so the entrance, the glide, the exit, the pick and the selection mark are unchanged.\n\nStyle through those four doors and the app keeps every later fix: leave the `.ak-*` selectors to the kit, and put the piece you would have bolted on with wrapper markup into the slot that is waiting for it.\n\nFORK ONLY AS A LAST RESORT: copy the component's markup out of its module and its `.ak-*` rules out of `/lib/aimeat-atelier/*.css`. You keep the tokens, the look and the motion helpers; you give up the keyed reconcile, the designed empty state, the accessibility wiring and every later fix. `describe(id).fork` says what that one costs. The dialog family stays whole whatever happens — the focus trap, Escape and focus return are the browser's through native `` — so your own markup goes in its `body(host)`.\n\n## A LIVING DOCUMENT: A SHEET WHOSE NUMBERS STAND ON EACH OTHER IS A RECORD\n\nWhen what the person asked for is a calculation sheet, a survey, a dosing record, a reading log or a spec that recomputes — anything where moving one number should move the rest — the arithmetic belongs in the document. Fork the genre with `GET https://aimeat.io/v1/app-templates/genre-living` and write ONE JSON record on `aimeat-living`: `{ v: 1, register, look, layout, model }`, where `layout` is an ordinary mosaic arrangement (the same blocks and spans you already write, and the person can rearrange them) and `model.nodes` is one dependency graph. `AIMEAT.living.mount(host, record)` is the only line of code on the page.\n\nASK THE LIBRARY, RATHER THAN TRUSTING ANY LIST. `AIMEAT.living.describe()` names every node type and `AIMEAT.living.describe(\"formula\")` gives its inputs, outputs, options and a worked example, read out of the node modules' own source so it says what this build does. `AIMEAT.living.validate(record)` reads a document WITHOUT running it and answers with every refusal in words — an unknown node, a circle naming the two ids, a unit that will not add, a block that is not there. Call it before you save.\n\nTHE NINE NODE TYPES, one line each so you know what to ask about: `value` (a named quantity, the writable ground the rest stands on), `formula` (a spreadsheet expression over other node ids, worked out with its units and printed as mathematics), `control` (a slider, toggle, pick, number or text field on ONE value), `binding` (one block prop reads one node), `text` (a sentence that changes when the numbers do), `machine` (a statechart in XState's vocabulary, whose output is the state it is in), `source` (a live value from a memory key or from an address), `trigger` (when a machine transitions, the document tells an address or one of the owner's own agents) and `decide` (the decision model reads a text and moves a machine by its own events above a threshold; below it, a person decides; the page then also loads aimeat-decide.js and the app asks for ai:use).\n\nWHERE A NODE LANDS ON THE SCREEN, two roads: a `binding` feeds a kit component — a figure's value, a gauge's reading, a chart's series — and the refresh goes through the mosaic's own door, so the count-up and the glide run for you; and a `block` field on a control, formula, text, machine or value node draws it into a `section` block of the same arrangement, which is where a node goes when the kit has no component for it.\n\nA DOCUMENT CAN ALSO REACH OUT, AND ONLY THROUGH ONE DOOR. A `trigger` fires when a machine TRANSITIONS — not on every recompute — and sends one message carrying the whole state: the document, the time, which machine moved from where to where on which event, every value with its unit and its label, and every machine's state. Its target is a url or one of the owner's agents, and an agent target becomes a task titled with the crossing. A `source` reads the other way, off an address, with a path into the answer and an `every` in seconds; a read that fails keeps the last value and writes the refusal into the node's `stale` output. Both go through the node's `living-hooks` extension as the signed-in caller, so the owner's allowlist decides which hosts may be reached — never the record, and never the browser calling a third party directly. A guest sees both roads disabled with words. Two switches are the owner's: `hooks: { enabled: false }` on the document stops every trigger, and `enabled` on a trigger stops that one. An address that wants a key gets it by NAME: a trigger's or a source's `headers` may carry `{{secret:NAME}}`, which the node fills from the signed-in owner's vault on the way out, so the record holds the placeholder and never the key. The gear dialogs offer the owner's stored names to pick from; a name the owner has not stored fails by name, and the words to give the person are \"store it as NAME on your Access page, section 04 Secrets, or ask your AI\".\n\nTHREE THINGS THAT KEEP IT A DOCUMENT. The arithmetic lives in a formula node, so the person changes what the sheet works out by asking their own AI to edit the record. It computes in the browser and persists as the record, which is a memory key — a slider moves faster than a request returns. And the record names a register the same as any other Atelier page, so the sheet arrives wearing a look somebody designed.\n\nONE LINE IN THE HEAD DECIDES WHETHER THE READER MAY CHANGE THE LIGHT. A genre that hardcodes its palette carries `` beside its register line, and the login pill's light/dark control stands down there rather than doing nothing; a fork inherits that line, so DELETE it (or write `content=\"follows\"`, which genre-living does) as soon as your page's colours are `--ak-*` tokens and it follows the theme — otherwise the switch is dead and the reader's operating system decides light or dark for them.\n\nA LABEL IS A LANGUAGE MAP. Any human-facing string in the record may be written as `{ \"fi\": \"Ilma ovella\", \"en\": \"Air at the door\" }` rather than as a plain string — a label, a hint, a pick's option, a text node's whole template, the words a machine's entry action writes, and a layout block's `title`, `sub` or `caption` — so ONE record is the document in every language it was written for. The page's language decides which is read (the login pill sets it), the record's own `lang` is the fallback and the map's first key the last resort; `describe(\"control\").languages` names the fields a given type takes as a map. Write each language as itself rather than translating one into the other, and give a sentence the SAME `{{ }}` holes in every language — validate() refuses one that reads a node in Finnish and not in English, and refuses a map with no language keys, naming both. Changing language moves the words only: the value a person moved stays where they left it and the machine stays in the state it reached.\n\nTWO SPELLINGS THAT DECIDE WHETHER THE NUMBERS COME OUT RIGHT. A PERCENTAGE IS A LABEL ON A FACE NUMBER: `{ value: 72, unit: \"%\" }` computes as 72, so `rh / 100` is 0.72 and `ln(rh)` is the logarithm of 72, and the two conversions are asked for out loud — `fraction(rh)` gives 0.72 and `percent(x)` gives a hundred times x. A reading in something the library has no unit for is happiest as a plain number with what it is measured in written into its `label`. And `°C` and `°F` are SCALES WITH AN OFFSET, so multiplying one gives a plain number and the formula's own `unit` names the result, which is what makes `{ expr: \"t * 9/5 + 32\", unit: \"°F\" }` mean what its author meant; `convert(t, \"K\")` is how a real conversion is written. Where a statechart stands at the moment it mounts moved between builds, so `AIMEAT.living.version` and `describe(\"machine\")` are the answer for the library THIS node serves.\n\n## Six patterns to copy\n\nEach of these runs as written against the kit this node serves. Copy one, change the words and the data, and the screen it makes is finished.\n\nA LIST THAT ARRIVES — keyed rows, a pick that opens the detail beside them:\n\n```js\nvar jobs = AIMEAT.atelier.listDetail({\n target: a.main,\n items: [],\n empty: { title: 'No jobs yet', hint: 'They appear here as they are booked.' },\n renderDetail: function (item, body) { body.textContent = item.sub; },\n});\nloadJobs().then(function (rows) { jobs.set({ items: rows }); });\n// The rows rise in, keyed by id. On the next set() a new row rises, a gone row fades\n// where it stood, a moved row glides, and a picked row crosses into the detail pane.\n```\n\nA PANEL THAT CHANGES — numbers that count to their new value, with what they are measured in and which way they went:\n\n```js\nvar kpis = AIMEAT.atelier.statRow({ target: a.main, variant: 'trend', tiles: [\n { id: 'booked', label: 'Booked', value: 12480, unit: '€', direction: 'up', delta: '+8%',\n trend: [8, 9, 9, 11, 10, 12] },\n { id: 'due', label: 'Overdue', value: 3, unit: 'jobs', direction: 'down', delta: '-2' },\n] });\nkpis.set({ tiles: [\n { id: 'booked', label: 'Booked', value: 13120, unit: '€', direction: 'up', delta: '+13%',\n trend: [8, 9, 9, 11, 10, 12, 13] },\n { id: 'due', label: 'Overdue', value: 1, unit: 'jobs', direction: 'down', delta: '-2' },\n] }); // each changed figure counts up on its own\n```\n\nA SCREEN THAT SWITCHES — two units of work under one tab row, the crossing already wired:\n\n```js\nvar pane = AIMEAT.atelier.section({ target: a.main, title: 'Open' });\nvar rows = AIMEAT.atelier.list({ target: pane.body, items: open });\nAIMEAT.atelier.tabs({\n target: a.main,\n items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }],\n value: 'open',\n onChange: function (id) {\n rows.set({ items: id === 'open' ? open : done }); // the swap runs inside the kit's\n }, // own screen transition\n});\n```\n\nA FORM THAT LANDS — the confirmation as a toast, the refusal as a dialog, the field rule as a throw:\n\n```js\nAIMEAT.atelier.form({\n target: pane.body,\n fields: [{ name: 'title', label: 'What', required: true },\n { name: 'due', label: 'When', type: 'date' }],\n submitLabel: 'Add job',\n onSubmit: function (values) {\n if (values.title.length < 3) throw { field: 'title', message: 'Give it a few more words.' };\n return save(values).then(function () {\n AIMEAT.atelier.toast({ title: 'Job added', sub: values.title, tone: 'ok' });\n }, function (err) {\n AIMEAT.atelier.dialog({\n title: 'That did not save', text: String(err.message || err), tone: 'danger',\n actions: [{ id: 'ok', label: 'Close', tone: 'primary' }],\n });\n });\n },\n});\n```\n\nA NEARLY-RIGHT ROW — the third line and the right-hand figure the list leaves empty, filled from the row itself:\n\n```js\nAIMEAT.atelier.list({\n target: pane.body,\n items: rows,\n onPick: open,\n parts: {\n extra: function (r) { return r.note; }, // the third line, rendered empty until now\n aside: function (r) { return r.amount; }, // the value on the right\n },\n});\n```\n\nA SHEET THAT RECOMPUTES — the whole page as one record: the slider moves the wall, and the figure, the printed maths, the sentence and the state all follow it:\n\n```js\nvar sheet = {\n v: 1, register: 'genre-living', look: 'vivid',\n layout: { v: 1, nav: 'stack', blocks: [\n { id: 'controls', component: 'section', span: 'full', props: { title: 'The wall' } },\n { id: 'tin', component: 'figure', span: 'half', props: { title: 'Litres of paint' } },\n { id: 'maths', component: 'section', span: 'half', props: { title: 'How it is worked out' } },\n { id: 'note', component: 'section', span: 'full', props: { title: 'What that means' } },\n { id: 'stock', component: 'section', span: 'full', props: { title: 'Tins' } },\n ] },\n model: { nodes: {\n area: { type: 'value', value: 24, unit: 'm^2', min: 2, max: 120, step: 0.5, label: 'Wall area' },\n coats: { type: 'value', value: 2, label: 'Coats' },\n spread: { type: 'value', value: 10, unit: 'm^2/L', label: 'Spread rate' },\n wall: { type: 'control', kind: 'slider', target: 'area', block: 'controls' },\n paint: { type: 'formula', expr: 'area * coats / spread', unit: 'L',\n label: 'Paint needed', block: 'maths' },\n litres: { type: 'binding', block: 'tin', prop: 'value', from: 'paint' },\n advice: { type: 'text', block: 'note', template:\n '{{ area | 1 }} m2 in {{ coats }} coats takes {{ paint | 1 }} litres. '\n + '{{ if paint > 5 }}Buy two tins.{{ else }}One 5 litre tin covers it.{{ end }}' },\n tins: { type: 'machine', block: 'stock', initial: 'one',\n states: { one: { on: { SECOND: 'two' } }, two: { on: { ENOUGH: 'one' } } },\n when: [{ expr: 'paint > 5', send: 'SECOND' },\n { expr: 'paint <= 5', send: 'ENOUGH' }] },\n } },\n};\nAIMEAT.living.validate(sheet); // every refusal in words, before anything is drawn\nAIMEAT.living.mount(a.main, sheet); // the only line of code this page runs\n// m^2 divided by m^2/L is litres, so the unit on `paint` is checked rather than decorative;\n// move `area` to 40 and paint passes 5 L, the sentence changes and the machine goes to two.\n// A bound figure prints a WHOLE number (it counts up to it, and rounds), so the exact\n// reading is the formula's own printout and the sentence: 5 in the tile, 4.8 in the words.\n```\n\n## The mosaic: the arrangement lives outside your file\n\nRender the screen through `AIMEAT.atelier.mosaic(...)` instead of appending components by hand. You declare WHAT the app has — one resolver per data source name, an `onPick`, a `fallback` layout of blocks — and the ARRANGEMENT (order, look, navigation mode) is a stored record the owner's AI can change later with one `aimeat_app_manage` call (action `ui_set`), no republish. Source names are the binding contract: keep them stable across edits. Block ids are part of the same contract: the stored arrangement keeps the old ids after a publish, so a fill for a renamed block never runs. When a version renames or removes a block, replace the arrangement with `aimeat_app_manage` action `ui_set` in the same change, and read `layout: \"kept-existing\"` in the publish answer as that warning.\n\n```js\nvar m = AIMEAT.atelier.mosaic({\n app: a,\n sources: { 'errands.': loadErrandRows }, // name → rows (or a Promise of rows)\n live: { 'errands.': { keyPrefix: 'errands.' } }, // see below — optional\n onPick: function (blockId, item) { open(item); },\n fallback: { v: 1, blocks: [\n { id: 'top', component: 'hero', props: { title: 'Errands' } },\n { id: 'main', component: 'list', props: { source: 'errands.' } },\n ] },\n});\nm.refresh('errands.'); // after your data changed — the change paints with motion\n```\n\nLIVE BY DECLARATION: load `https://aimeat.io/v1/libs/aimeat-live.js` beside the kit and give the mosaic a `live` map — source name → { keyPrefix } naming the memory keys whose change means that source moved. When anything writes those keys (the owner's agent, another device, a schedule), the source re-resolves and the screen repaints with the components' own motion — you never poll, never open a socket, never write a listener. The wiring refuses a memory subscription without a keyPrefix (that would re-fetch on every write anyone makes) and never fires more often than every few seconds. Without the live library on the page the declaration is inert, so it is always safe to write.\n\nEVENTS FIRST, A TIMER LAST. Data that lives on the node reaches the screen because the node said it changed. Before you write `setInterval` around a read, name the event that says this data moved. The owner's records: the `live` map above with a `keyPrefix`. Work an agent does for the app (each stage line of a task, done, failed, a task a schedule created): `live: { jobs: { domains: ['agent-tasks'] } }`, which needs no prefix, and for one task `AIMEAT.agents.watch(agent, taskId, onUpdate)`. The domains an app may hear, each with the permission that opens it: `memory` (memory:read), `agent-tasks` (task:read), `files` (storage:read), `organisms` (organism:read), `workflows` and `scheduler` (workflow:read), `messages` (messages:read), `boards` and `realtime-rooms` (social:read), `wallet` (wallet:read), `knowledge` and `packages` (knowledge:read). `realtime-rooms` says the realtime room list moved: a room opened or closed, a player came or went. Outside a mosaic the same thing is `AIMEAT.live.subscribe(['agent-tasks'], reload, { minIntervalMs: 3000 })`. An event names the domain and never the record, so every change in that domain on the account wakes the page: read while your app has something under way, and re-read the one source that moved. A delete emits its domain as a write does; the aimeat-live description names the few that emit nothing. A timer is right in three cases, and each gets a comment saying which one it is: the data has no event (a public record a signed-out visitor reads, since the stream opens for a signed-in person; an answer from a service outside the node); the text depends on the clock itself (a countdown, \"starts in 5 min\"), which is a repaint and makes no request; one slow read, every ten minutes, that reconciles after a stream that was down. Check it the way a person meets it: start the work and watch the screen follow each stage within a few seconds.\n\nThe layout's `nav` field projects the same blocks as stacked sections, a tab row, a bottom bar, a swipeable deck, a step-by-step flow, a pan-zoom canvas, a desktop-grade left rail (`rail`) or a full-screen menu in display type (`overlay`) — all of them work on every screen size, so never build navigation by hand. On the stacked grid, blocks below the fold reveal as the person scrolls; that too is the kit's, never yours to code.\n\nTwo more one-field decisions, both data and both optional. `choreography: \"cinema\"` makes scroll the camera: the opening band recedes as the person leaves it and each section rises to meet them — right for a front, a story or a report, wrong for a tool someone lives in, and free at idle because it is pure CSS scroll timelines. And a chart block may carry `presentation: \"mural\"`: the chart stops living in a tile and becomes the section's full-bleed ground — the data as the decor, one mural per screen.\n\nTHE MACHINE ROOM IS AN ARRANGEMENT, NOT APP CODE. Four blocks make any admin or monitoring screen: `health` (one row per watched thing — lamp, name, latest reading), `queue` (work items with states, counted in a strip), `gauge` (ONE value on a dial, bands turning the tone) and `console` (the log vane — monospace, capped, follows the tail only while the reader is at the tail). Their tones ride the theme's ok/warn/err colours, so a status screen reads at a glance in every look and mode.\n\nCHARTS ARE A FAMILY on one block: `chart` with `kind: \"axes\"` (bars, lines and filled areas — a series may be kind \"area\"; `stacked: true` piles the bars into one column per label, `horizontal: true` turns ranked things sideways, and a `note` puts a one-line story bubble on the point that matters — every axes chart answers touch with a tooltip on its own), `\"donut\"` (parts of a whole — the total in the middle, and a `delta` puts its change there too), `\"calendar\"` (a stretch of days as a heat grid, months named) or `\"scatter\"` (points on two measures with an honest trend line), `\"funnel\"` (stages losing people — the survival rate written at each step), `\"treemap\"` (shares as area when the donut's slices would not fit), `\"flow\"` (where the quantity went — ribbons as wide as their sums) or `\"radar\"` (profiles on spokes — one polygon per series, for \"strong where, weak where\"). A statRow tile carrying `trend: [numbers]` draws its short history as a filled sparkline under the figure.\n\nWORK AGAINST PEOPLE AND TIME is its own family: `kanban` (work as columns by state — queue shows the same work as a list, this is the board, and with onMove wired the cards actually move), `plan` (stretches on a shared time axis with today drawn as a line — timeline tells what happened, this tells what is running) and `schedule` (a week as a grid, bookings as blocks — chart kind \"calendar\" is the year at a distance, this is next week). And two small truth-tellers: `steps` (where a process stands — done behind, current lit, the rest ahead) and `rating` (a score as stars, display only — collecting one is a form's job).\n\nWHEN THE OWNER SAYS \"A MAP\", THEY MEAN THE REAL ONE: the `map` block is Leaflet over OpenStreetMap street tiles — pins with popups at real addresses, the view framing the markers on its own, the licence's attribution built in, dark mode re-toning the tiles. The `atlas` block is the different, narrower thing: an offline choropleth of countries for data-by-country, no streets on it. Reaching for atlas when the owner asked for a map is a wrong answer with a confident face.\n\nAnd when a screen has earned a SHOWPIECE, the `scene3d` block gives it real depth: `kind: \"orb\"` (a signature object turning under the hand), `\"sky\"` (a procedural atmosphere band), `\"bars\"` (the bound rows stand up as a field of columns — the 3D chart), `\"model\"` (a .glb/.gltf by URL, fitted, grounded and studio-lit like a product shot) or `\"globe\"` (the earth — places as dots, data travelling between them as lifted arcs). One per layout, loaded lazily, colours from the look's tokens, and the render loop stops at rest so an idle scene costs nothing. It is a statement, not a default: most screens want a chart, not a scene.\n\nCOMPOSE, do not pile: a block may carry `span` — `full` (default), `main` + `side` for the asymmetric editorial split, or `half` — and the screen becomes a laid-out page instead of a column of cards. Narrow screens fold every span to one column on their own.\n\nA SETTINGS PAGE AND A QUEUE PAGE HAVE RULES, and a wide screen is where they break. The kit's form fills its container and the page is as wide as the screen, so on a desktop every field becomes a line across the room. Twelve rules, each from a design system or a usability study: (1) no input fills a wide page: a form field's `width` is short (a number), date, medium (a name or email) or long (a URL or a line of text, 32rem), full width only on a phone; (2) help text is at most 60ch per line; (3) one column, the label above its field, and only short related fields share a row; (4) every group of settings is a `settingsGroup` with a heading and ONE sentence of help, and no field stands outside a group; (5) from 840 px the group puts its help in a left column beside the controls, below that above them, and the groups of one page share ONE card divided by hairlines (target them into `
`), each control saving on change; (6) a tool with more than two screens uses `app({ nav: 'side' })`: the pages in a left column, the content capped at 65rem; (7) advanced settings go behind ONE closed disclosure (`reveal`); (8) the primary button aligns left with the inputs, says its verb and spans the width on a phone; (9) a setup screen opens with a `statusBand` (\"5 of 5 done\" and a bar) holding a `checkGrid`, and each missing step is one tile with one fix a tap away; (10) a batch of ten seconds or more is a `progressFigure`: \"3 / 10\", the item being worked on and its steps; (11) a number that changed flashes in place without moving (`attention(el, \"flash\")`); (12) every item an AI classified offers \"Why?\" (a `callout` with the answer, the reason and the data it saw) and \"Correct\", which says what it changes and from when. A work queue is `listDetail`, its queues listed in the side column with counts. THE WHOLE SHAPE IS READY: the look `workbench` and the genre `workbench` (setup, queue, processing and settings screens with sample data) are this design finished; fork the genre rather than drawing it again. AND WHEN THE OWNER APPROVED A DRAWN DESIGN OF THEIR OWN, the order is fixed: the drawing becomes a GENRE first (the drawing's screens as one page on sample data), the owner looks at it running and approves it, and only then is the app forked from that genre. An app built straight from a drawing out of kit parts drifts from it screen by screen, and the owner finds every difference himself (Postinjalostamo, 2026-09-28: three rounds).\n\nTHE FIRST MOVE IS A PRESET, not a blank page: `GET https://aimeat.io/v1/apps/ui/catalogue` carries `layouts` — finished, fillable shapes (cover, dashboard, browse, work-queue, story-deck, guided-flow). Pick the one nearest the app, replace every value with the app's own words and source names, and use it as the fallback — and as the first stored layout when the owner wants one.\n\n## Start from a GENRE — a complete committed register, and the register is required\n\nEvery Atelier app names the register it committed to, and the publish refuses one that does not: `\">` is in every genre's head already, so a fork carries it; a page that commits to a look of its own declares `\">`, where the name says what the register is (custom:game, custom:ledger) and is never \"default\". The bare shell carries a REPLACE-ME line in that place, and the gate refuses it as served: the shell is a frame, not a page.\n\nWhatever the app is — a poster, a console, a departure board, a ledger — do not assemble blocks: FORK A GENRE. Each genre is a finished free-composition page in a committed register; fetch it with `GET https://aimeat.io/v1/app-templates/`, swap the words, sources and images for the app at hand, and KEEP THE PHYSICS (finite entrances, motion only under the hand or the scroll, zero idle repaints — the look's ambient layer is the one declared exception — reduced-motion honesty). The kit's scenic props (`flapify`, `ransom`, `vu`, `typeout`, `dealIn`, the `.ak-stamp` / `.ak-ticker` / `.ak-torn` / `.ak-polaroid` family), the MATERIALS (one class per surface: `.ak-mat--glass`, `--aurora`, `--grain`, `--ink`, `--signal`, `--ring`, `--spot`) and the MOTION RECIPES (`.ak-move--magnet`, `--sheen`, `--deal` as classes; `spotlight`, `tilt`, `sheen`, `odometer`, `thumb`, `deal` as calls — every one answers the hand or a change and rests, none loops), the kit's own MOTION PRIMITIVES (`spring`, `stagger`, `inView`, `scrollLink`, `drag` — Web Animations API, no dependency, finite, a no-op under reduced motion; reach for these before a library) and the pattern shelf below carry the shared stagecraft. When an app needs a full animation library, the node serves three as packs — Motion (`motion`), anime.js (`anime`) and Lenis (`lenis`) — read the pack's doc before writing a line, because every one of them changed its API after the version you know.\n\nORNAMENTS: `AIMEAT.atelier.ornament(el, id, { speed, delay, leaves })` grows an engraved or living SVG figure round ONE element, in the look's colours, once, then holds still: `frame` (block), `vine-border` (block), `rope` (block), `jugend` (block), `guilloche-band` (block), `wreath` (badge), `guilloche` (badge), `vine-bar` (bar), `wrap` (bar), `divider` (rule), `vine-rail` (rule), `braid` (rule), `cord` (rule), `guilloche-strip` (rule), `fleuron` (rule), `dinkus` (rule), `flourish` (heading), `swash` (heading), `dropcap` (text), `ribbon` (heading), `bullets` (list), `ivy` (column), `brackets` (button). The word in brackets is the element it was drawn for. One or two per screen, on what matters: a frame round the card, a vine round the progress bar, flourishes beside the title. Never draw an ornament of your own. See each: https://aimeat.io/v1/designbook/ornament-/preview\nORNAMENT SETS, five figures in one style: `AIMEAT.atelier.ornamentSet(set, { frame: card, rule: emptyEl, bar: progressbar, bullets: ul, strip: emptyEl }, { value })`, any role left out: `modern`, `futuristic`, `cyberpunk`, `vibrant`, `emotional`, `dramatic`, `symmetrical`, `chaotic`, `velocity`, `art-deco`, `crystal`. One set per screen, in the app's mood. See each: https://aimeat.io/v1/designbook/ornament-set-/preview\n\n- `genre-pressdrop` — **The poster drop**: A full-page poster: image and giant type share the same space, duotone washes reveal true colour on hover, tilted stamps, a torn edge, a scroll-driven ticker, a sideways filmstrip with real scale contrast, one loud slab, the wordmark running off the page. For launches, drops, campaigns. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressdrop/preview\n- `genre-nightfloor` — **The night floor**: An ops room at 03:12: one number the size of the room (counts up once), glass panels floating deliberately unaligned that lean toward the pointer, a duotone camera feed with scanlines, a diagonal floor cut, a log rail whose newest line glows. For dashboards that watch one operation. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightfloor/preview\n- `genre-pressctl` — **The console**: The whole page is a terminal: a boot log that types itself once, a phosphor masthead glowing through scanlines, a mono queue table with status bars, gauges in ruled cells, a sticky F-key command bar. For queues, consoles and anything an operator lives in. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressctl/preview\n- `genre-pressindex` — **The index**: Type IS the interface: five giant outline rows are the whole navigation — hover floods the word solid and lights a full-page image behind everything. For fronts and site indexes with few doors. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressindex/preview\n- `genre-quarterly` — **The broadsheet**: A typeset newspaper front page: double-rule masthead, justified columns with a column rule, a red drop cap, a pull quote that breaks the column, a captioned figure, an IN BRIEF rail with numbers, a footer figures grid. For editorial fronts, reports and periodicals. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-quarterly/preview\n- `genre-thewall` — **The gallery corridor**: The page scrolls SIDEWAYS: you walk past framed works hung at their own heights under their own spotlight cones, each with a brass plaque; the wheel walks the corridor and a HUD shows how far. For portfolios and collections. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-thewall/preview\n- `genre-almanac` — **The almanac**: A Swiss data poster: a strict ruled grid, one red, numerals the size of weather, the season as moon dots, a week strip with one burning day. No texture, no tilt, no shadow — the discipline is the style. For stats pages and summaries. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-almanac/preview\n- `genre-blueprint` — **The blueprint**: A cyanotype: white line-work on process blue over grid paper — an SVG floor plan with dimension arrows, dashed callout notes pinned around it, one hot-yellow zone, and a proper title block with a rotated AS BUILT stamp. The light choice gives the whiteprint (blue lines on white paper, red for the hot zone); put running text on whiteprint blocks, because white text on the blue is hard for some eyes to read. For plans, maps and technical overviews. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-blueprint/preview\n- `genre-nightradio` — **The radio**: A valve set on walnut dark: a long tuning dial you drag (the needle springs to the frequency), programme rows that retune it and swap NOW PLAYING, VU bars drawn once per pick, an ON AIR lamp. For players, programmes and schedules. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightradio/preview\n- `genre-receipt` — **The receipt**: The whole page is one object: a giant thermal till roll on a dark counter — perforated tears, dashed rules, dotted leader fills, a VOID line, a rotated PAID stamp in multiply, a barcode — and it prints itself downward once. For confirmations, summaries and orders. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-receipt/preview\n- `genre-fanzine` — **The fanzine**: A photocopied punk collage: a ransom-note headline cut from six sheets, a staple, torn strips carrying shouted paragraphs, taped polaroids thrown on the desk (hover straightens one), xerox noise, a shouty two-line footer. For bulletins, community pages and anything with elbows. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-fanzine/preview\n- `genre-departures` — **The departure board**: A split-flap hall board: every character in its own flap cell, amber on black with green BOARDING and red DELAYED rows, and the whole board flips itself legible once, row by row. A LAST CALL strip below. For schedules, statuses and queues. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-departures/preview\n- `genre-patterndept` — **The specimen sheet**: A pattern specimen page: a zone-pattern banner with the title punched through, swatch cards on springs, a words-on-a-whisper proof card, a loud divider, rule cards. For style guides, catalogues and departments of anything. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-patterndept/preview\n- `genre-nightwatch` — **The night watch**: A small power station's wall at 02:40, all phosphor: the water route drawn as one glowing schematic with the kit's gauge bolted onto it, lamp-lit system cabinets, the watch log in tones, night orders signed on paper, the river's name burning off the page. For plants, fleets and anything one person keeps alive at night. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightwatch/preview\n- `genre-crossing` — **The crossing**: A ferry line's night board: the kit's real map framed to the strait, the route inked across it with the ship mid-water, tonight's sailings ruled like the harbour office copy, a torn boarding stub with a stamped corner. For routes, logistics and anything that moves between two shores. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-crossing/preview\n- `genre-orchard` — **The season book**: A family orchard's year printed as a keepsake: the kit's calendar heat wall hung as a framed print (the story readable in its shape), the harvest weighed in a ruled grid, the split as a ring with a jam-lid badge, torn diary strips taped down crooked. For seasons, logs and any year worth keeping. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-orchard/preview\n- `genre-mtv` — **Music television**: 1980s music TV at night: a broadcast ident bar, a block logo with a sprayed tag, a CRT set whose credits box carries the provenance (maker · machine · human share), countdown rows with outlined numerals lit by their channel colour, neon channel chips, a cassette submission band and a yellow news strip at the floor. Proven live in an AI music chart. For charts, players, countdowns and anything that is ON AIR. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-mtv/preview\n- `genre-nighttrain` — **The night train**: A scroll STORY on the kit's director: one journey, Helsinki to Rovaniemi, told chapter by chapter under Lenis. The platform board and its lamps, a carriage of berths that light as a wave, the stations passing SIDEWAYS under vertical scroll, the aurora as three parallax layers behind a window, the route drawing itself with the distance filling a ring, and the doors opening at the end. The rail marks the chapter, the arrow keys move, the scroll snaps to a chapter start when the hand lets go. Fork it for anything told in order: a product launch, a year in review, a route, a recipe, an onboarding. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nighttrain/preview\n- `genre-platformer` — **Ridge Run**: A GAME: a night patrol on a ridge as a platformer on aimeat-phaser. Three nights as levels the save unlocks, coins as lamps, spikes, a fox on patrol, the cairn as the goal; title and level-select scenes, pause, a settings panel, the synth for coin, hit and win. Around the canvas: a conditions board, the ledger of the three nights, the patrol log. For any platformer. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-platformer/preview\n- `genre-shooter` — **Harbour Watch**: A GAME: a top-down shooter on aimeat-phaser. A launch on dark water, stick or WASD to steer, the pointer to aim, drifting mines to clear and lanterns to collect, waves that grow, the best wave saved; title, game over from menuItems, pause, settings, gamepad on. For any twin-stick or arena shooter. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-shooter/preview\n- `genre-match` — **Market Stall**: A GAME: a match-three puzzle on aimeat-phaser, the light page. A 7 x 7 crate of produce, swap by pointer or keys, cascades, a hands counter and a target per crate, three crates, the best saved; title, pause, settings, the synth for a match. For any tile puzzle. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-match/preview\n- `genre-runner` — **Night Courier**: A GAME: an endless runner on aimeat-phaser. One button, a seeded roof pattern that always stays jumpable, vents to hop and gaps to clear, speed that rises, distance as the score, a parallax skyline from generated textures; title, game over, pause, settings, gamepad on. For any one-button runner. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-runner/preview\n- `genre-living` — **The record sheet**: A LIVING DOCUMENT: a nursery's growing record for one glasshouse block, and the whole sheet is one JSON record on aimeat-living. Two readings are entered by hand; the conversion, the dew point set as mathematics beside its answer, the wall number, the dial, the day's four bars, the sentence that changes at 30 °C and the standing order a statechart writes are all worked out from them, and the chain of who feeds whom is drawn in the margin and lights along the path a change travelled. Numbered fields, a filing head, a rubber stamp for the state, and every colour off the tokens, so it prints in either theme. Fork it for anything whose numbers stand on each other: a calculation sheet, a survey, a dosing record, a spec you can move. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-living/preview\n- `genre-workbench` — **The workbench**: A TOOL someone works in every day, on the kit's own workbench pieces and the workbench look: the app's mark and name in a solid bar, the pages in a left column with counts and tone dots, a status band with readiness tiles, three ways to let AI help, a queue as list and detail with a reason callout, a batch as \"3 / 10\" with its tallies, and settings with the help beside controls sized to their content. For intake, review and admin tools. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-workbench/preview\n\nFIXED OR FOLLOWING is the owner's choice, and both are right. A FIXED genre is a finished object with its own colours: it looks the same at noon and at night, and the sign-in bar's light/dark control stands down on it. A FOLLOWING page is drawn in the theme's `--ak-*` tokens and changes with the person's light/dark and palette, which is what a tool people work in all day usually wants. Following today: `genre-blueprint`, `genre-living`, `genre-workbench`; every other genre is fixed. A fixed genre becomes a following one by replacing its hardcoded colours with `--ak-*` tokens and changing `` to `follows`: keep the composition, the type and the physics, and check it in BOTH modes beside the original, because a palette that was tuned for one ground rarely survives the other untouched. Every picture of a genre is one address away (`See it`), and the whole shelf is https://aimeat.io/v1/design-book; give the owner the links, do not describe a look in words when they can look.\n\nTHE TRAP THIS SECTION EXISTS TO STOP: a mosaic block stack wearing a look is a tool screen, never a statement — assembling components and applying a world reads as \"the same dashboard in new paint\" no matter which world. When a page must IMPRESS, start from the SUBJECT (whose page is this, what does it say), fork the genre that carries that register, and let the components serve the page — they mount in any element, so a free-composed page can still carry a live gauge or a map. If you cannot name what the page is about beyond \"it shows the blocks\", you are building a demo, and a demo never looks designed.\n\n## A fork people sign in to, in two languages\n\nA genre is a finished page with no sign-in, no language switch and its words in one language. Your fork adds all three, the same way every time. Do not write a header or a sign-in control of your own: the bar below is the node's, it carries the language switch and the light and dark control, and a hand-made one is the first thing a review sends back.\n\n**Two languages is the default: `en fi`.** Keep both unless the owner asked for one. Every word the page shows goes through a dictionary; a string typed into the markup is a string that cannot change language, and a page where the bar is Finnish and the content English is refused at review.\n\n```html\n\n\n\n\n\n
\n

\n\n\n\n\n```\n\nThe switch must keep what the person was doing: a conversation, a half-filled form and the settings survive it, because `paint()` changes words and nothing else. Numbers, dates and money follow the language too (`toLocaleString(i18n.lang())`). Languages of speech recognition or of an AI answer are separate settings; do not tie them to this switch unless the owner asks.\n\nAn app nobody signs in to still mounts the bar when it has two languages, because the switch lives there. Before you call it done, press the switch: English to Finnish and back, in the middle of using the app, and read every screen in both.\n\n**What the genre does not have, the kit has, and it wears the genre.** A form, a dialog, an empty state, a toast, a chart or a gauge comes from `AIMEAT.atelier`, never from your own markup. Every fixed-colour genre carries a block marked THE BRIDGE after its `:root`, which hands the kit the genre's ground, ink, one accent, corners and faces, so a kit component mounted into the page looks like part of it. When you change a colour of the genre, change it in the bridge with it. Mount a component ON the genre's own ground (the paper of a receipt, the panel of a board), where its ink is readable.\n\n## The node's libraries: read this list before you write a mechanism\n\nSpeech, audio, files, live updates, notifications, printing, calendars, decisions, payments and agents are already written, served by this node and kept in step with it. Before you write a mechanism of your own, find it here. An app that runs its own speech loop, its own socket or its own `fetch` to `/v1/memory` works on the day it ships and stops following the platform afterwards, and the publish says so (`app_hints`, pitfall `hand-rolled`).\n\nLoad with `\n\n\n
\n\n```\n\nTHE FILL COMES FROM THE BOOK: pick one from the list at the end of this part, read it with `aimeat_designbook_get { id }`, replace every value with this app's words and source names, take its `look` line out (in a genre the genre is the look, and the bridge makes every block wear it), and put it in the `#aimeat-layout` block. THE PUBLISH DOES THE REST, so there is nothing to call afterwards: it counts each part the meta names as used (once per app), and on the app's FIRST publish it stores the `#aimeat-layout` block as the app's arrangement, so from then on the owner's AI rearranges the screen with `aimeat_app_manage` action `ui_set` and no republish; a later publish never writes over what they arranged. The answer's `next_steps.design_book_parts` says what was counted, what it does not hold, and whether the layout was stored. Compose blocks of your own only where no fill is near.\n\nWhat stays hand-made in a genre fork is what the genre itself is made of: a figure only this page has, the masthead, a game board. Everything a mosaic block can show is a block.\n\nCOMPONENTS: WHAT ANOTHER APP MADE BY HAND. The list at the end of this part has a COMPONENTS group: pieces of page an earlier builder made because the Book had nothing, from apps whose owner was satisfied. Take one with `aimeat_designbook_adopt { id, filename }`, before your app exists: it answers `snippet` { html, css, use, prefix }, which you build into the page as they are. A component carries NO script, so you wire its behaviour as `use` says, and it reads the page's tokens, so inside a genre it wears the genre. Look there before you make a grid, a strip, a dial or a board of your own.\n\nWHEN YOU DO MAKE SOMETHING BY HAND, MAKE IT SO IT CAN BE OFFERED LATER, which costs nothing now: give it ONE class prefix of its own (`wkgrid`, `wkgrid-cell`), take every colour from a `var(--ak-…)` token and never a literal, and keep its behaviour in your script, reading `data-` attributes on the markup. That is exactly the shape the Book takes a component in, so when the owner says the app turned out well it goes onto the shelf as it is.\n\nWRITE DOWN WHY, AS YOU CHOOSE. A count says an AI reached for a part; it does not say the part is any good, and nobody can improve the Book from a number. So the page carries your reasons, one sentence each, in a third block beside the two above:\n\n```html\n\n```\n\n`took` is a part that is in this page and what made it fit (a part named here needs no `aimeat-book-parts` meta). `passed` is a part you looked at and left, and what made it NOT fit: it is the only place a part's weakness is ever written down, so it is the most useful of the three. `made` is what you built by hand because the Book had nothing, and why it had nothing. Write the true reason, including \"the name matched and I did not look further\": a reason that sounds good and is not why you chose teaches the Book the wrong thing. The publish keeps these with the version they belong to. NOTHING GOES INTO THE BOOK BECAUSE A BUILD IS FINISHED. An app is often rebuilt twice before its owner likes it, and a version that was thrown away must not teach the Book anything. Tell the owner, in one line when you hand the app over, that when they are happy with it they can say so; that is recorded with `aimeat_designbook_keep { filename }`, by whichever AI they say it to, and it is the moment what this app took and made starts to count.\n\n## AI inside the app\n\nThe `aide` block puts an AI panel on the screen whose tools are the app's OWN declarations: hand the mosaic spec your `sources` and an `actions` list ({ id, summary, params?, run }) and the aide can read what the screen reads and PROPOSE what the buttons do — a person confirms every run, the platform AI notice and provenance labels are built in, and it runs on the owner's own key (it sleeps politely when no key is set). A model answer may be a small mosaic panel rendered inline over the same sources — arrangement from the closed vocabulary, never markup. Two more affordances every mosaic carries: `m.explain()` renders \"what this screen holds\" from the declarations (never hand-write a help text that will drift), and `m.setOverlay({ hidden, order, nav })` applies THIS VIEWER'S own arrangement over the owner's page — store it in the viewer's own memory (`atelier.overlay.`), never in the owner's layout.\n\n## Data, in short\n\nLogin and data come from `aimeat-auth` and `aimeat-data` exactly as on the rest of the platform: the shell hands you the session in `onReady`; private data is `AIMEAT.data.set/get` with a `.`-prefixed key; one key holds one record a user opens as a unit, never one key per field; read back after writing. Declare the scopes the app uses in ``.\n\n**How the data map answers steer the build** (the three questions of the interview). SHARED BY THE TEAM: ONE organism workspace that every member reads and writes, through `AIMEAT.organism` (read, writeDraft, publish); `AIMEAT.atelier.workspacePicker({ target, app, onReady })` picks or creates it on the first run. Never per-user memory for team data. PERSONAL: `AIMEAT.data.set/get`, private to each person. PUBLIC: a record with `visibility: public`. WHO OPENS IT: the app's `open_to` setting, set when you publish (`anyone`, `signed-in`, or `organism:` for one organisation's members) with `aimeat_app_manage` action `settings` or PATCH /v1/apps/:filename; the data map's `form` says the same (`group` or `organism-workspace` for a team app). THE TRAP: a team app built on per-user memory gives every person an empty copy of their own, and nobody sees what a colleague added.\n\n## Finishing\n\nBefore you call it done: open the app at 390×844, 1280×900 and 1280×460 in BOTH themes; `document.body.scrollWidth === document.documentElement.clientWidth` at every width; every state (loading, empty, error, signed-out) reached through `a.status(...)`; no console errors. Publish with `aimeat_app_publish` and pass `spec_token: atelier-b982bcc761d3` — the digest of this document — so the node can tell the app was built against the spec in force.\n\n## What the review always catches\n\n- A form that switches into edit mode says so: retitle it and its primary action (\"Edit entry\" / \"Save changes\"), and the row being edited stays visibly selected. A form still headed \"Log an entry\" while it edits reads as adding a duplicate.\n- Counters and the lists beside them read from the SAME data, computed in one place. A screen whose numbers disagree with its rows reads as broken even when both are defensible.\n- Say a number ONCE. The same three counts as a stat row, as tab labels, as chips and again in a heading is the most common defect the review finds — pick the one place the number earns, and delete the echoes.\n- The content people came for comes BEFORE the form that adds to it. In a journal, reading is the daily act; a full-height form above the entries buries the product under its input.\n- Master-detail is ALWAYS listDetail, never a hand-rolled pick panel: the component carries the selection mark, the row-to-detail morph and the narrow-screen fold, and a hand-rolled panel loses all three.\n- The shell's bar is the ONLY top bar. Building a second header of your own puts two bars and the account pill in a fight for the same edge.\n- A filter applies WHEN IT CHANGES. A separate Show/Apply button beside a dropdown is a second step nobody expects of a filter.\n- Give the shell a `tagline` (one line on what the app IS): the sign-in screen presents the app with it, so a first visitor learns what they are looking at before they log in.\n- Storage internals never reach the person: \"under keys that start with standup.\" is a sentence for a developer, not for a screen.\n\n## Never\n\n- daisyUI/Tailwind classes outside a `section` body — the kit is the vocabulary.\n- Hand-written ARIA, focus management or animation code — the components carry them.\n- A theme, palette or language control — the login pill owns all three.\n- An invented script/style URL — everything the app loads is named in the shell.\n- The Classic build spec — two tracks, two guides, no mixing.\n","body":"## The Atelier track\n\nYou are building on the ATELIER track. Its guide is THIS document and the `node:aimeat-app-builder-atelier` skill — never the standard build spec at /v1/prompts/build-app, whose vocabulary (daisyUI classes, hand-written boilerplate) does not apply here. The app declares `` so a later session loads the right guide.\n\nTHE FIRST MOVE OF THE BUILD IS THE GENRE FORK. An app here starts from a committed register, never from the bare shell: list the genres with `GET https://aimeat.io/v1/designbook?kind=genre`, fork the one that carries the page's register with `GET https://aimeat.io/v1/app-templates/genre-`, and swap the words, sources and images (the genre section below has the menu). Every Atelier app declares the register it committed to — `\">`, which every genre already carries, or `custom:` for a page that commits to a look of its own — and the publish REFUSES an Atelier app that names none.\n\nThe shell is the frame the genres are built on — fetch it to learn the structure, never invent it:\n\n```\nGET https://aimeat.io/v1/app-templates/shell-atelier\n```\n\nIt carries a REPLACE-ME register line on purpose, so published as it is served it is refused: the shell is a frame, not a page. A GAME starts from the game shell instead: the same frame with a Phaser canvas, a title menu, pause, settings and a leaderboard already wired through aimeat-phaser, and its register is the canvas (`custom:game`):\n\n```\nGET https://aimeat.io/v1/app-templates/shell-phaser-game\n```\n\nThe head is eight lines and stays that way: the ceremony (theme restore, login boot, mobile guards, designed states, accessibility wiring, motion) lives in the served kit, not in your file. Every byte you add is a byte you re-read on every edit.\n\n## The components (`AIMEAT.atelier`)\n\nEvery component takes a spec and returns `{ el, set(patch), destroy() }`. Copying an example below yields a finished, beautiful, accessible piece — that is the paved path.\n\n- `app` — The shell that carries the whole ceremony: login pill + boot, language re-render, designed loading/empty/error/sign-in states, the only scrolling region, the bottom chrome reserve, and the ambient layer behind the frame (the look decides; `ambient` names a preset, `{ preset, alpha, speed }`, or `false`). Fill handle.main; switch states with handle.status().\n ```js\n var a = AIMEAT.atelier.app({ title: 'Errands', look: 'vivid', onReady: function (s) { render(a, s); } });\n ```\n- `hero` — The ONE focal band a screen gets (two heroes is shouting, zero is flat). With no image it paints a designed gradient mesh; with an image the text sits on a mode-following scrim. data: URIs are refused — upload to storage and pass the URL.\n ```js\n AIMEAT.atelier.hero({ target: a.main, title: 'Errands', sub: '3 open', actions: [{ id: 'add', label: 'Add', kind: 'primary', onClick: addOne }] });\n ```\n- `statRow` — The KPI strip. On set(), a changed figure counts up — the state-change motion arrives with the data.\n ```js\n var kpis = AIMEAT.atelier.statRow({ target: a.main, tiles: [{ id: 'open', label: 'Open', value: 3 }] }); kpis.set({ tiles: [{ id: 'open', label: 'Open', value: 4 }] });\n ```\n- `list` — Rows keyed by id: set() adds (slides in), removes and updates (flashes) instead of rebuilding. Rows are real buttons when onPick exists; an empty list renders the designed empty state.\n ```js\n var l = AIMEAT.atelier.list({ target: a.main, items: [], onPick: open, empty: { title: 'No errands yet', action: { label: 'Add one', onClick: addOne } } }); l.set({ items: rows });\n ```\n- `listDetail` — The list beside a detail pane, split by a container query: a narrow box shows one pane at a time with a back affordance. You render the detail; select() drives it.\n ```js\n var ld = AIMEAT.atelier.listDetail({ target: a.main, items: rows, renderDetail: function (item, body) { body.textContent = item.title; } });\n ```\n- `cardGrid` — The browsing grid. Every card has an art area with zero images: deterministic monogram washes keep a pictureless grid designed, never grey.\n ```js\n AIMEAT.atelier.cardGrid({ target: a.main, items: products, onPick: openProduct });\n ```\n- `mediaCard` — One card on its own — a feature, a highlight — with an optional action row.\n ```js\n AIMEAT.atelier.mediaCard({ target: a.main, item: { id: 'p1', title: 'Featured' }, actions: [{ id: 'go', label: 'Open', kind: 'primary', onClick: go }] });\n ```\n- `form` — Fields declared as data, accessibility wired for you (labels, hints, worded inline errors, focus to the first problem). Throw { field, message } from onSubmit and the form places your rule like its own. NEVER hand-roll inputs or ARIA.\n ```js\n AIMEAT.atelier.form({ target: dlg, fields: [{ name: 'title', label: 'What', required: true }, { name: 'due', label: 'When', type: 'date' }], onSubmit: save });\n ```\n- `table` — Real table semantics that scroll INSIDE THEIR OWN BOX (the page never widens), sortable headers with aria-sort, tabular numerals.\n ```js\n AIMEAT.atelier.table({ target: a.main, columns: [{ key: 'name', label: 'Name', sortable: true }, { key: 'n', label: 'Count', align: 'right' }], rows: rows });\n ```\n- `searchBar` — Debounced search that reports the query; what it means is your business.\n ```js\n AIMEAT.atelier.searchBar({ target: a.main, onChange: function (q) { l.set({ items: filter(rows, q) }); } });\n ```\n- `timeline` — Events on the vertical line every history and activity view shares.\n ```js\n AIMEAT.atelier.timeline({ target: a.main, items: [{ id: 'e1', ts: Date.now(), title: 'Published', tone: 'ok' }] });\n ```\n- `tabs` — A tab row that reports the pick; you swap the view.\n ```js\n AIMEAT.atelier.tabs({ target: a.main, items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }], onChange: show });\n ```\n- `figure` — The data IS the hero: one giant numeral with its label and context line, counting up on change — use it when a single number is what the person came to see.\n ```js\n AIMEAT.atelier.figure({ target: a.main, value: 48, label: 'Combined storage', sub: 'Monday looks like the wettest day.', delta: '-19% vs last year' });\n ```\n- `section` — The titled card AND the escape hatch: markup the catalogue cannot express goes inside a section body, so custom work keeps the surface, the measure and the entrance. This is the ONLY place raw HTML belongs.\n ```js\n var s = AIMEAT.atelier.section({ target: a.main, title: 'Custom' }); s.body.appendChild(myOwnMarkup);\n ```\n- `emptyState` — The designed empty/error/notice card — spot mark, title, hint, action. Never ship a bare string or a grey box.\n ```js\n AIMEAT.atelier.emptyState({ target: host, title: 'Nothing matched', hint: 'Try another word.' });\n ```\n- `skeleton` — Loading placeholder rows the real content replaces; the shimmer is finite.\n ```js\n var sk = AIMEAT.atelier.skeleton({ target: a.main, rows: 3 }); load().then(function (rows) { sk.destroy(); l.set({ items: rows }); });\n ```\n- `sideNav` — The left column of a working tool: entries with a count and a tone dot, under group headings. Usually through app({ nav: 'side', navItems }), which also folds it into the bottom bar on a phone; handle.nav.set({ value, items }) moves the mark and the counts.\n ```js\n var a = AIMEAT.atelier.app({ title: 'Mail', logo: LOGO_URL, look: 'workbench', nav: 'side', navItems: [{ id: 'setup', label: 'Setup', count: '5/5', tone: 'ok', onPick: show }, { id: 'unclear', label: 'Unclear', count: 1, tone: 'warn', group: 'Waiting for you', onPick: show }] });\n ```\n- `statusBand` — A page's opening card: where things stand (title + one sentence), a progress bar, one primary action. Its body takes a checkGrid.\n ```js\n var b = AIMEAT.atelier.statusBand({ target: a.main, title: 'Ready', text: 'Five of five done.', progress: { value: 5, total: 5 }, action: { label: 'Run a batch', onClick: run } });\n ```\n- `checkGrid` — Readiness tiles: ok, todo (needs the person, click to fix), optional, fail, wait. One line under each title.\n ```js\n AIMEAT.atelier.checkGrid({ target: b.body, items: [{ id: 'mail', state: 'ok', title: 'Mailbox', sub: 'Gmail' }, { id: 'send', state: 'optional', title: 'Forwarding', sub: 'Not in use' }], onPick: fix });\n ```\n- `choiceCards` — Two to four ways to do one thing as a radio group of cards, and a panel under them the app fills for the chosen one.\n ```js\n AIMEAT.atelier.choiceCards({ target: s.body, items: [{ id: 'chat', kicker: 'Your own AI', title: 'Interview me', text: '…' }, { id: 'agent', kicker: 'Connected', title: 'Let an agent do it' }], renderPanel: function (item, host) { host.textContent = item.title; } });\n ```\n- `settingsGroup` — One group of settings: heading and one sentence on the left, the controls on the right capped at a measure; folds to one column on a narrow box. Give each form field a `width` (short, date, medium, long).\n ```js\n var g = AIMEAT.atelier.settingsGroup({ target: a.main, title: 'Batch', hint: 'How much mail one run reads.' }); AIMEAT.atelier.form({ target: g.body, fields: [{ name: 'size', label: 'Messages per batch', type: 'number', width: 'short' }], onSubmit: save });\n ```\n- `progressFigure` — A batch while it runs: \"3 / 10\" as the largest thing, the bar, the item being worked on with step chips, toned tallies. set() counts up.\n ```js\n var p = AIMEAT.atelier.progressFigure({ target: a.main, label: 'Processing', value: 3, total: 10, now: subject, steps: [{ label: 'read', state: 'done' }, { label: 'extract', state: 'now' }], counts: [{ id: 'ok', label: 'Clear', value: 2, tone: 'ok' }] });\n ```\n- `promptPanel` — The person's own AI helps: copy the prompt, paste the answer; expect \"json\" hands onResult the parsed object.\n ```js\n AIMEAT.atelier.promptPanel({ target: panel, prompt: setupPrompt, expect: 'json', onResult: preview });\n ```\n- `queueRow` — A queue item's content (who, when, subject, chips, why it waits), as a list row part.\n ```js\n parts: { row: function (r) { return AIMEAT.atelier.queueRow({ who: r.from, when: r.at, title: r.subject, chips: [{ text: r.klass }] }); } }\n ```\n- `callout` — A tinted note with a tone (info, ok, warn, err) that says why: why an item is unclear, what failed, what to do.\n ```js\n AIMEAT.atelier.callout({ target: detail, tone: 'warn', title: 'Why this is unclear', text: reason });\n ```\n- `margins` — Wide screens: the sides wear the home margin figure.\n ```js\n AIMEAT.atelier.margins(AIMEAT.atelier.marginsOf(prefs));\n ```\n\n## A COMPONENT THAT IS NEARLY RIGHT IS CUSTOMISED, NEVER COPIED\n\nFour doors, the same four on every component; `AIMEAT.atelier.describe(\"list\")` tells you which ones a component has, and `describe()` names every component that answers.\n\n1. **Named parts.** Every element the kit builds carries `data-ak-part=\"\"`; your own CSS reaches it by name — `[data-ak-part=\"aside\"] { … }` — so the rule keeps working when the markup around it changes, which a selector written by DOM depth does not.\n2. **Slots.** `parts: { : value }` on the spec; a value is a string, a DOM node, an array of those, or a function of the row returning one of those. `extra`, `aside`, `before` and `after` are rendered EMPTY and appear the moment you fill them, so a row that needs a third line and a value on the right is `AIMEAT.atelier.list({ items, onPick, parts: { extra: function (r) { return r.note; }, aside: function (r) { return r.amount; } } })` and nothing more. A slot returning `null` removes that part. `parts.row` (`item` on timeline, `card` on kanban) replaces the whole row, and it is still keyed, entered and picked.\n3. **Variants.** `variant: \"dense\"` stamps `data-ak-variant` and the stylesheet reads it, so you PICK a legitimate shape: `dense` and `plain` on list, listDetail, table, timeline, cardGrid, mediaCard, queue, health, kanban, section, searchBar and shelf; `numbered` on list and listDetail; `wide` on cardGrid; `lined` on table; `tall`, `compact` and `center` on hero; `compact`, `trend` and `plain` on statRow; `compact` and `center` on figure; `compact` on rating, aiTask, aiChat and requestPanel; `plain` on doc and board; `fill` on board; `dense` on tabs, bottomNav, segmented, members, workspacePicker, workflowInput and handbook; `dense` and `plain` on fingerprint; `pill` on tabs; `quiet` on section; `ghost` on stateButton; `table` on members and workspaceTeam. An unknown name is refused with a console line naming the real ones.\n4. **Per-component tokens.** `--ak-list-aside-size`, `--ak-stat-figure-size`, `--ak-card-aspect`, `--ak-hero-title-size` and seventy-five more, each defaulting to the value the component already had. Set one on YOUR OWN element and exactly that part changes, in every look and both modes.\n\nA statRow tile and a figure also take `unit` (what the number is measured in) and `direction: \"up\"|\"down\"|\"flat\"` with `delta` (how far it went, in your own words).\n\nEVERYTHING CUSTOMISED STILL MOVES: a slot fills the row the kit already built and keyed, so the entrance, the glide, the exit, the pick and the selection mark are unchanged.\n\nStyle through those four doors and the app keeps every later fix: leave the `.ak-*` selectors to the kit, and put the piece you would have bolted on with wrapper markup into the slot that is waiting for it.\n\nFORK ONLY AS A LAST RESORT: copy the component's markup out of its module and its `.ak-*` rules out of `/lib/aimeat-atelier/*.css`. You keep the tokens, the look and the motion helpers; you give up the keyed reconcile, the designed empty state, the accessibility wiring and every later fix. `describe(id).fork` says what that one costs. The dialog family stays whole whatever happens — the focus trap, Escape and focus return are the browser's through native `` — so your own markup goes in its `body(host)`.\n\n## A LIVING DOCUMENT: A SHEET WHOSE NUMBERS STAND ON EACH OTHER IS A RECORD\n\nWhen what the person asked for is a calculation sheet, a survey, a dosing record, a reading log or a spec that recomputes — anything where moving one number should move the rest — the arithmetic belongs in the document. Fork the genre with `GET https://aimeat.io/v1/app-templates/genre-living` and write ONE JSON record on `aimeat-living`: `{ v: 1, register, look, layout, model }`, where `layout` is an ordinary mosaic arrangement (the same blocks and spans you already write, and the person can rearrange them) and `model.nodes` is one dependency graph. `AIMEAT.living.mount(host, record)` is the only line of code on the page.\n\nASK THE LIBRARY, RATHER THAN TRUSTING ANY LIST. `AIMEAT.living.describe()` names every node type and `AIMEAT.living.describe(\"formula\")` gives its inputs, outputs, options and a worked example, read out of the node modules' own source so it says what this build does. `AIMEAT.living.validate(record)` reads a document WITHOUT running it and answers with every refusal in words — an unknown node, a circle naming the two ids, a unit that will not add, a block that is not there. Call it before you save.\n\nTHE NINE NODE TYPES, one line each so you know what to ask about: `value` (a named quantity, the writable ground the rest stands on), `formula` (a spreadsheet expression over other node ids, worked out with its units and printed as mathematics), `control` (a slider, toggle, pick, number or text field on ONE value), `binding` (one block prop reads one node), `text` (a sentence that changes when the numbers do), `machine` (a statechart in XState's vocabulary, whose output is the state it is in), `source` (a live value from a memory key or from an address), `trigger` (when a machine transitions, the document tells an address or one of the owner's own agents) and `decide` (the decision model reads a text and moves a machine by its own events above a threshold; below it, a person decides; the page then also loads aimeat-decide.js and the app asks for ai:use).\n\nWHERE A NODE LANDS ON THE SCREEN, two roads: a `binding` feeds a kit component — a figure's value, a gauge's reading, a chart's series — and the refresh goes through the mosaic's own door, so the count-up and the glide run for you; and a `block` field on a control, formula, text, machine or value node draws it into a `section` block of the same arrangement, which is where a node goes when the kit has no component for it.\n\nA DOCUMENT CAN ALSO REACH OUT, AND ONLY THROUGH ONE DOOR. A `trigger` fires when a machine TRANSITIONS — not on every recompute — and sends one message carrying the whole state: the document, the time, which machine moved from where to where on which event, every value with its unit and its label, and every machine's state. Its target is a url or one of the owner's agents, and an agent target becomes a task titled with the crossing. A `source` reads the other way, off an address, with a path into the answer and an `every` in seconds; a read that fails keeps the last value and writes the refusal into the node's `stale` output. Both go through the node's `living-hooks` extension as the signed-in caller, so the owner's allowlist decides which hosts may be reached — never the record, and never the browser calling a third party directly. A guest sees both roads disabled with words. Two switches are the owner's: `hooks: { enabled: false }` on the document stops every trigger, and `enabled` on a trigger stops that one. An address that wants a key gets it by NAME: a trigger's or a source's `headers` may carry `{{secret:NAME}}`, which the node fills from the signed-in owner's vault on the way out, so the record holds the placeholder and never the key. The gear dialogs offer the owner's stored names to pick from; a name the owner has not stored fails by name, and the words to give the person are \"store it as NAME on your Access page, section 04 Secrets, or ask your AI\".\n\nTHREE THINGS THAT KEEP IT A DOCUMENT. The arithmetic lives in a formula node, so the person changes what the sheet works out by asking their own AI to edit the record. It computes in the browser and persists as the record, which is a memory key — a slider moves faster than a request returns. And the record names a register the same as any other Atelier page, so the sheet arrives wearing a look somebody designed.\n\nONE LINE IN THE HEAD DECIDES WHETHER THE READER MAY CHANGE THE LIGHT. A genre that hardcodes its palette carries `` beside its register line, and the login pill's light/dark control stands down there rather than doing nothing; a fork inherits that line, so DELETE it (or write `content=\"follows\"`, which genre-living does) as soon as your page's colours are `--ak-*` tokens and it follows the theme — otherwise the switch is dead and the reader's operating system decides light or dark for them.\n\nA LABEL IS A LANGUAGE MAP. Any human-facing string in the record may be written as `{ \"fi\": \"Ilma ovella\", \"en\": \"Air at the door\" }` rather than as a plain string — a label, a hint, a pick's option, a text node's whole template, the words a machine's entry action writes, and a layout block's `title`, `sub` or `caption` — so ONE record is the document in every language it was written for. The page's language decides which is read (the login pill sets it), the record's own `lang` is the fallback and the map's first key the last resort; `describe(\"control\").languages` names the fields a given type takes as a map. Write each language as itself rather than translating one into the other, and give a sentence the SAME `{{ }}` holes in every language — validate() refuses one that reads a node in Finnish and not in English, and refuses a map with no language keys, naming both. Changing language moves the words only: the value a person moved stays where they left it and the machine stays in the state it reached.\n\nTWO SPELLINGS THAT DECIDE WHETHER THE NUMBERS COME OUT RIGHT. A PERCENTAGE IS A LABEL ON A FACE NUMBER: `{ value: 72, unit: \"%\" }` computes as 72, so `rh / 100` is 0.72 and `ln(rh)` is the logarithm of 72, and the two conversions are asked for out loud — `fraction(rh)` gives 0.72 and `percent(x)` gives a hundred times x. A reading in something the library has no unit for is happiest as a plain number with what it is measured in written into its `label`. And `°C` and `°F` are SCALES WITH AN OFFSET, so multiplying one gives a plain number and the formula's own `unit` names the result, which is what makes `{ expr: \"t * 9/5 + 32\", unit: \"°F\" }` mean what its author meant; `convert(t, \"K\")` is how a real conversion is written. Where a statechart stands at the moment it mounts moved between builds, so `AIMEAT.living.version` and `describe(\"machine\")` are the answer for the library THIS node serves.\n\n## Six patterns to copy\n\nEach of these runs as written against the kit this node serves. Copy one, change the words and the data, and the screen it makes is finished.\n\nA LIST THAT ARRIVES — keyed rows, a pick that opens the detail beside them:\n\n```js\nvar jobs = AIMEAT.atelier.listDetail({\n target: a.main,\n items: [],\n empty: { title: 'No jobs yet', hint: 'They appear here as they are booked.' },\n renderDetail: function (item, body) { body.textContent = item.sub; },\n});\nloadJobs().then(function (rows) { jobs.set({ items: rows }); });\n// The rows rise in, keyed by id. On the next set() a new row rises, a gone row fades\n// where it stood, a moved row glides, and a picked row crosses into the detail pane.\n```\n\nA PANEL THAT CHANGES — numbers that count to their new value, with what they are measured in and which way they went:\n\n```js\nvar kpis = AIMEAT.atelier.statRow({ target: a.main, variant: 'trend', tiles: [\n { id: 'booked', label: 'Booked', value: 12480, unit: '€', direction: 'up', delta: '+8%',\n trend: [8, 9, 9, 11, 10, 12] },\n { id: 'due', label: 'Overdue', value: 3, unit: 'jobs', direction: 'down', delta: '-2' },\n] });\nkpis.set({ tiles: [\n { id: 'booked', label: 'Booked', value: 13120, unit: '€', direction: 'up', delta: '+13%',\n trend: [8, 9, 9, 11, 10, 12, 13] },\n { id: 'due', label: 'Overdue', value: 1, unit: 'jobs', direction: 'down', delta: '-2' },\n] }); // each changed figure counts up on its own\n```\n\nA SCREEN THAT SWITCHES — two units of work under one tab row, the crossing already wired:\n\n```js\nvar pane = AIMEAT.atelier.section({ target: a.main, title: 'Open' });\nvar rows = AIMEAT.atelier.list({ target: pane.body, items: open });\nAIMEAT.atelier.tabs({\n target: a.main,\n items: [{ id: 'open', label: 'Open' }, { id: 'done', label: 'Done' }],\n value: 'open',\n onChange: function (id) {\n rows.set({ items: id === 'open' ? open : done }); // the swap runs inside the kit's\n }, // own screen transition\n});\n```\n\nA FORM THAT LANDS — the confirmation as a toast, the refusal as a dialog, the field rule as a throw:\n\n```js\nAIMEAT.atelier.form({\n target: pane.body,\n fields: [{ name: 'title', label: 'What', required: true },\n { name: 'due', label: 'When', type: 'date' }],\n submitLabel: 'Add job',\n onSubmit: function (values) {\n if (values.title.length < 3) throw { field: 'title', message: 'Give it a few more words.' };\n return save(values).then(function () {\n AIMEAT.atelier.toast({ title: 'Job added', sub: values.title, tone: 'ok' });\n }, function (err) {\n AIMEAT.atelier.dialog({\n title: 'That did not save', text: String(err.message || err), tone: 'danger',\n actions: [{ id: 'ok', label: 'Close', tone: 'primary' }],\n });\n });\n },\n});\n```\n\nA NEARLY-RIGHT ROW — the third line and the right-hand figure the list leaves empty, filled from the row itself:\n\n```js\nAIMEAT.atelier.list({\n target: pane.body,\n items: rows,\n onPick: open,\n parts: {\n extra: function (r) { return r.note; }, // the third line, rendered empty until now\n aside: function (r) { return r.amount; }, // the value on the right\n },\n});\n```\n\nA SHEET THAT RECOMPUTES — the whole page as one record: the slider moves the wall, and the figure, the printed maths, the sentence and the state all follow it:\n\n```js\nvar sheet = {\n v: 1, register: 'genre-living', look: 'vivid',\n layout: { v: 1, nav: 'stack', blocks: [\n { id: 'controls', component: 'section', span: 'full', props: { title: 'The wall' } },\n { id: 'tin', component: 'figure', span: 'half', props: { title: 'Litres of paint' } },\n { id: 'maths', component: 'section', span: 'half', props: { title: 'How it is worked out' } },\n { id: 'note', component: 'section', span: 'full', props: { title: 'What that means' } },\n { id: 'stock', component: 'section', span: 'full', props: { title: 'Tins' } },\n ] },\n model: { nodes: {\n area: { type: 'value', value: 24, unit: 'm^2', min: 2, max: 120, step: 0.5, label: 'Wall area' },\n coats: { type: 'value', value: 2, label: 'Coats' },\n spread: { type: 'value', value: 10, unit: 'm^2/L', label: 'Spread rate' },\n wall: { type: 'control', kind: 'slider', target: 'area', block: 'controls' },\n paint: { type: 'formula', expr: 'area * coats / spread', unit: 'L',\n label: 'Paint needed', block: 'maths' },\n litres: { type: 'binding', block: 'tin', prop: 'value', from: 'paint' },\n advice: { type: 'text', block: 'note', template:\n '{{ area | 1 }} m2 in {{ coats }} coats takes {{ paint | 1 }} litres. '\n + '{{ if paint > 5 }}Buy two tins.{{ else }}One 5 litre tin covers it.{{ end }}' },\n tins: { type: 'machine', block: 'stock', initial: 'one',\n states: { one: { on: { SECOND: 'two' } }, two: { on: { ENOUGH: 'one' } } },\n when: [{ expr: 'paint > 5', send: 'SECOND' },\n { expr: 'paint <= 5', send: 'ENOUGH' }] },\n } },\n};\nAIMEAT.living.validate(sheet); // every refusal in words, before anything is drawn\nAIMEAT.living.mount(a.main, sheet); // the only line of code this page runs\n// m^2 divided by m^2/L is litres, so the unit on `paint` is checked rather than decorative;\n// move `area` to 40 and paint passes 5 L, the sentence changes and the machine goes to two.\n// A bound figure prints a WHOLE number (it counts up to it, and rounds), so the exact\n// reading is the formula's own printout and the sentence: 5 in the tile, 4.8 in the words.\n```\n\n## The mosaic: the arrangement lives outside your file\n\nRender the screen through `AIMEAT.atelier.mosaic(...)` instead of appending components by hand. You declare WHAT the app has — one resolver per data source name, an `onPick`, a `fallback` layout of blocks — and the ARRANGEMENT (order, look, navigation mode) is a stored record the owner's AI can change later with one `aimeat_app_manage` call (action `ui_set`), no republish. Source names are the binding contract: keep them stable across edits. Block ids are part of the same contract: the stored arrangement keeps the old ids after a publish, so a fill for a renamed block never runs. When a version renames or removes a block, replace the arrangement with `aimeat_app_manage` action `ui_set` in the same change, and read `layout: \"kept-existing\"` in the publish answer as that warning.\n\n```js\nvar m = AIMEAT.atelier.mosaic({\n app: a,\n sources: { 'errands.': loadErrandRows }, // name → rows (or a Promise of rows)\n live: { 'errands.': { keyPrefix: 'errands.' } }, // see below — optional\n onPick: function (blockId, item) { open(item); },\n fallback: { v: 1, blocks: [\n { id: 'top', component: 'hero', props: { title: 'Errands' } },\n { id: 'main', component: 'list', props: { source: 'errands.' } },\n ] },\n});\nm.refresh('errands.'); // after your data changed — the change paints with motion\n```\n\nLIVE BY DECLARATION: load `https://aimeat.io/v1/libs/aimeat-live.js` beside the kit and give the mosaic a `live` map — source name → { keyPrefix } naming the memory keys whose change means that source moved. When anything writes those keys (the owner's agent, another device, a schedule), the source re-resolves and the screen repaints with the components' own motion — you never poll, never open a socket, never write a listener. The wiring refuses a memory subscription without a keyPrefix (that would re-fetch on every write anyone makes) and never fires more often than every few seconds. Without the live library on the page the declaration is inert, so it is always safe to write.\n\nEVENTS FIRST, A TIMER LAST. Data that lives on the node reaches the screen because the node said it changed. Before you write `setInterval` around a read, name the event that says this data moved. The owner's records: the `live` map above with a `keyPrefix`. Work an agent does for the app (each stage line of a task, done, failed, a task a schedule created): `live: { jobs: { domains: ['agent-tasks'] } }`, which needs no prefix, and for one task `AIMEAT.agents.watch(agent, taskId, onUpdate)`. The domains an app may hear, each with the permission that opens it: `memory` (memory:read), `agent-tasks` (task:read), `files` (storage:read), `organisms` (organism:read), `workflows` and `scheduler` (workflow:read), `messages` (messages:read), `boards` and `realtime-rooms` (social:read), `wallet` (wallet:read), `knowledge` and `packages` (knowledge:read). `realtime-rooms` says the realtime room list moved: a room opened or closed, a player came or went. Outside a mosaic the same thing is `AIMEAT.live.subscribe(['agent-tasks'], reload, { minIntervalMs: 3000 })`. An event names the domain and never the record, so every change in that domain on the account wakes the page: read while your app has something under way, and re-read the one source that moved. A delete emits its domain as a write does; the aimeat-live description names the few that emit nothing. A timer is right in three cases, and each gets a comment saying which one it is: the data has no event (a public record a signed-out visitor reads, since the stream opens for a signed-in person; an answer from a service outside the node); the text depends on the clock itself (a countdown, \"starts in 5 min\"), which is a repaint and makes no request; one slow read, every ten minutes, that reconciles after a stream that was down. Check it the way a person meets it: start the work and watch the screen follow each stage within a few seconds.\n\nThe layout's `nav` field projects the same blocks as stacked sections, a tab row, a bottom bar, a swipeable deck, a step-by-step flow, a pan-zoom canvas, a desktop-grade left rail (`rail`) or a full-screen menu in display type (`overlay`) — all of them work on every screen size, so never build navigation by hand. On the stacked grid, blocks below the fold reveal as the person scrolls; that too is the kit's, never yours to code.\n\nTwo more one-field decisions, both data and both optional. `choreography: \"cinema\"` makes scroll the camera: the opening band recedes as the person leaves it and each section rises to meet them — right for a front, a story or a report, wrong for a tool someone lives in, and free at idle because it is pure CSS scroll timelines. And a chart block may carry `presentation: \"mural\"`: the chart stops living in a tile and becomes the section's full-bleed ground — the data as the decor, one mural per screen.\n\nTHE MACHINE ROOM IS AN ARRANGEMENT, NOT APP CODE. Four blocks make any admin or monitoring screen: `health` (one row per watched thing — lamp, name, latest reading), `queue` (work items with states, counted in a strip), `gauge` (ONE value on a dial, bands turning the tone) and `console` (the log vane — monospace, capped, follows the tail only while the reader is at the tail). Their tones ride the theme's ok/warn/err colours, so a status screen reads at a glance in every look and mode.\n\nCHARTS ARE A FAMILY on one block: `chart` with `kind: \"axes\"` (bars, lines and filled areas — a series may be kind \"area\"; `stacked: true` piles the bars into one column per label, `horizontal: true` turns ranked things sideways, and a `note` puts a one-line story bubble on the point that matters — every axes chart answers touch with a tooltip on its own), `\"donut\"` (parts of a whole — the total in the middle, and a `delta` puts its change there too), `\"calendar\"` (a stretch of days as a heat grid, months named) or `\"scatter\"` (points on two measures with an honest trend line), `\"funnel\"` (stages losing people — the survival rate written at each step), `\"treemap\"` (shares as area when the donut's slices would not fit), `\"flow\"` (where the quantity went — ribbons as wide as their sums) or `\"radar\"` (profiles on spokes — one polygon per series, for \"strong where, weak where\"). A statRow tile carrying `trend: [numbers]` draws its short history as a filled sparkline under the figure.\n\nWORK AGAINST PEOPLE AND TIME is its own family: `kanban` (work as columns by state — queue shows the same work as a list, this is the board, and with onMove wired the cards actually move), `plan` (stretches on a shared time axis with today drawn as a line — timeline tells what happened, this tells what is running) and `schedule` (a week as a grid, bookings as blocks — chart kind \"calendar\" is the year at a distance, this is next week). And two small truth-tellers: `steps` (where a process stands — done behind, current lit, the rest ahead) and `rating` (a score as stars, display only — collecting one is a form's job).\n\nWHEN THE OWNER SAYS \"A MAP\", THEY MEAN THE REAL ONE: the `map` block is Leaflet over OpenStreetMap street tiles — pins with popups at real addresses, the view framing the markers on its own, the licence's attribution built in, dark mode re-toning the tiles. The `atlas` block is the different, narrower thing: an offline choropleth of countries for data-by-country, no streets on it. Reaching for atlas when the owner asked for a map is a wrong answer with a confident face.\n\nAnd when a screen has earned a SHOWPIECE, the `scene3d` block gives it real depth: `kind: \"orb\"` (a signature object turning under the hand), `\"sky\"` (a procedural atmosphere band), `\"bars\"` (the bound rows stand up as a field of columns — the 3D chart), `\"model\"` (a .glb/.gltf by URL, fitted, grounded and studio-lit like a product shot) or `\"globe\"` (the earth — places as dots, data travelling between them as lifted arcs). One per layout, loaded lazily, colours from the look's tokens, and the render loop stops at rest so an idle scene costs nothing. It is a statement, not a default: most screens want a chart, not a scene.\n\nCOMPOSE, do not pile: a block may carry `span` — `full` (default), `main` + `side` for the asymmetric editorial split, or `half` — and the screen becomes a laid-out page instead of a column of cards. Narrow screens fold every span to one column on their own.\n\nA SETTINGS PAGE AND A QUEUE PAGE HAVE RULES, and a wide screen is where they break. The kit's form fills its container and the page is as wide as the screen, so on a desktop every field becomes a line across the room. Twelve rules, each from a design system or a usability study: (1) no input fills a wide page: a form field's `width` is short (a number), date, medium (a name or email) or long (a URL or a line of text, 32rem), full width only on a phone; (2) help text is at most 60ch per line; (3) one column, the label above its field, and only short related fields share a row; (4) every group of settings is a `settingsGroup` with a heading and ONE sentence of help, and no field stands outside a group; (5) from 840 px the group puts its help in a left column beside the controls, below that above them, and the groups of one page share ONE card divided by hairlines (target them into `
`), each control saving on change; (6) a tool with more than two screens uses `app({ nav: 'side' })`: the pages in a left column, the content capped at 65rem; (7) advanced settings go behind ONE closed disclosure (`reveal`); (8) the primary button aligns left with the inputs, says its verb and spans the width on a phone; (9) a setup screen opens with a `statusBand` (\"5 of 5 done\" and a bar) holding a `checkGrid`, and each missing step is one tile with one fix a tap away; (10) a batch of ten seconds or more is a `progressFigure`: \"3 / 10\", the item being worked on and its steps; (11) a number that changed flashes in place without moving (`attention(el, \"flash\")`); (12) every item an AI classified offers \"Why?\" (a `callout` with the answer, the reason and the data it saw) and \"Correct\", which says what it changes and from when. A work queue is `listDetail`, its queues listed in the side column with counts. THE WHOLE SHAPE IS READY: the look `workbench` and the genre `workbench` (setup, queue, processing and settings screens with sample data) are this design finished; fork the genre rather than drawing it again. AND WHEN THE OWNER APPROVED A DRAWN DESIGN OF THEIR OWN, the order is fixed: the drawing becomes a GENRE first (the drawing's screens as one page on sample data), the owner looks at it running and approves it, and only then is the app forked from that genre. An app built straight from a drawing out of kit parts drifts from it screen by screen, and the owner finds every difference himself (Postinjalostamo, 2026-09-28: three rounds).\n\nTHE FIRST MOVE IS A PRESET, not a blank page: `GET https://aimeat.io/v1/apps/ui/catalogue` carries `layouts` — finished, fillable shapes (cover, dashboard, browse, work-queue, story-deck, guided-flow). Pick the one nearest the app, replace every value with the app's own words and source names, and use it as the fallback — and as the first stored layout when the owner wants one.\n\n## Start from a GENRE — a complete committed register, and the register is required\n\nEvery Atelier app names the register it committed to, and the publish refuses one that does not: `\">` is in every genre's head already, so a fork carries it; a page that commits to a look of its own declares `\">`, where the name says what the register is (custom:game, custom:ledger) and is never \"default\". The bare shell carries a REPLACE-ME line in that place, and the gate refuses it as served: the shell is a frame, not a page.\n\nWhatever the app is — a poster, a console, a departure board, a ledger — do not assemble blocks: FORK A GENRE. Each genre is a finished free-composition page in a committed register; fetch it with `GET https://aimeat.io/v1/app-templates/`, swap the words, sources and images for the app at hand, and KEEP THE PHYSICS (finite entrances, motion only under the hand or the scroll, zero idle repaints — the look's ambient layer is the one declared exception — reduced-motion honesty). The kit's scenic props (`flapify`, `ransom`, `vu`, `typeout`, `dealIn`, the `.ak-stamp` / `.ak-ticker` / `.ak-torn` / `.ak-polaroid` family), the MATERIALS (one class per surface: `.ak-mat--glass`, `--aurora`, `--grain`, `--ink`, `--signal`, `--ring`, `--spot`) and the MOTION RECIPES (`.ak-move--magnet`, `--sheen`, `--deal` as classes; `spotlight`, `tilt`, `sheen`, `odometer`, `thumb`, `deal` as calls — every one answers the hand or a change and rests, none loops), the kit's own MOTION PRIMITIVES (`spring`, `stagger`, `inView`, `scrollLink`, `drag` — Web Animations API, no dependency, finite, a no-op under reduced motion; reach for these before a library) and the pattern shelf below carry the shared stagecraft. When an app needs a full animation library, the node serves three as packs — Motion (`motion`), anime.js (`anime`) and Lenis (`lenis`) — read the pack's doc before writing a line, because every one of them changed its API after the version you know.\n\nORNAMENTS: `AIMEAT.atelier.ornament(el, id, { speed, delay, leaves })` grows an engraved or living SVG figure round ONE element, in the look's colours, once, then holds still: `frame` (block), `vine-border` (block), `rope` (block), `jugend` (block), `guilloche-band` (block), `wreath` (badge), `guilloche` (badge), `vine-bar` (bar), `wrap` (bar), `divider` (rule), `vine-rail` (rule), `braid` (rule), `cord` (rule), `guilloche-strip` (rule), `fleuron` (rule), `dinkus` (rule), `flourish` (heading), `swash` (heading), `dropcap` (text), `ribbon` (heading), `bullets` (list), `ivy` (column), `brackets` (button). The word in brackets is the element it was drawn for. One or two per screen, on what matters: a frame round the card, a vine round the progress bar, flourishes beside the title. Never draw an ornament of your own. See each: https://aimeat.io/v1/designbook/ornament-/preview\nORNAMENT SETS, five figures in one style: `AIMEAT.atelier.ornamentSet(set, { frame: card, rule: emptyEl, bar: progressbar, bullets: ul, strip: emptyEl }, { value })`, any role left out: `modern`, `futuristic`, `cyberpunk`, `vibrant`, `emotional`, `dramatic`, `symmetrical`, `chaotic`, `velocity`, `art-deco`, `crystal`. One set per screen, in the app's mood. See each: https://aimeat.io/v1/designbook/ornament-set-/preview\n\n- `genre-pressdrop` — **The poster drop**: A full-page poster: image and giant type share the same space, duotone washes reveal true colour on hover, tilted stamps, a torn edge, a scroll-driven ticker, a sideways filmstrip with real scale contrast, one loud slab, the wordmark running off the page. For launches, drops, campaigns. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressdrop/preview\n- `genre-nightfloor` — **The night floor**: An ops room at 03:12: one number the size of the room (counts up once), glass panels floating deliberately unaligned that lean toward the pointer, a duotone camera feed with scanlines, a diagonal floor cut, a log rail whose newest line glows. For dashboards that watch one operation. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightfloor/preview\n- `genre-pressctl` — **The console**: The whole page is a terminal: a boot log that types itself once, a phosphor masthead glowing through scanlines, a mono queue table with status bars, gauges in ruled cells, a sticky F-key command bar. For queues, consoles and anything an operator lives in. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressctl/preview\n- `genre-pressindex` — **The index**: Type IS the interface: five giant outline rows are the whole navigation — hover floods the word solid and lights a full-page image behind everything. For fronts and site indexes with few doors. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-pressindex/preview\n- `genre-quarterly` — **The broadsheet**: A typeset newspaper front page: double-rule masthead, justified columns with a column rule, a red drop cap, a pull quote that breaks the column, a captioned figure, an IN BRIEF rail with numbers, a footer figures grid. For editorial fronts, reports and periodicals. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-quarterly/preview\n- `genre-thewall` — **The gallery corridor**: The page scrolls SIDEWAYS: you walk past framed works hung at their own heights under their own spotlight cones, each with a brass plaque; the wheel walks the corridor and a HUD shows how far. For portfolios and collections. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-thewall/preview\n- `genre-almanac` — **The almanac**: A Swiss data poster: a strict ruled grid, one red, numerals the size of weather, the season as moon dots, a week strip with one burning day. No texture, no tilt, no shadow — the discipline is the style. For stats pages and summaries. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-almanac/preview\n- `genre-blueprint` — **The blueprint**: A cyanotype: white line-work on process blue over grid paper — an SVG floor plan with dimension arrows, dashed callout notes pinned around it, one hot-yellow zone, and a proper title block with a rotated AS BUILT stamp. The light choice gives the whiteprint (blue lines on white paper, red for the hot zone); put running text on whiteprint blocks, because white text on the blue is hard for some eyes to read. For plans, maps and technical overviews. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-blueprint/preview\n- `genre-nightradio` — **The radio**: A valve set on walnut dark: a long tuning dial you drag (the needle springs to the frequency), programme rows that retune it and swap NOW PLAYING, VU bars drawn once per pick, an ON AIR lamp. For players, programmes and schedules. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightradio/preview\n- `genre-receipt` — **The receipt**: The whole page is one object: a giant thermal till roll on a dark counter — perforated tears, dashed rules, dotted leader fills, a VOID line, a rotated PAID stamp in multiply, a barcode — and it prints itself downward once. For confirmations, summaries and orders. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-receipt/preview\n- `genre-fanzine` — **The fanzine**: A photocopied punk collage: a ransom-note headline cut from six sheets, a staple, torn strips carrying shouted paragraphs, taped polaroids thrown on the desk (hover straightens one), xerox noise, a shouty two-line footer. For bulletins, community pages and anything with elbows. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-fanzine/preview\n- `genre-departures` — **The departure board**: A split-flap hall board: every character in its own flap cell, amber on black with green BOARDING and red DELAYED rows, and the whole board flips itself legible once, row by row. A LAST CALL strip below. For schedules, statuses and queues. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-departures/preview\n- `genre-patterndept` — **The specimen sheet**: A pattern specimen page: a zone-pattern banner with the title punched through, swatch cards on springs, a words-on-a-whisper proof card, a loud divider, rule cards. For style guides, catalogues and departments of anything. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-patterndept/preview\n- `genre-nightwatch` — **The night watch**: A small power station's wall at 02:40, all phosphor: the water route drawn as one glowing schematic with the kit's gauge bolted onto it, lamp-lit system cabinets, the watch log in tones, night orders signed on paper, the river's name burning off the page. For plants, fleets and anything one person keeps alive at night. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nightwatch/preview\n- `genre-crossing` — **The crossing**: A ferry line's night board: the kit's real map framed to the strait, the route inked across it with the ship mid-water, tonight's sailings ruled like the harbour office copy, a torn boarding stub with a stamped corner. For routes, logistics and anything that moves between two shores. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-crossing/preview\n- `genre-orchard` — **The season book**: A family orchard's year printed as a keepsake: the kit's calendar heat wall hung as a framed print (the story readable in its shape), the harvest weighed in a ruled grid, the split as a ring with a jam-lid badge, torn diary strips taped down crooked. For seasons, logs and any year worth keeping. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-orchard/preview\n- `genre-mtv` — **Music television**: 1980s music TV at night: a broadcast ident bar, a block logo with a sprayed tag, a CRT set whose credits box carries the provenance (maker · machine · human share), countdown rows with outlined numerals lit by their channel colour, neon channel chips, a cassette submission band and a yellow news strip at the floor. Proven live in an AI music chart. For charts, players, countdowns and anything that is ON AIR. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-mtv/preview\n- `genre-nighttrain` — **The night train**: A scroll STORY on the kit's director: one journey, Helsinki to Rovaniemi, told chapter by chapter under Lenis. The platform board and its lamps, a carriage of berths that light as a wave, the stations passing SIDEWAYS under vertical scroll, the aurora as three parallax layers behind a window, the route drawing itself with the distance filling a ring, and the doors opening at the end. The rail marks the chapter, the arrow keys move, the scroll snaps to a chapter start when the hand lets go. Fork it for anything told in order: a product launch, a year in review, a route, a recipe, an onboarding. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-nighttrain/preview\n- `genre-platformer` — **Ridge Run**: A GAME: a night patrol on a ridge as a platformer on aimeat-phaser. Three nights as levels the save unlocks, coins as lamps, spikes, a fox on patrol, the cairn as the goal; title and level-select scenes, pause, a settings panel, the synth for coin, hit and win. Around the canvas: a conditions board, the ledger of the three nights, the patrol log. For any platformer. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-platformer/preview\n- `genre-shooter` — **Harbour Watch**: A GAME: a top-down shooter on aimeat-phaser. A launch on dark water, stick or WASD to steer, the pointer to aim, drifting mines to clear and lanterns to collect, waves that grow, the best wave saved; title, game over from menuItems, pause, settings, gamepad on. For any twin-stick or arena shooter. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-shooter/preview\n- `genre-match` — **Market Stall**: A GAME: a match-three puzzle on aimeat-phaser, the light page. A 7 x 7 crate of produce, swap by pointer or keys, cascades, a hands counter and a target per crate, three crates, the best saved; title, pause, settings, the synth for a match. For any tile puzzle. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-match/preview\n- `genre-runner` — **Night Courier**: A GAME: an endless runner on aimeat-phaser. One button, a seeded roof pattern that always stays jumpable, vents to hop and gaps to clear, speed that rises, distance as the score, a parallax skyline from generated textures; title, game over, pause, settings, gamepad on. For any one-button runner. LIGHT: fixed, keeps its own colours in both modes. See it: https://aimeat.io/v1/designbook/genre-runner/preview\n- `genre-living` — **The record sheet**: A LIVING DOCUMENT: a nursery's growing record for one glasshouse block, and the whole sheet is one JSON record on aimeat-living. Two readings are entered by hand; the conversion, the dew point set as mathematics beside its answer, the wall number, the dial, the day's four bars, the sentence that changes at 30 °C and the standing order a statechart writes are all worked out from them, and the chain of who feeds whom is drawn in the margin and lights along the path a change travelled. Numbered fields, a filing head, a rubber stamp for the state, and every colour off the tokens, so it prints in either theme. Fork it for anything whose numbers stand on each other: a calculation sheet, a survey, a dosing record, a spec you can move. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-living/preview\n- `genre-workbench` — **The workbench**: A TOOL someone works in every day, on the kit's own workbench pieces and the workbench look: the app's mark and name in a solid bar, the pages in a left column with counts and tone dots, a status band with readiness tiles, three ways to let AI help, a queue as list and detail with a reason callout, a batch as \"3 / 10\" with its tallies, and settings with the help beside controls sized to their content. For intake, review and admin tools. LIGHT: follows the person's light/dark and palette. See it: https://aimeat.io/v1/designbook/genre-workbench/preview\n\nFIXED OR FOLLOWING is the owner's choice, and both are right. A FIXED genre is a finished object with its own colours: it looks the same at noon and at night, and the sign-in bar's light/dark control stands down on it. A FOLLOWING page is drawn in the theme's `--ak-*` tokens and changes with the person's light/dark and palette, which is what a tool people work in all day usually wants. Following today: `genre-blueprint`, `genre-living`, `genre-workbench`; every other genre is fixed. A fixed genre becomes a following one by replacing its hardcoded colours with `--ak-*` tokens and changing `` to `follows`: keep the composition, the type and the physics, and check it in BOTH modes beside the original, because a palette that was tuned for one ground rarely survives the other untouched. Every picture of a genre is one address away (`See it`), and the whole shelf is https://aimeat.io/v1/design-book; give the owner the links, do not describe a look in words when they can look.\n\nTHE TRAP THIS SECTION EXISTS TO STOP: a mosaic block stack wearing a look is a tool screen, never a statement — assembling components and applying a world reads as \"the same dashboard in new paint\" no matter which world. When a page must IMPRESS, start from the SUBJECT (whose page is this, what does it say), fork the genre that carries that register, and let the components serve the page — they mount in any element, so a free-composed page can still carry a live gauge or a map. If you cannot name what the page is about beyond \"it shows the blocks\", you are building a demo, and a demo never looks designed.\n\n## A fork people sign in to, in two languages\n\nA genre is a finished page with no sign-in, no language switch and its words in one language. Your fork adds all three, the same way every time. Do not write a header or a sign-in control of your own: the bar below is the node's, it carries the language switch and the light and dark control, and a hand-made one is the first thing a review sends back.\n\n**Two languages is the default: `en fi`.** Keep both unless the owner asked for one. Every word the page shows goes through a dictionary; a string typed into the markup is a string that cannot change language, and a page where the bar is Finnish and the content English is refused at review.\n\n```html\n\n\n\n\n\n
\n

\n\n\n\n\n```\n\nThe switch must keep what the person was doing: a conversation, a half-filled form and the settings survive it, because `paint()` changes words and nothing else. Numbers, dates and money follow the language too (`toLocaleString(i18n.lang())`). Languages of speech recognition or of an AI answer are separate settings; do not tie them to this switch unless the owner asks.\n\nAn app nobody signs in to still mounts the bar when it has two languages, because the switch lives there. Before you call it done, press the switch: English to Finnish and back, in the middle of using the app, and read every screen in both.\n\n**What the genre does not have, the kit has, and it wears the genre.** A form, a dialog, an empty state, a toast, a chart or a gauge comes from `AIMEAT.atelier`, never from your own markup. Every fixed-colour genre carries a block marked THE BRIDGE after its `:root`, which hands the kit the genre's ground, ink, one accent, corners and faces, so a kit component mounted into the page looks like part of it. When you change a colour of the genre, change it in the bridge with it. Mount a component ON the genre's own ground (the paper of a receipt, the panel of a board), where its ink is readable.\n\n## The node's libraries: read this list before you write a mechanism\n\nSpeech, audio, files, live updates, notifications, printing, calendars, decisions, payments and agents are already written, served by this node and kept in step with it. Before you write a mechanism of your own, find it here. An app that runs its own speech loop, its own socket or its own `fetch` to `/v1/memory` works on the day it ships and stops following the platform afterwards, and the publish says so (`app_hints`, pitfall `hand-rolled`).\n\nLoad with `\n\n\n
\n\n```\n\nTHE FILL COMES FROM THE BOOK: pick one from the list at the end of this part, read it with `aimeat_designbook_get { id }`, replace every value with this app's words and source names, take its `look` line out (in a genre the genre is the look, and the bridge makes every block wear it), and put it in the `#aimeat-layout` block. THE PUBLISH DOES THE REST, so there is nothing to call afterwards: it counts each part the meta names as used (once per app), and on the app's FIRST publish it stores the `#aimeat-layout` block as the app's arrangement, so from then on the owner's AI rearranges the screen with `aimeat_app_manage` action `ui_set` and no republish; a later publish never writes over what they arranged. The answer's `next_steps.design_book_parts` says what was counted, what it does not hold, and whether the layout was stored. Compose blocks of your own only where no fill is near.\n\nWhat stays hand-made in a genre fork is what the genre itself is made of: a figure only this page has, the masthead, a game board. Everything a mosaic block can show is a block.\n\nCOMPONENTS: WHAT ANOTHER APP MADE BY HAND. The list at the end of this part has a COMPONENTS group: pieces of page an earlier builder made because the Book had nothing, from apps whose owner was satisfied. Take one with `aimeat_designbook_adopt { id, filename }`, before your app exists: it answers `snippet` { html, css, use, prefix }, which you build into the page as they are. A component carries NO script, so you wire its behaviour as `use` says, and it reads the page's tokens, so inside a genre it wears the genre. Look there before you make a grid, a strip, a dial or a board of your own.\n\nWHEN YOU DO MAKE SOMETHING BY HAND, MAKE IT SO IT CAN BE OFFERED LATER, which costs nothing now: give it ONE class prefix of its own (`wkgrid`, `wkgrid-cell`), take every colour from a `var(--ak-…)` token and never a literal, and keep its behaviour in your script, reading `data-` attributes on the markup. That is exactly the shape the Book takes a component in, so when the owner says the app turned out well it goes onto the shelf as it is.\n\nWRITE DOWN WHY, AS YOU CHOOSE. A count says an AI reached for a part; it does not say the part is any good, and nobody can improve the Book from a number. So the page carries your reasons, one sentence each, in a third block beside the two above:\n\n```html\n\n```\n\n`took` is a part that is in this page and what made it fit (a part named here needs no `aimeat-book-parts` meta). `passed` is a part you looked at and left, and what made it NOT fit: it is the only place a part's weakness is ever written down, so it is the most useful of the three. `made` is what you built by hand because the Book had nothing, and why it had nothing. Write the true reason, including \"the name matched and I did not look further\": a reason that sounds good and is not why you chose teaches the Book the wrong thing. The publish keeps these with the version they belong to. NOTHING GOES INTO THE BOOK BECAUSE A BUILD IS FINISHED. An app is often rebuilt twice before its owner likes it, and a version that was thrown away must not teach the Book anything. Tell the owner, in one line when you hand the app over, that when they are happy with it they can say so; that is recorded with `aimeat_designbook_keep { filename }`, by whichever AI they say it to, and it is the moment what this app took and made starts to count.\n\n## AI inside the app\n\nThe `aide` block puts an AI panel on the screen whose tools are the app's OWN declarations: hand the mosaic spec your `sources` and an `actions` list ({ id, summary, params?, run }) and the aide can read what the screen reads and PROPOSE what the buttons do — a person confirms every run, the platform AI notice and provenance labels are built in, and it runs on the owner's own key (it sleeps politely when no key is set). A model answer may be a small mosaic panel rendered inline over the same sources — arrangement from the closed vocabulary, never markup. Two more affordances every mosaic carries: `m.explain()` renders \"what this screen holds\" from the declarations (never hand-write a help text that will drift), and `m.setOverlay({ hidden, order, nav })` applies THIS VIEWER'S own arrangement over the owner's page — store it in the viewer's own memory (`atelier.overlay.`), never in the owner's layout.\n\n## Data, in short\n\nLogin and data come from `aimeat-auth` and `aimeat-data` exactly as on the rest of the platform: the shell hands you the session in `onReady`; private data is `AIMEAT.data.set/get` with a `.`-prefixed key; one key holds one record a user opens as a unit, never one key per field; read back after writing. Declare the scopes the app uses in ``.\n\n**How the data map answers steer the build** (the three questions of the interview). SHARED BY THE TEAM: ONE organism workspace that every member reads and writes, through `AIMEAT.organism` (read, writeDraft, publish); `AIMEAT.atelier.workspacePicker({ target, app, onReady })` picks or creates it on the first run. Never per-user memory for team data. PERSONAL: `AIMEAT.data.set/get`, private to each person. PUBLIC: a record with `visibility: public`. WHO OPENS IT: the app's `open_to` setting, set when you publish (`anyone`, `signed-in`, or `organism:` for one organisation's members) with `aimeat_app_manage` action `settings` or PATCH /v1/apps/:filename; the data map's `form` says the same (`group` or `organism-workspace` for a team app). THE TRAP: a team app built on per-user memory gives every person an empty copy of their own, and nobody sees what a colleague added.\n\n## Finishing\n\nBefore you call it done: open the app at 390×844, 1280×900 and 1280×460 in BOTH themes; `document.body.scrollWidth === document.documentElement.clientWidth` at every width; every state (loading, empty, error, signed-out) reached through `a.status(...)`; no console errors. Publish with `aimeat_app_publish` and pass `spec_token: atelier-b982bcc761d3` — the digest of this document — so the node can tell the app was built against the spec in force.\n\n## What the review always catches\n\n- A form that switches into edit mode says so: retitle it and its primary action (\"Edit entry\" / \"Save changes\"), and the row being edited stays visibly selected. A form still headed \"Log an entry\" while it edits reads as adding a duplicate.\n- Counters and the lists beside them read from the SAME data, computed in one place. A screen whose numbers disagree with its rows reads as broken even when both are defensible.\n- Say a number ONCE. The same three counts as a stat row, as tab labels, as chips and again in a heading is the most common defect the review finds — pick the one place the number earns, and delete the echoes.\n- The content people came for comes BEFORE the form that adds to it. In a journal, reading is the daily act; a full-height form above the entries buries the product under its input.\n- Master-detail is ALWAYS listDetail, never a hand-rolled pick panel: the component carries the selection mark, the row-to-detail morph and the narrow-screen fold, and a hand-rolled panel loses all three.\n- The shell's bar is the ONLY top bar. Building a second header of your own puts two bars and the account pill in a fight for the same edge.\n- A filter applies WHEN IT CHANGES. A separate Show/Apply button beside a dropdown is a second step nobody expects of a filter.\n- Give the shell a `tagline` (one line on what the app IS): the sign-in screen presents the app with it, so a first visitor learns what they are looking at before they log in.\n- Storage internals never reach the person: \"under keys that start with standup.\" is a sentence for a developer, not for a screen.\n\n## Never\n\n- daisyUI/Tailwind classes outside a `section` body — the kit is the vocabulary.\n- Hand-written ARIA, focus management or animation code — the components carry them.\n- A theme, palette or language control — the login pill owns all three.\n- An invented script/style URL — everything the app loads is named in the shell.\n- The Classic build spec — two tracks, two guides, no mixing.\n","spec_token":"atelier-b982bcc761d3"},"hints":{"next_actions":[{"description":"The genres: complete pages in a committed register. A build starts here; each carries its aimeat-register meta","method":"GET","url":"/v1/designbook?kind=genre"},{"description":"The Atelier shell: the frame the genres are built on. Read it for the structure; published bare it is refused","method":"GET","url":"/v1/app-templates/shell-atelier"},{"description":"The game shell: the same frame with a Phaser canvas, menus, settings and a leaderboard wired","method":"GET","url":"/v1/app-templates/shell-phaser-game"},{"description":"Publish the finished app (pass spec_token)","method":"POST","url":"/v1/apps"}],"help_url":"/v1/docs"}}