NB - Native Browser Bridge

@@ -1,74 +0,0 @@-# PUBLISH skill (source-only, dev-skills/) — how to cut a native-browser bridge release--> Reader: **this bridge's own cloud/dev thread.** NOT shipped to user containers (it is not a-> `SKILL.md`, and it is not in `package.json` `files[]`). Keeps future-me from getting the publish-> dance wrong. Bridge SDK: https://wiki.adom.inc/adom/adom-desktop-bridges--## What "the bridge" actually is (3 artifacts, 3 places)-1. **Runtime** — `bridge/` (server.js + bridge.json) shipped as a `.bin` payload + a manifest on the-   wiki page. AD streams it to `bridges-cache/native-browser/` and spawns it.-2. **Skills pkg** — the `SKILL.md`s, published via `adom-wiki pkg publish --org adom`, installed into-   the container's `~/.claude/skills` + `~/.codex/skills`.-3. **Discovery** — `discovery_triggers` + `discovery_pitch` on `page.json`.--## bridge.json contracts we declare (and one we deliberately don't)-- **`timeouts`** (AD v1.9.79+): AD hard-caps every bridge verb at 60s unless you declare per-verb HTTP-  budgets. Ours match the bridge's own `timeoutFor()` (`screenshot|record|fetch_url|input_dispatch` →-  120s) plus `wait` (blocks up to its 120s cap): `verbs {wait:125, fetch_url:120, input_dispatch:120}`-  + `prefixes [{screenshot:120},{record:120}]`, `default:60`, and `statusVerb:"nbrowser_status"` (AD-  returns `{stillRunning:true,statusVerb}` on its own timeout → caller polls). Keep the describe-  `timeoutSeconds` in `server.js` aligned with these. Note: the adom-desktop **CLI has its own ~30s-  client timeout**, separate from AD's bridge budget — you can't observe a >30s verb via a bare CLI-  call, but a real relay caller respects the stillRunning+poll pattern.-- **`detect` — intentionally OMITTED.** `detect` is for a HOST APP AD detects/gates. Native-browser-  drives the user's REAL browser via the extension, so the authoritative "is it usable" signal is-  **extension-connected** (`nbrowser_readiness`), not a browser binary on disk — and our read-only-  verbs are always forwarded regardless. A single `hostApp:"Google Chrome"` would MISREPORT the common-  Edge-only machine (verified real: ADOMBASELINE runs fine on Edge with no Chrome), and Edge is-  universal on Windows so "browser installed" is near-zero signal. So we do NOT declare `detect`.--## Release the RUNTIME — the exact, proven sequence-Deps: none (core `http`/`net`), so the payload is source-only (no `node_modules`).--1. **Bump the version in THREE places, together** (they drift if you don't):-   - `bridge/bridge.json` `version` (what AD reads + reports),-   - `bridge/package.json` `version`,-   - `bridge/BRIDGE_VERSION`.-   `server.js` reads `VERSION` from `bridge.json` (authoritative) so it can't drift — keep it that way.-2. **Build the zip with files at the ROOT** (there is no `zip` binary — use Python `zipfile`):-   members = `bridge.json`, `package.json`, `server.js`, `BRIDGE_VERSION`. Name it-   `native-browser-bridge-v<ver>.bin` (⚠ `.bin`, NOT `.zip` — the wiki SILENTLY rejects `.zip`-   uploads: returns `ok:true, commit:null` and stores nothing).-3. **sha256 + byte size** → write `native-browser-bridge-manifest.json`-   `{manifest_version:1, version, url:"native-browser-bridge-v<ver>.bin", sha256, size, released_at}`.-4. **Upload the `.bin`** via the base64 files API (repo push drops binaries):-   `adom-wiki api -X POST /api/pages/adom/adom-browser-extension/files --body '{"files":[{"path":"...bin","content":"<b64>","encoding":"base64"}],...}'` (CLI `--body` cap ~128 KB; the ~28 KB zip is fine).-5. **Push manifest + source as TEXT** with `adom-wiki repo push adom-browser-extension --files native-browser-bridge-manifest.json bridge/bridge.json bridge/package.json bridge/server.js bridge/BRIDGE_VERSION ...`.-6. **Land it on a laptop:** `refresh_bridges {name:"native-browser"}` (self-reaps, AD 1.9.27+), then-   verify with `bridge_check_updates` → `current==latest==<ver>, updateAvailable:false`.--## ⚠ Two traps that WILL waste an hour (both hit live)-- **Orphaned bridge process blocks the new code.** `refresh_bridges`/`bridge_pause`/`resume` do NOT-  always reap a stuck persistent process — it keeps holding the port so your new code never runs-  (tell-tale: `host.json` `version` stays old while `bridge_list` shows the new cache version). Read-  the LIVE version from `~/.adom/bridges/native-browser/host.json`, not `bridge_list`. If stuck:-  `tasklist /FI "PID eq <pid>"` to confirm it's the bridge node.exe, then **targeted** `taskkill /PID-  <pid> /F` (one PID — never a broad `taskkill /IM node.exe`, that kills the user's other node). Then-  poke `nbrowser_status` to respawn fresh.-- **Version drift.** `VERSION` must read `bridge.json` (not `package.json`, which is easy to forget to-  bump). Confirm the live `host.json` version matches after every release.--## Publish the SKILLS pkg-`adom-wiki pkg publish --org adom`. Ship ONLY user `SKILL.md`s; keep `dev-skills/*.md` (this file, the-DEV skill) OUT of `package.json` `files[]` — the wiki indexes every `SKILL.md` in the tarball as an-installable user skill (Artifact 2 trap #1). `install.sh` must deploy to BOTH `~/.claude/skills` and-`~/.codex/skills`.--## Discovery-Edit `page.json` `discovery_triggers` (30+ user-task phrasings, login/forms niche — pup can't do-logins) + `discovery_pitch` (an INSTRUCTION). Push `page.json` **LAST** (a pkg publish clobbers it and-drops the hero). Verify: `adom-wiki discover preview --json "<7 real user queries>"` → land top-3.--## After ANY wiki change: show John in pup (standing rule)-Open the live page in a maximized pup window + shotlog + hand him the phone URL. Never just report-"published."