Two public documents state things the tree falsifies: the architecture count (43 vs 44) and the ROCm FP8 KV refusal

[localai-org-maint-bot]

Row: -

Two public documents state things the tree falsifies. Both were found while triaging #2374 and #2236, which each carry one of these corrections buried inside a much larger rewrite that main has since moved past. Filing them separately so the live half is not lost when those PRs close.

1. The registered-architecture count is 43 in the docs and 44 in the registry

scripts/check-supported-models.py on a clean main prints "exactly the 44 architectures" and exits 0. The prose says 43 in six places:

README.md:11    "43 registered architectures, CUDA / CPU / Metal / Vulkan"
README.md:110   "**Everything.** 43 registered architectures, 38 tool-parser families"
README.md:286   "The full architecture matrix (43 registered architectures grouped by family)"
README.md:333   "all 43 registered architectures with their tested checkpoint and gate"
docs/FEATURES.md:62    "| Architectures | 43 registered, 27 gated |"
docs/FEATURES.md:139   "Today that is **43 registered architectures**."

The checker validates the LIST and passes; nothing checks the number written in the sentence beside it. So this is a gate gap as much as a typo — a count in prose that no checker reads will drift again the next time an architecture is registered. Worth considering whether the count should be derived at read time rather than written down, which is the shape AGENTS.md §Records prescribes for exactly this.

2. docs/USAGE.md says ROCm refuses FP8 KV, and ROCm registers it

docs/USAGE.md:274:

Every one of the 16 refuses before writing, so the half-sized block is never fed floats; what differs is how much the message tells you. Metal and ROCm refuse it too.

But src/vt/rocm/rocm_ops.hip:206:

    RegisterOp(OpId::kReshapeAndCacheFp8, DeviceType::kROCM,

191f64608 landed the ROCm FP8 KV path and src/vt/ops.cpp:4899-4900 admits kROCM. The sentence is a leftover from before that. The Metal half of it has not been checked here and may well still be true — whoever fixes this should verify Metal separately rather than assume the two halves fail together.

Why these are worth an issue rather than a drive-by

Both are the same failure shape: a public surface asserting something the code contradicts, where the checker that could have caught it looks at a neighbouring artifact instead. docs/FEATURES.md and README.md are the two surfaces a reader trusts most, and a wrong capability claim there is more expensive than a wrong comment in a kernel.