README's tool-parser counts are stale by two waves: says 36 families / 40 names, actual 38 / 42

[localai-bot]

What

README.md states the tool-parser registry size twice, and both numbers are wrong:

Line	Says	Actual
README.md:81	36 tool-parser families	38
README.md:219	36 tool-parser families (40 accepted names)	38 families, 42 names

Re-derived from source, not incremented: src/vllm/entrypoints/openai/tool_parsers/abstract.cpp tool_parser_names() holds 42 entries, and get_tool_parser has 42 name == branches over 38 distinct std::make_unique<T> classes. tests/.../test_detect.cpp already pins names.size() == 42.

The drift predates #608: at 43a6c5518 the true values were already 37/41 while README said 36/40, so it missed muse_glimmer (#MODEL-MUSE-GLIMMER-W7, 40 -> 41) before #608 W1 took it to 42.

Why nothing caught it

scripts/check-readme-structure.py and scripts/check-public-doc-tables.py both pass: neither cross-checks a prose count in README against the registry. docs/STATUS.md and docs/USAGE.md carry the same numbers and were kept current by the rows that moved them; README was not, because "a registry grew by one" does not read like "a user-visible headline changed" under the AGENTS.md §Public documents trigger table.

#649 covers stale counts in the TOOLS-CALLING-CORE engine-matrix row only — a different surface, and itself now stale (it says "actual 41").

Fix

Correct both README lines to 38 families / 42 accepted names. Fixed in flow in the #608 W1 review-repair change (PR #683); this issue exists for traceability per AGENTS.md "every change starts from an issue".

Kind: bug

[localai-bot]

Fix is written and verified but NOT landed in #683, and the reason is worth recording here before anyone picks this up.

scripts/check-doc-checkpoint.py --staged refuses any README edit in a change that does not also touch a landing source — .agents/mission.md, CMakeLists.txt, benchmarks/demo/{footprint_gb10,qwen36_27b_c1_c32,vulkan_27b_llamacpp}.json, examples/cli/main.cpp, examples/server/main.cpp:

ERROR: staged change: changed README.md without touching a landing source (...).
The README is the landing page; routine checkpoints belong in the purpose-specific
docs. Co-edited public projections never justify README churn.

The checker's own comment calls that rule deliberate and directly tested, and weakening a checker to make a transition pass is forbidden, so #683 reverted its README edit and filed this instead.

The same rule refuses a README-only fix. A PR that changes nothing but these two numbers touches no landing source either, so it fails the identical gate. Closing this needs one of:

1. a change that legitimately moves a landing source and corrects the counts alongside it;
2. an argued exception in its own commit message (AGENTS.md §"Changing the rules or a checker" — no waiver registry, the argument lives in the diff it excuses); or
3. deciding the registry size does not belong in README at all and removing both mentions, which is itself a landing-page change and may need (2) anyway.

Worth weighing (3) seriously: a count in the landing page is a number that goes stale every time the registry grows, on a surface no per-row change is allowed to touch. That is the shape AGENTS.md §Records warns about, and it is why this drifted through two waves unnoticed.

Verified values at 4b319ba7c, re-derived not incremented: tool_parser_names() = 42 entries; get_tool_parser = 42 name == branches over 38 distinct std::make_unique<T> classes. tests/vllm/entrypoints/openai/tool_parsers/test_detect.cpp:222 already pins the 42.