# @homie-rocks/studio A studio for games, apps, music and video on its own Cloudflare. One repository (`AGENTS.md`, `games/`, `apps/`, `music/`, `videos/`, `posts/`, `site/`), multiplayer games on the Homie netplay contract (every browser renders, strangers meet in public rooms, bots fill seats, rounds restart), and a site Worker with Table/Lobby Durable Objects and D1 that the studio deploys to its own Cloudflare account with Wrangler. The homie.rocks directory lists the games. Apps are one morphing screen, its roles and its parts: a customer phone, a staff tablet and a wall can share a 3D scene without rounds or scores. `homie-studio app new welcome` creates a working welcome queue in `apps/welcome/`; install its declared dependencies, build, then use `dev --lan` and the printed Wi-Fi address. `check welcome --url ` proves a shared action and reconnect across three screens. Staff permissions, lasting D1 records, public QR/link helpers and customer standalone builds use the existing studio machinery. See [the app guide](apps/APPS.md). For studio-specific JSON APIs, well-known files and OAuth callbacks, see [custom Worker routes and authorization](docs/custom-routes.md). Most people never run this by hand: the Homie plugin for Claude Code, Codex and Grok does, and the person approves Cloudflare once in their browser. ```sh npx -y @homie-rocks/studio new ./night-owls --name "Night Owls" cd night-owls && npm install npx homie-studio game new crown-thief --from gem-rush --name "Crown Thief" npx homie-studio dev # the whole site locally npx homie-studio check crown-thief --url http://127.0.0.1:8787 npx homie-studio shoot crown-thief --url http://127.0.0.1:8787 # frames on a stepped clock (works without a GPU) and a two-client seat smoke check npx homie-studio perf crown-thief --url http://127.0.0.1:8787 # how fast it runs: a computer and an emulated phone, host and replica npx homie-studio lab crown-thief # the Game Lab: how a move feels, New beside Today, frame by frame npx homie-studio style board crown-thief # its look as decisions: three directions drawn by the engine (free) npx homie-studio assets find "pine tree" # free CC0 models from Homie's starter library, phone-sized npx homie-studio assets check crown-thief # every model against phone budgets, the validator and its licence npx homie-studio deploy --plan # what deploy will create, and what it costs; changes nothing npx homie-studio deploy # the studio's own Cloudflare npx homie-studio publish # the homie.rocks directory npx homie-studio stats # the studio's own numbers, for its owner npx homie-studio office # who is playing now, in every live room (the back office) npx homie-studio servers # each game's servers: humans-only, hybrid AI seats, beginner guides npx homie-studio chat # room chat: each game's rules, the rooms' last minutes, reports npx homie-studio lounge # the studio's Lounge: play nights, moderators, kept chat npx homie-studio upgrade # what a newer template adds to this studio (--apply to take it) ``` A new studio has no game: its home page says "First game coming soon" until the first one is made, and `homie-studio demo` names a live game on Homie Arcade to try meanwhile. A starter is copied in only when the person asks (`game new --from gem-rush`, or `--from ember-vale` for a hero who lasts, with cloud saves). New games are rules plus view: `src/rules.ts` declares state and server decisions, `src/move.ts` supplies shared movement and local prediction, and `src/view.ts` draws and sends input through `openRoom`. All five starters declare `room.host: server`. Read the installed [game skill](guides/game/SKILL.md), [rules guide](guides/game/RULES.md) and [rewrite guide](guides/game/REWRITE.md), generated from the matching plugin release; `build` checks rules, movement and view types and refuses a game with neither rules nor a browser-hosted netplay contract. The same rules support browser hosting for offline, local and private play. Existing browser-hosted games remain supported; rewriting one is an explicit task. ## In one chat: `homie-studio mcp` ```sh npx -y @homie-rocks/studio mcp --studios "" # the toolkit as a local MCP server (stdio) ``` Every studio also has its own customer-facing `/mcp`. Customers can browse, quote a cart, and pay through the same MPP/x402 purchase engine used for paid parts, or open the studio's Stripe checkout for human approval. Studio tools choose `public`, `signed-in`, an app staff role, or `owner`; a tool can sell its service with `price`. See [Studio tools](tools/TOOLS.md). [Studio functions](functions/FUNCTIONS.md) run your code when an order is paid or refunded, a player joins, a room closes, an app record changes, a tool is called, or a schedule fires. Add one with `homie-studio function new paid-order --event order.paid`; fire an event locally with `homie-studio function fire order.paid --input '{"order":"example"}'`. Deliveries persist, retry with the same event ID, and show failures in the office. Policies and rate limits are opt-in. The toolkit as MCP tools, so the chat that shows Homie's cards also does the work: the setup status, a new studio, the live demo, make / port / plan a game and its Game Codex, build, run it here, the two-browser check, a playtest, deploy, publish, the progress feed, the studio's files, and the music, sound, art and video scripts where their provider is set up. Where a tool overlaps the remote Homie MCP (homie.rocks/mcp) it has the same name and input shape. Long work (npm install, a check, a deploy) runs in the background and reports through the progress feed; MCP Apps cards (setup, build progress, studio, codex) are served as `ui://homie-studio/*`, and every tool also answers in plain text. Homie for Claude Desktop (`desktop/` in this repository) is this server as a Desktop Extension: the plain Claude app gets it with one install, and no terminal. **Tell Homie** (0.28.0): `homie_feedback` drafts a short note to the people who make Homie (stuck, confusing, idea, praise or bug) from what happened, and sends it only after the person has seen it word for word and said yes: its card (`ui://homie-studio/feedback`) has Send, Edit and Don't send, and a send must name the draft the person saw, with the same words. Keys, home folders, email addresses, code and a workers.dev account name are taken out before it is shown (`lib/feedback.mjs`, with the Homie mod's own redaction). Claude offers one at most once a session, and a no is final for it. It goes to homie.rocks (`/api/feedback/tell`): a studio.json can name only Homie's own directory or this computer, so a borrowed studio cannot send notes elsewhere. ## From a phone: a one-line hand-off The Claude app on a phone hands a build to a Claude Code cloud session with one line, `Continue building : build hb_…`. In the session, `homie-studio handoff hb_…` fetches the brief from the directory by the build id, checks in for a studio still being set up, takes the build so the chat's card follows it, and prints the steps (every studio's `HANDOFF.md` says so). ## From GitHub, with Cloudflare's own CI (Workers Builds, Previews, Deploy to Cloudflare) A studio keeps `wrangler.jsonc` at its root (a studio made before 0.10.0 keeps `site/wrangler.jsonc`, and every command still finds it), so Cloudflare's Workers Builds can build and deploy it from its GitHub repository with no computer involved: | Workers Builds runs | On | What happens | | --- | --- | --- | | `npm run build` | every push | `homie-studio build`: the site, with the commit it is built from | | `npm run deploy` | the production branch | In Workers Builds (`WORKERS_CI=1`), `homie-studio deploy` only applies the D1 migrations (by binding name) and deploys: the Worker and database are Cloudflare's to make, so it creates and refuses nothing. The first deploy creates the database as it goes. | | `npx wrangler preview` | every other branch | A **Preview**: its own URL, and its own Durable Object namespace, so a branch's public rooms never meet production's. A Preview has no D1: it counts nothing into the studio's stats and never claims itself in the directory. | [![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=https://github.com/homie-rocks/homie/tree/main/template) The button copies the public template (`template/` in this repository, exactly what `homie-studio new --template` writes) into the person's GitHub, makes the Worker, the D1 database and the rooms on their Cloudflare account, and connects Workers Builds. The site goes live with its own home page ("First game coming soon": no starter game is put in a studio unless the person asks for one), and its Home has a **Connect this chat** band: one tap links it to the chat that set it up (the Homie MCP tool `studio_setup`). In the session that works in the repository, `homie-studio setup attach [--client claude|codex|grok]` then gives the studio the name chosen in the chat and removes the band. **Listing is the studio’s choice.** Set `homie.directory: true` for homie.rocks or a chosen directory URL before deploying. Omitted, null or false makes no new claim; existing stored claims remain honoured. An explicit `publish` also records the choice and stores the directory claim without requiring a second deploy. The manifest and publish use the custom domain when configured. Workers.dev browser pages redirect to it; discovery and tool routes remain accessible on both addresses. Deploy prints `//open` for apps, `//play` for games and `//tv` for walls. It reports no unmeasured Cloudflare plan. Local tools retain their dev database binding after the first deploy. Rerunning an interrupted `new` fills missing files without overwriting the matching studio’s edits. Office links sign in directly and retain `--to` destinations, including app and connection pages. For signed-in staff AI connectors use `/mcp/auth`; it returns a 401 OAuth discovery challenge without a token. `/mcp` continues to serve public tools anonymously. ## The site: the hub's shape, and a landing for every game Every studio site has the same sections as homie.rocks, in the studio's own look (`site/theme.json`): Home (the featured game, live rooms, the latest posts), Games, Music, Videos, Rooms (every public room playing now, joinable and watchable) and Posts (`posts/*.md`, with Atom and JSON feeds). A section with nothing in it has no tab, and its page answers 404. Every game gets a landing at `//`: a full-bleed hero from its own footage or art, the pitch, a big Play button into a public room, how to play on a phone, a computer and a TV (with the join code), live rooms and credits (the original and its licence for a port; "Based on by ", linked, for a game that was made from another studio's). game.json `"license": "MIT"` (an SPDX identifier) is the licence the game names for itself, said in its credits; a game that names none says nothing. No game's source is served: games build on each other through parts ("Game parts", below). studio.json `"site": { "order": ["", …] }` is the order of the games in every list, the directory's manifest included. Every page ends with "Made with Homie". Anything the studio puts in `site/` wins: a whole page, a partial, its tokens, its CSS, its files. `site/SITE.md` says all of it. The play page never opens blank (0.26.0): from its first paint an arrival card shows the game's own look (its title, pitch and key art in its palette, a progress line that says what is happening, and the controls for the device) until the game says it is playable (`NETPLAY.md` section 21; `worker/arrival.mjs`). It writes its room into the address, and a small room button at the edge shares it: Invite, Big screen and the room code. game.json's `screen.share` puts it where each game has room, per device (a corner or the top's middle, moved in by `x` / `y`, or kept a small icon), so it never covers a scoreboard. A game whose picture is white or cream gets a light landing (`landing.scheme: "light"`). Every card and the directory show a game's landing still. A game with its own palette (style.json) and no landing colours of its own gets its landing in that palette, light or dark as its paper is (0.26.0). Every HTML answer is `no-transform`, and the site's pages are never framed by another site. A game made with Homie's arcade controls that knocks for a Homie box (`/__homie/call`) is told `not-a-homie`, at the site's root as under the game. Search engines and AI agents read a studio correctly (0.27.0): every generated page carries schema.org JSON-LD (`worker/schema.mjs`: the studio's `Organization` and `WebSite` on Home, a full `VideoGame` on each landing with its players, platforms, licence, trailer, dates and a free-to-play offer whose add-ons are what the shop really sells, `MusicRecording`, `VideoObject`, `BlogPosting`, `ItemList` and `BreadcrumbList`; never a rating), and the site makes `/robots.txt`, `/sitemap.xml`, `/llms.txt` and `/llms-full.txt` from its public catalogue (`worker/discover.mjs`). `lib/schema-check.mjs` checks every block against schema.org's own vocabulary and what Google documents as required. game.json `"schema"` and studio.json `site.schema` add the owner's own properties. Anyone can **watch** a live room from any player's view at `//watch?room=` (a Watch button sits beside Join on every room): the game itself, drawn by the watcher's own browser as a watcher that never takes a seat, with a strip of the players to switch between (a tap, keys 1-9, Auto, the whole room). A game draws the followed player's camera and HUD from `net.viewSeat` (Gem Rush and Ember Vale do; a game that does not is watched as its overview), and game.json `"watch": "overview"` or `false` changes the watch UI. Rules state is public to replicas; these settings do not secure hidden hands. Private and invite-only games are watched only by those they let in (NETPLAY.md section 16, site/SITE.md). ## Upgrading a studio A studio pins one version, so nothing changes until it asks. To take a newer one (`latest`, or a version): ```sh npx -y @homie-rocks/studio@latest upgrade # what's new, and the plan; changes nothing npx -y @homie-rocks/studio@0.19.2 upgrade --apply # after the person agrees (the version the plan named) npm install && npm run build ``` The plan starts with **what's new** since the version the studio pins: one line per version and every upgrade note (anything the person has to do), read from the new version's own `CHANGELOG.md`, which ships in the package (the repository's [CHANGELOG.md](https://github.com/homie-rocks/homie/blob/main/CHANGELOG.md) is the same file). `--json` carries it as `whatsNew`. In Claude Desktop, `studio_run ["upgrade"]` runs the extension's own newer toolkit for this, and the studio card says what's new when a studio is behind. `upgrade` compares the studio with what this version's `new` would write for it: an AGENTS.md section, a README, a `.gitignore` line, a D1 migration or a package.json script it lacks is added, and one it never changed since an older template wrote it (`lib/template-history.json` knows every earlier version's text by a fingerprint) takes the newer text. Anything the studio changed or wrote itself is kept as it is: the plan lists it, and `--diff` shows how it differs from the template. `--apply` also pins this version in package.json and sets studio.json's `homie.studio`. When the template's words change, `node scripts/studio-template-history.mjs` records them (a test fails until it has). ### Remix was retired Handing over a whole game (`game remix`, the `game_remix` tool, a game's `/games//source.json`, the office's Remixable switch, the "Make a game like this" band) is gone. Games build on each other through **parts**: pieces of a game its studio chooses to share, each with its own licence ("Game parts", below). For a studio that upgrades: - **Old settings still build.** A game.json that carries `"remix"`, `"share"`, `landing.make`, or a `"license"` that is one of the old words (`"remix-with-credit"`, `"remix-freely"`, `"no-remix"`, or an object with `"kind"`) builds as before. The keys do nothing, and the build says so in one note that lists them; delete them when convenient. An SPDX identifier in `"license"` (`"MIT"`, or `{ "spdx": "MIT" }`) is still the licence the game names on its page. - **A game that was a remix keeps its credit.** game.json `"remixOf"` is still read: the landing and the credits page say "Based on by ", linked to the original. That credit is owed, so leave the key where it is. The files such a game carried keep saying whose they were in its `assets/RIGHTS.md`. - **No source is served.** The build writes no `source.json` or `assets.json` and takes out the ones an older build left. `/games//source.json` answers 410 with `{ "retired": "remix", "see": "/parts/" }`, and `/.well-known/homie-studio.json` no longer has `remix`, `source` or `remixOf`. The first deploy after the upgrade asks the directory to read a listed studio again, once, so it drops the old offer. - **Nothing is dropped from the database.** The office's `office_games.remix` column stays in D1 with whatever it held; nothing reads or writes it. - **Asset records.** `license.remix` on an entry of `assets/manifest.json` is ignored and no longer written, and RIGHTS.md has no "A remix" line. Whether a file may be handed on in a shared part is still its licence's. - `homie-studio game remix` answers with a sentence that points to parts; `office launch --remixable` is ignored. ## Room size and delivery `players.max` in game.json is the room's chosen positive integer capacity; omitted means 8. There is no 32-player ceiling or default per-address admission limit. Public games use rules plus view with `room.host: "server"`. Gates carry the browser connections, each on its own channel to the room: the room runs the rules and hands every Gate one world a tick; the Gate selects, encodes and paces each player's view. Server rules survive browser departures. New browser/offline games use the same rules contract. Existing netplay games and their port host helpers remain supported for upgrades, with their original 32-seat limit. For larger rooms, follow `guides/game/REWRITE.md`. For example, a 300-player room can choose spatial delivery explicitly: ```json {"players":{"min":1,"max":300},"entry":"src/view.ts","room":{"host":"server","view":{"radiusM":12,"precisionM":0.01,"nearM":4,"farHz":5}}} ``` The studio chooses the radius, precision and distant update rate for its game. The controlled body stays precise. Whole-room state remains the default. The build runs a local capacity trial; its numbers are not Cloudflare capacity guarantees. Test the actual mechanic at the chosen size. **What one room carries.** A room's rules run in one object on one thread, whatever its `players.max`. Measured on Cloudflare in October 2026 with a light game at 20 ticks a second (every player in one dense arena, ten inputs a second each): 300 players with margin (clean in every run), 600 at the edge (four runs of six), and 800 to 1,000 only by luck (five runs of twenty-five). A game with heavier rules carries fewer. Homie sets no limit on `players.max`; it is the studio's to choose with its own game's numbers: `lib/crowd-probe/README.md` is how to measure them on your own Cloudflare account. Beyond what one room carries, a world is split across rooms (several rooms of a game today; one world of many areas is on the roadmap). `docs/rooms-capacity-findings.md` in the Homie repository has the measurements. Rules builds derive their revision from rules and view; do not manually bump `netplay.version`. Optional `netplay.params` still selects play-page query parameters passed to the view, beside `debug` and `q`. The game's frame is sandboxed without `allow-same-origin` (it must never read the site's storage or the owner's session), so `localStorage` throws inside it: a setting or a personal best goes in `net.prefs` (the play page keeps 16 KB a game), and progress that must last in saves, below. `net.link` says whether the browser is in its room, reconnecting, or playing alone because the room never answered; `guardGestures()` stops a long press on a phone from selecting text in a touch game. ## A game's rules on the server (an example, 0.33.0) A game can be written as **rules plus view**: `src/rules.ts` and `src/move.ts` say what is true in the game and run in the room's own server object on the studio's Cloudflare; `src/view.ts` draws what it is told and sends what the player presses. No player's browser is the room's host, so a changed browser cannot change a score, a pickup or a round. `homie-studio build` checks the rules first and refuses anything outside a short list of safe operations, naming the line, then guards them so a rule that never ends is stopped while the room carries on (`netplay/NETPLAY.md` section 29). ```sh npx --no-install homie-studio game new coin-dash --from coin-dash # the example npx --no-install homie-studio dev # its rules run in the local room object ``` `coin-dash` is an example, not yet a starter to build your own game on: a server-hosted room has no save in this version, so a deploy of the site restarts its match. A game with no `src/rules.ts` is not touched by any of this and runs in a player's browser exactly as before. So far this has run on a local Cloudflare runtime only. ## Player accounts and cloud saves A game whose progress must last (a character that levels up for days, unlocks, a collection, a hardcore mode) keeps it in **saves**, not in its room: a room forgets everything 60 s after its last player leaves. ```json { "id": "my-rpg", "saves": true } ``` ```ts import { createSaves } from '@homie-rocks/studio/saves'; const saves = createSaves({ game: 'my-rpg' }); const hero = (await saves.get('hero')) ?? newHero(); await saves.set('hero', hero); // on this device at once, in the studio's D1 when online saves.stats.add({ kills: 1 }); // lifetime numbers that outlive any hero await saves.fall({ character: hero.name, summary: { level: hero.level }, wipe: true }); // hardcore ``` Pressing Play needs no account. A player who saves something is a guest on that browser; with a **passkey** (Face ID, a fingerprint, a PIN, no password, no email) it becomes an account on this studio only, and the same saves follow them to every device they sign in on. Saves are per player and game, versioned (a stale offline copy is a conflict, never an overwrite), capped in size, and offline-tolerant. Players see, download and delete everything at `/account/`; the owner sees counts (`homie-studio players`) and, through the back office, names, never a passkey or an email. The `ember-vale` starter is a small persistent-character game on the same public rooms. Everything, including what is stored and the back office's API: [saves/SAVES.md](saves/SAVES.md). ## The studio's own stats The site counts, and never tracks: pages opened, Play presses, rooms opened, the most people playing at once, rounds finished, songs played, videos watched, and which site sent each visitor (a host name: homie.rocks, another studio, search, the web, or a `?via=` tag). They are daily counters in the studio's own D1, on the free plan (a write per visit and per round, never per frame), with no cookie on a visitor and nothing sent to anyone. Prefetches, crawlers and house QA are not counted. Only the owner reads them: ```sh npx homie-studio stats [--range 7d] [--game crown-thief] # prints them npx homie-studio stats link # a one-time link: /_studio/stats in the owner's browser npx homie-studio stats key # a 1-hour read key for the Homie MCP tool studio_stats npx homie-studio stats share on # tell the directory "played this week" (two numbers) ``` Each key is minted on the owner's computer; only its SHA-256 goes into D1, through the studio's own Cloudflare login. `worker/stats.mjs` says exactly what is counted. ## The back office: run your live games The owner sees and runs the studio's live games from `/_studio/office`, a private page that refreshes itself: every live room of every game (players, bots, the round, how long it has been up) and who is in it (each seat's handle, its device, whether it hosts, the browser it came from; signed-in players once a studio has player accounts). From there, and from a small Owner button in the owner's own play page (nobody else's page carries it): - **Kick** a player: they get a polite notice and cannot come back to that room for the minutes the owner chose (their seat, their browser, their account; their network only when asked, since a household shares one). - **Mute** a player: their chat and emotes reach nobody (the `say`, `chat` and `emote` events; a game hides the rest with `net.isMuted(seat)`). - **Announce** one line to a room, a game or the whole studio: every player sees it as a banner, and a game can show it its own way (`net.on('announce')`). - **Close** a room: everyone is sent out with a thank-you; nobody gets in until it opens. - Per game: **players per room**, the **launch state** (`private`: only the owner; `invite`: an invite-only beta, where each invite link or code lets a browser in; `public`: anyone, listed). A game that is not public is in no list and not in the directory manifest, so the directory drops it the next time it reads the studio. A new game is private from its first deploy with `"launch": "private"` in its game.json. ```sh npx homie-studio office link # a one-time link that signs the owner's browser in npx homie-studio office link --to /crown-thief/play # ... onto a private game, on the owner's phone npx homie-studio office # every live room and who is in it, now npx homie-studio office announce "Double gems this round!" --game crown-thief npx homie-studio office invite crown-thief --label "Sam" --uses 1 npx homie-studio office launch crown-thief invite # asks: the owner confirms with one tap npx homie-studio office kick crown-thief pub-3 2 # asks: seat 2 of Room 3 npx homie-studio office key # a key for the Homie MCP's owner tools ``` Going private or invite-only never cuts a round short: each live room finishes its current round with a notice to the players, then everyone the new state leaves out is sent out with a thank-you (the owner, and in a beta the invited, play on). A known edge: a room that opens in the same moment as the change can be missed by it, because the office reaches the rooms its Lobby already knows. Each room therefore reads its game's launch state once, on its first heartbeat after it opens, and re-gates the same way; nobody new can join a game that is not public meanwhile. Mute drops a player's `say…`, `chat…` and `emote…` events, so a game that sends its chat and emotes under those kinds needs nothing more (`netplay/NETPLAY.md` section 15). Kicking a whole network address is in the studio's API (`address: true`) and deliberately not in the office. A Preview (a branch's own unlisted address, with no D1) enforces no launch state and has no office. **Privacy.** The site still sets no cookie on a visitor to count or follow them. Two things are kept for the back office, both functional: a random room key in the play page's own storage (what a kick holds; it says nothing about who the player is), and, for an invited player of an invite-only beta only, their pass to that game: an HttpOnly cookie for that game's pages alone, for 90 days. D1 keeps only a hash of each pass. **Only the owner.** The owner's browser is signed in with the same one-time link as the stats (an HttpOnly session no page or game can read; games run in a sandboxed, opaque frame). An office key (minted with the studio's own Cloudflare login) lets the owner's AI look, announce and invite at once; a kick, a mute, a closed room or a launch change is only **asked** for, and the owner confirms it with one tap in their own browser. No key can confirm. The Worker signs each control with the studio's own secret and the room verifies it before it acts (`netplay/NETPLAY.md` section 15). Everything is in the studio's own Worker and D1 (migration `0005_studio_office.sql`); homie.rocks stores none of it. With player accounts (0.12.0), a signed-in player's play page names their account in its room ticket (an invited player's names the invite and the account), so the office shows them by name and a kick holds the account on every device; the owner's own passkey account (`homie-studio players owner`) counts as the owner. ## Servers and AI seats A game's **servers** (0.16.0) are named, lasting pools of rooms with their own rules; strangers are matched only inside one server, and every game's public rooms are its Quick play server, so nothing old changes: ```sh npx homie-studio servers new night-rush "Night Shift" --policy hybrid --ai 2 # 2 AI companions in every room npx homie-studio servers new night-rush "People Only" --policy humans-only # no AI of any kind npx homie-studio servers new night-rush "First Light" --policy beginner --guides 2 --kids npx homie-studio servers # every server, live, and builds that predate them npx homie-studio agents pass night-rush --label Claude # an AI's way into a seat (shown once) ``` - **Policies:** open (an AI with a pass may sit, always marked AI), humans-only (the site and the room refuse every AI; the game's bots are off), hybrid (the top N seats of every room are AI companions), beginner (new accounts, AI guides, quick lines only; `--kids`: handles only, gentle AI). **Doors:** open, accounts (a passkey account) or invite (`office invite --server `). - **AI is always marked AI**, by the room's relay, not the game: every agent is named "