Pup - the AI's own browser

@@ -0,0 +1,75 @@+# Handoff to the adom-desktop build thread — pup is now cloud-owned++Paste the block below into the adom-desktop build thread (the one that owns+`github.com/adom-inc/adom-desktop`). It mirrors what was done for the kicad/fusion bridges.++---++**Subject: The Puppeteer (pup) bridge moved out of adom-desktop into its own wiki repo — please treat it like kicad/fusion now.**++We took over code management of the Puppeteer bridge. It now lives at its own canonical wiki repo,+exactly like the kicad and fusion bridges:++- **Canonical repo / page:** https://wiki.adom.inc/adom/adom-desktop-puppeteer-bridge+- **Current published version:** **1.1.0** (release asset + streaming manifest are live)+- **Manifest (updateManifestUrl target):** `https://wiki.adom.inc/api/v1/pages/adom-desktop-puppeteer-bridge/files/adom-bridge-puppeteer-manifest.json`+- **Release zip:** `https://wiki.adom.inc/download/adom/adom-desktop-puppeteer-bridge/1.1.0/adom-bridge-puppeteer-v1.1.0.zip` (sha256 `525eabb0350ea0eaf52a949e9b3026f5a4a035868afe9546a7478298b9539b8c`, source-only — node_modules is reconstructed by AD's `npm install` on spawn, as today)++**What changed in 1.1.0 (the reason for all this):** cold-start self-heal. On a fresh PC (HD bundles+AD; the installer pre-installs neither Node nor Chrome for Testing), the first "open in pup" used to+fail with a generic "Failed to launch Chrome after 3 attempts" + a dev string (npx…). Now the bridge+detects a missing Chrome for Testing, auto-installs it (programmatically via the bundled+@puppeteer/browsers), and exposes `browser_readiness` + `browser_prewarm`; `/status` reports+led/summary/tooltip truthfully (yellow while installing). The `node_not_found` path you already own is+unchanged and still correct.++**Please make these adom-desktop changes (all small, mirroring kicad/fusion):**++1. **Keep pup a pre-installed bundled SEED** (do NOT remove it from `bundle.resources`) — same as+   kicad/fusion/blender. Fresh installs must still ship a working pup offline.++2. **Update the bundled seed `plugins/puppeteer/` to v1.1.0** so a fresh install ships the cold-start+   fix even before the first wiki sync. Easiest: download + unzip the 1.1.0 release zip (URL above)+   into `plugins/puppeteer/` (it's the `src/` tree at zip-root: `server.js`, `chrome.js`,+   `bridge.json`, `BRIDGE_VERSION`=1.1.0, etc.), keep the existing bundled `node_modules`. The seed's+   `bridge.json` already declares `updateManifestUrl` (see #3).++3. **Confirm the seed `bridge.json` carries `updateManifestUrl`** = the manifest URL above, so AD+   auto-pulls our updates (cache-over-bundled, numeric version_gt) via `refresh_bridges` / the 4h poll —+   exactly like kicad/fusion. (It's already set in the 1.1.0 source.) Add a short+   `plugins/puppeteer/CANONICAL.md` breadcrumb pointing at the wiki repo, like the kicad/fusion seeds.++4. **Stop treating `plugins/puppeteer` as the source of truth.** Don't hand-edit it as if live and don't+   `release-bridge.sh puppeteer` from the adom-desktop repo anymore (it would clobber the cloud-owned+   page). pup is now in the same bucket as kicad/fusion in `BRIDGE_OWNERSHIP.md` /+   `release-publish.sh` SKILLS_SRC — please add the same guard. (Also: pup's consumer SKILL now ships+   from the bridge's own wiki page, so drop `pup-SKILL.md` from the AD-core pkg's SKILLS_SRC to avoid a+   stale copy clobbering ours — same move you made for kicad/fusion.) **ALSO remove `"puppeteer"` from+   `AD_CORE_SKILL_BRIDGES` in `bridge_registry.rs`** so `bridge_list` reports+   `skillPkg = adom/adom-desktop-puppeteer-bridge` for the puppeteer bridge — that's what makes the daily+   `sync_skills` auto-install the pup skills into every container. It's hardcoded `null` (skill-in-core)+   today, which is no longer true now that the skill ships from the pup page.++5. **THE ONE AD-CORE FIX WE NEED (we can't do this from the bridge): warm Node + Chrome for Testing on+   the HD-embedded first-run.** Today the first-launch prefetch (`AUTOSTART_VERSION` task in `lib.rs`,+   ~lines 3601–3607) is **skipped when AD is embedded** — which is exactly the HD-bundled fresh-PC case,+   so nothing pre-warms and the whole cold-start cost lands on the user's first "open in pup". Please+   either:+   - re-enable that idle-time prefetch task on the embedded path (it already calls+     `start_browser_bridge`, which now self-installs Chrome for Testing), **or**+   - after AD enters embedded mode, fire `browser_prewarm` once (fire-and-forget) to kick the Chrome+     download in the background.+   Either way, gate it behind the existing Node check (if Node is missing it's a no-op / the+   `node_not_found` path stays the recovery). Net effect: a fresh HD install quietly warms pup so the+   user's first "open in pup" is instant instead of a 2–3 min download.++**Verify after your change:** on a fresh embedded boot with Node present, `bridge_list` shows pup at+1.1.0 (cache or seed), `browser_readiness` returns `{ready:true}` without the user ever asking, and+`bridge_check_updates` reaches the new page via `updateManifestUrl`. On a box without Node,+`browser_open_window` still returns the clean `node_not_found` → `desktop_install_node` path.++Questions / bugs in pup itself (a `browser_*` verb, a hint, the Chrome self-heal) → file them against+the wiki repo, not adom-desktop. Generic AD capabilities (a new lifecycle verb, the prewarm trigger+above) → adom-desktop, but don't re-absorb the bridge.++---