Pup - the AI's own browser

@@ -288,3 +288,43 @@ use 240 (browser_use can trigger installs), open_window 150 (spawn-verified fall candidates x 3 attempts x 30s CDP wait), record* 90. An AD timeout is NON-terminal: callers get {stillRunning:true, statusVerb, timeoutSeconds} and poll browser_readiness. When adding a verb that can block >60s, add its bare key here AND bump runtime version (bridge.json+BRIDGE_VERSION+manifest+zip).++## ⛔ EVERY SHIP IS THREE ARTIFACTS, IN THIS ORDER (John, 2026-07-25 — learned the hard way twice)++A release is not "shipped" when the zip installs. **Skills → pkg tarball → release zip.** Do all three,+in that order, every time. Both failures below were invisible from the release side, which is exactly why+they need a checklist rather than judgement.++**1. UPDATE THE SKILLS FIRST (before you build anything).** If this ship changed a verb's behavior,+response fields, hints, or defaults, the user-facing `SKILL.md` (+ any `skills/pup-*/SKILL.md`) must say+so. Consumers read the skill in their container; a hint your code returns but the skill never mentions is+half-delivered. **Measured failure:** after shipping the native-first flip, `renderCheck`/`_verifyRender`,+the AI-thread naming, and the bug-report invitation, the user-facing skill documented **none** of it —+grep found 5 of 6 new concepts missing. John asked "are your skills up to date that users would get in+their container?" and the honest answer was no.++**2. THEN PUBLISH THE PKG TARBALL.** `adom-wiki pkg publish --org adom` is what actually delivers those+skills. A release does NOT ship skills.+  - Bump `package.json` `version` to the version you are shipping, so the pkg and the release agree.+  - **THE TRAP: a release and its pkg share ONE version list, and the resolver picks the MAX row and+    fails if that row has no tarball.** Shipping releases 1.9.94→1.9.104 while the last pkg sat at 1.9.93+    made the max row a tarball-less release and **broke every constraint install of the page** —+    `adom-wiki pkg update` reported `STALE_INSTALL: the registry no longer resolves it` and skipped pup+    entirely. Nothing in the release pipeline noticed, because the release half was perfect.+  - Verify, do not assume:+    `curl -s -o /dev/null -w "%{http_code}" https://wiki.adom.inc/api/v1/packages/adom/adom-desktop-puppeteer-bridge/<VER>/tarball`+    must be **200**. `ship.sh` GATE 2b now checks this and warns, but the warning only helps if you read it.++**3. THEN THE RELEASE ZIP + MANIFEST** (the existing recipe: bump BRIDGE_VERSION + bridge.json → build →+`release upload` → repoint the manifest → `repo push` → `bridge_install` → verify on disk).++**Order matters:** skills are text inside the pkg, so publishing the pkg before editing the skills ships+the old docs; and cutting the release last means the version you verify on disk is the one whose skills+and pkg you already published.++**Quick self-check before you call a ship done:**+```bash+grep -ciE '<new concept>' SKILL.md            # 0 = the skill is stale, go back to step 1+python3 -c "import json;print(json.load(open('package.json'))['version'])"   # must equal the release+curl -s -o /dev/null -w '%{http_code}\n' https://wiki.adom.inc/api/v1/packages/adom/adom-desktop-puppeteer-bridge/$(cat src/BRIDGE_VERSION)/tarball+```