diff --git a/.agents/engine-matrix.md b/.agents/engine-matrix.md index b9bc071e8..ae56ecf48 100644 --- a/.agents/engine-matrix.md +++ b/.agents/engine-matrix.md @@ -44,11 +44,11 @@ forensics: roadmap_v1.md and the parity ledger. | Sampling and generation | 15 | 4 | 2 | 0 | 0 | 4 | 0 | 1 | 4 | | Structured output and tools | 7 | 0 | 4 | 0 | 0 | 2 | 0 | 0 | 1 | | Speculative decoding | 21 | 0 | 0 | 1 | 0 | 5 | 0 | 4 | 10 | -| Serving, API, CLI, library | 33 | 10 | 2 | 0 | 2 | 10 | 2 | 3 | 4 | +| Serving, API, CLI, library | 34 | 10 | 2 | 0 | 3 | 10 | 2 | 3 | 4 | | LoRA and adapters | 2 | 0 | 0 | 0 | 0 | 1 | 0 | 0 | 1 | | Long context and attention | 10 | 5 | 0 | 0 | 1 | 0 | 1 | 0 | 3 | | Loading, tokenizer, config | 10 | 3 | 3 | 0 | 0 | 1 | 1 | 1 | 1 | -| **Total** | **153** | **35** | **17** | **4** | **9** | **30** | **8** | **11** | **38** | +| **Total** | **154** | **35** | **17** | **4** | **10** | **30** | **8** | **11** | **38** | ## Engine core and scheduling @@ -218,6 +218,7 @@ claims it. | `ENG-TRAILER-MERGE-ARTIFACTS` | The trailer gate rejects CORRECT commits because of paragraph placement, and that is why `main` is red on `agent-record`. `check-commit-trailers.py` reads trailers via `git interpret-trailers --parse`, which treats ONLY the final paragraph as the block; GitHub appends `Co-authored-by:` as a SEPARATE trailing paragraph on a squash merge, so a complete correct block becomes invisible and the gate reports it missing. MEASURED: piping `git show -s --format=%B dbd0d51c` into `git interpret-trailers --parse` prints nothing but the co-author line, and 13 of the last 30 commits on `main` fail the check -- unnoticed only because those runs were cancelled (#274), which HID the defect rather than causing it. FIX: fuse consecutive trailing TRAILER-SHAPED paragraphs before parsing. Nothing is relaxed -- the block must still exist, the marker must still sit above it, each declaration must still appear exactly once, and an AI co-author is still forbidden; the block is merely FOUND where the merge tool left it. A prose paragraph still terminates it. REJECTED IN FLIGHT and recorded because it is the more instructive half: a first attempt also collapsed identical duplicate trailers to fix the multi-commit-squash shape, which relaxes the uniqueness rule an existing test already pins. Rewriting that assertion to suit the change is what AGENTS.md forbids, and the distinction is real -- a doubled block is genuinely malformed and fixable at source, whereas the co-author case is a correct commit defeated by the parser. Reverted in full. SCOPE LIMIT, stated rather than implied: this fixes ONE of five observed shapes. `f64f2b71` (bot co-author) is a REAL violation the parse had been hiding and now correctly fails; `87308dea` (GitHub's `---------` separator), `b8293c88` (squash doubled the block) and `b580452d` (merge button, no trailers) stay red by design. Closing those is a merge-method change, not a checker change | T0 | NO vLLM analogue -- local protocol machinery, so the mirror rule does not apply and there is no upstream `file:line` to port from. Governed by `AGENTS.md` §"Changing the rules or a checker" | `scripts/check-commit-trailers.py:60` (`join_trailing_trailer_paragraphs`, `_is_trailer_paragraph`, and the fused `parsed_trailers`) | `tests/scripts/test_check_commit_trailers.py:1` 21 cases -- the RED-BEFORE appended-co-author case plus four GUARDS that keep the fusion bounded (doubled block still fails, contradictory declarations still fail, a no-trailer merge message still fails, prose after the block still fails), all four green before and after; closure [parity-ledger.md#L941](parity-ledger.md#L941) | [trailer-merge-artifacts.md](specs/trailer-merge-artifacts.md); issue [#406](https://github.com/mudler/vllm.cpp/issues/406) | `DONE` | `157080c8` | | `ENG-FORGE-COAUTHOR` | The forbidden-AI-trailer rule was catching ATTRIBUTION rather than an authorship claim, which is why bot-opened PRs red `main` on merge. GitHub composes the squash message itself and appends the account that opened the PR — `Co-authored-by: localai-org-maint-bot <...@users.noreply.github.com>` — and most PRs here are opened by a bot, so nearly every squash trips the AI-identity check. Real instance `f64f2b71`, invisible until #406 repaired the parse, which is why it reads as a new failure and is not one. The rule exists so an AI cannot claim it WROTE the code, and that stays; GitHub is recording who pressed the button, and the AI-involvement claim is already carried separately by `AI-Assisted` and `Assisted-by` in the same block. FIX: accept a `Co-authored-by` at a GitHub account noreply address even when the name matches an AI identity token, keyed on the FORGE'S OWN DOMAIN rather than the name so the exemption cannot be borrowed. A hand-written `Co-authored-by: Claude ` still fails; `Signed-off-by` is excluded from the exemption entirely, because a sign-off is a legal assertion about provenance rather than attribution. `AGENTS.md` records the same distinction in the same change so prose and checker cannot drift | T0 | NO vLLM analogue -- local protocol machinery, so the mirror rule does not apply and there is no upstream `file:line` to port from. Governed by `AGENTS.md` §"Changing the rules or a checker" | `scripts/check-commit-trailers.py:38` (`FORGE_ACCOUNT_EMAIL` and the forbidden-trailer skip) | `tests/scripts/test_check_commit_trailers.py:1` 25 cases -- the RED-BEFORE forge-bot case plus THREE guards that matter more than the relaxation because this LOOSENS a rule: a hand-written AI co-author still fails, `Signed-off-by` at the same noreply address still fails, and a human co-author still passes; all three green before and after. Real commit `f64f2b71` re-verified per commit | [forge-coauthor-attribution.md](specs/forge-coauthor-attribution.md); issue [#418](https://github.com/mudler/vllm.cpp/issues/418) | `ACTIVE` | `CLAIM-ENG-FORGE-COAUTHOR` | | `ENG-NOW-DERIVED` | W1-W5 remove the per-row `.agents/NOW.md` write: each moved row's own spec carries `## Now`, `scripts/now.py` renders the live roster offline-first, and the digest cannot regrow a row table. Implementation merge `dbd0d51c`; progressive legacy-spec backfill is the selected compatibility policy, not remaining work. Runtime/performance/parity are `VOID` because this is local protocol machinery | T0 | No vLLM analogue; governed by `AGENTS.md` §Changing the rules or a checker | `scripts/now.py:163`; `scripts/check-doc-checkpoint.py:181`; `scripts/check-now-current.py:57` | `tests/scripts/test_doc_checkpoint.py:142`; `tests/scripts/test_now_render.py:34`; `tests/scripts/test_check_now_current.py:1`; closure [parity-ledger.md#L939](parity-ledger.md#L939) | [now-derived.md](specs/now-derived.md); issue [#374](https://github.com/mudler/vllm.cpp/issues/374) | `DONE` | `dbd0d51c` | +| `ENG-UPSTREAM-OMNI-PIN` | Pin `vllm-project/vllm-omni`, the SEPARATE repository holding every omni-only architecture (MiniMax-H3, LTX-2.5, and the ~40-module TTS family incl. IndexTTS-2.5). Its pin now lives in the oracle registry [`.agents/oracles/vllm-omni.md`](oracles/vllm-omni.md) landed by #650, which records the truth today: `pin = UNPINNED`, `gateable = no`, `evidence = #633`. So the RECORD is no longer missing; the PIN is, and with it any oracle-run gate for those lanes. What this row still owes 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, so forcing them equal would move every gated row to suit a lane that touches none), 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 and touches neither `${VLLM_SOURCE}` nor the environment the parity pin measures itself from. NOTE this spec was rewritten mid-flight: its first draft proposed a second pin block inside `upstream-sync.md`, which #650 superseded with the one-file-per-oracle registry, and the row now proposes no record format at all | T1 | `vllm-project/vllm-omni` `vllm_omni/model_executor/models/registry.py`; source-audited at `a4ea67a2` (v0.26.0) and at `bbe6ccc512a404a2df8c977ea29003002f2683e8` (#609, #610) -- neither is a pin, both read source | none -- protocol change, no product code | `tests/scripts/test_agent_record.py` `test_omni_pin_row_is_inside_the_engine_ratchet` (RED-first vs the exact bad merge: row dropped, `ENGINE_ROWS` rewound, rollup rewound, every count agreeing -- 1 of 53 tests fails and it is that one). W3-W5 assertions owed | [upstream-omni-pin.md](specs/upstream-omni-pin.md); issue [#633](https://github.com/mudler/vllm.cpp/issues/633) | `READY` | unassigned | | `SERVE-CLI-CHAT` | Interactive `chat` and `complete` commands against a running OpenAI-compatible server, plus preservation of the existing local-model completion invocation | T1 | registration `vllm/entrypoints/cli/main.py:17-37,73-98`; client/model resolution + stream shaping `vllm/entrypoints/cli/openai.py:30-100`; chat `:155-234`; complete `:237-312` at `5559679229` | current in-process completion only `examples/cli/main.cpp:1-207`; remote command implementation absent | C-ABI stream baseline `tests/capi/test_capi.cpp:567-711`; chat-template baseline `tests/capi/test_chat_prompt.cpp:37-89`; command/fake-server tests absent | [cli-chat-complete.md](specs/cli-chat-complete.md) | `ANCHOR-BACKFILL` | `CLAIM-SERVE-CLI-CHAT-SPIKE` | | `SERVE-RECIPE-ARGS` | Accepted-and-inert serve arguments: an enumerated table of flags that published recipes pass, that are no-ops for this engine, and that must therefore not abort argument parsing. Not a catch-all — anything unlisted still aborts, and mirrored validation still fires. Found by the 2026-08-13 recipe-surface sweep: `vllm-serve` rejects unknown arguments (`src/vllm/entrypoints/openai/server_main.cpp:440`), so `--enable-auto-tool-choice` (89/157 official recipes) and `--trust-remote-code` (82/157) stop the server before model load even though neither means anything here — including for models we ship token-exact and gated | T1 | `vllm/entrypoints/openai/cli_args.py:105` (`enable_auto_tool_choice` default), `:395` (requires `--tool-call-parser`, a `TypeError` otherwise — mirrored, not dropped); threading `vllm/entrypoints/openai/api_server.py:426,441,529,544` at `5559679229` | `src/vllm/entrypoints/openai/server_main.cpp:289` (`kAcceptedInertArgs`, the enumerated table), `:312` (`FindAcceptedInertArg` — returns `nullptr` for anything unlisted, so the existing `unknown argument` abort is untouched), `:505` (the parse branch + the per-flag notice), `:560` (the mirrored `cli_args.py:395` validation); `docs/USAGE.md` § "Accepted for recipe compatibility" | `tests/vllm/entrypoints/openai/test_serve_recipe_args.cpp:141` (listed flags reach model load), `:165` (an unlisted flag STILL aborts — the load-bearing case), `:188` (the mirrored `cli_args.py:395` refusal), `:212` (the per-flag notice); registered `tests/CMakeLists.txt:877`. 4 cases / 58 asserts GREEN; RED-first against the pre-change binary (17 failed, `Status: FAILURE!`). Each case re-execs the binary into the REAL `VllmServerMain`. MUTATION PROVEN in a scratch copy: widening `FindAcceptedInertArg` into a catch-all turns exactly `:165` RED (8 asserts) and leaves the other three GREEN | [serve-recipe-args.md](specs/serve-recipe-args.md) | `ACTIVE` | `CLAIM-SERVE-RECIPE-ARGS` | | `SERVE-POOLING-ENDPOINTS` | Embeddings, pooling, score, rerank, classify HTTP surface (`/v1/embeddings`, `/pooling`, `/score`, `/rerank`, `/classify`). **SPIKED 2026-07-28 (`CLAIM-POOLING`):** the whole pooling task class is scoped in [pooling-task-class.md](specs/pooling-task-class.md). **`/v1/embeddings` LIVE 2026-08-08 (ARCH-ONE-SURFACE ROW 6, `CLAIM-EMBEDDINGS-ONE-SURFACE`):** task-conditional registration (embed/api_router.py:22-28 mirror; the route exists ONLY on a pooling-model server, and the generate routes do not — both directions socket-404-pinned), OpenAI request/response shape (string-or-array input; `dimensions`/base64/token-arrays are named-residual 400s), handler drives the ONE engine path (`LoadedEngine -> LLMEngine::embed -> registry forward -> PoolingRunner`) — the same path `vllm_embed` (ABI v15) drives. RESIDUALS: `/pooling`, `/score`, `/rerank`, `/classify` (need a classify arch) | T2 | `vllm/entrypoints/pooling/embed/api_router.py:28`; `vllm/entrypoints/pooling/embed/protocol.py:34,173-185`; `vllm/entrypoints/pooling/scoring/api_router.py:37,71`; `vllm/entrypoints/pooling/classify/api_router.py:26` | `src/vllm/entrypoints/openai/api_server.cpp` `handle_embeddings` + the `if (embedder_)` route gate; `examples/server/main.cpp` pooling task dispatch | `tests/vllm/entrypoints/openai/test_api_server.cpp` embeddings section (dispatch shape + socket smoke + BOTH-direction 404 pins) | [embeddings-one-surface.md](specs/embeddings-one-surface.md) | `ACTIVE` | `CLAIM-EMBEDDINGS-ONE-SURFACE` | diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index c7202ee46..91219dbf9 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -90,6 +90,7 @@ issue is not yet placed. Keyed record: update in place, never append. | [#322](https://github.com/mudler/vllm.cpp/issues/322) | `ENG-RELEASE-BINARIES` | Release handoff collides with tracked checkout `assets` directory | bug | | [#406](https://github.com/mudler/vllm.cpp/issues/406) | `ENG-TRAILER-MERGE-ARTIFACTS` | The trailer gate fails on how commits LAND: GitHub's Co-authored-by displaces the trailer block | bug | | [#467](https://github.com/mudler/vllm.cpp/issues/467) | `ENG-TRAILER-MERGE-ARTIFACTS` | `agent-preflight.sh` prints "trailer suites ok / All gates green" over a range where `check-commit-trailers.py` reds on 3 rules: it runs the checker's own MUTATION SUITE, never the checker over the actual range, so git-generated merge messages are the one commit class nothing checks | bug | +| [#633](https://github.com/mudler/vllm.cpp/issues/633) | `ENG-UPSTREAM-OMNI-PIN` | vLLM-Omni has no parity pin: H3 W3+, LTX-2.5 and ~40 omni-only architectures (the whole TTS family included) cannot be gated against any oracle | feature | | [#466](https://github.com/mudler/vllm.cpp/issues/466) | `GATE-27B-FP8-TOWER-GOLDEN` | The SACRED 27B gate cannot execute the FP8 tower: it pins unsloth@890bdef7 (zero FP8 tensors) while every fp8 lever targets nvidia@0893e160 | bug | | [#470](https://github.com/mudler/vllm.cpp/issues/470) | `GATE-27B-FP8-TOWER-GOLDEN` | `PackedGdnDecodeEnvSelected` mirrors only the ENV; the real predicate also requires `in_proj_qkv_fp8.Empty()`, so the 27B gate throws for the wrong reason on any fp8 tower | bug | | [#476](https://github.com/mudler/vllm.cpp/issues/476) | `GATE-27B-FP8-TOWER-GOLDEN` | The 27n fp8-tower arm cannot see a dequant fallback on `out_proj_fp8` or the four `self_attn.*_proj_fp8`: `GdnFp8InProjDebugStats` counts GDN `in_proj` only, and `6603356a` proves that defect is token-invisible | bug | diff --git a/.agents/specs/upstream-omni-pin.md b/.agents/specs/upstream-omni-pin.md new file mode 100644 index 000000000..c6aacadfa --- /dev/null +++ b/.agents/specs/upstream-omni-pin.md @@ -0,0 +1,171 @@ +# SPEC — pinning vLLM-Omni + +**Row:** `ENG-UPSTREAM-OMNI-PIN` +**Issue:** [#633](https://github.com/mudler/vllm.cpp/issues/633) +**State:** `READY` — protocol change, no product code. + +## Scope + +Make the vLLM-Omni oracle *pinnable*, and state the two rules that follow from +the fact that it is a second pin rather than a second value of the vLLM one. + +**This spec was rewritten after [#650](https://github.com/mudler/vllm.cpp/pull/650) +landed.** Its first draft proposed an `omni-parity-pin` block inside +[upstream-sync.md](../upstream-sync.md). #650 adopted the oracle registry — +one file per oracle under [`.agents/oracles/`](../oracles/), a fenced +`oracle-pin` block, and `scripts/check-oracle-pins.py` enforcing it — which is a +better answer to the same problem and explicitly rejects the shared-surface shape +the first draft had. So the registry is now the home of the pin, and this row no +longer proposes a record format at all. + +In scope: the rules governing how the omni pin and the vLLM parity pin interact; +the answer to whether an omni pin advance re-opens the vLLM-side binding grids; +and the work owed to actually take the pin. + +Out of scope: advancing the vLLM core pin to 0.27.0+; inventorying the omni model +surface; porting any omni architecture; re-stating anything AGENTS.md +§"When vLLM has no implementation" or [`.agents/oracles/README.md`](../oracles/README.md) +already says. + +## Upstream chain + +`vllm-project/vllm-omni` — a separate repository from `vllm-project/vllm`, on its +own release cadence, registry at `vllm_omni/model_executor/models/registry.py`. +Source-audited twice: `a4ea67a2` (v0.26.0) for MiniMax-H3 +([minimax-h3.md](minimax-h3.md) §8.2), and +`bbe6ccc512a404a2df8c977ea29003002f2683e8`, which the Moss-TTS, Qwen3-TTS and +Higgs-Audio rows in [model-matrix.md](../model-matrix.md) anchor to (#609, #610). + +Neither audit is a pin. Both read source, and a source read establishes what +exists, never what runs. + +## Our baseline + +[`.agents/oracles/vllm-omni.md`](../oracles/vllm-omni.md) exists and already +records the state honestly: `pin = UNPINNED`, `gateable = no`, `evidence = #633`. +So the *record* is no longer missing. What is still missing is the pin itself, +and with it any oracle-run gate for MiniMax-H3 W3+, LTX-2.5 and the whole TTS +family including IndexTTS-2.5 ([#634](https://github.com/mudler/vllm.cpp/issues/634)). + +vLLM-Omni requires vLLM **0.27.0+**; our parity pin is `555967922` (0.26.0.dev0). +That conflict is the reason this cannot be handled by advancing one number. + +## Port map + +Nothing is ported. Two record changes, and one deliberate non-change: + +| Change | Where | +|---|---| +| The omni pin's home is the oracle registry, not this file; do not add a second pin block here | [upstream-sync.md](../upstream-sync.md) | +| The two omni rules (below) | [upstream-sync.md](../upstream-sync.md) §Rules | +| **No edit** to `.agents/oracles/vllm-omni.md` | it already says `UNPINNED` / `gateable = no` / `evidence = #633`, which is true | + +**Rule 1 — the two pins may legitimately disagree, and an omni-gated number is +labeled with both.** vLLM-Omni needs 0.27.0+ while the parity pin is 0.26.0.dev0. +Forcing them equal would mean advancing the core pin — touching every gated row +and every binding number — to satisfy a lane that touches none of them. + +**Rule 2 — an omni-gated result is never evidence about the core pin's surface.** +Not in a vLLM-side parity claim, not in a binding grid, not in a +`docs/BENCHMARKS.md` row owned by a core-pinned row. Rule 1 is what makes Rule 2 +necessary: once the two pins can differ, a number carried across is a number +measured against a different dependency tree. + +Per-architecture gateability is NOT restated here: AGENTS.md already requires an +oracle to demonstrably build and run the model, and +[`.agents/oracles/README.md`](../oracles/README.md) already binds `gateable = yes` +to that. The only omni-specific consequence worth recording is that one +`gateable = yes` does not generalize across ~40 architectures, which is why the +demonstration is recorded on the owning row rather than the oracle file. + +## Tests to port + +None from upstream — local protocol machinery, no vLLM analogue, so the mirror +rule does not apply. + +| Assertion | Proves | Owed by | +|---|---|---| +| the `ENG-UPSTREAM-OMNI-PIN` row and the `ENGINE_ROWS` bump arrive together | a count moved for a row, not to silence a failure | this PR (landed) | +| an omni-gated evidence row cited by a core-pinned row goes red | Rule 2 is enforced by a checker, not by prose | W3 | +| a `core_commit_used` value that does not match the `vllm.__version__` in the same interpreter goes red | the isolation condition under Gates actually fires | W4 | + +`check-oracle-pins.py` already covers the block's own shape, and this row does +not duplicate it. + +## Gates + +**Does advancing the omni pin re-open the vLLM-side binding grids? No — +conditional on isolation.** The conditions: + +- the omni oracle lives in its own virtualenv, never the venv the parity pin's + oracle runs from; +- no core-pinned row's evidence cites an omni-gated number (Rule 2); +- the omni install mutates neither the shared checkout, `${VLLM_SOURCE}`, nor the + `vllm-oracle-next` environment the parity pin measures itself from. + +Fail any condition and the environments are entangled: what moved is the +denominator's own dependency tree, so every binding grid measured afterwards is +suspect and the advance is re-validated as a core sync cycle. + +The isolation is asserted, not assumed. The identity check reads +`vllm_omni.__version__` **and** the `vllm.__version__` visible in the same +interpreter. Recording the latter needs a key the `oracle-pin` schema does not +have yet — deliberately not invented here, because the pin is `UNPINNED` and +there is no value to record. Adding `core_commit_used` to the schema, and +teaching `check-oracle-pins.py` about it with its own mutation evidence, is part +of W4 and lands with the measurement. + +## Dependencies + +An eligible host, and nothing else in this repository. The pin values are +**PENDING**: they require installing vLLM-Omni somewhere and measuring +`vllm_omni.__version__` there, and an unavailable value stays `PENDING` rather +than becoming an assumption. + +Exact handoff: create a dedicated venv (never `vllm-oracle-next`), install +vllm-omni at the chosen commit with the vLLM version it requires, record `pin`, +`pin_label`, `pinned_on` and the new `core_commit_used` from the running +interpreter, and prove gateability for at least one architecture by generating +output from it. + +Note for that operator, current as of 2026-08-13: dgx `/home` was reported at 99% +with two reboots that morning under multi-session GPU load. ENOSPC on that host +has previously produced **false policy refusals citing a retired rule**, so a red +result there is evidence about the disk until it is back under 95%. + +## Work breakdown + +| W | Work | Depends on | +|---|---|---| +| W1 | Point `upstream-sync.md` at the registry; land the two omni rules | — | +| W2 | ~~Scope the exhaustive-inventory claim~~ — **superseded**, #609/#610/#650 did it | — | +| W3 | Checker: an omni-gated number cited by a core-pinned row goes red | W1 | +| W4 | Measure the pin; extend the `oracle-pin` schema with `core_commit_used` and teach the checker, with mutation evidence | W1, a host | +| W5 | Prove gateability for one architecture by generating output from it | W4 | + +W1 is this PR. W3-W5 are owed and unclaimed. + +## Risks/decisions + +- **Scope creep into a core pin advance.** vLLM-Omni wanting 0.27.0+ is a + standing pull toward moving the parity pin, which touches every gated row and + every binding number. **Stop** if the work cannot proceed without moving it, + and reconcile that as its own row. +- **Two pins read as one.** The failure Rule 2 exists to prevent. W3 gives it a + test; until then it is prose, and prose drifts. +- **A pin that cannot run anything.** Pinning a commit whose models do not run on + our hardware records a revision and unblocks nothing. `gateable` is what keeps + the pin from being mistaken for capability. +- **This spec was already superseded once, mid-flight.** #650 landed the registry + while this row was open, and the first draft's central proposal became the + wrong shape. Re-verify against `main` before implementing W3-W5; that is the + rule this row has already been caught by once. + +## Now + +`READY`, unclaimed. W1 lands with this spec; W2 is superseded; W3-W5 are not +started and the pin values are PENDING an eligible host. + +Downstream: [#634](https://github.com/mudler/vllm.cpp/issues/634) (IndexTTS-2.5) +is planned behind this row; MiniMax-H3 W3+ and LTX-2.5 carry the same blocker and +unblock together. diff --git a/.agents/upstream-sync.md b/.agents/upstream-sync.md index 148741346..cce831e16 100644 --- a/.agents/upstream-sync.md +++ b/.agents/upstream-sync.md @@ -42,6 +42,16 @@ from a release number. If a future pin is genuinely a released wheel, give the commit its own asserted field first; do not delete the assertion to make the block parse. +**vLLM-Omni's pin does NOT live here.** It is a separate repository, and under +AGENTS.md §"When vLLM has no implementation" every oracle carries its own file: +[`.agents/oracles/vllm-omni.md`](oracles/vllm-omni.md), whose `oracle-pin` block +is the one place its revision is recorded. Do not add a second pin block to this +file; one file per oracle, read by glob, is what keeps a pin from becoming a +surface every change has to write. What belongs HERE is only the part that is +about the relationship between the two, which the oracle file cannot state on its +own: see the omni rules under §Rules, and +[specs/upstream-omni-pin.md](specs/upstream-omni-pin.md) (#633) for why they hold. + **Prior cycle (2026-07-12):** audited target v0.25.0 `702f4814fe54`; report [`sync/2026-07-12-702f481.md`](sync/2026-07-12-702f481.md). The exact 145-commit `e24d1b24..702f481` delta was classified (94 `INVENTORY`, 51 `IGNORE`, no @@ -68,6 +78,10 @@ superseded it at **55/124 axes pass, 69 fail**; the current binding is `9ecd9d0` against. Gaps vs it are normal and tracked in the inventory, not hidden. - **Parity pin (post-MVP)** — one repo-wide vLLM commit. "We have feature X" always means "X as of the pin". Never compare against a moving target. +- **Omni parity pin** — the same idea for `vllm-project/vllm-omni`, recorded in + [`.agents/oracles/vllm-omni.md`](oracles/vllm-omni.md), not here. It is a + second pin rather than a second value of this one: it names the vLLM commit + *it* ran against, which need not be ours. - **Per-file pins** — every ported file's header records the upstream path + the upstream commit it matches. Normally equal to the parity pin; a file may be temporarily ahead (hot-fix port) but never behind without a ledger note. @@ -116,6 +130,14 @@ superseded it at **55/124 axes pass, 69 fail**; the current binding is `9ecd9d0` ## Rules - Ledger and inventory updates are part of the cycle, not optional follow-ups. +- An omni-gated number is labeled with BOTH commits and is never cited in a + vLLM-side parity claim, a binding grid, or a `docs/BENCHMARKS.md` row owned by + a core-pinned row. +- Advancing the omni pin does not re-open the vLLM-side binding grids PROVIDED + the omni oracle is installed in its own virtualenv and touches neither + `${VLLM_SOURCE}` nor the environment the core pin measures itself from. If that + isolation does not hold, the advance is a core sync cycle and is re-validated + as one — the dependency tree under the denominator moved. - Never mix a sync cycle with feature work in the same commit. - If an upstream change conflicts with a recorded deviation (inventory §9), the deviation doc gets updated in the same cycle — deviations must always diff --git a/scripts/check-agent-record.py b/scripts/check-agent-record.py index 8dc1b001c..0e8aeb40a 100644 --- a/scripts/check-agent-record.py +++ b/scripts/check-agent-record.py @@ -411,7 +411,15 @@ # `main` is squash-only, so a justification framed at an intermediate commit would # ship as a comment that is false about the file it sits in. # Bumped for a real new row, never to make a failing state transition pass. -ENGINE_ROWS = 153 +# 154 since 2026-08-13: +`ENG-UPSTREAM-OMNI-PIN` (a parity pin for the separate +# `vllm-project/vllm-omni` repository). A genuinely-new protocol capability, not a +# restatement of the vLLM pin: it is a SECOND pin that may legitimately disagree +# with the first, because vllm-omni requires vLLM 0.27.0+ against our 0.26.0.dev0 +# core pin. Landed the same day as the 153 bump above and merged against it: both +# rows are real and neither replaces the other, which is why this line reads 154 +# rather than restating 153. `READY`, spec `specs/upstream-omni-pin.md`, issue #633. +# Bumped for a real new row, never to make a failing state transition pass. +ENGINE_ROWS = 154 ENGINE_SUMMARY_SECTIONS = ( ("Engine and scheduling", "Engine core and scheduling"), diff --git a/tests/scripts/test_agent_record.py b/tests/scripts/test_agent_record.py index 2c2c86830..549781aae 100644 --- a/tests/scripts/test_agent_record.py +++ b/tests/scripts/test_agent_record.py @@ -269,6 +269,28 @@ def test_serve_recipe_args_row_is_inside_the_engine_ratchet(self) -> None: self.assertEqual(len(recipe), 1) self.assertEqual(recipe[0].path.name, "engine-matrix.md") + def test_omni_pin_row_is_inside_the_engine_ratchet(self) -> None: + """The #633 row and its 153 -> 154 ratchet bump are one semantic change. + + Same shape as the #117 and #606 assertions above, and it carries one + extra hazard worth pinning. This bump COLLIDED: `main` took the constant + 152 -> 153 for `SERVE-RECIPE-ARGS` while the omni-pin branch took the + same 152 -> 153 for its own row, so both sides read 153 and the merge + looked clean. Resolving it by keeping either 153 would have dropped a + real row while leaving the matrix internally consistent, which is + exactly the state no other assertion here can see. Naming BOTH rows is + what makes 154 checkable rather than plausible. + """ + + errors: list[str] = [] + rows, _ = agent_record.check_matrices(errors) + self.assertEqual([error for error in errors if "engine rows" in error], []) + + for item_id in ("ENG-UPSTREAM-OMNI-PIN", "SERVE-RECIPE-ARGS"): + found = [row for row in rows if row.item_id == item_id] + self.assertEqual(len(found), 1, item_id) + self.assertEqual(found[0].path.name, "engine-matrix.md", item_id) + def test_model_row_ratchet_is_load_bearing(self) -> None: """The MODEL row pin must catch a row appearing or vanishing.