docs(memory): record the gap tts-dev found in my served-page gate

They adopted the gate as tts-stack tools/gate_served_page.py and extended it in a
place that matters: my version would have passed a broken page.

A worklet lives inside a template literal, so a syntax error in it is invisible to
a parse of the enclosing script - it is just a string until addModule compiles it
at runtime, where it fails as a rejected promise and the page quietly falls back to
buffered playback or records nothing. Silent degradation, which is harder to notice
than a dead page rather than easier. They parse the worklet separately, and they
positive-controlled the whole thing against two deliberately broken pages rather
than assuming a gate that has only ever passed is not blind. The second control -
valid enclosing script, broken worklet - is the one my version fails.

The lesson on my own work is the useful part: I built a gate for the failure I had
just been shown and stopped at its boundary. The class is 'code that is a string at
parse time and code at run time'; an inline script is one instance and a
template-literal worklet is another. I checked the instance, not the class.

Also promotes the underlying rule to the index, since it was named twice tonight
from two unrelated directions: a check that reads an artifact as stored cannot see
a transformation that happens between storage and execution.

persistent-memory.d/2026-09-15-talk-v10-deploy.md

@@ -72,6 +72,33 @@ configured intent, not the running reality. Both check the INPUT to a transforma
 and get reported as if they checked its OUTPUT. See
 `2026-09-15-parakeet-stt-fv-ml1.md` for the ASR instance of the same shape.
 
+## ⚠ My fifth gate had a GAP — tts-dev found it and fixed it
+
+Adopted into tts-stack as **`tools/gate_served_page.py`** (`uv run tools/gate_served_page.py <url>`;
+needs only curl-equivalent and node). But **my version would have passed a broken page**:
+
+**A worklet lives inside a template literal**, so a syntax error in it is invisible to a
+parse of the *enclosing* script — it is just a string until `addModule` compiles it at
+runtime, where it fails as a **rejected promise**. The page then quietly falls back to
+buffered playback, or records nothing at all on the capture side. **Silent degradation,
+which is harder to notice than a dead page, not easier.** Their version parses the
+worklet separately.
+
+They **positive-controlled it** rather than assuming it worked — a gate that has only
+ever passed cannot tell you it is not blind. Two deliberately broken pages, both exit 1:
+
+    the exact escape bug            -> block 0 SYNTAX ERROR
+    broken worklet, valid script    -> block 0 OK, worklet SYNTAX ERROR   <- mine passes this
+
+⚠ **Empty block list exits 2, not 0.** A page that suddenly has no inline script is a
+different page or a broken build; passing there would make the gate a no-op exactly
+when it matters most.
+
+⭐ Lesson on my own work: I built a gate for the failure I had just been shown and
+stopped at its boundary. The failure class is "code that is a string at parse time and
+code at run time" — an inline `<script>` is one instance of it, a template-literal
+worklet is another, and I checked the instance rather than the class.
+
 ## Host compose verified, not assumed
 
 tts-dev claimed the host copy was byte-identical to the repo, "unlike voice-studio".

persistent-memory.md

@@ -177,6 +177,10 @@ hardened for ha-dev (`d1769ed` ff); `kb` KB-search tool (`68fa80f`).
 
 - `[2026-09-15]` **Parakeet STT live on fv-ml1 GPU 0, behind LiteLLM `ext-stt` / `whisper-1`.** ⚠ **Placed on GPU 3 first, which was wrong — operator caught it.** A ~800 MiB seat should ride the card with the most uncommitted headroom (GPU 0, util 0.88, ~13 GB spare), not put the first fingerprint on the one pristine 96 GB card: vLLM sizes KV cache against TOTAL VRAM, so any tenant on an empty card eats a future full-size seat's profiling margin (flash-next needs 93 of 96 GiB). **GPU 3 is now a deliberate reserve at 2 MiB.** Retargeted the existing `stacks/parakeet/` (sherpa-onnx + our own FastAPI wrapper) from irv-ml1; v3 int8, 25 languages. ⚠ **ORT's CUDA EP compiles kernels lazily and the first decode on sm_120 took 45.7 s** — every later call ~0.5 s; a startup warmup in `app.py` now absorbs it, so the first real request is 0.65 s instead of a 45 s hang that no client would wait through. GPU use was **verified by a process on GPU 3 (922 MiB), not by the `provider=cuda` log line**, because ORT falls back to CPU silently and still returns correct text. Silence → `""` (null control), known sentence → near-exact (positive control). → `persistent-memory.d/2026-09-15-parakeet-stt-fv-ml1.md`
 
+- `[2026-09-15]` ⭐⭐ **A check that reads an artifact AS STORED cannot see a transformation between storage and execution** — named twice in one night and it generalises. `node --check` on a source file passes while the SERVED page's inline script is dead (a JS `'didn\'t'` inside a Python string arrives as `'didn't'` and closes it); `provider=cuda` in a log echoes configured intent while ORT silently ran on CPU. Both check the INPUT to a transformation and get reported as checks of its OUTPUT. Remedy: gate the wire, not the file — `tts-stack tools/gate_served_page.py`. ⚠ My first version had a gap tts-dev closed: **a worklet inside a template literal is just a string to a parse of the enclosing script**, so its syntax error surfaces as a rejected `addModule` promise and *silent degradation*. I checked the instance, not the class. → `persistent-memory.d/2026-09-15-talk-v10-deploy.md`
+
+- `[2026-09-15]` **talk v10 LIVE on nh3-dev :8092 — the fleet speaks and listens on one page.** First consumer of the `ext-stt` Parakeet seat: `POST /api/listen`, push-to-talk, barge-in. Gated build→throwaway→teardown→cutover, then **re-gated against production** (a gate that only ran against the throwaway proves the image, not the deployment). ⚠ Deploys route through infra-ops only because tts-dev's identity is not in nh3-dev's `docker` group — a permissions accident, not a judgement call; group-vs-relay is in front of the operator.
+
 - `[2026-09-15]` ⭐⭐ **Two restart patterns from svos-dev worth stealing: (a) DRY-RUN BOOT against the still-held port** — start the new process while the old one holds the socket; it proves every check above the bind and dies on `[Errno 98]`, so a one-way restart becomes a rehearsed one at zero cost. **(b) ⚠ SIGTERM freed the port but left the process alive for 35 s** — a script waiting on the port would have run two copies. **Kill by PID, wait on the PID, never on the port.** A freed port is not evidence of a dead process.
 
 - `[2026-09-15]` ⭐ **`svos_miranda` ENABLED and LIVE in Hermes — but `agent.disabled_toolsets` is permanently OFF by operator ruling ("i dont want the tools disabled everywhere").** That key is a **global** end-of-pipeline subtraction, not api_server-scoped: measured 46 tools → 20 on a default session. It is also **unnecessary** — `platform_toolsets.api_server: [svos_miranda]` alone resolves an api_server session to exactly the 8 tools, write-klass absent. Gateway restarted 02:10 (PID 3107822→3901622, observed); `/v1/toolsets` now 29 rows incl. `svos_miranda`; operator's own surface verified intact at 46. ⚠ **SVOS must stop verifying against the GLOBAL roster before it restarts** — it will see 29 and refuse, by design now. → `persistent-memory.d/2026-09-15-svos-miranda-plugin-validation.md`