FORK.md: upstream 0.11 made BU_CDP_WS reach the daemon

Upstream 0.11.0 moved BU_CDP_WS into discoverEndpoint(), so the claim
that the daemon ignores it is no longer true. Say why BU_CDP_HTTP is
still needed, where BU_CDP_WS sits in the precedence, and what to
expect and run when taking upstream releases now that upstream has a
boundary scanner and a daemon import-graph test.

1 files changed, 34 insertions, 10 deletions

diff --git a/FORK.md b/FORK.md
index 3858cd6..639e76c 100644
--- a/FORK.md
+++ b/FORK.md
@@ -20,12 +20,18 @@ Upstream can only reach a browser on localhost:
   `createDaemonTransport`)
 - the daemon resolves Chrome with `discoverWsUrl()` (`src/daemon/bridge.ts`)
 - that probe is hardcoded to `127.0.0.1` (`src/cdp/discovery.ts`)
-- `BU_CDP_WS`, the documented remote escape hatch, is read only by the
-  in-process client (`src/client.ts`) — which that path never touches, so it has
-  no effect on the extension
+- `BU_CDP_WS`, upstream's remote escape hatch, pins a full WebSocket URL
 
-Without the patch the only option is relaying the remote browser onto localhost
-(ssh tunnel or socat), which means a local service on every client machine.
+Before upstream 0.11.0, `BU_CDP_WS` was read only by the in-process client and
+so did nothing for the extension. 0.11.0 (`6d30009`) moved it into
+`discoverEndpoint()`, so the daemon now honours it too. It still does not cover
+this fork's use: the URL embeds the browser UUID, which Chrome re-mints on every
+launch, and it is read once when the daemon starts. There is also no default,
+no fallback and no way to switch from inside pi.
+
+Without the patch the options are pinning `BU_CDP_WS` and re-setting it after
+every remote restart, or relaying the remote browser onto localhost (ssh tunnel
+or socat), which means a local service on every client machine.
 
 `BU_CDP_HTTP="host:port"` is resolved inside `discoverEndpoint()`, so daemon and
 client both honour it. It names an **HTTP** endpoint, not a WebSocket URL,
@@ -78,6 +84,11 @@ Precedence is `BU_CDP_HTTP` > `/browser-target` > built-in default, so a one-off
 `BU_CDP_HTTP=… pi` is never silently overridden by a choice made days ago. When
 the variable is set, `/browser-target` says so instead of pretending to obey.
 
+Upstream's `BU_CDP_WS` sits above all of these: `discoverEndpoint()` returns it
+before consulting the fork's target, so an explicit WebSocket URL still wins.
+`/browser-status`, `/browser-target` and the system prompt do not know about it,
+and describe the `BU_CDP_HTTP`/stored/default target even when it is set.
+
 The asymmetry is deliberate. An explicit endpoint is an instruction, so failing
 to reach it must not quietly automate a different browser — that would drive
 your own signed-in Chrome instead of the shared one. The default is only a
@@ -93,8 +104,8 @@ previous approach (patching `node_modules` in place) suffered from.
 
 ## Taking upstream releases
 
-The patch is a single commit on top of an upstream tag, so rebasing keeps it
-that way:
+The patch is a short series of fork commits on top of an upstream commit, so
+rebasing keeps it that way:
 
 ```
 git fetch upstream
@@ -102,9 +113,22 @@ git rebase upstream/main          # or: upstream/main --onto a specific tag
 git push --force-with-lease origin master
 ```
 
-Conflicts to expect are confined to `src/cdp/discovery.ts` (the
-`discoverEndpoint()` short-circuit and the `host` parameter on
-`queryLiveWsUrl`) and `src/setup.ts` (the skipped local-process precondition).
+Conflicts to expect are mostly in `src/cdp/discovery.ts` (the
+`discoverEndpoint()` short-circuit, placed after upstream's `BU_CDP_WS` check,
+and the `host` parameter on `queryLiveWsUrl`) and `src/setup.ts` (the skipped
+local-process precondition). Upstream refactors also touch the fork's hunks in
+`src/index.ts` (imports, `/browser-status`, `before_agent_start`),
+`src/prompt.ts`, `src/daemon/spawn.ts` (`stopDaemon`), `src/profile/*` and
+`CHANGELOG.md`.
+
+Verify with `npm run check` (typecheck, the boundary scanner and the tests).
+The boundary scanner rejects unguarded casts, so parse JSON with
+`src/util/guards.ts`. `test/daemon/entry-imports-test.ts` walks the daemon's
+import graph, which includes `endpoint.ts` and `target-store.ts`, and fails if
+it reaches a non-runtime dependency such as `typebox`. The fork's own tests
+(`test/cdp/endpoint-test.ts`, `test/cdp/target-store-test.ts`) use a
+hand-rolled `check()` rather than `node:test`; the test glob still runs them and
+a failure exits non-zero.
 
 The setup precondition skips `isBrowserRunning()` whenever the resolved target
 is remote — by env var, `/browser-target` choice, or the built-in default — not