11. The game factory

11. The game factory

"Efficiency of the game platform depends on how quickly and successfully we can build and launch the NEXT game."

(operator, decision 44, 2026-10-19)

The factory turns "a new game" into "a new game's gameplay". Everything the gates check (saves, text, input,
layout, pause, calm mode, dialogs, leaks) is owned by one small runtime and proven by one command, so a builder writes
only the rules of the game and a game is very likely to pass every gate the first time.

All commands run from MM/ (maneet-games/master-mind/). Node 18+ (Node 20 is fine: the scripts
add --experimental-websocket themselves), Python 3, Google Chrome.

1. Quick start: create → build → check → release-prep → publish

node ci/create-game.mjs star-catch --kind arcade --name "Star Catch" --emoji "⭐" --color "#ffb703" \
     --desc "Catch the falling stars." --cat arcade          # 1 create (never overwrites anything)
open games/star-catch/index.html                             # 2 build: replace the GAME part of the script
node ci/game-check.mjs star-catch                            # 3 check: every gate, ~1.5 min, table + logs
node ci/game-check.mjs star-catch --full                     #   release grade, ~6 min
node ci/release-prep.mjs star-catch                          # 4 release-prep: freeze + full gates + packet
#                                                              5 publish: a person / the coordinator (§5)

Kinds (six; each is a small working game that already passes every gate; change it, don't start from blank):

2. What create-game writes

factory/ is outside games/, so none of it is shipped by the pipeline.

3. The runtime: games/_factory/kit2.js

One file (v2.4.0, ~610 lines, no build step) plus vmath.js (VMath 1.1.0); API reference with examples: MM/games/_factory/README.md. What a game
gets without writing it, and the lesson behind each:

Why _ordie/core.js is loaded by every factory game: it holds THE display sink. Wrapping it (not copying it) keeps
one sink rule for the whole platform. Cost: 77 KB per game. Proposal P1 moves the sink to _shared/display-sink.js
(proposals (../proposals/2026-10-19-game-factory-shared-changes.md)).

Verified maths: games/_factory/vmath.js

Operator, 2026-10-19 (mnp-review/analysis/matiz-games-mapping.md recommendation 1). Exact BigInt rationals and answer
equivalence (1/2 = 0.5 = 2/4 = 50%), and validateQuestion(q): one accepted answer (identities and no-solution items
rejected), an independent recomputation, distinct options with exactly one equal in value to the answer, clean display,
no parity giveaway on prime questions. A maths game declares pure generators in <script id="k2-maths"> and shows items only
through VMath.draw. ci/factory-maths.mjs runs every declared generator over 10,000 seeds in game-check (advisory:
shown in the table and metrics, not in the verdict). The module is standalone so ci/math-question-test.mjs (another
builder, for Whetstone and Color Monster Academy) can import it (loadVMath in ci/factory-maths.mjs). API: MM/games/_factory/README.md.
The maths template's two generators: 10,000 / 10,000 valid each.

4. The gates: ci/game-check.mjs <id>

One command, a staged copy (~/.cache/claude-scratch/game-factory/runs/<id>/<stamp>/), a pass/fail table, a log per
gate, the sha256 of the tested bytes, and an entry in ci/factory-metrics.json. Staging means other builders'
in-flight edits cannot change a result half-way, the hashes say exactly what was tested, and the pipeline's dist/
and reports never touch the shared tree. The copy (only) gets longer Chrome timeouts (≥ 180 s instead of 60 s; one
Chrome at a time above half load), so a slow hub page on a busy machine does not turn into a red gate; the report says so.

Chrome lifecycle: every run is guarded (ci/factory/chrome-guard.mjs): exit/signal handlers and a detached watchdog
(chrome-watchdog.mjs) stop the run's Chromes and orphaned gate processes if game-check is killed (tested: SIGKILL
mid-gate, 11 → 0 processes in 15 s), and leftovers after each gate are stopped and noted. It only ever touches processes
inside the run folder it owns, or whose cdp profile names a gate pid it spawned. node ci/cleanup-orphans.mjs lists
Chromes whose owner pid is dead (--all-cdp for any cdp run, --kill to stop them). The upstream fix for ci/cdp.mjs
is proposal P11.

Exit 0 = all green; 1 = a game gate failed; 3 = only estate gates (shared files the game cannot fix) failed.
Options: --full, --in-place, --keep, --no-metrics, --json <file>, --root <master-mind>,
--remote oldisgold.local (stages here, rsyncs to ~/game-factory/runs/ there, runs with that host's Chrome
~/mm-runner/bin/chrome, copies the logs back).

Factory static F01–F08 (stricter than the platform rules on purpose: the kit owns every text write):
F01 no dynamic text write outside the sink (DOM properties, {textContent:}, insertAdjacentHTML, createTextNode,
document.write, text attributes, append of strings, canvas fillText/strokeText), with a / sink-ok: reason /
escape hatch; also every aria-, value, document.title and ariaLabel · F08 (D45) every input boundary in the
game file (.value reads, message events, fetch/XHR/WebSocket, clipboard, URL, MM.data reads, <input>/<textarea>/
contenteditable) goes through G.ingest/G.textInput · F02 every string in a / kit2:answers */ list passes kidsafe.js (also upper-cased); word and
…or Die games must have one · F03 script load order · F04 no storage writes outside the kit · F05 versioned, stable
save key · F06 no CSS text-transform · F07 (warn) raw timers and listeners. --selftest plants a bug for every rule
and checks every template is clean.

