Pup - the AI's own browser

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.9.161",+  "version": "1.9.162",   "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": [

@@ -1,7 +1,7 @@ --- name: pup-adom-wiki user-invocable: true-description: "Driving the Adom wiki (wiki.adom.inc) inside a pup window — the common case of loading, viewing, and VERIFYING wiki pages with the browser_* verbs. Use when the user says show me the wiki / open my wiki page in pup / verify my page rendered / check the hero/version/download card / does my published page look right. Covers: pup shows the RENDERED page (use the adom-wiki CLI for API tasks like publish/search/releases — NOT pup); wiki pages are component-heavy with nested scroll, so use the shadow-DOM-survey + scroll-the-element techniques; and the LOGIN situation — pup currently sees the wiki LOGGED OUT (auto-login from the container identity isn't supported yet; tracked in adom/wiki discussion #89), so don't claim logged-in-only content and offer auto-login only once that lands. Trigger words: adom wiki, wiki.adom.inc, show me the wiki, open the wiki in pup, open my wiki page, verify my wiki page, check my hero, wiki version chip, download card, wiki page rendered, is my page live, wiki login pup, log into the wiki."+description: "Driving the Adom wiki (wiki.adom.inc) inside a pup window — the common case of loading, viewing, and VERIFYING wiki pages with the browser_* verbs. Use when the user says show me the wiki / open my wiki page in pup / verify my page rendered / check the hero/version/download card / does my published page look right. Covers: pup shows the RENDERED page (use the adom-wiki CLI for API tasks like publish/search/releases — NOT pup); wiki pages are component-heavy with nested scroll, so use the shadow-DOM-survey + scroll-the-element techniques; and the LOGIN situation — every pup window shares ONE durable profile (v1.9.162), so once the user signs into the wiki once it stays logged in everywhere; wikiView:"public" is the explicit logged-OUT view for publish-visibility checks. Trigger words: adom wiki, wiki.adom.inc, show me the wiki, open the wiki in pup, open my wiki page, verify my wiki page, check my hero, wiki version chip, download card, wiki page rendered, is my page live, wiki login pup, log into the wiki." ---  **Parent skill:** adom-desktop-puppeteer-bridge  ·  See also: `pup` (start here), `pup-screenshots-recording` (the tricky-pages techniques), the `adom-wiki` skill (the CLI for API work).@@ -50,10 +50,14 @@ The wiki renders widgets (download cards, sample-prompt cards, the hero) and oft pup can now open a wiki page from **either viewpoint**, and the killer use is showing the user **both** to verify publish visibility: -- **Public / anonymous (default):** `browser_open_window {sessionId, url:"https://wiki.adom.inc/..."}`-  — a fresh logged-out profile: exactly what the WORLD sees.-- **Logged-in:** `browser_open_window {sessionId, url:"...", wikiView:"authed"}` — routes to pup's-  reserved persistent authed-wiki profile whose cookie jar holds a 30-day SSO session.+- **Logged-in (the DEFAULT now, v1.9.162):** a plain `browser_open_window {url:"https://wiki.adom.inc/..."}`+  opens in the ONE shared `adom-you` profile — the same jar every other pup window uses — so once+  the user has signed into the wiki once, EVERY wiki window (and every other pup window) is already+  logged in. `wikiView:"authed"` is now just the explicit name for this default.+- **Public / anonymous (EXPLICIT):** `browser_open_window {url:"...", wikiView:"public"}` — this is+  the ONLY wiki view that gets a separate jar: a fresh logged-OUT isolated profile, because showing+  "what the world sees" requires being logged out. It does NOT accumulate anything and is only for+  a deliberate publish-visibility check.  **Use ONE window normally.** Don't open two windows for the same page — that double-reloads and annoys. Just pick the view the task needs. The ONLY time to compare both is a deliberate@@ -63,13 +67,12 @@ public should get only the binaries but I keep the source private — did the AI the source?"* The public view answers that directly (if you can see `src/` there, it leaked). The response `_hint` tells you which view you opened and nudges you to open the other. -**One-time login for the authed view.** The first `wikiView:"authed"` open (or after the ~30-day-session expires) comes back with `wikiLoginNeeded:true`. To sign in: `browser_raise_os_window`-with a `foregroundReason` like `"sign into the Adom wiki"` so the user completes the-hydrogen.adom.inc SSO once; the session then persists in the authed profile and every later-`wikiView:"authed"` open is logged in automatically. Tell the user it is a one-time login.-(Container-identity auto-login — no interactive step — is still tracked in `adom/wiki` #89; when it-lands, this becomes zero-touch.)+**One-time login, then it accumulates.** If the shared profile has not been signed into the wiki+yet, an authed open comes back `wikiLoginNeeded:true`. Sign in once: `browser_raise_os_window` with+a `foregroundReason` like `"sign into the Adom wiki"`, the user completes the hydrogen.adom.inc SSO,+and the session now lives in the ONE shared `adom-you` jar (v1.9.162) — so it is logged in for every+pup window from then on, not just wiki ones. Tell the user it is a one-time login.+(Container-identity auto-login — zero interactive step — is still tracked in `adom/wiki` #89.)  **The user can flip the view themselves (v1.9.3).** Every wiki pup window carries a **taskbar right-click menu** task — "🔓 Switch to logged-in view" on a public window, "📖 Switch to public

@@ -65,7 +65,17 @@ persists on disk. Email+password works too but needs a credential you do not hav    other durable-profile login. Do NOT tell the user "you're logged in and it'll stick" until the    reopen check passes — that claim was made falsely once and the window came up logged out. -## Which profile — and why NOT the shared one for a crashy portal+## ORG DEFAULT (v1.9.162): ONE shared profile for everything++John's standing decision: ALL pup windows use the single durable `adom-you` profile so logins+accumulate into one growing store that gets nicer to use over time. So the "dedicated per-vendor+profile" advice below is the SAFER-but-not-default option — reach for `{profile:"autodesk"}` only+when a specific portal is known to crash and the user asks for isolation. By default, sign the user+in on the shared profile (no `profile` arg). The crash tradeoff is knowingly accepted: one Chrome+process, so a portal crash takes every session down together — which is exactly why the+close+reopen+verify flush discipline in step 6 matters even more.++## Which profile — the isolation option (not the default)  - **Persistence needs a durable profile** (default `adom-you`, or a named one). Never `isolated:true`   for a login you want to keep.