From 3ef0c5370fcc0b64a5d9d6171187a5f7e4d9004e Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 04:06:22 +0000 Subject: [PATCH 1/2] record(intake): place five issues filed during the Nemotron campaign (#514, #515, #547, #569, #573) FOLLOWING_AGENTS_PROTOCOL "No work without an open issue" only holds if the issue is reachable from the intake surface. These five were filed and worked but never linked from the roadmap table, so the table understated what is open and none of them was findable from the place the protocol says to look. #569 is the one that matters most and is already fixed on a branch: the Nemotron revision pin was existence-only, so a directory holding a DIFFERENT model resolved as long as a `trees/.json` manifest sat beside it -- and the manifest can be empty. It is placed on the model row because it gates W6's token-exact gate, which is exactly the instrument that cannot see a substituted checkpoint. #515 and #573 are both check-doc-checkpoint creating a shared-write surface, so both go on ENG-RECORD-CONFLICT-SURFACES: the first classifies any root CMakeLists.txt edit as a usage change, the second evaluates its obligation per COMMIT rather than per change, which forced this campaign to squash a branch and lose its RED-first history. #514 is placed on ENG-RELEASE-WINDOWS: both windows-msvc jobs fail on EVERY pull request while main stays green, because those jobs are skipped on push. That makes CI unusable as a signal from the one place it is read. #547 is left unplaced. It is a shared-seam defect -- GB10 reports UnifiedMemory() true, so ReferenceTierEligible(kCUDA) installs the CPU host kernel over cudaMalloc pointers where it needs DeviceMemoryIsHostAddressable() -- and I am not confident which row owns the op-provider seam. The table documents an em dash for exactly that case, and guessing a row would put wrong data in a keyed record. Records only, no product code touched. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index f47a19e36..36debfd59 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -97,6 +97,11 @@ issue is not yet placed. Keyed record: update in place, never append. | [#305](https://github.com/mudler/vllm.cpp/issues/305) | `KERNEL-SSM-MAMBA` | GDN causal-conv: the `conv_state` initial-state read races the final-state write across blocks (`VT_CONV_REG` + exact chunks, both default ON) | bug | | [#496](https://github.com/mudler/vllm.cpp/issues/496) | `KERNEL-SSM-MAMBA` | Mamba2 SSD core is unported: the row carries only the GDN arm, so every hybrid-SSM arch (Nemotron-H/3.5, Granite-4, Zamba2, Falcon-H1, Mamba2) is blocked | feature | | [#517](https://github.com/mudler/vllm.cpp/issues/517) | `MODEL-TEXT-nemotron-h-nemotron-hfor-causal-lm` | Run Nemotron-3.5-Lightning-30B-A3B-NVFP4 e2e: NemotronH hybrid (23 Mamba2 / 6 GQA / 23 non-gated relu2 MoE), first MIXED_PRECISION checkpoint | feature | +| [#514](https://github.com/mudler/vllm.cpp/issues/514) | `ENG-RELEASE-WINDOWS` | `tests/vt/test_backend_cross_device.cpp` uses POSIX `setenv`/`unsetenv`, so both windows-msvc jobs fail on EVERY pr while `main` stays green (they are skipped on push) | bug | +| [#515](https://github.com/mudler/vllm.cpp/issues/515) | `ENG-RECORD-CONFLICT-SURFACES` | check-doc-checkpoint treats every root `CMakeLists.txt` edit as a usage change, so adding a source file demands a `docs/USAGE.md` edit with nothing true to say | bug | +| [#547](https://github.com/mudler/vllm.cpp/issues/547) | — | GB10 reports `UnifiedMemory()` true, so `ReferenceTierEligible(kCUDA)` runs the CPU host kernel over `cudaMalloc` pointers; it needs `DeviceMemoryIsHostAddressable()` | bug | +| [#569](https://github.com/mudler/vllm.cpp/issues/569) | `MODEL-TEXT-nemotron-h-nemotron-hfor-causal-lm` | The Nemotron revision pin was existence-only: a substituted checkpoint still resolved, and W6's token gate cannot see that | bug | +| [#573](https://github.com/mudler/vllm.cpp/issues/573) | `ENG-RECORD-CONFLICT-SURFACES` | check-doc-checkpoint evaluates per COMMIT, so a multi-commit branch must edit `docs/FEATURES.md` repeatedly or squash away its RED-first history | bug | | [#352](https://github.com/mudler/vllm.cpp/issues/352) | `KV-EVENTS` | The batch envelope is never published and `kv_cache_report_mode` does not exist — events can only be observed by reaching into the `BlockPool` | feature | | [#353](https://github.com/mudler/vllm.cpp/issues/353) | `KV-EVENTS` | `KVEventsConfig` has no `__post_init__`: an enabled config with an unset publisher reports `unknown event publisher ''` instead of resolving to zmq | bug | | [#396](https://github.com/mudler/vllm.cpp/issues/396) | `KV-EXTERNAL-CACHE` | `test_lmcache_connector` data race under TSan: `MockLmcacheServer` writes non-atomic `listen_fd_` before joining its accept thread | bug | From 5da9c393043cae9100bdb354a5310dda351a5bd8 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Thu, 13 Aug 2026 04:21:52 +0000 Subject: [PATCH 2/2] record(intake): #512 is a SECOND Windows defect, distinct from #514 FOLLOWING_AGENTS_PROTOCOL Correcting my own characterisation. I described both windows-msvc jobs as failing on #514's POSIX setenv/unsetenv. They do not. windows-msvc-vulkan fails on #514, the C3861 compile error. windows-msvc-cpu fails on #512, a PowerShell workflow defect -- "Cannot bind argument to parameter 'Arguments' because it is an empty array" -- with ZERO compile diagnostics. Verified on the #514 fix branch's own run: the cpu job's failure is byte-identical to the baseline PRs and has nothing to do with the POSIX APIs. That matters because it changes what fixing #514 buys: the vulkan job only. windows-msvc-cpu stays red on every PR until #512 lands too, so CI is not restored as a signal by either fix alone. Records only, no product code touched. Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/roadmap_v1.md | 1 + 1 file changed, 1 insertion(+) diff --git a/.agents/roadmap_v1.md b/.agents/roadmap_v1.md index 36debfd59..bfc3b27ad 100644 --- a/.agents/roadmap_v1.md +++ b/.agents/roadmap_v1.md @@ -97,6 +97,7 @@ issue is not yet placed. Keyed record: update in place, never append. | [#305](https://github.com/mudler/vllm.cpp/issues/305) | `KERNEL-SSM-MAMBA` | GDN causal-conv: the `conv_state` initial-state read races the final-state write across blocks (`VT_CONV_REG` + exact chunks, both default ON) | bug | | [#496](https://github.com/mudler/vllm.cpp/issues/496) | `KERNEL-SSM-MAMBA` | Mamba2 SSD core is unported: the row carries only the GDN arm, so every hybrid-SSM arch (Nemotron-H/3.5, Granite-4, Zamba2, Falcon-H1, Mamba2) is blocked | feature | | [#517](https://github.com/mudler/vllm.cpp/issues/517) | `MODEL-TEXT-nemotron-h-nemotron-hfor-causal-lm` | Run Nemotron-3.5-Lightning-30B-A3B-NVFP4 e2e: NemotronH hybrid (23 Mamba2 / 6 GQA / 23 non-gated relu2 MoE), first MIXED_PRECISION checkpoint | feature | +| [#512](https://github.com/mudler/vllm.cpp/issues/512) | `ENG-RELEASE-WINDOWS` | Windows release runner rejects empty process arguments, so windows-msvc-cpu fails on EVERY pr independently of #514 | bug | | [#514](https://github.com/mudler/vllm.cpp/issues/514) | `ENG-RELEASE-WINDOWS` | `tests/vt/test_backend_cross_device.cpp` uses POSIX `setenv`/`unsetenv`, so both windows-msvc jobs fail on EVERY pr while `main` stays green (they are skipped on push) | bug | | [#515](https://github.com/mudler/vllm.cpp/issues/515) | `ENG-RECORD-CONFLICT-SURFACES` | check-doc-checkpoint treats every root `CMakeLists.txt` edit as a usage change, so adding a source file demands a `docs/USAGE.md` edit with nothing true to say | bug | | [#547](https://github.com/mudler/vllm.cpp/issues/547) | — | GB10 reports `UnifiedMemory()` true, so `ReferenceTierEligible(kCUDA)` runs the CPU host kernel over `cudaMalloc` pointers; it needs `DeviceMemoryIsHostAddressable()` | bug |