post-W7 cleanup

docs/wasm-runtime-architecture.md

@@ -5,9 +5,7 @@ describes the **runtime architecture as built** — the process topology, the
 wasm membrane, the unified request dispatch, and the central WebSocket broker.
 Native `.so` unit execution/dlopen fallback has been removed; the parser and
 preprocessor remain only as the front-end that emits C++ for wasm side-module
-compilation. For the historical motivation and the phased migration plan, see
-[`WASM-PROPOSAL.md`](../WASM-PROPOSAL.md); this file is the steady-state
-reference that proposal points at.
+compilation.
 
 The guiding principle: **request code never shares an address space or an
 allocator with the runtime.** Every unit runs as a WebAssembly module inside a
@@ -55,9 +53,9 @@ gets invoked*.
 | **serve_http dispatcher** (×bind) | one custom-server bind address | no — forwards to the pool | `custom_server_http_dispatcher_loop()` |
 | **Proactive compiler** | nothing; pre-compiles units | no | `run_proactive_compiler()` |
 
-The key invariant: **only workers instantiate Wasmtime and run unit code.**
+**only workers instantiate Wasmtime and run unit code.**
 Every connection-owning process (broker, serve_http dispatcher) forwards the
-real invocation back to a worker over `/run/uce.sock` using the minimal
+request invocation back to a worker over `/run/uce.sock` using the minimal
 FastCGI client in [`src/lib/fcgi_forward.h`](../src/lib/fcgi_forward.h). This is
 forced by Wasmtime: an `Engine`/`Store` cannot be safely re-created across
 `fork()`, and the brokers fork from the parent that already touched the
@@ -163,7 +161,7 @@ otherwise (page)         → serve_via_wasm(entry_unit, "render")
 
 The `UCE_*` params are set by whichever broker forwarded the request:
 
-- **Page render**: nginx → `/run/uce.sock` directly; no `UCE_*` flags → `render`.
+- **Page render**: FastCGI nginx → `/run/uce.sock` directly; no `UCE_*` flags → `render`.
 - **CLI**: the CLI socket sets `is_cli`.
 - **serve_http**: the custom-server dispatcher sets `UCE_SERVE_HTTP=1` plus
   `UCE_SERVE_HTTP_FUNCTION` and rewrites `SCRIPT_FILENAME` to the configured
@@ -181,21 +179,12 @@ code.
 
 ## 6. The central WebSocket broker
 
-The broker is the architectural centerpiece. **One process owns the HTTP port
+**One process owns the HTTP port
 and every WebSocket connection**, so any unit's `ws_*` call can reach any or all
 connections, and a unit-code crash (which happens in a worker) never drops live
 connections.
 
-### 6.1 Why central, and why it forwards
-
-Earlier designs gave each worker its connections and captured `ws_*` output to
-return inline. That was wrong: connections couldn't outlive a worker, and one
-unit could only talk to connections it happened to own. The broker fixes both —
-it is the sole connection registry and data broker between connected clients and
-the units that handle them. It renders nothing itself; like every other
-connection owner it forwards unit invocation to the worker pool.
-
-### 6.2 Inbound: a WS frame → a worker render (non-blocking)
+### 6.1 Inbound: a WS frame → a worker render (non-blocking)
 
 `ws_broker_ws_message(request, message, opcode)` fires when a complete
 (reassembled) WS message arrives on a connection. It does **not** block the
@@ -216,7 +205,7 @@ writing each queued request, then drains and discards the reply (the unit's
 output comes back via the command socket, not this reply), closing the fd when
 the worker closes its end.
 
-### 6.3 Outbound: `ws_*` commands flushed back to the broker
+### 6.2 Outbound: `ws_*` commands flushed back to the broker
 
 Any unit code — not just WebSocket handlers — may call `ws_send` / `ws_send_to`
 / `ws_close`. In the workspace these **record dispatch commands** rather than
@@ -236,14 +225,14 @@ the full registry it owns: `broadcast` (by scope), `send_to` (by connection id),
 `close`. If the batch carries `connection_state`, it persists that onto the
 matching live connection's `websocket_state`.
 
-### 6.4 Un-upgraded HTTP on the WS port
+### 6.3 Un-upgraded HTTP on the WS port
 
 The WS port can also receive ordinary (non-Upgrade) HTTP requests.
 `ws_broker_complete()` routes by param: `UCE_WS_DISPATCH=1` → apply commands;
 otherwise → `forward_request_to_worker()` — the *same* shared facility the
 serve_http dispatcher uses, so there is no duplicated request-forwarding code.
 
-### 6.5 The broker loop
+### 6.4 The broker loop
 
 `run_ws_broker()` drops the worker listeners it inherited
 (`close_inherited_server_sockets`), installs permissive `on_request`/`on_data`
@@ -255,9 +244,7 @@ command socket, and loops `process(50)` + `drain_outbound()`. The design is
 broker's single epoll loop** — the broker never blocks on a worker.
 
 The parent respawns the broker if it dies (`ws_broker_alive` / `ensure_ws_broker`
-in `main()`). A broker restart loses live connections (acceptable: crashes
-happen in workers, so the broker stays up in practice), but no unit state is at
-risk because the broker holds none.
+in `main()`). 
 
 ---
 
@@ -309,11 +296,10 @@ header free-functions are `inline`. The wasm backend exposes only declarations
 
 - **Regression gate**: `scripts/run_cli_tests.sh --include-wasm-kill` runs the
   in-runtime CLI suite (`site/tests/cli_runner.uce`) plus the site test pages.
-  Current baseline: **87 passed, 0 failed**.
+
 - **WebSocket end-to-end**: a headless client performs a raw WS handshake to
   `:HTTP_PORT` with path `/site/tests/websockets.ws.uce` (self-resolving
   `SCRIPT_FILENAME`) and asserts the `hello-ack` frame — exercising the full
   broker → worker → broker → client chain across process boundaries.
 
-All builds, runs, and installs happen on the dev host (`k-uce` / uce-dev) over
-SSH; the local checkout is edit-only.
+