@fugood/bricks-ctor 2.25.0-beta.5 → 2.25.0-beta.50

package/skills/bricks-design/references/when-the-brief-is-vague.md

@@ -0,0 +1,85 @@
+# When the Brief is Vague — Direction Advisor
+
+If the brief is too open to execute ("design me a signage app", "make something for the lobby", "I don't know what kind of kiosk I want"), do not improvise on generic intuition. That's how every signage screen ends up looking like every other signage screen.
+
+Switch into **Direction Advisor** mode. The output of this mode is *a chooser*, not a design — a small set of differentiated directions the user can pick or blend. Once they pick, drop out of Advisor mode and continue the normal workflow.
+
+## What "differentiated" means
+
+Pick directions that disagree on a real axis. Three minimalist variants is not three directions; it is one direction at three opacities.
+
+The strongest axis is **interaction archetype** — what the user *does* in front of the screen. Six archetypes:
+
+| Archetype | The user... | Dominant Brick(s) | Generator load | Canvas count |
+|---|---|---|---|---|
+| Glance | reads in 1–2 seconds while passing | Slideshow, RichText, Video | Light — content fetch only | 1 |
+| Browse | scans options without commitment | Items, Slideshow, Maps | Light to medium | 1–3 |
+| Interact | drives a flow, taps to choose | Items, BrickRect tiles, TextInput | Light | 2–5 |
+| Transact | completes a task with stakes (payment, identity) | TextInput, BrickRect, Camera, payment | Heavy — peripheral generators | 4–8 |
+| Monitor | watches changing state | Chart, Items bound to live Data | Heavy — MQTT/HTTP/MCP | 1–2 |
+| Dwell | inhabits the space; the screen is ambient | Video, Slideshow, Lottie | Light — looped media | 1 |
+
+Full rule sets per archetype (what carries forward, failure modes, which UX disciplines weight strongest) live in the companion skill — see `bricks-ux/references/interaction-archetypes.md`. Use the table above to pick at Advisor time; consult the companion file when the picked archetype needs to drive structural decisions.
+
+For most vague briefs you can spread three options across this set — e.g., "lobby screen" reasonably maps to {Glance, Dwell, Interact}, "retail aisle screen" to {Glance, Browse, Transact}, "transit platform" to {Glance, Monitor, Browse}.
+
+You can also differentiate on:
+- **Visual system** — Editorial / Cinematic / Brutalist / Soft minimalist / Maximalist. Useful when the deployment is fixed and the conversation is about expression.
+- **Brick set** — what the design is *built from* (image-led / type-led / map-led / video-led / chart-led).
+- **Motion language** — calm vs. cinematic vs. snappy.
+
+But interaction archetype is the most useful starting axis because it changes the entire shape of the Subspace, not just its skin.
+
+## What to deliver in Advisor mode
+
+A direction is the combination of three choices — two axes the user perceives, and one structural decision that flows from them:
+
+- **Interaction archetype** (above) — *what the user does*. Drives Subspace structure.
+- **Visual language** — *what the design says*. Drives expression: type, color, motion, signature moves, asset emphasis. Pick from the curated library in [`design-languages.md`](design-languages.md) (Swiss Editorial / Kenya Hara emptiness / Field.io motion poetics / Brutalist web / Y2K futurist-retro / etc.) or invent one rooted in the same discipline.
+- **Canvas-graph shape** — when the brief reads as a presentation / pitch deck / introduction / explainer / slideshow / storyboard / demo / training-loop / kiosk-welcome, the choice between **Shape A** (Slideshow Generator — uniform layout, content-driven), **Shape B** (multi-Canvas state machine — bespoke layouts, hero continuity), and **Shape C** (hybrid) is a real direction differentiator. See [`presentation-and-slideshow.md`](presentation-and-slideshow.md). When the brief is not sequenced (single Canvas signage, dashboard, dwell loop), this collapses to "single Canvas" and isn't a real axis.
+
+For each of 3 directions, write:
+
+- **One-sentence pitch** combining the axes ("Glanceable signage in the Kenya Hara emptiness register — a single hero photograph holding the canvas, captions smaller than instinct demands.").
+- **A real-world flagship** for the visual language (the user is unlikely to recognize an interaction archetype on its own, but they will recognize "MUJI lobby loops" or "Bloomberg Terminal").
+- **3 vibe keywords**.
+- **Interaction archetype + visual language pairing**, named explicitly so the user can refer back.
+- **Canvas-graph shape** (only for sequenced work — Shape A / B / C).
+- **Dominant Brick / Generator** the work will be built from.
+- **Canvas-count shape** — single canvas / 2–3 / state machine.
+- **Trade-off** — what this direction gives up.
+
+Keep each direction to ~5 lines. The chooser is the artefact, not finished work.
+
+**Spread across the axes.** Three directions all in the same archetype but different languages is a thin spread. Three different archetypes paired with the same language is also thin. For sequenced work, also spread across Canvas-graph shapes when it changes the user's experience meaningfully (Slideshow Generator vs multi-Canvas state machine is a different *kind* of presentation, not just a different look). Aim for at least two different archetypes and at least two different language schools across the three options.
+
+## The 3-cell preview
+
+Build a lightweight preview that lets the user compare side by side:
+
+- **Best**: 3 minimal Subspaces (one Canvas each, placeholder content, real Brick layout) loadable in `bricks-ctor` `preview`. The user can render each.
+- **Good**: 3 sketches in a single Canvas — three frames within one Subspace, each labelled. Use this when speed matters more than fidelity.
+- **Acceptable**: 3 hand-drawn or screenshot-style images placed as Image Bricks with captions.
+
+Don't build full Subspaces. Direction Advisor is a 5–10 minute cycle. If you're 30 minutes in, ship what you have and let the user redirect.
+
+## When the user picks
+
+Once they pick (or pick a blend):
+
+1. **Drop out of Advisor mode.** Stop offering alternatives. Commit.
+2. **Re-confirm deployment context.** The pick changes some assumptions (e.g., picking Transact when the deployment is no-touch is wrong; surface that and renegotiate).
+3. **Continue the normal workflow.** Declare a system, build a runnable skeleton, iterate, ship variations within the chosen direction (variants on visual / motion / content rhythm — not on archetype anymore).
+
+## Anti-patterns
+
+- **Three options that all want the same archetype.** Three "elegant minimalist" variants is not a chooser. The user can't decide because the options haven't disagreed yet.
+- **Naming the visual style without naming the interaction.** "Editorial / Brutalist / Soft" tells the user nothing about what they'll do in front of the screen. Lead with archetype.
+- **Building all three to high fidelity.** You're spending design budget you should spend after the user picks.
+- **Skipping Advisor when the brief is "kind of vague" but you have a strong opinion.** State your opinion in plain language ("I'd default to a glanceable signage loop because of the lobby context — want me to start there, or see two other options?") and let them redirect. Skipping the chooser without checking is how design budgets get burned on the wrong direction.
+
+## When to skip Advisor mode
+
+- The user supplied concrete references (a Figma render, an HTML mockup, a competitor URL). The translation rules in [`translating-inputs.md`](translating-inputs.md) take over; Advisor is unnecessary.
+- The brief is concrete enough to act on — specific screen, specific interaction, specific brand. Don't manufacture ambiguity.
+- The user is impatient and named a clear preference. State your default and proceed; offer to revisit if they want options later.

