@fugood/bricks-ctor 2.25.0-beta.12 → 2.25.0-beta.13

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-design/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.

package/skills/bricks-ux/references/flow-states.md

@@ -0,0 +1,175 @@
+# Flow States
+
+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. A kiosk whose idle state is "whatever the last user was looking at" is a kiosk that confuses every next user.
+
+This file treats each as a **first-class designed state**. Universal principles, BRICKS-native expression notes, and the failure mode that consistently slips into agent-produced work.
+
+The common thread across all of them: every state has a *who arrives*, a *what they see*, a *what they need to know*, and a *how they leave*. If you cannot answer all four, the state is unfinished.
+
+## Idle
+
+**The state when the screen is on, the user is not present, and no peripheral / sensor event is active.**
+
+Most kiosks and interactive deployments spend the majority of their hours idle. Yet idle is the most-skipped designed state in agent work — it gets treated as "whatever Canvas is loaded when nobody's using it," which is wrong.
+
+**Design discipline:**
+
+- **Idle is a designed Canvas (or set of Canvases), not a side-effect.** The flow returns to it after every session via an idle-timeout reset.
+- **Idle invites.** A passerby should look at the idle screen and understand what's offered here. This is the affordance layer for the eventual interact flow — see [`user-journey.md`](user-journey.md) step 1.
+- **Idle resets cleanly.** No state from the previous user persists into idle — no half-built order, no name still on screen, no "please confirm". The reset wipes flow Data; `persistData: true` is reserved for *deployment* state (last-known-good, config), not session state.
+- **Idle rotates if needed.** For deployments where idle runs hours, a slow Slideshow / Canvas rotation prevents burn-in and gives the screen rhythm. Don't loop a single static Canvas indefinitely.
+- **Idle is calm.** No spinners, no progress indicators, no "loading" residue. The screen is at rest.
+
+**Failure modes:**
+
+- Idle = "last interact Canvas frozen." Next user arrives mid-flow, doesn't know whose order is on screen, may complete or cancel someone else's.
+- Idle with a spinner or "please wait" — implies the system is busy when it isn't.
+- Idle without an attractor element — passersby see "this is on" but not "this is for them".
+- Idle timeout reset that doesn't actually reset all Data — partial state leaks into next session.
+- Idle too noisy — looping animation that demands attention from people not interacting; reads as broken.
+
+## Attractor
+
+**The active state of "no current user, but invite the next one."**
+
+Some deployments differentiate idle (passive) from attractor (actively inviting). A kiosk in a quiet store may use the same Canvas for both; a kiosk in a busy mall might cycle a deliberate attractor sequence to pull users in.
+
+**Design discipline:**
+
+- **A clear value proposition.** "Order here", "Check in", "See today's events", "Find your room". One line, large, immediately readable from approach distance.
+- **A demonstration of action.** A subtle animation showing the kind of interaction the user will do — a finger graphic tapping a tile, a card moving toward a reader, a face-detection frame breathing.
+- **Brand presence, not brand wallpaper.** The brand is in the attractor; the attractor isn't *only* brand. A wordmark-only attractor doesn't tell the passerby what's possible.
+- **Calibrated motion.** Enough to catch the eye from peripheral vision (10–15° off-axis), not enough to read as broken or anxious.
+- **Time-of-day / context aware** if the deployment runs long hours — morning rush attractor differs from afternoon quiet differs from late-night.
+
+**Failure modes:**
+
+- Attractor that's only logo + tagline — looks like signage, not like an invitation to act.
+- Attractor that demos a different action than what's available — promises one experience, delivers another.
+- Attractor with hover-style affordances on no-touch hardware — implies pointing-device interaction that doesn't exist.
+- Attractor competing with the deployment's surroundings — the screen drowns in a busy retail wall, or shouts over a quiet hotel lobby.
+
+## Boot
+
+**The state when the device just started — pre-content, pre-user.**
+
+Per `bricks-design/performance.md`, the boot Canvas must render in < 1s using only cached/persisted Data. That's the runtime floor. The design floor is *what the user sees during that second and what arrives after*.
+
+**Design discipline:**
+
+- **Boot is brand, not work.** The first second is brand presence — wordmark, logo lockup, a confident moment. Not a spinner. Not "loading…".
+- **Boot transitions into idle gracefully.** Standby Transitions carry the boot chrome into the idle Canvas; Truth #3 shared Brick ids preserve continuity. The user doesn't see a blank moment between boot and idle.
+- **Boot is fault-tolerant.** If a Generator fails, if a Data source is unreachable, if a peripheral hasn't initialised — boot completes anyway, with the failure surfaced in the affected component (a sensor that hasn't reported reads as "—", not as a frozen screen).
+- **Boot is what a watchdog reset returns to.** A reset is a fresh boot; design boot so the operator and any in-progress user can recover gracefully. Persistent state restores last-known-good, not last-current-screen.
+
+**Failure modes:**
+
+- Boot as a loading spinner over a blank background — every reset reads as "this is broken."
+- Boot Canvas different from idle Canvas — the user sees the brand appear, then a layout shift to idle; instability tell.
+- Boot that requires network / Generator success — offline boot fails; deployment goes dark.
+- Boot that doesn't acknowledge watchdog reset — operator or user in-flight is suddenly back at boot with no explanation.
+
+## Loading
+
+**The state when the user has acted (or the system has triggered) and a response is pending.**
+
+This is step 4 of the user journey (in-flight visibility, see [`user-journey.md`](user-journey.md)). Loading is a *state visibility* discipline, not a decorative flourish.
+
+**Design discipline:**
+
+- **Loading is not blankness.** A pending response gets a visible state — spinner, progress indicator, animated tile, "processing" badge — that confirms the system is working.
+- **Loading is bounded by time-out.** Every loading state has a failure path. If the response doesn't arrive in N seconds (deployment-relative, typically 10–30 seconds for network operations, 2–5 for peripheral), the state transitions to error recovery (step 6 of the journey).
+- **Loading disables the trigger.** While loading, the affordance that triggered it is `pressable: 'disabled'` or Switch-hidden — user can't re-trigger.
+- **Loading scales with expected wait.** A < 1s wait is a snap-cut visual change; a 1–5s wait is a spinner; a 5s+ wait surfaces progress estimate or "still working".
+- **Skeleton screens** (showing the *shape* of incoming content with a placeholder) work for content that arrives gradually. Less appropriate for transact-flow loading (a fake-result skeleton would mislead).
+
+**Failure modes:**
+
+- Loading visually identical to idle — user doesn't know if they pressed something or not.
+- Loading without a time-out — system hangs; loading state persists forever; user walks away.
+- Loading that allows re-trigger — user impatient, presses again, queues duplicate work.
+- Loading dressed as success — skeleton that looks complete; user assumes the action finished and acts on the placeholder.
+- Loading on a transact flow that reads ambiguous between "still processing" and "approved" — user walks away from a partial transaction.
+
+## Empty
+
+**The state when there's nothing to show — no items in the list, no events today, no notifications, no search results.**
+
+Empty is the most-forgotten state in agent work. Loading gets designed because it follows from acting; empty gets skipped because it follows from *not* acting and the agent thinks "there's nothing to design".
+
+**Design discipline:**
+
+- **Empty explains the absence.** Not "nothing here". Specifically: "No bookings today. New bookings appear here." or "No events scheduled. Check back tomorrow." or "No matches. Try a different spelling."
+- **Empty offers a path forward.** Even on monitoring deployments, empty should suggest what will populate it ("Sensor will report every 30 seconds") or how the user can change the state ("Add an item to begin").
+- **Empty is not error.** A bookings list with no bookings today is a perfectly normal state — design it as content, not as failure.
+- **Empty preserves the layout.** The list area / grid area is still occupied — by an empty-state composition, not by collapsed-away whitespace that resizes the rest of the screen.
+- **Empty is rare on dense deployments and frequent on others.** A retail menu board never has an empty menu (it would close instead). A queue display is empty when there's no queue — which is most of the time.
+
+**Failure modes:**
+
+- Empty rendered as collapsed space — the screen's layout shifts because there's nothing there; users perceive the screen as broken.
+- Empty rendered as "—" everywhere — placeholders never replaced by content; design forgot to handle the populated case (or vice versa).
+- Empty as error — "No results" styled as red and alarming; the user thinks they made a mistake.
+- Empty without explanation — the user can't tell if there's truly nothing or if data hasn't loaded.
+
+## Error
+
+**The state when something went wrong — peripheral disconnected, validation failed, network unavailable, Generator timed out, content feed broken.**
+
+Error is step 6 of the user journey. It is a first-class designed state, not a corner-text afterthought.
+
+**Design discipline:**
+
+- **Error declares the failure.** Specifically. "Card declined." "Couldn't reach the menu. Try again in a moment." "Scanner can't see the code." Not "An error occurred." Not "ERR_TX_REJECTED."
+- **Error explains in user-language.** Technical codes belong in logs, not on the user's screen. If the underlying cause is genuinely useful to surface (network-down state for an interactive kiosk in a corporate setting), translate.
+- **Error offers a path forward.** Retry, alternate method, get help, abandon. Never a dead-end. Even "the system is unavailable, please come back later" is a path (the user knows to leave).
+- **Error preserves user input.** Form input retained; user shouldn't re-type after a single validation fail. Selection state preserved; user shouldn't re-select after a "couldn't connect, try again".
+- **Error distinguishes categories.** *User error* (action didn't succeed, retry sensibly). *System error* (the system has a problem, not the user's fault). *Abandonment* (timeout, idle reset). Each has its own treatment.
+- **Error is calm in tone where possible.** A "card declined" screen designed in shouting red feels accusatory; the user did nothing wrong (the bank declined). Match the tone to what's actually happened.
+
+**Failure modes:**
+
+- Error as a stack of red text — accusatory and unhelpful.
+- Error as a generic toast — disappears before the user reads it.
+- Error with no recovery path — user stuck on an error Canvas with no way forward except staff intervention.
+- Error that erases user progress — single-field validation fail dumps the user back to step 1 of a 7-step flow.
+- Error category collapsed — every kind of failure ("declined" / "network down" / "wrong card type") shown identically; user can't pick the right recovery.
+- Error styled as alarm-grade visual when the failure is mundane — fatigues the user and the operator.
+
+## Maintenance
+
+**The state when the deployment is intentionally taken out of service — software update, content refresh, scheduled downtime, manual operator pause.**
+
+**Design discipline:**
+
+- **Maintenance is a Canvas, not a black screen.** The screen tells the user / operator that the deployment is intentionally offline and when it'll return.
+- **Maintenance distinguishes itself from error.** "We're updating menus — back in 5 minutes" reads differently from "Something went wrong." Different visual tone, different language.
+- **Maintenance has a return path.** Specific return time if known; vague "shortly" if not, with a contact route if relevant.
+- **Maintenance is operator-aware.** A factory-floor monitor in maintenance shows the operator badge / contact / instructions to bring it back online. A passerby-facing deployment shows a friendly message; the operator interface for resuming is gated by some access (Settings, password, key combo).
+
+**Failure modes:**
+
+- Maintenance = black screen — user thinks the device is broken.
+- Maintenance = the most-recent error state — implies failure, not intentional pause.
+- Maintenance without a return signal — operator forgets the deployment is paused; users walk away assuming the venue is closed.
+- Maintenance accessible to passerby — anyone can put the kiosk into maintenance and walk away.
+
+## When to design each state
+
+Different deployments live in different states most of the time.
+
+- **Signage / glance**: idle (= the running state), boot, occasional maintenance. Loading / empty / error rare; design lightly. Attractor sometimes a separate state for higher-energy deployments.
+- **Self-service kiosk / interact / transact**: idle, attractor (often = idle), boot, loading (per step), error (per failure category), occasional empty, maintenance. **All states must be designed**; this is the highest-flow-state-count category.
+- **Dashboard / monitor**: calm (= the running state, see [`monitoring-screens.md`](monitoring-screens.md)), stale-data variant, demand / alarm states, occasional empty (no data yet), error if feed is dead, maintenance.
+- **Dwell / ambient**: looping content (= idle), boot. Error / empty rare; treat lightly.
+
+Design the states that will actually be visited. Skipping a state because it's "rare" is correct *only if* you can confirm it actually is rare in this deployment.
+
+## How to use this file
+
+1. **List which states this deployment will visit.** Not all states apply to every deployment.
+2. **For each, design the four answers** — who arrives, what they see, what they need to know, how they leave.
+3. **Verify the state's existence in preview.** Force-trigger each state via Automation or by editing Data values; capture a screenshot; view it back. A state you haven't seen is a state you haven't designed.
+4. **Surface every gap in the trade-off note.** If a state is in-scope but unverified for some reason (peripheral simulation not available, error mode hard to trigger), say so explicitly. The user reading the handoff should know which states have been actually tested in design.
+
+A flow declared done where only the golden path has been screenshot-verified is a flow with undesigned states. The next user will find them.