Factory probe P01–P36 (real Chrome, the game in a fake hub iframe, real CDP touch and keys): P01 boot in the hub ·
P02 Play by touch · P03a sink masks blocked words (also after upper-casing) · P03b sink fails closed when the
…or Die core is missing · P03c no blocked word in any shown text or text attribute on the title, play and results
screens (also upper-cased) · P04 hidden → paused with game-time frozen · P05 dialog focus trap and Escape · P06 keys,
blur releases · P07 two-finger pad ownership · P08 gamepad press and release · P09 5 rounds leave no leaked kit
listeners, timers, scopes, disposables, raw intervals or raw window/document listeners · P10 calm follows OS
reduced-motion unless the player chose · P11 a round's result reaches the cloud, survives reload, keeps an unknown
field · P12 a player switch mid-round leaks nothing · P13 a newer-version save present at boot is never overwritten ·
P13b one arriving from another device mid-round (through the SDK's real cloud merge) is kept on the device and in
the cloud · P14 rotate re-fits · P15 no uncaught errors · P16 a device that cannot store is told (never a silent
loss) · P17 a pause inside a game-time timer halts that frame · P18 pausing mid-drag ends the drag; then the game's own
factory/<id>/<id>.test.mjs. Added for D45 and the review rounds: P19 plant-and-render (unsafe text planted in save
fields, the player name, typed text, AI/party/import/URL text, document.title and attributes never reaches the save or
the screen; unknown fields stay byte-identical) · P20 a late filter (placeholders, then everything repainted) · P21 a
mid-round player switch reports nothing of A's as B's · P22 Reset never replaces a quarantined newer save · P23 a refused
Reset is reported, retried and lands · P24 a failed save is retried with a real write until the device copy reads back ·
P25 a newer save arriving outside a round is not overwritten by a Settings change · P27 P is not pause, Escape is · P28
controller navigation · P29 saveOnQuit. --selftest runs a deliberately broken fixture (raw unsafe text, pause disabled, a timer
and a window listener leaked per round) and fails unless P03c, P04 and P09 catch it.

What the static heuristics cannot see in a factory game: S07, S08, S10 and S11 scan only the game file, and the loop,
input and DPR cap live in kit2.js, so for a factory game they pass without proving anything. The probe is the proof
(P04, P06–P08, P14). docs/04 says so too.

5. Release: ci/release-prep.mjs <id>, then the publish step

release-prep never publishes, never writes the db, never posts and never edits the hub. It:

1. freezes the tree to ~/.cache/claude-scratch/game-factory/releases/<id>-<stamp>/freeze/master-mind and writes
FREEZE.sha256 (the game's files, the shared files it loads, the gate code, the test stub);
2. runs game-check --full --in-place on the frozen bytes with the frozen gate code;
3. re-hashes the source tree and reports any drift since the freeze (re-run if any);
4. writes REVIEW-PACKET.md (filled: hashes vs live, gate table, scope, gaps), CODEX-PROMPT.md + CODEX-COMMAND.sh
(the exact read-only Codex review of the frozen copy), PRE-PUBLISH-POST.txt (channel text, not sent),
RELEASE-CHECKLIST.md (prefilled), PUBLISH-STEP.md, hub-entry.js.

Scope: if a shared platform file (games/_*) differs from the live version (ci/published.json), the packet says a
second-family (Codex) review is required (decision 22). The first release of any factory game ships
games/_factory/kit2.js for the first time, so it needs one.

The publish step (human / coordinator only): gates green on the frozen bytes or a gate exception recorded first ·
reviews done and every finding dispositioned · the hub owner pastes hub-entry.js and re-runs the hub gates ·
PRE-PUBLISH post (status OK + seq) · publish the frozen shipped files, read back, compare with FREEZE.sha256 ·
npm run ci:mark-published -- <version> · POST-PUBLISH post · Board row done · lessons to docs/10.
Details: 05-release-process.md (05-release-process.md).

6. Proof: two pilots and five templates (2026-10-19)

Two small original pilots were made with the factory only (no copyrighted characters; not added to the hub; hub
snippets in MM/factory/<id>/hub-entry.js), plus every kind template in a scratch tree.

Timings and first-pass results (MM/ci/factory-metrics.json; wall-clock, Mac under load ≈ 15–19):

The time to first green includes writing the gameplay (the builder was an AI agent; a person will take longer to
write the game, not to clear the gates). Neither pilot needed a single fix to pass a gate. The one red result was
infrastructure (Chrome timeouts on the hub page under machine load), and one remote run of word-garden failed because
of a factory bug (Node 20 on oldisgold did not get --experimental-websocket; fixed, re-run green, 101 s).

Templates (create-game --kind <k> with no changes, scratch tree): all five reached all-green on their first
game-check (puzzle, word, ordie, 3d and arcade --full; arcade fast first), then again after the Codex fixes on
oldisgold (fast, ~95–105 s each). The 3d template first showed an S09 warning (removed objects never disposed); the
template now creates and disposes one per-round material, and the warning is gone. Template "time to first green"
in the scratch log (5–31 min) is queue time: all five were created at once and checked one after another.

Final gate table (both pilots, release-prep, full mode, on the frozen bytes, after all review fixes):

Kit2 2.4.0 + VMath 1.1.0, oldisgold.local, 2026-10-20 00:40–01:30 (release-prep --remote oldisgold.local):

Templates (fresh scratch tree, fast mode on oldisgold, kit2 2.4.0): arcade, puzzle, word, ordie, maths GAME GREEN; 3d
GAME RED only on the sink-poison test, which gives no output for a WebGL page (the page renders; the test's recorder
never reports): a harness limit, added to proposal P14. The 3d template's probe P03c/P19/P20 text checks pass. The
maths template's generators: 10,000 / 10,000 valid each.

Release folders (review packet, Codex command, pre-publish text, checklist, publish step):

• ~/.cache/claude-scratch/game-factory/releases/lantern-glide-2026-10-20T00-40-13-90976-gymvm/
• ~/.cache/claude-scratch/game-factory/releases/word-garden-2026-10-20T01-07-28-10782-0n8bm/

Metrics (MM/ci/factory-metrics.json): first all-green run 2.4 min (Lantern Glide) and 2.1 min (Word Garden) after
create-game, both on the first run with every gate passing; 17 and 15 recorded runs since (most are the review rounds).

7. Metrics: ci/factory-metrics.json

One entry per factory game: kind, createdAt (create-game), every gate run (at, endAt, mode, host,
seconds, pass, per-gate ok), firstRun (the first-pass gate results), firstGreenAt, runsToFirstGreen,
timeToFirstGreenMin and timeToFirstFullGreenMin. Time-to-first-green is wall-clock from create-game to the end
of the first all-green run, so it includes the builder's own build time; that is the number to drive down.
Remote and infrastructure failures are recorded as runs too (the 2026-10-19 Node 20 flag bug shows up as one red
remote run of word-garden).

8. Known gaps (honest list)

• Real-device walk-off: not done for either pilot; Lantern Glide moves an avatar, so it needs a phone row and a

desktop row before release (docs/04 §7). Headless input is not proof of feel.

• The probe drives rounds through the test hook and real input, but it does not play a game to its natural end in

every way a child would; deep-play behaviour is the game's own test stub's job.

• F01 is a source scan, a heuristic by design. Codex r21 still bypassed it with contrived injected code: a re-assignment

split over lines, parenthesised or commented ((label) ||= …), x. append( with a space, and a "node" initialiser
concatenated with text. None occurs in the pilots or templates. The runtime layers catch such text when it is shown:
probe P03c (DOM, attributes, canvas), P19 (plant-and-render) and the sink-poison test.

• _ordie/core.js (77 KB) loads with every factory game until proposal P1.
• The factory runtime is new shared code: its first release needs the Codex review (§5). A pre-release Codex review

of the factory itself was run on 2026-10-19 (§9).

• Two tabs of one game and player can overwrite each other's saves (an SDK limitation in every SDK game; proposal P13

has the fix direction and a regression test). The kit tells the player and never makes it worse; it cannot fix it from
outside the SDK (two attempts, both withdrawn after review).

• Not run by game-check: the hub suites (the hub is not changed by a new game), Code Editor override versions, fun.

9. Review of the factory itself

A read-only Codex review of the whole factory (kit2, scaffolder, templates, gates, release-prep, both pilots) ran on
2026-10-19 (~/.cache/claude-scratch/game-factory/codex-r1/codex-review.md): verdict DON'T SHIP, 6 P1 + 8 P2.
Triage: raised 14 · verified against the code 14 · folded 14 · rejected 0.

Round 2 (same reviewer, verifying): 9 fixed, 5 partly, 2 new P2s. Round 3: 4 of 7 fixed, 3 partly, 4 new
(N3–N6). Each round's items were verified at file:line before fixing; none was rejected. What rounds 2–3 added:

Known limit kept honest: the SDK skips identical re-writes and writes the device copy asynchronously, so after a
failed device write the kit can tell the player and re-commit (which applies any incoming save first), but the device
copy is only re-written by the SDK on hide/pagehide or by the next change. Proposal P9 asks the SDK for a write status.
Rounds 4–9 (same reviewer, verifying each fix and hunting new ones), plus the coordinator's reviews of the frozen pilot
candidates (master-mind-games seq895, seq900) and two operator decisions (D45 ingest at the source; verified maths). Every
item was checked at file:line before fixing; none was rejected. Main items and their regression checks:

Each round's verdict and the round-10 result are in §6 and the hand-back. Review files:
~/.cache/claude-scratch/game-factory/codex-r1 … codex-r10/codex-review.md.