@genex-ai/cli-demo 0.93.0 → 0.94.0-dev.250

package/templates/skills/genex-game-director/SKILL.md

@@ -1,430 +1,340 @@
 ---
 name: genex-game-director
-description: The Genex game director — the entry point for every Genex build. Checks what your environment can do, writes the DESIGN.md design contract, routes any new-game, feature, or component request to the right Genex skills in the right order, and fans independent modules out to your sub-agents when you have them. Load first for any game work, or when unsure which skill applies.
+description: The lightweight Genex request router. Read the latest game, tool, component, or focused-change request; ask only genuinely unresolved build forks; keep DESIGN.md current; and load only the Genex skills that the requested work actually needs. Use first for new work, resumed work, or whenever ownership is unclear.
 ---
 
 # Genex Game Director
 
-Own the end-to-end outcome: a finished, playable, good-looking game — not a
-tech demo that boots. You are the director; the other Genex skills are your
-specialists. Load only the skills that change the result; never the whole
-pack by default.
+The player chooses what to build and in what order. You route that request;
+the owning Genex skills control how their lanes run. Load only skills that
+change the requested result—never the whole pack by default, and never
+commission unrelated work because an old workflow listed it.
 
-**After ANY context compaction or session resume**, re-read the game's
-`AGENTS.md` (the Genex build contract block), `DESIGN.md`, and the skill for
-the stage you are executing — never keep building from memory alone. A
-compaction that eats the conversation does not release you from the
-pipeline; those two files are how it comes back.
+**After any context compaction or session resume**, re-read the project's
+`AGENTS.md`, `DESIGN.md` when present, and the skill for the work you are
+executing. Then follow the player's latest clear request; do not reconstruct
+the project from memory or replay completed discovery.
 
-## 1. Check what you can do (once, before planning)
+## 1. Check capabilities and boundaries once
 
-Look at your own tool list and note the answers — the rest of this workflow
-uses them:
+Look at your available tools:
 
-- **A question tool?** Something that asks the player a structured question
-  with clickable options. If you have one, use it wherever this workflow says
-  "ask"; if not, a short numbered list in plain chat.
-- **Sub-agents?** A way to hand a scoped task to a background worker. If you
-  have them, delegation (§6) is your default for independent modules; if not,
-  do the same work yourself, in the same order — nothing else changes.
-- **A browser?** If you can open pages and take screenshots, verify visuals
-  yourself; if not, ask the player to look and tell you what they see.
+- **Question tool:** use it only when this skill says a real unresolved fork
+  remains; otherwise continue. Without one, ask one short plain-language
+  question in chat.
+- **Sub-agents:** useful for independent workstreams in a whole coordinated
+  build; never required for focused work.
+- **Browser:** use it to inspect the actual result. Without one, ask the player
+  for the smallest useful visual observation.
 
-Never claim a capability you didn't find, and never stall because one is
+Never claim a capability you did not find, and never stall because one is
 missing.
 