package/skills/bricks-ux/references/interaction-archetypes.md

@@ -0,0 +1,189 @@
+# Interaction Archetypes
+
+The user in front of a BRICKS screen is doing one of six things. The archetype determines Subspace shape — Canvas count, dominant Brick families, motion vocabulary, what carries forward across the flow — and which UX disciplines weight strongest.
+
+Pick the archetype first, then commit. Archetypes don't blend gracefully; a "glanceable + interact" hybrid is a sign that you need two Subspaces or one designed-as-archetype-X Subspace with a clearly bounded archetype-Y moment.
+
+## Glance
+
+**What the user does:** reads the screen in 1–2 seconds while passing. No interaction. No commitment. Often peripheral vision.
+
+**Where it lives:** lobby signage, transit platform info, queue-number displays, menu boards, ambient information screens, attractor loops between active sessions.
+
+**Rule set:**
+
+- Type at the *legibility floor for viewing distance* — calibrate to the deployment, not to instinct. A 75" panel viewed from 4m needs body text at ≥ 4 grid units (with appropriate hardware); a 32" panel at 1m can read smaller.
+- One primary idea per Canvas. Two competing headlines = neither lands.
+- Refresh cadence calm — content rotates on a slow rhythm (8–15 seconds per item). Anything faster crosses into demand-attention territory.
+- Hero continuity (Truth #3) — even glanceable signage benefits from a persistent element (logo, time, brand chrome) so the viewer's eye knows where they are returning to.
+- No affordance for interaction the hardware can't deliver. No hover, no implied "tap for more" on a no-touch panel.
+
+**Carries forward:** nothing. Each glance is self-sufficient.
+
+**Failure modes:**
+
+- Two-line headline at the edge of legibility — viewer can't read in 1.5 seconds, looks away.
+- Slideshow rotates faster than read time — viewer catches "Item 4 of 12" but never the title.
+- Content-dense layout imported from web — five sections fighting for the eye.
+- Affordance signals (chevrons, button-styled tiles, "click here" copy) where the hardware can't deliver.
+
+**Critical UX dimensions:** visual hierarchy, legibility floor, dwell-pacing.
+**Negligible UX dimensions:** in-flight visibility, error recovery, closure (the user doesn't act).
+
+## Browse
+
+**What the user does:** scans options without commitment. Reads multiple things looking for what's relevant. Looks at, doesn't necessarily decide.
+
+**Where it lives:** menu boards with multiple categories, schedule boards, room-availability displays, retail-shelf overhead screens, museum exhibit info.
+
+**Rule set:**
+
+- Layout supports comparison. Adjacent items should be visually parallel (same Brick shape, same scale) so the eye can shift between them.
+- One axis of variation per dimension — sort by category OR by time OR by price, not all three simultaneously without UI separation.
+- If the deployment is touch-capable, browse can promote to interact: tiles with deliberate pressable affordance (see [`pressable-composition.md`](pressable-composition.md)). On no-touch, browse stays pure read.
+- Carry forward minimal — if the user wanders away and comes back, the screen should be in the same readable state (no half-completed selection clogging the view).
+- Dwell time is real — viewer may stand there 5–20 seconds. Plan for it. Content should *reward* dwell with subtle motion (Standby on Brick lists, gentle highlights) without crossing into demand attention.
+
+**Carries forward:** sometimes selection state if browse promotes to interact; otherwise nothing.
+
+**Failure modes:**
+
+- Items styled too differently — eye can't compare, fragments instead of scans.
+- Excessive depth — a browse screen that requires drilling reads as interact, not browse.
+- Auto-rotation while user is browsing — content shifts mid-read, viewer loses place.
+- Empty browse state (no items today, gallery closed) treated as forgotten case — see [`flow-states.md`](flow-states.md).
+
+**Critical UX dimensions:** visual hierarchy, comparison legibility, empty/sparse state design.
+**Negligible UX dimensions:** transact discipline, alarm hierarchy.
+
+## Interact
+
+**What the user does:** drives a flow. Taps to choose, navigates between Canvases, completes a non-financial task — order something, request information, configure a setting, sign in to a non-payment portal.
+
+**Where it lives:** self-service ordering, ticket selection, info-kiosk requests, queue ticket dispensers, event check-in, configuration interfaces, language pickers.
+
+**Rule set:**
+
+- Every action gets the full 7-step journey (see [`user-journey.md`](user-journey.md)). Skipping any step is a UX failure.
+- Hero Bricks carry continuity across the flow Canvases (Truth #3). The brand chrome / progress indicator / step number should never disappear mid-flow.
+- Pressable affordance is unambiguous (see [`pressable-composition.md`](pressable-composition.md)). Tiles that look like tiles, taps that visibly land.
+- Idle reset — interact deployments are often left mid-flow. The Subspace must have an idle timeout that returns to attractor / boot state without preserving the abandoned session for the next user (unless explicitly designed for resumption).
+- Position memory — the user should be able to back out one step without losing the whole flow. Switch on a `flowStep` Data with persistent intermediate states.
+- Reduce decision pressure — short on-Canvas option lists (≤ 5 primary choices on one Canvas); promote to multi-Canvas if more.
+
+**Carries forward:** flow state (selection, configuration, pending submission) across Canvases until completion or reset.
+
+**Failure modes:**
+
+- 12-option grid that needs scrolling on Canvas 1 — overload, no scroll on BRICKS (Truth #10).
+- Continuation Canvas changes the location of the back action — user can't return.
+- Mid-flow content overload — every Canvas tries to summarise everything before, instead of advancing.
+- Idle timeout missing — next user inherits previous user's half-built order.
+- Recovery for no-input dead-ends absent — user walks away without completing; no abandonment cleanup.
+
+**Critical UX dimensions:** journey completeness (all 7 steps), affordance clarity, idle reset, position memory.
+**Negligible UX dimensions:** alarm hierarchy, monitoring discipline.
+
+## Transact
+
+**What the user does:** completes an action with stakes — payment, identity capture, signed agreement, regulated action. The cost of error is real (financial, legal, safety).
+
+**Where it lives:** payment terminals, self-checkout, identity verification, age check, regulated-document signing, controlled-access entry.
+
+**Rule set:**
+
+- The 7-step journey *tightens* (see `user-journey.md` § "When the seven steps intensify"). Confirmation before commit. In-flight visibility cannot be skipped. Recovery has explicit categories. Closure declares completion.
+- The *point-of-no-return moment* must be visually distinct from everything before and after. The user knows when they've committed.
+- Peripherals dominate — payment terminal, NFC reader, camera for ID. Each peripheral's state must be visible to the user. Generator events drive Switch transitions; never guess at peripheral state.
+- Audio cues if hardware allows — financial transactions benefit from non-visual confirmation (the user is often looking at the terminal, not the screen, mid-tap).
+- Path 2 verification (on-device DevTools) is mandatory for these deployments; the design must be tested on the real hardware with the real peripherals before declaring done.
+- No idle timeout *during* an active transact step — the system waits for the user, not the other way around. Idle timeout only between sessions.
+- Receipt / artifact handoff is part of the design — the closure Canvas waits for the printer event or the email-sent confirmation before declaring done.
+
+**Carries forward:** transaction state through to closure; nothing after.
+
+**Failure modes:**
+
+- Confirmation step skipped — user commits without realising.
+- In-flight state ≤ 200ms — the user double-taps because they don't see acknowledgement; second tap queues a duplicate.
+- Generic error recovery — "Try again" doesn't distinguish card-declined (try a different card) from network-down (wait and try) from user-cancelled (start over).
+- Closure transient — success Canvas auto-advances to idle in 1.5 seconds; user mid-blink, never saw confirmation; calls customer service.
+- Peripheral assumed instead of observed — design assumes card-tap is instant; in production the reader takes 2–3 seconds; users walk away thinking it failed.
+
+**Critical UX dimensions:** journey intensification, point-of-no-return clarity, in-flight visibility, recovery categories, closure weight, peripheral state visibility.
+**Negligible UX dimensions:** ambient pacing, dwell rhythm.
+
+## Monitor
+
+**What the user does:** watches changing state. Often peripheral attention — the screen is a stand-by surface that becomes the centre of attention when something changes. Not always actively read; trusted by reference.
+
+**Where it lives:** control rooms, factory floor monitors, network operations dashboards, security camera grids, transport-control screens, sensor-driven status boards, hospital nurse stations, AI-assistant monitoring panels.
+
+**Rule set:**
+
+- Calm-state default. The screen at rest should be readable and forgettable — operator can scan, look away, return.
+- Change must be detectable without being demanding — a subtle motion / colour shift / hierarchy promotion that draws the eye but doesn't startle. Demand attention is reserved for true alarms.
+- Stale-data trust principle — if the operator can't tell what's current, they will trust what they see. Stale state must be visibly declared.
+- Alarm hierarchy under stress — multiple simultaneous alarms must already have priority order designed. The screen sorts; the operator doesn't.
+- Show vs ask — a monitor screen often only *shows* state, leaving action to operator judgement; sometimes it *suggests* action (highlighted protocol button). Decide which it is; not both.
+- Full coverage in [`monitoring-screens.md`](monitoring-screens.md).
+
+**Carries forward:** operator's mental model of "what was last normal" — design with this in mind, since change-from-baseline is the operator's real read.
+
+**Failure modes:**
+
+- Every data field updates identically — operator can't distinguish meaningful change from background fluctuation.
+- Alarms styled the same regardless of severity — minor warning indistinguishable from critical alert.
+- Stale-data badge in 8pt corner type — operator never sees it.
+- Color-only encoding (red for alarm, green for normal) — fails for colour-blind operators and in low-contrast environments.
+- Loading state designed, empty state forgotten — fresh deployment shows "—" everywhere with no explanation.
+
+**Critical UX dimensions:** calm/detect/demand hierarchy, stale-data trust, alarm priority, accessibility (operators may be on shift, fatigued, in suboptimal viewing conditions).
+**Negligible UX dimensions:** dwell pacing, single-action affordance discipline.
+
+## Dwell
+
+**What the user does:** inhabits the space. The screen is ambient — wallpaper for a hospitality lobby, a hotel-room TV channel, a restaurant ambient display, a museum atmospheric backdrop, a brand-experience wall.
+
+**Where it lives:** hotel and hospitality lobbies, restaurant ambiences, retail mood walls, brand-experience installations, event backdrops, spas, premium reception areas.
+
+**Rule set:**
+
+- Content rotates slowly — 15–60 seconds per item depending on register. Field.io-style motion poetics can run continuous loops; Kenya Hara photographs hold longer.
+- No interaction. No affordance. The screen does not invite touching.
+- Visual quality at maximum — assets must score high on the 5-10-2-8 craft bar (see `bricks-design/when-the-brief-is-branded.md`); poor assets in a dwell context degrade the surrounding brand more than they would in a glanceable signage context.
+- Motion has continuity — Truth #3 hero auto-tween across Canvases keeps the dwell experience reading as one piece rather than a slide rotation.
+- Day-night awareness if relevant — dwell deployments often run 24-hour; design adapts to ambient luminance, time-of-day, scheduled content.
+- Sound (if hardware allows) is part of the design — ambient music selection, volume scheduling, silence as deliberate.
+
+**Carries forward:** nothing per-user; only the slow rhythm of the loop itself.
+
+**Failure modes:**
+
+- Looped motion at the wrong speed — too slow reads as broken, too fast reads as nervous. Calibrate.
+- Content variation insufficient — the same three Canvases looping every 30 seconds for 14 hours reads as broken signage.
+- Day-night neglected — dwell loop blasting bright content into a darkened lounge at 11pm.
+- Decorative motion competing with the brand chrome — the dwell loop should feel of-a-piece with the venue, not be a separate visual register.
+
+**Critical UX dimensions:** asset quality, motion continuity, content variation, ambient-luminance awareness.
+**Negligible UX dimensions:** affordance, journey completeness, alarm hierarchy.
+
+## Hybrid and transitions
+
+Real briefs sometimes span archetypes:
+
+- **Glance → Interact**: signage that becomes interactive when a user approaches (BLE proximity, camera detection). Treat as a Subspace state machine — glanceable Canvas as default, transition into interact Subspace on approach event. Don't try to make one Canvas serve both; the design discipline differs.
+- **Browse → Transact**: retail menu that promotes to ordering. Same — boundary Canvas with explicit "I want to order" affordance.
+- **Monitor → Interact**: dashboard with an action button (acknowledge alarm, dispatch protocol). The action follows the full 7-step journey; the monitor part follows monitoring discipline.
+- **Dwell → Glance**: ambient screen that occasionally surfaces information (welcome message for VIP, time-sensitive promotion). Add a glance Canvas as a temporary state, return to dwell after.
+
+In every case, the transition itself is a designed moment, not an accident.
+
+## How to use this file
+
+1. **Pick the archetype** as part of Priority #0 — what is the user doing in front of the screen?
+2. **Apply the rule set** as the design's starting constraints.
+3. **Check the failure modes** before declaring the design done — most are specific to the archetype.
+4. **Note the UX dimension weights** — let critique focus where it matters for the chosen archetype.
+
+If you find yourself wanting to follow rules from a different archetype, the brief may actually be that archetype. Pick again.