spec(ENG-UPSTREAM-OMNI-PIN): vLLM-Omni needs its OWN pin, and the inventory that says otherwise (#633) - #635
Merged
Merged
Conversation
added 3 commits
August 13, 2026 14:29
…entory that says otherwise (#633) FOLLOWING_AGENTS_PROTOCOL The pin protocol covers one repository. Every architecture living only in `vllm-project/vllm-omni` therefore has no oracle this protocol can NAME — not a hard comparison, an unavailable one. Two rows already carry it as their blocker: `minimax-h3.md:205-208` ("a vllm-omni pin is a prerequisite for W3+") and the H3 row in `model-matrix.md`, which closes with "OPEN: there is no vllm-omni parity PIN". #435 (LTX-2.5) is the third. The surface is ~40 modules wide, not three rows: the whole TTS family (IndexTTS2, Fish Speech, GLM-TTS, Ming-TTS, MOSS-TTS, Qwen3-TTS, VoxCPM2, Voxtral-TTS, Higgs Audio v2/v3, Step Audio2, CosyVoice3, OmniVoice) plus Qwen2.5/3-Omni, Aura-Omni, Ming-Flash-Omni and Hunyuan Image3/Video. So this is also a RECORDS defect: `model-matrix.md` claims an EXHAUSTIVE architecture inventory of 329 rows, and that claim is scoped to one repository without saying so. Design, in the spec: a SECOND pin block rather than a second value of the first. vllm-omni requires vLLM 0.27.0+ against our 0.26.0.dev0 core pin, so the two are allowed to disagree, and `vllm_core_commit_used` records which core commit the omni oracle actually ran against. Two rules follow — an omni-gated number is labeled with BOTH commits, and is never evidence about the core pin's surface. Gateability stays per ARCHITECTURE: the oracle must build, run and EMIT OUTPUT for that model, because `assert_oracle_commit` exists precisely because an oracle once resolved and was a rollback. The spec answers the question it would otherwise leave to be discovered: an omni pin advance does NOT re-open the vLLM-side binding grids, conditional on isolation (own virtualenv, no core-pinned row citing an omni number, no mutation of ${VLLM_SOURCE} or the environment the core pin measures itself from). Fail any condition and the denominator's own dependency tree moved, so it is re-validated as a core sync cycle. W1-W2 (the `upstream-sync.md` block schema, concept and rules) land here. W3-W5 are owed and unclaimed: the checker with its five RED-first assertions, the measured pin values, and a per-architecture gateability demonstration. The pin values are deliberately NOT invented here — they need an eligible host, and an unavailable value stays PENDING rather than becoming an assumption. `ENGINE_ROWS` 152 -> 153 for a genuinely new protocol row, never to make a failing transition pass. Gates: `agent-preflight.sh` and `--staged` both green. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
FOLLOWING_AGENTS_PROTOCOL Two keyed-record conflicts, both resolved by taking the target branch version WHOLESALE and reapplying the scoped edit, per AGENTS.md §Records. `main` had independently bumped `ENGINE_ROWS` 152 -> 153 for `SERVE-RECIPE-ARGS` while this branch bumped the same constant 152 -> 153 for `ENG-UPSTREAM-OMNI-PIN`. Both rows are real and neither replaces the other, so the merged value is 154 — taking either side's 153 would have silently dropped one row while leaving the matrix looking consistent. The `Serving, API, CLI, library` rollup is merged the same way: 32 -> 34 rows, main's +1 ACTIVE and this branch's +1 READY both kept. Unrelated keys verified byte-for-byte: the whole engine-matrix diff against origin/main is this row plus those two rollup cells, and the roadmap issue table carries no duplicate issue key after its automerge. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…top overclaiming the inventory gap (#633) FOLLOWING_AGENTS_PROTOCOL Two corrections found while writing the IndexTTS-2.5 row against this spec. The spec cited `a4ea67a2` as the one source audit of vllm-omni. `main` has since landed a second, newer one: #609/#610 anchor their omni rows to `bbe6ccc512a404a2df8c977ea29003002f2683e8`. Both are now cited, with the point that neither is a pin — a source read establishes what EXISTS, never what RUNS, which is the whole distinction this row turns on. The spec also said the omni surface is "uninventoried and uncounted". That was true when written and is no longer: those same PRs rowed several omni architectures explicitly as out-of-repo. The residual defect is narrower and the text now says the narrower thing — the document's scope sentence still does not state the boundary those rows work around, and each of them repeats the same missing-pin blocker in its evidence cell. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…d-bearing (#633) FOLLOWING_AGENTS_PROTOCOL `check-pr-size.py` correctly refused the branch: a change to `scripts/check-agent-record.py` owes semantic mutation evidence in `tests/scripts/test_agent_record.py`, and the count bump had none. The new assertion names BOTH rows the constant now covers, which matters more here than in the #117 and #606 precedents it copies, because this bump COLLIDED. `main` took the constant 152 -> 153 for `SERVE-RECIPE-ARGS` while this branch took the same 152 -> 153 for `ENG-UPSTREAM-OMNI-PIN`, so both sides read 153 and the merge looked clean. Keeping either 153 would have dropped a real row while leaving the matrix internally consistent. RED-first, against exactly that bad merge: drop the omni-pin row, rewind `ENGINE_ROWS` to 153 and rewind the serving rollup, so every count agrees with every other count. The full suite then reports 53 tests with ONE failure, and it is this test — nothing else in the record can see a row that vanished into a matching number. Scratch copy restored byte-for-byte, verified by comparison. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
…nded (#633) FOLLOWING_AGENTS_PROTOCOL #650 landed the oracle registry while this row was open, and it is a better answer to this row's problem than the one this spec proposed. The first draft put an `omni-parity-pin` block inside `upstream-sync.md`; the registry puts one file per oracle under `.agents/oracles/`, read by glob, and explicitly rejects the shared-surface shape the draft had. So the spec is rewritten rather than patched, and says at the top that it was superseded. What this row no longer does: propose a record format, restate per-architecture gateability (AGENTS.md and `oracles/README.md` already bind it), or touch `.agents/oracles/vllm-omni.md` at all — that file already reads `pin = UNPINNED`, `gateable = no`, `evidence = #633`, which is exactly true. What survives is what the registry file cannot state on its own: the two pins may legitimately DISAGREE (vllm-omni requires vLLM 0.27.0+ against our 0.26.0.dev0 parity pin), an omni-gated number is therefore labeled with BOTH commits and is never evidence about the core pin's surface, and an omni pin advance does not re-open the vLLM-side binding grids provided the omni oracle is isolated in its own virtualenv. `upstream-sync.md` now points at the registry and carries only those rules. `core_commit_used` is deliberately NOT added to the `oracle-pin` schema here. The pin is UNPINNED, so there is no value to record, and extending a checker-enforced schema for a value that does not exist is speculation. It lands with the measurement as W4, with its own mutation evidence. Merge resolution: main had moved `PARTIAL` 16 -> 17 and `INVENTORIED` 39 -> 38; this branch's one READY row is reapplied on top of those numbers rather than either side being taken whole. Gates: preflight green except `test_cpu_x86_llamacpp_floor`, which exits 4 (NO_QUIET_WINDOW) at load 74-103 while another session builds LTX-2.5 on this box. It never measured anything; base-SHA comparison recorded on the PR. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
FOLLOWING_AGENTS_PROTOCOL Fourth time main has moved under this branch today. This one merged CLEAN with no conflicts, and every record gate was re-run afterwards rather than inferred from the absence of conflict markers: check-agent-record, check-model-checklist, check-oracle-pins, check-doc-checkpoint, check-public-doc-tables and the 54-case record suite are all green on the merged tree. That distinction matters here: a clean automatic merge of a keyed record is the failure mode this protocol refuses, not evidence of correctness. The earlier model-matrix merge on the sibling branch merged clean too and produced a file with two Total rows. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
localai-bot
pushed a commit
that referenced
this pull request
Aug 13, 2026
FOLLOWING_AGENTS_PROTOCOL #635 landed as squash `782264c0c`, so the pin content this branch carried as its own commits arrives on main as a DIFFERENT commit. That produced an add/add conflict on `specs/upstream-omni-pin.md` plus content conflicts on `upstream-sync.md` and the roadmap issue table. Resolved by taking MAIN's version for everything the pin PR owned — the squash is the merged truth for those files, and keeping this branch's pre-squash copies would resurrect a superseded draft — then reapplying only this row's own scoped edit, the #634 issue-table entry. Verified on the merged tree rather than inferred: check-agent-record, check-model-checklist, check-oracle-pins, check-doc-checkpoint, check-public-doc-tables, check-now-current and the 54-case record suite all green, with `ENGINE_ROWS = 154` (from the merged pin row) and MODEL = 372 (this row's two architectures) both intact. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Scopes #633.
Rewritten after #650 superseded the original design
This PR originally proposed an
omni-parity-pinblock inside.agents/upstream-sync.md. While it was open, #650 landed the oracleregistry — one file per oracle under
.agents/oracles/, a fencedoracle-pinblock,
scripts/check-oracle-pins.pyenforcing it — which is a better answer tothe same problem and explicitly rejects the shared-surface shape the draft had.
So the spec was rewritten rather than patched, and says so at the top. Reviewing
the diff against the first version is the wrong frame; the current spec is the
proposal.
What this row no longer does
implementation" and
.agents/oracles/README.mdalready bindgateable = yesto "demonstrably builds and runs the model".
.agents/oracles/vllm-omni.mdat all. That file already readspin = UNPINNED,gateable = no,evidence = #633, which is exactly true.Nothing to correct.
What survives, because the registry file cannot state it
our parity pin is
555967922(0.26.0.dev0). Forcing them equal means movingevery gated row to suit a lane that touches none of them.
the core pin's surface — not in a parity claim, a binding grid, or a
docs/BENCHMARKS.mdrow owned by a core-pinned row.the omni oracle is isolated in its own virtualenv and touches neither
${VLLM_SOURCE}nor the environment the parity pin measures itself from. Faila condition and the denominator's own dependency tree moved, so it is
re-validated as a core sync cycle.
upstream-sync.mdnow points at the registry and carries only those rules.Deliberate non-change
core_commit_usedis not added to theoracle-pinschema here. The pin isUNPINNED, so there is no value to record, and extending a checker-enforcedschema for a value that does not exist is speculation. It lands with the
measurement as W4, with its own mutation evidence.
Mutation evidence
check-pr-size.pyrequires it for thecheck-agent-record.pycount change, andit is load-bearing:
test_omni_pin_row_is_inside_the_engine_ratchetis RED-firstagainst the exact bad merge this branch hit —
mainbumpedENGINE_ROWS152 -> 153 for
SERVE-RECIPE-ARGSwhile this branch bumped it 152 -> 153 for itsown row, so both sides read 153 and the merge looked clean. Drop the row, rewind
the constant and the rollup so every count agrees, and the suite reports 53 tests
with ONE failure: that test. Merged value is 154; keeping either 153 would
have dropped a real row while leaving the matrix internally consistent.
Gates
agent-preflight.shgreen excepttest_cpu_x86_llamacpp_floor, which exits 4(
NO_QUIET_WINDOW) at load 74-127 while another session builds LTX-2.5 on thesame box. It never measured anything, so it is not a verdict on this change; the
base-SHA comparison on an unmodified
origin/maintree is noted in the thread.Follow-up
#634 / #637 (IndexTTS-2.5) is
stacked on this row. MiniMax-H3 W3+ and LTX-2.5 carry the same blocker.