ci(core-ref): pin core at MODULE_API 1.9.0, unbreaking frozen-manifest #25

wtclaude · 2026-09-01T12:36:19Z

wtclaude commented

2026-09-01 12:36:19 +00:00

The frozen-manifest red on #24 was structural and predated it. This is the bump you scheduled for the moment website#178 landed — it should have ridden in #24 and did not. One file, two lines.

Why it was red

ci/core-ref.json pinned 963d734 — website main at the Teams cutover, MODULE_API 1.6.0. That core has no ceilings.js, no registerEventTriggers and no registerAudiences, so the module has failed to load into it since Phase 11a added the first of those calls. The job clones core at the pin and drops the module in, so a module that cannot register cannot have its routes diffed.

The break is datable: the last green run was #39 (6a276a7, Phase 10's protocol-5 ingest), which added no register* call and so still loaded against 1.6.0. Phase 11a (#22) failed this exact job and was merged anyway, and every engagement PR since has inherited it.

New pin: 52eac24 — website edge carrying MODULE_API 1.9.0 (registerEngagementSeeds) and the Phase 11b core fixes (website#179).

`routes.manifest.json` is not regenerated, deliberately

The pin's own comment says "bump it, regenerate routes.manifest.json, and commit both together" — and here there is nothing to regenerate. Phase 11b added triggers, bodies and rules and not one route. The job's own check is the evidence rather than my assertion:

routes.manifest.json is current — 73 routes, all documented

Committing a no-op regeneration would just be churn in the file the check exists to keep honest.

Reproduced locally, the way the job does it

The runner's Actions logs are unreadable from here, so the job's steps were run by hand against the new sha:

core @ 52eac24, deps installed
routes:manifest --check  (core alone)     → route manifest up to date (243 routes)
module installed, npm ci --omit=dev
routes:manifest          (core + module)  → 312 public + 4 internal
  [uo] registered v0.5.0 {"streams":7,"triggers":26,"audiences":3}
frozenManifest.js --check                 → current, 73 routes, all documented

The triggers: 26 line is the one worth reading twice — that is the module registering against a core that actually has the API it calls, which is the whole thing that was broken.

check:imports and check:bundle also clean. The 527 tests are unaffected (no source change).

Reverts to a main sha at the Phase 13 cutover, which is what the pin is for.

AI-assisted: written with Claude Code.

🤖 Generated with Claude Code

The `frozen-manifest` red on **#24** was structural and predated it. This is the bump you scheduled for the moment website#178 landed — **it should have ridden in #24 and did not.** One file, two lines. ## Why it was red `ci/core-ref.json` pinned `963d734` — website `main` at the Teams cutover, **MODULE_API 1.6.0**. That core has no `ceilings.js`, no `registerEventTriggers` and no `registerAudiences`, so the module has failed to *load* into it since Phase 11a added the first of those calls. The job clones core at the pin and drops the module in, so a module that cannot register cannot have its routes diffed. The break is datable: the last green run was **#39** (`6a276a7`, Phase 10's protocol-5 ingest), which added no `register*` call and so still loaded against 1.6.0. **Phase 11a (#22) failed this exact job and was merged anyway**, and every engagement PR since has inherited it. New pin: **`52eac24`** — website `edge` carrying MODULE_API 1.9.0 (`registerEngagementSeeds`) and the Phase 11b core fixes (website#179). ## `routes.manifest.json` is not regenerated, deliberately The pin's own comment says "bump it, regenerate `routes.manifest.json`, and commit both together" — and here there is nothing to regenerate. Phase 11b added triggers, bodies and rules and **not one route**. The job's own check is the evidence rather than my assertion: ``` routes.manifest.json is current — 73 routes, all documented ``` Committing a no-op regeneration would just be churn in the file the check exists to keep honest. ## Reproduced locally, the way the job does it The runner's Actions logs are unreadable from here, so the job's steps were run by hand against the new sha: ``` core @ 52eac24, deps installed routes:manifest --check (core alone) → route manifest up to date (243 routes) module installed, npm ci --omit=dev routes:manifest (core + module) → 312 public + 4 internal [uo] registered v0.5.0 {"streams":7,"triggers":26,"audiences":3} frozenManifest.js --check → current, 73 routes, all documented ``` The `triggers: 26` line is the one worth reading twice — that is the module registering against a core that actually has the API it calls, which is the whole thing that was broken. `check:imports` and `check:bundle` also clean. The 527 tests are unaffected (no source change). **Reverts to a `main` sha at the Phase 13 cutover**, which is what the pin is for. --- AI-assisted: written with Claude Code. 🤖 Generated with [Claude Code](https://claude.com/claude-code)

wtclaude added 1 commit 2026-09-01 12:36:21 +00:00

ci(core-ref): pin core at MODULE_API 1.9.0, unbreaking frozen-manifest

PR Checks / client-build (pull_request) Successful in 17s

Details

PR Checks / server-tests (pull_request) Successful in 21s

Details

PR Checks / frozen-manifest (pull_request) Successful in -35s

Details

3139cb4364

The pin was `963d734` -- website `main` at the Teams cutover, MODULE_API **1.6.0**.
That core has no `ceilings.js`, no `registerEventTriggers` and no
`registerAudiences`, so this module has failed to load into it since Phase 11a
added the first of those calls, and `frozen-manifest` has been red on every
engagement PR since. The last green run was #39 (`6a276a7`, Phase 10's
protocol-5 ingest), which added no `register*` call and so still loaded.

The red X was never about the PR in front of it. This is the bump the org lead
scheduled for the moment website#178 landed; it should have ridden in
Module-uo#24 and did not.

New pin: `52eac24` -- website `edge` carrying MODULE_API 1.9.0
(`registerEngagementSeeds`) and the Phase 11b core fixes (website#179).

`routes.manifest.json` is unchanged and is NOT regenerated here: this phase's
work added triggers, bodies and rules, and not one route. The job's own check
confirms it -- 73 routes, all documented.

Reproduced locally the way the job does it: core at the new sha, manifest without
the module, module installed with `npm ci --omit=dev`, manifest with it, then
`frozenManifest.js --check`. The module registers cleanly (26 triggers, 3
audiences) and the check passes. `check:imports` and `check:bundle` clean.

Reverts to a `main` sha at the Phase 13 cutover.

Co-Authored-By: Claude <noreply@anthropic.com>

whitlocktech merged commit 3a81766526 into edge

2026-09-01 12:52:06 +00:00

whitlocktech deleted branch ci/bump-core-ref-1.9.0

2026-09-01 12:52:06 +00:00

whitlocktech referenced this issue from a commit

2026-09-01 12:52:07 +00:00

Merge pull request 'ci(core-ref): pin core at MODULE_API 1.9.0, unbreaking frozen-manifest' (#25) from ci/bump-core-ref-1.9.0 into edge

wtclaude referenced this pull request

2026-09-01 13:47:58 +00:00

feat(engagement): 26 shard triggers and the in-universe bodies — cutover 4 of 7 (`edge` → `main`) #26

wtclaude referenced this pull request

2026-09-01 17:48:22 +00:00