← Commit history

Document the three ship verification gates (served-zip hash via plain download, gate on install result, on-disk version) and the dependency-bump node_modules refresh

John Lauer ·5a5e6022f5 ·3mo ago ·parent 2171418
1 file changed +36−3
publish-skills/pup-bridge-publish/SKILL.md+36−3
@@ -113,12 +113,45 @@ The pkg description lives in the root **`package.json`** `description` — keep   indexed, tab-listed, `skills install`-able skill. (This is *separate* from `pkg install`, which installs   the pkg tarball governed by the `files` allowlist.) Corollary → see "Keep dev/publish skills source-only". -## Verify (every ship)+## Verify (every ship) — THREE GATES, and none of them is "the manifest version matched"++Learned the hard way 2026-07-24: a ship can report success while deploying NOTHING. Three independent+failures stacked in one session — a `release upload` that silently didn't replace the served zip, an+edge cache serving a stale zip to AD's download path, and AD preserving stale `node_modules` so a+dependency bump never applied. Each gate below catches one; skip them and you WILL pass a broken deploy.++**GATE 1 — the SERVED ZIP hash, fetched the way AD fetches it (PLAIN url, NO cache-buster).**+The manifest version matching is NOT proof. AD downloads the manifest's `url` with no cache-buster, so+an edge cache can hand it a STALE zip while your `?cb=`-busted curl sees the fresh one. bridge_install's+sha256 guard then correctly REFUSES it (`sha256 mismatch: manifest=… got=…`).+```bash+curl -sL -o /tmp/served.zip "https://wiki.adom.inc/download/adom/.../adom-bridge-puppeteer-v<V>.zip"   # NO ?cb=+test "$(sha256sum /tmp/served.zip | cut -d' ' -f1)" = "<local zip sha>" || echo "STALE — do not install"+```+If it stays stale after a few retries, the edge cache is poisoned at that URL: **bump to a FRESH+version** to get a new URL the cache has never seen. Re-uploading to the same version often won't bust it.++**GATE 2 — bridge_install actually succeeded. NEVER pipe it to /dev/null.**+A sha mismatch (Gate 1) surfaces ONLY here, as an `"ok": false` / `"error": "sha256 mismatch…"`. Capture+the output and grep for `"status": "ok"`; do not print "installed" unless it's there.++**GATE 3 — the version ON DISK, not what install claimed.**+```bash+adom-desktop --target <name> shell_execute '{"command":"cmd /c type \"%LOCALAPPDATA%\\Adom Desktop\\bridges-cache\\puppeteer\\BRIDGE_VERSION\"", "reason":"…"}'+```+(Use `cmd /c type`, not `powershell -File` — a damaged PS profile on some boxes drops `-File` to an+interactive banner and burns the timeout.)++**DEPENDENCY BUMPS need an extra step.** If you changed `package.json`/`package-lock.json` (e.g. a+puppeteer bump to move CfT), the code deploys but the DEPS do NOT: AD's `preserve_client_deps` carries+the old `node_modules` across re-sync. Force a fresh install: `bridge_kill` → `rmdir /s /q …\node_modules`+→ `restart_bridge` (AD npm-installs when node_modules is missing). Then confirm with+`node -e "require('puppeteer').executablePath()"` on the box. (Fleet-wide this needs an AD fix —+npm-install-on-lockfile-change — filed in AD_REQUEST_bridge_staleness.md.)  ```bash-# manifest serves at the updateManifestUrl path:+# manifest serves at the updateManifestUrl path (necessary, NOT sufficient — see Gate 1): curl -s https://wiki.adom.inc/api/v1/pages/adom-desktop-puppeteer-bridge/files/adom-bridge-puppeteer-manifest.json | jq .sha256-# live install + new verbs on a real desktop (multi-desktop → --target; `adom-desktop targets` lists them): adom-desktop --target <name> bridge_install '{"manifestUrl":".../files/adom-bridge-puppeteer-manifest.json","force":true}' adom-desktop --target <name> browser_readiness '{}' # render the page in pup + READ the screenshot (curl 200 is NOT verification). Confirm version + Skills tab.