← Commit history

Publish 1.9.106

John Lauer ·dbc4b2b012 ·3mo ago ·parent cc0f510
3 files changed +45−2
SKILL.md+43
@@ -177,3 +177,46 @@ threads; pass `wikiView:"authed"|"public"` on browser_open_window instead. Detai   opens** while AD says `bridge_starting` — one is enough; it's already starting. (`bridge_list`   `status:"running"` is not liveness; the LED + `browser.bridgeRunning` + an actual verb reply are.) - Full machine-readable catalog: `adom-desktop browser_describe '{}'`.++## Verify what you rendered — pup checks it FOR you (v1.9.106)++**`ok:true` means the navigation worked. It says NOTHING about whether the page rendered.** A thread+recently opened its own app, got `ok:true`, and told the user it worked. The page was serving+`404 page not found`.++So pup now looks. Every `browser_open_window` / `browser_open_tab` / `browser_navigate` /+`browser_reload` response can carry two fields:++- **`renderCheck`** — a verdict: `{ok, httpStatus, signals[], excerpt, bodyChars, elements}`. Signals+  include `http_404`, `page_says_not_found`, `dev_server_cannot_get`, `server_error_text`,+  `stack_trace_visible`, `effectively_blank`, `no_stylesheets_loaded`, `broken_images_N`.+- **`_verifyRender`** — what to do. When `renderCheck.ok` is false it leads with+  *"THIS PAGE DID NOT RENDER CORRECTLY — pup checked it, so do NOT report success"*.++**The rule: if `renderCheck.ok === false`, do not tell the user it works.** Screenshot it+(`browser_screenshot {sessionId}`) and READ the image, fix the cause, `browser_reload`, and re-check+until the response comes back clean. A 404 or "Cannot GET" usually means the dev server is not running,+is on a different port, or the path is wrong; unstyled HTML means the CSS 404'd; a stack trace means the+app threw.++`renderCheck` is a cheap DOM probe, not a screenshot, so it can miss things a human eye catches (wrong+layout, wrong content, an element off-screen). A clean `renderCheck` is not proof the page is *right* —+when you generated or edited the content, screenshot it anyway.++## Name your thread so the user can tell your window apart++Pass `--ai-thread "<what this conversation is>"` on every `adom-desktop` call (a global flag, like+`--target`). A typical user runs ~20 AI threads against one desktop, so pup puts your thread name at the+FRONT of the window title (visible in the taskbar hover-preview header, which truncates ~25-30 chars)+and in the hover tooltip alongside the container, browser and session. That is how the user knows which+of their conversations opened a window. Do NOT export `ADOM_AI_THREAD` — threads share one container, so+it names the shell rather than you.++## Found a pup bug? Please report it++Responses carry `_reportIssues` on failures and on your first substantive verb. Reports from real+machines are the only way this bridge gets correct:+`adom-wiki issue list adom/adom-desktop-puppeteer-bridge` to check for a duplicate, then+`adom-wiki issue create adom/adom-desktop-puppeteer-bridge --title "<symptom>" --category bug-report+--body "<what you ran, expected, got, the VERBATIM response JSON, bridge version, OS>"`.+An AD-core problem (relay, bridge lifecycle, caller identity) goes to `adom/adom-desktop` instead.
package.json+1−1
@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.9.104",+  "version": "1.9.106",   "type": "app",   "description": "The pup SKILL PACK \u2014 the AI skills that teach a cloud/container AI how to drive the Adom Desktop Puppeteer (pup) bridge (browser_* verbs): the everyday `pup` skill plus focused sub-skills for windows/sessions/tabs, screenshots+recording, browsers+Chrome install, and driving the Adom wiki. Installs into ~/.claude/skills + ~/.codex/skills. DOCS ONLY \u2014 this is NOT the bridge runtime. The bridge itself (the Node program that drives the browser) runs on the DESKTOP: Adom Desktop bundles it and auto-installs/updates it, and it's published separately on the Releases tab as adom-bridge-puppeteer-v<ver>.zip. So the pkg version (skills, bumps often) and the Release version (runtime, bumps rarely) differ on purpose. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.",   "keywords": [
page.json+1−1
@@ -4,7 +4,7 @@   "slug": "adom-desktop-puppeteer-bridge",   "title": "Adom Desktop - Puppeteer Bridge",   "brief": "The Adom Desktop Puppeteer (pup) bridge — drive a real headful browser on the user's desktop from the cloud: open/screenshot/eval/record. Cold-start drives the browser ALREADY on the machine (installed Chrome, else Microsoft Edge — every Windows PC ships with Edge) with a fresh isolated profile, so the common case needs NO download; Chrome for Testing is fetched only as a last resort. Two artifacts: the Releases zip is the bridge runtime (also bundled in Adom Desktop); the pkg installs the container-side Claude skills.",-  "version": "1.9.104",+  "version": "1.9.106",   "tags": [     "skills",     "pup",