docs(frank-zealot): PTQ1_0 was ordered, measured and approved — not an unfinished arm

Frank's 02:36 instruction (archive 01a14c93) ordered the 27B PTQ1_0 arm at
2 x 200,704 with the Q8 mmproj and batch/ubatch 3072/1536; it served
production 03:14:39-03:38:57 (pid 191358, journal type ptq1_0: 402 tensors).
Recovered its numbers from that process's own print_timing lines: ~48 t/s
single-stream decode, 25-27 t/s per stream at two streams, prefill 1,295 t/s
at 30,637 -> 943 at 97,856 -> 801 at 141,365. It bought the promised 1,201 MiB
and lost 37% of decode against the PQ2_0 record, so the publisher's Ampere
warning generalizes to GA102; Frank scratched the 27B plan at 03:33 for the 9B.

Every 'unfinished experiment' claim is re-keyed, and the AGENTS.md law gains
the durable lesson: a bench verdict that never reaches the repo is
indistinguishable from a rogue arm.

serverAppConfigs-docs/log.md

@@ -2157,9 +2157,10 @@ every restart since the cutover.
   revert the swap commit — the 27B payload and the build-10754 fork tree are
   both still on disk.
 - Deployed 13:16 PDT (`deploy.sh dankclaw --service frank-zealot`, e2e 33/33)
-  — and the first boot was **not the shipped payload**: a stale
+  — and the first boot was **not the shipped payload**: a leftover
   `frank-zealot.service.d/ptq1.conf` from the bench window (written 03:29 for
-  an unfinished 27B **PTQ1_0** experiment) pointed
+  the 27B **PTQ1_0** arm Frank ordered at 02:36 and measured from 03:14 — see
+  the record below) pointed
   `FRANK_ZEALOT_ENV_FILE` at `/tmp/zealot-arm-current.env`, so the unit booted
   that arm: 3 slots of 133,888, 21,188 MiB used, batch 3072/ubatch 1536.
   `/health` 200, `/v1/models` echoed the alias, Playwright 33/33 — nothing in
@@ -2190,6 +2191,35 @@ every restart since the cutover.
   200,704). Note the columns are `params`/`meta` JSON — the table has no
   `context_length`/`description` columns.
 
+## 2026-10-18 — frank-zealot PTQ1_0 arm: measured, approved, and never written down
+
+- **Correction to the entry above and to my own report.** The
+  `frank-zealot.service.d/ptq1.conf` drop-in was NOT a half-finished experiment.
+  The session archive (`01a14c93`) carries Frank's own instruction at **02:36**:
+  replace frank-zealot with `Ternary-Bonsai-2-27B-PTQ1_0.gguf`, use the **Q8**
+  mmproj, batch/ubatch **3072/1536**, "fit as much context as possible in 2
+  contexts".
+- It was the production payload **03:14:39 → 03:38:57** (pid 191358; journal
+  `type ptq1_0: 402 tensors`, `file type = PTQ1_0 — 1.75 bpw ternary`, mmproj
+  loaded, 2 × 200,704) and served real traffic. Recovered from that process's
+  own `print_timing` lines (17 timed tasks): single-stream greedy decode
+  **48.0 and 47.6 t/s at 512 tokens, 47.9 at 229, 49.0 at 451**; 25–27 t/s per
+  stream with two streams live; prefill **1,295 t/s @ 30,637 → 943 @ 97,856 →
+  801 t/s @ 141,365** (one 176 t/s row at 97,024 is a concurrent-slot request,
+  not a clean probe).
+- Against the PQ2_0 27B record (76.6 t/s decode, 691.7 t/s prefill at 166k):
+  PTQ1_0 freed the **1,201 MiB** its fetch script promised and paid **−37 %
+  decode** — the publisher's "dense ternary unpacking loses on Ampere" warning,
+  now confirmed on GA102 — while prefilling deep prompts faster than that
+  record ever managed. Frank scratched the whole 27B plan at **03:33** ("scratch
+  the current frank-zealot plan completely… 9B… enable mtp… if you can possibly
+  fit a third context, do it"), which is what shipped at 13:16.
+- The durable failure is mine: those numbers lived only in `/tmp` and the
+  journal, never in the repo, so the next agent on the host could not tell an
+  approved payload from a rogue drop-in and called it a hijack. The runbook
+  deploy ledger now carries the measurement; `/home/dank/models/Bonsai2-PTQ1_0/`
+  stays on disk as the 27B rollback and the drop-in stays trashed.
+
 
 ## 2026-10-18 — frank-dragoon: the 401,408-position pool goes live; docs re-keyed to the measured boot