wtclaude
c679944181
Module-uo#25 moved this pin onto website `edge` (52eac24) to unbreak frozen-manifest during the engagement window, with its own note saying it reverts to a `main` sha at the cutover. The cutover is step 4 of 7, merged as #26, and website#180 landed the same code on `main` -- so the pin now names a branch that no longer exists. No regeneration, and the reason is checkable rather than asserted: website's tree at 66bb3b9a (main, the cutover merge) and at 52eac24d (the edge head it merged) are the SAME tree, e7a7240. `main` was zero commits ahead, so the merge carried edge's tree unchanged. The frozen-manifest job clones a different commit and reads identical bytes; routes.manifest.json cannot move. What changes is what a reader learns from the file: which core this module was last proved against, named by a ref they can still resolve. Co-Authored-By: Claude <noreply@anthropic.com>
7 lines
847 B
JSON
7 lines
847 B
JSON
{
|
|
"$comment": "The core this module is proved against. MODULE_API.md §5.3: the frozen-manifest job clones RunicGateway/website at this exact ref, drops this module in as modules/uo and runs CORE's own routeManifest.js — nothing else can answer whether the URLs the module claims are the URLs it actually serves. Pinned rather than tracking `edge` on purpose: core moves for reasons that have nothing to do with this module, and a bump is then a deliberate commit saying which core the module was last proved against, instead of an unexplained red X on someone else's PR. Bump it, regenerate routes.manifest.json, and commit both together.",
|
|
"repo": "https://gitea.whitlocktech.com/RunicGateway/website.git",
|
|
"ref": "66bb3b9a3fad01112c06f32d931c9bae56d22de6",
|
|
"refName": "main @ MODULE_API 1.9.0, the engagement cutover (website#180)"
|
|
}
|