Pup - the AI's own browser

@@ -50,6 +50,36 @@ if they aren't expecting it they'll deny it and the whole cold-start dead-ends.  (Use `--target <name>` on all of these when more than one desktop is connected.) +**No-UAC alternative (portable Node).** If the user refuses/denies the UAC, install Node the user-scoped+way — **no admin, no UAC** — via `shell_execute` (which needs a one-time AD *shell* approval, see below —+NOT a UAC). Warn them, `notify_user`, then run:+```bash+adom-desktop shell_execute '{"command":"powershell -NoProfile -Command \"$v=\\\"v22.11.0\\\"; $d=\\\"$env:LOCALAPPDATA\\adom-node\\\"; $z=\\\"$env:TEMP\\node.zip\\\"; Invoke-WebRequest \\\"https://nodejs.org/dist/$v/node-$v-win-x64.zip\\\" -OutFile $z; Expand-Archive $z $d -Force; $n=(Get-ChildItem $d -Directory | Select-Object -First 1).FullName; [Environment]::SetEnvironmentVariable(\\\"Path\\\", \\\"$n;\\\"+[Environment]::GetEnvironmentVariable(\\\"Path\\\",\\\"User\\\"),\\\"User\\\")\""}'+```+Then the user **quits + reopens Adom Desktop** (so AD's PATH picks up the new user dir — again, an app+restart, not a UAC). Both Node paths still require that AD reopen; only AD bundling `node.exe` avoids it.++## Permissions on the user's desktop — what needs the user to approve++**Core AD verbs and this bridge's `browser_*` / `desktop_record_*` verbs run WITHOUT any desktop prompt.**+But **anything open-ended — `shell_execute`, `run_script`, arbitrary PowerShell/scripts — pops an AD+"Shell command needs approval" dialog** on the user's desktop (Approve 1 hr / 24 hr / Bypass Permissions).+Until the user clicks it, **your call just hangs and times out** (that's not a failure of your code — it's+waiting for approval).++- **Prefer core verbs.** Do the job with `browser_*` / `desktop_*` verbs whenever possible — they never+  prompt. Reach for `shell_execute` / `run_script` only when no verb covers it.+- **Whenever you DO issue `shell_execute` / `run_script`, warn the user first** — in chat AND with a+  desktop heads-up, so they approve instead of ignoring it:+  ```bash+  adom-desktop notify_user '{"title":"Approve the command in Adom Desktop","body":"I need to run a setup command on your PC. Please click Approve (24 hr) on the Adom Desktop popup so it can run."}'+  ```+- **It's a per-box setting.** Some machines have shell auto-approve / Bypass on and show NO popup; others+  prompt every time. If a `shell_execute` times out with no result, assume an unapproved popup is waiting —+  tell the user to approve it (or enable Bypass/24 hr), then retry.+- **This is NOT a UAC.** The shell-approval dialog is AD's own permission gate (safe to approve for your+  setup commands); a Windows UAC is the separate admin-elevation prompt (e.g. the Node MSI).+ ### "What do I have / is it ready?"  - **`browser_readiness`** (this bridge, **READ-ONLY**) → `{ready, browserKind, browserSource, browserExecutablePath, candidates, defaultBrowser, …}` — tells you which browser pup will drive (`chrome` / `edge` / `chrome-for-testing`), the **full candidate list** it will fall through, the current **default**, and whether it's ready. Never triggers a download.

@@ -123,6 +123,17 @@ What we learned and baked into the code: - **Verbose hints everywhere.** Every open returns `browser` (what we drove) + `availableBrowsers` +   `defaultBrowser` + an `_hint` explaining how to switch/install. Goal: the AI resolves any browser   situation in as few turns as possible without a human.+- **Desktop permission prompts gate open-ended verbs (learned live).** Core AD verbs + this bridge's+  `browser_*` verbs run with NO prompt. But `shell_execute` / `run_script` / arbitrary scripts pop an AD+  "Shell command needs approval" dialog (Approve 1h/24h/Bypass) — and the call **hangs until approved**+  (we saw `shell_execute` time out on the vbox with the popup waiting; winvm had it auto-approved and+  showed nothing). Two consequences baked into SKILL.md: (1) prefer core/`browser_*` verbs over shell;+  (2) before any `shell_execute`, `notify_user` the person to approve the popup. This is a separate gate+  from the Windows UAC (admin elevation) — don't conflate them.+- **No prompt-free Node without AD.** pup is a Node process AD spawns via `node` on PATH. Getting Node onto+  a fresh box costs SOME prompt: the MSI (`desktop_install_node`) = a UAC; portable Node (zip→user dir→user+  PATH via `shell_execute`) = a shell-approval, no UAC. BOTH then need AD reopened (stale PATH). The only+  zero-prompt path is AD bundling `node.exe` / doing the portable install itself — see HANDOFF.  ## Publishing (the wiki has TWO storage layers — don't mix them) 

@@ -1,6 +1,6 @@ {   "slug": "adom-desktop-puppeteer-bridge",-  "version": "1.5.1",+  "version": "1.5.2",   "type": "app",   "description": "CONTAINER-SIDE install \u2014 the everyday `pup` user skill only. This pkg drops the `pup` skill (drive the browser bridge: open/close/tabs/screenshot/record, background-by-default) into ~/.claude/skills/ AND ~/.codex/skills/. It does NOT install the developer/publishing skills (pup-bridge-dev, pup-bridge-publish) \u2014 those are source-only; clone the repo (adom-wiki repo clone adom/adom-desktop-puppeteer-bridge) to get them from dev-skills/. It also does NOT contain the bridge runtime: the bridge (Node + Chrome for Testing) lives on the DESKTOP \u2014 bundled inside Adom Desktop and published here on the Releases tab as adom-bridge-puppeteer-v<ver>.zip, which Adom Desktop streams into its bridges-cache. TL;DR: `pkg install` = the pup user skill; dev skills = clone the source; the bridge = the Release zip + bundled in Adom Desktop.",   "keywords": [