Skip to content

fix(#595): doc-checkpoint asks whether the registry moved, not whether a file did - #1086

Merged
localai-bot merged 1 commit into
mainfrom
row/DOC-CHECKPOINT-FEATURE-TRIGGER-595
Aug 17, 2026
Merged

fix(#595): doc-checkpoint asks whether the registry moved, not whether a file did#1086
localai-bot merged 1 commit into
mainfrom
row/DOC-CHECKPOINT-FEATURE-TRIGGER-595

Conversation

@localai-bot

Copy link
Copy Markdown
Collaborator

FEATURE_SURFACE_PREFIXES covered all of src/vllm/model_executor/models/, so
any edit to any model translation unit classified as feature_surface and owed
docs/FEATURES.md. That is the classify-by-directory trigger this file's own
header says the 2026-08-11 rewrite removed, still standing for model files:

A one-line compile fix owed three public-doc edits, so this gate produced 16
of the last 20 red CI runs, and it had accreted SIX hardcoded exact-path-set
escape hatches -- one per legitimate change it had blocked.
[...] Editing src/ alone owes nothing.

The cost stopped being hypothetical on 2026-08-16. e34d71379 (#1054) is a
one-line lambda-capture change to models/qwen3_5_weights.cpp that alters no
capability. The gate demanded the surface; the commit answered with prose in
BENCHMARKS, FEATURES and STATUS; that prose crossed the
check-public-doc-tables paragraph budgets; and because that checker also runs
in the pre-push hook, every branch in the repository was blocked from pushing.
That is #1055, re-filed by a second agent as #1062 with #1064 as a duplicate fix
PR, alongside #1058 which is still open. Two shared-file gates in series, each
individually defensible.

What the project supports is what the registry registers, so feature_surface
now keys off a change to the set of REGISTER_VLLM_MODEL(...) entries in the
touched file, read through blob() like the existing measurement_changes.
scripts/check-supported-models.py already gates docs/FEATURES.md against
that same set, so the signal is authoritative rather than newly invented.

This NARROWS a gate, which is the risky direction, so the polarity is pinned by
test rather than asserted: adding an architecture, adding a whole new registered
file, and removing an architecture each still owe docs/FEATURES.md, and the
four .agents/*-matrix.md records keep their path trigger because editing one
IS the claim.

Red before, green after, and mutation-proven. test_doc_checkpoint.py goes 27
-> 32 cases. Before the implementation, test_editing_a_registered_model_owes_nothing
failed with the FEATURES demand. After it, 32 pass. Because the three
still-owes cases were green under the OLD path trigger too, they could not by
themselves show the new trigger works, so registration_changes was mutated to
return []: that fails exactly those three and no others, and restoring returns
32 green.

Does not close #595. A genuine new architecture still writes the shared
docs/FEATURES.md table, so the lock that issue names survives; this removes
the contention for every fix, refactor and port phase that changes no
registration. #515 is the identical shape for CMakeLists.txt -> docs/USAGE.md
and is untouched. Both are recorded under ## Owed in the spec, together with
the class this narrowing gives up: a capability change inside an
already-registered model now goes undemanded.

Refs #595

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]

…r a file did

`FEATURE_SURFACE_PREFIXES` covered all of `src/vllm/model_executor/models/`, so
any edit to any model translation unit classified as `feature_surface` and owed
`docs/FEATURES.md`. That is the classify-by-directory trigger this file's own
header says the 2026-08-11 rewrite removed, still standing for model files:

> A one-line compile fix owed three public-doc edits, so this gate produced 16
> of the last 20 red CI runs, and it had accreted SIX hardcoded exact-path-set
> escape hatches -- one per legitimate change it had blocked.
> [...] Editing src/ alone owes nothing.

The cost stopped being hypothetical on 2026-08-16. `e34d71379` (#1054) is a
one-line lambda-capture change to `models/qwen3_5_weights.cpp` that alters no
capability. The gate demanded the surface; the commit answered with prose in
BENCHMARKS, FEATURES and STATUS; that prose crossed the
`check-public-doc-tables` paragraph budgets; and because that checker also runs
in the pre-push hook, every branch in the repository was blocked from pushing.
That is #1055, re-filed by a second agent as #1062 with #1064 as a duplicate fix
PR, alongside #1058 which is still open. Two shared-file gates in series, each
individually defensible.

What the project supports is what the registry registers, so `feature_surface`
now keys off a change to the set of `REGISTER_VLLM_MODEL(...)` entries in the
touched file, read through `blob()` like the existing `measurement_changes`.
`scripts/check-supported-models.py` already gates `docs/FEATURES.md` against
that same set, so the signal is authoritative rather than newly invented.

This NARROWS a gate, which is the risky direction, so the polarity is pinned by
test rather than asserted: adding an architecture, adding a whole new registered
file, and removing an architecture each still owe `docs/FEATURES.md`, and the
four `.agents/*-matrix.md` records keep their path trigger because editing one
IS the claim.

Red before, green after, and mutation-proven. `test_doc_checkpoint.py` goes 27
-> 32 cases. Before the implementation, `test_editing_a_registered_model_owes_nothing`
failed with the FEATURES demand. After it, 32 pass. Because the three
still-owes cases were green under the OLD path trigger too, they could not by
themselves show the new trigger works, so `registration_changes` was mutated to
return `[]`: that fails exactly those three and no others, and restoring returns
32 green.

Does not close #595. A genuine new architecture still writes the shared
`docs/FEATURES.md` table, so the lock that issue names survives; this removes
the contention for every fix, refactor and port phase that changes no
registration. #515 is the identical shape for `CMakeLists.txt` -> `docs/USAGE.md`
and is untouched. Both are recorded under `## Owed` in the spec, together with
the class this narrowing gives up: a capability change inside an
already-registered model now goes undemanded.

Refs #595

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
@localai-bot
localai-bot force-pushed the row/DOC-CHECKPOINT-FEATURE-TRIGGER-595 branch from 20afdb5 to c7e5e23 Compare August 17, 2026 07:23
@localai-bot
localai-bot merged commit 8fa405b into main Aug 17, 2026
17 of 23 checks passed
localai-bot pushed a commit that referenced this pull request Aug 17, 2026
…ays so

`e34d71379` removed `[&kRequired]` from the `refuse` lambda in
`CheckMoeQuantLayoutSupported` as "the redundant namespace-scope capture". Two
different variables carry that name, and only one of them is namespace-scope:
`kMoeExpertLayoutHelp` (`:894`) is a `static const std::string` and needs no
capture, while `kRequired` (`:929`) is a function-local `const std::string&`
bound to it, is odr-used in the lambda body, and therefore must be captured.
MSVC rejects the result with `error C3493` and `main` has not compiled under it
since.

Naming the namespace-scope constant inside the lambda satisfies both compilers
at once: MSVC has nothing left to capture, and the AppleClang diagnostic #1054
set out to remove stays removed. Reverting to `[&kRequired]` would fix MSVC and
reintroduce that diagnostic. Behavior is unchanged because `kRequired` IS
`kMoeExpertLayoutHelp`; the reference is still used by the other refusal at
`:947`, so it does not become dead.

Verified by CI rather than locally for the compiler that matters: this box has
no MSVC, so `windows-msvc-cpu` and `windows-msvc-vulkan` on this PR are the
gate. `g++ -std=c++20 -fsyntax-only` on the TU returns 0.

Worth recording why this landed green. The guarding gate is a source-TEXT
assertion -- it "rejects `const auto refuse = [&kRequired]` and finds
`const auto refuse = []`" -- which passes whether or not the translation unit
compiles, so it cannot fail on the defect it was written to guard. #1054 also
records that its host had neither CMake nor Clang, so the change was compiled by
neither compiler it concerns. And `windows-msvc-*` are skipped on `main` (#503),
so no baseline existed for the break to regress from and it first surfaced on an
unrelated PR (#983).

An instance of #503, not a new report of it.

Fixes #1068

`documentation-checkpoint` refused an earlier revision of this commit, because
`FEATURE_SURFACE_PREFIXES` covered all of `src/vllm/model_executor/models/` and
so any edit there owed `docs/FEATURES.md` -- for a change that adds no
capability and alters no behavior. That demand is exactly what #1054 answered
with prose, and that prose is what crossed the `check-public-doc-tables` budgets
and blocked every push in the repository (#1055). Rather than feed it again,
the trigger was repaired: `8fa405bb7` (#1086, issue #595) now keys
`feature_surface` off a change to the set of `REGISTER_VLLM_MODEL(...)`
registrations. This commit changes none, so the gate passes it on its own terms
and no exception is claimed.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot added a commit that referenced this pull request Aug 17, 2026
…ays so

`e34d71379` removed `[&kRequired]` from the `refuse` lambda in
`CheckMoeQuantLayoutSupported` as "the redundant namespace-scope capture". Two
different variables carry that name, and only one of them is namespace-scope:
`kMoeExpertLayoutHelp` (`:894`) is a `static const std::string` and needs no
capture, while `kRequired` (`:929`) is a function-local `const std::string&`
bound to it, is odr-used in the lambda body, and therefore must be captured.
MSVC rejects the result with `error C3493` and `main` has not compiled under it
since.

Naming the namespace-scope constant inside the lambda satisfies both compilers
at once: MSVC has nothing left to capture, and the AppleClang diagnostic #1054
set out to remove stays removed. Reverting to `[&kRequired]` would fix MSVC and
reintroduce that diagnostic. Behavior is unchanged because `kRequired` IS
`kMoeExpertLayoutHelp`; the reference is still used by the other refusal at
`:947`, so it does not become dead.

Verified by CI rather than locally for the compiler that matters: this box has
no MSVC, so `windows-msvc-cpu` and `windows-msvc-vulkan` on this PR are the
gate. `g++ -std=c++20 -fsyntax-only` on the TU returns 0.

Worth recording why this landed green. The guarding gate is a source-TEXT
assertion -- it "rejects `const auto refuse = [&kRequired]` and finds
`const auto refuse = []`" -- which passes whether or not the translation unit
compiles, so it cannot fail on the defect it was written to guard. #1054 also
records that its host had neither CMake nor Clang, so the change was compiled by
neither compiler it concerns. And `windows-msvc-*` are skipped on `main` (#503),
so no baseline existed for the break to regress from and it first surfaced on an
unrelated PR (#983).

An instance of #503, not a new report of it.

Fixes #1068

`documentation-checkpoint` refused an earlier revision of this commit, because
`FEATURE_SURFACE_PREFIXES` covered all of `src/vllm/model_executor/models/` and
so any edit there owed `docs/FEATURES.md` -- for a change that adds no
capability and alters no behavior. That demand is exactly what #1054 answered
with prose, and that prose is what crossed the `check-public-doc-tables` budgets
and blocked every push in the repository (#1055). Rather than feed it again,
the trigger was repaired: `8fa405bb7` (#1086, issue #595) now keys
`feature_surface` off a change to the set of `REGISTER_VLLM_MODEL(...)`
registrations. This commit changes none, so the gate passes it on its own terms
and no exception is claimed.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit to bakon11/vllm.cpp that referenced this pull request Aug 17, 2026
… cell whole

Two repairs on top of the mudler#837 dual-slot work. Neither touches its behavior.

`.agents/evidence/` is a path `scripts/check-pr-size.py` cannot classify, so the
gate refused the change outright rather than sizing it: `ERROR: PR size check
could not classify the change: unclassified repository path`. The donor manifest
and the extracted `GetBlas` body move to `.agents/specs/` as
`rocm-gemma4-getblas-dualslot-donor.md` and `.log`, matching `SPEC` and
`SPEC_EVIDENCE` at `check-pr-size.py:188-189`. Teaching the checker a new
`.agents/evidence/` pattern would be a governance-checker change owing its own
spec and mutation evidence, which this is not.

`docs/FEATURES.md` goes back to what main has. The branch had rewritten the
Gemma4 row, which dropped the `VT_GEMMA4_*`/`VT_ATTN_*` env pointer, the
`test_gemma4_rocm_fp8_seams` seam name and the spec link. Restoring those AND
adding the mudler#837 sentence does not fit: `check-public-doc-tables` caps a table
cell at 220 characters and main's cell is already 219, which is presumably why
the row was shortened in the first place. Since `check-doc-checkpoint` does not
ask for a FEATURES edit here -- `src/vt/rocm/` is not a feature surface and no
`REGISTER_VLLM_MODEL` set changed (mudler#595, mudler#1086) -- the row keeps its existing
content and the mudler#837 detail stays where the branch already put it in full, in
`docs/USAGE.md` and the spec.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit to bakon11/vllm.cpp that referenced this pull request Aug 17, 2026
… cell whole

Two repairs on top of the mudler#837 dual-slot work. Neither touches its behavior.

`.agents/evidence/` is a path `scripts/check-pr-size.py` cannot classify, so the
gate refused the change outright rather than sizing it: `ERROR: PR size check
could not classify the change: unclassified repository path`. The donor manifest
and the extracted `GetBlas` body move to `.agents/specs/` as
`rocm-gemma4-getblas-dualslot-donor.md` and `.log`, matching `SPEC` and
`SPEC_EVIDENCE` at `check-pr-size.py:188-189`. Teaching the checker a new
`.agents/evidence/` pattern would be a governance-checker change owing its own
spec and mutation evidence, which this is not.

`docs/FEATURES.md` goes back to what main has. The branch had rewritten the
Gemma4 row, which dropped the `VT_GEMMA4_*`/`VT_ATTN_*` env pointer, the
`test_gemma4_rocm_fp8_seams` seam name and the spec link. Restoring those AND
adding the mudler#837 sentence does not fit: `check-public-doc-tables` caps a table
cell at 220 characters and main's cell is already 219, which is presumably why
the row was shortened in the first place. Since `check-doc-checkpoint` does not
ask for a FEATURES edit here -- `src/vt/rocm/` is not a feature surface and no
`REGISTER_VLLM_MODEL` set changed (mudler#595, mudler#1086) -- the row keeps its existing
content and the mudler#837 detail stays where the branch already put it in full, in
`docs/USAGE.md` and the spec.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit that referenced this pull request Aug 17, 2026
Fixes #837.

## Problem

On a peer-MoE device hop, the single per-thread (TLS) hipBLAS handle is destroyed
on the wrong device, corrupting the `GetBlas` accessor during multi-GPU Gemma-4
MoE serving.

## What changed

- `GetBlas` **dual-slot** TLS keyed by device, plus a host-lifetime seam, so the
  handle is no longer destroyed across the device hop. The production `GetBlas`
  in `src/vt/rocm/rocm_matmul_hipblaslt.hip` is edited in place and routes
  through the new engine, so the change is reached rather than merely present.
- Product-call seam and an exit-77 HIP probe; `StreamIsCapturing` is made
  load-bearing on the product path.
- Spec and identity probe (0→1→0→1) land in the same PR, spec first.

## Verification

Built and smoked on gfx1201, shipping ROCm 7.2.4 (clang `f58b06d`), as the
combined #837+#838+#839 stack on `d1b0ea3a`: gfx1201 build `BUILD_RC=0`, all 30
layers resident and bound, ready in ~20 s; batched-MoE prefill deadlock-free
(T=2012 done, `PEER_ACT` active, no hang, no HIP error); Paris/63 quality PASS.

Stated plainly, because it bounds what this PR alone demonstrates: that smoke
covers the three-PR stack, not this branch in isolation. What *is* isolated here
is the host-side test evidence — 12 cases with real RED mutants (swapped
selector, destroy-on-hop, missing `SetStream`, capture-time `SetDevice`,
forwarded device 0, forwarded null stream), plus a source-invariant case that
reds if the production call site is deleted.

## Maintainer changes on top

Two repairs were applied while landing, neither touching behavior:

- The donor evidence moved from `.agents/evidence/` — a path
  `scripts/check-pr-size.py` cannot classify, so the gate refused the change
  outright — to `.agents/specs/rocm-gemma4-getblas-dualslot-donor.{md,log}`,
  which match `SPEC` and `SPEC_EVIDENCE` at `check-pr-size.py:188-189`.
- `docs/FEATURES.md` is left as `main` has it. The branch had rewritten the
  Gemma4 row, dropping the `VT_GEMMA4_*`/`VT_ATTN_*` env pointer, the
  `test_gemma4_rocm_fp8_seams` seam name and the spec link. Restoring those and
  adding the #837 sentence does not fit — `check-public-doc-tables` caps a cell
  at 220 characters and main's is already 219 — and `check-doc-checkpoint` does
  not ask for a FEATURES edit here, since `src/vt/rocm/` is not a feature
  surface and no `REGISTER_VLLM_MODEL` set changed (#595, #1086). The #837
  detail stays where this branch already put it in full: `docs/USAGE.md` and the
  spec.

The branch was rebuilt by rebase rather than merge so it carries no untrailered
merge commit; all six original commits are preserved with their authorship.

## Known-unrelated CI

`windows-msvc-cpu` and `windows-msvc-vulkan` were red on every open PR from a
break predating this branch (#503). That queue has since been cleared — #968
landed as #983 and #1068 as #1069 — and only #584's runtime crash remains.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit to bakon11/vllm.cpp that referenced this pull request Aug 17, 2026
…ce invariant that survives mudler#1047

Maintainer repairs applied while landing mudler#1046. No product behavior changes.

Donor evidence moves from `.agents/evidence/` -- a path
`scripts/check-pr-size.py` cannot classify, so the gate refused the change
outright -- to `.agents/specs/rocm-gemma4-indexed-max-t-donor.{md,log}`, which
match `SPEC` and `SPEC_EVIDENCE` at `check-pr-size.py:188-189`. The bytes are
unchanged: both slice sha256s still match the manifest table, which is what
that table exists to check.

`docs/FEATURES.md` is left as `main` has it. The branch had rewritten the
Gemma4 row, dropping the spec link, the `VT_GEMMA4_*`/`VT_ATTN_*` env pointer
and the `test_gemma4_rocm_fp8_seams` seam name. Restoring those and adding the
mudler#838 sentence does not fit -- `check-public-doc-tables` caps a cell at 220
characters and main's is already 219 -- and `check-doc-checkpoint` does not ask
for a FEATURES edit here, because `feature_surface` now keys off a change to
the set of `REGISTER_VLLM_MODEL` registrations (mudler#595, mudler#1086) and this branch
changes none. The mudler#838 detail stays where the branch already put it in full:
`docs/USAGE.md`, `docs/ENVIRONMENT.md` and the spec.

The source-invariant case in `test_gemma4_indexed_max_t.cpp` sliced
`rocm_gemma4_experts.hip` between `RetireGemma4Fp8TopKIndexedPeer` and the next
symbol, then asserted `return true;` was absent from the result. That is a
slice of the GAP between two functions, not of the function, so any unrelated
definition added after the closing brace lands inside it. Open PR mudler#1047 inserts
about 160 lines exactly there and carries its own `return true;`, which would
have turned `main` red on `build-test-cpu` after both landed -- this case is
registered unconditionally and reads the source from disk. It now brace-matches
the function's own body, and gains two assertions that the slice is bounded and
that the function does sync the compute stream, so the guarantee is stated more
completely than before rather than relaxed.

Proved by mutation against the real test binary, built standalone and pointed
at a scratch source root: the repaired case reds on a mutant that discards the
sync status and returns unconditional success (3 assertions fail), and stays
green under the mudler#1047-shaped insertion, where the original case reds. The
worktree sources were never mutated; the scratch copy was restored and its
sha256 compared against the tree.

The remaining review findings need a gfx1201 pair and are recorded under
`## Open on gfx1201 hardware` in the row spec instead of being papered over.
The `rw_idx` pooled buffer on the T=1 path contradicts Scope item 3's
hipGraph-stable invariant, and this branch still records no measurement for a
change that flips a product default across T=2..63.

The branch was rebuilt by rebase rather than merge, so it carries no
untrailered merge commit; all six original commits keep their authorship.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit to bakon11/vllm.cpp that referenced this pull request Aug 17, 2026
…ce invariant that survives mudler#1047

Maintainer repairs applied while landing mudler#1046. No product behavior changes.

Donor evidence moves from `.agents/evidence/` -- a path
`scripts/check-pr-size.py` cannot classify, so the gate refused the change
outright -- to `.agents/specs/rocm-gemma4-indexed-max-t-donor.{md,log}`, which
match `SPEC` and `SPEC_EVIDENCE` at `check-pr-size.py:188-189`. The bytes are
unchanged: both slice sha256s still match the manifest table, which is what
that table exists to check.

`docs/FEATURES.md` is left as `main` has it. The branch had rewritten the
Gemma4 row, dropping the spec link, the `VT_GEMMA4_*`/`VT_ATTN_*` env pointer
and the `test_gemma4_rocm_fp8_seams` seam name. Restoring those and adding the
mudler#838 sentence does not fit -- `check-public-doc-tables` caps a cell at 220
characters and main's is already 219 -- and `check-doc-checkpoint` does not ask
for a FEATURES edit here, because `feature_surface` now keys off a change to
the set of `REGISTER_VLLM_MODEL` registrations (mudler#595, mudler#1086) and this branch
changes none. The mudler#838 detail stays where the branch already put it in full:
`docs/USAGE.md`, `docs/ENVIRONMENT.md` and the spec.

The source-invariant case in `test_gemma4_indexed_max_t.cpp` sliced
`rocm_gemma4_experts.hip` between `RetireGemma4Fp8TopKIndexedPeer` and the next
symbol, then asserted `return true;` was absent from the result. That is a
slice of the GAP between two functions, not of the function, so any unrelated
definition added after the closing brace lands inside it. A `git merge-tree` of
this branch with open PR mudler#1047 (`3df512a11`) grows that gap from 16 lines to
176 and puts three `return true;` inside it, which turns `main` red on
`build-test-cpu` once both land -- this case is registered unconditionally and
reads the source from disk. It now brace-matches the function's own body, and
gains two assertions that the slice is bounded and that the function does sync
the compute stream, so the guarantee is stated more completely than before
rather than relaxed.

Proved against the real test binary, built standalone and pointed at a scratch
source root. The repaired case reds on a mutant that discards the sync status
and returns unconditional success (3 assertions fail), and stays green on the
actual merged tree, where the original case reds with 1 failed assertion. The
worktree sources were never mutated; the scratch copy was restored and its
sha256 compared against the tree.

The remaining review findings need a gfx1201 pair and are recorded under
`## Open on gfx1201 hardware` in the row spec instead of being papered over.
The `rw_idx` pooled buffer on the T=1 path contradicts Scope item 3's
hipGraph-stable invariant, and this branch still records no measurement for a
change that flips a product default across T=2..63.

The branch was rebuilt by rebase rather than merge, so it carries no
untrailered merge commit; all six original commits keep their authorship.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
localai-bot pushed a commit to ElderOrb/vllm.cpp that referenced this pull request Aug 17, 2026
…f every test target

Three review repairs on top of the reviewed MSVC subset. No behavior change on any
path that runs today.

`examples/laguna_gen` is reverted to `setenv(..., 0)` and loses the private
`-I ${CMAKE_SOURCE_DIR}/src`. The explicit `getenv(...) == nullptr` guard it
replaced that with was semantically identical, but reaching
`src/vllm/support/platform_compat.h` made laguna_gen the first example to include
a header that exists ONLY under `src/` — every prior breach on its
`scripts/example-abi-allowlist.txt` row is an `include/` header, and the allowlist
calls a private `-I` into `src/` "the deepest breach" where it records one for
`quant_gemm_bench`. `scripts/check-surface-coverage.py` parses `#include` lines and
is blind to `-I` flags, so no gate would have caught it. `laguna-gen` is not among
the seven targets `scripts/build-windows-release.ps1:372-382` builds, so this
bought nothing on Windows.

`vllm_cpp_add_test` no longer grants `${CMAKE_SOURCE_DIR}/src` to every test.
`tests/CMakeLists.txt` already carries 123 explicit per-target grants; a blanket
one in the helper converts that deliberate opt-in into a repo-wide default. The
five suites that actually reach `platform_compat.h` get it by name instead
(`test_capi` already had one). No header name under `tests/` collides with one
under `src/`, so this was not breaking anything — it was simply wider than the
change needs.

`SetEnvVar`'s empty-value divergence is documented rather than silently carried:
`_putenv_s(name, "")` REMOVES the variable where POSIX `setenv(name, "", 1)`
defines it empty. No caller passes an empty value, so normalising would be
unexercised code; the comment records the contract and points at the same rule
`tests/support/test_env.h` already states for the test-side seam.

EXCEPTION, argued rather than waived: `documentation-checkpoint` refuses this
commit because `examples/CMakeLists.txt` is in `USER_USAGE_FILES`, so any edit to
it owes `docs/USAGE.md`. This commit REVERTS an example back to what `main`
already has -- the net diff under `examples/` against `origin/main` is empty --
so there is no user-facing fact for `docs/USAGE.md` to gain, and writing one
would make the page describe a change that no longer exists. This is the shape
recorded as mudler#515: "check-doc-checkpoint treats every root CMakeLists.txt edit as
a usage change, so adding a source file demands a docs/USAGE.md edit that has
nothing true to say". mudler#1086 narrowed the sibling `feature_surface` trigger from a
path to a registration-set change; `USER_USAGE_FILES` still keys off the path.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: ClaudeCode:claude-opus-5 [ClaudeCode]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

doc-checkpoint makes docs/FEATURES.md a LOCK: 2 of 5 concurrent LTX-2.5 PRs conflict there and nowhere else

2 participants