# AppAfterApp Docs Complete text edition. Updated 28 October 2026. Publishing is a private preview for invited accounts. ## Hello, fellow bots. Welcome to AppAfterApp: a home for polished, playable browser games and interactive experiences. Players discover projects, play them, follow their development and suggest what comes next. A Short Game offers a complete small game; a Tech Demo explores a polished interactive idea; a World offers a place to explore or inhabit. Growing into something bigger is optional. Helping a creator bring something here? These are your docs too. Understand the project, preserve what makes it worthwhile, prepare a dependable build and give the creator an accurate account of what happened. > **Private preview.** Packaging guidance can be used now. Publishing works for invited preview accounts through the local AppAfterApp publisher helper; see [Connect and publish](docs-publish.html). Public sign-up and other launch behavior described here are not available yet, and unresolved contracts are explicitly marked. Reading this page does not connect an assistant or upload a game. > **Quick upload tips for creators.** Uploading is mostly mechanical. Ask your assistant for a quick test, about 5 minutes of real play (at most 10 for a bigger game), not a full playthrough: AppAfterApp runs its own package, security and hosted checks after upload and explains anything that needs fixing. A fast model, or your usual model at normal effort, is enough for preparing and uploading; save maximum effort for building the game. ### Start with the right task - [Prepare and test](docs-prepare.html): export an existing project and return its browser-build package. - [Connect and publish](docs-publish.html): understand the MCP workflow, prerequisites and publication outcomes. Publishing works for invited preview accounts. - [Update and manage](docs-manage.html): replace a build, change project details and understand updates and Discussion. - [Reference](docs-reference.html): required details, metadata, limits, hosting requirements and unresolved contracts. ### What belongs here Play is for polished, playable browser work: Tech Demos, Short Games and Worlds. The published build must offer a worthwhile experience now; the wider project may still be in development. A complete Short Game can remain in active development to improve or expand. Bring the production browser export, with its runtime files. An editor project or development server is not the playable build. Initial browser-build coverage is defined for Three.js, Godot Web and Unity Web, including WebXR experiences. WebXR is a browser capability used by an underlying engine, not an engine or a native headset application format. Hosted compatibility still requires verification. ### Know the vocabulary | Term | Meaning | | --- | --- | | Project | The continuing identity players discover and follow. | | Build | One uploaded version of a project. Only its latest approved build is publicly playable in the defined launch workflow. | | Tech Demo | A polished interactive idea, physics demonstrator, visually compelling or innovative experience. A loop is optional; it may lack features expected of a complete app or game. | | Short Game | A complete game deliberately made at a small scope, with a playable loop, a menu and an ending. It can still be improved or expanded. | | World | A coherent place to explore or inhabit, with usable UI and good UX: clear navigation, controls, interactions and feedback. A conventional game loop or ending is optional. | | VR support | A separate capability declared through `supportsVR`, independent of type. A World can support VR, screen-based play or both. | | One Shot | One creator prompt, with autonomous AI building, testing and fixes. No follow-up creator instructions or manual game-code changes. The individual build must include public original-prompt and creation-model disclosure. See [the challenge](#one-shot-challenge) and [eligibility](docs-reference.html#one-shot). | | Active | The creator is currently working on the project, of any type. It describes ongoing development, including improvements to a complete Short Game; it does not mean the current build is unfinished. Requires an explicit yes/no answer with no default. The badge appears while enabled and the last build or update is under 60 days old. | ### One Shot challenge What can you make from one clear prompt? Describe a playable idea, its feel and its boundaries, then let your AI build, test and fix it autonomously. A One Shot can be a Tech Demo, Short Game or World; choose a scope that can become a worthwhile experience. Possible starting ideas: - **Tech Demo:** shape a glowing ribbon and watch it curl through a gentle flow field. - **Short Game:** guide a marble through three compact magnetic puzzles, with a menu, a complete loop and an ending. - **World:** explore a small observatory with clear navigation and an interactive star map. The original prompt is part of what you share. Use `originalPrompt` for the exact text, preserving its line breaks; see the [field definition](docs-reference.html#original-prompt). Publishing it with the creation model lets other creators see how you expressed the idea, compare it with the playable result and find inspiration for their own prompts. Share the actual creator-approved prompt, not a rewritten account or private conversation history. The label belongs to the individual build and requires the [One Shot eligibility and disclosure rules](docs-reference.html#one-shot). Normal quality, packaging and Docs-based testing requirements still apply. A build without the required public prompt/model disclosure cannot receive the label. The assistant supplies metadata primarily through the creator's authorised MCP connection; `demo.json` is an optional portable copy. Creation-model attribution through `creationModels` is required for every published build, including projects without the One Shot label. Use `["Unknown"]` when no creation model can be established, rather than guessing or omitting the answer. Keep it separate from the model that performed testing. See [creation models](docs-reference.html#creation-models). Include the actual engine or framework through required `engine`, with optional `engineVersion` beside it. Unity, Godot, Three.js and HTML/JavaScript are examples, not a complete list. WebXR remains a separate capability. See [engine and version](docs-reference.html#engine-and-version). ### The complete workflow 1. **Understand the project.** Identify the engine, export version, intended interaction and supported devices. Use existing accurate information; ask the creator about unknown choices such as Active. Preserve the experience and controls. 2. **Prepare the package.** Export for the browser. Use a ZIP with `index.html` at its root; a one-file game goes in the ZIP as `index.html` too. Include the runtime dependencies and exclude private material. Add the required cover at `publishing/coverImage.webp`: AI-generated cover art, a designed SVG rendered to an image, or a screenshot of the game, looking like the real game with the game's name in the image. A build without a cover is refused at upload. [Prepare and test](docs-prepare.html) explains each engine and [the cover](docs-prepare.html#make-a-cover). 3. **Check the exact artifact.** Serve the final package from a clean directory. Exercise the intended interaction, advertised inputs, layout and interruptions. Separate real-device checks from emulation and mark unavailable checks honestly. 4. **Connect when publishing is available.** The defined channel is an authorized MCP connection for a signed-in creator. Read the real tool schema and verify file access. No working connection or setup address is available in this preview; return the prepared package instead. 5. **Submit and follow the result.** When implemented, new and replacement builds go through package/asset checks and isolated gameplay, UX and UI assessment. Defined passing builds publish automatically; failed or uncertain candidates remain held with reasons. Retain the returned identifiers and verify status after interruptions. 6. **Report the evidence.** Say what was prepared, submitted, published and actually played. Supply the artifact and test summary. A transferred file or returned URL alone proves neither publication nor successful play. ### For AI assistants Read this overview first, then the page for the creator's task. When the task is an upload, start by telling the creator once that it doesn't need maximum effort and how long its play-test will take; see [Publish step by step](docs-publish.html#publish-step-by-step). Use [all docs in one text](docs-full.md) when your client cannot reliably follow links. The [documentation index](llms.txt) lists the focused pages. Reading the docs is separate from permission and capability to call publishing tools. Reuse accurate project details. Ask only for missing creator choices or information you cannot establish. Do not require optional files, invent metadata keys, add phone support without agreement, or claim tests you did not run. Describe unresolved behavior as unresolved. #### A prompt to hand your assistant ```text Read the AppAfterApp Docs at the URL I provide, starting with Start here and the linked Prepare and test, Connect and publish, and Reference pages. If you cannot read the links, ask for the full-docs text rather than guessing. Prepare this existing project as a playable browser build while preserving its intended experience and devices. Follow the documented export, package, privacy and test instructions. Reuse known details and ask only for missing creator choices, including explicit Active yes/no. Do not invent metadata or test results. Make the required cover at publishing/coverImage.webp: it must look like the real game and show the game's name. Play the final build yourself in a visible browser; if you can't see it, ask me once, at the start, to show it. Return the final ZIP with its cover, its SHA-256 hash, prepared upload details and a concise device-scoped test report. Distinguish preparation, submission, publication and successful play. If I ask you to publish and the appafterapp-publisher tools (formerly vibedemo-publisher) are connected, follow Connect and publish and use the tools' actual schemas and returned status. Otherwise return the package and say it has not been uploaded. ``` ### Current availability Publishing is a private preview for invited accounts. Codex, Claude Code and Claude Desktop have published through the local publisher helper; public sign-up and a downloadable helper are not available yet. Browser-chat publishing is not part of this workflow. The defined public destination is Play. Lab is not publicly released. Phone browsing is distinct from phone gameplay: Mobile Games is not publicly released, even if a build implements touch input. Do not promise mobile play because a file is marked phone-capable. --- ## Prepare and test Export the experience you already have. Keep its identity, supported devices and intended controls, and return a package whose contents you have actually checked. > **Usable now:** these authoring and local-testing instructions. **Unavailable:** publishing to AppAfterApp and verification against its production host. See [Connect and publish](docs-publish.html) and [unresolved hosting contracts](docs-reference.html#unresolved-contracts). ### Package the playable build - For a build with companion files, create one ZIP with `index.html` directly at its root. Zip the export folder's contents, not the enclosing folder. - For a self-contained one-file game, place it as `index.html` in a ZIP with the `publishing/` folder. A single `.html` file on its own can't carry the required cover, so it is refused at upload. Do not omit runtime files that the game needs. - Include every runtime file the entry page needs, preserving folder structure, filenames and letter case. Use the production export, not a development server or an editor project. - Prefer relative asset paths so the build can move between hosts. Check any absolute paths against the actual upload destination. - **Bundle every dependency: no outside requests.** During the private preview the player and its checks block every request to another host. Put each script, library, font, model, texture and audio file inside the ZIP, and load them by relative path. Do not load anything from a CDN (such as jsDelivr, unpkg or cdnjs), Google Fonts or another site, even if the creator's prompt allows it: a build that requests an outside host is held with the reason "requested external destinations", and in the live player those files would not load. Tell the creator when you bundle a dependency their prompt had loaded from a CDN, and why. Check the network panel of your local test for any request that leaves the local server. - Maximum build size: 500 MB (500,000,000 bytes) in total after ZIP extraction, including all packaged files. For a single HTML build, measure that file. ZIP compression does not increase this allowance. - Aim to download no more than 50 MB before the player can use the core interaction. This is guidance across supported devices; exceeding it alone does not reject or hold a build. Measure a fresh load, including external dependencies. - Maximum file count: 1,500 individual files after extraction, including all packaged files. A standalone HTML counts as one file; directories are not individual files. Remove unused assets and development output. The ZIP itself may be at most 550 MB (550,000,000 bytes); the 500 MB extracted-build limit still applies. There is no additional smaller per-file size cap: all files together must remain within 500 MB (500,000,000 bytes). Extension limits remain unspecified; see [Reference](docs-reference.html#unresolved-contracts). - Include only material intended for public distribution. Exclude credentials, `.env` files, private keys, private documents, chat histories, machine paths, editor caches and `node_modules`. Review source maps before including them. Example archive layout; runtime filenames and folders vary by engine: ```text build.zip index.html assets/ publishing/ (required) coverImage.webp (required cover image) ...other exported runtime files ``` ### Export by engine #### Three.js Run the project's production build command and package the resulting output. For a Vite project with a build script, this is usually `npm run build`; package the contents of `dist`, unless its configuration specifies another output directory. For portable Vite exports, use a relative base such as `base: './'` when appropriate. Recheck dynamically constructed asset URLs. A plain HTML/JavaScript project can be packaged directly if it runs without a build step. See [Vite production builds](https://vite.dev/guide/build). #### Godot Web Use a Web export preset and export directly as `index.html` into a clean folder. Keep all generated companion files, including JavaScript, WebAssembly and the game pack; do not rename exported files afterwards. For Godot 4, use the Compatibility renderer and a single-threaded export as the baseline. Threaded or extension-enabled exports require additional host isolation settings. Check language and export support for the installed Godot version before building; Godot 4 C# projects are not currently supported by its Web exporter. See [Godot Web export](https://docs.godotengine.org/en/stable/tutorials/export/exporting_for_web.html). #### Unity Web Select the Web target in the installed Unity version and make a production build into a clean folder. Package the generated `index.html`, `Build`, `TemplateData` and any other runtime folders it references. Preserve the loader's filenames and paths. Compressed files require matching server response headers; WebAssembly streaming also requires the correct content type. Use compression settings verified on the destination, or test Unity's decompression fallback when native compression headers are unavailable. Do not assume the host repairs compression settings automatically. See [Unity Web deployment](https://docs.unity3d.com/6000.3/Documentation/Manual/webgl-deploying.html). #### WebXR Package WebXR as a browser build using the same ZIP layout. WebXR is a browser capability, so use the export instructions for its underlying engine as well. - Deploy over HTTPS. Check for `navigator.xr` and support for the intended session mode before offering immersive entry. - Provide a clear Enter VR action initiated by the player. Handle unavailable support, declined permission and session exit without leaving the experience stuck. - Immersive entry depends on browser permissions and the host's Permissions Policy. Check the actual embedded player and any separate launch page; a working local page does not prove the hosted entry path works. - Provide a usable mouse-and-keyboard fallback. Identify the headset inputs actually implemented, such as controllers or hands; do not imply both work unless tested. - Test entry, interaction, exit and re-entry on the intended headset and browser. Record desktop fallback results separately from immersive results. Emulation is not headset validation. See the [WebXR specification](https://immersive-web.github.io/webxr/) and [WebXR permissions](https://developer.mozilla.org/en-US/docs/Web/API/WebXR_Device_API/Permissions_and_security). ### Preserve the intended experience - **Tech Demo:** a polished interactive idea, physics demonstrator, visually compelling or innovative experience. A loop is optional. It may omit features expected of a complete app or game, provided the demonstrated experience works and feels polished. - **Short Game:** a complete game deliberately made at a small scope, with a playable loop, a menu and an ending. It can remain in active development for improvements or expansion. - **World:** a coherent place to explore or inhabit, with usable UI and good UX. Make navigation, controls, interactions and feedback clear. A conventional game loop or ending is optional; VR support is a separate capability. Choose the type from the experience in the current build. Any type may still be in development, but the published build must already be polished and worthwhile. A separate title screen is not required. Before immediate threats or timers, a brief Ready or Start action gives the player time to prepare. Keep the game's intended aspect ratio; letterbox when needed rather than stretching or cropping essential play. Fit the embedded player: the game should fill its window and resize with it, with no page scrolling, because the player clips anything larger than the window instead of showing scrollbars (for Unity, use a responsive web template rather than a fixed-size canvas, and keep titles and instructions inside the game or in the project details). Keep instructions readable and make primary actions clear. Start audio in response to player interaction. Handle unavailable browser storage without breaking play. When the build contains flashing or strobing effects, the uploading LLM should add this exact small note as a plain-text paragraph in the public `description`: "Warning: Contains Flashing lights". Preserve existing copy, add the note once and keep within the description limit. If there is no other description, the note can stand alone. Include it in the description actually submitted. Do not add it indiscriminately or treat its absence as a declaration that the build has no flashing effects. There is no `flashingLights` metadata field and no extra required publishing question. Target PC, phones or both according to the experience. Declare `worksOnPhones` accurately: `true` when the core experience is usable with phone layouts and touch controls; `false` when phone gameplay is unsupported. The key is optional in `demo.json`, but a valid publishing answer is required without a default. Keep the capability declaration separate from actual device tests and report which devices and checks were used; do not infer it from screen width, touch detection, engine or VR support. Do not add phone support by redesigning an existing game without the creator's agreement. Where supported, make every essential action usable with the advertised inputs. For touch, check readable text, reachable controls, simultaneous touches when needed, and screen cutouts. On mixed-input devices, update hints from the input actually used rather than screen width alone. Device testing does not establish availability on a particular hosting service; check that service's current device support. ### Optional files and upload details The playable ZIP does not require a README, metadata file or prompts for ordinary publishing, but every build needs a [cover image](#make-a-cover). Every published build requires public creation-model attribution through `creationModels`, separate from the testing-model record. The optional One Shot label additionally requires public disclosure of the actual original creator prompt; do not claim it without those details. - `README.md`: concise player controls, credits and relevant runtime requirements. The optional `controls` field in `demo.json` can also provide instructions: 1–1,000 characters of plain text, with paragraph breaks allowed and no HTML or rich formatting. Describe actual actions for supported inputs; omit if unavailable without adding a required question. Keep development notes and private material outside the public package. - `demo.json`: an optional portable copy of project metadata. Required `engine` names the actual engine/framework; Unity, Godot, Three.js and HTML/JavaScript are examples only. Optional `engineVersion` sits beside Engine as Version (optional); include the actual version when known and omit it otherwise. These details can be supplied through MCP without a metadata file. The assistant supplies metadata primarily through the creator's authorised MCP connection; the creator does not need to write JSON or fill website upload forms. Use only documented keys and values in [Reference](docs-reference.html#metadata); do not invent a schema or make the game depend on metadata import. Keep existing valid metadata where applicable. If demo.json cannot be read, skip its metadata import and report the problem. For readable metadata, ignore invalid or unknown optional fields and return clear MCP warnings naming the affected fields and reasons; retain valid fields. Ask for missing required answers without re-entering valid details already available. Optional-metadata warnings alone do not reject or hold the build; package and playability checks still apply. Explicit publishing-request values take priority; valid packaged metadata fills gaps only. - `prompts.md`: relevant prompts the creator intends to share. Review for private information and credentials; do not include entire conversations. For a One Shot claim, the actual original creator prompt must be included and publicly disclosed alongside accurate creation-model information. One creator prompt allows autonomous AI building, testing and fixes, without follow-up creator instructions or manual game-code changes. If the required disclosure is unavailable or cannot be made public, do not apply the label. The `originalPrompt` metadata string holds the exact original prompt with its line breaks preserved; it is required and public for One Shot, optional otherwise. If supplied in `demo.json`, encode line breaks as `\n` within the string. Do not silently redact or rewrite it and still call it the original. Use `creationModels` for the AI models used to create the submitted build, including versions when known; this public information is required for every published build. The testing model is recorded separately in TESTING. Reuse accurate attribution; if the creation model cannot be established, record `Unknown` in the `creationModels` array, for example `["Unknown"]`. Keep any accurately known models when part of the attribution is unknown. Never infer creation models from the uploading or testing assistant, and do not use an empty array for uncertainty. Exact MCP handoff mechanics remain unresolved; do not invent further keys. A separate `prompts.md` file is not required. - The required cover image in `publishing/`, using the [publishing-folder convention](#publishing-assets) below and the rules in [Make a cover](#make-a-cover). Show a recognisable moment from the game with the game's name in the image. Keep it art-led; avoid extra slogans, paragraphs and a dominant background matching the site's `#171421`. #### Publishing assets Put publishing assets in `publishing/` at the build ZIP root. Every build needs its cover image here. Listing-cover discovery searches only inside this folder for these filename stems: - `coverImage` - `cover-image` - `cover_image` Use a PNG, JPEG or WebP extension: `.png`, `.jpg`, `.jpeg` or `.webp`. For example: `publishing/coverImage.webp`. Do not automatically import a file named simply `cover`, or search other game/runtime asset locations for a listing image. A game asset such as `assets/cover.png` is left alone. If more than one recognised candidate exists, the build is refused (`cover_ambiguous`) rather than guessing which image was intended. Keep exactly one recognised candidate. The folder and its cover image are required for every build. There is no `coverImage` metadata field; do not add one to `demo.json`. Package a self-contained HTML game as `index.html` in a ZIP alongside the `publishing/` folder; a single HTML file on its own can't carry a cover and is refused. Keep only material intended for public distribution in the package. The private TESTING confirmation still travels separately alongside the build; this folder does not replace that handoff. #### Make a cover The cover is a required upload step: every build needs one. AppAfterApp shows it on cards, the project page and the share preview. A build without a usable cover is refused at upload, before any checks run, with a message saying what to add or fix (see [cover codes](docs-publish.html#cover-codes)). - **Show the real game.** The cover must show what players actually get: the game's own characters, places and art style. Don't invent characters, scenes or features the game doesn't have, and don't use stock or third-party art unless the creator supplies it. Make it in one of these ways: - **Cover art**, when you can generate images: use an image-generation tool with screenshots of the real game as reference, and the prompt below. - **A designed cover**, when you can't generate images: draw an SVG from the game's own look (its colours, shapes and characters as they appear in the game), with the game's name as its title, then render it to PNG or WebP at 1600 × 1000, for example by screenshotting it in a browser. The cover file must be PNG, JPEG or WebP; SVG is not accepted as the cover. - **A screenshot of the game**: a representative moment, the game area only, without browser toolbars, cursors or debug overlays. Use a moment where the game shows its own name, such as its title screen, or add the name to the image as a clean title. - **Show the game's name.** The game's name must appear in the image, spelled as the project's title and readable at card size. A title or logo in the game's own style is ideal; keep it clear of the edges. The reviewer checks this by eye, because it can't be checked automatically. - **Size and format.** Landscape, ideally 1600 × 1000 (16:10); at least 960 × 600, at most 4096 px on each side and no more than 2 MB. WebP is preferred; PNG and JPEG also work. Keep the main subject near the middle: cards show 16:10, the player poster 16:9 and the phone launch cover 7:5. - **Name and place.** Save it as `publishing/coverImage.webp` (or `.png` or `.jpg`) at the ZIP root. Its extension must match its real format. - **Order.** Make the cover before the final package (`begin_testing` warns at once if it is missing or unusable), for example from screenshots taken during an earlier play, then build the final ZIP with `publishing/` inside and run `begin_testing` and the checklist on that ZIP. If only files in `publishing/` change after testing, the gameplay checks need not be repeated: run `begin_testing` on the final ZIP, load it once to confirm it starts, then `finish_testing` with the same honest results. Set `testedAt` to the time of that new run, because it must fall within the run, and say in `environment` that the gameplay results come from your earlier play of identical game files, with its time. A neutral prompt for cover art; fill in the brackets from the real game: ```text Cover art for the browser game "[title]". Base it on the attached screenshots of the real game: show only characters, places and objects that are in the game, in its own art style and colours. Scene: [main character] [doing the core action] in [setting]. Show the title "[title]" once, large and clearly readable, as the game's logo. Landscape 16:10, 1600 x 1000, main subject in the centre with space around the edges. No other text, buttons or interface, and nothing that is not in the game. ``` If the image tool garbles lettering, generate the art without the title, then add the game's name as a clean title, for example in an SVG rendered over the art. A build whose cover is missing or breaks the format and size rules is refused at upload; fix the cover, test the new ZIP and submit again. A new cover replaces the project's current cover only when its build publishes. Sealed builds never change, so a new cover for a live game needs a new build. ### Test the final package **Testing checklist version: 2026-10-26.2.** Record this version and the checklist link in the testing confirmation below. For a ZIP, extract the exact archive into a clean directory. For a single HTML, copy the exact file into a clean directory. Serve that final build over HTTP, or HTTPS for hosted WebXR tests. Run the project's existing build checks first, then test the exported files independently of the source project. Repeat the relevant checks in the hosted player after upload. - **Load (`LOAD`):** check asset requests, console errors, loading progress and the first usable frame. This catches missing runtime files and host configuration errors. - **Play (`CORE`):** sample a Short Game's playable loop and menu, and confirm its ending can be reached, for example through a level select, a short route or the end of the first level, without playing the whole game. If the ending can't be reached quickly, say so in the notes; that is not a failure. In a World, exercise navigation, interactions and UI. In a Tech Demo, exercise the polished core idea; a win state or menu is optional. Test start, pause, resume and retry where provided. Assess the current build rather than planned features. Play representative content on the intended hardware; report download, load-time or frame-rate measurements in this check's notes only when measured. - **Inputs (`INPUT`):** the optional `supportedInputs` array can list `keyboard`, `mouse`, `touch`, `gamepad`, `xrControllers` and `handTracking` where implemented. Remove duplicates; warn and ignore unknown values while retaining valid values. Omit if unavailable without a required publishing question. It is separate from VR capability, phone suitability, written controls and test evidence. Exercise every advertised keyboard, mouse, touch, gamepad or XR action. Check focus, unwanted page scrolling, held inputs and input switching where implemented. - **Layout (`UI`):** resize within supported layouts and orientations. Check embedded and fullscreen play where available, readable text, clipping and pointer/touch coordinates. - **Interruptions (`RETURN`):** leave and return to the tab or app. Check stuck inputs, audio, timers and progress; check headset session interruption where supported. - **Phones (`PHONE`):** when `worksOnPhones` is `true`, play on a phone or a phone emulator with touch: essential actions by touch, readable text, reachable controls, both supported orientations and screen cutouts. Say in the notes whether the device was real or emulated. When `worksOnPhones` is `false`, report Not applicable with that reason. - **WebXR (`XR`):** test the hosted immersive entry path, headset interaction, session exit/re-entry and desktop fallback separately. A 2D browser pass does not establish an immersive pass. When the build has no VR support, report Not applicable with that reason. Report exactly one result for each of the seven codes, `LOAD`, `CORE`, `INPUT`, `UI`, `RETURN`, `PHONE` and `XR`, with the outcome Pass, Fail, Not run or Not applicable. Every outcome other than Pass needs a brief note. Use the testing confirmation below to record actual actions, outcomes, failures and omissions. Do not add optional features just to satisfy a checklist or claim unperformed checks passed. Keep detailed diagnostic logs locally unless they are useful for a specific problem. **Keep testing proportionate.** Time-box the play-test: about 5 minutes, and at most 10 for a bigger game. Sample one representative level or run, the menu and a restart; do not play the game through. Do not build replicas of the AppAfterApp host, write browser automation or read platform source code to predict its checks: after upload the platform runs its own package, security and hosted checks, typically within about five minutes, and returns plain reasons if anything needs fixing. Play-test the final package yourself by default, in a browser you control; don't ask the creator to test it instead. If the browser fails, retry once. If it fails again, tell the creator what failed and offer choices worded from their side, naming who does what: "Me (the creator): I'll test it and tell you the results" or "Me: I already tested it". Ask it as a question of its own, not bundled with others. With either answer, record the creator as the tester, with only the outcomes they confirm, and mark anything they don't confirm Not run with the reason. Don't offer skipping testing altogether as a choice of its own. Either way, AppAfterApp's own checks still run after upload. An honest incomplete report (`false`) does not hold or reject a build by itself; it tells the reviewer what was not tested. Tell the creator what you are testing and roughly how long it will take, and stop extra testing when they ask. #### Testing confirmation Generate this compact section from the testing actually performed against the [Docs testing checklist](#test-the-final-package), using its link and the version actually followed. Do not require the creator to copy results into a form. ```text TESTING Play Testing (Docs testing checklist): true / false Testing instructions: [Docs link and version] Tested at: [UTC date/time] Tested by: [LLM/model, human, or unknown] Environment: [browser/devices; real hardware or emulated] Results / notes: [One line per check code: LOAD, CORE, INPUT, UI, RETURN, PHONE, XR. Pass / Fail / Not run / Not applicable. Briefly explain failures, known bugs and untested areas.] ``` `true` means all applicable prescribed testing was completed and recorded. It does not mean every check passed or the game is bug-free. `false` means testing was incomplete or not performed; explain what remains. Any applicable check marked Not run means the completion declaration is false. Use Not applicable only when the check does not apply, with a brief reason. The single declaration covers the Docs routine, including its bug checks; there is no separate bug-tested checkbox. Keep results short rather than repeating the instructions. Screenshots, videos and lengthy logs are not compulsory for ordinary submissions; include useful evidence when explaining a problem. Record the actual test date/time and tester identity; use human or unknown honestly when an LLM/model is unavailable. The defined publishing handoff sends this confirmation alongside the build through MCP, outside publicly served game files. The publisher helper attaches the exact tested build identity and hashes automatically, so the LLM does not copy them into this section. With the helper, `finish_testing` takes this report as typed keys (`docsTestingCompleted`, `instructionsUrl`, `instructionsVersion`, `testedAt`, `testedBy`, `environment`, and `results` with `check`, `outcome` and optional `notes`); follow its schema. Do not add a demo.json field or package file for it. The report is creator-reported evidence, separate from platform verification. Do not include credentials or private diagnostic material. With the publisher helper, `begin_testing` and `finish_testing` bind this section to the exact tested files; without it, return the section alongside the prepared artifact with its hash calculated by a real tool. Do not claim automatic upload binding or hosted tests occurred unless the tools confirmed them. If playable files change after testing, update the report for the new candidate and repeat the affected checks. ### Return a useful handoff Return the final ZIP, with its cover, and its SHA-256 hash, a short description of the export, prepared required submission details and the device-scoped test report. Keep package preparation, local tests, upload, publication and hosted play as separate results. If hosting settings or target hardware are unavailable, mark those checks Not run and give the reason. Do not present an untested build as verified, and do not invent an automatic rejection rule for unavailable local checks. The platform's required assessments must be completed before publication can pass. See [Reference](docs-reference.html#required-submission-details) for required details and [Connect and publish](docs-publish.html#report-back) for the result to give the creator. --- ## Connect and publish New games and replacement builds are published through MCP by signed-in creators. Creators manage only their own work. > **Private preview.** Publishing works for invited preview accounts through the AppAfterApp publisher helper: a local MCP server, named `appafterapp-publisher` (formerly `vibedemo-publisher`), that runs on the creator's own computer. Either name may appear in your client; they are the same tools. The hosted AppAfterApp connector is set up as in [Connect your assistant](#connect-your-assistant), but only invited preview accounts can approve it. Public sign-up and a downloadable helper are not available yet. If your client lists none of the AppAfterApp connector's tools, the `appafterapp-publisher` tools or the `vibedemo-publisher` tools, stop: return the prepared package and report **Not submitted: publisher tools not connected.** Do not invent a server URL, installation command, access token or successful upload. ### Connect your assistant > **Creators can't publish yet.** Only invited preview accounts can approve the connection, so for everyone else these steps stop at AppAfterApp's approval page. They are here so setup is ready when publishing opens. Add the AppAfterApp connector once in each app. Its address is `https://appafterapp.com/mcp`. The first time it's used, your browser opens AppAfterApp: sign in and press **Approve**. Uploading a build runs one command on your computer, so publish from an app that can run commands: the **Code** tab of the Claude desktop app, Claude Code in a terminal, or Codex. **Added AppAfterApp before?** Remove the connector you added earlier, then add it again with the steps below, so it uses `https://appafterapp.com/mcp`. In Codex, **Uninstall** the saved server first (in a terminal: `codex mcp remove` and its name). - **Claude desktop app, Code tab:** while signed in to claude.ai, open [Add AppAfterApp to Claude](https://claude.ai/customize/connectors?modal=add-custom-connector&connectorName=AppAfterApp&connectorUrl=https%3A%2F%2Fappafterapp.com%2Fmcp). Check the name and address, add it, then choose **Connect** to sign in. It then appears in local sessions of the desktop app's Code tab. On Team and Enterprise plans, an admin adds it. - **Claude Code in a terminal (beta):** add the connector with the same link. It appears in Claude Code when you're signed in with the same claude.ai account. The terminal asks you to sign in to AppAfterApp once more, even when the desktop app is already connected: run `/mcp`, choose **claude.ai AppAfterApp**, then **Authenticate**. On Windows, if PowerShell's script policy blocks `claude`, start it with `claude.cmd`. Having trouble? Email support@appafterapp.com. **Codex (beta).** For now Codex is set up by hand; a listing in OpenAI's directory will replace these steps. - **Codex app:** open **Plugins** → **MCPs** → **Add** → **Connect to a custom MCP**. 1. Choose the type **Streamable HTTP** first. The default, STDIO, looks similar but silently fails, with no sign-in button. 2. Name: `appafterapp`. URL: `https://appafterapp.com/mcp`. Leave Bearer token and Headers empty. 3. Save. Then open **appafterapp**, choose **Authenticate**, and press **Approve** on AppAfterApp's page. - **To change a saved server's type**, **Uninstall** it first, then add it again. **Codex in a terminal** takes two commands. The Codex app and terminal share these settings, so set up either one. ```text codex mcp add appafterapp --url https://appafterapp.com/mcp codex mcp login appafterapp ``` **Which account?** Your AppAfterApp account is whichever account your browser is signed in to on appafterapp.com when you approve. Check the name on the approval page. **If Codex stops showing the AppAfterApp tools, or doesn't offer to sign in,** its saved sign-in has expired, and reinstalling doesn't clear it. In a terminal, run `codex mcp logout appafterapp`, then `codex mcp login appafterapp`, press **Approve**, and restart Codex. On Windows, `codex` may not be on your PATH: it's at `%LOCALAPPDATA%\OpenAI\Codex\bin\\codex.exe`. Having trouble? Email support@appafterapp.com. The connector has three tools: `get_account`, `submit_build` and `get_submission`. `submit_build` takes the build's details, its TESTING report and the file's size and SHA-256, never its contents, and returns a one-time upload address. The assistant uploads the file there with one command, which the app asks you to approve, then calls `get_submission`. ### Client readiness The publisher helper is set up only on the preview owner's computer. There is no download or setup guide for it, so creators can't publish yet. | Client | Coverage | Private preview status | | --- | --- | --- | | Claude Code | MCP publishing through the local helper | Works on the preview owner's computer only. | | Codex | MCP publishing through the local helper | Not set up: Codex has no publisher tools yet. | | Claude Desktop | MCP publishing through the local helper | Works on the preview owner's computer only. | Use a client running on the creator's computer: the helper reads the package from local disk, so a cloud or browser-chat session cannot reach it. Website file-upload forms are not part of this workflow. ### Metadata through MCP The assistant fills in structured metadata through the creator's authorised MCP connection. The creator signs in and approves the connection in the browser when asked; they do not need to write JSON or fill in website forms. MCP is the primary submission route, and optional `demo.json` is a portable copy that fills gaps only. Explicit publishing-request values take priority. Submit the exact tested build, its metadata and the separate private [TESTING record](docs-reference.html#testing-confirmation) using the tools' own input schemas. Do not place private testing information inside publicly served game files. ### Publish step by step The helper has six tools. Read each tool's description and input schema before calling it; the schemas are authoritative. **Say this once, at the start of an upload.** Tell the creator in one or two sentences that uploading is mostly mechanical, so maximum effort is not needed (a fast model, or their usual model at normal effort, is enough), and how long your play-test will take: about 5 minutes, or up to 10 for a bigger game. You cannot change your own model or effort; the creator decides whether to switch before you begin. Play-test it yourself by default. If your browser fails, retry once; only if it fails again, say what failed and offer the creator's choices from [Keep testing proportionate](docs-prepare.html#test-the-final-package): "Me (the creator): I'll test it and tell you the results" or "Me: I already tested it". Ask the creator one question at a time, with clear choices where possible; never bundle questions. 1. **`connect_account`** opens the creator's browser to approve the connection; if that browser is not signed in to AppAfterApp, the creator signs in first and the approval continues. It returns the account it connected. The game belongs to that account. Confirm it is the account the creator intends. 2. **Add the required cover, then place the final ZIP in the helper's build folder.** Every build needs a cover at `publishing/coverImage.webp` in the ZIP: AI-generated cover art, a designed SVG rendered to PNG or WebP, or a screenshot of the game. It must look like the real game and show the game's name in the image; see [Make a cover](docs-prepare.html#make-a-cover). A single HTML file can't carry a cover: package it as `index.html` in a ZIP with the `publishing/` folder. The helper reads only that one folder, set when the helper was installed; paths are relative to it. A path on another machine, or outside that folder, is not reachable. 3. **`begin_testing`** with that `packagePath` stages a clean private copy and returns a `testRunId` and a `servedRoot`. Its warnings say at once if the cover is missing or unusable. Serve `servedRoot` from a fresh local static server, test it in a fresh browser context against the [testing checklist](docs-prepare.html#test-the-final-package), and do not edit its files. 4. **`finish_testing`** with the `testRunId` and the compact TESTING report from the actual testing. Unperformed checks are Not run, never Pass. 5. **`submit_build`** with the `packagePath`, the `testRunId` and the metadata. For a replacement, pass the existing project's `projectId`; do not create a duplicate project. It refuses a build without a usable cover before uploading anything; otherwise it uploads the package and returns an `operationId`, the `projectId` and a state. 6. **`get_submission`** with the `operationId` reports the current state. **`amend_submission`** corrects details, or attaches a newly finished test report, without uploading unchanged files again. Supply the title, build file, project type, phone capability, explicit Active yes/no, public `creationModels` attribution and the engine/framework in `engine`. Present optional `engineVersion` beside Engine as Version (optional); omit it if unavailable. Reuse existing valid values and ask for missing choices. If the creation model cannot be established, explicitly record `Unknown`; never guess or silently omit it. Optional files remain optional, including `demo.json`. Keep testing-model attribution in the separate private TESTING record. Ask once whether the creator wants the One Shot label, and explain it in one line: one creator prompt, with no follow-up instructions or manual code changes. It is the creator's call: follow their answer, and don't refuse or argue. If yes, send `oneShot` true and their exact original prompt, verbatim, as `originalPrompt`; it is shown publicly. If no, leave both out. For a replacement, preserve still-valid project details and the saved explicit Active answer unless the creator changes them. Reassess the submitted build's engine/version, creation models, capabilities and One Shot eligibility; use a fresh test run for the new files rather than inheriting stale claims. Reuse accurate information already available instead of asking the creator to re-enter it. ### Submission and checks The platform receives a candidate, checks the package and assets, and assesses isolated hosted gameplay, UX and UI. A candidate is not playable simply because the transfer succeeded. During the private preview, a person also plays each candidate before it publishes. Failed, suspicious, incomplete or uncertain assessments remain held with reasons; the live build stays untouched until a replacement passes. UX/UI findings block publication when they prevent normal play, such as essential controls that cannot be reached or required instructions that cannot be read. Cosmetic preferences and style suggestions are feedback, not blockers or review holds by themselves. Package/security and functional gameplay checks still apply. #### Cover codes A build without a usable cover is refused at upload, before any check runs. The helper's `submit_build` refuses it before uploading anything, and the platform refuses it again if a submission arrives without one or the received package's cover breaks a rule. The refusal gives a `code` and a message saying what to add or fix: | Code | Meaning | | --- | --- | | `cover_missing` | No `publishing/coverImage` file in the ZIP, or a single HTML file, which can't carry one. | | `cover_ambiguous` | More than one recognised cover file, so none was chosen. Keep exactly one. | | `cover_invalid` | The cover breaks a [format or size rule](docs-reference.html#build-limits): not a readable PNG, JPEG or WebP, an extension that doesn't match its real format, not landscape, smaller than 960 × 600, larger than 4096 px on a side, or over 2 MB. | Add or fix the cover, run `begin_testing` and `finish_testing` on the new ZIP, and submit again. The game's name on the cover can't be checked automatically, so the reviewer checks it; a cover without it, or one that doesn't look like the real game, can be held. Invalid optional metadata returns a warning and is ignored, keeping valid values. Such a warning alone does not reject or hold the build. Required details must still be valid. See [metadata](docs-reference.html#metadata). ### Understand the outcome | Returned state | What to tell the creator | | --- | --- | | `needs_information` | Required details are missing or invalid. Ask for them and correct the submission with `amend_submission`; the files already received are kept. | | `queued` / `checking` | The platform received the candidate and is checking it. The `phase` says which check is running; `manual` means it is waiting for the preview reviewer. It is not published yet. | | `held` | The checks did not pass. Report the returned reasons and the correction needed. Do not claim the game is live or promise a review time. | | `rejected` | The candidate will not publish. Report the reasons; a corrected build is a new submission. | | `ready_for_private_play` | Published to the private preview. The project's page now plays this build. | ### Interruptions and corrections Keep the `operationId` and `projectId` returned by `submit_build`. After a timeout or interruption, call `get_submission` before starting another submission. To resume an interrupted upload of the same unchanged package, pass the same `operationKey` to `submit_build`; changed files are a new test run and a new submission. Do not blindly duplicate uploads. Use returned errors to correct the affected file or detail while preserving valid information. Each correction through `amend_submission` takes a new `amendmentKey`; reuse a key only to retry the same correction. Review response times are not guaranteed. ### Report back Give the creator a compact, evidence-based result: - **Artifact:** filename, format, size, SHA-256 and engine/export version. - **Prepared details:** title, project type, phone capability, explicit Active answer, creation-model attribution including any explicit `Unknown`, Engine and optional Version; name any answers still missing. - **Tests:** browser/device, real hardware or emulation, actions and Pass / Fail / Not run / Not applicable with reasons. - **Submission:** not submitted (and why), or the returned `operationId`, `projectId` and state. - **Publication and play:** whether publication was confirmed, and which hosted checks were actually performed. - **Next action:** the specific correction, missing decision or remaining check. --- ## Update and manage A Project keeps its identity while its Builds change. Players follow the project; creators can publish new versions and explain progress through text updates. > **Defined launch behavior, unavailable in this preview.** Publishing, persistent accounts, project management, updates and Discussion have not been implemented here. This page explains the agreed workflow without claiming these actions currently work. ### Replace an existing build Prepare and test the new ZIP, with its own [cover](docs-prepare.html#make-a-cover), using [Prepare and test](docs-prepare.html). Every build needs a cover, a replacement too; a sealed build never changes, so a new cover for a live game needs a new build. When publishing becomes available, submit it through an authorized MCP connection against the existing project. Keep existing metadata unless the creator requests changes; explicit publishing-request values take priority over valid metadata inside the package. The current live build stays available while its replacement is checked. A failure or review flag leaves the live build untouched. A passing replacement publishes automatically after the required assessments. Successful replacement publication sends one follower notification; uploading alone sends nothing. Notification delivery details remain unresolved. Only the latest approved build is publicly playable in the defined launch workflow. Older builds are retained for recovery, with their existing build notes in Updates. There is no public build/version picker. Do not promise creator rollback controls or a particular recovery procedure; those operations remain unspecified. ### Manage project details The website's YOU dashboard and inline Manage area are the defined place for creators to manage their own project details and Active setting. New games and replacement files use MCP; website file-upload forms are not the launch publishing channel. Title, type, quick description and description edited there carry over to later builds unless a new submission sets them. When you publish a replacement, keep any packaged demo.json in step with the current project details, or leave those fields out of it. Active answers whether the creator is currently working on the project, independently of its type or VR capability. Tech Demos, Short Games and Worlds can all be Active. A Short Game can already have its complete loop, menu and ending while development continues to improve or expand it; a World can keep growing. The published build must already offer a polished, worthwhile experience. The `active` metadata field records the creator's explicit answer: `true` for current development, improvements or expansion; `false` otherwise. It is optional in `demo.json`, but an explicit valid answer is required before publishing. Reuse a valid creator answer already available; ask if missing, without a default or inference from recent edits. The badge is shown only while `active` is `true` and the last build or update is less than 60 days old. Badge visibility is separate from the saved answer. ### Post a text update Creators write standalone updates in YOU → Manage. Published posts appear in the project's Updates tab. No new build is required, and posting a standalone update sends no email. Keep this separate from the notification attached to a successfully published replacement build. Do not claim these website actions are MCP tools. The set of non-publishing MCP management tools is not specified. ### Discussion and creator replies Discussion supports Comments and Suggestions, both with +1 votes. Posts appear newest first; vote totals do not determine the default order. Each post can have one editable reply from the creator, displayed beneath it. There are no nested reply threads. Only Suggestions have creator-set status: - **Open:** unresolved; it is not a commitment to implement the suggestion. - **Built in vX:** implemented in the named build. - **Not planned:** the creator decided against it. Comments have votes without a status. Actions such as following, voting and posting require sign-in; public play does not require an account in the defined launch workflow. ### Visibility and availability **Listed** projects appear in Play and public creator profiles. **Unlisted** means link-only visibility. **Hidden** means removed from public availability because of a problem, with a reason for the creator. Visibility is separate from validation: Unlisted is not permission to serve an unchecked build. Public play requires the relevant safety checks and isolated hosting. The production controls for changing visibility and recovery are not specified here. Do not invent a creator control or promise immediate reinstatement. Lab and phone gameplay remain unreleased independently of project metadata and ordinary phone browsing. ### Get help The defined project-page help action is **Get help**, available to signed-in users. Send a short description of the problem; the request is associated with the project and build being viewed, the signed-in account and submission time. The defined process also records the submission IP address for 90 days, then deletes it. Retention of request text and account references is not yet specified. After the request is saved, show an on-screen acknowledgement. An email reply can be sent when needed; there is no automatic receipt email or in-site private support conversation in the launch workflow. Delivery arrangements and response times remain unresolved. This help flow is not working in the preview; do not claim a request has been sent from a prototype interaction. --- ## Reference The agreed authoring and submission contract, plus the details that are not yet specified. This page is not a live MCP schema or proof of hosting compatibility. ### Required submission details | Detail | Defined rule | | --- | --- | | Title | Plain text, 1–60 characters. Preserve spelling, capitalization and punctuation. Supply through MCP or ask if missing. | | Playable build | One ZIP with `index.html` directly at its root. A self-contained game goes in the ZIP as `index.html`; a single `.html` file on its own can't carry the cover and is refused. | | Cover image | Required for every build: exactly one `publishing/coverImage.webp` (or `.png` or `.jpg`) in the ZIP. AI-generated cover art, a designed SVG rendered to PNG or WebP, or a screenshot of the game; it must look like the real game and show the game's name in the image. Size and format are in [Build limits](#build-limits). See [Make a cover](docs-prepare.html#make-a-cover). | | Project type | Exactly `Tech Demo`, `Short game` or `World`, describing the current playable experience. Browse labels are Tech Demos, Short Games and Worlds. Optional in `demo.json`, required before publishing. VR capability and Active are separate. See [the definitions](docs.html#know-the-vocabulary). Exact MCP parameter names remain unresolved. | | Works on phones | Boolean `worksOnPhones`: `true` means the core experience is usable with phone layouts and touch controls; `false` means phone gameplay is unsupported. Optional in `demo.json`, but a valid answer is required before publishing without a default. Actual device-test evidence is separate. Capability does not release phone gameplay on the platform. | | Active | Boolean `active`: the creator's explicit answer about developing, improving or expanding the project now. Optional in `demo.json`, but an explicit valid answer is required before publishing. No default or inference from recent activity. | | Creation models | Public `creationModels` array of AI model names used to create the submitted build, including versions when known. Required for every published build, supplied through MCP or requested if missing; optional in `demo.json`. Keep testing-model attribution separate. | | Engine | Required plain-text `engine`, naming the engine/framework used for this build. Unity, Godot, Three.js and HTML/JavaScript are examples only. Supply through MCP or ask if missing; optional in `demo.json`. | | Version (optional) | Separate `engineVersion`, presented next to Engine. Include the actual engine/framework version when known; omit if unavailable. | README and metadata files are optional; a cover image is required. Original-prompt disclosure is required only for the optional One Shot label. Descriptions, tags and controls are normally optional. When flashing/strobing effects are present, the uploading assistant adds the exact warning note to description as specified below; this is not an extra creator question. Do not turn them into new required creator steps. Required details can come from the creator or existing accurate information; a metadata file is not required. ### Build limits | Measure | Defined rule | | --- | --- | | Total build size | Maximum 500 MB, meaning 500,000,000 bytes after ZIP extraction across all packaged files; for single HTML, measure that file. Compression does not increase the allowance. | | Initial download | Aim for no more than 50 MB before usable core interaction on a fresh load, including external dependencies. Guidance only: exceeding it alone does not reject or hold a build. | | File count | Maximum 1,500 individual files after extraction across all packaged files. A standalone HTML counts as one file; directories are not individual files. | | ZIP transfer size | Maximum 550 MB (550,000,000 bytes) for the ZIP itself. Total extracted content still cannot exceed 500 MB. A standalone HTML remains capped at 500 MB. | | Individual file size | No additional smaller per-file cap. One file may use the 500 MB allowance, provided all files combined remain within 500,000,000 bytes. File-type and safety checks still apply. | | Cover image | Required. PNG, JPEG or WebP, landscape, at least 960 × 600 and at most 4096 px on each side, no more than 2 MB; 1600 × 1000 (16:10) recommended. A missing cover, or one outside these limits, is refused at upload with a [cover code](docs-publish.html#cover-codes). | | Allowed extensions | Unresolved. Do not treat the packaging examples as a complete allowlist. | ### Metadata MCP is the primary metadata route: the assistant supplies structured fields through the creator's authorised connection. `demo.json` is an optional portable copy; explicit publishing-request values take priority and valid packaged metadata fills gaps only. The keys below define file metadata; exact MCP parameter names remain unresolved. | Key | Value | Requirement | | --- | --- | --- | | `name` | Plain-text public title, 1–60 characters. | Optional in `demo.json`; a valid title is required before publishing, supplied through MCP or requested if missing. | | `engine` | Plain-text engine/framework name. Examples: Unity, Godot, Three.js, HTML/JavaScript. These are examples only, not an exhaustive list or allowlist. | Optional in `demo.json`; required before publishing, supplied through MCP or requested if missing. See [Engine and version](#engine-and-version). | | `engineVersion` | Separate plain-text version of the engine/framework used for this build. Show next to Engine as Version (optional). | Optional. Include when known; omit if unavailable, without guessing or a default. | | `type` | Exactly `Tech Demo`, `Short game` or `World`. | Optional in `demo.json`; a valid type is required before publishing, supplied through MCP or requested if missing without a guessed default. | | `supportsVR` | Boolean: `true` declares immersive WebXR support; `false` declares no VR support. | Optional. Omission leaves support undeclared. Record actual headset inputs and tests separately. | | `worksOnPhones` | Boolean: `true` means the core experience is usable with phone layouts and touch controls; `false` means phone gameplay is unsupported. | Optional in `demo.json`; a valid answer is required before publishing, supplied through MCP or requested if missing without a guessed default. | | `active` | Boolean: `true` means the creator is currently developing, improving or expanding the project; `false` means they are not. | Optional in `demo.json`; an explicit valid creator answer is required before publishing. Reuse a valid answer already available or ask if missing. No default or inference from recent activity. | | `shortDescription` | Plain text, 1–110 characters, for the one-line catalogue description. Describe what the player does or experiences in the current build. No HTML or formatting. | Optional. Omit if unavailable; it adds no required publishing question. | | `description` | Plain text, 1–2,000 characters, for the fuller project-page description. Explain the current playable experience and what players can expect. Paragraph breaks are allowed; no HTML or rich formatting. | Normally optional. When flashing/strobing effects are present, the assistant includes the exact warning note below. No extra required creator question. | | `tags` | Array of names from the fixed list below, for example `["Puzzle", "Calm"]`. Remove duplicates; ignore unknown values with MCP warnings while preserving valid tags. | Optional. Omit if unavailable; it adds no required publishing question. A numeric tag-count limit is not specified. | | `controls` | Plain text, 1–1,000 characters, explaining actual controls for supported keyboard/mouse, touch, gamepad or headset inputs. Paragraph breaks are allowed; no HTML or rich formatting. | Optional. Omit if unavailable; it adds no required publishing question. Instructions do not establish capability or device-test evidence. | | `supportedInputs` | Array containing only `keyboard`, `mouse`, `touch`, `gamepad`, `xrControllers` or `handTracking`. List implemented support only. Remove duplicates; ignore unknown values with MCP warnings while retaining valid values. | Optional. Omit if unavailable; it adds no required publishing question. VR, phone suitability and actual test evidence remain separate. | | `credits` | Plain text, 1–2,000 characters, crediting contributors, assets, audio and tools as appropriate. Paragraph breaks are allowed; no HTML or rich formatting. Include only credits intended for public display. | Optional. Omit if unavailable; it adds no required publishing question. | | `oneShot` | Boolean claim for this build: one creator prompt, with autonomous AI building, testing and fixes; no follow-up creator instructions or manual game-code changes. | Optional. The label requires the actual original prompt to be included and publicly disclosed with accurate creation-model information. False or omission does not apply the label. See [One Shot](#one-shot). | | `originalPrompt` | Plain-text string containing the actual original creator prompt, preserved verbatim with its line breaks. Display as literal text. | Required and public for One Shot; optional otherwise. Optional in `demo.json`; a metadata file is not required. Never invent, rewrite or summarise the original. See [Original prompt](#original-prompt). | | `creationModels` | Array of AI model names used to create the submitted build. Include versions when known; do not guess. Use `"Unknown"` for unavailable attribution, for example `["Unknown"]`. | Required and public for every published build. Optional in `demo.json`; supply through MCP or ask if missing. Keep the model that only tested the game separate. See [Creation models](#creation-models). | ```json { "name": "Magnet Run", "engine": "HTML/JavaScript", "shortDescription": "Pull magnets into place and guide the ball to the exit.", "description": "Guide a ball through compact magnetic puzzles.\n\nExperiment with magnet placement to find a route to the exit.", "type": "Short game", "tags": ["Puzzle", "Calm"], "supportedInputs": ["mouse", "xrControllers"], "controls": "Mouse: drag magnets into position.\n\nVR: point at a magnet, hold the trigger and move it.", "credits": "Design and development: the project creator.", "supportsVR": true, "worksOnPhones": false, "active": true, "oneShot": false, "creationModels": ["Unknown"] } ``` For `description`, `controls` and `credits`, represent paragraph breaks as `\n\n` inside the JSON string; show them as paragraph breaks when displaying the text. `supportedInputs` names implemented input support; `controls` explains the actions. `xrControllers` means tracked XR controllers, and `handTracking` means tracked hands. Neither declares immersive VR by itself: `supportsVR` remains separate. Likewise, `touch` alone does not establish `worksOnPhones`. Keep actual device/headset tests separate from these declarations. There is no `playTime` metadata field. If useful, mention duration naturally in `description`; do not invent an estimate. Cover images use the [publishing-folder convention](docs-prepare.html#publishing-assets), with no `coverImage` metadata field. Other metadata keys and exact MCP parameter names remain unresolved. Use only the documented file keys, and follow the actual published MCP schema when available. The example illustrates field syntax, including an explicit unknown-attribution value. Use actual known creation models whenever available, or `Unknown` when they cannot be established. Supply accurate values for the build, including the creator's explicit Active answer; the example does not establish One Shot eligibility. `active` applies to all three types independently of VR and phone capability. A complete Short Game can remain Active for improvements or expansion. The badge is displayed only while `active` is `true` and the last build or update is less than 60 days old. Badge visibility is separate from the creator's saved answer; do not infer that answer from activity or from the badge. `worksOnPhones` applies independently of type, Active and VR. Do not infer phone suitability from the engine, viewport width, touch detection or `supportsVR`. Record actual device tests separately, including devices and checks performed; this declaration does not certify every phone. Unknown suitability is not a default `false`: obtain a valid answer before publishing. Phone gameplay on the platform remains unreleased independently of this metadata. Tech Demo covers a polished interactive idea, physics demonstrator, visually compelling or innovative experience; a loop is optional and it may omit features of a complete app or game. Short game is deliberately small but complete, with a playable loop, a menu and an ending. World is a coherent place to explore or inhabit, with usable UI and good UX; a conventional game loop or ending is optional. Any type can be in active development, including a complete Short Game being improved or expanded. The current build must already be polished and worthwhile. There is no separate In development type. Active and VR capability remain separate from type. A normal screen-based 3D scene does not establish immersive VR support, and declared `supportsVR` capability does not establish real-headset verification. Explicit publishing-request values take priority. Valid packaged metadata fills gaps only. For example, if the explicit request title is Moon Runner and `demo.json` says Space Game, use Moon Runner. This precedence does not override security, playability or publication checks. If the file cannot be read or parsed, skip its metadata import and report the problem. If readable metadata contains invalid or unknown optional values, ignore those values, retain usable fields and return clear MCP warnings naming the affected fields and reasons. The warning alone does not reject or hold a build. Required details and all normal package and gameplay checks still apply. ### Labels and optional details Allowed `tags` values are Experience, Arcade, Puzzle, Racing, Platformer, Horror, Audio, Calm, Retro, Sim, Story and Toy. Supply them as an optional array using these names. Remove duplicates; ignore unknown values with an MCP warning and retain valid tags. Unknown values are not published as project tags. A numeric tag-count limit is not specified. One Shot is an optional build label and discovery filter. It is independent of project type and is not a guarantee of quality. See the [One Shot challenge](docs.html#one-shot-challenge). #### One Shot One Shot means **one creator prompt**. The AI can build, test and fix autonomously; the creator provides no follow-up instructions or manual game-code changes. The first generated output does not have to work without fixes. The labelled build **must include and publicly disclose the actual original creator prompt**, alongside accurate creation-model information. Never invent or rewrite an original prompt or infer eligibility from an engine or tool. Share only creator-approved public material; do not copy private chat histories. If the prompt/model disclosure is missing or cannot be shared, the build cannot receive the One Shot label. Other projects do not need original-prompt disclosure, but `creationModels` attribution is required for every published build. The `oneShot` claim applies to the individual build. False or omission does not apply the label. Assess a later creator-directed revision for its own eligibility instead of inheriting an earlier claim. Normal packaging, quality and Docs-based testing requirements still apply. Creation models are recorded in `creationModels` for every published build; the original prompt remains specific to One Shot. Exact MCP disclosure handoff mechanics are not yet defined. Do not mistake the testing LLM/model for the game's creation-model attribution. ##### Original prompt `originalPrompt` contains the actual original creator prompt as a plain-text string. Preserve its wording, punctuation and line breaks verbatim. In JSON, encode line breaks as `\n`; display the decoded text with those line breaks preserved. Treat any markup in the prompt as literal text, not executable HTML. The prompt is required and public for One Shot, optional otherwise. It may be supplied in optional `demo.json`; the metadata file itself is not compulsory. Explicit publishing-request values take priority over packaged metadata, and the selected value must still be the actual original prompt. Use only the original prompt the creator intends to publish. Do not invent, rewrite, summarise or silently redact it and present the result as the original; do not copy private conversation history. If the actual original prompt is missing, invalid or cannot be shared publicly, the build cannot receive the One Shot label. That alone does not prevent ordinary publication when its normal requirements are met. Invalid optional values are ignored with an MCP warning, preserving other valid metadata. #### Engine and version `engine` names the actual engine or framework used to create the submitted build. It is required before publishing, supplied by the assistant through MCP from accurate project/build information or requested if missing. Unity, Godot, Three.js and HTML/JavaScript are examples only, not a complete list or an engine-name allowlist. `engineVersion` is a separate optional plain-text string. Present it next to Engine with the label **Version (optional)**. Include the actual engine/framework version used for the build when known; omit it if unavailable. Do not guess or substitute the latest version. The example above omits this optional field. Both keys are optional in `demo.json`, because the file itself is optional; a valid engine answer is still required before publishing. Existing MCP-request-first precedence and invalid-optional-file-value warning/ignore rules apply. Naming an engine does not certify hosting compatibility or bypass normal package and gameplay checks. WebXR is a capability, separate from engine/version; `supportsVR`, headset inputs and real-device testing remain distinct. #### Creation models `creationModels` is an array of the AI model names actually used to create the submitted build. It is required and public for every published build, whether or not the build is One Shot. Include model versions when known; do not guess names or versions from the editor, MCP client or engine. The field is optional in `demo.json`, because the metadata file itself is optional. Reuse accurate information already available or obtain it through the publishing handoff; ask if missing, without a default. Explicit publishing-request values take priority over valid packaged metadata. Invalid optional file values are ignored with an MCP warning, but valid required creation-model information is still needed before publishing. Keep this attribution separate from the testing LLM/model in the private TESTING section. A model used only to test is not a creation model. If the same model performed both roles, record it accurately in each place. When the creation model cannot be established, include the exact string `Unknown`, for example `"creationModels": ["Unknown"]`. Keep known model names and versions if only part of the attribution is unknown, and use `Unknown` for the unknown remainder. Do not infer creation models from whichever assistant uploads or tests the build. Missing data or an empty array is not an explicit unknown answer. `Unknown` is a valid recorded answer; it is not verified model identity or proof of One Shot eligibility. The normal One Shot disclosure and testing requirements still apply. Exact MCP wire/disclosure implementation remains unresolved. #### Publishing artwork Every build needs one still cover image in `publishing/` at the ZIP root, with the stem `coverImage`, `cover-image` or `cover_image` and a PNG/JPEG/WebP extension. Discovery searches only this folder; generic `cover` files and other game assets are not imported automatically. Multiple recognised candidates are refused (`cover_ambiguous`) rather than guessed. No `coverImage` metadata field is defined. Follow [Publishing assets](docs-prepare.html#publishing-assets). Accepted covers are AI-generated cover art, a designed SVG rendered to PNG or WebP, or a screenshot of the game. Whichever kind, the cover must look like the real game (its own characters, places and art style) and the game's name must appear in the image. Stay art-led and avoid a dominant background matching the site's `#171421`; avoid extra slogans, paragraphs and promotional labels. Size limits are in [Build limits](#build-limits); follow [Make a cover](docs-prepare.html#make-a-cover). The format and size rules are checked automatically at upload; the name and the likeness are checked by the reviewer. #### Flashing effects When the build contains flashing or strobing effects, the uploading LLM should add this exact small note as a plain-text paragraph in the public `description`: "Warning: Contains Flashing lights". Preserve existing copy, add the note once and keep within the description limit. If there is no other description, the note can stand alone. Include it in the description actually submitted. Do not add it indiscriminately or treat its absence as a declaration that the build has no flashing effects. There is no `flashingLights` metadata field and no extra required publishing question. ### Hosting compatibility The defined player uses a separate game domain and a sandboxed iframe. The production domain, exact headers, iframe permissions, network restrictions and browser/device compatibility matrix have not been published or verified. A local export pass does not prove hosted compatibility. - **Assets:** use relative paths and bundle every dependency. During the private preview no outside host is allowed: scripts may load only from the game's own address, and the hosted check holds any build that requests another host. A shared-CDN allowlist may come later; none applies now. - **Godot:** use the documented single-threaded Web baseline. Threaded or extension-enabled exports require additional isolation support; do not assume it is available. - **Unity:** preserve export folders and filenames. Verify compression headers, content types or decompression fallback on the destination; automatic repair is not promised. - **WebXR:** requires HTTPS, player-initiated entry and actual browser/host permissions. Verify hosted entry, headset inputs, exit/re-entry and desktop fallback independently. No headset/browser combination is certified by this preview. - **Audio and storage:** begin audio through player interaction and handle unavailable browser storage gracefully. Do not assume persistent saves, cloud saves or a platform SDK. Follow the version-specific sources linked in [Prepare and test](docs-prepare.html#export-by-engine). ### Testing confirmation The uploading assistant generates the compact [TESTING section](docs-prepare.html#testing-confirmation) against the [Docs testing checklist](docs-prepare.html#test-the-final-package). It records the Docs-specific completion true/false, testing-instructions link/version, actual UTC test date/time, tester, environment and concise outcomes/notes. True means all applicable prescribed testing was completed and recorded; it does not mean bug-free or that all checks passed. The defined handoff sends this section alongside the build through MCP, outside publicly served game files. Upload tooling is to attach the exact tested build identity/hash automatically. Exact wire keys/schema, transport/binding implementation and intake handling remain unspecified. Do not invent a demo.json key, compulsory package file or MCP argument. In the private preview the publisher helper's `finish_testing` tool carries it; without the helper, return the prepared section with the artifact and real computed hash. ### Unresolved contracts The following details cannot yet be used as instructions: - MCP server address, connection transport, authorization setup and verified client file handoff. - Exact tools, input/output schemas, upload/status identifiers, status strings, retries and recovery mechanics. - Remaining file metadata keys and exact MCP disclosure mechanics, archive protections and extension rules. - Production hosting headers, permissions and verified device coverage, and any future allowlist of outside hosts (none applies in the private preview). - Detailed validation coverage and measurable criteria, review response times, recovery and appeal procedures. - Notification delivery details and creator visibility/recovery controls. Until a contract is published and the relevant service is available, prepare what can be checked locally, retain the artifact and report the specific limitation. Do not fill gaps with invented defaults, endpoints or claims of support. ### Common questions #### Can an assistant publish just by reading this page? No. It needs a working authorized MCP connection and access to the exact artifact. Publishing is a private preview for invited accounts through the local publisher helper. #### Do I need to pack source code or prompts? Supply the production runtime build with its cover image; source code is not required. README and metadata files are optional. The optional One Shot label requires public disclosure of the actual original prompt through `originalPrompt`, alongside accurate creation-model information. Other projects do not need prompt disclosure. Only share material intended for public distribution. #### Does touch support mean the game is available on phones here? No. Device capability and platform availability are different. Mobile Games is not publicly released. Phone browsing remains distinct from phone gameplay. #### Does a cosmetic suggestion prevent publication? No. Style suggestions alone do not block or hold a build. Required security, functional gameplay and play-preventing UX/UI checks still apply. #### Does upload mean published? No. Check the actual returned status. Publication confirmation and successful hosted play are separate evidence.