Pup - the AI's own browser

@@ -1,6 +1,6 @@ {   "slug": "pup-bridge",-  "version": "2.0.556",+  "version": "2.0.557",   "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. The pkg version is kept in lockstep with the Release version so the page's max version row always carries BOTH a pkg tarball (skills) and a runtime zip (bridge) \u2014 a skills-only or runtime-only bump on the top row breaks constraint installs. TL;DR: pkg install = the skills for your AI; the bridge = the Release zip, which Adom Desktop manages for you.",   "keywords": [@@ -147,5 +147,5 @@       "prompt": "Download the puppeteer-bridge zip from the wiki and walk me through server.js"     }   ],-  "changelog": "The real fix for the external-extension Action required bubble, replacing the 2.0.553 attempt. Diagnosis: on Windows, extension settings live in Secure Preferences under MAC protection, not in Preferences, so pre-seeding extensions.settings.<id>.ack_external (2.0.553) never landed and is removed as an approach. The registry-installed extensions (Adobe Acrobat efaidnbmnnnibpcajpcglclefindmkaj, Application Launcher for Drive lmjegmlicamnimmfhcmpkclmigmmcbeh) were confirmed present in adom-you Secure Preferences with location 6 (external registry) and unacknowledged, which is exactly the state that raises the bubble. Fix: every Chrome for Testing launch now passes --disable-extensions-except=<pup's own extension paths> alongside --load-extension, so only pup's toolbar extensions are enabled and Chrome's external registry providers do not install anything into pup profiles. Profile-scoped via launch flags; the machine registry is untouched."+  "changelog": "Taskbar identity regression in the extension lane, fixed (John, 2026-09-14: 'why is my windows taskbar icon just this? did you regress on the windows taskbar icons?'). An ext-lane window whose birth outran open_window_ext's 3 s hwnd wait (the 2.0.545 birth goes about:blank, identity shim, then the real URL, which can take longer on a cold browser) kept hwnd None for ever, so identity::stamp had nothing to stamp and the button wore Chrome's stock icon under its native per-profile AUMID. Three changes: (1) extdrive::rebind_unbound runs on every 15 s health tick and on pup_rescan, binding every unbound ext session to the lane window and stamping it exactly as a timely birth would; (2) pup_audit_icons now reports an unbound or unstamped session as a finding instead of zero findings; (3) pup_rescan judges ext sessions by the lane's liveness rather than a debug port they deliberately never have, so it stops calling a live ext window 'their Chrome is gone'. The birth wait is also 6 s. Carries 2.0.556's --disable-extensions-except bubble fix." }

@@ -4,7 +4,7 @@   "slug": "pup-bridge",   "title": "Pup - Puppeteer Bridge",   "brief": "pup is the AI's own browser: a real, full Chrome on the user's desktop that the AI fully controls (a sandbox, not the user's signed-in browser). Rides Bridge; pup_* verbs open windows and tabs, navigate, screenshot, and eval JS.",-  "version": "2.0.556",+  "version": "2.0.557",   "tags": [     "skills",     "pup",@@ -167,5 +167,5 @@       "pup-bridge verbs are invoked through the adom-bridge CLI, not through a binary this package installs, so prefix rules cannot reach them."     ]   },-  "changelog": "The real fix for the external-extension Action required bubble, replacing the 2.0.553 attempt. Diagnosis: on Windows, extension settings live in Secure Preferences under MAC protection, not in Preferences, so pre-seeding extensions.settings.<id>.ack_external (2.0.553) never landed and is removed as an approach. The registry-installed extensions (Adobe Acrobat efaidnbmnnnibpcajpcglclefindmkaj, Application Launcher for Drive lmjegmlicamnimmfhcmpkclmigmmcbeh) were confirmed present in adom-you Secure Preferences with location 6 (external registry) and unacknowledged, which is exactly the state that raises the bubble. Fix: every Chrome for Testing launch now passes --disable-extensions-except=<pup's own extension paths> alongside --load-extension, so only pup's toolbar extensions are enabled and Chrome's external registry providers do not install anything into pup profiles. Profile-scoped via launch flags; the machine registry is untouched."+  "changelog": "Taskbar identity regression in the extension lane, fixed (John, 2026-09-14: 'why is my windows taskbar icon just this? did you regress on the windows taskbar icons?'). An ext-lane window whose birth outran open_window_ext's 3 s hwnd wait (the 2.0.545 birth goes about:blank, identity shim, then the real URL, which can take longer on a cold browser) kept hwnd None for ever, so identity::stamp had nothing to stamp and the button wore Chrome's stock icon under its native per-profile AUMID. Three changes: (1) extdrive::rebind_unbound runs on every 15 s health tick and on pup_rescan, binding every unbound ext session to the lane window and stamping it exactly as a timely birth would; (2) pup_audit_icons now reports an unbound or unstamped session as a finding instead of zero findings; (3) pup_rescan judges ext sessions by the lane's liveness rather than a debug port they deliberately never have, so it stops calling a live ext window 'their Chrome is gone'. The birth wait is also 6 s. Carries 2.0.556's --disable-extensions-except bubble fix." }\ No newline at end of file