chore(ci): the pinned core is on main now, not edge #5

wtclaude · 2026-08-12T23:06:04Z

wtclaude commented

2026-08-12 23:06:04 +00:00

The kit's half of the module-system cutover (website#150). Merges after it, once edge is deleted.

The sha did not move

Worth leading with, because §2.11.1 flagged this pin as "one of the things the cutover has to revisit" and the revisit turns out to be smaller than the warning implied. 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 — deliberately not the moment d2 exists to create.

Why a purely documentary field was still worth fixing

Nothing in CI reads branch. The workflow clones the repo and checks out the sha (git clone + git -C .core checkout "$REF"). That is both why the cutover couldn't break this build and why a wrong label here would have sat unnoticed indefinitely — no check can see it.

The field exists for the person deciding whether a newer core is worth re-reading the book for. A branch that no longer exists tells them nothing, and worse, tells them something false with total confidence. The why block now says which half is load-bearing, so the next person to touch it knows the sha is the mechanism and the branch is the note.

One error message that had quietly become wrong

checkCoreApi.js's not-a-core failure asserted that core main "has none until the cutover" — true when written, false at the same merge. A reader hitting it would have gone hunting for a cutover that already happened, which is precisely the kit's own CRLF lesson (a failure message that names a diagnosis has to be right about it) turned back on the kit's own scripts. It now dates the cutover and describes the case that can still produce the error.

Verified

checkCoreApi.js still passes against a real core checkout — coreApi ^1.5.0 matches the pinned core's 1.5.0 — OK.
The rewritten failure message rendered by actually triggering it, not by reading it.
checkLinks (58 links / 15 files), checkRenameSites (22 files), checkChapterPaths (34 paths) all clean, plus the script test suites.

Risk

None to the build. The one behavioural line is an error message on a path CI does not take when green.

🤖 AI-assisted: written with Claude Code (Claude Opus 5).

The kit's half of the module-system cutover ([website#150](https://gitea.whitlocktech.com/RunicGateway/website/pulls/150)). Merges after it, once `edge` is deleted. ## The sha did not move Worth leading with, because §2.11.1 flagged this pin as *"one of the things the cutover has to revisit"* and the revisit turns out to be smaller than the warning implied. 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 — deliberately not the moment d2 exists to create. ## Why a purely documentary field was still worth fixing **Nothing in CI reads `branch`.** The workflow clones the repo and checks out the sha (`git clone` + `git -C .core checkout "$REF"`). That is both why the cutover couldn't break this build *and* why a wrong label here would have sat unnoticed indefinitely — no check can see it. The field exists for the person deciding whether a newer core is worth re-reading the book for. A branch that no longer exists tells them nothing, and worse, tells them something false with total confidence. The `why` block now says which half is load-bearing, so the next person to touch it knows the sha is the mechanism and the branch is the note. ## One error message that had quietly become wrong `checkCoreApi.js`'s not-a-core failure asserted that core `main` *"has none until the cutover"* — true when written, false at the same merge. A reader hitting it would have gone hunting for a cutover that already happened, which is precisely the kit's own CRLF lesson (**a failure message that names a diagnosis has to be right about it**) turned back on the kit's own scripts. It now dates the cutover and describes the case that can still produce the error. ## Verified - `checkCoreApi.js` still passes against a real core checkout — `coreApi ^1.5.0 matches the pinned core's 1.5.0 — OK`. - The rewritten failure message rendered by actually triggering it, not by reading it. - `checkLinks` (58 links / 15 files), `checkRenameSites` (22 files), `checkChapterPaths` (34 paths) all clean, plus the script test suites. ## Risk None to the build. The one behavioural line is an error message on a path CI does not take when green. --- 🤖 AI-assisted: written with Claude Code (Claude Opus 5).

wtclaude added 1 commit 2026-08-12 23:06:06 +00:00

chore(ci): the pinned core is on main now, not edge

PR Checks / prose (pull_request) Successful in 7s

Details

PR Checks / template (pull_request) Successful in 26s

Details

8fa4210477

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>

whitlocktech merged commit 77418aaef5 into main

2026-08-12 23:07:45 +00:00

whitlocktech referenced this issue from a commit

2026-08-12 23:07:46 +00:00

Merge pull request 'chore(ci): the pinned core is on `main` now, not `edge`' (#5) from chore/core-pin-on-main into main

whitlocktech deleted branch chore/core-pin-on-main

2026-08-12 23:07:48 +00:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: RunicGateway/Integration-kit#5

chore(ci): the pinned core is on main now, not edge #5

The sha did not move

Why a purely documentary field was still worth fixing

One error message that had quietly become wrong

Verified

Risk

chore(ci): the pinned core is on `main` now, not `edge` #5