Skip to content

record(TOOLS-PARSER-BREADTH): backfill the 41 parsers already shipped, and correct three counts (#608) - #643

Merged
localai-bot merged 4 commits into
mainfrom
row/tool-parser-breadth-w0
Aug 13, 2026
Merged

record(TOOLS-PARSER-BREADTH): backfill the 41 parsers already shipped, and correct three counts (#608)#643
localai-bot merged 4 commits into
mainfrom
row/tool-parser-breadth-w0

Conversation

@localai-bot

@localai-bot localai-bot commented Aug 13, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Closes part of #608 (W0 only; W1/W2/W3 remain open).

This is a record repair, not an achievement

No parser was ported. No src/ or tests/ file changed. Every parser
named below was already on main before this PR — it landed incrementally
under other rows, and the TOOLS-PARSER-BREADTH row simply never recorded it.
Please read the diff as "the row caught up with the tree", never as "this PR
delivered forty-one parsers."

The row read:

Qwen-Coder XML, Mistral, pythonic, and remaining parsers · Our code: - ·
Our tests/evidence: - · INVENTORIED

All three families it names by title are implemented, alongside 34 more. Same
defect SAMPLE-REASONING carried before its own W0.

W0 of .agents/specs/tool-parser-breadth.md.

What is now recorded

  • 41 accepted parser names over 37 families. Aliases explain the gap:
    llama3_json/llama4_json, qwen3_coder/qwen3_xml/mimo, glm45/glm47.
  • Factory + tool_parser_names() anchors in tool_parsers/abstract.cpp.
  • The 27-row ordered autodetect table and its ORDER MATTERS collision
    analysis in tool_parsers/detect.cpp, which records the deliberately
    EXPLICIT-ONLY families.
  • 38 test files, including the registry test that pins the count, so a
    factory branch added without listing its name fails the suite instead of
    shipping an unreachable dialect.

State: INVENTORIED → PARTIAL, and not further

The matrix header defines ANCHOR-BACKFILL as "code and tests but still lacks
its required leaf spike". That spec is committed, so that half is no longer
true. What remains true is the other half — "the implementation is also
known to omit upstream behavior" — which is exactly PARTIAL.

(I originally cited TOOLS-STRUCTURAL-TAG as the precedent "for the same
reason". Withdrawn: that row is PARTIAL with planned: specs/structural-tag.md and no such file exists, so it carries PARTIAL
without a committed spec — the opposite of the reason argued here. The state
choice on this row stands on its own argument above and is unchanged.)

Summary counts moved with it, re-derived from the rows rather than
incremented: Structured output and tools PARTIAL 3→4 / INVENTORIED 2→1;
Total PARTIAL 16→17 / INVENTORIED 39→38.

Three counts re-derived and corrected

From the two registries at the pin 5559679229bc961848b121ccdeaa8fa5d79bec98
(SHA confirmed in the pinned checkout before reading):

Claim Spec said Derived Why
Our registered names 40 41 muse_glimmer took it 40→41 on 2026-08-10 under MODEL-MUSE-GLIMMER-W7; test_detect.cpp:221 already pinned 41, so the spec was stale against a committed test
Upstream registered names 43 44 counted from _TOOL_PARSERS_TO_REGISTER
Upstream-only names 5 5 ✅ confirmed exactly: openai, inkling, minimax_m3, cohere_command3, cohere_command4

New finding the spec did not have: two of our names are absent from
upstream's registry at the pin — qwen3 (our local alias for the Hermes-JSON
Qwen dialect) and muse_glimmer. So 44 − 5 = 39 shared, 39 + 2 = 41. The old
"40 = 43 − 3" arithmetic only worked because two errors cancelled.

The second commit is a self-correction. My first pass explained
muse_glimmer as an anchor that had drifted across the pin advance
("decorator-registered at the older e24d1b24"). That was wrong — it never
existed at e24d1b24 either, and the implementing commit is not an ancestor of
the pin at all. The real provenance was already recorded in
porting-inventory.md §16: the only upstream implementation is the unmerged
vllm#51655 at head
075d645af, a deliberate off-pin anchor exception. This changes how "44 vs 41"
should be read — our 41 spans two upstream sources, and a pin advance landing
#51655 folds muse_glimmer into the shared set rather than adding a name.
Recording it as drift would have invited a future reader to "fix" the anchor by
pointing it at the pin, where there is nothing to point at.

nemotron_json, kimi_k3, ling3 confirmed in neither registry (post-pin).

docs/STATUS.md was wrong on both halves

It claimed "36 parser families / 40 accepted names" and "every vLLM tool parser
at the pin except the three Rust/Harmony-backed ones". Five are missing, not
three. Repaired, and the unported ToolParserTestConfig harness is now stated
rather than implied by "all held to the upstream test suites".

My first pass then mis-stated the characterisation in the other direction
("openai, cohere_command3, cohere_command4 are plain Python"). That is
corrected in the third commit — see F2 below. Plain Python is not the same
as portable.

docs/USAGE.md states the parser-name count at :1126, already correct at
41/37, so it needed no content change — but the spec's anchor for it did. See
F1 below.

roadmap_v1.md restated from the registries

Its #608 row still carried the earlier usage-derived framing ("six names
missing"), which listed nemotron_json as portable — it is registered nowhere
at the pin — and missed both Cohere entries. AGENTS.md requires the issue
table, the spec and the PR body to agree.

Anchors

Every anchor was re-derived and read against the tree I wrote it on, and
upstream ones against the pinned checkout. One was wrong on the way in and
fixed before commit: abstract_tool_parser.py:235 is a bare @classmethod
decorator, so the manager anchor is now :223,236,318.

Correcting that claim: I originally wrote "every anchor was re-derived and
read at this head", and that was not true of one of them. docs/USAGE.md:902
was read at the pre-rebase base a20cdac30 and I did not re-read it after
rebasing onto cefacd2d0 (#641), which moved it. Nothing gates anchor line
numbers (#632), so preflight stayed green across the rot. Repaired in the third
commit — see F1.

Gates

  • scripts/agent-preflight.sh --staged — exit 0, "All gates green"
  • scripts/agent-preflight.sh re-run post-rebase — exit 0, "All gates
    green"    , including doc-checkpoint range, now-current range and
    commit-trailers vs origin/main
  • scripts/check-agent-record.py — exit 0, ENGINE=153 MODEL=370 QUANT=82 KERNEL=51 BACKEND=81
  • scripts/check-windows-portability.py — exit 0 BEFORE the rebase; exit 1
    AFTER it, and that red is inherited, not mine.     See below.
  • scripts/check-public-doc-tables.py — exit 0

Rebased onto cefacd2d0 (#641), which also touched roadmap_v1.md and
docs/STATUS.md. The rebase was clean, and per the keyed-record rule I did not
take that on trust: git diff origin/main was verified to contain only the
four scoped edits.

The two red windows-msvc-* checks are inherited from main

Flagging this because the cause changed and a reviewer could easily
misattribute it. The brief I worked from said these two are red on every PR due
to #584/#603. That is no longer the whole story — the failure on this PR is a
third, distinct cause introduced by #641, the same commit I rebased onto:

ERROR: src/vllm/multimodal/video_engine.cpp:21: unguarded POSIX include/call reaches Windows
ERROR: src/vllm/multimodal/video_engine.cpp:59: unguarded POSIX include/call reaches Windows
ERROR: src/vllm/multimodal/video_engine.cpp:64: unguarded POSIX include/call reaches Windows

Already tracked as #648 (the VideoEngine POSIX stat) and #646 (main
does not compile under MSVC since #641, and check-windows-portability.py
runs in no CI job, hook, or preflight). No new issue filed.

Proof it is not mine, rather than assertion:

Correcting my own earlier claim: I reported this checker green, and it was —
but I ran it before rebasing. #646 is exactly right that it sits in no
preflight, so nothing re-ran it for me across the rebase. Post-rebase it exits 1
on inherited content. I am leaving it unfixed deliberately: it is a src/
change, out of this records-only task's authority, owned by #641/#646/#648, and
mixing it in would make this backfill unreviewable.

Known stale count: now filed as #649

The TOOLS-CALLING-CORE row's prose (.agents/engine-matrix.md:156) still says
"tool_parser_names() 40 names / reasoning_parser_names() 7". Re-derived at
this head, both are stale: 41 (tool_parsers/abstract.cpp:269) and 12
(reasoning_parsers/abstract.cpp:72). The code and its tests are correct —
test_detect.cpp:221 already pins 41 — only the record drifted.

Flagging it here with no issue behind it was itself the defect; AGENTS.md is
explicit that a bug found while doing something else still gets an issue. It is
now #649, linked from the roadmap_v1.md open-issues table. Still not fixed
in this PR: it is a third row's prose and its reasoning half belongs to
SAMPLE-REASONING (#605), so repairing it inside a records-only
TOOLS-PARSER-BREADTH change is the "would surprise a reviewer" case that the
in-flow rule carves out.

Remaining

W1 (openai, inkling, minimax_m3) · W2 (cohere_command3/4) · W3 (port
upstream's ToolParserTestConfig as a shared harness). Deferred to the pin
advance: nemotron_json, kimi_k3, ling3.

Review findings repaired (third commit, 04c22ffa5)

A fresh scoped review FAILed this PR on four findings. All four are records-only;
none needed a src/ or tests/ change.

F1 (MEDIUM) — an anchor that rotted during this PR's own rebase. The spec
cited docs/USAGE.md:902 for the parser-count line. Correct at the pre-rebase
base a20cdac30; #641 changed docs/USAGE.md by 572 lines and the line moved
to :1126. Re-derived and read at the pushed head:

1126: | `--tool-call-parser <name>` | `hermes` | Tool-call dialect (41 names over 37 families). …
 902: | `:main-cuda` / `-vulkan` / `-cpu` | moves with **main**: rebuilt when container infrastructure changes …

The spec now carries :1126 and the reason it moved, so the next reader
knows anchors here are ungated (#632). The "read at this head" claim above is
corrected rather than left standing.

F2 (MEDIUM) — the new characterisation was wrong where the old one was right.
The COUNT correction (5, not 3) stands. "Plain Python" does not. Read at the pin
5559679229bc961848b121ccdeaa8fa5d79bec98:

Name What actually backs it Portable from vLLM source?
openai gptoss_tool_parser.py:17 is a declared stub; both methods (:31, :45) raise NotImplementedError("GptOssToolParser is a stub. Use HarmonyParser for tool parsing.") No — Harmony-backed by declaration
cohere_command3 / cohere_command4 cohere_command_tool_parser.py:6-13 — shims over the out-of-tree cohere_melody package (PyFilter/PyFilterOptions, hard ImportError if absent); classes :34, :125, :138 No — no grammar exists in vLLM source
minimax_m3 minimax_m3_tool_parser.py:7,18 — RustToolParser + rust_parser_name No — grammar is in the Rust crate
inkling inkling_tool_parser.py:4,7 — ParserEngine adapter Yes — the only one

This is load-bearing, so W1 and W2 are rescoped, not reworded. W1 is three
different jobs (inkling the ordinary port; minimax_m3 from the wire format,
from-scratch under §9, with its upstream test as the fidelity gate; openai
owes a recorded decision — mirror the Harmony seam or register an explicit
refusal naming the missing piece). W2's Cohere scope carries an undisclosed
external dependency and likewise owes a decision before code. docs/STATUS.md
and the roadmap_v1.md #608 row move to the same reading, since AGENTS.md
requires the three surfaces to agree.

F3 (LOW) — filed as #649, see above.

F4 (LOW, informational) — the TOOLS-STRUCTURAL-TAG precedent citation is
withdrawn, see above. The PARTIAL state choice is unchanged.

Gates on the repair head

🤖 Generated with Claude Code

mudler added 2 commits August 13, 2026 16:01
@mudler
record(TOOLS-PARSER-BREADTH): backfill the 41 parsers already shipped…
56d3152 
…, and correct three counts (#608)

THIS IS A RECORD REPAIR, NOT AN ACHIEVEMENT. No parser was ported, no `src/`
or `tests/` file changed, and no behaviour moved. Every parser named below was
already on `main` before this commit; it landed incrementally under other rows
and this row simply never recorded it. Read the diff as "the row caught up with
the tree", never as "this change delivered forty-one parsers".

The row read:

    Qwen-Coder XML, Mistral, pythonic, and remaining parsers
    Our code: -  ·  Our tests/evidence: -  ·  INVENTORIED

All three families it names by title are implemented, alongside 34 more. This
is the same defect `SAMPLE-REASONING` carried before its own W0 ("the seam
shipped under da93382 but this row was never advanced").

W0 of .agents/specs/tool-parser-breadth.md. W1 (openai, inkling, minimax_m3),
W2 (cohere_command3/4) and W3 (port upstream's ToolParserTestConfig harness)
are separate changes and remain owed.

What is now recorded on the row: 41 accepted parser names over 37 families;
the factory and `tool_parser_names()` anchors in `tool_parsers/abstract.cpp`;
the 27-row ordered autodetect table and its `ORDER MATTERS` collision analysis
in `tool_parsers/detect.cpp`; and the 38 test files, including the registry
test that PINS the count so a factory branch added without listing its name
fails the suite instead of shipping an unreachable dialect.

State `INVENTORIED` -> `PARTIAL`, and not further. The matrix header defines
`ANCHOR-BACKFILL` as "code and tests but still lacks its required leaf spike";
that spec is committed, so that half is no longer true. What remains true is
the other half — "the implementation is also known to omit upstream behavior"
— which is exactly `PARTIAL`. Summary counts moved with it (Structured output
and tools PARTIAL 3->4 / INVENTORIED 2->1; Total PARTIAL 16->17 /
INVENTORIED 39->38), both re-derived from the rows rather than incremented.

Three counts in the spec were re-derived from the two registries at the pin
5559679229bc961848b121ccdeaa8fa5d79bec98 and corrected:

  * We register 41 names, not 40. `muse_glimmer` took it 40 -> 41 on
    2026-08-10 under MODEL-MUSE-GLIMMER-W7, and `test_detect.cpp:221` already
    pinned 41 — so the spec was stale against a committed test.
  * Upstream registers 44, not 43.
  * The five upstream-only names are confirmed exactly as the spec listed
    them. But two of OUR names are absent from upstream's registry at the pin:
    `qwen3` (our local alias for the Hermes-JSON Qwen dialect) and
    `muse_glimmer` (decorator-registered at the older e24d1b24 port anchor,
    gone from vllm/tool_parsers/ at 555967922). 44 - 5 = 39 shared, 39 + 2 =
    41. The old "40 = 43 - 3" arithmetic only worked because two errors
    cancelled.

`docs/STATUS.md` claimed "36 parser families / 40 accepted names" and "every
vLLM tool parser at the pin except the three Rust/Harmony-backed ones". Both
halves were wrong: five are missing, not three, and of those five only
`minimax_m3` is Rust-backed (`inkling` is a ParserEngine adapter; `openai`,
`cohere_command3` and `cohere_command4` are plain Python). Repaired, and the
unported `ToolParserTestConfig` harness is now stated rather than implied by
"all held to the upstream test suites".

The `roadmap_v1.md` issue row still carried the earlier usage-derived framing
of #608 — "six names missing", which listed `nemotron_json` as portable (it is
registered nowhere at the pin) and missed both Cohere entries. AGENTS.md
requires the issue table, the spec and the PR body to agree, so it is restated
from the registries. `nemotron_json`, `kimi_k3` and `ling3` are in NEITHER
registry and arrive with the pin advance, not here.

Every anchor recorded here was re-derived and read at this head, upstream ones
against the pinned checkout. One was wrong on the way in and fixed before
commit: `abstract_tool_parser.py:235` is a bare `@classmethod` decorator, so
the manager anchor is now `:223,236,318`.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
@mudler
record(TOOLS-PARSER-BREADTH): muse_glimmer is the off-pin PR anchor, …
6388bcc 
…not a drifted one (#608)

Self-correction to the W0 backfill in the previous commit. Still a RECORD
REPAIR: no code, no `src/`, no `tests/`.

The W0 row and spec explained why `muse_glimmer` is one of the two names in our
registry but not upstream's, and got the reason WRONG. They said it was
"decorator-registered at the older `e24d1b24` port anchor, gone from
vllm/tool_parsers/ at 555967922" — i.e. an anchor that had drifted across the
pin advance.

It never existed at `e24d1b24`. `git grep -ln muse_glimmer e24d1b24` in the
pinned checkout returns nothing, and `git merge-base --is-ancestor` shows the
implementing commit is not an ancestor of the pin at all.

The real provenance was already recorded in porting-inventory.md §16 and this
commit stops contradicting it: Meta released Muse Glimmer on 2026-08-08, after
the pin (2026-07-26); the ONLY upstream implementation is the unmerged
vllm#51655 at head `075d645af`, where the parser is decorator-registered at
`muse_glimmer_tool_parser.py:183`. That is a deliberate off-pin anchor
exception taken on explicit developer direction, not drift.

This matters for how "44 vs 41" is read. It is not one registry missing three
names; our 41 spans TWO upstream sources, and a pin advance that lands #51655
folds `muse_glimmer` into the shared set rather than adding a name. Recording
it as drift would have invited a future reader to "fix" the anchor by pointing
it at the pin, where there is nothing to point at.

Found by re-deriving the claim instead of trusting it — the same discipline
that caught the 40-vs-41 and 43-vs-44 errors in the previous commit. Landed as
a follow-up commit rather than an amend, because this branch is already pushed
and nothing here is ever force-pushed.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
This was referenced Aug 13, 2026
Open
Open
@mudler
record(TOOLS-PARSER-BREADTH): only inkling is portable from vLLM so…
04c22ff 
…urce, and the USAGE anchor rotted in this branch's own rebase (#608, #649)

Fresh-review findings on #643. Records only: no `src/`, `include/` or `tests/`
file is touched and no row state moves.

F1 - the USAGE.md anchor rotted during this branch's own rebase. The spec cited
`docs/USAGE.md:902` for the parser-name count. That was right at the pre-rebase
base `a20cdac30`; #641 (`cefacd2d0`) changed `docs/USAGE.md` by 572 lines and
the count line moved to `:1126`. Re-derived and READ at this head:

    1126: | `--tool-call-parser <name>` | `hermes` | Tool-call dialect
          (41 names over 37 families). `auto` detects from the chat template ...

`:902` at this head is a container-tag table row (`| :main-cuda / -vulkan /
-cpu | moves with main ...`). The spec now says `:1126` and carries the reason
it moved, because nothing gates anchor line numbers (#632): a rebase moves them
silently and a re-run preflight still passes, which is exactly how this
survived. The PR body's "every anchor was re-derived and read at this head" is
corrected there; it was not true of this one.

F2 - the new characterisation was wrong where the old one was right. W0's COUNT
correction stands: five upstream-only names, not the "three Rust/Harmony-backed
ones" `docs/STATUS.md` claimed. Its restatement that
`openai`/`cohere_command3`/`cohere_command4` are "plain Python" does not, and it
is wrong in the more dangerous direction - plain Python is not the same as
portable. Read in the pinned checkout 5559679229bc961848b121ccdeaa8fa5d79bec98:

  * vllm/tool_parsers/gptoss_tool_parser.py:17 - `GptOssToolParser` is a
    declared stub ("All output parsing is handled by HarmonyParser. This stub
    exists as a capability declaration via HarmonyParser.tool_parser_cls"), and
    BOTH methods, :31 and :45, raise NotImplementedError("GptOssToolParser is a
    stub. Use HarmonyParser for tool parsing."). Harmony-backed by explicit
    declaration, not a text parser.
  * vllm/tool_parsers/cohere_command_tool_parser.py:6-13 - both Cohere classes
    (base :34, :125, :138) are shims over the out-of-tree `cohere_melody`
    package (`PyFilter`/`PyFilterOptions`), with a hard ImportError if it is
    absent. All parsing is delegated; NO grammar exists in vLLM source to port.
  * minimax_m3_tool_parser.py:7,18 - `RustToolParser` +
    rust_parser_name = "MinimaxM3ToolParser". The grammar is in the Rust crate.
  * inkling_tool_parser.py:4,7 - a ParserEngine adapter over
    `InklingParserToolAdapter`.

So of the five upstream-only names, only `inkling` is portable from vLLM
source. That is load-bearing, so W1/W2 are RESCOPED, not reworded. W1 is three
different jobs: `inkling` is the ordinary port; `minimax_m3` is written from the
wire format its docstring describes, recorded from-scratch in
porting-inventory.md section 9, with its upstream test as the fidelity gate; and
`openai` has no upstream text parser at all, so it owes a decision recorded in
the spec before code - mirror the Harmony seam, or register the name with an
explicit refusal naming the missing piece, per AGENTS.md. W2's Cohere scope
carries an undisclosed external dependency and likewise owes a decision rather
than a port. `docs/STATUS.md` and the `roadmap_v1.md` #608 row move to the same
reading, since AGENTS.md requires the three surfaces to agree.

F3 - filed as #649 rather than repaired here. The `TOOLS-CALLING-CORE` row
(.agents/engine-matrix.md:156) still records `tool_parser_names()` 40 /
`reasoning_parser_names()` 7; re-derived at this head they are 41
(src/vllm/entrypoints/openai/tool_parsers/abstract.cpp:269) and 12
(src/vllm/entrypoints/openai/reasoning_parsers/abstract.cpp:72). It was flagged
in the PR body with no issue behind it, which is the thing AGENTS.md forbids.
#649 now tracks it and is linked from the roadmap_v1.md open-issues table. It is
not fixed in this commit: it is a third row's prose and its reasoning half
belongs to SAMPLE-REASONING (#605), so repairing it inside a records-only
TOOLS-PARSER-BREADTH change is the "would surprise a reviewer" case the in-flow
rule carves out. Code and tests are already correct - test_detect.cpp:221 pins
41 - so only the record drifted.

F4 was informational. The PR body cited `TOOLS-STRUCTURAL-TAG` as the `PARTIAL`
precedent, but that row carries `planned: specs/structural-tag.md` and no such
file exists, so it is PARTIAL WITHOUT a committed spec - the opposite of the
reason argued. The body is corrected; the `PARTIAL` state on this row is
unchanged and remains correct on its own argument.

scripts/agent-preflight.sh --staged: exit 0, "All gates green".
scripts/check-windows-portability.py: exit 1, INHERITED - three errors in
src/vllm/multimodal/video_engine.cpp introduced by #641, tracked by #648 (the
fix) and #646 (the checker runs in no CI job, hook or preflight).
`git diff origin/main -- src/ include/ tests/ scripts/` is empty and
video_engine.cpp is byte-identical to origin/main.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
This was referenced Aug 13, 2026
Open
Closed
@mudler
Merge origin/main into row/tool-parser-breadth-w0 (#608, #649)
860e391 
FOLLOWING_AGENTS_PROTOCOL

main advanced to b81a5e4 (#641's LTX-2.5, then #650's oracle policy) and
roadmap_v1.md's Open-issues table conflicted. That table is a KEYED RECORD, so
AGENTS.md forbids resolving it by automatic three-way merge: took main's file
WHOLESALE and reapplied this branch's two scoped edits.

The two edits are NOT the same operation, and treating them alike is the trap I
walked into first. #608 already exists on main -- it landed via #612 -- so it is an
UPDATE IN PLACE. #649 is new, so it appends. My first attempt appended both and
produced a duplicate #608, caught by counting rather than by any gate: the
uniqueness check the checker does run would have caught it too, but only after I
had already written the wrong thing.

Verified rather than asserted: diff against main is +2/-1 -- one row replaced, one
added -- and grep gives exactly one #608 row and one #649 row.

One gate needed a second look. test_cpu_x86_llamacpp_floor's contended-leg case
failed once here at load 26.97, then passed twice consecutively in this same
worktree, and passes on clean main at the same load; the test file and tools/bench
are byte-identical to main. That is #618's known flakiness, not this resolution.
Re-ran the full staged gate afterwards for a clean result rather than reasoning
past the red.

scripts/agent-preflight.sh --staged: exit 0, all gates green.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
@localai-bot
localai-bot merged commit 67e53e7 into main Aug 13, 2026
11 of 16 checks passed
localai-bot pushed a commit that referenced this pull request Aug 13, 2026
@mudler
Merge origin/main into row/mm-input-limits (#607)
0206e7f 
FOLLOWING_AGENTS_PROTOCOL

This branch was based on a20cdac and main has since reached 67e53e7 -- #641's
LTX-2.5, #650's oracle policy, and #643's own tool-parser backfill. roadmap_v1.md
conflicted.

Resolved by the keyed-record rule rather than by three-way merge: took main's file
WHOLESALE, then reapplied this branch's two edits IN PLACE -- the #607 issue row
and the recipe-sweep table's --language-model-only line, both of which existed
already and both of which this branch UPDATES rather than adds. Diff against main
is +2/-2, exactly two replacements and no additions.

The reason wholesale mattered here and not just as ceremony: this branch's tree
still carried the PRE-CORRECTION #608 row, which said four of the five parsers
were portable at the pin. #643 has since corrected that to "only inkling is
portable from vLLM source". An automatic merge would have been free to keep either
side; taking main's file wholesale means the corrected row is the one that
survives, and I checked that it did rather than trusting the mechanism.

Exactly one #607 row and one #608 row afterwards.

scripts/agent-preflight.sh --staged: exit 0, all gates green.

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]
@localai-bot
localai-bot deleted the row/tool-parser-breadth-w0 branch August 13, 2026 18:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@localai-bot @mudler