merge: L9B into L9C -- the scene row, and an append-only log that really was one

Collapses the L9 stack. The register-gate fix (#597, which closed the reviewer's
prompt_valid_rows finding two-sided) is already folded in below this.

Two conflicts, and they wanted opposite treatments, which is the whole reason
the "union it" reflex is wrong on record files.

.agents/benchmark-record.md IS genuinely append-only: both sides appended
distinct sections at the same anchor, nothing keyed collided. Unioned in
chronological order, older (the 2026-08-11 BENCHMARKS.md overflow move) before
newer (L9c's drain measurement), and verified both survive.

docs/FEATURES.md is the same single keyed row for the THIRD time this campaign,
and again neither side was a superset. L9C knew the render had become a scene at
320x192/25f with the connector wired; L9B knew the coverage had grown to both
VAE encoders and the conditioning items, and that torchao-NVFP4 loads while the
first-party file does not. Composed the facts true of the merged tree.

The row then failed check-public-doc-tables at 221 chars in one cell against the
220 cap -- worth recording that the budget bites at exactly the point a merge
tempts you to concatenate two descriptions instead of writing one.

Issue: #435

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [Claude Code]

Author: mudler

.agents/backend-matrix.md

@@ -1714,6 +1714,7 @@ NOT touch `GatherLogprobs` -- issue #249's unbounded `k` is a separate row.
 | `CLAIM-MUSE-GLIMMER-SPEC` | `MODEL-MM-muse-glimmer-muse-glimmer-for-conditional-generation` (`SPIKE`) | Claude Code (opus-5), helper role | isolated worktree `/home/mudler/_git/vllm.cpp-muse-glimmer`; CPU-only, records+spec+W0 scaffold — NO GPU, weights on the shared NAS | `row/MODEL-MUSE-GLIMMER`, base `origin/main`; PR [#279](https://github.com/mudler/vllm.cpp/pull/279) OPEN | The Muse Glimmer port. Spec `.agents/specs/muse-glimmer.md`, the `MODEL-MM-muse-glimmer-*` matrix row + checklist + rollup, issue-table entry for [#268](https://github.com/mudler/vllm.cpp/issues/268), porting-inventory §9 deviation 16 (the OFF-PIN anchor), `check-agent-record.py` MODEL count, the W0 scaffold (registry + config parse + weight name map + refuse-by-name forward, gate 11/11), `CHECKPOINT_ROOT` in `.env.example` + `.agents/environment.md`. Those helpers ALL LANDED onto the row branch: W1 the 52-layer text forward, W3 the 50-layer perception encoder, W4 the mm wiring (tower to adapter to projection to `perception_emb_norm` to the masked scatter; released-30B accounting 1436/1436), W7 the ATEM reasoning + tool parsers. The branch is no longer "records + spec + W0 scaffold" and its forward no longer refuses. `CLAIM-MUSE-GLIMMER-FIX` (`row/MODEL-MUSE-GLIMMER-FIX`) then closed the PR #279 review findings: three COVERAGE HOLES that mutation testing found green (`perception_emb_norm` untested, the whole non-FusedChain fallback arm unexercised, RoPE theta ungated at a realistic magnitude), the stale "OPEN FINDING" that had disarmed the real-weights accounting assertion, and the false claim in both parser headers that the seam has no `skip_special_tokens` (it does; channel scoping is an OPEN GAP at server defaults, spec §6.7). WHAT IS STILL NOT ESTABLISHED, and must not be implied: the full-depth 52-layer arm never ran (evidence is reduced depth 4/52, 5 prefill argmax positions, no generated tokens), multi-step decode is untested, the perception encoder has no reference check, and nothing has run through the server. **Anchored to the UNMERGED [vllm#51655](https://github.com/vllm-project/vllm/pull/51655) head `075d645af`** on explicit developer direction 2026-08-10: Muse Glimmer exists neither at the pin `555967922` nor on vLLM `main`. **No speed axis is claimable** until #51655 merges and the pin advances — the pinned oracle cannot load the model. | `ACTIVE` | 2026-08-10 |
 | `CLAIM-LORA-RUNTIME-W2` | `LORA-RUNTIME` (moved `ANCHOR-BACKFILL` -> `ACTIVE` in this same change, in the engine matrix and its rollup — W2 of [lora-adapter.md](specs/lora-adapter.md), issue #278) | Claude Code (opus-5), helper role | isolated worktree `/home/mudler/_git/vllm.cpp-lora-w2`; CPU-only `build-cpu` (`-DVLLM_CPP_CUDA=OFF` Release); NO GPU (owned by another session), NO download | `row/LORA-RUNTIME-W2`, PR #282, `origin/main` `5812b8b6` MERGED in (never rebased -- a rebase would need a force-push, and `main` is never force-pushed) | W2 packed + merged/TP layers: `PackedLoRALayerWeights` in `include/vllm/lora/lora_weights.h`, the multi-slice punica ops in `include/vllm/lora/punica.h` + `src/vllm/lora/punica_cpu.cpp`, the NEW `include/vllm/lora/layers.h` + `src/vllm/lora/layers.cpp` wrapped-layer family (replicated/column/row/merged-column/qkv/merged-qkv/variable-slice + the fully-sharded slicing overrides + embedding + logits), the NEW `tests/vllm/lora/test_lora_layers.cpp` port of `tests/lora/test_layers.py`, their two build-list lines, and the `LORA-RUNTIME` records. Does NOT own the fully-sharded APPLY path (needs the TP collectives — it REFUSES at tp_size>1), `pack_moe` (W7), `LoRAConfig` (W5) or `convert_mapping` (W3) | `ACTIVE` | 2026-08-11 — CPU-gated: `test_lora_layers` 16/16 (4,498 assertions) + `test_punica_cpu` 8/8 (149 assertions), clean `-Werror`, full CPU ctest. A fresh review returned FAIL with 2 blocking + 3 major findings and 6 of 9 mutations SURVIVING (two ASan memory-safety bugs among them); all repaired in this same branch, each with a RED-first mutation, and the deferred fully-sharded apply now REFUSES instead of returning a partial delta. ALL SIX previously-surviving mutations were RE-RUN against the repaired head and all six are now CAUGHT (M1/M7 re-run with the newly-unused parameter voided, so the catch is behavioural and not `-Werror=unused-parameter`); the tree was restored byte-for-byte after each. Re-gated after merging `origin/main` `5812b8b6`. |
 | `CLAIM-SPEC-DSPARK` | `SPEC-DSPARK` (`ACTIVE`) | Claude Code (opus-5), helper role | isolated worktree `/home/mudler/_git/vllm.cpp-spec-dspark`; CPU-only so far, NO build, NO GPU, NO download | `row/SPEC-DSPARK`, base `origin/main` `bc6e3d72`; NOT PUSHED, no PR yet (remote step PENDING developer authority) | The DSpark spike, records-only in this commit: NEW `.agents/specs/dspark-spec-decode.md`, the `SPEC-DSPARK` engine-matrix row + section/total counters, the feature-matrix §8 DSpark row, the superseded grounding-note header, this claim, `.agents/NOW.md`, and the `docs/STATUS.md`/`docs/FEATURES.md`/`docs/BENCHMARKS.md` one-liners. **NON-COLLISION:** touches NO `src/`, `include/`, `tests/`, `examples/` or CMake path. Implementation slices W1-W6 follow under this same claim. | `ACTIVE` | 2026-08-09 — spike committed. DSpark = the landed DFlash lane + Markov logit-bias head + sequential block sampling + anchor-as-first-prediction layout + `d2t` reduced vocab + method/config resolution + Speculators-format translation; upstream surface is 1613 lines over 5 files, 3 of them DFlash subclasses. Draft checkpoints exist for both gate models and for the 4B pair the upstream test uses; DeepSeek-V4 DSpark is out of scope (HW-blocked). NEXT: W1 config slice (CPU, RED = `speculative.cpp:44` rejects `"dspark"` today) and R1, prove the pinned oracle `555967922` actually RUNS DSpark (it forces the V2 runner). PENDING developer authority: checkpoint downloads, dgx GPU time, push/draft-PR. |
+| `CLAIM-ENG-RELEASE-WINDOWS` | `ENG-RELEASE-WINDOWS` (`ACTIVE`; W14-W16) | Codex (GPT-5) | `/home/mudler/.cache/sdd/mudler-vllm.cpp/task-4-workflow`; helper worktree under the Windows release operator | `row/ENG-RELEASE-WINDOWS-W15-WORKFLOW`, base `27cf2e6e` | Complete native Windows CPU/Vulkan portability, packaging, ten-tuple workflow, prerelease identity, and truthful records in issue #117's single PR. Excludes Windows CUDA/arm64/installers/WSL/MinGW and any tag or publication before hosted gates | `ACTIVE` | 2026-08-12 — local W14-W16 implementation and mutation gates in progress; native hosted PR CI, exact merged-SHA dry run, v0.0.3-pre.1 prerelease and 32-asset audit pending |
 | `CLAIM-ENG-RELEASE-BINARIES-W1-W13` | `ENG-RELEASE-BINARIES` (`ACTIVE`; complete release matrix) | Codex (GPT-5) | `/home/mudler/_git/vllm.cpp-release-binaries`; inline execution in the existing isolated worktree | `row/ENG-RELEASE-HANDOFF-FLAT`, base `origin/main` `24306364`; follow-up PR pending | Complete W1-W13 contract in one PR; the current follow-up completes the W8/W13 hosted handoff after run `31408404388` built and uploaded all eight required tuples but aggregation failed on nested `download-artifact` extraction. Owns the workflow-wide flat-download invariant, checker and red-first mutation, hosted dry-run verification, and exact release-readiness audit; no backend/package/manifest behavior change. ROCm remains blocked | `ACTIVE` | 2026-08-09 — required W1-W11/W13 implementation complete; hosted ten-SM completion, full eight-tuple dry run, matching-hardware gates, rebase/merge, and tagged publication pending. Update 2026-08-10: all eight bundles now build and upload, while aggregation still fails before verify because `plan/release-plan.json` is nested under the artifact name; W12 optional/non-primary |
 | `CLAIM-ENG-RELEASE-BINARIES-W5` | `ENG-RELEASE-BINARIES` (`ACTIVE`; W5 only) | Codex (GPT-5) | `/home/mudler/_git/vllm.cpp-release-binaries`; CPU/build-time metadata tooling only, no GPU/download/service work | `row/ENG-RELEASE-BINARIES`, base `b38f78a7`, claim commit `29107d0b`, draft PR #141 | W5 implemented: versioned manifest schema + deterministic generator/validator, canonical synthetic CPU/CUDA fixtures, fail-closed mutation tests, release checker/registration and required record/doc checkpoints. Excludes W1-W4, W6-W13, archives, install/package/publish workflows and runtime artifacts | `ACTIVE` | 2026-08-08 — W5 19/19; fresh-review production removals 10/10 killed; accepted release suite 30/30; no archive or real runtime/correctness/performance evidence |
 | `CLAIM-KIMI-LINEAR-W0` | `MODEL-TEXT-kimi-linear-kimi-linear-for-causal-lm` (stays SPIKE — dedicated W0 spike) | Claude Code (opus-4-8) | isolated worktree `.claude/worktrees/agent-a771cc029e6843be0`; CPU-only, records-only — NO build, NO GPU, NO download (two GPU jobs queued ahead; the W0 GPU golden capture is a SEPARATE later step) | branch `worktree-agent-a771cc029e6843be0`, base `origin/main` HEAD `10dd23ee` | The FULL dedicated W0 spike for `KimiLinearForCausalLM` (Kimi-Linear-48B-A3B) per the spike-first protocol, so W1 implementation can start immediately. Owns ONLY: NEW `.agents/specs/kimi-linear.md`, the `MODEL-TEXT-kimi-linear-*` matrix row (Spike link → the dedicated spec + note; STAYS `SPIKE` because it is actively claimed — protocol forbids a claimed row from being `READY`; checklist mark stays `📋`), this claim row + the narrative block below, the roadmap breadth note, `docs/STATUS.md`/`docs/BENCHMARKS.md`/`docs/FEATURES.md` one-liners, the `.agents/NOW.md` live-claim row + stamp, and one `.agents/state.md` entry. **NON-COLLISION:** records-only — touches NO model/kernel/registry/loader source, NO CMake, NO test. Co-owns the Kimi-Linear row with `CLAIM-MLA-DEEPSEEK` (MLA half) + `CLAIM-KDA-KERNEL` (KDA host refs), exactly as the K3 row is co-owned by `CLAIM-KIMI-K3-SCOPE`/`CLAIM-KIMI-K3-W2-W5`. | `DONE` | 2026-08-05 — **W0 DEDICATED SPIKE LANDED (records-only, NOT pushed).** Authoritative `config.json` fetched (27 layers = 20 KDA + 7 NoPE-MLA; 256e/top-8/1-shared sigmoid `noaux_tc` `routed_scaling=2.446` `first_k_dense_replace=1`; `num_nextn_predict_layers=0` ⇒ no MTP); reuse-vs-new map with our `file:line`; HW-fit (FITS one GB10, 91.5 GiB / 0.77× pool — real e2e SACRED gate reachable); W0-W7 breakdown + GPU golden-capture recipe. NET-NEW = KDA device kernel (host refs landed, `CLAIM-KDA-KERNEL`), NoPE-MLA branch, hybrid schedule/het-KV, loader name-map. Record checkers green (`check-model-checklist`, `check-agent-record`, `check-doc-checkpoint`, `check-now-current`). |