fix(glm): vendor a minja-compatible chat template — tool calling works, and the #1254 mechanism was wrong

[noonghunna]

Fixes the tool path on all 18 GLM composes, and corrects a mechanism I got wrong in
#1254.

From #1250 (@paulp83), and reported
independently upstream on ggml-org/llama.cpp#27754
on 2026-09-07 where it got no reply.

The line in the error is the crash site, not the cause

Two earlier readings were wrong. Both are recorded in the patch README so nobody re-derives them:

• ❌ "minja cannot evaluate .items()" — GLM-4.7-Flash.jinja carries the identical
  construct, is exercised by llama.cpp's own autoparser tests, and passes.
• ❌ "the caps probe under-detects supports_object_arguments because the template iterates
  rather than indexing" — adding a named access changes nothing; the probe never gets that far.

Actual cause: minja does not implement numeric dotted attribute access (x.0). Jinja2 defines
x.0 as x[0]; minja parses it as a non-computed member whose property is a number literal, and
throws. The embedded template uses it in 4 places, so the caps probe throws, infers nothing, and
leaves every capability false — including supports_object_arguments, which gates the JSON-string →
object conversion of tool arguments in chat.cpp. Arguments stay a string, and then the
autoparser dies on .items() at line 163.

The tell that the earlier readings were wrong: supports_string_content is also false, which no
tools-only explanation accounts for.

The patch — 5 lines, wire format untouched

-{% for tool in tools %}
+{% for tool in tools if tool %}          # caps probe passes tools=[null]; 'function' in tool trips
-...m.content.0.type...        +...m.content[0].type...
-...tr.output.0.type...        +...tr.output[0].type...
-...m.content.0.output...      +...m.content[0].output...
-...entry.output.0.type...     +...entry.output[0].type...

Tool calls still render <tool_call>NAME<arg_key>K</arg_key><arg_value>V</arg_value>…. That is
load-bearing: change the format and the generated parser stops matching what the model emits.

Verified without loading 140 GiB, with llama.cpp's own tooling

llama-template-analysis --template-file <t>:

capability	GGUF-embedded	override
supports_tools	false	true
supports_tool_calls	false	true
supports_parallel_tool_calls	false	true
supports_string_content	false	true

llama-debug-template-parser (the real autoparser path) on the override yields
tool_mode: TAG_WITH_TAGGED, per_call_start '<tool_call>', and a full PEG parser + GBNF carrying
the <arg_key>/<arg_value> rules.

Reference Jinja2 3.1.2: original ≡ override byte-identical across 8 cases, including the
two-call sort path, reasoning_content, typed content, list-of-outputs tool content, and a
<think>-split message.

⚠️ Not verified

No live boot. GLM-5.3-Flash is ~140 GiB and this has not been served end-to-end. Everything
above is static analysis plus the engine's own autoparser.

The production pin is server-cuda-b10236; the analysis build came from a local checkout whose
minja may differ. The error text and byte offset match exactly, so the mechanism holds, but the two
builds are not proven identical.

Drift guard asserts positively

A re-vendored vendor template without the fix fails silently — boot green, /health green, tool
calls 400. So the guard requires the caps to read true rather than merely checking the .0.
string is absent, and pairs that with a tool-call smoke and a 3-turn loop.

Upstream

Not fixed upstream as of 2026-09-11. Right fix is in minja: implement x.0 as x[0], or have the
caps probe degrade gracefully rather than inferring nothing when a probe throws. Closest prior art
is #28509 (Gemma 4 misclassified
supports_typed_content), same subsystem, closed completed. An issue is drafted for the maintainer
to post — ggml-org bars autonomous agent contributions.