Files
Integration-kit/book
wtclaude 067804706e
Some checks failed
PR Checks / prose (pull_request) Successful in 11s
PR Checks / template (pull_request) Failing after 9s
docs(kit): pin core 1.12.0; chapter 5 teaches progress() and ctx.events.expired
The pin moves from 655fbf3f (1.10.0) to 0a37a44 (1.12.0, website#210),
past 1.11.0 (website#209), which it had skipped. Chapter 5 was read
again for both versions:

- 1.11.0: a thing the game ends on its own schedule is reported with
  ctx.events.expired and filed `expired`, not `orphaned`.
- 1.12.0: an action's optional progress(), the line on a public event
  page. It answers for one reader, cheaply, and costs a line rather
  than the page when it fails. "What to build, in order" gains it as
  step 7.

The template declares neither, so nothing it does changed meaning.
template/module.json's coreApi becomes ^1.12.0 for the equality check.

Checks run at the new pin:

- checkCoreApi, links, rename sites and chapter paths all pass.
- The template's import, swagger, build and externals checks pass.
- Tests pass: server 82, client 20, scripts 10 and 11.
- The template was loaded as `examplegame` into a real core of this
  code through core's own loader, and it registered.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01E14m6SuuY6i1vASFeGDBeY
2026-10-06 08:26:57 -05:00
..

The book

Five chapters, in the order the work happens. The first four are the job; the fifth is optional and comes after you have one.

Read the dry run before any of them — a complete module designed on paper for a second game, and the shortest honest picture of the whole job.

# Chapter What it covers
1 Your first module in twenty minutes Copy the template, rename it, build it, install it, see a page. No theory.
2 The website module The bulk of the work: module.json, register(ctx, api), the schema fragment, the client chunk, packaging, and what a module must never do.
3 The sidecar Why the website never talks to a game server, what "persist before you forward" means, and what a thin sidecar is.
4 The game-side plugin The least code and the highest stakes: never block the game thread.
5 Making your module event-capable Optional, and the first thing here that can do damage: letting a scheduled event on the website change your live world, and get it back.

Chapters 1, 2 and 5 quote template/, which CI builds against a pinned core, so their code is a tree that is proved rather than prose that looks like one. Chapters 3 and 4 cite uo-link and servuo-plugins by file and identifier rather than by line, on purpose: those repositories move for their own reasons and a line number in a book is wrong the moment they do.

Chapter 5 is the one you can stop before. Chapters 1 to 4 get a game onto the platform and everything in them moves one way — out of the game and onto a page. Chapter 5 is the other direction, and a deployment that never reads it still has a working event engine over core's own verbs. Chapters 3 and 4 each carry one section that only matters if you are going there (§2a and "A command that changes the world runs at most once"); both say so at the top.

What is normative, and what is here

Nothing in these chapters is. Where a chapter and one of these disagree, the document is right and the chapter has a bug — say so:

Authority For
MODULE_API.md Everything a module may do.
MODULE_SYSTEM.md Why the module system is shaped this way, and how a module is installed and removed.
link/PLAN.md + INTEGRATION.md The game↔sidecar wire protocol, as one real sidecar implements it.
EVENTS.md The event system: what an event is, what a module declares, and what core owns.

The chapters teach: the order to do things in, the reasoning, and the mistakes that cost this project time.