From d8f17bf07852a10ea1e94ee983050b58ae19f394 Mon Sep 17 00:00:00 2001 From: Ettore Di Giacinto Date: Sat, 22 Aug 2026 21:59:22 +0000 Subject: [PATCH] fix(records): #1649 has two index rows, and the one its own spec never owned is the one that goes Closes #1731. Closes #1733 as a duplicate of #1731. `main` at `038ff61e5` is RED on `scripts/check-agent-record.py` -- the CI job `agent-record` -- and therefore on every session's preflight and every branch cut from it: ``` ERROR: .agents/issue-index.md: issue #1649 listed twice. Under `merge=union` a duplicate is what two branches appending the same issue look like ``` The checker's message diagnoses its own cause. `:592` was appended by `a7bb3130b` (#1633) under `ENG-HF-MODEL-DOWNLOAD`, the lane that FILED #1649. `:632` was appended by `2f2a70925` (#1701) under `GATE-WINDOWS-PORTABILITY-TARGET-SCOPE`, the lane that FIXED it. Neither lane could see the other's append, and `merge=union` combines two appends silently. ## Which row goes, and on what test Not on which row is older, and not on which reads better. On the rule `AGENTS.md` states under `## Every change starts from an issue`: the issue is linked "in three places that must agree: the index, the row's spec, and the pull request body". Exactly one of the two rows passes that test. * `:632` names `GATE-WINDOWS-PORTABILITY-TARGET-SCOPE`, whose spec `.agents/specs/gate-windows-portability-target-scope.md` reads `Issue: #1649` on its third line, and whose pull request #1701 names #1649 in its title. Three surfaces, all agreeing. * `:592` names `ENG-HF-MODEL-DOWNLOAD`, whose spec `.agents/specs/hf-model-download.md` does not mention #1649 anywhere at all -- not under `## Owed`, not in any other section. `grep -n 1649` over that file returns nothing, against a positive control that the same grep over `gate-windows-portability-target-scope.md` returns eight hits. That row's ownership claim was never corroborated by the spec it pointed at. Two further facts read the same way and are recorded so the choice can be re-checked rather than taken on trust. `:592` asserts in the present tense that "`windows-msvc-cpu` is RED on `main` and on every pull request", which #1701 made false; `:632` is a superset of `:592`'s technical content and adds the fix, a second red `:592` missed, the mutation evidence and the residual. And nothing in the tree anchors a line number into this file: `grep -rn 'issue-index.md#L'` over the repository returns nothing, against a positive control that `.md#L` anchors do exist elsewhere, so no reader and no checker is holding an offset that either deletion would move. MERGING the two rows was rejected. It edits one row and deletes the other, which is a strictly larger violation of the same rule than deleting one, and under `merge=union` an edited line is duplicated rather than merged, so the merged row is the shape most likely to come back as a third `#1649`. ## The dropped row is not lost Its four facts that `:632` does not carry -- the introducing commit `a50c57d69` and the `git log -S` that isolates it, the job that measured the red, the disambiguation from #503, #603 and #965, and how the `/w` was isolated and by which lane -- now live in `.agents/specs/gate-windows-portability-target-scope.md` section 10, which is the spec a reader reaches from the surviving row. The row's verbatim text is this paragraph: | [#1649](https://github.com/mudler/vllm.cpp/issues/1649) | `ENG-HF-MODEL-DOWNLOAD` | **`windows-msvc-cpu` is RED on `main` and on every pull request, and no compilation is ever attempted.** `scripts/build-windows-release.ps1:31` runs `scripts/check-windows-portability.py` before the build and it exits 1 with `CMakeLists.txt: MSVC /W4 /WX policy is negated on the C/C++ compile by /w`. Measured on `9f13751c3` in job [96949585684](https://github.com/mudler/vllm.cpp/actions/runs/32540549699/job/96949585684): the refusal lands seventeen seconds after `Build files have been written to`, and the log carries no `error C####` and no `error LNK####`. NOT [#503](https://github.com/mudler/vllm.cpp/issues/503), [#603](https://github.com/mudler/vllm.cpp/issues/603) or [#965](https://github.com/mudler/vllm.cpp/issues/965), which name a baseline-reporting hole, a POSIX `setenv` and a C4456 shadow respectively -- none of them a checker refusal. Isolated to ONE token: `CMakeLists.txt:2441` gives the FETCHED BoringSSL targets `target_compile_options( PRIVATE $,/w,-w>)`, and dropping only the MSVC arm makes the same checker print `Windows portability contract OK` (probed and restored byte-for-byte against a pre-taken sha256). The `/w` is deliberate and correct -- the comment above it reads "Vendored code is not on this project's -Werror path" -- and what the checker cannot see is SCOPE: it reads `/w` anywhere in `CMakeLists.txt` as a project-wide negation, which is true of a global `add_compile_options(/w)` and false of a `PRIVATE` option on a third-party target. Introduced by [a50c57d69](https://github.com/mudler/vllm.cpp/commit/a50c57d69) ([#1505](https://github.com/mudler/vllm.cpp/issues/1505), row `ENG-HF-MODEL-DOWNLOAD`, [#1280](https://github.com/mudler/vllm.cpp/issues/1280)), which added the static-BoringSSL transport; `git log -S` on that generator expression returns that commit alone. NOT fixed in flow: which side is wrong is a real decision, and teaching the checker scope is a semantic checker change, which `AGENTS.md` `## Changing the rules or a checker` sends down the spec + red-before + fresh-review path. Found while repairing the fresh-review findings on [#1633](https://github.com/mudler/vllm.cpp/pull/1633), which reads the red, is not its cause, and does not touch `CMakeLists.txt`. Spec [`hf-model-download.md`](specs/hf-model-download.md) | bug | ## Exception argued, not waived This deletes a base-reachable row from an append-only file, which is exactly what `scripts/check-issue-index-append-only.py` forbids. That gate is RED on this branch and it is not being weakened. There is no waiver registry here, so the argument lives in this message, attached to the diff it excuses, as `ff264cb82` (#1025) argued the same one for the #995 duplicate. The append-only contract cannot repair a duplicate. Appending a third `#1649` row makes `check-agent-record` angrier, and the file only becomes well-formed by removing one. The two gates are in genuine contradiction on this tree, and that contradiction is the defect, not the repair. The rule is preserved in substance, verified mechanically: * 620 rows before and 620 after: one `#1649` row removed, one `#1733` row appended; the other 619 rows byte-identical and in the same relative order, and every non-row line of the file byte-identical * `#1649` appears exactly once, down from twice * no key added beyond `#1733`, and no key lost * the gate is preflight-only and absent from `.github/`, against a positive control that `check-agent-record` is there, so this costs no CI red * once this lands, a later branch diffs a `main` with no duplicate and sees no removal in its range, so the violation is confined to this commit ## The instrument, and a false measurement it produced #1733 reports that "the repair is measured and it is NOT blocked", quoting `agent record OK: ENGINE=170 MODEL=377 ...` and `OK: issue index append-only` from the same tree. Both cannot be true of one committed tree while the duplicate is base-reachable, and they are not: `scripts/check-issue-index-append-only.py:50-51` diffs `merge-base(origin/main, HEAD)..HEAD`, which reads COMMITS. Measured here at base `038ff61e5`: * deleting `:592` in the WORKING TREE only: `OK: issue index append-only` rc 0, and `git diff --numstat 038ff61e5..HEAD -- .agents/issue-index.md` is EMPTY * committing the byte-identical deletion: the same checker rc 1, with a `removed:` line naming the row An uncommitted mutation therefore looks exactly like a gate that cannot detect it. The `#1733` row appended here records that, because the row cannot be edited afterwards. ## Gates `check-agent-record.py` rc 1 before, rc 0 after, reporting `ENGINE=170 MODEL=377 QUANT=84 KERNEL=57 BACKEND=85 ANCHOR-ROT=37`. `check-conflict-markers.py` 0 findings over 3898 tracked text files, proved discriminating by injecting a marker into a scratch copy of `docs/USAGE.md` (rc 1, one finding) and restoring it against a pre-taken sha256. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code] --- .agents/issue-index.md | 2 +- .../gate-windows-portability-target-scope.md | 60 +++++++++++++++++++ 2 files changed, 61 insertions(+), 1 deletion(-) diff --git a/.agents/issue-index.md b/.agents/issue-index.md index 5cfdde5ca..3368f81e4 100644 --- a/.agents/issue-index.md +++ b/.agents/issue-index.md @@ -589,7 +589,6 @@ rather than merged. `scripts/check-agent-record.py` gates both. | [#1562](https://github.com/mudler/vllm.cpp/issues/1562) | `SPEC-DFLASH2` | **W6's oracle capture harness exists only as PROSE, and the FLASH_ATTN label is a post-hoc relabel of an uncommitted log.** `## Owed` O22 and O23 were written so the next agent would not pay three 51.75 GiB loads again; they describe the hook on `DFlashSpeculator.propose` below the `cg_mode == FULL` branch, the `torch.cuda.is_current_stream_capturing()` delegation, the resolved-backend read-back and the abort-on-zero -- and none of it is in the tree, nor is `w6-relabel.py`, nor any run log. Three consequences visible in the committed evidence: `dflash2_27b_spec_on_flash_attn.json` carries `attention_backend_source: "corrected from the run log by w6-relabel.py; the capture's original value came from VLLM_ATTENTION_BACKEND, which does not exist in this wheel and selected nothing"`, which does not meet the read-back rule O22 itself lays down and cannot be re-derived; the TRITON_ATTN golden's `hook_stats` reads `{propose_calls: 59, skipped_dummy: 1, skipped_capture: 0}` against 55 recorded blocks with contiguous `call` ids 3..57, so `59-1-0 = 58 != 55` and THREE propose calls are unaccounted for (now bounded one-sidedly by the gate and pinned at 3, still unexplained); and `## Owed` O17's discharge has no committed runner and no log, so its peak-RSS pair and its `[SPECTRACE]` lines cannot be re-derived either. Owed: commit the harness, the relabel script and the log, or record that they were lost with the lease | bug | | [#1564](https://github.com/mudler/vllm.cpp/issues/1564) | `SPEC-DFLASH2` | **The two divergent draft blocks were attributed to the SELECTOR's rank contraction, and the block shape argues against it.** W6 measured 45 of 47 draft blocks byte-identical and wrote that both flips are "the lattice op is a REDUCTION over `selector_rank`". Nothing measured that: the golden records `{call, req_row, anchor, drafts}` per block and no values, no logits and no top-2 gap, so it cannot say whether either flip was a near-tie at all, let alone in which reduction. The shape points the other way -- in BOTH blocks only slot 2 changes while slots 3-6 are byte-identical, and `src/vt/cpu/cpu_ops.cpp:3219` has step l read block row `previous`, the slot step l-1 chose, so a flipped CHILD INDEX would move the predecessor row every later step reads and four identical later slots would be four coincidences per block, twice. A different candidate ID at the SAME winning slot, a rank swap in `ComputeCandidates`' top-k over the target head's logits, produces this shape with none. `SPEC-DFLASH` D6 licenses a near-tie envelope; it does not license labelling an unmeasured flip as one nor naming the op. The attribution is WITHDRAWN in the spec and the benchmark record rather than replaced. The instrument is available and cheap: `Qwen3DFlash2Model::ComputeCandidates` already returns `(ids, values)` and so does upstream's `compute_candidates`, so the next capture records the top-2 candidate margin at the flipping slot on both sides. Blocks nothing -- the gate reads 45/47 on a majority bar and both blocks emitted the same target tokens either way | bug | | [#1607](https://github.com/mudler/vllm.cpp/issues/1607) | `SPEC-DFLASH2` | **The DFlash2 startup notice prints TWICE on every draft load, and `docs/USAGE.md` called it one-time.** `CheckDflash2DraftArm` (`src/vllm/entrypoints/model_loader.cpp:502`) ends in an unconditional `std::cerr <<` of the whole notice paragraph with no once-flag, and the loader reaches it TWICE on one load of one `EngineParams`: directly from `FromModelDir` at `:1929`, deliberately placed ahead of every path, config, tokenizer and weight operation so a misclassified draft is caught before a 51.75 GiB target is mapped; and again from `ResolveSpecConfig` at `:1206`, which the `LoadedEngine` constructor runs in its member initializer at `:1538` on all three `new LoadedEngine(...)` returns (`:2172`, `:2341`, `:2359`). The server, the C ABI and the bench client therefore each emit the paragraph twice, on the safetensors arm and the GGUF arm alike. The tree already states that the resolution re-runs (`model_loader.cpp:2313`, `:871-874`); what nothing stated is that the notice re-runs with it. ESTABLISHED STATICALLY, by reading the call graph rather than by executing it -- a runtime confirmation needs a DFlash2 checkpoint and a rebuild of the whole 464-object library. Cosmetic rather than behavioural: nothing is loaded twice and nothing is refused twice, and `CheckDflash2DraftArm` returns early for every non-DFlash2 draft. Found by the THIRD fresh review of `SPEC-DFLASH2` W6 (#1314) and NOT fixed in flow, deliberately: the fix changes the production loader and needs its own red-first test and its own fresh review, while that wave was scoped to prose. `docs/USAGE.md` is corrected in the same change, so the shipped documentation is no longer wrong about the behaviour while this is open. Owed under `## Owed` O25 of [the DFlash2 spec](specs/dflash2-spec-decode.md) | bug | -| [#1649](https://github.com/mudler/vllm.cpp/issues/1649) | `ENG-HF-MODEL-DOWNLOAD` | **`windows-msvc-cpu` is RED on `main` and on every pull request, and no compilation is ever attempted.** `scripts/build-windows-release.ps1:31` runs `scripts/check-windows-portability.py` before the build and it exits 1 with `CMakeLists.txt: MSVC /W4 /WX policy is negated on the C/C++ compile by /w`. Measured on `9f13751c3` in job [96949585684](https://github.com/mudler/vllm.cpp/actions/runs/32540549699/job/96949585684): the refusal lands seventeen seconds after `Build files have been written to`, and the log carries no `error C####` and no `error LNK####`. NOT [#503](https://github.com/mudler/vllm.cpp/issues/503), [#603](https://github.com/mudler/vllm.cpp/issues/603) or [#965](https://github.com/mudler/vllm.cpp/issues/965), which name a baseline-reporting hole, a POSIX `setenv` and a C4456 shadow respectively -- none of them a checker refusal. Isolated to ONE token: `CMakeLists.txt:2441` gives the FETCHED BoringSSL targets `target_compile_options( PRIVATE $,/w,-w>)`, and dropping only the MSVC arm makes the same checker print `Windows portability contract OK` (probed and restored byte-for-byte against a pre-taken sha256). The `/w` is deliberate and correct -- the comment above it reads "Vendored code is not on this project's -Werror path" -- and what the checker cannot see is SCOPE: it reads `/w` anywhere in `CMakeLists.txt` as a project-wide negation, which is true of a global `add_compile_options(/w)` and false of a `PRIVATE` option on a third-party target. Introduced by [a50c57d69](https://github.com/mudler/vllm.cpp/commit/a50c57d69) ([#1505](https://github.com/mudler/vllm.cpp/issues/1505), row `ENG-HF-MODEL-DOWNLOAD`, [#1280](https://github.com/mudler/vllm.cpp/issues/1280)), which added the static-BoringSSL transport; `git log -S` on that generator expression returns that commit alone. NOT fixed in flow: which side is wrong is a real decision, and teaching the checker scope is a semantic checker change, which `AGENTS.md` `## Changing the rules or a checker` sends down the spec + red-before + fresh-review path. Found while repairing the fresh-review findings on [#1633](https://github.com/mudler/vllm.cpp/pull/1633), which reads the red, is not its cause, and does not touch `CMakeLists.txt`. Spec [`hf-model-download.md`](specs/hf-model-download.md) | bug | | [#1654](https://github.com/mudler/vllm.cpp/issues/1654) | `ENG-LOAD-DIRECT-UPLOAD` | **`WeightF32` (`src/vllm/model_executor/models/qwen3_5.cpp:1054-1060`) forms a `const uint16_t*` over an `OwnedTensor`'s bytes, which are a BORROW of the safetensors mapping whenever `BorrowStTensorBytes` took the direct-upload arm.** A safetensors data offset carries no 2-byte alignment guarantee, so the read is undefined behaviour. This is the [#301](https://github.com/mudler/vllm.cpp/issues/301) / [#772](https://github.com/mudler/vllm.cpp/issues/772) class at a site neither reached: both were closed by repairing the sites they had FOUND rather than by giving the borrow a contract, and #772's own title says one of its four was "invisible to UBSan by construction". MEASURED, not read: [#1633](https://github.com/mudler/vllm.cpp/pull/1633)'s loader-seam cases drive `LoadedEngine::FromModelDir` against a synthetic on-disk Qwen3.5 dense target, and while their fixture writer left `8 + header_len` odd the `sanitize-cpu (address,undefined)` lane reported `qwen3_5.cpp:1059:84: runtime error: load of misaligned address ... for type 'const short unsigned int', which requires 2 byte alignment`; that lane builds `-fno-sanitize-recover=all` (`CMakeLists.txt:260`), so the process exits 1 at the first finding. `BorrowStTensorBytes` (`src/vllm/model_executor/models/qwen3_5_weights.cpp:431-461`) already PROMISES what is missing -- it says it will "FAIL CLOSED on anything that is not a whole-range verbatim view" and that "a mismatch can only cost the lever, never correctness" -- and checks the keep-alive, the data pointer, the byte count and the exact span, but never ALIGNMENT, the one mismatch that costs correctness. NOT fixed in flow because the two candidate repairs trade differently and the choice is a load-time measurement this row owns: refusing the borrow on an unaligned source honours the stated contract but silently disables the direct-upload lever for a whole checkpoint, while reading through `vt::LoadUnaligned` keeps the lever and leaves the next such site to be found the same way. Reachability from a PUBLISHED checkpoint is not claimed: the reference `safetensors` writer pads its header, and nothing here measures what every producer on the hub does; what is measured is that the loader accepts an unpadded producer and then reads it as UB. #1633 pads its own fixture header instead, and says so at the writer. Spec [`load-direct-upload.md`](specs/load-direct-upload.md) | bug | | [#1646](https://github.com/mudler/vllm.cpp/issues/1646) | `SPEC-DFLASH2` | **`tests/tools/` held 351 cases across 20 suites and NO lane ran one of them.** Measured at `e100e64e1` on a clean worktree: `python3 -m unittest discover -s tests/tools -t . -p "test_*.py"` reports `Ran 351 tests in 21.067s / OK`, standard library only, zero skips, no GPU and no vLLM wheel — and no workflow, no CTest registration and no `scripts/agent-preflight.sh` line executed it. The only `unittest` invocations in `.github/workflows/` are four `tests.scripts.*` modules; preflight's `SUITES` loop runs `tests/scripts/$suite.py` only; a tree-wide grep for `tests.tools` outside the directory returns prose in `.agents/` and four unrelated path constants in `scripts/check-snapshot-pins.py`. Worse than untested: the suites are QUOTED AS EVIDENCE — `.agents/parity-ledger.md` carries "all tools 34/34" on five `SERVE-GATE-ONLINE` rows and `.agents/upstream-sync.md:38` records "34 of the 233 `tests/tools` cases" — so they read as gating in every document that cites them while being reachable only by an agent who typed the command. What they cover is not marginal: `test_oracle_pin.py` is the [#520](https://github.com/mudler/vllm.cpp/issues/520) oracle-identity assertion, `test_gpu_clock_state.py` is the [#543](https://github.com/mudler/vllm.cpp/issues/543) clock attribution every ratio rests on. FIXED IN FLOW by one preflight line and one CI step, DISCOVERED rather than enumerated because an enumerated list is a shared file every new suite must edit, which is the record-lock shape `AGENTS.md` §Records forbids. Found while wiring [#1562](https://github.com/mudler/vllm.cpp/issues/1562)'s refusal gate, which would otherwise have landed dead; not owned by that row's subject matter | bug | | [#1648](https://github.com/mudler/vllm.cpp/issues/1648) | `SPEC-DFLASH2` | **[#1646](https://github.com/mudler/vllm.cpp/issues/1646)'s central claim is FALSE: `tests/tools/` HAS a CTest registration and CI has been running it on every pull request.** #1646's row says the 351 cases across 20 suites had "no workflow, no CTest registration and no `scripts/agent-preflight.sh` line" executing them. `tests/CMakeLists.txt:12-16` registers the target `test_serve_low_tools` running exactly `python3 -m unittest discover -s tests/tools -p "test_*.py"` with `PYTHONPATH` set, and has since `e58858a91`; `CMakeLists.txt:2728` makes it live and `.github/workflows/ci.yml:1057` runs `ctest --test-dir build` inside `build-test-cpu` on every `pull_request`. Executing that command on the branch head reports `Ran 414 tests / OK` in 20.2 s. The error came from grepping `tests.tools`, the DOTTED module path, while CMake and the workflow spell it `tests/tools` -- a null grep proving the terms wrong rather than the thing absent. Three consequences: `.agents/parity-ledger.md`'s `all tools` citations and `.agents/upstream-sync.md:38` were citing a LIVE suite, not a dead one; the NARROW gap was real and its fix stands, because preflight genuinely ran none of them, and the CI step's remaining value is a Python-only verdict in ~21 s under its own name rather than behind a C++ build; and the DISCOVERY mechanism #1646 chose is correct and unaffected. TWO FURTHER ERRORS in the same immutable row, recorded here because it cannot be edited: "pinned at 3" pins nothing, since `hook_reasons` asserts `recorded_blocks <= propose_calls - skipped`, which holds for any residual at or above 0; and "all tools 34/34 on five rows" does not occur -- the ledger reads `35/35` on two rows and `164/164` on eleven, and 34 is `upstream-sync.md`'s count of cases that go RED under a released-wheel version shape, a different quantity from a pass count. The #1646 row is append-only and STANDS AS WRITTEN; this issue and `## Owed` O27 of [the DFlash2 spec](specs/dflash2-spec-decode.md) are the authority over it, as this campaign handled the #1538 row. Prose corrected in `.github/workflows/ci.yml` and `scripts/agent-preflight.sh` in the same change. Found by the fresh review of the SPEC-DFLASH2 speed harness ([#1562](https://github.com/mudler/vllm.cpp/issues/1562)) | bug | @@ -636,3 +635,4 @@ rather than merged. `scripts/check-agent-record.py` gates both. | [#1721](https://github.com/mudler/vllm.cpp/issues/1721) | `ENV-GPU-LEASE-METHODOLOGY` | `git stash` is repo-global across linked worktrees, so a bare `git stash pop` in one worktree consumes whatever sits at `stash@{0}` — which on this checkout belonged to another row. `git stash` on an already-clean tree saves nothing and prints nothing, but the paired `pop` still fires: it pulled `row/ENG-PUBLIC-DOC-PROJECTIONS`'s 56-file entry into an unrelated worktree, and only survived because the conflict made git KEEP the entry. 14 entries are on the stack, some labelled recovery. Same shape as #777 and #998: a resource that looks per-worktree and is per-repository | bug | | [#1725](https://github.com/mudler/vllm.cpp/issues/1725) | `BACKEND-CUDA-SM110` | `kMatmulFp8Cutlass` and `kMatmulFp8BlockScaled` fall through to the portable CPU tier and SEGFAULT on sm_110 (`test_ops_fp8_cutlass:191`, `test_ops_matmul_fp8_block_cuda:345`, measured at `0764ded2b`). The sm_110 baseline attributed them to [#960](https://github.com/mudler/vllm.cpp/issues/960), which was CLOSED COMPLETED three days earlier by `d607fec4c` -- that fix covered `QuantFp8Static` only, while these two ops are registered from TUs `CMakeLists.txt:1790-1791` builds solely for `VT_CUTLASS_FP8_ARCHS`. `cuda_matmul_fp8_block_cutlass.cu:56-58` asserts they refuse by name instead, which the measurement contradicts; `cffe59b02` has since rewritten that dispatch, and no CI lane can see either way because `cutlass-fp8` is ENABLED on the GB10 gate host | bug | | [#1731](https://github.com/mudler/vllm.cpp/issues/1731) | `ENG-RECORD-CONFLICT-SURFACES` | `check-agent-record` is RED on `main`: `#1649` is listed twice in `.agents/issue-index.md`, at `:592` (added by `a7bb3130b`, the lane that FILED it) and `:632` (added by `2f2a70925`, the lane that FIXED it). Neither is wrong and neither could see the other -- `merge=union` combines two appends silently, so a duplicate is the ordinary outcome when filing and fixing happen on different branches, and the checker only notices once both have landed on main, where every later PR inherits the red. Not repaired in flow: the index preamble forbids editing or deleting a row, and the two bodies carry different facts (`:632` has a second red and the mutation evidence, `:592` has the attribution to `a50c57d69`), so choosing which survives is a judgement | bug | +| [#1733](https://github.com/mudler/vllm.cpp/issues/1733) | `ENG-RECORD-CONFLICT-SURFACES` | CLOSED as a duplicate of [#1731](https://github.com/mudler/vllm.cpp/issues/1731), filed seventeen minutes after it against the same red, and recorded here rather than left unindexed because its one MEASURED claim is FALSE and an append-only row cannot be corrected in place later. Both issues report that `.agents/issue-index.md` lists [#1649](https://github.com/mudler/vllm.cpp/issues/1649) twice on `main` at `038ff61e5`, at `:592` from `a7bb3130b` (the lane that FILED it) and at `:632` from `2f2a70925` (the lane that FIXED it). #1731 is the earlier filing, already carries an index row, and is the record. #1733 adds one thing #1731 does not, and it is wrong: "the repair is measured and it is NOT blocked", on the evidence that removing one of the two rows in a worktree and running both checkers gives `agent record OK: ENGINE=170 MODEL=377 ...` and `OK: issue index append-only`. The second half is an artefact of the instrument. `scripts/check-issue-index-append-only.py:50-51` diffs `merge-base(origin/main, HEAD)..HEAD`, which reads COMMITS, so an UNCOMMITTED deletion is invisible to it. Measured on `row/FIX-ISSUE-INDEX-1649-DUP` at base `038ff61e5`: deleting `:592` in the WORKING TREE alone returns `OK: issue index append-only` at rc 0 with `git diff --numstat 038ff61e5..HEAD -- .agents/issue-index.md` EMPTY, and committing the byte-identical deletion turns the same checker rc 1 with a `removed:` line naming the row. #1733's own quoted `agent record OK: ENGINE=170 MODEL=377` is the tell, because that is the working-tree reading and the committed tree cannot produce it while the duplicate stands. So the duplicate IS base-reachable, the two checkers ARE in genuine contradiction on this tree, and the repair is the argued exception #1731's row anticipated rather than the free edit #1733 reported | bug | diff --git a/.agents/specs/gate-windows-portability-target-scope.md b/.agents/specs/gate-windows-portability-target-scope.md index 871b9de94..4c7ccbf94 100644 --- a/.agents/specs/gate-windows-portability-target-scope.md +++ b/.agents/specs/gate-windows-portability-target-scope.md @@ -138,3 +138,63 @@ pass the compile itself is unproven here and is #503/#603/#965 territory. ## 9. Outcome Recorded on landing. + +## 10. The index row this row now owns alone + +`.agents/issue-index.md` carried [#1649](https://github.com/mudler/vllm.cpp/issues/1649) +TWICE on `main` at `038ff61e5`, so `scripts/check-agent-record.py` exited 1 for +every session and every pull request cut from it: + +``` +ERROR: .agents/issue-index.md: issue #1649 listed twice. Under `merge=union` a +duplicate is what two branches appending the same issue look like +``` + +`:592` was appended by `a7bb3130b` (PR [#1633](https://github.com/mudler/vllm.cpp/pull/1633)) +under `ENG-HF-MODEL-DOWNLOAD`, the lane that FILED the issue. `:632` was +appended by `2f2a70925` (PR [#1701](https://github.com/mudler/vllm.cpp/pull/1701)) +under this row, the lane that FIXED it. Neither lane could see the other's +append, and `merge=union` combines two appends silently. + +`:592` was dropped and this row's `:632` kept. The test is the one `AGENTS.md` +states under `## Every change starts from an issue`: the issue is linked "in +three places that must agree: the index, the row's spec, and the pull request +body". Only one of the two rows passes it. This spec names `Issue: #1649` on +its third line and PR #1701 names #1649 in its title, so `:632`'s ownership +claim is corroborated on all three surfaces. `.agents/specs/hf-model-download.md` +mentions #1649 nowhere at all — it is absent from that spec's `## Owed` and from +every other section — so `:592`'s ownership claim was never corroborated by the +spec it pointed at. Keeping `:592` would have left the index asserting an +ownership the tree does not support; keeping `:632` leaves the assertion true. + +`:592` carried four facts `:632` does not, and they are recorded here so that +dropping the row costs the reader nothing: + +1. **Where the `/w` came from.** `a50c57d69` + (PR [#1505](https://github.com/mudler/vllm.cpp/pull/1505), row + `ENG-HF-MODEL-DOWNLOAD`, [#1280](https://github.com/mudler/vllm.cpp/issues/1280)) + added the static-BoringSSL transport, and with it the + `$,/w,-w>` generator expression that §2 quotes. + `git log -S` on that expression returns that commit alone. +2. **The run that measured the red.** `9f13751c3`, PR #1633's head, in job + [96949585684](https://github.com/mudler/vllm.cpp/actions/runs/32540549699/job/96949585684). + The refusal lands seventeen seconds after `Build files have been written to`, + and the job log carries no `error C####` and no `error LNK####`, which is how + the filing established that no translation unit is ever read. +3. **What the red is NOT.** Not + [#503](https://github.com/mudler/vllm.cpp/issues/503), a baseline-reporting + hole; not [#603](https://github.com/mudler/vllm.cpp/issues/603), a POSIX + `setenv` in `test_backend_cross_device.cpp`; and not + [#965](https://github.com/mudler/vllm.cpp/issues/965), a C4456 shadow in + `server_main.cpp`. None of the three is a checker refusal, and none names + this string. §8 already sends the compile itself back to those three; this + is the separation that put the refusal outside them. +4. **How it was isolated, and by whom.** Dropping only the MSVC arm of that + generator expression made the same checker print `Windows portability + contract OK`, and the tree was restored byte-for-byte against a pre-taken + sha256. Found while repairing the fresh-review findings on PR #1633, which + reads the red, is not its cause, and does not touch `CMakeLists.txt`. + +The dropped row's verbatim text is in the body of the commit that dropped it. +`git log -S'#1649' -- .agents/issue-index.md` finds that commit, and +`git show ` prints both the argument and the row.