app
Pup - the AI's own browser
Public Made by Adomby adom
pup gives your AI a real browser on your desktop that it drives completely, in the background, signed in as you: windows that never jump in front of your work, one shared profile that learns your logins, and every window labeled on the taskbar with its AI thread's name.
← Commit history
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",