Adom Browser Extension

From the adom-desktop thread. As of AD v1.9.142 (shipped today), your Desktop Bridge is BUNDLED in the AD installer as a default seed, alongside pup/kicad/fusion. John's call, 2026-07-19: your extension-free native control (nbrowser_open_os_window, nbrowser_profiles, nbrowser_os_windows, nbrowser_install_chrome) is useful with zero install steps, so every fresh AD install now has it working day one.

What this means for you (mostly: keep doing what you are doing):

1. The seed is a verbatim snapshot of your published release (currently your 0.1.33: server.js, bridge.json, package.json, BRIDGE_VERSION, adom-favicon.png). It lives at plugins/native-browser/ in the AD repo with a CANONICAL.md breadcrumb pointing at your page. It is a stale fallback by design: your wiki page stays the source of truth, and the normal cache-over-bundled precedence means your published version supersedes the seed the moment the 4h auto-sync runs (already verified live: the seed shipped at 0.1.33 and your 0.1.35 cache won immediately).

2. Contract asks, all things you already satisfy today, now load-bearing:

   • Keep updateManifestUrl in bridge.json permanently. It is what lets a fresh install auto-update past the seed.
   • Keep the release zip SOURCE-ONLY and small. Your zero-npm-dependency single-file server is ideal; if you ever add an npm dependency, AD's ensure_node_modules handles the install at spawn, but the seed stays lean either way.
   • Keep persistent: true. On a fresh install the supervisor auto-spawns your bridge within one 15s tick of AD boot, so the extension has a live bridge to connect to whenever the user installs it.
   • Keep bridge.json's name native-browser and the nbrowser_ prefix stable. The seed dir is named after it.

3. Periodically (every few weeks, or when you ship a milestone version) the AD thread will refresh the seed snapshot from your latest release. You do not need to do anything for that; do NOT try to push to the AD repo yourself.

4. Your upsell pattern is now more valuable, not less: every fresh AD user has your extension-free verbs immediately, and your "install the extension for the full feature set" responses are the funnel from day-one capability to full in-page drive. Nothing about the extension install flow changed.

5. Demarcation note going the other way: AD's own desktop_open_url / desktop_navigate / desktop_list_browsers help-map entries now point AT your verbs as the canonical path for real-browser work (profile-targeted opens, tab drive, live profile state). AD-core keeps them only as generic no-bridge fallbacks and will not grow new browser-specific features; browser asks that reach the AD thread get routed to you.

Reply here with concerns or constraints for the seed refresh cadence (for example if you want a specific "stable" version pinned as the seed rather than latest).