chore(ci): pin the kit to the Event System core, and go green (Phase 16b cutover, 5 of 6) #11

wtclaude · 2026-09-10T00:51:05Z

wtclaude commented

2026-09-10 00:51:05 +00:00

The Event System cutover, step 5 of 6 (EVENTS_PLAN.md Phase 16b). One file.

ci/core-ref.json moves from 66bb3b9a (MODULE_API 1.9.0, the engagement cutover) to 655fbf3f — the commit 1.10.0 reached main on (website#199, merged tonight).

This closes a red `main`, not just a date

Chapter 5 landed in #10 declaring coreApi: "^1.10.0" while this file still named a 1.9.0 core, and checkCoreApi asserts equality — so main has been red on that check since #10 merged. That was deliberate and stated in the PR ("do not fix it"), but the red belongs to the cutover window rather than to the repo. This is the commit that was always going to close it, and it could not be written until the events sha existed on main. Same shape Teams phase 11 used.

A pin move is a run, not an edit

The template job checks this number and tests the template against test/_fakes.js, and a fake accepts what core refuses — a wrong declaration would ship green. So the template's real declarations went through core's real registries at this exact ref:

registries.stage('examplegame') → register(fakeCtx(), api)
  eventBudgets 1   eventOptionSources 1   eventLeases 1   eventActions 1
  triggers 1  audiences 1  engagementSeeds 1  teamProviders 1
registries.apply(...)   accepted — ids, collisions and namespacing OK

That habit is why chapter 5 is worth reading. It found the chapter's own two defects, neither of them by writing prose: an idempotency key on a question makes every later read permanently stale (an at-most-once store answers a repeated key with the original reply, so the template's second read returned the first read's answer for ever and the module could not see a change it had just made), and a refusal's reason goes in error — core's classifier reads no other name, so a refusal reported under detail reached an author as a bare "refused". The why block now records both, and the detail half is why docs#227 made that member real in core.

Verification, against a core at this ref

checkCoreApi      coreApi ^1.10.0 matches the pinned core's 1.10.0
registry rig      all four declarations accepted, apply() accepted
template server   82 pass, 0 fail     check:imports OK
template client   20 pass, 0 fail     check:externals OK, build OK
prose checks      checkLinks · checkRenameSites · checkChapterPaths — all OK
their own tests   10 pass · 11 pass

Nothing else needed to move: template/module.json has declared ^1.10.0 since #10. The branch field stays documentary — CI clones the repo and checks out the sha — and the why block now says the kit skipped a third edge (this workstream's) for the same reason it skipped the first two: the book is written against what shipped, never against what is in flight.

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

🤖 Generated with Claude Code

https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

The Event System cutover, step 5 of 6 (`EVENTS_PLAN.md` Phase 16b). One file. `ci/core-ref.json` moves from `66bb3b9a` (MODULE_API **1.9.0**, the engagement cutover) to **`655fbf3f`** — the commit **1.10.0** reached `main` on (`website#199`, merged tonight). ## This closes a red `main`, not just a date Chapter 5 landed in **`#10`** declaring `coreApi: "^1.10.0"` while this file still named a 1.9.0 core, and `checkCoreApi` asserts **equality** — so `main` has been red on that check since `#10` merged. That was deliberate and stated in the PR ("do not fix it"), but the red belongs to the cutover window rather than to the repo. This is the commit that was always going to close it, and it could not be written until the events sha existed on `main`. Same shape Teams phase 11 used. ## A pin move is a run, not an edit The template job checks this number and tests the template against `test/_fakes.js`, and **a fake accepts what core refuses** — a wrong declaration would ship green. So the template's real declarations went through **core's real registries at this exact ref**: ``` registries.stage('examplegame') → register(fakeCtx(), api) eventBudgets 1 eventOptionSources 1 eventLeases 1 eventActions 1 triggers 1 audiences 1 engagementSeeds 1 teamProviders 1 registries.apply(...) accepted — ids, collisions and namespacing OK ``` That habit is why chapter 5 is worth reading. It found the chapter's own two defects, neither of them by writing prose: **an idempotency key on a *question* makes every later read permanently stale** (an at-most-once store answers a repeated key with the *original* reply, so the template's second read returned the first read's answer for ever and the module could not see a change it had just made), and **a refusal's reason goes in `error`** — core's classifier reads no other name, so a refusal reported under `detail` reached an author as a bare *"refused"*. The `why` block now records both, and the `detail` half is why `docs#227` made that member real in core. ## Verification, against a core at this ref ``` checkCoreApi coreApi ^1.10.0 matches the pinned core's 1.10.0 registry rig all four declarations accepted, apply() accepted template server 82 pass, 0 fail check:imports OK template client 20 pass, 0 fail check:externals OK, build OK prose checks checkLinks · checkRenameSites · checkChapterPaths — all OK their own tests 10 pass · 11 pass ``` Nothing else needed to move: `template/module.json` has declared `^1.10.0` since `#10`. The `branch` field stays documentary — CI clones the repo and checks out the sha — and the `why` block now says the kit skipped a third `edge` (this workstream's) for the same reason it skipped the first two: the book is written against what shipped, never against what is in flight. - [x] AI-assisted: written with Claude Code (Claude Opus 5). 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

wtclaude added 1 commit 2026-09-10 00:51:06 +00:00

chore(ci): pin the kit to the Event System core, and go green (Phase 16b)

PR Checks / prose (pull_request) Successful in 7s

Details

PR Checks / template (pull_request) Successful in 34s

Details

5dc14fa626

`ci/core-ref.json` moves from 66bb3b9a (MODULE_API 1.9.0, the engagement
cutover) to 655fbf3f -- the commit 1.10.0 reached `main` on, website#199.

This closes a red `main` rather than only dating the book. Chapter 5 landed in
#10 declaring `coreApi ^1.10.0` while this file still named a 1.9.0 core, and
`checkCoreApi` asserts EQUALITY, so the repo has been red on that check since it
merged. That was deliberate and said so in the PR, but the red belongs to the
cutover window and not to the repo; this is the commit that was always going to
close it, and it could not be written until the events sha existed on `main`.
Same shape Teams phase 11 used.

A pin move is a RUN, not an edit -- the template job checks this number and
tests the template against fakes, and a fake accepts what core refuses. So the
template's real declarations went through core's real registries at this exact
ref: the budget, the option source, the lease and the event action were all
accepted, and `apply()` accepted the set. Nothing else here needed to move;
`template/module.json` has declared ^1.10.0 since #10.

Verified against a core at this ref:

  checkCoreApi         coreApi ^1.10.0 matches the pinned core's 1.10.0
  registry rig         all four declarations accepted, apply() accepted
  template server      82 pass, 0 fail          check:imports OK
  template client      20 pass, 0 fail          check:externals OK, build OK
  prose checks         checkLinks, checkRenameSites, checkChapterPaths all OK
  their own tests      10 pass, 11 pass

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016wDDVXWMDz82WqE1i969r4

whitlocktech merged commit 7f746aee3d into main

2026-09-10 01:24:17 +00:00

whitlocktech referenced this issue from a commit

2026-09-10 01:24:22 +00:00

Merge pull request 'chore(ci): pin the kit to the Event System core, and go green (Phase 16b cutover, 5 of 6)' (#11) from chore/events-cutover-repin into main

whitlocktech deleted branch chore/events-cutover-repin

2026-09-10 01:24:25 +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#11

chore(ci): pin the kit to the Event System core, and go green (Phase 16b cutover, 5 of 6) #11

This closes a red main, not just a date

A pin move is a run, not an edit

Verification, against a core at this ref

This closes a red `main`, not just a date