E2E Golden Path is not flaky and is not a CLI defect. It fails at Step 9/13 (nself plugin install) with:
error installing "ai": checksum verification for plugin "ai": checksum mismatch: expected eb68a...
Error: failed to install: ai
Step 9 FAILED (exit 1)
Root cause
eb68a866cb1111... is exactly the value in plugins-pro/registry.json for ai@1.1.3. The registry is correct; the tarball is not reproducible.
Pro plugin tarballs are repacked by ping_api from a GitHub codeload archive, and codeload stamps every entry's mtime with the ref's commit time. Verified on the live endpoint just now — entries in the ai tarball carry Aug 29 08:54, a plugins-pro commit time, not a fixed epoch. So any commit to plugins-pro changes every plugin's tarball bytes, which invalidates every checksum the registry just recorded.
That is why this gate has failed 47/53 runs since 2026-04-27 while the CLI itself is fine.
The fix already exists but is not deployed
nself-org/web#131 normalises entry mtime/uid/gid/mode (FIXED_MTIME = new Date(0)) in streamScopedPluginTarball. I built and verified an image containing it, but deploying it fails with column l.product does not exist — staging has applied 1 of 89 migrations, so the code is ahead of the schema. Tracked in nself-org/web#134.
Why regenerating checksums is not a fix
Recomputing registry.json from currently-published artifacts makes the gate pass exactly until the next plugins-pro commit, then it breaks again. It also silently rewrites the integrity values that the checksum check exists to protect. The tarball has to become deterministic first.
Order of operations
- Resolve the staging blocker (web#134) and deploy web#131
- Confirm two downloads spanning a plugins-pro commit produce identical bytes
- Then regenerate
registry.json checksums
- E2E Golden Path goes green on its own
Do not mark this fixed by pinning, skipping, or continue-on-error on Step 9 — the checksum check is doing its job correctly here.
E2E Golden Pathis not flaky and is not a CLI defect. It fails at Step 9/13 (nself plugin install) with:Root cause
eb68a866cb1111...is exactly the value inplugins-pro/registry.jsonforai@1.1.3. The registry is correct; the tarball is not reproducible.Pro plugin tarballs are repacked by ping_api from a GitHub codeload archive, and codeload stamps every entry's mtime with the ref's commit time. Verified on the live endpoint just now — entries in the
aitarball carryAug 29 08:54, a plugins-pro commit time, not a fixed epoch. So any commit to plugins-pro changes every plugin's tarball bytes, which invalidates every checksum the registry just recorded.That is why this gate has failed 47/53 runs since 2026-04-27 while the CLI itself is fine.
The fix already exists but is not deployed
nself-org/web#131 normalises entry mtime/uid/gid/mode (
FIXED_MTIME = new Date(0)) instreamScopedPluginTarball. I built and verified an image containing it, but deploying it fails withcolumn l.product does not exist— staging has applied 1 of 89 migrations, so the code is ahead of the schema. Tracked in nself-org/web#134.Why regenerating checksums is not a fix
Recomputing
registry.jsonfrom currently-published artifacts makes the gate pass exactly until the next plugins-pro commit, then it breaks again. It also silently rewrites the integrity values that the checksum check exists to protect. The tarball has to become deterministic first.Order of operations
registry.jsonchecksumsDo not mark this fixed by pinning, skipping, or
continue-on-erroron Step 9 — the checksum check is doing its job correctly here.