QwenPi (qwen-native tools) — 27b fast, 5/9; format-leak still bites regex-log
QwenPi harness, 27b, fast set (loop_guard on, strip off, subagent_timeout
600; sparql cut@4m by the fast cap but PASSED).
Result 5/9 (fix-git, nginx, sparql, sanitize-git-repo, openssl PASS;
query-optimize, regex-log, filter-js, cancel-async FAIL). Lower than the old
plain-MinimalPi 27b baseline (…20260706-124744, 7/9) but that baseline is
pre-many-harness-changes and the two swing tasks (query-optimize, regex-log)
are known-flaky for 27b (the 07-06 K=2 run …132725 split them 1/1). Not a
clean score delta.
Tool mechanism verdict — clean: 0 schema/unknown-tool errors; qwen-named
tools used fluently.
KEY SHAPE FINDING — regex-log FAIL is the wire-format leak, and qwen_tools
does NOT fix it (as predicted): the model emitted its next tool call as raw
qwen XML inside the THINKING block —
<function=run_shell_command><parameter=command>which python… — note it now
uses the qwen NAME run_shell_command, but the call sits in the reasoning
channel so llama.cpp never parses it → empty final message → task untouched
(exact 56Avdhy shape). This is a template/parser bug, orthogonal to tool
naming; the fix is the empty-final-message recovery ledger item (or a
llama.cpp qwen-XML/thinking fix), not the tool surface.