@funpixel/tools 0.0.0-stage → 0.1.1

package/plugins/cursor/skills/funpixel-verify/references/actors.md

@@ -0,0 +1,94 @@
+# The actors contract: where everything stands
+
+`npx @funpixel/tools walk` plays every route from the title and judges the world as it goes;
+`life`, `framing` and `score` place and judge people, creatures and the hero. They read one global
+the game answers, in metres, y up, the feet at `x, y, z`:
+
+```ts
+window.__FPX_ACTORS__ = () => ({ unit: 'm', supports: ['gantryWalk'], actors: [
+  { id: 'ren', kind: 'player', type: 'person', x, y, z, h: 1.75, r: 0.35, ground: heightAt(x, z), node: 'player' },
+  { id: 'carter-3', kind: 'person', type: 'carter', scene: 'crane', task: 'haul', state: 'walk', reacting: 'wave', facing, x, y, z, h: 1.68, r: 0.3, ground, node: 'folk-3' },
+  { id: 'crab-3', kind: 'creature', type: 'crab', x, y, z, h: 0.32, r: 0.2, ground, solid: false, state: 'flee' },
+  { id: 'kite-1', kind: 'creature', type: 'kite', x, y, z, h: 0.4, r: 0.5, flying: true, ground },
+  { id: 'container-12', kind: 'prop', type: 'container', x, y, z, h: 2.6, w: 6.1, d: 2.44, yaw, ground },
+  { id: 'late-show', kind: 'machine', type: 'ship', landed: true, x, y, z, h: 13, w: 27, d: 9, yaw, ground: pad.top, mesh: 'lateShow' },
+  { id: 'pad', kind: 'prop', type: 'landing pad', support: true, x, y, z, h: 1.1, w: 28, d: 30, yaw, node: 'landingPad' },
+] });
+```
+
+| field | meaning |
+|---|---|
+| `id` | stable per actor (`framing --actors ren`, the hero of a `score` moment) |
+| `kind` | `player`, `person`, `creature`, `machine` or `prop`; a species or role word (`crab`, `townsfolk`, `npc`, `drone`) is read into one of those and kept as `type` |
+| `type` | what it is, the key into `funpixel.json` `scale`; missing = `species`, `role`, or the id without its number |
+| `x, y, z` | the feet, world space, metres (or `pos`/`position` as `{x,y,z}` or `[x,y,z]`) |
+| `h` | height; without it scale is not judged |
+| `r` or `w, d, yaw` | the footprint: a radius, or a box turned by `yaw` about +y |
+| `ground` | the height of what is under the feet (the terrain, or the pad's deck under a landed ship); without it floating is not observed. `ground: true` (a boolean) on an entry instead marks its mesh as ground others stand on, as `support: true` does |
+| `supports` | at the top of the answer: mesh names that are ground others stand on (a deck, a walkway, a pad) when their names do not say so |
+| `flying` (or `flies`) | meant to be in the air: judged for a flap, not for floating or collisions; on a vehicle or prop, left out of grounding |
+| `landed` | a vehicle or prop that must rest on the ground under its whole footprint, judged whatever its size |
+| `gait` | the gait preset it moves on (`walk`, `run`, `sneak`, `carry`, `limp`, `old`, `child`, `quadruped`, `flyer`; the starter's `src/motion.ts`): `life` notes travel far from the preset's design speed (the feet moonwalk or scramble, measured with `h` as its height) and a declared gait that slides |
+| `scene` (or `group`) | the little scene a person belongs to (`crane`, `stall`); people of one scene may stand close. It is authoritative: untagged people are read for one (facing each other within 2.5 m, or moving together) and reported "untagged: inferred scene"; two different tags close together are a clump |
+| `facing` (or `heading`) | a person's or creature's forward as a world yaw, `atan2(forward.x, forward.z)`; without it the node's own turn is read |
+| `solid` | default true; false for what may be walked through |
+| `task` | the loop it is on (`haul`, `patrol`, `errand`) |
+| `state` | what it is doing (`idle`, `walk`, `flee`); a change near the player counts as a reaction |
+| `reacting` | what it is doing because of the player (`wave`, `look`, `yield`, `flee`) |
+| `node` (or `mesh`) | the scene node's name, so `life` ties the animation it sees to this actor and its role, and `boxes`/`walk` find its mesh. With neither, an id is matched to a mesh by a word of it (`ship-lateShow` is the mesh `lateShow`), and for a machine or a landed entry by one name containing the other; a linked landed entry's `ground` and `x, z` are used to judge it |
+
+Also read as the contract: a bare array (`__FPX_ACTORS__ = () => [...]`), an `{ id: actor }` map,
+or an `actors` array in `__FPX_STATE__()`. With none, a Three scene is read from node names (ground
+not observed) and the report says so.
+
+## What reads it
+
+- `walk`: clipping, placement, floating, scale, stalls, challenge, losses and retry, people who
+  move through space vs animate in place, the hero's face on a crowd, flyers without a flap,
+  reactions; the crowd's placement (clumps within 1.5 m with no shared `scene`, tagged or inferred, stretches of the
+  path with nobody in view, the count against `walk.crowd.people`); and every 4 s the world itself,
+  as `boxes` reads it.
+- Big props and vehicles need no entry: `boxes` and `walk` read them from the scene (anything with
+  a 2.5 m footprint, or a node named like a vehicle: ship, craft, crawler, truck…) and raycast the
+  surfaces under where each touches down (its lowest vertices cell by cell, or its box's corners):
+  hovering, hanging over a drop, sunk, judged against the nearest surface below it. Surfaces are the
+  terrain (a mesh named `ground`, `terrain` or `floor`) and the supports: a mesh whose name ends in
+  deck, pad, platform, ramp, bridge, pier, dock, floor, street, walkway, stairs (`rampDeck`,
+  `landingPad`; not `padCrates`, not `padLeg`), one the contract lists in `supports` or marks
+  `ground: true`/`support: true`, and one the player or a person is found standing on. A leg,
+  trestle, piling or post going down into a pit with its top under a support is braced, not sunk; a
+  railing or kerb within 1.5 m of its deck is attached. A painted cut-out stands where its picture's
+  lowest opaque row does. Name the node in the contract with `landed: true` to judge a small one,
+  `flying: true` to leave one out (a ship taking off). The headline lists the worst first, landed
+  things and vehicles before props.
+- `boxes` and `walk` name a person or creature of the contract (with its `node`) built of a handful
+  of boxes, whatever its size on screen (`BOX FIGURES`). A style lock that says the world is faceted
+  (`flat-shaded`, `faceted`, `low-poly` in `design/style-block.txt`, `design/plan.md` or
+  `funpixel.json` `metadata.artStyle`) keeps terrain and rock out of the boxes read ("style: faceted (not
+  judged as boxes)") unless one facet covers more than 12% of the frame.
+- Routes in `funpixel.json` `walk.routes`:
+  `[{ name, start: ["press Enter", "click .play"], hold: ["ArrowUp"], steer, progress, done, max_s, then, continue }]`.
+  `steer` holds a state field near a value (`{ field: "lat", to: 0, lower: "ArrowLeft", raise:
+  "ArrowRight" }`); with no lateral field, `waypoints: [[x, z], …]` (or a `path` in the state)
+  steers by the player's position and learns which key turns which way. `then: "run01"` goes on
+  from where a route arrives in the same page and the same film (a prologue, then the first run);
+  `--chain a,b` does it ad hoc. A chained leg skips its `start` steps (they lead from the title) and
+  plays its `continue` steps instead, if it has any. A leg that arrives in under 3 s (its `done`
+  already held, often a chained leg with no `continue` steps) is "not observed" and nothing on it is
+  judged.
+- Framing is judged on time, not the mean: more than 15% of the walk outside the `framing` band
+  warns and names the stretches (`s 44–96 at 13–14% (floor 18%)`).
+- The hero's face on a crowd is judged by CONTENT, for people only: a picture by its URL or pixel
+  hash, a mesh by vertex count, bounds and name, so the hero's file loaded twice (once for the
+  player, once for the crowd) is still the hero's body; the shared parts are named.
+- `life`: one view, the same life verdicts. Travel is labelled with its window (10 s) and defers to
+  `walk.json` when walk ran (people on task loops wait at their stops; a short look under-counts).
+  A moment whose view jumps through its payoff and fires every cue at once is flagged, not read as
+  the world answering. `framing`: each actor's share of the frame. `score`: the hero's share
+  against the target's `hero_share` (a `--capture` still has no contract: the hero is "not read").
+- `funpixel.json` beside it: `scale` (metres), `framing` (`{ "ren": [0.16, 0.22] }`), `moments` and
+  `accuracy_min`, `life` (`{ "people": "regex", "creatures": "regex" }` for node names; `"hero": "rides"`, or
+  flies, rolls, swims, for a hero with no walk to judge),
+  `walk.crowd` (`{ "people": [6, 10], "clump_m": 1.5, "gap_m": 40 }`).
+
+Every finding is a warning; what the game does not expose is "not observed", never a pass.

package/plugins/cursor/skills/funpixel-verify/references/bar.md

@@ -0,0 +1,62 @@
+# The release bar and the panel
+
+The bar is the minimum the team's best shipped games clear. The panel is how a game is judged
+against it: three critics, blind, from captures only, seven axes and an overall each (the phone
+shots re-read on the same axes by every seat, `mobile` being that phone overall), gated as in
+the bar's rule R1. The calibrated seat prompts and captures are the studio's historical
+calibration. Apply the current scope and evidence rules here;
+revised anchors have not yet been recalibrated against those games.
+
+## The bar
+
+Each item is checked from frames; `unseen` means no captured frame shows it, so capture the view
+that would.
+
+| Item | Met when |
+|---|---|
+| `art_direction` | The frames break none of the five AD rules (matching `design/target.png` is the `art-director` agent's check, outside the scored panel) |
+| `consistency` | Assets belong to the declared direction; differences in materials, outlines or detail are intentional and readable; recurring characters keep their identity |
+| `motion` | Relevant actions and state changes read clearly across frames; intentional stillness is valid, while missing promised animation or an accidental bind pose is a finding |
+| `juice` | The action has a readable result appropriate to the game; quiet placement and physical impact can use different techniques |
+| `fun` | The ramp is visible (a wave, an area, a new threat, not only speed), the end screen gives a reason to play again, and verify reached the designed resolution (a win or close, and a loss where the design has one) |
+| `screens` | A real title (the game's own art and name, a start control), play, pause, and an end screen with instant restart |
+| `hud` | Every readout reads at phone size (no text under 12 px), never covers what the player steers, and draws the design's HUD idea in the game's theme |
+| `sound` | Promised audio is checked by verify and listening; intentional silence is valid. A still-frame seat marks sound `unseen` |
+| `input` | Keyboard and touch both wired; touch controls visible at phone size and within thumb reach |
+
+## The seats
+
+Run the `critic` agent once per seat, in parallel, and name the seat in the request ("You sit as
+the skeptic."). Each seat scores the same seven axes and overall; the persona decides what it looks at first.
+
+| Seat | Looks first at | Typical finding |
+|---|---|---|
+| Veteran player | The hit frames against the juice table, the visible ramp, the reason to play again | "the before and after frames do not distinguish a hit from a miss" |
+| UX designer | What to steer, chase and press; the screen set as one system | "pause is reachable only by Esc; no touch route" |
+| Mobile producer | The first six seconds at phone size: thumb reach, safe area, text, the store-listing look | "title art is cropped under the notch at 390x844" |
+| Skeptic | What gives it away as unfinished or generated | "enemies are orange diamonds; the backdrop is in a second style"; "the crate has no ink line, every model does" |
+
+**Blind** means each seat gets what the calibrated panel gets: the frames, a store description, the
+five AD rules, the screen audit's numbers and its own previous verdict, and nothing else: no design
+note, no target frame, no verify summary, no builder's explanation, no other seat's scores, no code.
+On the same frames of one game, seats briefed with the note and the builder's summary scored 7.10 where
+blind seats scored 6.90 (Sonnet, one panel each), and the whole in-loop panel ran 0.6 above the
+calibrated anchored one, which also saw the payoff frame.
+
+## Scoring
+
+- Each seat scores seven axes and an overall per surface ([rubric.md](rubric.md)); its score on an
+  axis is the mean over its surfaces.
+- The gate: the seats' `overall` mean at least 6.0 and their `lookAndFeel` mean at least 7.0,
+  on standard captures (every declared view at both sizes, play frames, the screen audit). That is
+  where all three bar games pass; 7.3 overall is the aim, on a curated set of the game's peak
+  moments, which costs about half a point less to reach.
+- A missing bar item or high finding stays open even above those means. Under the gate, run a named fix round: merge the findings, fix the highest (a `missing` bar item
+  first), verify, capture every view at both sizes again, and re-seat all three. Judge, fix, confirm once, then stop: one confirm round per milestone, and a
+  third panel on it re-reads taste (`playtest report` counts them). When rounds stop moving the
+  means, hand back both means, the open findings and the next round in the note's `## Fix round`
+  table.
+
+**The panel informs.** `playtest report` exits 0 whatever the panel says; `playtest report --min-score
+6.5` fails under a number you ask for (CI, or a creator holding themselves to a floor). Only the owner's
+`owner_gates.panel_min` in funpixel.json makes the panel stage an owner gate that may hold a session.

package/plugins/cursor/skills/funpixel-verify/references/checks.md

@@ -0,0 +1,69 @@
+# Checks in funpixel.json, and the hooks in detail
+
+## A check
+
+```json
+"checks": [
+  { "mechanic": "left arrow moves the player", "verb": "moveLeft", "key": "ArrowLeft",
+    "field": "x", "expect": "decreases", "subject": "player", "times": 2 }
+]
+```
+
+- `expect` is `increases`, `decreases` or `changed`.
+- `key` presses the real key; `pointer` taps a real element (a CSS selector); with neither, the
+  check calls the verb.
+- `trace: 12` holds the input for 12 frames and samples each one, which catches a jump that rises
+  and lands.
+- `subject` also reads that object's position on screen, along `axis`: `"x"` (the default) or
+  `"y"`, so a jump or a fall with a subject needs `"axis": "y"`.
+- `"sound": true` fails the check when its drive starts no sound.
+- A mechanic with no input (a timer, gravity, a spawn) gets a verb that lets time pass, awaited by
+  the check: `async wait() { await new Promise((r) => setTimeout(r, 500)); }`, then
+  `"verb": "wait"`. There is no wait field.
+
+One check per mechanic you claim is what lets verify say which one broke; a check that reaches the
+win or the loss is what proves the loop closes.
+
+Each check after the first starts from the play view entered again, with `window.__FPX_SEED__ = 1`
+set first when the page has none. So a check that ends the round or lights a one-shot power-up does
+not break the ones after it, as long as the play view's `enter()` starts a fresh round (the
+scaffold's does). An `enter()` that resumes a round keeps what the last check left, which is worth
+knowing when a later check fails for no reason of its own.
+
+`--front-door` reads the same state. When `__FPX_STATE__()` names a `screen` (or `phase`, `view`,
+`scene`, `countdown`, `started`), the press started the game only if one of those moved; the
+button's own pressed style or a ripple on the canvas does not count. A countdown that runs on the
+title passes once the state says so, for example `phase: 'countdown'`.
+
+## The signature moment
+
+`{ swarm: { moment: true, enter() {...} } }` in `__FPX_VIEWS__`: its `enter()` drives the game into
+its payoff through its own rules (pack the horde, fire the shot; `funtools sim` names the seed and
+time that stage the best one). A frame play cannot reach misleads
+every reviewer who sees it, so the moment is staged by the rules, not drawn. `capture` plays it as a
+burst (about 1.8 s) and keeps the frame at the heaviest `__FPX_MOMENT__` mark. A payoff that lands
+after the last frame is reported with how late it was, since then every frame shows the run-up.
+
+## Seeing the player
+
+For Pixi, set `window.__PIXI_APP__` and give the player a `.label`. For Three, set
+`window.__THREEJS_SCENE__`, `window.camera` and `window.THREE`, and give the player a `.name`. With
+those, a check can say whether the player can be seen, not just whether a number moved: a player
+hidden (`visible = false`, alpha 0, scale 0) while its position moves fails as "cannot be seen".
+
+## Listening
+
+Verify's `--json` carries an `audio` block (context state, sounds started, the most-played cues) and
+each check's `sounds` and `sound_cues`, where `hit x4` is one hit playing four times. By hand, after
+the first click `audio.ctx.state` is `'running'` (skill `funpixel-audio`).
+
+## Many mechanics
+
+The `qa-lead` agent turns a verdict into a short test plan when a game has many mechanics.
+
+## The whole manifest, held to its shape
+
+`npx @funpixel/tools schema` checks funpixel.json against every key a kit command reads (a mistyped
+key is named with the one it meant; `--strict` makes it an error) and the plan files beside it:
+`src/look.json`, `assets/assets.json`, `design/pipeline.json`, `design/spec/tunables.json` (a default
+outside its range, a number with no reason) and a forged world (doors that name rooms it lacks).

package/plugins/cursor/skills/funpixel-verify/references/experience.md

@@ -0,0 +1,67 @@
+# The experience bar: what the stills cannot see
+
+The calibrated panel scores seven craft axes from still frames: look, readability, intuitiveness,
+juice, fun as far as frames show it, mobile, HUD. Stills cannot see whether skill grows, whether new
+things keep arriving, why anyone comes back, who wants what, which places a player remembers, where
+a session breathes, or what the one idea is. The experience seats score those seven, 0–10 on fixed
+anchors, beside the craft panel and never instead of it; the craft panel's words stay as calibrated.
+The full bar, the hits' calibration and our games' scores are the studio's own record; this page carries what a run needs.
+
+## Running it
+
+1. `npx @funpixel/tools playtest` as usual. The blind player's round is now a long session
+   (`--long 10`, about ten minutes of game time; `--long 0` for a short round), ending with "would
+   you come back tomorrow, and why?" (`come_back` in its report).
+2. After the round is filed, `npx @funpixel/tools playtest experience` runs `funtools depth` for free
+   into the playtest's `experience/` folder and writes one prompt per experience seat: the designer
+   (depth, content, replay, the arc) and the storyteller (story, world, the arc, the signature).
+   `--quick` writes the designer only.
+3. Run each seat as a fresh agent handed only its prompt file, as the craft seats are.
+4. `npx @funpixel/tools playtest report` puts their means beside the genre hit's calibration, the
+   come-back answer, what the design claimed and nothing showed, and ranks their changes among the
+   next steps.
+
+`npx @funpixel/tools depth` alone gives the evidence at any time: facts X1… (the bots' skill spread
+from `sim`, the verb's windows from `feel`, the design's content tables, the shipped pictures, sounds,
+music and words, what real play reached, the beat strip's numbers, the come-back answer, which
+dimensions the GDD addresses), `text.md` (every sentence a player can read) and a beat strip.
+
+## The evidence it reads, and what makes it better
+
+| Dimension | Free evidence | What lets it measure more |
+|---|---|---|
+| depth and mastery | `sim` cohorts (skilled, naive, novice, idle), `feel` windows | `test/probes.ts` and `test/feel.json` (without them it says "not measured") |
+| content and progression | the GDD's content tables (claims), real play's places and firsts a minute | a `place` field in `__FPX_STATE__` (level, room, world, garden, wave…); a debut column |
+| replay | the long session's come-back answer | a long blind session on the current build |
+| story and storytelling | `text.md`, the beat strip, the GDD | lines the player reads in play, not only in the design |
+| world building | places reached, frames | a `place` field; each place's own look and rule on screen |
+| emotional arc and pacing | beats a minute, the longest flat stretch, tension peaks and releases | a `tension` field (0–1) in the state; `sim` timelines for music |
+| originality | the seats, the head to head | a signature named in the GDD's promise |
+
+## Reading the scores
+
+- **Delivered, not claimed.** The seats credit only what play, frames or readable text show, and
+  list the rest as `claimed`. Our games' largest gaps were claims: six gardens of which play reached
+  one, eight worlds of which play reached two levels. A playtest that plays further scores more
+  without a line of code changing.
+- **A slice is capped where only a longer game can go.** Content above about 4, replay and world
+  above about 6, and an arc above about 6 need more than one level. Compare a slice to its hit on
+  depth, story and originality, where a slice can reach the hit; read the rest as distance to a
+  full game.
+- **The two seats agreed within one point on 97 of 98 dimension scores** (the hits and our six
+  games; one split of 3 on Suika Game's originality), and re-runs on lightly changed evidence moved
+  a game's mean by 0.14 at most. Differences under 0.5 on one dimension are noise.
+- **The genre hit is not always high here.** Suika Game scores 3.1 (no story, no world, one jar),
+  Pac-Man Championship Edition DX 4.7; Hades 8.1 and Celeste 8.0. A craft score at the hit's and an
+  experience score far under it is the gap the owner named: the hits' extra point is depth.
+
+## What moves a game on this bar, cheapest first
+
+1. Wire `test/probes.ts`: the skill spread is the whole depth score's evidence, and a naive bot that
+   wins as fast as a skilled one is the most common depth finding.
+2. Put `place` and `tension` in `__FPX_STATE__`, so `depth` can count places and draw the arc.
+3. Make the reachable game match the claimed one: a long blind session that reaches the later
+   levels, or a design that claims what play reaches.
+4. One want, one turn, one payoff told through play (a place that changes as it is saved, an end
+   card that pays the first screen's want off).
+5. A reason to come back tomorrow that the title shows (a daily seed, an unlock, a best per level).

package/plugins/cursor/skills/funpixel-verify/references/eyes.md

@@ -0,0 +1,54 @@
+# Looking closer: inspect, profile, phone, clip
+
+Four local, free looks for when a verdict says *that* something is wrong and you want to see *what*.
+Each reports and never judges; pick the one that answers your question.
+
+| Question | Look | What comes back |
+|---|---|---|
+| What is this thing on screen, and where is it made? | `npx @funpixel/tools inspect --at 50%,80%` or `--name hero` | each object under the point (HUD first), its state, the source `file:line` that created it |
+| Why did it throw? | `npx @funpixel/tools inspect` | every runtime error so far at its source line, and `__FPX_STATE__()` |
+| What did my change cost? | `npx @funpixel/tools profile --views playing --compare` | the moved numbers against the last run made the same way, GPU time when the browser has the timer |
+| Does it work in real iPhone Safari? | `npx @funpixel/tools phone` | screenshots from the iOS Simulator, the controls and their sizes, WebKit's frames and errors |
+| How does it feel in motion? | `npx @funpixel/tools reel --frames-only`, then `npx @funpixel/tools clip` | 12-frame strips and one prompt per clip seat for your own agent |
+
+## inspect
+
+The platform's inspector (the one a person clicks in the Studio) answers from the game's own dev
+server, so it needs `npm install` and a Pixi or Three game; `--url` points it at a running
+`funtools dev`. `--view`, `--verbs` and `--front-door` get to the state first. On the scaffold,
+`--name player` answered `player (Container) … made at src/game.ts:18 const box = new
+PIXI.Container();` — the factory line; the call that used the factory is one step up in your
+code. Name the objects you will ask about (`label` in Pixi, `name` in Three); unnamed ones read as
+`Graphics` or `Sprite_12`. A planted `null.a` two lines under a TypeScript interface came back at
+its true line (104), where the raw transformed file said 86.
+
+## profile --compare
+
+Frame times in a headless browser sit at the display's 16.7 ms until the CPU runs out, so a heavy
+change can leave them flat. On the scaffold, 30 blurred glows left frame p95 at 16.7 ms while GPU
+p95 went 0.67 → 11.78 ms and draw calls 2 → 274; taking them out read as the same numbers falling.
+The burn rate counts frames over the budget (`--budget`, default 18 ms) against a 1% allowance: 1×
+is right at the line, 3× sustained, 10× a stutter. Runs are compared only when made the same way
+(seed, viewport, throttle, renderer, frames); a changed condition is named instead. Moves inside
+±5% are noise between two runs, `--repeat 3` narrows it.
+
+## phone
+
+Optional: an Apple Silicon Mac, Xcode 26 and `brew install baguette` (`doctor` says which is
+missing). It opens the built game in Mobile Safari, taps the start control it finds by name, plays
+for `--seconds` and screenshots each step; `--taps "20%,80% 80%,80%"` presses during play. Its
+frame numbers are WebKit's pacing on the Mac, not a phone's speed; its value is WebKit itself:
+layout under Safari's bars and the notch, a start control that answers in Chrome and not in
+Safari. On the scaffold the page measured 402x714 CSS px under Safari's bars (Chromium's phone view
+is 390x844 with no bars) with every safe-area inset 0, and Play moved `screen` from `title` to
+`playing`. `--orientation landscape` plays too (its taps are mapped to the turned screen). The four
+looks from cheapest (Chromium, `--engine webkit`, `phone`, your own iPhone through `dev --phone`)
+and when each earns its cost: skill `funpixel-mobile-ui`, `references/phone-check.md`.
+
+## clip
+
+Stills cannot judge feel. `clip` cuts strips of 12 consecutive frames, one per payoff the game
+marked with `__FPX_MOMENT__` and the rest spread over the run, and writes a prompt for a `player`
+and an `animator` seat (feel, juice, motion, clarity; each cites strips and frames). Run each prompt
+in a fresh agent with no other context, then `clip report`. Its words are separate from the
+calibrated still panel's, so its scores are not comparable to the panel's numbers or the hits'.

package/plugins/cursor/skills/funpixel-verify/references/fidelity.md

@@ -0,0 +1,126 @@
+# Plan fidelity: what was planned against what was built
+
+The critic panel never sees the plan, so it cannot see that the game drifted from it. A
+third-person horror chapter (29 Sep 2026) scored 6.55 overall and 7.62 on look
+from the panel; a blind judge holding the same build against its own GDD gave art direction 4 and
+creative direction 3, and named what the panel could not: the thesis frame's fingers missing from
+the seam, the first walker at arm's length instead of far down the corridor, a stencil colour that
+had drifted, a camera low and to the side where the plan put it high over the shoulder. A pass later
+held the dark, the camera and the stencils (AD-3 held) and still missed the fingers. That judge is now
+the fidelity seat in `funtools playtest`.
+
+## What the seat sees, and nothing else
+
+- The GDD's creative direction in its own words: the pitch, the promise, the thesis, the 6-second ad.
+- The declared style (the first paragraph under the look or art direction heading).
+- The AD rules.
+- Each target frame's moment and intent (what the frame must carry).
+- The measured facts (F…, and P1: which moments were paired and which were not, and why).
+- Image pairs: the target frame beside the game's frame of the same moment, and a strip of
+  consecutive frames when the moment is animated.
+- The last round's findings, last.
+
+It scores each moment on art (camera and composition, light, materials, how the actors read, the
+world's marks, the grade) and creative (does the frame carry the moment's intent), 0–10; then art
+direction and creative direction overall, each AD rule as held, partly or broken, and five changes.
+It ignores the HUD, and where the plan's words and its own picture disagree, the words win.
+
+## Pairing the moments
+
+The GDD template's target-frames table ties each target to its moment:
+
+| Moment | Target | Game frame | Intent | Pins |
+|---|---|---|---|---|
+| 1:00 the first walker | design/first-look/frame-walker.png | view firstWalker | dread: a lone figure far down the corridor, joints lit, torso dark | AD-2, AD-3 |
+
+A game frame is a declared view (`view firstWalker`, shot by `capture --all`), a journey mark
+(`journey chapter1 walker`, the frame the latest run held at that mark) or a file. With no table,
+`design/target.png` is paired with the play view. A moment with no game frame is listed in P1 with
+the reason, never scored.
+
+**Shoot the moment the plan means, not a fixed timestamp.** The walker at the six metres the target
+drew, the splice as it completes, the merge at its pop. A view whose `enter()` replays a recorded run
+to that beat (the playtest reference's `game.replay.seek('first-walker')`), or a journey mark placed
+at it, lands there on every build; a clock time drifts the first time the level changes. Two of our
+own fallback pairs show the cost: one game's play view was captured with an empty basket, so the
+seat could only say the target's pile and squish were missing; another's was captured before
+any sneeze, so the flowers the target promises were not on the ground.
+
+**Or pin it to a time on the saved route, and name both.** From the first playtest on, the blind
+player's steps are kept as the route (`test/journeys/playtest-route.json`) and every playtest replays
+it with the same viewport and seed. A game frame `at 1:00` (or a moment written `1:00 the first
+walker`) is the route's frame at that time on the script's own clock: like with like every round,
+as the horror chapter's films were (0:10, 1:00, 2:00, 3:00, 5:00). A row that names both, `at 1:00, view
+firstWalker`, is judged on the played frame, and the view stays beside it as the staged frame. When
+the played route never reaches what a staged view or a lane's file shows (no moment, screen or beat
+by that name in play), the report says so: the horror chapter's diver was showcase art in its lane's frame
+and "a few coral points" in play. A moment past the route's end is play that never got there. Keep
+the route while the level holds; when the level changes, record a new one (`journey record
+playtest-route --force`) and read the history's next column as a new baseline, which the report marks.
+
+## How the judging is kept honest
+
+Borrowed, with credit, from Scenario's quality skills (MIT; research 06 §2.2–2.3):
+
+- **The rubric comes first** (Scenario). The plan's words were written before the build; a rubric
+  written after seeing the frames inherits their flaws. Every miss cites the line it fails:
+  `[AD-2]`, `[intent: the seam]`, `[direction]`.
+- **Declared style is intent, never a finding**. Pixel art that looks pixelated is
+  what was asked for; the style applied inconsistently still is a finding.
+- **Sweep an animated moment for identity** (Scenario). Across a strip, a named part gained, lost,
+  recoloured or reshaped is drift; a part moving with the action is animation. A spot check at one
+  frame missed a defect that faded in half a second later.
+- **Facts over the frame**. The numbered facts outrank a reading of one picture: a
+  world that looks empty in one frame while the facts count what is off-camera is not empty.
+- **Adjudicate the last round**. Each earlier finding comes back marked fixed,
+  unchanged or worse, and a score whose evidence did not change does not move.
+
+## The plan's interface: UI and UX as imagined or not
+
+The owner's second question, from that game's lane: is the interface the one the plan designed?
+Its GDD draws its phone HUD and its message screen as HTML at 852 × 393, each element
+numbered with a line of spec ("1 collar ring: health, five cyan lights"; "nothing sits in the middle
+of the screen"). When a GDD has such mockups (a `.phone` or `[data-mockup]` element in any page under
+`design/`, the first look's `hud.html` first), `funtools playtest` renders each as an element
+screenshot and pairs it with the game's same screen, captured through a view at phone size in touch
+mode (the GDD's `| Screen | Mockup | Game frame |` row names the view; a HUD pairs with the play
+view). A still auto-presses a screen that waits for input, so a screen that waits is opened through
+a view, never reached by a capture pressing on.
+
+Pictures count as mockups too: the style bible's `**HUD target:**` and `**Title target:**` lines
+(skill `funpixel-art`, ui.md) and a GDD mockups row naming an image pair with the play and
+title views, carrying the bible's `## UI` section as their words. The seat also reads `look --hud`'s
+dressing facts (system type, dark neutral plates, the scaffold's own glyphs, icons typed as
+characters, a plain wordmark), and
+judges the title as a player meets it: look, readability and whether it makes one want to press
+Play, beside the genre hit's opening when a still named `title` or `opening` is in its evidence.
+
+After the blind round, `playtest experience` also writes the UI seat (`panel/fidelity-ui.md`): the
+screens' words and numbered elements, the plan's interface rules, the image pairs, and the blind
+phone player's round as play facts, because UX is how it plays (a goal the player could not find,
+a dodge never taught). Per screen it scores ui (layout, what sits on the character against the
+glass, sizes, the visual language) and ux (does it work as intended); each numbered element held,
+partly or missing; what the game adds that the plan does not have, and whether each serves or fights
+the plan's rules; then UI and UX fidelity and five changes. The report puts them beside the art
+seat's scores and ranks the changes, a missing planned element first. On that game's two mockups
+it gave UI 5 and UX 4: of 15 planned elements 3 held, 8 partly and 4 missing, and four additions
+(a tutorial line at top centre, a permanent minimap) fought "nothing sits in the middle".
+
+## Reading the result
+
+The report puts art direction and creative direction beside the last round, each rule's state, and
+ranks the seat's changes among the next steps (a broken rule first). A low creative score with a
+held look usually means the moment was shot at the wrong time or the frame's subject is missing;
+fix the view or the moment before the art. When three of our games were judged against their
+single target frame, one kept its palette and lantern design (art 8) but lost the wheel of
+lanterns and the visible chain (creative 6); another built the target's set but not its round felt
+critters or the squish (5 and 3, AD-1 broken).
+
+## After a greenlight lock: reference-match rounds
+
+When `design/greenlight/lock.json` exists (skill `funpixel-gdd`, the greenlight), the seat reads the
+style bible's locked target table first, its facts name the locked version and anything changed
+since, and its brief gains `panel/reference-match.md`: compare the establishing view first, then
+the player's view, and list the biggest differences between the accepted pictures and the running
+game, each with the one change that closes it. Those targets cleared the genre hit before any code,
+so a large gap here is the build falling short of its own plan, not the plan's taste.

package/plugins/cursor/skills/funpixel-verify/references/hit-bar.md

@@ -0,0 +1,31 @@
+# Comparing a slice against a genre hit
+
+Use this when the person asks for the stronger bar. A short, satisfying loop can be compared
+fairly without promising a commercial game's content volume. Pick a named genre hit and state
+which skill and device the comparison covers before judging. The internal 6.0 overall / 7.0 look
+floor is still useful; it does not certify this comparison.
+
+The provisional bands from the platform's HITS_CALIBRATION evaluation are:
+
+1. Overall and look-and-feel each within 0.5 of the chosen hit, using the same unanchored rubric.
+2. Fun and juice each within 1.0 of it. Stills only partly observe these: add actual play and
+   matched motion evidence, and report what the reviewer could not observe.
+3. Order-normalized head-to-head win rate at least 0.375, with the player seat winning or tying
+   at least one pair. Use phone against phone when the hit ships there; otherwise desktop against
+   desktop. This is not a raw count of wins in eight calls.
+
+Keep the supplied platform evaluator's normalization unchanged and record its inputs and result.
+If that evaluator is unavailable, keep both presentation orders and raw seat verdicts, mark the
+normalized criterion uncomputed, and do not invent a pass. These thresholds came from a small
+calibration set and need further validation; disclose that in the review.
+
+Use like-for-like evidence: a normal playable moment against a normal playable moment, comparable
+viewport, duration and UI visibility. No trailer against raw gameplay. Seat reviewers blind to
+who made each game. Separate appearance findings from directly observed controls and rhythm.
+Do not show other seats' scores or the target score to a reviewer before its verdict.
+
+Keep each round's source fingerprint, captures, clip paths, player report, reference, rubric,
+seat verdicts and normalized result. Fix the highest actionable difference, then rebuild and
+repeat the same protocol. At the fix-round limit, report the shortfall and the next concrete
+change; never lower the bar to make a green badge. The person's own play session remains a
+separate acceptance step, recorded only when it happens.

package/plugins/cursor/skills/funpixel-verify/references/journeys.md

@@ -0,0 +1,77 @@
+# Journeys: the real controls, replayed
+
+A scene in `__FPX_VIEWS__` reproduces a state; it says nothing about whether a player can reach
+it. A journey is the other half: what a player does from the visible start, through the real
+controls, kept as a script that replays on the same seed and the same screen size, so two runs can
+be set side by side. OpenAI's Astra write-up keeps the two apart for this reason, and our own games
+show why: a staged victory passed every check while the real Play button did nothing (the front
+door: Sonnet pressed it in 1 of 72 lab sessions).
+
+## The script
+
+`test/journeys/<name>.json` (a test, kept with the game):
+
+```json
+{ "name": "first-win", "viewport": "phone", "seed": 1,
+  "steps": ["mark start screen=title", "tap 0.5 0.62", "wait 800",
+            "mark playing screen=playing", "drag 0.3 0.8 0.7 0.8 400", "wait 2500",
+            "mark first-score score>0", "tap 0.5 0.5", "wait 20000", "mark round-end screen!=playing"] }
+```
+
+- Steps are `funtools play`'s: `tap X Y`, `drag X1 Y1 X2 Y2 ms`, `hold X Y ms`, `hold KEY ms`,
+  `press KEY [n]`, `wait ms`, and `A & B` for two fingers at once, or a key held under another
+  (`hold ShiftLeft 1500 & hold ArrowRight 1500`, a held run; modifiers go down first), and
+  `look DX DY [ms]` (the mouse moved with no button: a camera look, also under pointer lock). A decimal
+  from 0 to 1 is a fraction of the screen, a whole number a CSS pixel. A phone takes touch only.
+  play's `hold … until` / `wait until` are not journey steps: `from-play` writes each as the fixed
+  hold or wait it took in the round.
+- `view` and `verb` are refused: they reach a state without the controls, which is what a scene
+  is for (`funtools capture --view`).
+- `mark NAME` is a checkpoint: the game's clock is held, the frame kept and `__FPX_STATE__` read.
+  Each `field=value` after the name is an expectation (`=`, `!=`, `>`, `<`, `>=`, `<=`; `player.x`
+  and `enemies.length` reach inside). A mark with no expectation still keeps its frame and counters.
+- `seed` is set as `window.__FPX_SEED__` before the game's code runs. The scaffold's rounds read
+  it; a game that draws from `Math.random()` or the clock replays differently each time, and the
+  noise run below shows how much.
+
+## Three ways to get one
+
+- `npx @funpixel/tools journey record <name> --viewport phone`: a window opens on the built game;
+  play it; close the window. Your taps, drags and keys become steps with the waits between them,
+  and each screen `__FPX_STATE__().screen` reaches becomes a mark expecting it. A drag replays as a
+  straight line; presses that overlapped replay one after the other (say it by hand with `&`).
+  This is the one a person makes: the creator's own path through the game.
+- `npx @funpixel/tools journey from-play last <name>`: the blind player's round (`funtools play`)
+  up to its first `view`/`verb` jump, with a mark after each act expecting the screen the player
+  saw. The player's clock was held while it thought, so marks can land earlier in game time.
+- Written by hand, when you know the path (a tutorial, the first level's solution).
+
+## Replay and compare
+
+`npx @funpixel/tools journey replay <name>` loads the game as a player finds it (no hook called),
+plays the steps and judges each mark. Exit 0 every expectation held, 1 a step or an expectation
+failed, 2 nothing judged (no expectation, or no state to read), 3 error. The run is kept in
+`.funtools/journeys/<name>/<n>/` and set beside the previous one: how much of each mark's frame
+changed, which counters moved, which expectations flipped. `--repeat 2` plays it twice on one build
+first: what differs between those two runs is noise, and a later difference smaller than that is
+not a finding. `journey diff <name> 3 7` compares any two runs; runs with another seed, viewport or
+script are named "not the same test".
+
+## When it helps
+
+- **Before and after a change to the title, menus, input, audio unlock or level flow**: replay the
+  journey that crosses it. A broken start shows as the first mark that did not reach its screen.
+- **A balance or feel change**: the counters at each mark (score, lives, enemies alive, time) on
+  the same seed say what moved; the frames say whether it shows.
+- **A regression the blind player found**: `from-play` keeps its exact path; after the fix, the
+  replay's marks should pass where the round was blocked.
+- **Phone layouts**: a phone journey presses the on-screen controls a thumb would; a key-only path
+  cannot pass there.
+
+`funtools feel --journey <name>` plays a journey's steps with every frame's state traced: the
+verb's numbers, tells, the death beat and looks by state along a player's real path (skill
+`funpixel-game-feel`, `references/measure.md`).
+
+What a journey does not prove: that the game is fun, readable or good to look at. It proves a path
+still works and says what changed along it. Frames from a software renderer are not a phone's
+performance (`funtools profile` says the same).