{"doc":"how-it-works","title":"How it works","markdown":"# How it works\n\nGamestage is six parts.\n\n**The creator's web app or page:** your HTML, CSS and JavaScript. It draws the\ngame, takes the fan's input and renders whatever the Engine returns. Gamestage\nnever edits this for you: its tooling advises your agent what to write.\n\n**The CLI, `gamestage`:** a local tool that inspects a project, scaffolds a new\none, writes the browser client and validates the App Manifest, all with no\naccount. Serving the real Engine rules on your machine and proving the\nmigration each need you signed in, and deploying needs that account\napproved.\n\n**The Engine:** the server that owns a game's truth. It holds the answer,\ncounts attempts, decides whether a play is accepted and commits the score. One\nEngine runs one rule set per game format, and nothing in it knows what sport\nor subject your game is about.\n\n**Backstage:** the API that knows about workspaces, games, plans, limits and\ndeploys. It is what the CLI signs in to.\n\n**[Monterosa](https://www.monterosa.co/) [Interaction Cloud](https://products.monterosa.co/mic/core-concepts):**\nthe platform underneath live games. A Gamestage game is a\n[project](https://products.monterosa.co/mic/creator-guide/projects) on it, a\nnamed run of the game is an\n[event](https://products.monterosa.co/mic/core-concepts/schedule-and-events),\nand one go at the game is an\n[element](https://products.monterosa.co/mic/reference/core-platform/elements).\n\nEvery deployed game is provisioned into Interaction Cloud, Starter included: a\ndeploy always creates its project, event and containers on the platform. What\nchanges above Starter is the Space it runs in, Studio access for content and\nlive operations, and routing analytics to your own destinations, not whether\nprovisioning happens.\n\n**Monterosa Studio:** the platform's own CMS and live operations UI, and where\ncontent is managed above Starter. A producer working in Studio can\nchange a game's styling and copy, for example. Gamestage has no content editor\nof its own.\n\n## The request path\n\n```\nFAN'S BROWSER ENGINE BACKSTAGE\n page + gamestage.js\n │ GET /play/v1/games/{game}/rounds/current\n │────────────────────────────►│ public part of the round only\n │◄────────────────────────────│ board, labels, prompt. no answers\n │\n │ POST /play/v1/games/{game}/rounds/{round}/plays\n │────────────────────────────►│ marks against the private material\n │◄────────────────────────────│ outcome, feedback, committed score\n │\nCREATOR'S TERMINAL │\n gamestage deploy ──────────────────┴──────────────►│ plan, limits, publish\n```\n\nEverything a fan's browser can reach is on `/play/v1`. The creator's own\ncommands go to a different prefix on a different credential, so a fan holding\na page has nothing that reaches a creator's workspace.\n\n## Why the answers live in the backend\n\nAnything the browser holds, the fan holds. When the page is delivered to the\nfan's machine, its source, its bundles and every JSON file beside it can be\nread, changed and replayed. A score the page works out is a score anybody can\nsend, so anybody can send a better one. A limit of three goes kept in device\nstorage comes off in one line in a developer console.\n\nThe line is drawn at who decides, not at where the code sits. The page owns\nwhat it looks like and what the fan touches. The Engine owns anything a fan\nwould benefit from lying about: the answer, the score, the number of attempts,\nwhether play is open, and settlement. Every rule in the chapters that follow\ncomes from that line.\n\nSo deleting the answers from the page is only half of it. They move into the\nprivate part of the App Manifest, and a deploy hands them to the Engine. A\nclean page with nothing on the server leaves the Engine nothing to mark\nagainst.\n\n## The journey, in one pass\n\nFive steps, each ending in something the next one can rely on. [The\njourney](/docs/journey) breaks the same route into finer steps, most with\ntheir own command.\n\n**Inspect the game.** `gamestage inspect .` reads the source without changing it\nand reports what the browser owns that it should not: answers, scoring,\nlimits, clocks and locks, each with the file and line. You get an inspection\nreport and a proposed App Manifest.\n\n**Move authority.** The agent edits the manifest and the page. Private\nmaterial goes into the server-owned container in `gamestage.yaml`, and the\npage changes to render Engine state rather than its own. At the end of this\nstep the browser holds no answer and has no second scoring path.\n\n**Run the rules locally.** `gamestage dev` needs you signed in, then serves\nyour own container through the same rule set the hosted Engine runs, so the\ngame is playable against a real Engine on your own machine.\n\n**Verify the result.** `gamestage verify` runs seven checks against your\nmanifest and the published bundle (the round is the game's own, the attempt\ncap was chosen rather than defaulted, no answer sits in what a deploy\npublishes, the page reads every setting a producer can change, the client is\npresent and is the only door to Monterosa, a deadline comes from the server's\nclock) plus two that need a real browser playing the game (the screen shows\nwhat the server decided, and the page notices the connection going and coming\nback). Each check ends up verified, open (something is wrong) or skipped\n(this cannot be checked from here, which is not the same as failing). It only\ncounts as verified if nothing is open and nothing is skipped.\n\n**Publish.** `gamestage deploy --dir .` publishes a snapshot and\nputs a round on it. A person approves identity and GitHub first, and the\naccount itself has to be approved before a deploy goes through.\n\nThe detail of each step is in [Build and deploy](/docs/migration).\n\n## Where a human takes over\n\nThe agent does the migration, and a person owns identity, commercial decisions\nand anything that changes what a live audience can touch. An agent that reaches\none of these should stop, say why, and hand over the exact command.\n\nTwo commands need a browser and therefore a person:\n\n```sh\ngamestage login\ngamestage link github\n```\n\n`login` starts a login device flow: the command prints a code and a URL and\nwaits for approval, and it creates an account when none exists. The resulting creator token is\nstored in the macOS keychain for example, or in an owner-only file outside the\nproject, and never in game code. `link github` is a second device\nflow, and the first hosted deploy is refused until it is done: it gives a\ndeployed game a route back to its creator and makes account farming\nexpensive.\n\nThree commands change what fans can reach, so a person decides:\n\n```sh\ngamestage suspend \ngamestage wake \ngamestage archive \n```\n\nSuspend takes a game off the air and frees its live slot. Wake puts it back\nwhen a slot is available. Archive takes it off the air for good while keeping\nits record, its claimed id and its files. Delete exists only for a game that\nwas archived without ever deploying: `gamestage prune` clears that debris,\nand nothing removes a game that ever went live.\n\nSome inputs cannot be inferred from code at all. If no built game format fits\nthe mechanic, a person decides whether it merits a new format or bespoke\ncustomer work. Age gates, consent, privacy and promotion rules depend on facts\noutside the repository. Ownership, supplier licences and allowed use need\nconfirming. So does the operating model: who changes content, who watches a\nlive game and what service level is needed. Record what a person decided as\n`human_decision` provenance; an agent's proposal stays `proposed`.\n\nOnly a person can mark a manifest section `approved`, and the named owner\nshould check the linked evidence rather than the prose. Particular checks:\nconfirm the identity issuer, keys and token lifetime; confirm the minimum age\nand the basis for it; supply promotion terms, jurisdictions and either a free\nentry route or the legal basis for a skill competition; and play the final\nbuild at phone and desktop widths, because a skipped browser check is not\napproval. Build stage does not measure accessibility, so a high stage is not\nevidence of WCAG compliance.\n\nMoving to a paid plan is a conversation with Monterosa. A paid customer needs a\nMonterosa account and org created by support, and the service account\ndeliberately cannot create an org itself. See\n[Plans and limits](/docs/starter-plan).\n"}