@funpixel/tools 0.0.0-stage → 0.1.1

package/plugins/claude/skills/mobile-ui/references/hud-and-title.md

@@ -0,0 +1,108 @@
+# The HUD as data, and a real title
+
+Styled ad hoc, one CSS rule at a time, both surfaces drift to the default: a score top left, lives
+top right, a white sans-serif, a title that is a heading and a button. One game's bar names that
+layout as the mark of an unauthored game.
+
+## The HUD is a list and a theme
+
+What the HUD shows is a list, how it looks is tokens in one file, and one component renders both:
+a look request changes a token or a row.
+
+```ts
+// src/hud.tsx (the scaffold's HUD)
+export const HUD = [
+  { id: 'lives', field: 'lives', tier: 'always',  anchor: 'bottom-left', icon: 'seal' },
+  { id: 'score', field: 'score', tier: 'always',  anchor: 'top-centre', frame: 'ledger-tab' },
+  { id: 'wave',  field: 'wave',  tier: 'context', anchor: 'centre', showFor: 2000 },
+  { id: 'pause', action: 'pause', tier: 'always',  anchor: 'top-right', icon: 'pause' },
+] as const;
+```
+
+```css
+/* the theme's tokens: set them in src/look.json (`look set ink=#2b211b`); styles.css keeps the defaults */
+:root {
+  --ink: #2b211b; --paper: #efe4cc; --accent: #9a3b20; --ink-dim: #6b5a4c;
+  --font-display: 'Fraunces', serif; --font-body: 'Work Sans', sans-serif;
+  --radius: 3px; --hud-size: clamp(16px, 4.2vmin, 26px);
+}
+```
+
+- **Tiers:** `always` for the few numbers play depends on, `context` for what shows when it changes
+  and then fades (a wave start, a combo), `on demand` behind pause. A budget of about eight
+  elements in play, none over what the player steers or dodges, is a starting point. (Tiers and the element budget
+  adapted from Claude Code Game Studios' HUD template, MIT.)
+- **Every number carries a label or an icon that says what it counts.** A bare "12" reads as
+  noise to a newcomer; an aim device on screen (a reticle, an arc, a trajectory) is explained the
+  first time it appears.
+- **Draw the design's idea literally.** If the note says lives are wax seals that crack, the row
+  draws a generated seal that cracks, not a number beside a heart.
+- **No literal colour outside the theme file**; contrast is computed from its pairs
+  ([contrast.md](contrast.md)). A misspelt token (`var(--acent)`) renders the browser default and
+  never errors, so capture and look after every theme change.
+- **The HUD only reads** state and fires actions, so a HUD bug never becomes a rules bug.
+- **The data is this game's.** There is no preset to pick; a shared preset is how every game ends
+  up with the same HUD.
+
+## A 3D action HUD on a phone: what one game measured
+
+A three.js horror game (29 Sep 2026) put what it could on the hero's model (collar
+lights for health, a gas tube, a wrist dial) and kept on the glass only what the hands can do now:
+a contextual key bar on desktop (explore, fight, grab, hold with its progress), a thumb cluster on
+touch (a stick that appears under the thumb, a button whose word changes with the moment, a hold
+button with a progress ring, the tool with its ammo). `look --hud` on its phone build read 41% of
+the play area painted by HUD (the shelf's aim is under a quarter). The causes, and what brought it
+to 22–34% at the busiest moments:
+
+- **Faded is not gone.** A chapter card faded to opacity 0 stayed in the render tree and counted as
+  HUD all chapter; a faded title kept animating over the canvas every frame. Adding
+  `visibility: hidden` (and pausing its animations) when a fade ends takes a layer out of both the
+  measure and the compositor.
+- **One thing read at a time.** The radio panel, a tutorial caption and a new-tool card could all
+  be up at once. The radio now waits to start a line while a caption or card is being read.
+- **Compact panels on a phone**, text at 12 px and up, every target 44 px or more.
+- **A control that answers on touch.** A tap-to-cut that missed showed nothing, so the blind player
+  could not tell a miss from a broken button; a CUT button when a joint is in reach, and a spark on
+  a miss, were its next step.
+
+## The title is a scene, not a form
+
+The title (`title` in `__FPX_VIEWS__`) is the first frame a player judges and the store shot's
+source. What a title can carry, as options; `data-fpx-start` is the one fact the tools rely on
+(`verify --front-door` presses it):
+1. The game's own art behind a wordmark in the display face, with a quiet zone so it reads.
+2. One start control marked `data-fpx-start`, in thumb reach and on Enter or Space. A mode choice
+   comes after it (`data-fpx-choice`).
+3. A key table on the title is wrong on touch; one line of objective, with controls taught in
+   play where first needed, is one way that works on both. What the how-to view says a thumb does
+   is exactly what the touch controls do, or the first tap contradicts the screen.
+4. Mute and settings as icons, here and in pause; the best score when the game keeps one.
+5. Something moving at rest tells the player the game is running; two captures a second apart
+   with no input show whether anything does.
+6. A short transition out (a few hundred ms) keeps the press feeling answered.
+
+`audit-screens` measures every declared view; `verify --front-door` presses the start control.
+
+## A splash, if the game wants one
+
+A splash is the first thing a player sees and a studio's signature: a second of the maker's name
+or mark before the title, the way a console game opens on its studio card. Nothing requires one;
+a game with no one to sign it can go straight to the title. What keeps it free for the player:
+- About 1 to 1.5 s, then it hands over to the title by itself. A tap or a key skips it, and the
+  skipping tap does not also press whatever appears under the finger.
+- Once per fresh load: a reload a minute later goes straight to the title.
+- A full-bleed background with the content inside the safe area, sized by `vmin` so portrait and
+  landscape both fit; under reduced motion it holds still.
+- It is a screen like the others: `__FPX_STATE__().screen` reads `"splash"` while it is up, so
+  `verify --front-door` waits for the title's start control rather than pressing into a card, and
+  declared as a view it is captured and audited like the rest (`capture --view splash`).
+
+In a funtools scaffold it is `src/splash.tsx`, picked by one line in `funpixel.json`:
+- `"splash": "own"` (the default): the game's own card. It starts as the title with a line for
+  the studio's name (`STUDIO`); make it yours with your mark, colours, a sting.
+- `"splash": "funpixel"`: a ready "Made with Funpixel" card in Funpixel's own mark, colours and
+  faces (`src/splash-funpixel/`), for a creator who wants to say where the game was made.
+- `"splash": "none"`, or no line: no splash.
+
+`src/splash-funpixel/` ships only when chosen: with any other line, funtools leaves it out of
+uploads, exports and packs.

package/plugins/claude/skills/mobile-ui/references/hud-genres.md

@@ -0,0 +1,124 @@
+# HUDs the hits ship, and a layout per genre
+
+A HUD is the game talking while the player is busy. The hits say very little, say it where the eye
+already is, and animate every change so the player feels it without reading. Our reviews name the
+opposite: banners over the fight, ×n counters piling into a heap, a pause button pushed off the
+screen by a lives row, a number with no label. This page is what to borrow, as options; the
+game's own idea comes first ([hud-and-title.md](hud-and-title.md)).
+
+## What the hits do
+
+| Game | What the HUD shows, and where | The idea worth taking |
+|---|---|---|
+| Hollow Knight | masks (health pips) and a soul vessel top left, currency under them; nothing else in play | Health as objects that crack when lost; the map only on a held button |
+| Celeste | nothing in play; a collected strawberry shows its count briefly, then fades | Dash state is on the character: her hair changes colour when the dash is spent |
+| Hades | health and death-defiance pips in a bottom corner, enemy bars under each enemy, the boss bar across the top | The centre belongs to the fight; damage numbers rise from what was hit |
+| Dead Cells | health bar with its number and the equipped skills in the bottom left, a small map in a corner | Cooldowns drawn on the skill icon itself as a sweep, so one glance reads both |
+| Vampire Survivors | an experience bar across the top edge with the level at its end, time under it, kills and gold in a corner; a small health bar under the character | The level-up stops play and offers three or four cards in the centre: the one moment the HUD may own the middle |
+| Balatro | a side panel with the target, the running score, hands and discards left, money | Every number counts up, each card's value pops above that card with a rising pitch, and nothing collides |
+| Suika Game | the next piece, the score and the whole evolution chain stay in the margins beside the jar | The rules are on screen the whole time (the evolution ring), so a newcomer never has to remember them |
+| Pac-Man CE DX | score, time and the multiplier outside the maze | Eats score where they happen; nothing is ever drawn over the maze |
+| Slay the Spire | a thin top bar (health, gold, potions, relics); in combat, health under each body and each enemy's next move as an icon with a number over its head | Intent icons: the threat announces its next move, which is most of the game's readability |
+
+In 3D the same ideas move into the world:
+- **Diegetic**: the information is part of the world (health drawn on the character's suit, ammo on
+  the weapon, dash state in a colour). Best for immersion; readable only when big and high in
+  contrast.
+- **World-space**: flat UI pinned to a thing in the scene (a bar over an enemy, a stamina ring
+  beside the character that appears only while it drains, a name over a player). Scales and hides
+  with distance and never leaves the thing it describes.
+- **Screen-space**: the classic overlay, kept to the edges.
+- **Reticle**: a small centre mark that grows with spread, changes colour over a target, and shows
+  a brief cross on a hit. It is the most-read pixel on the screen; keep it 2 px of stroke with an
+  outline, not a big graphic.
+- **Compass and waypoints**: a strip across the top that slides with the camera's heading, or a
+  marker pinned over the goal that clamps to the screen edge as an arrow when the goal is behind or
+  off screen, with the distance beside it.
+
+## Information tiers
+
+1. **Standing** (at most four readouts in play): what a decision needs every second: health, the
+   score or the goal count, the timer if it pressures, the pause control.
+2. **Context**: appears when it changes and fades after 1.5 to 2.5 s: a wave start, a combo, a
+   pickup's count, a new enemy's tag.
+3. **On demand**: behind pause or a held button: map, inventory, the full stats.
+4. **On the actor**: whatever describes one thing lives on it (its health, its intent, its
+   cooldown), so the eye does not travel to a corner and back.
+
+Prefer moving a readout down a tier to shrinking it: Celeste shows nothing and teaches everything by
+play.
+
+## Juice on a HUD change
+
+Every change the player caused gets an answer the eye catches while it looks at the play:
+- **Counters count** from the old value to the new over 200 to 400 ms, ease-out, with a scale pulse
+  (1 → 1.15 → 1 in about 120 ms) and a brief tint in the accent. A large gain counts longer; a
+  loss snaps down at once and flashes the harm colour.
+- **Collects fly**: the pickup arcs from where it was taken to its HUD icon (300 to 500 ms), then
+  the counter pulses on arrival, not before.
+- **Pips pop** in on a gain (scale 1.4 → 1 and a few sparks) and crack or shake on a loss; the lost
+  pip stays as an empty outline, so the maximum stays readable.
+- **Bars trail**: a second, lighter bar holds the old value for 300 to 500 ms and then drains, so a
+  hit's size reads after the fact. A bar under a fifth pulses slowly, under twice a second, so it
+  warns rather than strobes.
+- **Pitch climbs** on a chain (each step a semitone or two), the number and the sound together.
+- **Merge, never stack**: a repeated event updates one badge (×4 becomes ×5 and pulses) instead of
+  spawning a second one. Stacking toasts is the most common HUD defect in our reviews.
+
+## Readable at phone size
+
+- Standing numbers at 16 to 22 CSS px, never under 12 px for any text; `tabular-nums` so a
+  counting number does not jitter.
+- Text over a moving scene sits on a plate (the theme's ink at 60 to 80% alpha) or carries a
+  2 px outline; a contrast ratio of at least 4.5:1 against the frame behind it, measured on the
+  captured frame rather than the stylesheet.
+- Icons 20 to 24 px beside their numbers; a label or an icon on every number.
+- Everything edge-anchored pads with `max(16px, env(safe-area-inset-*))`. In landscape the notch is
+  on a side: the corner the thumb does not use holds the HUD.
+- Under a quarter of the play area covered by HUD, and nothing in the middle where the player
+  steers or dodges.
+
+## The HUD zone and the message lane
+
+Decide where the HUD may paint before drawing any of it:
+- **The zone**: the edge bands (top and bottom bands in portrait, the four corners in landscape)
+  plus one banner line. The rest belongs to the play.
+- **Banners** (wave, NEW, boss) sit in the band away from the player: over the play only when the
+  play is paused or between waves, and never over the player's actor.
+- **Messages go through one lane**: one message at a time in the band under the HUD row, each
+  on screen at least as long as its words take to read (0.8 s, plus about 0.3 s a word); a newer
+  one waits until the current one has been read, a repeat merges into it (×2), and a critical beat
+  (death, the boss) clears the lane. Eight of our games covered the play with stacked banners at
+  the moment that mattered, or faded a line before it could be read; both came from the kit's old
+  toast defaults.
+- **Pause and mute never move**: a lives row that grows must wrap or shrink, not push a control
+  off the screen.
+
+## A layout per genre
+
+| Genre | Standing | Context | Where |
+|---|---|---|---|
+| Arcade (chase, shooter) | score, lives as pips, the multiplier | chain pops at the event, wave banner | score top centre or a top corner, lives the other corner, pops on the play |
+| Platformer | health pips, the collectible count only after a pickup | checkpoint, a pickup's count | top left; ability state on the character (a colour, a glow) |
+| Survivors | experience bar across the top, time, health under the character | level-up cards (pause), evolution | the top band; nothing in the middle of the horde |
+| Puzzle, merge | score, the next piece, the rules (the chain, the goal) | combo and clear pops | margins beside the board; in portrait the band above it, never over the pile |
+| Card, deckbuilder | health, energy, block, the enemies' intents | each card's value over the card as it scores | the bottom band for the hand and energy, the intents over the enemies |
+| RTS, tower defence | resources, the wave timer, the selected unit's panel | wave warning, low-resource flash | resources in the top band, the selection panel at the bottom, health bars over units |
+| Racing | position, lap, speed | a split time, a near miss | position and lap at the top, speed in the corner under the free thumb |
+| FPS (arena) | health, ammo, the reticle, a threat compass | hit markers, damage direction arcs at the screen's rim | the bottom corners and the exact centre; nothing else |
+| RPG, adventure | health and a resource, the objective marker | quest update, loot pops | a top corner, the marker in the world or on a compass strip |
+| Third-person 3D | health, the target lock | stamina ring beside the character while used | edges plus world-space rings and bars |
+
+## The scaffold's kit, and the audit
+
+`funtools init` writes `src/hud-kit.tsx` (an animated counter, pips, a trailing bar and the
+message lane, `src/toasts.ts`, that keeps to the HUD zone) and, in a Three game, `src/world-hud.ts` (markers pinned to
+objects, clamped to the screen edge with an arrow, and a reticle). Both are options: use a piece,
+restyle it through the theme, or delete the file.
+
+`npx @funpixel/tools look --hud` measures the HUD on the real frame while the game plays: how much
+of the play area it covers, each text's size and its contrast against the pixels behind it, how
+often a HUD piece sat over the player or a threat, how many transient pieces were on screen at
+once, a worded message over the middle of the play, a text gone before it can be read, and
+developer copy left on screen ("will be here", TODO, NaN; `audit-screens` lists it per view). Its findings name the element and the number; they are a mirror, and a finding the design
+chose on purpose (a banner that pauses play) is named in the hand-back with its reason.

package/plugins/claude/skills/mobile-ui/references/phone-check.md

@@ -0,0 +1,156 @@
+# Checking a game on phones
+
+A desktop verify says nothing about a phone. In one batch of 45 reviewed games, 28 of the fixes the
+reviewer asked for were phone layout, one phone frame was entirely black and was still marked "ok",
+and one game drew 7 frames a second on the phone against 28 on the desktop. A reviewer that tested
+input by tapping the middle of the screen scored a working fighting game 2 out of 10: the middle of
+that screen was empty, and the fight button sat lower down. This page is the check that catches
+each of those, in the order they were found.
+
+## The device matrix
+
+| Phone | Portrait | Landscape | Why it is in the matrix |
+|---|---|---|---|
+| Narrow Android | 360x800 | 800x360 | the narrowest common width: rows of buttons wrap here first |
+| Small iPhone (SE class) | 375x667 | 667x375 | the shortest screen: the primary button falls below the fold here |
+| Funpixel review frame | 390x844 | 844x390 | what Funpixel's own review and `verify --viewport phone` use |
+| Large iPhone (Pro Max class) | 430x932 | 932x430 | the widest: a layout sized in `vw` grows its title past the card |
+
+Check portrait and the game's own orientation. Turn touch emulation on, or the touch controls stay
+hidden and the check proves nothing; set the pixel ratio to 3, or a canvas that ignores
+`devicePixelRatio` looks sharp in the check and blurry on the phone.
+
+Desktop device emulation usually reports every safe-area inset as 0, so a notch overlap does not
+show there. `funtools capture` and `audit-screens` at `--viewport phone` emulate the review phone's
+insets instead (portrait 47 top and 34 bottom; landscape 47 each side and 21 bottom): `env()` reports
+them, so a layout that pads with `max(16px, env(safe-area-inset-*))` (skill step 2) looks padded in
+the shot and passes the audit, and one that does not sits in the notch in both. A fixed pixel margin
+that happens to clear 47 passes too, but a taller notch on another phone would cover it; `env()` is
+the one that follows the phone. Sign off on one real phone or on the review frame.
+
+`audit-screens` counts an overlap only where two elements both paint (clip-path wedges of a d-pad
+whose boxes cross do not overlap), and does not call rows clipped that their scroll container
+scrolls to.
+
+## On each frame
+
+In this order, because an earlier failure hides the later ones (a blank frame has no controls to
+press).
+
+1. **It drew.** A frame that is one flat colour after the title screen is a failure, however the
+   rest of the review reads. Blank means fewer than about 0.1% of the pixels differ from the clear
+   colour. An unreadable frame is different: a canvas the page could not read back, a tab that was
+   not visible, a read that came back fully transparent. That is not observed, never blank. One
+   builder was told a working game was blank because an off-screen pane read every frame as empty,
+   and rewrote it 14 times, down to a title screen.
+2. **Press what a thumb would press.** Find the controls by name: buttons and links with text or an
+   `aria-label`, and every element with `data-fpx-touch`. Press the start words first (play, start,
+   tap to start, go, fight, new game), then each control on its own. Read `window.__FPX_STATE__()`
+   and take a screenshot before and after each press. A press that changes neither the state nor
+   more than about 2% of the picture is a dead control. Tapping the empty centre instead is how the
+   working fighting game above scored 2.
+3. **No control under 44 by 44 CSS px.** Measure the hit area (the element's box, padding
+   included), not the glyph. List every smaller one with its size.
+4. **Nothing covers play.** At the points where the action happens (the hero, the next target, the
+   primary button), `document.elementsFromPoint(x, y)` returns the canvas or the control you
+   meant, not a HUD panel. Get those points from the game's own world-to-screen function.
+5. **The frame rate held.** Sample at least 30 frames on the phone frame and on the desktop in the
+   same browser. The number to read is `1000 / p95 frame time`, not the average, which hides the
+   stutters. In a software-rendered browser (headless, CI, a review box) absolute numbers mean
+   nothing: judge the drop from desktop to phone. On a real phone, hold 50 or more.
+6. **Text fits and nothing overlaps.** The glyph-bounds check in
+   [recipes.md](recipes.md) at every size in the matrix.
+
+## A self-test for every frame
+
+Register it once; the hosted probe and `funtools verify` run `__FPX_SELFTEST__` at each viewport
+they open.
+
+```ts
+const HIT = 'button, a[href], [role="button"], [data-fpx-touch], input, select';
+function smallTargets(min = 44): string[] {
+  return [...document.querySelectorAll<HTMLElement>(HIT)]
+    .filter((el) => el.offsetParent !== null)                       // visible only
+    .map((el) => ({ el, r: el.getBoundingClientRect() }))
+    .filter(({ r }) => r.width < min || r.height < min)
+    .map(({ el, r }) => (el.getAttribute('aria-label') ?? el.textContent?.trim() ?? el.tagName) + ' ' + Math.round(r.width) + 'x' + Math.round(r.height));
+}
+function overlappingControls(): string[] {
+  const boxes = [...document.querySelectorAll<HTMLElement>(HIT)].filter((el) => el.offsetParent !== null)
+    .map((el) => ({ el, r: el.getBoundingClientRect() }));
+  const out: string[] = [];
+  for (let i = 0; i < boxes.length; i++) for (let j = i + 1; j < boxes.length; j++) {
+    const a = boxes[i].r, b = boxes[j].r;
+    if (a.left < b.right && b.left < a.right && a.top < b.bottom && b.top < a.bottom) out.push(i + '/' + j);
+  }
+  return out;
+}
+window.__FPX_SELFTEST__ = [
+  ...(window.__FPX_SELFTEST__ ?? []),
+  { name: 'tap targets at least 44px', run: () => smallTargets().length === 0 },
+  { name: 'controls do not overlap', run: () => overlappingControls().length === 0 },
+];
+```
+
+Controls hidden on purpose (the desktop layout) are skipped by the `offsetParent` test; run the
+check with touch on so the touch layout is the one measured.
+
+## What the phone fixes were
+
+The 28 phone-layout fixes from that batch, by kind. The checks above are ordered by this count.
+
+| Kind | Fixes | Typical case |
+|---|---|---|
+| Portrait fit, orientation or scale | 12 | a landscape world squeezed into a sliver at the top of a portrait screen |
+| Tap targets and touch affordance | 7 | a small end-screen button; bottles too small to tap apart |
+| Safe area, notch, status bar | 4 | the HUD under the status bar |
+| Overlap | 3 | a level label on top of the undo and reset buttons |
+| Clipped or broken text | 2 | a title cut off at both sides |
+
+A frame rate that collapses on the phone and a colour pair that stops reading at phone brightness
+were found too, and are not in the 28.
+
+## Four looks, cheapest first
+
+Chromium at a phone size misses WebKit's own behaviour: audio that unlocks only on a release,
+`100vh` under the address bar, safe-area insets, the silent switch, a start control that answers in
+Chrome and not in Safari. Each look below catches more and costs more; use each where it is cheapest.
+
+Safari's bars take about 160 px of an upright phone's height, and the 390x844 review frames have
+none: one game's basket filled 86% of the width in them and 60% on the owner's iPhone, because it
+was sized by the height. `look --hud --viewport phone` measures the play again on the page Safari
+leaves (390x684) and saves that frame beside its own (`hud-playing-phone-safari.png`);
+`capture --viewport phone --safari` shoots any view there (724x283 held sideways). Judge a phone
+layout on those.
+
+| Look | Command | Costs | Catches | When |
+|---|---|---|---|---|
+| Chromium | `verify --viewport phone` (and capture, play, journey, feel) | seconds, free, runs everywhere | the rules, the layout at phone sizes, touch through emulation; the server's probe is this engine | every change |
+| WebKit | the same with `--engine webkit` | seconds; once the WebKit install line `doctor` prints (Playwright pinned to funtools' own version) | Safari's engine: its CSS, events, audio and WebGL quirks, without Safari's bars or iOS input | each round, and whenever a bug might be Safari's |
+| iOS Simulator | `phone` (`--orientation landscape` too) | about a minute a run; an Apple Silicon Mac, Xcode 26, `brew install baguette` | real Mobile Safari: its bars, the notch, safe-area insets, iOS taps, the page's own frames and errors | before hand-back |
+| Your iPhone | `dev --phone`, scan the QR code | your time; the same Wi-Fi | the feel in the hand, real audio and haptics, the phone's real speed; every save rebuilds there | for feel and acceptance |
+
+A WebKit verify is kept in `.funtools/verify/webkit.json`; `verify.json`, which publish reads,
+stays Chromium's. WebKit's taps are trusted, but its holds and drags are synthetic events (no CDP
+there), so a game that checks `isTrusted` ignores them. The simulator's frame numbers are WebKit's
+pacing on the Mac, not a phone's speed, and its audio is the Mac's. `dev --phone` binds the Mac's
+local-network address and exposes the dev server to that network: stop it when you are done.
+
+```sh
+npx @funpixel/tools verify --viewport phone --front-door --engine webkit
+npm run build && npx @funpixel/tools phone            # --sim "iPhone Air"; --orientation landscape
+npx @funpixel/tools phone --taps "20%,80% 80%,80%"    # presses during play, points or percents
+npx @funpixel/tools dev --phone                       # a QR code for your phone on the same Wi-Fi
+```
+
+`phone` boots an iPhone, opens the built game in Mobile Safari, waits for Safari's first-run tip
+and closes it (on a fresh Safari it takes the first tap anywhere: the page gets the touch but no
+click, so a start button looks dead), finds the controls through the accessibility tree (each
+one's size; under 44 pt is named), taps the start control by name, plays a few seconds and
+screenshots each step to `.funtools/phone/<time>/`. The page reports its own frame intervals,
+errors, `__FPX_STATE__()`, safe-area insets and which taps reached it, so a start tap that leaves
+`screen` on the title is said with what the page saw. `--swipes "right up"` swipes the play in
+portrait and names the state fields each swipe changed: a game steered by a swipe is steered in
+Safari, not only in Chromium's emulated touch. Then the simulator shuts down. It is a look,
+not a gate. A later path, not built: Safari's Remote Automation (`safaridriver`) drives a real
+iPhone over USB once Settings › Safari › Advanced › Remote Automation is on.