-One more thing to note while you're looking: your platform may bundle its own
-image / video generation workflows AND its own site-building / hosting /
-deploy skills. **None of them are part of any Genex lane — don't load them
-for this project.** All generated art, audio, video, characters, and UI come
-from `genex` commands, unless the player explicitly asks for another tool by
-name — and a local reference image is never a reason to switch tools:
-`genex image --edit` and `--inpaint` take a local file path directly. The
-same exclusivity covers shipping: the game builds, previews, and publishes
-only through `genex preview` / `genex publish` — a platform hosting skill in
-context is pure confusion fuel.
-
-## 2. Scope check — what is this?
-
-- **A new game** → the full flow: contract (§3), teams menu (§4), build order
-  (§5), delegation (§6).
-- **A feature or fix for an existing game** → read the game's `DESIGN.md` if
-  present (keep it current as you work; create a stub if it's missing and the
-  change is big), then load just the skills the
-  [routing map](references/routing-map.md) names for the touched systems.
-  Read before writing: learn the current renderer choice, physics setup, and
-  file conventions first, then extend them — don't rebuild working systems or
-  switch renderers mid-project.
-- **A component or tool** — a custom controller, a shader, an asset-pipeline
-  piece → skip the contract; route straight to the matching skills via the
-  routing map. Mostly we build games, but nothing here breaks for
-  game-adjacent work.
-
-## 3. The design contract — DESIGN.md
-
-**First, the design interview — before DESIGN.md is written.** Ask the
-player 2–4 build-forking questions, batched in ONE round — use your
-structured question / ask tool if your harness has one, with answer options
-for the user. Ask only what genuinely forks the build:
-
-- the one-line pitch, confirmed or corrected ("a co-op scythe hunt in a
-  ruined cathedral — right?");
-- the solo / co-op / versus shape (it decides netcode and scope);
-- scope ambition, when the request could honestly be read small or large
-  (compact arena vs. open world);
-- any real ambiguity in the request itself.
-
-Never ask about SDKs, engines, renderers, file layout, or anything
-technical — those are your decisions. **The silence fallback applies only
-AFTER the questions have been posted in chat.** A request that already names
-the game does not skip the interview — then it's the confirm-pitch round.
-Asking is never optional; waiting is: if the player is silent or has no way
-to answer, proceed on your own stated assumptions and write each one into
-DESIGN.md → Decisions as "assumed — player didn't answer"; the build never
-stalls on the interview.
-
-Then, before rendering code, write `DESIGN.md` at the project root from
-[references/design-contract.md](references/design-contract.md) — including
-its **Build plan & status** section: numbered milestones, a status mark per
-line, and a `Now:` line naming the current one. While drafting it, make the
-parallel call per module (dependencies decide — see §6) and write each call
-into the Modules table with its one-line reason. The moment the file lands,
-post a 5–6 line summary of the contract in chat — pitch, core loop, content
-counts, screens, multiplayer shape, what you build first — **and say in one
-plain line that the plan is locked in and lives in `DESIGN.md`** (the player
-must never have to wonder whether the contract happened). Then keep building
-immediately: the summary is information, not a gate (the plan-message duties
-from `$genex-threejs-game-ui` fold into this file plus that summary). The
-file is the single source of truth: sub-agents build against it, after any
-long break or context compaction work resumes from its `Now:` line, and a
-milestone flips to done only when its work reached a preview
-(`→ previewed`). Keep it current — decisions land in its log the moment
-they're made.
-
-## 4. Know your teams — what we can generate
-
-Plan the DESIGN.md Assets table from this menu. Details, flags, and approval
-steps live in each owning skill — load it when its lane fires:
-
-- `npx genex model "<prompt>"` — a real 3D thing (GLB): what you chase,
-  drive, fight → `$genex-ai-model`
-- `npx genex texture "<prompt>"` — any surface bigger than a prop
-  (`--terrain` for ground) → `$genex-ai-texture`
-- `npx genex skybox "<prompt>"` — a described 360° sky when the game is
-  outdoors → `$genex-ai-skybox`
-- `npx genex sfx "<prompt>"` — the core verb and every impact →
-  `$genex-ai-sfx`
-- `npx genex music "<prompt>"` — ONE looping instrumental gameplay track
-  (~90 s default; the menu reuses it quieter; settings gets Music + SFX
-  sliders) → `$genex-ai-music`
-- `npx genex voice "<line>"` — short spoken lines: NPC barks, narrator
-  beats, tutorial VO (curated cast via `--voice`; keep lines short,
-  subtitled, skippable) → `$genex-ai-voice`
-- `npx genex image "<prompt>"` — posters, signs, sprites, decals, HUD art
-  (`--transparent` for anything laid on a surface; `--glass` for real-
-  translucency glass panels) → `$genex-ai-image`,
-  `$genex-ai-hud`
-- `npx genex video "<prompt>"` — in-world screens and billboards (`--loop`
-  for a seamless in-world loop) → `$genex-ai-video`; the animated menu
-  backdrop is its own lane — `$genex-ai-menu`'s `--frame` flow, never `--loop`
-- `npx genex character "<prompt>"` — the game's themed character (approval
-  flow — §7) → `$genex-ai-character`
-- `npx genex creature "<desc>"` — a rigged enemy/creature in one shot
-  (biped-shaped bodies only — the creatures skill routes the rest to
-  static + procedural) → `$genex-threejs-creatures`
-- `npx genex controller character|car|drone|touch|quality` and
-  `npx genex animations search "<intent>"` — ready-made, tuned movement and
-  motion; never write movement physics from scratch →
-  `$genex-threejs-character-controller`,
-  `$genex-threejs-vehicle-controllers`, `$genex-threejs-touch-controls`,
-  `$genex-threejs-adaptive-quality`
-
-Run the commands inside the project (the `@genex-ai/cli-demo` dev dependency
-makes `npx genex` resolve to the right CLI). Each prints a permanent
-`assets.genex.technology` URL you load straight from at runtime — the asset
-lives in Genex storage, not your repo, so there's nothing to commit; each
-owning `genex-ai-…` skill has the exact loader code. Prefer the procedural skills in
-the routing map for abstract/parametric/animated systems (no files, infinite
-variation); prefer these generators for concrete, describable, photoreal
-assets — they complement each other. Assets you didn't plan don't exist: if
-the menu has a lane this game needs, put a row in the Assets table.
-
-**No eternal `proposed`.** At every preview and publish, walk the Assets
-table and resolve every `proposed` row — promote it to `planned` (and
-enqueue it when its turn comes) or cancel it, saying which in one visible
-line ("cancelled: UI hover sfx — out of scope for v1"). A row parked at
-`proposed` across a whole session is a decision you didn't make.
-
-**Generate a core asset set by default — don't wait to be asked.** For any
-game that needs concrete objects or surfaces, decide a small core set from the
-game IDEA — and from the Content lines when there are any (locations and the
-enemy roster name the set) — and put it in the Assets table up front. This set
-is concept-INDEPENDENT (prompted from the idea, not the concept image, and it
-mostly survives a style change), so it never waits on the concept at all. Each
-`npx genex` job is an independent ~1-minute render: launch them concurrently
-in the background (`--no-wait`), scaffold the scene while they run, and wire
-each in as it lands, with a procedural placeholder until then:
-
-- the **hero model** the player controls or chases (`npx genex model`),
-- one key **texture** for the ground/main surface (`--terrain` for ground),
-- a **skybox** when the scene is outdoors,
-- a **sfx** or two for the core action and its feedback,
-- one looping **music** track for the gameplay bed (`npx genex music`,
-  ~90 s; the menu reuses it at lower volume).
-
-Skip generation only for purely abstract/geometric games. For three.js
-questions no skill covers, use the official three.js documentation
-(https://threejs.org/docs/) — the skills cover the Genex-specific parts, not
-the whole engine.
-
-## 5. Build order — the same hard floors, one owner
-
-The mandatory rows, in order, each with its one "done when" line:
-
-1. **Identity first** — load `$genex-threejs-embed-auth` unconditionally,
-   every game (multiplayer or not), before any boot code. Done when:
-   `initEmbed(...)` runs at the very top of boot and the right gate
-   (`waitForPlayer()` vs `waitForAuth()`) is wired.
-2. **Adaptive quality at boot** — `$genex-threejs-adaptive-quality`. Done
-   when: the device tier is wired at boot (tier-capped pixel ratio), the
-   governor runs in the loop, and generated skyboxes/textures load through
-   their rungs. Phones enforce a hard GPU-memory kill desktop testing never
-   shows; the tier is what keeps a phone boot alive.
-3. **UI plan gate** — `$genex-threejs-game-ui`, every game: the screen
-   inventory, one shared style brief, 2–3 AAA references, the menu archetype,
-   then ONE concept image with its full HUD already on it (no candidate
-   variants unless the player asks). **The moment it lands: decide the HUD
-   lane (the lane beat below), enqueue the Stage-2 sheet + the menu still +
-   the logotype `--no-wait` IMMEDIATELY, and only THEN show the player the
-   frame and ask keep-or-change with your question tool — as information,
-   never as a gate.** Silence = the concept stands; a "change" answer loops
-   the concept with the player's notes and the chain re-runs from the new
-   frame (image-priced — cheap by design). Only the menu VIDEO waits, for
-   the FIRST of: the player's yes · the next `genex preview` after the menu
-   still landed · style work being the only work left — and it never fires
-   while a player objection is open. Done when: the sheet, still, and
-   logotype are enqueued and the frame is in front of the player.
-4. **Content contract when the request names plural content** — quests,
-   enemies, bosses, locations, spells, items, or a content genre (an RPG, an
-   adventure, an open world, a story game) — `$genex-threejs-game-content`.
-   Its countable lines live in DESIGN.md's Content section, written before
-   the asset batch (the asset set derives from it). Done when: every plural
-   noun of the request has a countable line. Shrinking one is a question to
-   the player, never a silent cut.
-5. **Route the rest** via [references/routing-map.md](references/routing-map.md):
-   the smallest useful skill set, the execution order, the visual-direction
-   gate (renderer baseline + named post stack), and the world-dressing
-   decision. Done when: DESIGN.md names the chosen skills and gates.
-6. **Multiplayer when 2+ players share a world** — `$genex-threejs-multiplayer`
-   before any networking code. Choose the net model from the experience
-   (`connect()` for one ongoing drop-in world, `matchmake()` for fresh capped
-   matches) — never ask the player to pick an SDK API. When a Play/Online
-   button exists, nothing connects before the click. A `matchmake()` game
-   declares its `genex.matchmaking` block before preview. Done when: the
-   model, start rule, and late-join behavior are stated in DESIGN.md and the
-   netcode feel gate ran before handoff.
-7. **Ship the playable v0 and preview it.** The scaffold prompt owns the
-   player-facing milestones and links — don't restate them; obey them. Done
-   when: the v0 loop is genuinely playable and the player has their draft
-   page link.
-
-**The HUD lane — the concept decides it, and DESIGN.md records it.** You
-make this call as the art director the moment the mockup lands: ornate /
-painterly / material widget chrome (carved bone, etched metal, glowing
-runes, brushed gold) → **sprites** — the `$genex-ai-hud` pipeline is
-mandatory. Chrome that is flat geometry + typography, where a CSS rebuild
-would be screenshot-indistinguishable from the mockup → **CSS allowed**,
-styled from the brief. The litmus test: would a screenshot of the CSS
-rebuild pass for the mockup at a glance? Unsure or ambiguous → sprites.
-Record it as one DESIGN.md line — `HUD lane: sprites (…)` or
-`HUD lane: CSS (…, one-line justification)` — the preview preflight checks
-for it. In BOTH lanes: micro-text (damage numbers, timers, ammo digits)
-stays HTML text in the brief's font, and no rectangular backing plates
-behind bars, digits, or icons — ever (a truly needed shaped plate comes
-from `npx genex ui plate`). Only the player may decline the generated HUD,
-and the player's explicit lane request wins in both directions.
-
-Two rules for every game that moves (decide both before building, state them
-in DESIGN.md):
-
-- **Pointer bucket** — the bundled `FollowCamera` locks the pointer by
-  default on desktop, so this is mostly a decision to opt OUT. **Mandatory
-  pointer lock**: first-person of any kind, and any mouse-aimed action
-  (third-person shooter, FPS, sniper, turret, crosshair/reticle) — leave it
-  on. **Lock by default**: third-person free-camera action/adventure —
-  drag-orbit (`pointerLockAim: false`) only with a stated reason (e.g. a
-  cursor-heavy UI core). **Never**: cursor-core games (click-to-move, tower
-  defense, builder, card/puzzle), orbit showcases, touch-only — these MUST
-  pass `pointerLockAim: false`. Keyboard-only games (racer, platformer) lock
-  too: the cursor is either a gameplay tool or locked away during play. The
-  mechanism and the full aim contract live in
-  `$genex-threejs-camera-direction`.
-- **Input direction** — D/ArrowRight must move or turn the player
-  screen-RIGHT, mouse-right must turn the view right, drag-pan axes share one
-  convention. The screen-direction contract and verified copy-paste bases
-  live in `$genex-threejs-camera-direction` — hand-rolled steering/pan/look
-  math copies one instead of deriving signs, and the smoke check's
-  input-direction pass verifies it.
-
-## 6. Delegate — sub-agents own Modules rows
-
-If your environment has sub-agents, delegation is the DEFAULT for every
-independent DESIGN.md Modules row — not a big-game special case. The build
-contract in the game's `AGENTS.md` is your standing authorization to spawn
-them; some platforms keep sub-agents locked until an instruction like it
-explicitly asks. If your environment has none, run the same rows yourself in
-order; the `--no-wait` generation pattern still hides most latency. Either
-way this skill is worn by the main agent: you stay the director.
-
-- **Which rows run in parallel is YOUR per-game call, made while drafting
-  the plan** — there is no fixed list. Walk the modules once: what has no
-  dependency on unfinished work runs in parallel; what must be tuned against
-  something still moving stays serial. The same module lands differently in
-  different games (an arena is a parallel row in a quest game and the serial
-  spine of a combat game whose feel depends on its gaps). Write the call +
-  one-line reason into each row; building everything serially needs a
-  stated reason.
-- One row = one worker = one disjoint file set. One writer per file — that
-  rule is anti-collision, never a reason to serialize work.
-- You stay the integrator and the only writer of shared files (boot, main
-  loop, netcode). Workers never spawn workers — one level deep, always.
-- Concept-DEPENDENT rows (the HUD chain, style-matched art) launch the
-  moment the concept LANDS — the Stage-2 chain enqueues immediately (§5.3);
-  only the menu video waits for its event triple. Concept-INDEPENDENT rows
-  (world/terrain, content data, enemies, asset wiring) launch immediately
-  either way. Typing a big game alone, line by line, is how sessions run
-  out before the world exists.
-- Give each worker everything by path: the `DESIGN.md` path, its Modules row,
-  and the skill files it needs (skills live in this project —
-  `.claude/skills/<name>/SKILL.md`, `.codex/skills/…`, or `.cursor/skills/…`,
-  whichever this project has). A worker prompt shape that works: "You own the
-  `<row>` module of `<project>/DESIGN.md` — read it first, then read the
-  named skill files. Build ONLY the files your row owns. Generate ONLY your
-  row's assets already marked `planned` in the Assets table; anything new you
-  need, add it as a `proposed` row and say so. Report what landed and what's
-  left."
-- **The Assets table is the budget.** A worker runs generation commands only
-  for its own rows already marked `planned`; anything new it wants goes in as
-  a `proposed` row for you to approve first. An asset-shepherd lane polls
-  `npx genex wait --all` and wires + flips landed rows to `wired` — it never
-  enqueues. (Whoever wires the HUD after a worker finishes follows
-  `$genex-ai-hud`'s handoff rule: read the produced mask/bbox JSON from disk,
-  never wire from a prose summary.)
-- Do NOT spawn workers to write extra test suites, audits, or verification
-  passes — the per-milestone smoke pass is yours, the director's, and it is
-  ONE pass (§8; the scaffold prompt owns the ceilings).
-- If you build a module the table planned for a sub-agent inline, say why in
-  one line in chat ("built enemies inline — the arena worker was still
-  holding the only free slot"). The table is accountability, not ceremony —
-  inline can be the right call.
-
-## 7. The game's character (Meshy) — the player's body
-
-**The game's own generated character IS the player's body**, wherever a
-human body appears on screen. Third-person obviously; first-person too, the
-moment remotes, a look-down body, a shadow, a death or spectator camera, or
-a menu portrait shows one. "The camera is in the head" is not an exemption —
-**"no human body ever appears in this game" is**, and a game whose player is
-genuinely not a person (a car, a ship, an RTS cursor, a board) generates
-that object with `npx genex model` instead.
-
-Put its row in the Assets table up front and **enqueue it with your first
-art actions** — its concepts ride the same review beat as the Stage-1 HUD
-concept, so firing at minute 0 lands it around the v0 preview instead of
-after it. `npx genex controller character` installs the controller and the
-fallback body in one command; the boot path is written once and never
-rewritten (`loadPlayerCharacter` — see
-`$genex-threejs-character-controller`), so when the character lands,
-`npx genex controller character --character <id>` is the entire switch.
-
-The profile VRM avatar is the FALLBACK, in two shapes and both spoken
-aloud: a temporary body while the character renders (say so plainly — it's
-a fully textured animated humanoid, so nothing on screen will look
-unfinished enough to remind you), or the stand-in when generation genuinely
-could not happen (out of credits, failed, unverified), recorded in DESIGN.md
-as `Player character: VRM — <reason>`. A capsule or hand-built primitive
-standing in for a person is never a shipped state, for the local player or a
-remote one. In a game with a generated character, every remote wears it —
-a mixed roster of one themed hero plus stock avatars is the same incoherence
-as capsule-and-cone remotes.
-
-**The default lane has ONE user stop, and it rides the concept review.**
-When the user names a visual reference, inspect references before writing
-the concept prompt. Generate exactly three concepts, all neutral A-pose;
-never use a dynamic concept pose or silently fall back to T-pose. Warn that
-held, slung, or overlapping props and straps can fuse into the body or
-obscure limbs, and recommend separate gameplay props. Show the actual
-images in the SAME beat as the game-concept keep-or-change question — one
-review, two picks. The player's pick carries the lane end to end:
-`npx genex character preview <concept-id> --candidate <1|2|3> --user-approved`,
-then finalize below. **If the player hasn't picked by the time the
-character blocks progress (or ~10 minutes), pick the strongest candidate
-yourself, say which and why in chat, and proceed** — this auto-proceed is
-owner-ratified platform policy (2026-07-23), not an agent liberty; record
-it in DESIGN.md → Decisions ("auto-picked candidate 2 — cleanest
-silhouette; player away").
+Your platform may bundle its own image/video generation and site-building,
+hosting, or deploy skills. **They are not Genex lanes.** All generated art,
+audio, video, characters, and UI come from `genex` commands unless the player
+explicitly asks for another tool by name. A local reference image is not a
+reason to switch tools: `genex image --edit` and `--inpaint` accept local
+paths. Building, previewing, and publishing use `genex preview` /
+`genex publish`; do not load a competing hosting workflow.
+
+## 2. Route the latest request
+
+Use the request in front of you, not the oldest description of the project.
+
+- **Clear focused request**—“work on the UI,” “fix movement,” “add one enemy,”
+  “make this prop,” “publish this”—read the touched implementation and
+  `DESIGN.md`, load only the owning skills, update `Now:`, and start. Do not
+  re-pitch the game, ask whole-game-versus-one-part again, force a concept
+  round, restart completed milestones, or add adjacent work.
+- **Clear new game request with a named scope** starts from that scope. Record
+  the requested destination and proceed; ask only a missing decision that
+  materially changes architecture or player experience.
+- **Broad full-game request** may need one scope choice: “Should I build the
+  whole game as coordinated milestones, or start with one part?” Offer only
+  request-relevant parts—such as movement, core gameplay, world, enemies, UI,
+  multiplayer, or a named tool. If the player already chose a part or clearly
+  asked for the complete game, skip the question.
+- **Blank or genuinely unclear intake** asks one neutral question: are they
+  making a game, building a tool/component, or changing existing work? Do not
+  invent or propose game concepts for them.
+- **Existing project** respects its renderer, physics, file conventions, and
+  working systems unless the player asks to change them.
+
+Ask one decision at a time. Never ask the player to choose an SDK, engine,
+renderer, file layout, provider, or other implementation detail. Product
+defaults fill missing implementation choices; they never override a clear
+request.
+
+The player's latest direction may replace `Now:` immediately. Preserve
+unfinished requested work as open commitments unless the player cancels or
+re-scopes it; focused work changes the current order, not historical truth.
+
+## 3. Keep DESIGN.md as durable memory
+
+For a new project or substantial multi-step request, create `DESIGN.md` from
+[references/design-contract.md](references/design-contract.md). For existing
+work, update only the sections touched by the latest request. A tiny focused
+fix does not need unrelated sections filled in.
+
+The file keeps three truths separate:
+
+1. **Requested outcome**—the player's final target, changed only by the player.
+2. **Current focus**—the exact `Now:` item and its observable done condition.
+3. **Open commitments**—requested work not completed, cancelled, or re-scoped.
+
+Also record the working mode: `whole coordinated build`, `step by step`, or
+`focused change`. Step-by-step changes order, not destination. The build plan
+is current, never “locked”; tell the player only that their request is recorded
+in `DESIGN.md` and you will keep it current.
+
+Preserve the exact markers used by existing machinery: `## Build plan &
+status`, `Now:`, `HUD lane:`, `Menu video:`, HUD pipeline stage IDs and paths,
+`Player character:`, generation IDs and permanent URLs, and asset wiring
+state. The paid Assets flow remains:
+
+`proposed → planned → generating (id) → landed (URL) → wired`
+
+A landed asset is not complete until wired or visibly cancelled. Procedural
+code-built assets use their own local flow:
+
+`proposed → planned → building (blockout | detail | material | runtime) →
+landed (<local TypeScript path>) → wired`
+
+Never invent a provider generation ID for local code. Sections for gameplay,
+content, UI, world, assets, multiplayer, character/animation, tools, or
+modules are conditional on the request and existing project.
+
+## 4. Route to the owning lane
+
+Use the [routing map](references/routing-map.md) for exact ownership. The main
+Genex asset and runtime lanes are:
+
+- `npx genex model "<prompt>"`—a static GLB → `$genex-ai-model`
+- `npx genex texture "<prompt>"`—a generated surface → `$genex-ai-texture`
+- `npx genex skybox "<prompt>"`—a 360° environment-only sky →
+  `$genex-ai-skybox`
+- `npx genex sfx "<prompt>"` / `music` / `voice` →
+  `$genex-ai-sfx`, `$genex-ai-music`, `$genex-ai-voice`
+- `npx genex image "<prompt>"` / `video`—2D and motion art →
+  `$genex-ai-image`, `$genex-ai-video`
+- UI, HUD, and menu requests → `$genex-threejs-game-ui`,
+  `$genex-ai-hud`, `$genex-ai-menu`
+- `npx genex character`, `creature`, and their motion commands →
+  `$genex-ai-character`, `$genex-threejs-creatures`
+- movement and vehicles → `$genex-threejs-character-controller`,
+  `$genex-threejs-vehicle-controllers`
+- phone input and phone-survivable rendering →
+  `$genex-threejs-touch-controls`, `$genex-threejs-adaptive-quality`
+- editable, parameterized reference objects or simple environment pieces →
+  `$genex-threejs-procedural-assets`
+
+For “make this image 3D,” ask **one** route question only when both results
+honestly fit: a generated static GLB, or editable parameterized Three.js code.
+If the request says procedural, parametric, code-built, reusable variations,
+or names a GLB, start the corresponding route directly. An image alone never
+auto-triggers the procedural lane. Player bodies, rigged characters/creatures,
+and animation stay with their protected owners.
+
+If a procedural request has a private reference, use it locally and do not
+upload, publish, or commit it without explicit permission. If no reference was
+supplied and creating one is part of the requested work, use the existing
+`npx genex image` lane unchanged and record that paid reference as its own
+Assets row.
+
+Plan and generate only assets the current request earns. In a whole coordinated
+game build, derive the set from the requested outcome and commitments; in
+focused work, do not create a default “core set” outside the touched scope.
+Run independent planned generations with `--no-wait`, scaffold while they
+land, and preserve their IDs, URLs, and wiring state.
+
+## 5. Execute by working mode
+
+### Focused change
+
+Start directly. Read the touched files, preserve working systems, update the
+relevant `DESIGN.md` section and `Now:`, execute the owning lane, and verify
+the requested result. Skip unrelated discovery, module fan-out, UI/HUD
+concepts, asset batches, and critic loops.
+
+### Step by step
+
+Set `Now:` to the chosen request-relevant part and build it. Preserve the
+player's final requested outcome and every other unfinished promise under Open
+commitments. When the step is previewed, ask what they want next only if their
+latest message did not already say.
+
+### Whole coordinated build
+
+Turn the actual request into milestones and workstreams. The director may run
+independent work in parallel and move through internal milestones without
+asking the player to manage each one. Dependencies determine order; no fixed
+module list does.
+
+For every new game, preserve the platform foundations:
+
+1. `$genex-threejs-embed-auth` owns identity and runs before boot code.
+2. `$genex-threejs-adaptive-quality` owns device tiers, the runtime governor,
+   and generated-asset rungs at boot.
+3. `$genex-threejs-touch-controls` owns mobile input whenever its recipe fits.
+4. `$genex-threejs-multiplayer` loads before networking code whenever 2+
+   players share a world.
+
+Record only content and world promises present in the request or essential to
+its stated genre. Make them countable or otherwise observable before choosing
+the paid asset batch. A requested large/open world records its intended scale,
+terrain/ground, boundaries, and locations from the request; never silently
+replace it with one small flat plane hidden by fog or impose fixed kilometer,
+chunk, biome, or POI defaults. Generated-asset availability never decides how
+much game the player receives. Ask one scope question only when a real
+reduction is required.
+
+There is **no startup game, UI, or HUD concept gate**. Schedule UI/HUD/menu at
+the appropriate later milestone when the complete requested outcome includes
+those surfaces. Enter that lane immediately when the player asks for it, and
+skip it during unrelated focused work.
+
+### When the UI/HUD/menu lane is invoked
+
+The existing owning skills control the full pipeline. Do not simplify or
+bypass their FAL calls, credits, checkpoints, retries, Stage-1/Stage-2 prompts,
+extraction, masks, wiring, markers, nudges, or preflights.
+
+The Stage-1 mockup decides the HUD implementation and `DESIGN.md` records it:
+ornate/painterly/material chrome → `HUD lane: sprites (…)`; flat geometry plus
+typography that CSS can reproduce screenshot-indistinguishably →
+`HUD lane: CSS (…, one-line justification)`. Unsure → sprites. The player's
+explicit lane request wins. Once invoked, follow `$genex-ai-hud` and
+`$genex-ai-menu` exactly, including `Menu video:` and every HUD pipeline state
+marker.
+
+In both lanes, micro-text stays HTML text in the chosen font, and no generic
+rectangular plate appears behind bars, digits, or icons; a genuinely shaped
+plate comes from `npx genex ui plate`.
+
+### Controls that move
+
+For every game that moves, apply the screen-direction contract and record the
+pointer bucket and input-direction convention:
+
+- `$genex-threejs-camera-direction` owns pointer lock. First-person/FPS
+  shooters and other mouse-aimed action keep it; cursor-core games and orbit
+  showcases pass `pointerLockAim: false`; keyboard-only games lock the unused
+  cursor during play.
+- D/ArrowRight moves or turns screen-right, mouse-right turns the view right,
+  and drag-pan axes share one convention. Copy the verified bases from the
+  camera skill before writing hand-rolled signs.
+
+## 6. Coordinate only when coordination helps
+
+Whole coordinated mode may use sub-agents for independent, request-derived
+workstreams. Focused work skips fan-out unless the requested task itself has
+usefully independent pieces.
+
+- One worker owns one disjoint file set. The main agent remains the integrator
+  and only writer of shared boot, main-loop, and netcode files.
+- Give each worker the `DESIGN.md` path, its exact row, owned files, relevant
+  skill paths, and observable done condition. Workers do not spawn workers.
+- A worker generates only Assets rows already marked `planned`; new wants
+  enter as `proposed`. Whoever wires HUD output reads its mask/bbox files, not
+  a prose summary.
+- Do not create workers merely to write extra test suites or reports.
+
+For a substantial, judgeable result in whole coordinated mode, a **fresh
+critic may** inspect the actual game, rendered pixels, reference, or test
+result—not the builder's summary. It returns the single largest meaningful
+gap; the builder may address that gap and request another fresh look. This is
+permission, not ceremony: no fixed round count, progress site, per-round
+ledger, or user approval between internal rounds.
+
+Stop when the requested acceptance is reached, improvement becomes immaterial,
+the player redirects the work, or the available time/compute budget is spent.
+A critic may identify a protected or paid-lane problem, but may not bypass,
+rewrite, or automatically repeat that lane; follow-up still uses its existing
+approval, checkpoint, retry, credit, and verification behavior.
+
+## 7. The game's character (Meshy)—the player's body
+
+**The game's own generated character is the player's body** wherever a human
+body appears on screen. Third-person obviously; first-person too when remotes,
+a look-down body, shadow, death/spectator camera, or menu portrait shows one.
+“No human body ever appears” is the exemption—not “the camera is in the
+head.” A genuinely non-person player (car, ship, RTS cursor, board) uses
+`npx genex model` instead.
+
+When this lane is relevant, put its row in the Assets table and enqueue it
+when its milestone starts—or in parallel when whole coordinated mode makes
+that useful. Its asset-specific concept review is its own beat; it never waits
+for or requires a UI concept. `npx genex controller character` installs the
+controller and fallback body; `loadPlayerCharacter` keeps the boot path stable,
+and `npx genex controller character --character <id>` switches the manifest
+when the generated body lands.
+
+The profile VRM avatar is the fallback: a temporary body while generation
+runs, or the stand-in when generation genuinely could not happen, recorded as
+`Player character: VRM — <reason>`. A capsule or hand-built primitive is never
+a shipped human body. In multiplayer, every remote wears the generated game
+character when one exists.
+
+**The default lane has one user stop: the character concept review.** When the
+user names a visual reference, inspect references before writing the concept
+prompt. Generate exactly three concepts, all neutral A-pose; never use a
+dynamic concept pose or silently fall back to T-pose. Warn that held, slung,
+or overlapping props and straps can fuse into the body or obscure limbs, and
+recommend separate gameplay props. Show the actual images and wait for the
+player to explicitly select a candidate. Their pick carries the lane:
+
+`npx genex character preview <concept-id> --candidate <1|2|3> --user-approved`
+
+If the player has not picked by the time the character blocks progress (or
+~10 minutes), use the existing owner-ratified platform policy (2026-07-23):
+pick the strongest candidate, say which and why in chat, proceed, and record
+the decision in `DESIGN.md`.
 
 Meshy Image-to-3D first produces an unremeshed high-detail model. Show its
 front, back, left, and right views and report its measured face count.
-Preserve that model in R2. The 10,000-face triangle remesh—not the
-high-detail source—is rigged and animated. In the default lane the remesh
-proceeds on the same authorization as the pick (say it plainly: "building
-the 10,000-face rigging copy now"):
-`npx genex character finalize <preview-id> --user-approved --approve-remesh 10000 [--animation <action-id>…]`.
-Keep every pre-animation generation in the selected neutral A-pose.
-
-**When the user themselves asked for a custom character** (an explicit
-custom-character request, not the game default), the ceremony is two
-separate stops and the approvals are the product: do not start Image-to-3D
-until they explicitly select a candidate, and before rigging ask them to
-approve the separate 10,000-face triangle remesh — wait for that explicit
-approval before finalize. (`npx genex character "<prompt>" --direct-text`
-is the explicit legacy one-shot path, not a substitute for these
-approvals.)
-
-Load `$genex-ai-character`, search Meshy actions first with
-`npx genex animations search "<intent>" --json`, and use returned action IDs;
-never invent IDs. Meshy limb rotations play unchanged. Never freeze hand tracks
-or apply post-mixer arm, hand, leg, or foot corrections. Only horizontal root
-or hip translation may be normalized for Rapier. In both lanes, the
-ECCTRL-derived character controller owns collision and world translation.
-Before handoff, visibly check idle, walk, run, crouch-idle, crouch-move, and
-jump — shoulders, elbows, wrists, hands, both leg cycles, and feet — and press
-every control the HUD advertises.
-
-## 8. Verification — the smoke pass's captures grow with the build
-
-The per-milestone smoke pass and its ceilings belong to the scaffold prompt
-(ONE pass per milestone, never test suites, never re-verify after cosmetic
-tweaks) — this section only defines WHAT that one pass captures once the
-relevant piece exists:
-
-- **Always:** the gameplay screenshot + the main controls responding the
-  right way (the scaffold prompt's baseline).
-- **Once the generated HUD is wired:** take the gameplay screenshot AFTER
-  taking damage once, with an enemy in frame facing the player. A full-HP
-  shot cannot show a broken meter (a painted trough hides behind a 100%
-  fill), and an enemy you never faced head-on may be looking sideways at
-  everyone.
-- **Once the menu video is wired:** watch one full loop cycle as rendered
-  (`$genex-ai-menu`'s seam check). A metadata probe can't see a seam, a
-  hidden video, or a leftover panel covering it.
-
-Judge each capture against DESIGN.md once, fix only what is visibly broken,
-and move on — the captures are eyes, not a test suite.
-
-**Fresh eyes before publish.** The pre-publish check is just the last
-milestone's pass, plus this: take the game's current screenshots (desktop
-and phone sizes) and hand them, with DESIGN.md only, to a fresh reviewer —
-a sub-agent if you have one, otherwise re-read them yourself adversarially,
-looking to refute "it's done": untextured surfaces, a bare HUD, missing
-screens, Content lines not in the game, Assets rows never flipped to
-`wired`, `proposed` rows never resolved. Fix or honestly report what it
-finds; never publish over an unacknowledged gap.
+Preserve that model in R2. The 10,000-face triangle remesh—not the high-detail
+source—is rigged and animated. In the default lane, the pick authorizes that
+remesh:
+
+`npx genex character finalize <preview-id> --user-approved --approve-remesh 10000 [--animation <action-id>…]`
+
+When the player explicitly requested a custom character, keep the existing
+two stops: wait for candidate selection before Image-to-3D, then wait for
+explicit remesh approval before finalize. The `--direct-text` legacy path is
+not a substitute.
+
+Load `$genex-ai-character`, search actions with
+`npx genex animations search "<intent>" --json`, and never invent IDs. Meshy
+limb rotations play unchanged. Never freeze hand tracks or apply post-mixer
+arm, hand, leg, or foot corrections. Only horizontal root or hip translation
+may be normalized for Rapier. The character controller owns collision and
+world translation. Before handoff, visibly check idle, walk, run, crouch-idle,
+crouch-move, and jump, plus every control the HUD advertises.
+
+## 8. Verify in proportion to the request
+
+Focused work verifies the focused result and the owning skill's required
+evidence; it does not trigger a whole-project audit. A milestone preview uses
+one smoke pass after the preview, not a new test suite.
+
+- Always capture the relevant running result and exercise the changed control
+  or interaction in its labeled direction.
+- Once a generated HUD is wired, capture gameplay after a changing value
+  (such as damage) so masks/fills are visible.
+- Once menu video is wired, watch one full rendered loop using
+  `$genex-ai-menu`'s seam check.
+- Multiplayer uses the existing two-distinct-identity netcode feel gate.
+- Character/animation uses the owning lane's pose, clip, and controller checks.
+
+Judge evidence against the requested result and current `DESIGN.md`, fix
+meaningful gaps, and move on. An explicit preview or publish request runs the
+existing protected flow directly; report open commitments honestly rather
+than restarting design discovery.
 
 ## 9. Say it straight
 
-"Loaded" means you read a file. "Built" means the thing runs. "Done" means its
-"done when" line is true. Never report a skill as applied because you read it,
-an asset as wired because it generated, or a gate as passed because you meant
-to.
+“Loaded” means you read a file. “Built” means the thing runs. “Done” means the
+requested acceptance and relevant owning-lane checks are true. Never report a
+skill as applied because you read it, an asset as wired because it generated,
+or the full requested outcome as complete while Open commitments remain.