The fifth chapter, and the template code it teaches out of. Events is the first
thing in the book that goes the other way — chapters 1-4 move data out of the
game and onto a page; an event changes a live world on a schedule, unattended.
**Chapter 5** covers the four declarations (budgets, option sources, leases,
actions), leads with the lease because EVENTS.md §H is right that it is the
primitive that travels and the spawn is the special case, and gives one section
each to the four things that are invisible until an outage: the envelope's
failure default, the idempotency passthrough, recording a resource before
confirming it, and under-declaring `cost`.
**Chapters 3 and 4 gain one section each** for the command plane, because
without them chapter 5 teaches a module to send an idempotency key to a sidecar
the book never told anyone to build a command path in. Both say at the top that
they are skippable until you want chapter 5.
**The template ships one of each declaration**, with `server/sidecarClient.js`
as the near end — a real timeout, a real key passthrough, a simulated transport
in one function marked for replacement. That file is named for the filename
`noGameConnection.test.js` already anticipated, so the test stays green now and
fires correctly the moment `deliver()` becomes a request.
Two things writing it found, both now in the chapter and beside the code:
* **An idempotency key belongs on a command, never on a question.** The first
draft keyed every call including the reads; an at-most-once store then
answers every future read with the first one's reply, forever. The lease
applied correctly and the module could no longer see it. Hence `ask` and
`send` as two functions.
* **A refusal's reason goes in `error`; core reads no other name.** The first
draft used `detail`, on the strength of the one place EVENTS.md §H mentions
it, and every refusal it produced was anonymous on the run console.
Proved by running the template's real declarations through core's real registry
at `edge` (all four accepted) and its real envelopes through the real
`events/dispatch.js` classifier.
**CI is RED on `checkCoreApi` and that is the mechanism working.** The template
now declares `coreApi: ^1.10.0` and `ci/core-ref.json` pins the engagement
cutover, where `main` is still 1.9.0. Equality is the check, a bump is meant to
turn this repo red until someone re-reads the chapters, and the pin move rides
in the events cutover (EVENTS_PLAN.md P16) as its own commit. Do not "fix" it.
Refs EVENTS_PLAN.md Phase 15, EVENTS.md §F, MODULE_API.md 1.10.0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4
The kit was pinned to website 963d734 -- MODULE_API 1.6.0, the Teams cutover --
and the platform is on 1.9.0. Three registrations and two calls arrived in
between, and a reader building against this book would have found no mention of
any of them: a module can now declare what its game can announce, and never who
is told.
Moving `ci/core-ref.json` is the mechanism for exactly this. The pin is now
66bb3b9a (website `main`, the engagement cutover) and `template/module.json`
declares `^1.9.0`.
What chapter 2 gained, under "Telling core something happened":
* a TRIGGER is a payload contract, not a notification stream -- the two share
one id namespace and are constantly confused;
* `ceiling` is required, has no default, and is a CONTAINMENT tree rather than
a size ladder (a `staff` ceiling does not permit `owner`);
* an AUDIENCE resolver returns user ids and nothing else, resolves to NOBODY
on failure, and takes CONSTANT params -- the constraint worth knowing before
you design around it;
* templates re-ensure per seedVersion, rule groups are offered ONCE per group
key, so a rule appended to an existing group reaches fresh installs only;
* `ctx.events.emit` binds the owner and is fire-and-forget; `ctx.inbox.push`
is the direct write, for when there is nothing for an operator to decide.
The template builds all of it: one trigger, one audience over the clan roster it
already had, one seeded body and one seeded rule group, and an emitter in
`boot.js` that fires on the TRANSITION rather than on the poll. Seven new tests,
including the audience that resolves to nobody when its query throws.
Three claims were wrong and are corrected here rather than shipped:
* core validates `subjectKey` against the declared variables and refuses the
module; the draft taught a cooldown keyed on `undefined`, which the check
exists to prevent and a reader will never see.
* `emit` throws OUTSIDE production and only drops-and-logs inside it. Teaching
the second half alone leaves a developer meeting a throw the book says
cannot happen.
* the seeded body itself was malformed -- heading `level: 2` where the block
registry takes 'h2', and no block ids at all.
The third is the one worth keeping: `registerEngagementSeeds` checks that
`blocks` is a non-empty array and stops, so that body would have registered,
seeded, and failed the first time an operator opened it. Found by running the
template's `register()` through core's real registry at the pinned ref -- which
CI does not do, and cannot: the template job checks the version and runs the
template against fakes. A fake accepts what core refuses. The gap is now named
in the chapter, beside the code, and in the pin's own comment, and the rule that
bit has a test that fails on it.
Also: `checkLinks` skipped `.core/`. Bumping this pin means cloning core into
that directory first, and the walk then reported nine broken links in someone
else's README. CI never saw it -- the clone happens in the `template` job and
the check runs in `prose` -- so it was a failure only a person could meet.
Co-Authored-By: Claude <noreply@anthropic.com>
The template shipped the declared-version release engine the reference module
has just abandoned: publish when a push to `main` leaves `module.json` at a
version with no release yet. Both flavours of the workflow move to the engine
`link`, `installer` and now Module-uo run - feat!/BREAKING CHANGE -> major,
feat -> minor, fix|perf -> patch - with `module.json` kept as a floor and a
`workflow_dispatch` backdoor for a manifest change with no releasable code
behind it. The tag is the number that ships, and the job writes it into the
`module.json` inside the bundle.
The chapter keeps the declared model in view rather than deleting it, because
the reason it was abandoned is the part a reader needs: its cost is paid on
every release, and the drift it prevents is something review catches anyway. A
week of merged work in the reference module produced no bundle at all.
Also carried over from the same pass: a tag pushed without a release behind it
is recovered instead of standing down forever, and the changelog moved into the
plan step (so assemble clears `$OUT`, not `dist/`).
Kept: the `# CHANGE THESE` banner, the exclusion list from the acceptance run's
F4, and the GitHub twin's `MODULE_SOURCE_HOSTS` note.
checkLinks, checkRenameSites and checkChapterPaths pass.
Co-Authored-By: Claude <noreply@anthropic.com>
Follows the org lead's two corrections on docs#170. The Rust example is an OXIDE
plugin - naming the framework is the difference between a design a reader can
start from and one they have to go and choose for themselves - and the
architecture pairs one sidecar to one game server, on that server's own host.
Chapter 3 gains the general form of that second one, since it is the chapter
where a reader decides what to build: if your game runs as a fleet, "how many
sidecars" is answered by where the loopback boundary is, not by how many
processes you would rather run. Your module holding several clients is the
cheaper end of that trade, and core never learns there is more than one.
Co-Authored-By: Claude <noreply@anthropic.com>
The kit taught, to an audience outside this org, that Rust needs "no game-side
plugin to write at all" because it ships RCON. That is overruled: the Rust dry
run reaches the game through a MOD - a plugin loaded by the server's own
framework, hooking events and dialling out - exactly as the ServUO overlay does
(docs#170).
Chapter 3's section kept its question and lost its example, which turned out to
improve it. The useful test is not "does my game expose a protocol" but "does it
DELIVER EVENTS": a remote-control channel is built for an operator typing
commands and tells you what you asked about, when you ask, and a website needs
what happened whether or not anyone was listening. A channel that answers
questions can only be polled, and polling turns "someone left the clan at 14:02"
into "the count was different at 14:03".
Rust now appears in that section as the counter-example rather than the example,
and carries the finding that is actually worth having: its server is a BINARY
where ServUO is source you compile, and the three-part shape survives that
unchanged. The plugin-dials-out arrangement is not a property of having source
access.
Chapter 4 said a game with a remote-control protocol may not need any of it, and
that its worked example is source you build. Both now say what is true - the
rules in that chapter are properties of being inside a game loop, and apply
identically to a mod in a closed server.
Co-Authored-By: Claude <noreply@anthropic.com>
The two mechanical lines the phase owed. template/module.json already declares
^1.6.0; this is the sha that makes checkCoreApi agree with it, which it could
not do until the cutover landed - the check is an equality against a core on
main, and 1.6.0 had only ever been on edge.
The `why` block records what the check bought this time rather than just what it
is for. Writing the chapters against 1.6.0 is what found that core's inverted
slot fills named three of module-uo's slots literally, so the direction worked
for that one module and silently did nothing for any other game. A book written
for an audience outside this org is exactly the instrument that finds that, and
it was fixed in core before this pin moved.
Also: the pin skipped the Teams `edge` entirely. The kit is written against what
shipped, never against what is in flight.
Co-Authored-By: Claude <noreply@anthropic.com>
The template was built into a running core - MariaDB, the real loader, a browser
- and both halves of the walk passed: core reconciled two Teams out of the
provider on the first boot, /public/teams/<slug>/members came back with
projected:true, and the clan page rendered core's activity feed and forum in the
two slots this module declared. That last one is the whole point of the phase: a
module whose id is not "uo" now gets core's Team content, which is what
website#160 fixed. module-uo's own guild page was walked on the same core and is
unchanged.
Two things the walk found, both of the kind only a browser can:
PageHeader takes `lead`, not `subtitle`. The template has been passing subtitle
since it was written, and an unknown prop on a React component is silently
dropped - so every page built from this template rendered its heading with
nothing under it, on a site where every core page has a line there. Nothing warns
anywhere. Fixed on all three pages, and chapter 2 now says to check prop names
against 3.4 rather than guessing them, beside the paragraph about `shell` that
exists for exactly the same reason.
"1 members" on the clan list.
Co-Authored-By: Claude <noreply@anthropic.com>
MODULE_API 1.6.0 expands the contract this book teaches against, so the book
owes two shapes and one correction. Chapter 2 gains both and the template grows
a working version of each, because a reader following a snippet has no way to
find out whether it runs.
ONE SENTENCE WAS WRONG. Chapter 2 said, of extension slots, "Only core may
declare a slot; a module may only fill one". 1.6.0 inverted exactly that: a
module declares a place on its OWN page and core fills it. That is not a stale
detail - a new game's module cannot implement Teams at all without the inverted
direction, so it is the shape the reader needs and did not have.
THE TWO SHAPES
- The inverted slot. A new "Slots go the other way too" section: why the
direction has to invert (core owns the Team, not the word for one), the
namespace rule, one slot per PLACE, the optional { core } naming which of
core's three contributions goes there, and why asking for one core does not
offer throws when almost everything else in that registry fails open.
- registerTeamProvider, in "Becoming the source of Teams". The first
registration where core calls YOU and waits, which is where every rule in it
comes from: the envelope, the ten-second budget, refusing as a normal answer,
and the one mistake worth naming - answering with an empty list because the
game is unreachable, which core reads as authoritative and acts on.
projectRoster gets its own treatment because it is the exception that fails
CLOSED. pageUrlTemplate is a footnote beside it, as intended.
WHAT THE TEMPLATE GREW
model/clans/ - the provider over two tables, with the guards that matter: an
unreachable game refuses rather than reporting no clans, an empty roster is
refused unless the game says the clan is empty (which is why the schema keeps a
member count the rows cannot supply), and the audience rule lives in one file
that both projectRoster and the module's own page consult, because a second copy
drifts in the direction that publishes what core is withholding.
Its own /clans routes, deliberately not /teams - core mounts that itself, and
the loader would refuse the collision. A clan list page and a clan page that
declares three slots for core.
12 provider tests and three registration tests, 47 server and 20 client in
total. The purge test finally proves something: two of the three tables are now
a parent and its child.
WHAT IT DOES NOT DO. Enumerate the contract. The kit teaches one path end to end
and links out; it has never mentioned three pre-Teams registrations and that is
the design, not a gap.
FOUND WHILE WRITING IT: core filled three literal uo.guild.* slot names, so the
inverted direction reached exactly one module and every other game's page came
up empty with nothing logged. Fixed in website#160 / Module-uo#15 / docs#165
before this chapter could teach it - which is what this phase is for.
The ci/core-ref.json pin moves in a later commit on this branch: checkCoreApi is
an equality against a core on main, and 1.6.0 does not reach main until the
cutover.
Co-Authored-By: Claude <noreply@anthropic.com>
The module system cut over on 2026-08-12 and website's `edge` branch was
deleted, so `ci/core-ref.json` named a branch that no longer exists.
The sha did not move. The pinned commit is an ancestor of `main`, the contract
is still MODULE_API_VERSION 1.5.0, and no chapter changed - this is a label
correction, not a re-pin, and deliberately not the moment d2 exists to create.
Nothing in CI reads the `branch` field: the workflow clones the repo and checks
out the sha, which is both why the cutover could not break the build and why a
wrong label here would have sat unnoticed indefinitely. The field is for the
person deciding whether a newer core is worth re-reading the book for, and a
branch that no longer exists tells them nothing. The `why` block now says which
half is load-bearing.
checkCoreApi.js's not-a-core error also asserted that core `main` "has none
until the cutover", which stopped being true at the same merge. A reader hitting
that message would have gone looking for a cutover that already happened - the
kit's own lesson from the CRLF defect, that a failure message naming a diagnosis
has to be right about it, applied to the kit's own scripts.
Verified both paths: the check still passes against a real core (^1.5.0 vs
1.5.0), and the rewritten message renders as intended. checkLinks,
checkRenameSites and checkChapterPaths all clean.
Co-Authored-By: Claude <noreply@anthropic.com>
A cold agent was given this repo and the documents it links to, and nothing
else — no core source, no module-uo — and asked to build a module for a second
game. It did, in one pass. The record is docs/modules/kit-acceptance.md; this is
the repair list, plus the two things it recommended that were not defects.
The one it could not find, because it had no core to render against: a module
page built exactly as this kit teaches renders OUTSIDE the site. PublicLayout is
the chrome, not the body. Core grew an opt-in `shell` prop for it
(MODULE_API_VERSION 1.5.0, website#148); the template passes shell="narrow" and
chapter 2 explains why you name a width and never a class.
Fixed:
- **F1, and the worst of them, because it lands in the first twenty minutes.**
`npm run check:swagger` failed on a PRISTINE template on Windows: the check
compared the committed fragment byte-for-byte and a default Windows clone is
CRLF while the generator writes LF. The message blamed "the routes or their
annotations". Now `template/.gitattributes` pins `eol=lf` and the comparison
normalises line endings anyway — a check may only fail for the reason it names,
and this one names a diagnosis.
- **F3** — `.gitea/workflows/release.yml` carries `gitea.example.com` and
`your-org/your-module` under a literal `# CHANGE THESE`, was not in the rename
checklist, and `checkRenameSites.js` could not match it, so CI was silent by
construction. Row added, pattern widened. (The agent reported both workflow
flavours; only the Gitea one is affected — GitHub supplies its own variables.
Corrected in the record.) The near-miss is kept in the check's comments and its
suite: the obvious widening is `example\.com`, which fires on a fixture URL in
checkImports.test.js. Every alternative has to be a string that cannot occur by
accident, which is the same rule that made the id `examplegame`.
- **F4** — the release bundle's include list was hardcoded, so adding
`server/utils/` would have silently dropped it from every release while the
bundle check stayed green. Inverted to an exclusion list, in both flavours, and
run by hand because a release workflow never executes in CI.
- **F5** — the annotation-quoting warning was wrong in both directions, and the
correction is measured rather than reasoned. A backtick is harmless (the
template's own description has two spans and they survive). A `"` is not, and
it does not throw: `'A "quoted" status'` is silently TRUNCATED to `A "` while
swagger-autogen prints Success and the error capture sees nothing. The only
signal is check:swagger blaming your routes.
- **F6** — `template/.gitignore`, so a copied template that is `git init`ed
inherits ignore rules instead of nothing.
- **F7** — the UI kit is eight exports across five rows, not seven. The contract
said seven and this kit had faithfully carried the miscount out of it.
Adopted, not defects:
- Chapter 1 now says to run every check on the untouched copy first. That is what
found F1; without a baseline the first failure is ambiguous forever.
- The template ships the §2.7 self-check the agent wrote for itself. The rule has
no CI in general — an outbound socket is not statically detectable — but a
module can make a decidable claim about its own tree. Ported from its code with
a header explaining how to NARROW it when a sidecar client arrives, since
talking to your sidecar is the expected shape and is not what §2.7 forbids.
The pin moves to website edge 4ad8b2b, the 1.5.0 bump, and template/module.json
declares ^1.5.0 — so checkCoreApi's equality assertion still holds and the
template uses a member that exists only at that ref and later.
32 server + 18 client template tests, 21 kit-script tests, all four checks green.
Co-Authored-By: Claude <noreply@anthropic.com>
The book, written out of the tree slice 1 proved. Four chapters in the order the
work happens: the first module in twenty minutes, the website module, the sidecar,
and the game-side plugin.
Shape, settled with the org lead:
* template/README.md stays the REFERENCE — it travels with a copied template and
CI holds it against the tree — and chapter 1 is the narration: what you should
see after each step, the state your module lands in, and the four ways it fails.
The chapter links to the checklist rather than restating it.
* chapters 3 and 4 cite link/ and servuo-plugins/ by FILE AND IDENTIFIER, never by
line. Those repositories move for their own reasons and checkLinks already
forbids commit permalinks, so a line number in this book is wrong the moment
they do. The template stays the only code quoted verbatim.
* one PR: the outline's status table and the link check are only coherent when the
whole set lands.
scripts/checkChapterPaths.js is the anti-rot half a machine can answer: every path
a chapter names in backticks must exist. None of those mentions is a markdown link,
so checkLinks never looked at them, and none is code, so nothing else did either —
renaming one template file would have left four chapters quietly pointing at
nothing. Its anchor list is STATED rather than derived from the tree, for the reason
the template's own build guard states it: a list derived from what exists cannot
fail when what exists changes, and an anchor that stops matching is a check that has
silently stopped checking. So each anchor must exist or the check fails. Eleven
tests, every "must not catch" case a span that really appears in the book.
stripFences moved to scripts/lib/markdown.js and both checks use it — shared code,
not a shared description.
CHAPTER 1 WAS RUN, NOT REASONED ABOUT. The template was copied into a real core on
edge, booted against the dev database, and every claim in "what you should see"
checked: the five log lines, /examplegame/status with its injected
<script type="module" src="/modules/examplegame/entry.js">, the chunk served
no-cache while module.json 404s, /api/v1/public/world/status, the capabilities in
/api/v1/public/modules, and the route in the merged /api/docs.json. Then the three
failures the chapter tells a reader to cause on purpose, because a chapter that
predicts the wrong debugging heuristic is worse than one that predicts none:
* an undeclared prefix -> stage `register`, "declared public/extra but never
registered it", routes 404 and absent from /public/modules;
* a table without the id prefix -> stage `schema`, at LOAD time, before mounting;
* a throwing onBoot -> after mounting, so the same route answers 503 "Module
unavailable" rather than vanishing.
All three came out exactly as written, and the messages in the chapter are that
core's own. Two small corrections fell out of the run: the log sample now shows the
real interleaving of core's three lines with the module's two, and the section on
failure adds that a module disappears from /api/v1/public/modules in every failure
case — a check that needs no login.
MODULE_SYSTEM.md 2.11.1 slice 2. Docs half: docs#146.
Co-Authored-By: Claude <noreply@anthropic.com>
The kit's `template/`: a complete, minimal Runic Gateway module a reader copies,
renames, and runs before reading a chapter. Slice 0 landed the workflow that runs
it; this is the tree that workflow was written against, so the `template` job
arms itself with no edit to the guard.
Installed into a real core it adds one public page at `/examplegame/status`, a nav
row pointing at it, one API route described in an OpenAPI fragment core merges,
one table created by an idempotent schema fragment and dropped by a purge file,
and both lifecycle hooks. That is deliberately less than a real module does; what
it is complete about is the shape — every seam used once, with the reasoning next
to it.
Four decisions, settled with the org lead:
1. **Public tier only, plus the lifecycle hooks.** §2.11.1 d1's "one public route",
plus enough to show the whole vertical seam once. Admin and player tiers become
worked examples quoted from module-uo in chapter 2 rather than two thirds of a
tree the reader deletes on day one.
2. **The release workflow ships as a file, in BOTH flavours** — `.gitea/` and
`.github/`. Neither runs where it sits (a workflow is only read from a
repository root) and each arms itself when the reader's copy is its own repo.
Packaging is the part of a module that cannot be guessed at, and the kit's
audience is outside this org, so assuming Gitea would have been assuming our
own deployment. Core installs from a URL and does not care where the release
lives — only that the host is on the operator's `MODULE_SOURCE_HOSTS`.
3. **A rename checklist that CI verifies**, not a rename script. `template/README.md`
carries the table; `scripts/checkRenameSites.js` holds it against the tree in
both directions — an unlisted file that still carries the placeholder fails, and
so does a listed file that no longer does. The second half is the one usually
left out and the more valuable: a row that has stopped matching reads as
instructions to edit something that is not there. Same rule core's identifier
check follows about its own exemptions. It has its own ten-test suite, run by
CI as `node --test`, because a check that has never been shown to fail is a
check nobody knows the state of.
4. **A neutral invented game.** One deviation from the literal answer, forced by
decision 3: the id is `examplegame`, not `example`. The checklist check is a
text search, and `example` occurs in ordinary English ("for example") all over
prose that is not a rename site — a placeholder that cannot occur by accident is
what makes the check answerable instead of a source of false alarms someone
learns to ignore.
**The pin moves to the 1.4.0 bump** (website `edge` 1b692bf), which is what
`template/module.json` declares as `coreApi`. Slice 0 pinned its parent, before
1.4.0 existed, so `checkCoreApi.js` arms for the first time here — it asserts
EQUALITY, and its failing on the next contract bump is the system working.
Also in CI: the client tests now run AFTER the build (two of them read the built
chunk and skip without one — run first, the job reports green while asking nothing
about the artifact that ships), and `check:swagger` verifies the committed
fragment is current.
## The finding: an UPDATE that changes nothing does not touch ON UPDATE CURRENT_TIMESTAMP
Every suite passed, both guards passed, the chunk built, the module loaded into a
real core and the page rendered correctly. Two hours later the same page said the
world was offline, and it was wrong.
`updated_at` was declared `ON UPDATE CURRENT_TIMESTAMP`, and MariaDB fires that
only when an UPDATE actually CHANGES a value. The boot refresh writes the same
numbers every thirty seconds — which is exactly what a quiet game looks like — so
the timestamp froze at the first write, the row crossed the freshness window, and
the model correctly reported a stale row as offline. Verified against the live
database: two hours of refreshes, `updated_at` still the boot timestamp.
No test in this repo could see it. The model takes its clock as an argument, and
nothing in a suite runs the same UPDATE twice against a real database. It is only
visible as a page that was right when you looked at it and wrong an hour later.
The writer now sets `updated_at = CURRENT_TIMESTAMP` explicitly and the column
drops the clause that was not doing what it looked like it was doing; both carry
the reasoning. Re-verified end to end: the timestamp advances every interval and
the API reports fresh.
Falling out of the fix, the schema fragment gained the rule the reader hits next:
**changing a table is an ALTER, never an edit to its CREATE** — `CREATE TABLE IF
NOT EXISTS` does nothing when the table exists, so an edited column definition
takes effect on a fresh install and on no existing one, which is the worst
possible split because your development database is usually the fresh one.
## Verified
- 29 server tests, 18 client tests, 10 kit-script tests; `check:imports`,
`check:externals`, `check:swagger` and `checkCoreApi` all green, run in CI's own
order from a clean `npm ci`.
- Browser smoke (MODULE_API.md §7.7) against a real core built from the pinned
ref: module `started`, published on `/api/v1/public/modules`, chunk served
`no-cache` with the right MIME from the entry's directory while `module.json`
and the server source 404, script tag injected after core's bundle, the page
rendering inside core's own chrome, the nav row interleaved into the public
header between Wiki and About, SPA navigation into it from another page, the
module's path and schema and tag merged into `/api/docs.json`, and
`[examplegame] registered against core API 1.4.0` in the console with no CSP
report and no React error.
Refs: MODULE_SYSTEM.md §2.11.1 (slice 1), MODULE_API.md §2.x, §3.x, §5.1, §7.7.
Co-Authored-By: Claude <noreply@anthropic.com>
Phase 5 slice 0 (MODULE_SYSTEM.md §2.11.1). The repo's governance, the front
page, the book's outline, and the CI that keeps the whole thing from rotting.
README.md
What the reader is building, all three parts, and the draft banner: the kit is
finished when someone outside this project builds a working module by
following it alone, and that has not happened. Says the sidecar rule plainly
(MODULE_API.md §2.7) rather than leaving it to chapter 3, because a reader who
skims the front page and starts coding should still get that one right.
book/README.md
The outline of four chapters, landed before the prose so the shape can be
argued with. Chapters are named but NOT linked — a link to a file that does
not exist is what the link check is for, and an outline should not be the
first thing to fail it.
CONTRIBUTING.md
The rule that governs every change here: the kit never re-specifies a
contract. Also the prose conventions, and why the pinned ref points at core's
`edge` rather than `main`.
SECURITY.md
Scoped for a repo that runs nothing: the two things that ARE reportable are a
template that teaches an insecure pattern (it is meant to be copied) and a
chapter that teaches something dangerous.
scripts/checkLinks.js
Relative links resolve; anchors match a real heading; no link pins a reader to
a commit snapshot of a moving document. Nothing is fetched — a self-hosted
Gitea would fail on a credential-less runner and teach us to ignore red.
Fences and code spans are stripped by a line walk, not a regexp.
Its first run found a real one: a PR template's relative links resolve from
the REPO ROOT, because that is where their text ends up when Gitea inlines
them into a pull request body. Encoded, with the reason.
scripts/checkCoreApi.js
The anti-rot check. Asserts template/module.json's `coreApi` EQUALS the pinned
core's MODULE_API_VERSION — equality, not "satisfies", because a range check
stays green across a contract bump and green would then mean "the template
still loads" instead of "someone has re-read the book". Both failure branches
and the pass were exercised against a real core checkout.
ci/core-ref.json
The pin, same convention as Module-uo's. Points at `edge`: core's `main` has
no server/src/modules/ until the cutover, and that pin is one of the things
the cutover has to revisit.
.gitea/workflows/pr-checks.yml
Two jobs. `links` always runs; `template` is conditional on
template/module.json existing, so the repo is gated now and the job arms
itself when slice 1 lands, with no edit to the workflow. Same guard Module-uo
used through its planning phase.
Co-Authored-By: Claude <noreply@anthropic.com>
The repo's first commit, pushed straight to `main` because an empty repo cannot
take a pull request. Everything after it goes through one, starting with the
scaffold.
Deliberately only the two files nobody needs to review: both are verbatim copies
of the versions already approved in the other Runic Gateway repos. The authored
scaffolding — README, CONTRIBUTING, SECURITY, the book's outline, the checks and
the CI — is a pull request, because in this repo the prose IS the product and
landing it unreviewed on `main` would skip the review that matters most.
Phase 5 of the module plan (docs: website/MODULE_SYSTEM.md §2.11, §2.11.1).
Co-Authored-By: Claude <noreply@anthropic.com>
