NB - Native Browser Bridge

@@ -71,7 +71,7 @@   "visibility": "public",   "brief": "Your real browser, driven by AI.",   "discovery_pitch": "nbe (the Adom Native Browser Extension, layer 2 of nb) drives the user's REAL signed-in Chrome/Edge via nbrowser_* verbs: use it for LOGGING IN, filling forms, and downloading behind auth with their OWN saved passwords - pup cannot (it is a fresh Chrome-for-Testing with no logins). Next moves: run 'adom-bridge bridge_list' to check it is installed; if not, OFFER to install it (see the installing-the-extension skill) - never make the user do it. If this container lacks the skills, 'adom-wiki pkg install adom/nb-bridge'. Check readiness with 'adom-bridge nbrowser_readiness' (state:needs-extension means offer the install).",-  "version": "0.16.1",+  "version": "0.16.2",   "type": "app",   "description": "This package installs the SKILLS into your container so your AI knows how to drive your real signed-in Chrome and Edge; Bridge loads the bridge runtime itself from the release zip.",   "install": {

@@ -284,7 +284,18 @@ This is **not** screenshot→eyeball-a-pixel→click automation, so it does **no   xy at all (it only does OS-level foreground/taskbar/window-screenshots). **This is now ENFORCED   (`stale_coordinates`, v0.1.0):** a raw `{x,y}` click is refused unless you pass `atScrollX`/`atScrollY`   from your latest screenshot's coordMap AND the page hasn't scrolled since (the "Next" pixel that became-  "Back" after a re-render). Just click by `text`/`selector`.+  "Back" after a re-render). Just click by `text`/`selector`. **The gate is for CLICKS only (ext 0.2.10,+  nb-bridge#41):** `nbrowser_hover`, `input_dispatch type:"move"`, and the wheel verbs accept raw `{x,y}` with+  no `atScrollX/Y`, because a stale hover shows the wrong tooltip but never presses the wrong control. A+  coordinate scan of a canvas (hover a grid of points, read the tooltip after each) needs no boilerplate.+- **Mouse wheel / canvas zoom: `nbrowser_scroll {sessionId, x, y, deltaY:-300}`** (or `input_dispatch+  type:"wheel"`). A real isTrusted `Input.dispatchMouseEvent mouseWheel` at that point, which is what a+  Babylon/three.js camera and a page-owned scroll pane listen for; `press_key` cannot do it. `deltaY` negative+  zooms in / scrolls up, positive out / down; `steps:5` splits a big delta for apps that clamp per event.+  `pageScrolled:false` is normal on a canvas that consumed the wheel: verify with a screenshot or an eval of+  the app state. **An unknown `input_dispatch` type is REFUSED (`unknown_input_type`)**; before 0.2.10 it fell+  through to a click, which on a canvas editor with a tool armed placed four clicks for four zoom attempts.+  Valid types: click | dblclick | rightclick | move | hover | wheel | type | key. - **Click-by-`text` that matches >1 visible element is refused (`ambiguous_target`, v0.1.0)** - two   "Next"/"Back" buttons, three "Yes" radios. Pass a unique `selector`, or `{debug:true}` to see the   numbered candidate overlay and pick one, or `acceptAmbiguous:true` to take the top-scored match. Verify@@ -334,7 +345,7 @@ Three ways to "see", and the choice matters:   other work, is imprecise, and usually implies foregrounding. There is always a targeted option above.   (`nbrowser_screenshot_full_res` is full-**PAGE**, not full-monitor - it still only sees the page.) ```bash-adom-bridge -t AdomLapper nbrowser_screenshot '{"sessionId":"s1","toFile":true}'   # PAGE bitmap → laptop PNG path+adom-bridge -t AdomLapper nbrowser_screenshot '{"sessionId":"s1","toFile":true}'   # PAGE bitmap → laptop PNG path (fixed dir %LOCALAPPDATA%\Temp\adom-nbrowser-shots); toFile:"C:/abs/path.png" writes THERE (bridge 0.16.2, nb-bridge#41) adom-bridge -t AdomLapper desktop_screenshot_window '{"hwnd":<from open_window>}'   # WINDOW + chrome + child popups # then: adom-bridge -t AdomLapper pull_file '{"filePaths":["<path>"],"saveTo":"/tmp"}' ```

@@ -215,6 +215,31 @@ They are independent. Repeat the flow per browser (matching scheme: `chrome://` sits top-right on Chrome, bottom-left on Edge). The host is registered per browser, so each connects its own host. Load into whichever the user wants, or both. +## Updating the extension (the load-unpacked folder is what runs, not the page)++Load unpacked reads the FOLDER on the laptop. Updating means refreshing that folder from the page's+`extension/` and reloading; nothing else moves it. The readiness readout has two different stale signals,+and it is easy to read the wrong one (nb-bridge#41 side note, Drew, 2026-09-03):++- **`staleProfiles` + `extensionStale:true`**: a CONNECTED profile is running an extension older than+  `expectedExtensionVersion`. This is the one that fires when the folder is old: the old build still connects+  and reports its version over the socket. (Drew's 0.1.3 folder vs expected 0.2.8 showed up HERE.)+- **`staleOnDisk`**: the folder's manifest on disk is older than expected. Until bridge 0.16.2 it was only+  computed for profiles that were NOT connected, so a stale-but-connected folder read `staleOnDisk:[]`.+  From 0.16.2 it covers connected profiles too.+- `nbrowser_dev_reload` reloads WHATEVER IS IN THE FOLDER. Reloading without refreshing the folder just+  reloads the old build, and readiness looks identical afterwards.++The update recipe, in order:+1. Read `nbrowser_readiness`: note `extensionVersions` per profile and `expectedExtensionVersion`.+2. Refresh the folder (the path Chrome loaded is in the profile's Secure Preferences `extensions.settings.<id>.path`;+   on John's laptop `C:\Users\john\adom-browser-extension\extension`): write the page's current `extension/`+   files over it with `desktop_write_file` (keep a `.bak-<old>` copy beside each file). `wsl_exec` cannot+   reach Windows loopback but CAN write `/mnt/c/...`; a ~75 KB `desktop_write_file` content is fine.+3. `nbrowser_dev_reload {profile}` PER PROFILE: a bare dev_reload only reloads the active profile, the second+   profile keeps the old build until you reload it by name.+4. Wait ~20s, re-read readiness: every profile in `extensionVersions` must show the new version.+ ## Recovery / common failures - **Load unpacked missing** -> Developer mode is off (Step A) or the page didn't navigate (re-`desktop_navigate`, verify by screenshot). - **Picker selected the wrong folder** -> the silent killer; always screenshot the picker path before Select.