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>
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>
