record(VT-REFTIER-HOST-ADDRESSABLE): the test cited as pinning CUDA reads the CPU backend

[localai-bot]

A post-hoc review of four merged records pull requests found that #1620 cited tests/vllm/platforms/test_platform.cpp as pinning the CUDA backend's DeviceMemoryIsHostAddressable() default. It does not.

FakeUnifiedAddressablePlatform's device_type() override returns DeviceType::kCUDA, but its backend() override returns vt::GetBackend(DeviceType::kCPU). So the assertion:

CHECK_FALSE(gb10.backend().DeviceMemoryIsHostAddressable());

reads the CPU backend. The fixture's own comment says so. Nothing in the tree pins the real CudaBackend.

What survives, and what does not

The conclusion is still true and no code changes here: CudaBackend declares no override, so it inherits Backend::DeviceMemoryIsHostAddressable's false default in include/vt/backend.h. But it holds by ABSENCE of an override, which is a strictly weaker claim than a pin, and the record read as though a test stood behind it.

No gate could have caught this. The assertion passes, and it passes for a reason unrelated to what it claims to measure — the same shape as a mutation that never applied reading as a passing test.

Why a new row rather than an edit

The wrong citation landed in three places:

• the VT_ADOPT_DEVICE_BYTES row of docs/ENVIRONMENT.md — corrected in this change
• the commit message — immutable, and stands as what was believed at the time
• the #1502 row of .agents/issue-index.md — append-only, and can never be edited

That last one is the whole reason this is a record-only change with a new row. CLAUDE.md makes the index append-only and gates it; the correction cannot be applied in place. Per policy a record-only pull request is correct when the record IS the work — a newly filed gap — which is this case.

Both citations name a ROW, not a line

An earlier revision of this branch cited the wrong claim's home by LINE NUMBER, and that citation was already false. origin/main appended rows above #1502 while this branch was open, so the line that revision named had stopped identifying that row before the branch had shipped even once — verified in the merged tree here, where the cited line holds a different row entirely. A permanent line number into a file nobody may edit would have shipped wrong on its first day, which is exactly the defect this row exists to describe, committed inside the row describing it. It is also #844's own rule: grep the symbol, because this index is append-only and a line number here would be permanent.

Correcting the number to its new value was rejected. A corrected line number is still a line number in an append-only file, and it rots again on the next append above it. So is a count of the rows that pushed it down, which is why neither this body nor the row states one. An earlier draft of both explained the stale line by naming how many lines origin/main had moved #1502, and the next merge falsified that figure exactly as the merge before it had falsified the line — the same defect, one level up, inside the change that exists to condemn it. The argument needs no quantity: rows landed above #1502, so the line stopped naming it. Stated that way it survives the merge this branch still has to do before it lands, and every merge after that. Every reference now names the row instead, and the row's citations into tests/vllm/platforms/test_platform.cpp and include/vt/backend.h name the two overrides, the assertion, and the virtual rather than four line numbers — #844's criterion is the file the number is WRITTEN IN, which is this append-only index and this permanent message, not the file it points at. The docs/ENVIRONMENT.md anchor got the same treatment even though that file is editable and the risk is lower: the row has to say where the claim lives either way, and naming the row costs nothing and cannot go stale.

Owed

Pinning the real CudaBackend needs a CUDA device and stays owed. It is the ## Owed bullet of .agents/specs/vt-reference-tier-host-addressable.md opening "Nothing in the tree pins the real CudaBackend's" — grep that, rather than counting down to a bullet position that the next appended bullet would move, for the reason this whole change is about.

Tracked by #1635, which stays OPEN. This change corrects the citation and records the gap; the pin itself is the other half of what #1635 owes, it needs a CUDA device, and it is not done here. No closing keyword appears anywhere in this body, for any issue, deliberately.

Verification

• agent-preflight.sh on the merged head: every gate ok and zero SKIPPED, including issue-index append-only, doc-checkpoint range, now-current range, commit-trailers and commit-style.
• check-commit-style.py --range and check-commit-trailers.py --filled exit 0 over $(git merge-base origin/main HEAD)..HEAD, and check-issue-index-append-only.py exits 0 over the same base. The base is written as that command rather than as a SHA, because the base moves every time this branch merges origin/main, and a pasted SHA names whichever merge happened to be last. check-agent-record.py takes no base — it reads one tree — and exits 0 on the merged tree.
• The merged index is origin/main's file plus exactly this branch's one row: deleting the #1635 row from it reproduces git show origin/main:.agents/issue-index.md BYTE FOR BYTE. So no existing row is edited or removed, no issue number is duplicated, #1635 appears once, and no conflict marker survives. That byte identity is the check, and it replaces the row-count arithmetic an earlier draft used — another number that was only true of whichever origin/main was merged last. The merge was done LOCALLY because GitHub does not honour the merge=union driver.
• test_cpu_x86_llamacpp_floor fails locally under load, with a failure count that varies run to run at load averages of 174 and 41 — the known contention flake, not reachable from three record and document files.

FOLLOWING_AGENTS_PROTOCOL

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