NB - Native Browser Bridge

@@ -75,6 +75,23 @@ wrong-variant model before it ever reaches the PCB. A development environment has to operate the browser the way a developer does. Each permission maps to a concrete action you ask for — to deliver the features above, never to collect data. +### A real example — debugging an authenticated Mouser / DigiKey app++You're building an app that pulls live pricing and stock from the **Mouser** and **DigiKey** APIs — calls+that only succeed from your **signed-in** session. A response comes back empty, so you ask your Adom+assistant to debug it, and it does exactly what you'd do in DevTools, in your own logged-in tab:++- **`eval`s** `await fetch('/api/digikey/search?mpn=ADS1262IPWR').then(r => r.json())` right in your app's+  page context and reads back the **real authenticated** response;+- inspects the **console + network** for the failing call — the `401`, the malformed auth header;+- patches the code, re-runs the call, and confirms the parts resolve — without you leaving your seat.++That's the whole reason for `debugger`, `cookies`, and `<all_urls>`: a developer debugging their own web app+against authenticated third-party APIs needs **full DevTools-grade access in their real session**. Take it+away and this is just a worse screenshot tool. The table below maps every capability to a concrete request.++<img src="/blob/app/adom-browser-extension/screenshots/dev-debug-mouser-digikey.png" alt="The Adom AI assistant debugging an authenticated DigiKey API call inside the developer's own signed-in browser — eval in the page context, reading back the real authed JSON response" width="100%">+ | Permission | What the user-requested feature needs it for | |---|---| | `debugger` | Drive, inspect, screenshot, and **debug the live page** via the DevTools protocol — exactly what building and testing a web app requires. Attached only while a command runs, detached when idle. |

@@ -12,6 +12,29 @@ justification into the matching field. Lead context (use in the single-purpose / > browser extension. Every permission below exists to deliver that user-directed automation, > not to collect data. +## Worked example — why a developer needs full DevTools-grade access++A concrete, representative task (use this verbatim if a reviewer asks "why so much power?"):++> An Adom developer is building a web app that pulls live pricing and availability from the+> **Mouser** and **DigiKey** APIs — calls that only succeed from their **signed-in** browser+> session. A request comes back empty, so they ask their Adom AI assistant to debug it. The+> assistant does exactly what the developer would do in DevTools, in the developer's own+> logged-in tab:+>+> 1. **`eval`** `await fetch('/api/digikey/search?mpn=ADS1262IPWR').then(r => r.json())` directly+>    in the app's page context, and reads back the **real authenticated** response.+> 2. Inspects the **console and network** for the failing call — the `401`, the malformed auth+>    header, the rate-limit body.+> 3. Patches the code, re-runs the call, and confirms the parts now resolve — all without the+>    developer leaving their seat.+>+> This is the single purpose: an AI pair-developer operating the user's own DevTools on the+> user's own session. `debugger` (run / inspect / console / network), and `cookies` + `<all_urls>`+> (act in the real signed-in session, on whatever app is being built) are not optional extras —+> remove them and the only thing left is a worse screenshot tool. The Extension never harvests+> these APIs or sessions; it performs the developer's debugging task, on the developer's command.+ | Permission | Justification (paste into store) | |---|---| | **nativeMessaging** | Connects the Extension to the user's local Adom Desktop application over Chrome's native-messaging channel, so the user's AI session can send commands and receive results. This is the core transport; without it the Extension cannot function. |