diff --git a/serverAppConfigs-docs/LLM/frank-primary-glm53-flash-w4a16.md b/serverAppConfigs-docs/LLM/frank-primary-glm53-flash-w4a16.md
index 4ef41d7..f6e3b68 100644
--- a/serverAppConfigs-docs/LLM/frank-primary-glm53-flash-w4a16.md
+++ b/serverAppConfigs-docs/LLM/frank-primary-glm53-flash-w4a16.md
@@ -216,6 +216,21 @@ KV cap above, and the profile-run activation peak (`TritonMLA` indexer scores:
 64 heads x 2,048 topk x NBATCH tokens x 2 B = 2.06 GiB at NBATCH 8192), which is
 what killed the first two boots at util 0.95.
 
+`PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True` is part of the qualified
+shape, not a tuning: the plan fills VRAM to its modelled headroom by design, so
+the default allocator's fragmentation fails the profile/graph-capture phase
+(measured on the deployed unit: "Tried to allocate 662.00 MiB. GPU 0 … 240.00
+MiB is free").
+
+The `deploy.sh` e2e gate also drives the admin panel's open-links spec, which
+walks every guarded vhost — including `http://192.168.0.112:8989/` on
+FrankBook-Pro. When that Mac mini is asleep the spec fails on a `page.goto`
+timeout and the deploy reports `DEPLOY INCOMPLETE` even though the engine is
+healthy; wake the host (magic packet to `de:6b:6d:c1:52:23`) or re-run
+`tests/e2e/run.sh` once it is up. Seen 2026-09-30: 32 passed, this one failed,
+and the WoL packet did not wake it (macOS "Wake for network access" needs
+toggling on the mini itself).
+
 ## Rollback targets
 
 | state | where |