package/skills/bricks-design/references/workflow.md

@@ -0,0 +1,134 @@
+# Workflow — questions and staged delivery
+
+Two disciplines bundled because they're both about how the work moves through time: deciding when to ask vs. when to build, and pacing the build itself so misalignment is caught early instead of after twelve Canvases.
+
+## Ask vs. build
+
+Ask when the design space has too many free variables. Build when constraints are already pinned.
+
+**Ask** if any of these are unclear:
+
+- Hardware / scene / network / language / brand (Priority #0 — never improvise on these).
+- Fidelity expectation — rough Canvas with tokens only, fully lit single scene, or full system across all Canvases.
+- Variation scope — one direction or multiple to choose from.
+- Variation axes — visual language, palette, density, motion, Canvas-graph shape.
+- Content provenance — does the user have copy/assets, or should you write placeholder in a declared voice?
+
+**Build** if:
+
+- Deployment context is concrete, brief names a recognisable shape, brand is supplied or absent-by-design.
+- Reference material was supplied (Figma / HTML / screenshot / website) — translation rules in [`translating-inputs.md`](translating-inputs.md) take over; ask only the residual.
+- The user named a strong preference. State your default, build, offer to revisit.
+
+**Batch the asks.** Single round of questions, not staged. Volleys cost user momentum. Aim for 5–10 well-targeted questions per round; fewer than 3 means you're missing problem-specific depth; more than 12 means you're stalling.
+
+## Question playbook by axis
+
+When you do ask, cover these axes — in one batch, omitting any already pinned:
+
+**Deployment context** (Priority #0 — covered in SKILL.md, repeat checklist if any is missing).
+
+**Output shape**
+
+- Single Canvas / multi-Canvas state machine / Slideshow Generator / hybrid?
+- How many Canvases roughly? (Calibrates effort, not a contract.)
+
+**Fidelity**
+
+- Rough skeleton with tokens declared / one fully-lit hero Canvas / full system across every Canvas?
+- Is the deliverable for review, for handoff to another designer, or for direct deployment?
+
+**Variations**
+
+- One direction, or three to pick from?
+- Axes that should vary — visual language, palette, density, motion, Canvas-graph shape, interaction archetype?
+- Conservative spread or one bold option included?
+
+**Tone and content**
+
+- Audience for the deployed Application (passersby / customers / employees / operators / VIPs)?
+- Tone register (formal / warm / playful / technical / quiet / loud)?
+- Copy supplied or placeholder-in-voice?
+
+**Problem-specific** (3–5 questions tailored to output shape — examples below):
+
+- *Slideshow / pitch deck*: how many slides, target duration per slide, narration or silent, branching or linear, who advances (auto-timer / operator remote / interaction).
+- *Kiosk / interactive*: peripherals attached, identity capture, payment terminal, queue/wait behaviour, idle reset interval.
+- *Dashboard / monitor*: data sources, refresh cadence, alert thresholds, what action a viewer might take from each state.
+- *Signage / glanceable*: dwell-time at the screen, day/night cycle, ambient sound, fleet vs. single-instance, content feed.
+
+## Staged delivery — five passes
+
+Don't sprint to a finished Subspace. Stage the work so wrong direction is caught at the cheapest point.
+
+### Pass 0 — Deployment context + style declaration
+
+Confirm Priority #0 verbatim. Write the style declaration block at the top of the Subspace file before placing any Brick:
+
+```ts
+/**
+ * System: <picked design language, e.g., Swiss Editorial>
+ * Archetype: <interaction archetype, e.g., glance>
+ * Type: <font family> · <size scale in grid units, e.g., 2 / 4 / 8 / 16 gu>
+ * Color: <ground> on <ink> · accent <#hex> (used only for …)
+ * Spacing: <scale in grid units, e.g., 2 / 4 / 8 / 16 gu>
+ * Grid stance: lean / break / breathe
+ * Motion: <Standby easing + ms> entrance · <ms> exit · loops only on <element>
+ * Heroes: <Brick id(s) that persist across Canvases via auto-tween>
+ * Asset emphasis: <real photography / type-only / hero video / …>
+ */
+```
+
+The grid substrate is given (Truth #6). What you commit to is type scale, palette, **spacing scale in grid units**, motion vocabulary, grid stance, and hero Bricks. The spacing scale is a small enumeration (3–5 values); inter-Brick gaps come from this set, not arbitrary integers. This block keeps the agent's arithmetic consistent across many Bricks and is what the design-critique pass cites.
+
+### Pass 1 — Showcase Canvas (the lockdown moment)
+
+Build **one** Canvas, fully lit, that represents the work at its highest fidelity. Choose the hardest Canvas — the boot screen, the most content-dense state, or the moment that carries the brand most. Run through Verification (compile + screenshot + view back). Show the user.
+
+This is the cheapest point to discover the direction is wrong. If the user wants the type bigger, the photography swapped, the rhythm slower, the language different — fix the Canvas and the style declaration, not twelve Canvases.
+
+**Do not** build the full Canvas graph before this checkpoint. The temptation is real because state-machine work feels productive; resist it. Sign-off on one Canvas first.
+
+### Pass 2 — Full Canvas graph
+
+After Pass 1 sign-off, build the remaining Canvases and the Switch / Data wiring that connects them. Hero Bricks use the same id across Canvases (Truth #3). Every visible Brick has a Standby Transition (Truth #7).
+
+Mid-review checkpoint partway through: show the user 3–4 representative Canvases (not all of them) and the navigation flow. Caught here is still cheap. Wait until everything is finished and you've spent the budget.
+
+### Pass 3 — Polish, edge cases, content rhythm
+
+Pass over every Canvas for:
+
+- Spacing-scale adherence (every gap from the declared set).
+- Density rhythm across consecutive Canvases (not three identical layouts in a row).
+- Standby Transitions consistent vocabulary, not 6 different easings.
+- Asset fidelity at the 5-10-2-8 bar (per `when-the-brief-is-branded.md`).
+- Multilingual content fits without breaking layout, if relevant.
+
+### Pass 4 — Verification + self-critique
+
+The non-negotiable Definition of done from SKILL.md plus the 5-dimension self-critique in [`design-critique.md`](design-critique.md). Compile, screenshot every Canvas, view back, critique pass, fix anything < 8 or surface as an accepted trade-off.
+
+Only after Pass 4 do you declare done.
+
+## When to compress passes
+
+Smaller deliverables don't need all five.
+
+- **Single-Canvas glanceable signage**: Pass 0 + a one-pass build + Pass 4. Pass 1 *is* the deliverable.
+- **Iterative changes on existing Subspace**: skip to the affected passes; don't re-declare the system.
+- **Direction Advisor mode**: 3 lightweight Pass 1 candidates, no Pass 2/3 until the user picks.
+
+Don't compress passes on:
+
+- Multi-Canvas state machines (3+ Canvases).
+- Anything with branding (Pass 1 lockdown catches asset-bar problems before they propagate).
+- Anything with peripherals, payment, or identity (Path 2 verification mandatory in Pass 4).
+
+## Anti-patterns
+
+- **Sprinting to a finished Subspace and showing it.** The user can't easily redirect a finished thing. Pass 1 is for redirection.
+- **Asking one question at a time.** Burns volleys, drains user energy.
+- **Asking nothing and inferring.** The five Priority #0 items are not inferrable; trying to is the most expensive mistake.
+- **Declaring done after Pass 2.** Pass 4 critique is what separates "runs" from "good."
+- **Re-declaring the style block on every iteration.** If you find yourself updating five values at once mid-Pass-3, you're rebuilding the system — back up to Pass 1.

package/skills/bricks-ux/SKILL.md

@@ -0,0 +1,114 @@
+---
+name: bricks-ux
+description: >-
+  Interaction design and end-user experience for any Application or Subspace
+  built on Canvases, Bricks, Generators, Data, DataCalculation. TRIGGER on
+  usability / flow / interaction / journey / state / affordance / feedback /
+  recovery / accessibility audits and design work — "audit this flow", "improve
+  usability", "design the wait state", "make the kiosk usable", "design the
+  payment flow", "design idle and attractor states", "design for multilingual /
+  low vision". Also triggers in parallel with visual-design work for end-to-end
+  deliverables (kiosk, signage, dashboard, interactive screen, pitch deck) where
+  interaction shape matters as much as look. SKIP for purely visual / aesthetic
+  / style / brand-asset / typography / palette work — that is bricks-design.
+  Encodes a universal user-journey spine, interaction archetypes, pressable
+  composition, monitoring-screen discipline, designed flow states,
+  accessibility, tiered UX critique; hardware floors are deployment-relative and
+  web habits do not transfer.
+---
+
+# BRICKS UX
+
+You are a BRICKS interaction designer. Your output is a **designed user journey** expressed through Canvas graphs, Brick affordances, Standby Transitions, Switch thresholds, and Data states. The deliverable is a Subspace whose interaction shape, not just its visual surface, is intentional.
+
+Web interaction habits do not transfer. There is no hover, no scroll, no `<form>` submit, no modal-as-default, no semantic link, no document flow. Hardware varies wildly — a phone-shaped PWA, a 32" landscape kiosk, a 75" portrait signage panel, a curved retail display. **Floors and discipline are deployment-relative**; pinning pixel measurements is the wrong altitude. Express discipline in grid units, viewing distances, fractions of viewport, deployment-shape categories.
+
+## Priority #0 — Verify the end user
+
+Before designing any flow, confirm:
+
+- **Who** uses the screen — passersby, customers, employees, operators, VIPs, mixed.
+- **What they're doing** in front of it — passing through, queuing, ordering, paying, monitoring, dwelling, troubleshooting.
+- **What state they arrive in** — fresh / mid-task / returning / interrupted / under time pressure / under emotional pressure (payment, identity).
+- **What stress they're under** — daylight glare, queue behind them, low literacy, accessibility need, multilingual mix, watchdog reset just happened.
+- **How they leave** — completion, abandonment, idle timeout, peripheral disconnect, someone else taking over.
+
+If any of the first four is missing, stop and ask in a single batch. UX without a named end user is decoration.
+
+## Priority #0.5 — Walk the journey end-to-end before designing
+
+Before placing Bricks for a flow, narrate the journey step-by-step out loud in your reply. Every step gets:
+
+- **Who's acting** — the user, the runtime, a peripheral, an operator.
+- **What they see** — Canvas + dominant Bricks at that moment.
+- **What they feel** — confident / hesitant / waiting / stuck / relieved.
+- **What can go wrong** — including the silent failures (peripheral delay, network blip, watchdog reset, language fallback).
+
+A flow you cannot narrate is a flow you cannot design. This step catches the missing-state cases (no in-flight visibility, no error recovery, no closure) before they ship.
+
+## The universal user-journey spine
+
+Every interaction — touch, peripheral, remote, external trigger — follows the same seven steps. Skipping any of them is the most common failure mode. Full file: [`references/user-journey.md`](references/user-journey.md).
+
+1. **Affordance** — "Can I do something here?"
+2. **Instruction** — "What do I do?"
+3. **Immediate feedback** — "Did I do it?"
+4. **In-flight visibility** — "Is it being handled?"
+5. **Continuation** — "What's next?"
+6. **Recovery** — "What if it went wrong?"
+7. **Closure** — "When can I leave?"
+
+This scaffold replaces device-specific recipes. QR scan, face detection, BLE proximity, NFC tap, payment, voice mic, touch — all the same seven steps, expressed through different Brick families and Generator events.
+
+## Interaction archetypes
+
+The user does one of six things in front of a BRICKS screen. The archetype determines Subspace structure (Canvas count, Brick dominance, motion vocabulary, what carries forward across Canvases).
+
+Glance · Browse · Interact · Transact · Monitor · Dwell.
+
+Each has its own rule set, what reads as fail, and which UX disciplines weight strongest. See [`references/interaction-archetypes.md`](references/interaction-archetypes.md).
+
+## Flow states are first-class
+
+Idle, loading, empty, error, attractor, boot, maintenance — these are not afterthoughts. They are states the deployment will spend real time in. A flow whose error state is a stack of red text in a corner is a flow that fails in the field. See [`references/flow-states.md`](references/flow-states.md).
+
+## Pressable composition
+
+Every composite (multi-element) button needs a deliberate decision about where `on_press` sits and how overlapping press chains resolve. Pressable-capable Bricks with no press events auto-bypass at the runtime, so the trivial wrapper case works without ceremony; explicit `pressable: 'bypass'` matters when inner Bricks carry their own chains. Affordance is a UX signal — the user must be able to *see* what's pressable before discovering it by accident. See [`references/pressable-composition.md`](references/pressable-composition.md).
+
+## Monitoring screens have their own discipline
+
+Calm state must be readable and forgettable. Change must be detectable without being demanding. Demand must compel response without crying wolf. Stale data is worse than no data. See [`references/monitoring-screens.md`](references/monitoring-screens.md).
+
+## Accessibility is non-optional, deployment-relative
+
+Universal access is not a checkbox; it's a deployment-floor commitment. Contrast, scale, motor, reduced-motion, color-not-only, predictable navigation, audio cues — each applies at a deployment-specific floor (viewing distance, ambient light, user posture, hardware capability). See [`references/accessibility.md`](references/accessibility.md).
+
+## Verification — UX critique
+
+Verification proves the flow *runs*. UX critique proves the flow is *usable*. Tiered by deployment risk (CRITICAL on transact / identity / safety-critical; HIGH on interact / monitor with alarms; MEDIUM on browse / dwell; LOW on glance / loop) with Must Have / Anti-Pattern pairs per section. See [`references/ux-critique.md`](references/ux-critique.md).
+
+UX critique runs alongside visual-design critique (in `bricks-design`), not after. The two are concurrent; a Canvas can fail one and pass the other, and both block ship.
+
+## Boundaries
+
+- Do not design flows for users not yet identified — Priority #0 must be answered first.
+- Do not invent peripheral behaviour — if a peripheral's behaviour at threshold is unknown, the journey has an unsafe step; surface it before designing past it.
+- Do not declare a flow done after testing only the golden path. Edge states (timeout, error, abandon, watchdog reset, peripheral disconnect) are part of the design.
+- Do not import web interaction patterns — hover affordances, scroll-to-reveal, modal overlays, page-submit forms — to no-touch or peripheral-bound hardware without translation.
+
+## Companion skill
+
+For visual design — type, palette, asset acquisition, design language, system commitment, visual rhythm — use `bricks-design` (companion skill). Most end-to-end briefs ("design a kiosk for X", "build a presentation about Y") invoke both in parallel.
+
+## Reference index
+
+| When you need to... | Read |
+|---|---|
+| Walk the universal interaction journey | [`references/user-journey.md`](references/user-journey.md) |
+| Pick the right interaction archetype + apply its rule set | [`references/interaction-archetypes.md`](references/interaction-archetypes.md) |
+| Compose a button so taps land where intended | [`references/pressable-composition.md`](references/pressable-composition.md) |
+| Design monitoring / dashboard / status-board UX | [`references/monitoring-screens.md`](references/monitoring-screens.md) |
+| Design idle / loading / empty / error / attractor / boot / maintenance states | [`references/flow-states.md`](references/flow-states.md) |
+| Ensure universal access at deployment-relative floors | [`references/accessibility.md`](references/accessibility.md) |
+| UX critique before declaring done | [`references/ux-critique.md`](references/ux-critique.md) |

package/skills/bricks-ux/references/accessibility.md

@@ -0,0 +1,162 @@
+# Accessibility
+
+Universal access is not a checkbox; it is a deployment-floor commitment. The floors themselves are **deployment-relative** — a 75" signage panel viewed at 5m has a different contrast floor than a 13" PWA at arm's length. Pinning pixel measurements is the wrong altitude; pin the principle to viewing distance, ambient light, user posture, hardware capability, and the audience that will actually be in front of the screen.
+
+This is design discipline, not compliance citation. Standards like WCAG are useful references for ratios and thresholds; the deployment is the audit.
+
+## The seven disciplines
+
+Each below is non-optional unless the brief explicitly removes the constraint (rare). Each is expressed in deployment-relative terms.
+
+### 1. Contrast at viewing distance
+
+The screen must remain readable under the deployment's actual luminance conditions — direct sunlight on outdoor signage, dim lobby, fluorescent retail, surgical-theatre lighting, day-night cycles in 24-hour venues.
+
+**Discipline:**
+
+- Body text contrast: at viewing distance, the text must be readable to a viewer with imperfect vision. Use the deployment's worst-case ambient (peak sun for outdoor; lowest lobby level for indoor) as the calibration point.
+- Critical-action elements (alarm indicators, transact-flow CTAs, way-finding directional cues): higher contrast than body, reads through glare and reflection.
+- The 4.5:1 ratio (a common reference) is a *floor*, not a goal — comfortable reading on a kiosk at 1m is more like 7:1 for body, 10:1 for critical.
+- Adjacent fills (a coloured Rect over a coloured ground) must also meet contrast — don't measure ink-on-ground only.
+- Audit by squint test: at 25% zoom on the design preview, primary content should still be readable. If it isn't, the contrast is wrong.
+
+**Failure modes:**
+
+- Mid-tone-grey body text on a slightly-lighter-grey ground — reads on the designer's monitor, vanishes under the deployment's actual conditions.
+- Brand-palette pastels on white grounds — pretty in a mockup, illegible on a sunlit signage panel.
+- Dark-mode invert without re-balancing contrast — see `bricks-design/design-critique.md` anti-slop list.
+
+### 2. Scale at viewing distance
+
+Text and pressable elements must be large enough for the deployment's actual viewing distance and user capability.
+
+**Discipline:**
+
+- Body text scale: pick a grid-unit height that, at deployment resolution and viewing distance, reads comfortably for the audience. A wayfinding screen for an aged audience at 3m needs body text larger than a control-room dashboard at 0.6m.
+- Touch targets: on touch-enabled hardware, every pressable Brick must be large enough that an adult finger lands reliably. Children-using-it deployments scale up; gloves-on factory deployments scale up further. The 44pt-equivalent web reference is a desk-laptop floor, not a kiosk floor.
+- Inter-element spacing: pressable Bricks need breathing room — accidental adjacent presses are common with single-finger interaction on dense layouts.
+
+**Failure modes:**
+
+- Web-default 14–16px body text on a 65" signage panel at 3m — readable only if the viewer walks up.
+- Touch targets sized for mouse cursors — 32px tiles on a kiosk; thumb miss rate is high; users press the wrong tile and abandon.
+- Inter-element spacing < 1 grid unit on a no-haptic-feedback touch panel — adjacent presses happen routinely.
+
+### 3. Color is necessary but never sufficient
+
+Critical information (status, error, severity, success) must be encoded by *more than colour*. Colour blindness is common; viewing conditions degrade colour rendering; monochrome failover paths exist.
+
+**Discipline:**
+
+- Status indicators encode by **colour + shape + label**. A red diamond labelled "CRITICAL" survives where a red dot doesn't.
+- Severity tiers use distinct shape vocabularies, not just hue ramps. Critical = filled, Warning = outlined, Normal = absent. Or critical = diamond, warning = triangle.
+- Form validation: errors marked by colour AND icon AND positional cue (the field with the error gets a distinct outline, an icon, and an inline message — not just a red border).
+- Print / screenshot / monochrome screenshot of the design should still convey the same information hierarchy.
+
+**Failure modes:**
+
+- Charts encoded by hue alone — multi-series charts unreadable when desaturated or for colour-blind viewers.
+- Red "alarm" badge in a corner with no shape or label distinction — invisible to red-green colour-blind operators.
+- Form-validation error styled only by red text — unreadable without a colour distinction the user can perceive.
+
+### 4. Motor allowances
+
+Some users have reduced fine motor control. Some are using gloves. Some are children. Some have pressed the wrong tile three times and are frustrated. Design for the realistic worst case the deployment will see.
+
+**Discipline:**
+
+- Touch targets sized for the audience and conditions (see §2).
+- No precise gestures (multi-touch, swipe-to-confirm, drag-to-amount) when the audience may include reduced-motor users. If gesture is needed, a tap alternative exists.
+- Accidental-press protection on consequential actions: confirm-step for transact, undo window for destructive actions, "press twice to confirm" for irreversible operator commands.
+- No time-pressure that fails the slow user. A 3-second confirmation timer that auto-cancels frustrates older users and accommodates none.
+
+**Failure modes:**
+
+- Swipe-to-pay as the only commit gesture — unusable for some, harder than a tap for most.
+- "Press twice within 1 second" — fails users who hesitate.
+- Tiny "X" close buttons on dialogs — children, gloved users, and users with tremor cannot hit them reliably.
+
+### 5. Reduced motion
+
+Some users find continuous motion distressing or disorienting. Some hardware deployments (in clinical settings, in environments with motion-sickness-prone audiences) need to minimise screen motion.
+
+**Discipline:**
+
+- Animation that's part of the design language can be reduced via a Data flag (`reduceMotion: true`). `Animation.runType` is a literal `'once' | 'loop'` and does not accept a `DataLink`, so the flag has to drive a `Switch` (`SwitchCondData`) whose `animation` override swaps the looping slot for a non-looping Animation or omits it entirely; Standby easing is shortened the same way. The flag is a deployment-time setting, not a per-user runtime toggle (since BRICKS deployments typically don't have OS-level reduce-motion).
+- Critical state changes (alarm transitions, success acknowledgement) remain animated even with reduced motion — these are functional, not decorative.
+- Where motion is the design language (Field.io poetics), reduced-motion mode reframes the deployment — possibly delivers a different Subspace. Don't half-fly the motion design.
+
+**Failure modes:**
+
+- Continuous looped animation on every Brick — fatiguing in the best case, distressing in the worst.
+- No reduced-motion path for a deployment in a clinical / safety-critical setting.
+- Reduced-motion that also breaks critical state visibility (the alarm pulse silenced along with the decorative motion).
+
+### 6. Predictable navigation
+
+Operators and users build mental models of where things live on the screen. Layout shifts that move primary elements between Canvases (or between states on one Canvas) destroy that mental model.
+
+**Discipline:**
+
+- Hero Bricks (logo, primary CTA, page indicator, time) keep position across Canvases via Truth #3 shared ids. The eye-anchor doesn't move.
+- Navigation affordances (back, next, home) sit in consistent positions across Canvases.
+- Error states do not relocate the user — the error appears in or near the affected element, not on a completely different Canvas that erases context.
+- Idle-reset returns to the *same* idle Canvas every time, not to a variant; reliability over novelty.
+
+**Failure modes:**
+
+- Brand chrome that moves between Canvases — the eye lands in different places every time.
+- "Back" button that moves around or disappears mid-flow.
+- Idle rotation that breaks the eye-anchor — the same brand element appears at top-left, then top-right, then centre across rotation cycles.
+
+### 7. Audio cues (when hardware allows)
+
+Visual is the dominant channel, but sound complements where it can. Sound becomes especially important when the user is *looking at the peripheral, not the screen* (a payment terminal, a card reader, a printer) and needs confirmation from the screen.
+
+**Discipline:**
+
+- Tap / press feedback: a brief audio cue (50–100ms) at the moment of registration helps users with reduced peripheral vision and confirms action when the visual feedback might be missed.
+- Alarm / demand state: an audio signal with the visual change. Distinguishable from ambient music or environment.
+- Success closure on transact: a short success cue when the transaction completes, especially when the user's attention is on the peripheral / receipt.
+- Volume and timing aware — late-night deployments quiet, daytime louder. Schedule via Data, not hardcoded.
+- Audio is never the *only* cue — pair with visual. A user wearing earphones, in a noisy environment, or hard-of-hearing must still see the change.
+
+**Failure modes:**
+
+- Audio cue at constant volume regardless of time of day — disruptive at 11pm, inaudible during a busy lunch rush.
+- Audio-only confirmation — the user without good hearing is left guessing.
+- Default OS / browser system sounds — unbranded, often jarring, dated.
+
+## Multilingual is an accessibility concern (for some deployments)
+
+Where the audience speaks multiple languages, accessibility includes language access. See [`multilingual-and-rtl.md`](multilingual-and-rtl.md) when that file exists; until then:
+
+- Strings used in the UI go through Data so a locale can be swapped (Truth #2 + critique bonus on hardcoded English).
+- Type scales must accommodate the longest expected translation — German strings are often 30%+ longer than English; CJK is often shorter but with different optical density.
+- RTL layouts (Arabic, Hebrew) flip at the Subspace / Canvas level — not a per-Brick CSS prop. Plan the Canvas to support flipping if RTL is in-scope.
+
+## Cognitive load discipline
+
+Universal-access also covers cognitive accessibility — users who are tired, distracted, unfamiliar with the system, under stress.
+
+**Discipline:**
+
+- One primary action per Canvas. The user knows what they're being asked to do.
+- Plain language over jargon. "Pay now" beats "Authorize transaction."
+- Reading comprehension at the audience's likely level — a venue-of-the-public deployment writes at a lower grade level than a control-room console.
+- Predictable patterns — same kind of action gets the same kind of affordance across the deployment.
+
+**Failure modes:**
+
+- Three competing CTAs on one Canvas — the user freezes choosing.
+- Jargon error messages (HTTP codes, internal error names) — the user doesn't know what to do.
+- Inconsistent affordance vocabulary — tiles look pressable on Canvas 1, identical tiles are decorative on Canvas 2.
+
+## How to use this file
+
+1. **Confirm the audience and conditions** as part of Priority #0. Reduced-motor users? Multilingual? Outdoor sun? Night-shift fatigue? Each shifts which disciplines weight strongest.
+2. **Apply the seven disciplines as a baseline.** Each has a deployment-relative floor; calibrate to the conditions, not to a default.
+3. **Verify at the deployment.** Path 2 (on-device DevTools, see `bricks-ctor/rules/verification-toolchain.md`) is the only way to confirm contrast under real lighting, touch-target size under real fingers, audio cue volume in real ambient.
+4. **Surface gaps in trade-off notes.** A deployment that opts out of one of the seven (e.g., audio cues skipped because the hardware is muted; reduced motion skipped because the design language IS motion) must say so explicitly in the handoff.
+
+A design that passes visual critique but fails accessibility floors is not done. Accessibility critique runs in parallel.