@homie-rocks/studio 0.48.4 → 0.50.0

package/guides/parts/SKILL.md

@@ -0,0 +1,158 @@
+---
+name: parts
+description: Studios build on each other with parts from games, apps, music and video that their owners choose to share or sell (a creature, a level generator, a chase camera, a bot brain, a pickup mechanic, an audio pack). Use this when planning or making games, apps, music or video (look for pieces before writing one from scratch), when the person asks what parts exist, says "use the X from that game", "make this reusable" or "share this", and before a game that uses parts goes online.
+compatibility: Node 22. Paid purchases need @homie-rocks/studio 0.37.2 or later. A studio made with @homie-rocks/studio; npm installs the packages a part builds on.
+---
+
+**Apps:** For a business, venue, cause or customer app, follow the `app` skill: `apps/<id>/app.json`, one morphing screen, roles and parts. Reuse these engines and workflows; do not impose game rounds, scores, bots, a game demo or page navigation. The app check proves shared actions and reconnect; app stores use the same standalone command.
+
+
+# Studio parts: games, apps, music and video
+
+A studio is the folder with `studio.json`. Studios build on each other with **parts**: reusable pieces of games, apps, music and video that their owners choose to share or sell. A creature from one game, a level from
+another, a bot brain from a third. Without parts you would have to come up with everything on your own.
+
+The rules, in full in `node_modules/@homie-rocks/studio/parts/PARTS.md`:
+
+1. Game and app lifting extracts a piece, **never the whole experience**. App components can also be lifted from `apps/<id>/`; music loops or tracks and video may be authored directly in `parts/<id>/`; their licence controls permitted use, including venue use.
+2. A part can take **any form** that suits the piece: code, assets, data, a JSON description, a tuned config, a mix.
+3. **Private until shared**: on purpose, with a licence (an SPDX identifier) and an attribution. A part records the
+   game and studio it came from.
+4. **Homie packages are not parts.** `@homie-rocks/*` packages are general mechanisms from npm. A part may say
+   which packages it builds on; npm installs them.
+5. **The person works in chat** and never types a command. Four tools: `parts_find`, `part_add`, `part_new`,
+   `part_share`.
+6. **You look for parts first.**
+
+There is no mash-up command: mashing up is making a game with parts from several games.
+
+## 1. Look first
+
+When planning or making a game, app, music or video, for each system it needs (camera, movement, bots, pickups, effects, sound, UI,
+environment, characters), before writing it from scratch:
+
+1. Check the `@homie-rocks/*` packages the studio has for the general mechanism.
+2. `parts_find` with the words for the piece (`"chase camera"`, `"cave"`, `"pickups"`), and `kind`, `tag`,
+   `license` or `builds` (a package or a skeleton it builds on) to narrow it.
+3. Tell the person what you found, a line each, **naming the source work and studio each piece is from**, with your pick.
+
+If the catalogue cannot be reached, the tool says so. That is not "nothing exists": say it could not be read, go on
+with what the studio has, and look again later. If it answered and nothing fits, write the piece.
+
+Record in the project notes or CODEX, under **Built from**, what came from where: the packages, each part with its game,
+studio and licence, and what you wrote from scratch and why.
+
+## 2. Use a part
+
+`part_add` with `"<studio site>/<part id>"` (as `parts_find` gave it; `@1.2.0` for one version) and the `game` option (a game or app id; omit it for standalone media). It
+fetches one exact version, checks every file's integrity before anything is written, copies it into the studio
+(the studio's to tune from then on), records where it came from, adds the credit to the game, and lets npm install
+the packages it builds on. Read what it answers:
+
+- **The import line**: `import … from '@parts/<studio site>/<part id>'`. Its `part.json` says what the piece takes
+  (`contract`) and who decides in a room; its `tuning.json` holds the values to tune.
+- **Packages**: npm's own words. If a package the studio already names does not fit, nothing was changed: tell the
+  person which part wants what.
+- **Other parts it names**: each with what adds it.
+- **Licences that cannot be combined** are said plainly. Tell the person before building on it.
+- **The credit** in the game's `credits.json`: keep it, whatever else changes.
+
+Adding the same part again later brings the newer version: it shows what changed and keeps `tuning.json`. A file
+the studio edited is not replaced unless you pass `overwrite`: ask the person first.
+
+Then build, and try it on two devices.
+
+## 3. Make a part
+
+After building a piece another game could use, offer it in one line: "The chase camera turned out reusable. Shall
+I make it a part, so your next game can use it? It stays private unless you ask to share it."
+
+`part_new` with `id`, `from` (the game or app) and `files` (the module or folder of that piece). The files are lifted out
+into `parts/<id>/`, the game imports them from there, and **the game still builds and plays the same**: build it
+and check. A file that reaches into the rest of the game is refused by name: pass what it needs in as an argument
+(a collision function, a palette, the room), then lift it. The game's own entry cannot be lifted: a part is never
+the whole game.
+
+Then fill `parts/<id>/part.json`: a one-sentence `summary`, tags, what it takes from a game (`contract`), the
+packages it builds on (`requires.packages`), its scale and skeleton if it has them, costs only if measured, a small
+`preview/index.html` that shows it, and its tunables in `tuning.json`.
+
+When the preview is something to play with, declare its shape in `preview`: `"aspect": "4:3"` and
+`"phoneAspect": "3:4"` (whole numbers 1 to 32, no flatter than 3:1, no taller than 1:2). The default is 16:9, which
+on a 390 px phone is a frame about 197 px tall: the controls fit and the demo under them is cut off, with no error.
+
+## 4. Share a part, only when the person asks
+
+Ask which licence (`CC-BY-4.0` for "use it, credit me", `CC0-1.0` for "no strings", `MIT` for code) and who to
+credit. `part_share` with `share: true`, `license` and `attribution`. It refuses in plain words when there is no
+SPDX licence, credit is owed and nobody is named, the part does not say where it came from, or the rights to a
+file are unknown (for example a model the studio bought): leave that file out or replace it, never work around it.
+`part_share` with no `share` only checks.
+
+It is **live after the studio's next deploy** (`studio_deploy`), not before: say so. Then the studio's site lists
+it and the catalogue on homie.rocks shows it if the studio is listed there. `share: false` stops it at the next
+deploy. A shared version never changes: a change needs a new `version`, then share again.
+
+## 5. Before a game that uses parts goes online
+
+The deploy plan (`studio_deploy` with `plan: true`) and the listing (`studio_publish`, and its `before: true`)
+show each part's licence and attribution and say plainly
+when licences cannot be combined: two share-alike licences in one game, a non-commercial part in a studio with a
+shop, a no-derivatives part that was edited. Tell the person, and settle it before deploying.
+
+## Never
+
+- Share a part the person did not ask to share, or pick its licence for them.
+- Copy a piece from another studio by hand: `part_add` is what checks it and writes the credit.
+- Remove or reword a credit a part wrote.
+- Treat a package as a part, or a whole game as one.
+
+## Paid parts: use the person's wallet
+
+Needs studio **0.36.0** or later. Read the full settings and recovery procedure in
+`node_modules/@homie-rocks/studio/parts/PARTS.md`.
+
+Show the exact quote, currency, quantity, recurring interval, licence, refund and update
+terms from `part_add`. Ask first. Spending authority means the person's yes to this price in this conversation,
+or a standing instruction that names a spending limit and covers these terms. A quote for a new release must show its new price. Never approve a
+hash beside an earlier purchase's price.
+
+Use the person's installed open wallet client: `HOMIE_PARTS_WALLET=link-cli` or `purl`. `part_add` invokes it after exact-quote approval. Money goes directly to the
+selling studio's Stripe account. Wallet authority and limits belong to that wallet;
+never create another spending mechanism or disable its controls. Link currently requires
+the person to approve each card spend in their wallet app. Give them the returned wallet
+approval link, then retry `part_add` after approval. This is not a seller checkout page.
+
+Checkout is the fallback when there is no compatible wallet, for recurring purchases,
+and where the protocol cannot quote the final total. On this fallback the person must
+accept the licence and operate Pay themselves. Never submit licence acceptance through
+a browser tool. A base price before tax is not Stripe's final total.
+
+Keep private purchase records and verified backups private. Never give a catalogue the
+claim or download token. A proof is evidence, not a download credential. First delivery
+and updates depend on the seller; an existing verified backup restores offline.
+
+Use `parts refund` only when requested. Never pass `--receipt-verified` on the assistant's
+own word: the seller must confirm matching the Stripe receipt and payer to the order.
+Never approve an unknown buyer's test order. Test downloads require owner approval of
+the exact claim, and do not become paid licences when the shop goes live.
+
+
+Machine purchases use the seller's Stripe account. Only studios with paid releases need the
+additional payment permissions. Connect and scheduled readiness use read-only provider calls;
+readiness does not prove a funded settlement. Tempo is disabled; the offered methods are card
+shared payment tokens and Base, subject to the seller's configuration and Stripe eligibility.
+Respect the wallet owner's limits, including x402's default payment cap. A decline can use a
+fresh approved token or the hosted fallback. An uncertain outcome must be reconciled first.
+
+The office lists unresolved orders and their provider identifiers. Use Reconcile payments now;
+a five-minute scheduled job also reads existing payments. After 23 hours it stops replaying
+charges but continues reading. If paid files cannot be restored, the owner must refund manually.
+For an unrecorded Base payment, send the exact refund from the seller address to the original
+payer after the purchase, then record its hash with `shop refund <order> --manual-transaction
+<hash>`. The chain must confirm the sender, recipient, amount and time before access ends.
+
+
+For app, music and video parts, use `part_new` without `from`, choose any suitable kind label, put the licensed files in its folder, and supply the source as `{kind, id, studio}` in `from`. Preserve existing game manifests and imports. Hash and share through the usual tools. No new app build framework is implied.
+
+Selling defaults to the keyless shop: `shop connect` uses the official Stripe CLI approval, creates Payment Links and the webhook, and installs the signing key privately. One approval if needed, zero for an already connected profile. Machine MPP/SPT and MCP charges and the Stripe-recorded x402 path need the fuller Worker credential. Read the payment-path table in PARTS.md before setup. With browser access, operate Stripe's key page for the owner, let them complete only provider verification prompts, click Copy, and run `shop connect --from-clipboard`. Never ask the owner to find or paste a key when this alternative is available. The command reads and clears the clipboard privately. Do not print its contents. No real-account verification is claimed by the release's stand-in tests.

package/guides/plan/SKILL.md

@@ -0,0 +1,126 @@
+---
+name: plan
+description: Plan a game or app with the person before building it — sensible defaults from their request, with an interview only when requested that ends in the game's Game Codex, games/<id>/CODEX.md, drawn as a page in the game's own palette, fonts and art that anyone can read and steer (a Claude artifact where the app has artifacts, else a page in their browser, and a private page on the studio's site), kept true as decisions change, with the build's progress on it. Use for step 4 of a new studio, or when someone says "let's plan my game", "what should my game be", "make a design doc, a game bible or a codex", "show me the plan", or before a big change to a game.
+---
+
+**One planning mechanism for games and apps.** For an app, use this workflow with `apps/<id>/CODEX.md`, created by `codex new <id> --kind app`. Its page, style decisions and build status use the same renderer as a game. Read the app skill's dream/scene/people/offers/needs instructions and fill those sections from the person's words; skip game-only sections and interviews. Build with the app skill, then prove its Codex needs on wall and phone. A starter is plumbing, never the planned scene. Choose engineering yourself and continue unless essential real-world information is missing.
+
+# Plan a game: defaults and its Game Codex
+
+You are in a Homie studio (a folder with `studio.json`) with a game in `games/<id>/`. The plan
+comes out as the game's **Game Codex**: `games/<id>/CODEX.md` (the source of truth, in the studio's
+repository) and a page drawn from it in the game's own look, with cards, tables and a Build status
+tab. People who never read code see the game in it and steer it; you keep it true.
+
+The implementation default is rules plus view on a server room, up to 32 seats.
+Choose engineering details yourself; never ask the person to choose hosting, ownership,
+tick rate or serialization. Capture the requested mechanic, controls, outcomes and visual
+identity in the Codex. Read the game skill's RULES.md before implementing. A live app uses
+the same transient rooms, without mandatory scores/bots/rounds, plus authorized records.
+
+## 1. Decide from the request
+
+Default to doing the planning yourself. Choose genre, controls, camera, palette, room size,
+round length, bots and scope from the person's premise. Use phones and computers, a small first
+version, CC0 art and local sound. Infer cloud saves for persistent characters and collections;
+short standalone rounds need none. Record decisions in the codex and continue building.
+Never route engineering or design questions to the person. A pub or charity may want an app;
+do not force a game interview onto it. Ask only when the intended outcome is missing.
+
+When the person explicitly asks to plan together, use references/INTERVIEW.md as an optional
+conversation aid. Their earlier answers count. Paid media needs a budget; use local assets until then.
+Run `style init <id> --prompt "<their words>"` with automatic defaults unless they requested hands-on styling.
+
+### While planning: what already exists
+
+Before the scope is fixed, look for what the game can be built from, two different things, and tell the person in a
+line each:
+
+- the `@homie-rocks/*` packages (npm) for the general mechanism: camera, input, audio, effects;
+- `parts_find` for pieces other studios shared: a creature, a level generator, a bot brain. (With a shell and no
+  chat tools: `npx --no-install homie-studio parts find "<words>"`.)
+
+Both go in the codex under **Built from**, with the game and studio each part came from and what will be written
+from scratch (the `parts` skill).
+
+## 2. Write the codex
+
+```sh
+npx --no-install homie-studio codex new <id>      # games/<id>/CODEX.md with every section, in the studio's colours
+```
+
+A new studio has no game yet: its game is planned before it is made. With no game `<id>`, `codex new <id> --name
+"<Name>"` starts the game's folder with only the codex in it, and once you have recorded the plan, `game new <id> --from
+gem-rush --name "<Name>"` makes the game around it (the codex stays).
+
+Never replace an existing codex: change it. Fill every section from the request and your defaults (the format, with an
+example: `references/CODEX.md`):
+
+- **The look in the frontmatter**: the game's own `palette` (`bg`, `ink`, `accent` for headings,
+  `accent2`, `danger`, `good`), `fonts` (a Google Fonts family that fits: "Press Start 2P" or "Silkscreen"
+  for pixel games, a font file from the game's folder, or none), `pixel: true` for pixel art, a `cover`
+  from the game's folder, an `eyebrow` and a `tagline`.
+- **Cards, not prose**, wherever there are several of a thing: characters, creatures, classes, items,
+  places, levels. Each `### Name` has its picture, a chip line (`` `C-01` `good: Ally` `danger: Boss` ``),
+  an italic one-line subtitle, a sentence, and `**Key:** value` stats.
+- **Controls** as a table with a column per device; **Milestones** as a checklist (`- [x]` done) that
+  matches the scope; **Latest** as dated decisions (`- 2026-10-01: ...`); **Open questions** as a list.
+- **Pictures** only from the studio's folder (a real frame of the game, its sprites, its cover, art the
+  `art` skill made). Until the game has art, a card without a picture is fine; never present a mock-up
+  as the game.
+
+## 3. Draw it and show it
+
+```sh
+npx --no-install homie-studio codex <id>          # .studio/codex/<id>.html; says what is not decided yet
+```
+
+It reports the sections still empty (`missing`), the open questions and any picture it could not use.
+Then show it where the person is:
+
+- **An app with artifacts** (Claude Code's Artifact tool, the Claude app): `codex <id> --artifact`
+  writes `.studio/codex/<id>.artifact.html`, one self-contained page made to be published as an
+  artifact. Publish it (private to the person until they share it), and update the same artifact each
+  time the codex changes.
+- **Otherwise**: `codex <id> --open` opens the page in their browser. It redraws itself whenever the
+  build's progress changes, and refreshes by itself while a build runs.
+- **On their phone or anywhere else**, after a deploy: the site has it at `/_studio/codex/<id>/` for the
+  owner only, never listed; `npx --no-install homie-studio codex link <id>` gives a one-time link.
+
+In the chat, say what you chose in one line, show the page, and continue. They can change it by asking.
+
+## 4. Keep it true
+
+- **Every decision that changes the plan goes into CODEX.md in the same change**, with a dated line
+  under Latest, and the page is redrawn (and the artifact updated).
+- Tick milestones as they land; move answered open questions into their section.
+- "Where are we?" or "how far along is it?": the codex's Build status tab (or
+  `npx --no-install homie-studio progress show`), in a line or two.
+
+## 5. Progress, baked in
+
+Open a progress feed for every build, titled with the milestone it works on:
+
+```sh
+npx --no-install homie-studio progress start <id> --title "Milestone 2: the valley and hand-offs"
+npx --no-install homie-studio progress stage plan done --note "<the plan in one line>"
+```
+
+`build`, `check` and `deploy` report into it; mark what only you know with `progress check`,
+`progress spend` and `progress log`; end it with `progress end passed|failed|stopped`. The codex's
+**Build status** tab shows it: a percentage, each step and check going green, a "Ready to try" box (the
+address and the codex's `try:` line), and what was spent. In Claude Code the status line shows one line
+of it (offered in the setup step: `homie-studio statusline --install`). Codex CLI has no command status
+line (its `tui.status_line` takes only built-in items), and Homie installs none in Grok Build, so in both the
+codex page is the progress view.
+
+## 6. The look, before the first model
+
+Before anything is made for the game's look, its decisions exist (`style init`, above): the automatic path says
+one line ("Look: flat low-poly, autumn grove palette, golden hour, high three-quarter camera; open the codex to
+change anything"); the hands-on path shows the style board (`style_explore`, or `style board <id>`) and lets them
+pick, mix, steer and lock. Models then come from the `models` skill, free routes first.
+
+## 7. Then build
+
+Build with the `game` skill, one agent by default. Use parallel agents when the person requested them.

package/guides/plan/references/CODEX.md

@@ -0,0 +1,105 @@
+# The Game Codex: the format
+
+`games/<id>/CODEX.md` is plain Markdown that reads well on GitHub, plus a few conventions that
+`homie-studio codex <id>` turns into a page in the game's own look. Everything in it is shown as text:
+HTML in it is escaped, and an HTML comment (`<!-- … -->`) is a note for you that never shows.
+
+## Frontmatter: the look
+
+```yaml
+---
+eyebrow: The Ashen Reach            # a small label over each section's heading
+tagline: Outrun the fire. Carry the last ember home.
+cover: hero/wide.jpg                # behind the title: a picture in the game's folder
+palette:
+  bg: "#120c0a"                     # the page
+  ink: "#f6e7d3"                    # the text
+  accent: "#f4b23c"                 # headings, the title
+  accent2: "#7ad38a"                # eyebrows, links, the tab bar's Build tab
+  danger: "#ff5a4e"                 # danger tags
+  good: "#5fdc8b"                   # good tags, ticks
+  gold: "#f2c14e"                   # rare tags, the Ready to try box
+fonts:
+  display: Press Start 2P           # a Google Fonts family name, or a .woff2/.ttf in the game's folder
+  body: Inter
+  mono: JetBrains Mono
+pixel: true                         # pictures keep hard pixel edges when scaled
+try: Arrow keys or WASD to run, Space to dash. Open a second tab to see two runners in one room.
+---
+```
+
+Every key is optional. A colour that is missing comes from the game's landing theme (game.json
+`landing.theme`), then the studio's `site/theme.json`. Colours are `#hex`, `rgb()` or `hsl()`; a font is a
+family name of letters, digits and spaces, or a file; anything else is left out with a warning. A light
+`bg` draws a light page.
+
+## The body
+
+- `# Name` is the title (else game.json's name). The paragraph under it is the pitch.
+- Every `## Section` is a tab, in the order written. The usual ones, which `codex` counts as decided once
+  they have something in them: **Concept**, **World**, **Characters**, **Art direction**, **Controls**,
+  **Rooms and players**, **Music and sound**, **Milestones**, **Open questions**, with **Latest** first.
+  Name others freely (Items, Classes, Levels, Story, Death, Quests…); they are tabs too.
+- The **Build status** tab is added by itself, from the game's progress feed.
+
+## Cards: `### Name` under any section
+
+```markdown
+## Creatures
+
+Wisps chase whoever holds the ember; moths only fight back.
+
+### Cinder Wisp
+![Cinder Wisp](art/cinder-wisp.png)
+`M-01` `danger: Aggressive · 6 tiles` `gold: Rare at night`
+*Level 1–3 · the burning floor*
+Drifts toward whoever holds the ember; touching it costs a spark.
+- **Where:** everywhere the grass is burning
+- **Health:** 2 hits
+- **Drops:** a short speed boost
+```
+
+- The first picture is the card's art (a sprite or a portrait; small pictures stay crisp with `pixel: true`).
+- A line of only `` `code` `` chips: one like `M-01` or `C-12` is the card's id; the rest are tags. A tag's
+  colour comes from `good:`, `danger:`, `gold:` or `info:` in front, else from its words (aggressive,
+  boss, enemy are danger; passive, ally, player are good; rare, elite, legendary are gold).
+- A line in italics is the card's subtitle (level, place, class).
+- A list where every item is `**Key:** value` (or `Key: value`) is the card's stats, in the mono font.
+- Anything else is the card's text.
+
+Text before the first `###` of a section is its introduction.
+
+## Tables, checklists, the decision log, pictures
+
+```markdown
+## Controls
+
+| Action | Phone | Computer | TV and phones |
+| --- | --- | --- | --- |
+| Run | drag from the lower left | WASD or arrows | each phone is a pad |
+| Dash | tap the right side | Space | the pad's A |
+
+## Milestones
+
+- [x] Step 1: a working copy of the starter plays in two browsers
+- [ ] Step 2: the valley, the wisps and hand-offs, checked with two browsers
+
+## Latest
+
+- 2026-10-01: Rounds go to 90 seconds; the valley needs time to cross.
+- 2026-09-30: Pixel art at 16 px, scaled 4x, no smoothing.
+```
+
+- Under **Latest**, a list item that starts with a date is a decision; the page shows them newest first.
+- A picture on a line of its own is a figure; several in a row are a gallery. Pictures come only from
+  inside the studio (a path from the game's folder, or from the studio's root) and are embedded in the
+  page: png, jpg, webp, gif or svg, up to 2.5 MB each and 10 MB in all. A web address is not loaded.
+- **Open questions** are drawn as numbered question cards.
+
+## Keeping it true
+
+- One codex per game; change it, never replace it.
+- A changed decision: change its section, add a dated line under Latest, redraw (`codex <id>`), and update
+  the artifact if there is one.
+- The codex is the person's plan, not a public page: it is not served
+  with a game's files, and on the site only at `/_studio/codex/<id>/` for the owner.

package/guides/plan/references/INTERVIEW.md

@@ -0,0 +1,86 @@
+# Plan interview: questions with options
+
+Only for a person who explicitly requests an interview. Otherwise infer these choices from the premise and continue building. Adapt the options to what the person has
+said; these are starting points, not a script.
+
+## 1. Game type and genre
+
+- "What kind of game? A brawl in an arena, a race, a co-op survival, a puzzle versus, a party game of
+  quick rounds, an adventure with a world to explore? From what you changed, I'd guess a brawl."
+- "What does a player do in the first ten seconds?" (move and grab, aim and shoot, draw, guess, build)
+- "How does a round end? First to a score, last one standing, the most points when the clock runs out?"
+- Multiplayer shape: "Everyone against everyone, two teams, or all together against the game?"
+
+## 2. Style and art direction
+
+- "Pixel art, painterly, low-poly 3D, clean vector shapes, neon on black, hand-drawn? For phones at a
+  glance I'd pick pixel or vector: they read small."
+- "Name a game, film or picture it should feel like." (Two or three references are plenty.)
+- "Day or night, cosy or tense, bright or moody?" Then propose a palette of four or five colours.
+- Fonts: suggest one display font that fits (pixel: "Press Start 2P", "Silkscreen"; storybook: "Fraunces";
+  sci-fi: "Orbitron", "Exo 2"; clean: "Inter").
+- If they want to discuss it: "Do you want to steer the look closely (I'll show you three directions, drawn by the game itself,
+  and you lock what you like), or should I pick and show you?" Hands-on: the `style` skill's board. Pick for me:
+  `style init` with their words, then one line about the look.
+- And once: "Art budget: free only (the starter library and the engine), a small budget on your own fal account
+  (I'd suggest US$5 for a handful of generated props), or your own number?" Free only means no generated assets
+  at all; the number is a hard cap (the `models` skill's `budget`).
+
+## 3. Devices
+
+- "People will play on phones and computers. Should it also work on a TV with phones as controllers, so
+  friends on one couch play together?" (Say what that adds: the big screen view and each phone a pad.)
+- Per device: "On a phone you steer from the lower left and press on the right; on a computer, keys.
+  Anything that needs more than that?"
+
+## 4. Players and rooms
+
+- "How many in a room: 2 to 4 for a duel feel, 6 to 8 for a party, larger rooms for a crowd?"
+- "Rounds of 60 seconds, 90, or longer?" (Short rounds keep strangers.)
+- "Bots fill empty seats. Should they be easy, or play to win?"
+- "Someone who joins mid-round takes a bot's place. Do they keep the bot's score or start at zero?"
+
+## 5. Progress and saves
+
+For an explicitly requested interview only: **"Does progress need to persist across sessions or devices?"** Then, if it does:
+
+- "What does a player keep between visits: a character and its level, an inventory, unlocks, a collection,
+  their settings? I'd keep the hero in one save, so it always saves whole."
+- "Should it follow them to their phone and their laptop? Then they make an account with a passkey (Face ID or
+  a fingerprint, no password); until they do, they play as a guest and keep it on that device."
+- "Lifetime numbers that never reset: kills, gold earned, time played, best level?"
+- "Can a death be forever? A hardcore mode wipes the character and writes its name in a hall of the fallen."
+- No persistence (a match is all there is): say so in one line and move on; nothing to wire.
+
+## 6. Art and film
+
+- "Who are the characters, creatures or pieces? Name them and I'll give each a card."
+- "Places: one arena, or several levels or zones?"
+- "A cover and a trailer come from the game itself, free. Painted art or generated video is on your own
+  fal account with a budget you set: want any of it, and how much at most?"
+- For a 3D game: "Models come free from the engine and Homie's CC0 starter library first; a few signature props
+  can be generated in your locked style for about US$0.54 each. Any you already own to bring in?"
+
+## 7. Music and sound
+
+- "A theme that loops while you play: fast and driving, calm, spooky, heroic? About what tempo?"
+- "Which moments need a sound you'd recognise with your eyes closed?" (pick-up, hit, win, countdown)
+- "Synthesized here for free, or a song from ElevenLabs on your own plan (quoted first)?"
+
+## 8. Scope
+
+- "For the first playable version: the core loop, one place, two or three characters, bots. Then art,
+  sound and the landing page. Then more places or modes. Sound right?"
+- "Anything that must be in the very first version?"
+- "Anything you don't want at all?"
+
+## Genre starters
+
+| Genre | Ask about | A good default |
+| --- | --- | --- |
+| Arena brawl | knock-back, power-ups, the arena's hazards | 6–8 players, 60 s rounds, most knock-outs wins |
+| Race | track shape, boosts, catch-up | 4–8 players, three laps or 90 s, first across wins |
+| Co-op survival | waves, the enemies, reviving | 2–6 players, waves of 30 s, survive as many as you can |
+| Party / quick rounds | the minigames, scoring across rounds | 4–8 players, 30 s rounds, five rounds a match |
+| Puzzle versus | the board, sending trouble to others | 2–4 players, until one board fills |
+| Adventure / RPG | classes, monsters, loot, zones, death, what persists | 2–8 players in a shared world, rounds as days or quests; the hero in cloud saves (start from the `ember-vale` starter) |