The Games tab in production shows three games; the feed has six
sceneTemplates.js reads https://cdn.jsdelivr.net/gh/theprototype-app/scenes@v2/index.json. The serving ritual retags v2 (git tag -f v2 && git push -f origin v2) and purges — and the retag is never picked up.
Root cause (measured 2026-09-20)
jsDelivr parses v2 as a semver version, not a tag:
$ curl -s https://data.jsdelivr.com/v1/package/gh/theprototype-app/scenes
{ "tags": {}, "versions": ["1", "2"] }
$ curl -sD - https://cdn.jsdelivr.net/gh/theprototype-app/scenes@v2/index.json | grep x-jsd
x-jsd-version: 2
x-jsd-version-type: version <- cached PERMANENTLY, never re-resolved
Files under a resolved version are immutable on jsDelivr's side; purge.jsdelivr.net reports finished for the path but the version→commit resolution is not refreshed. Result: scenes@v2/index.json is still the copy from before Jam Room (towers, stars-room, football), ~16 h and four purges after the retag, while the new files resolve by path (they were never cached) and scenes@a5ebe8f/index.json is right.
@main resolves as a branch (x-jsd-version-type: branch, cached ≤ 12 h, purgeable) and lists all six games.
Options (a product decision — the pinned-format-tag convention is the user's)
- Point
SCENES_BASE at a non-semver ref. A branch (scenes@main, or a format-2 branch that only moves on the ritual) or a tag whose name jsDelivr cannot parse as a version (format-2). Keeps "new ref per FORMAT bump only". One-line change in sceneTemplates.js (+ the same trap for packs@v1, which has not been retagged yet and will hit this the day it is).
- Cloud build override today, no core release:
VITE_SCENES_BASE=https://cdn.jsdelivr.net/gh/theprototype-app/scenes@main in the cloud .env.deploy — contentBase() exists for exactly this. Production shows the six games on the next deploy.
- Per-release commit pins (
scenes@<sha>): always fresh, but every content change becomes a core release, which the tag convention was chosen to avoid.
Recommended: 2 now (a deploy), then 1 in the next core release, with a note in the scenes repo's ritual that v2 is dead on jsDelivr.
Found while closing roadmap 29 round 2 (lane 29-integrate).
The Games tab in production shows three games; the feed has six
sceneTemplates.jsreadshttps://cdn.jsdelivr.net/gh/theprototype-app/scenes@v2/index.json. The serving ritual retagsv2(git tag -f v2 && git push -f origin v2) and purges — and the retag is never picked up.Root cause (measured 2026-09-20)
jsDelivr parses
v2as a semver version, not a tag:Files under a resolved version are immutable on jsDelivr's side;
purge.jsdelivr.netreportsfinishedfor the path but the version→commit resolution is not refreshed. Result:scenes@v2/index.jsonis still the copy from before Jam Room (towers, stars-room, football), ~16 h and four purges after the retag, while the new files resolve by path (they were never cached) andscenes@a5ebe8f/index.jsonis right.@mainresolves as a branch (x-jsd-version-type: branch, cached ≤ 12 h, purgeable) and lists all six games.Options (a product decision — the pinned-format-tag convention is the user's)
SCENES_BASEat a non-semver ref. A branch (scenes@main, or aformat-2branch that only moves on the ritual) or a tag whose name jsDelivr cannot parse as a version (format-2). Keeps "new ref per FORMAT bump only". One-line change insceneTemplates.js(+ the same trap forpacks@v1, which has not been retagged yet and will hit this the day it is).VITE_SCENES_BASE=https://cdn.jsdelivr.net/gh/theprototype-app/scenes@mainin the cloud.env.deploy—contentBase()exists for exactly this. Production shows the six games on the next deploy.scenes@<sha>): always fresh, but every content change becomes a core release, which the tag convention was chosen to avoid.Recommended: 2 now (a deploy), then 1 in the next core release, with a note in the scenes repo's ritual that
v2is dead on jsDelivr.Found while closing roadmap 29 round 2 (lane 29-integrate).