Runbook

For: the person who operates this product. That means running it on a laptop, putting it on staging, putting it in front of players, and finding out what went wrong when it misbehaves.

One person holds every one of those roles here. The pages below are written so that none of them needs a second person, a remembered detail, or a search through source to get through a job.

The pages

Page	Answers
Run it locally	What to install once, what to run every time, which ports come up, and how to stop cleanly.
Cloudflare	What exists in the Cloudflare account, which binding is which, and where to click for logs, storage and domains.
Deploy to staging	The command, the preconditions, what to check afterwards, and how to reset the environment.
Deploy to production	The same, plus what is irreversible and what a rollback costs.
Data and stores	Where the game state actually lives, how to read it, how to change it, and how to get a copy out.
Credentials and access	Every login, key and token this product needs, where each is obtained, and which one a given job wants.
iOS	What exists for iOS today, and the route from this repository to a device and to the App Store.
Android	The same for Android and Google Play.
Desktop	The desktop shell: building it, smoke-testing it, and shipping it.
Debugging	Reading logs, reproducing a report, and the failures that have already cost time once.

The rule these pages follow

No page here contains a credential value. Every page names the credential it needs, states where that credential is obtained, and stops. Credentials and access is the index of those names, and it holds no values either.

Where the tooling cannot do something, the page says so instead of describing the thing it cannot do. A runbook that describes an imagined procedure is worse than one with a gap in it, because the gap is visible and the imagined procedure is not.

Before anything else

Three facts decide most of what follows.

The product runs in three environments — dev, staging and production — from one build with environment-selected configuration and three separate stores. Production is never wiped; staging is reset freely; dev is disposable.

The gate is the arbiter of whether a change may ship. npm run check runs it, locally and in continuous integration alike. A red gate is a stop, not a warning.

The server is a Cloudflare Worker with a Durable Object holding the universe. The game state is therefore not in a database you can open with a client: it lives inside a running object. Data and stores is the page that explains how to reach it.