Three pages described the fleet; two of them still described the pre-September arrangement.
Re-read live on 2026-10-21 (`/v1/models`, `systemctl`, `lspci`, `nproc`, `resolvectl`):
- `system/network.md` called Dankclaw the "large inference model" box and Dankserver the
"small" one — that is the topology from before the RTX 3090 moved in September. The served
ids today are `frank-archon` on Dankserver:7770 (the main model) and `frank-dragoon`
(:7770) + `frank-zealot` (:7771) on Dankclaw. The gateway and the DNS pin were re-read too.
- `system/dankserver.md` claimed `frank-medium` is *masked*: the unit file does not exist
(`is-enabled` answers `not-found`), which is a different fact with a different remedy. And it
claimed 8C/16T: this 7700X exposes **8 threads** (`nproc` = 8), so anything sized for 16 is
sized for a machine that is not this one.
- `system/dankclaw.md` transcribed the engine's slot/KV/context math — `2×262,144 slots over
one 524,288 pool, unquantized f16 K+V, MTP off` — while the live unit says `3x200704 slots
over one 602112 pool, f16 K + q8_0 V, MTP armed`, and dragoon's ctx had moved too. That math
belongs to the serverAppConfigs runbook the page already names: the unit's `ExecStart` is a
wrapper script, so any copy here rots on the next engine change. The page now keeps the
contract — id, unit, port, engine family, which GPU, and how to prove it — and disowns the
numbers, with the reason stated so the next agent does not re-transcribe them.
Also recorded, because it is how this audit nearly missed a stopped service: `curl :7770/v1/models`
answered normally while `frank-dragoon.service` sat `inactive` with `Result=exit-code` — the
container is running outside systemd. A serving port is not a healthy unit. (Flagged for Frank
separately; no production unit was touched.)
Refs #64
Frank
54bb0202c2