The fourth game is a command: scripts/newgame.ts writes a registered, tested game on this engine #259

The direction of this repository is that a second game can use the engine, and three now do. What it still costs to start one is a paste: copy src/example/main.ts, copy its stage helper, copy a page, add a registry entry, remember the bundle ceiling, remember the boot test. /example says the wiring is "two files and 220 lines" — true, and all of it is the same two files every time.

Make the fourth game a command.

Done looks like

• [ ] bun run scripts/newgame.ts <name> writes a working, registered game: an entry that builds the renderer and runs the engine's loop, a bindings table, a page, a stage helper, a boot test, and the entry in src/games.ts with a ceiling measured from what it just built — nothing else.
• [ ] What it writes passes: immediately after running it, bun test is green and bun run src/server.ts serves the new game's page beside the other three. The script's own test runs it into a temporary directory and asserts exactly that, then cleans up.
• [ ] The name is validated at the boundary — lower-case letters and digits, not a path, not an existing game — and a name that is not one is a sentence, not a stack trace. Nothing is written outside the repository, and a run that would overwrite a file refuses.
• [ ] What it writes is the example's shape, not a copy of the shooter: one room, one thing to do, a score, the guide's sample as the reference — small enough that a person reads all of it before changing it.
• [ ] It writes no engine code. Everything the generated game does goes through src/engine/index.ts, which the boundary test already holds, and the pull states how many lines the generated game is.
• [ ] src/engine/GUIDE.md and the README say the command exists and what it gives you — the guide's "start here" for somebody who took the package (#225 serves that guide).

Files I expect to change

A new scripts/newgame.ts and scripts/newgame.test.ts, src/engine/GUIDE.md, README.md.

Risks

• A generator that drifts from what the repository actually does is worse than a paste. Keep the template small and let its test — build, boot, serve — be what stops the drift.
• Do not make this a framework. It writes files once; it is not imported by anything, it runs when a person runs it, and it never runs at request time.
• If the honest answer turns out to be "the template is three lines different from src/example/, so document the copy instead", write that in the pull and close it — a measurement that says no is a result.

Suggested: Torque — a tool, with the test that proves what it wrote works.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.