Skip to content

The cross-game compounding flywheel: how each game makes the next one cheaper, and the last one better

The useful claim is not "AI writes code faster." Faster typing is real, but it is not enough to build a catalog of games. The stronger claim is narrower and more testable: every shipped game leaves behind artifacts that can lower the cost of the next game, and every serious lesson from a new game can be folded back into the system that still governs the older games.

That is the flywheel here. Forward means the next game starts with more examples than the last one did. Backward means a lesson from one run becomes a rule, lint, template, shared helper, or retrofit ticket that applies across the catalog. The repo only earns this claim when those movements are visible in files, not when a post says "compounding" loudly enough.

What the next game inherits

A game in this project does not leave only source code behind. It leaves a package of reusable context:

  • design and rules docs under docs/games/<slug>/
  • engine code under src/engine/<slug>/
  • stage code under client/src/stage/<slug>/
  • server-shaped fixtures and tests
  • the ticket that described the work
  • the sibling *.run.md record that says what actually happened

That last pair matters as much as the code. A future ticket can read a shipped game's docs and implementation, but it can also read why the previous agent made a decision, what failed first, which checks proved the result, and what the review stage corrected. The next game is not primed only with an example. It is primed with the example plus the work history around it.

I am not claiming the repo has measured a clean cost curve where game four took exactly less time than game three. The current artifact-backed claim is simpler: the reusable inputs are real, they are local, and the workflow tells agents to read them before building the next surface. That is the forward half.

How lessons move backward

The backward half is not automatic. It is the job of the orchestrator loop.

Every implementation run is supposed to end with a run record next to the ticket. The run-record contract includes sections for surprises, dead ends, prevention opportunities, context, review corrections, and rule or feedback artifact changes. The phase and feedback retro templates then require the retro agent to read sibling run records, inspect review findings, run backlog-drafts, disposition deferred or escalated items, and update process docs or seed follow-up tickets when a pattern deserves it.

That is the pump. A lesson learned while building one game can become a standing rule in CLAUDE.md, a lint in workflow/scripts/, a ticket template field, or a cross-game cleanup ticket. Once it lands there, older games are no longer protected only by their original implementation choices. They are protected by the newer rule set that review now applies to every change.

This is why the retro is not paperwork. Without it, each *.run.md file is local memory. With it, repeated lessons can turn into project behavior.

The orchestrator is the clearest example

The strongest current examples are not game mechanics. They are the orchestrator surfaces that every game build goes through.

Tempo, the Go port of the workflow system, is one example. The repo has a hard rule that changes under workflow/ must be mirrored into the corresponding Tempo surface when one exists. You can see the shape in the tree: workflow/docs/** has embedded bootstrap mirrors under tempo/assets/bootstrap/workflow/docs/**; the Go config model mirrors workflow/project.config.json; tempo/lint_gates.go routes Tempo commands to vendored Python lint modules; and Tempo keeps its own history-index and codemap Python engines instead of rewriting proven analyzers just to make the port look pure.

That is backward folding at the tool layer. A workflow lesson does not stay in the bash implementation only. If it is generic orchestrator behavior, the rule forces the Go port to carry the same contract or record that no equivalent exists yet. The parity tests make the discipline concrete: Tempo has read-surface and mutation-surface parity cases, lint-gate matrix coverage, and committed golden outputs for surfaces such as backlog listing, status, config lookup, and history queries.

The result is not "Tempo is finished." It is not. The honest result is better: the project has a visible path for moving a working workflow idea into the installable orchestrator without pretending the port covers more than it does.

The data loop is also real

The game-authoring flywheel is a second loop beside the catalog-quality loop. It is not a fine-tuned game-building model today. It is a data substrate that can support retrieval, evals, and training exports later.

The current files are enough to state that carefully. The history index rebuilds .state/history.duckdb from tickets, run records, git history, state files, audit trajectories, context manifests, PR cache, and reports. Its schema includes tables for tickets, run_records, context_manifests, trajectories, lint_gate_vector, run_rewards, grounding, preference_pairs, spiral_labels, audit_runs, and more. The audit trail schema records event types such as prompts, model responses, tool calls, lint results, review verdicts, preference pairs, and rewards. Large or sensitive payloads go through the redacting AuditBlobStore and are referenced by hash instead of being copied into DuckDB.

That matters because the build loop is producing joinable evidence:

  • what the ticket asked for
  • what context the agent read
  • what tools it called
  • which lint gates passed or failed
  • what review corrected
  • whether the run record says the work merged cleanly

Near term, that supports history search, semantic search, grounding audits, and offline eval episodes. Longer term, it can become training material for better game-authoring agents. The honest boundary is important: the repo records the ingredients for that loop; it does not prove that a future model will improve.

What this unlocks

The payoff is a catalog whose quality does not have to stay stratified by build date. In a normal project, the first feature often keeps the mistakes you had not learned to avoid yet. Here, a later lesson can become a shared rule or review gate, and then the next change to an older game is checked against that newer standard.

That is the useful compounding claim:

forward: shipped game -> examples, fixtures, tests, run records -> better next ticket
backward: new lesson -> retro -> rule, lint, helper, or retrofit ticket -> older surfaces improve

The loop does not remove review cost. It moves more of the cost into written contracts and repeatable checks, where the next run can reuse it.

The limits

There are three important limits.

First, every backward fold touches working software or working process. A catalog-wide rename, a new layout rule, or a stricter run-record gate can break things that were previously passing. That is why the review and lint surfaces exist.

Second, not every lesson generalizes. A rule that belongs to one game should stay in that game. Hoisting it into a base contract because uniformity feels good is how one local quirk becomes everyone else's problem.

Third, the loop stops when the retro discipline stops. The forward half is easy to notice because the next ticket can copy an old example. The backward half is deliberate. Someone, or some agent acting under the retro contract, has to read the run records, name the pattern, and turn it into a change.

That is the case for this way of building. Each game can make the next game cheaper by adding examples. Each run can make the previous games better by turning lessons into shared contracts. The project compounds only when both directions keep moving.