Three prose inaccuracies in the memory-bound work merged as 2f67c9358 (#1331). All low, none affect what the gate detects — the instrument itself was independently verified, including the ASan and TSan lanes. But one of them is a "measured" claim that a later measurement contradicts, which is the shape this project most wants caught.
Found by the scoped re-review of the repairs. Filed rather than fixed in flow because the PR was otherwise PASS and the corrections are documentation-only.
1. The volatile indirection's stated reason does not reproduce
tests/vt/test_ops_matmul_mem.cpp:444-450 (also :66-69, .agents/specs/ltx25-text-linear-mem.md:487-494) says a direct std::malloc(...) in that translation unit "is folded by the compiler and never becomes a reference to the malloc symbol, so it is never wrapped".
The reviewer replaced the volatile call with a direct std::malloc(kProbe) and the gate stayed green at 38/38 — the direct call is wrapped and is counted. The original standalone probe most likely hit GCC's allocation-DCE on an unused allocation; generalising that to "this translation unit" is falsified at the gate's own settings.
No effect on detection — a separate mutation proves the assertion is load-bearing — but the comment explains a design decision with a mechanism that does not hold, and a later reader will believe it.
Fix: either re-derive the real reason the indirection is needed, or drop the claim and keep the indirection as belt-and-braces with an honest note.
2. Miscount inside the correction itself
.agents/specs/ltx25-text-linear-mem.md:224 states that row #1286 at issue-index.md:423 cites cpu_ops.cpp:125 twice. It cites it once (exact count over the row and the whole file).
The substantive point — that the row is append-only and therefore frozen with the wrong anchor, and must not be corrected by appending a duplicate — is right and should stay.
3. Overload count understated
.agents/specs/ltx25-text-linear-mem.md:458 says "all eight aligned new/delete overloads". There are ten aligned overloads (4 new, 6 delete), and the code replaces all ten — the reviewer confirmed all 20 replaceable global allocation functions are covered.
Code is complete; only the prose undercounts.
Why these are worth a follow-up rather than nothing
The gate merged here exists because the tree had no bound on the seam's memory at all, and its first draft read growth_bytes = 0 while passing every assertion. The value of that work is that its claims are checkable. Three claims in it are not accurate, and one is contradicted by measurement — so correcting them protects exactly the property the row was built to establish.
Related: #1230 (tree-wide anchor rot, which item 2 touches), and the observation recorded in #1331's spec that check-symbol-anchors.py's CITATION_RE matches only path::Symbol, leaving path:line anchors an entirely uncovered class.
Three prose inaccuracies in the memory-bound work merged as
2f67c9358(#1331). All low, none affect what the gate detects — the instrument itself was independently verified, including the ASan and TSan lanes. But one of them is a "measured" claim that a later measurement contradicts, which is the shape this project most wants caught.Found by the scoped re-review of the repairs. Filed rather than fixed in flow because the PR was otherwise PASS and the corrections are documentation-only.
1. The
volatileindirection's stated reason does not reproducetests/vt/test_ops_matmul_mem.cpp:444-450(also:66-69,.agents/specs/ltx25-text-linear-mem.md:487-494) says a directstd::malloc(...)in that translation unit "is folded by the compiler and never becomes a reference to themallocsymbol, so it is never wrapped".The reviewer replaced the volatile call with a direct
std::malloc(kProbe)and the gate stayed green at 38/38 — the direct call is wrapped and is counted. The original standalone probe most likely hit GCC's allocation-DCE on an unused allocation; generalising that to "this translation unit" is falsified at the gate's own settings.No effect on detection — a separate mutation proves the assertion is load-bearing — but the comment explains a design decision with a mechanism that does not hold, and a later reader will believe it.
Fix: either re-derive the real reason the indirection is needed, or drop the claim and keep the indirection as belt-and-braces with an honest note.
2. Miscount inside the correction itself
.agents/specs/ltx25-text-linear-mem.md:224states that row#1286atissue-index.md:423citescpu_ops.cpp:125twice. It cites it once (exact count over the row and the whole file).The substantive point — that the row is append-only and therefore frozen with the wrong anchor, and must not be corrected by appending a duplicate — is right and should stay.
3. Overload count understated
.agents/specs/ltx25-text-linear-mem.md:458says "all eight alignednew/deleteoverloads". There are ten aligned overloads (4new, 6delete), and the code replaces all ten — the reviewer confirmed all 20 replaceable global allocation functions are covered.Code is complete; only the prose undercounts.
Why these are worth a follow-up rather than nothing
The gate merged here exists because the tree had no bound on the seam's memory at all, and its first draft read
growth_bytes = 0while passing every assertion. The value of that work is that its claims are checkable. Three claims in it are not accurate, and one is contradicted by measurement — so correcting them protects exactly the property the row was built to establish.Related: #1230 (tree-wide anchor rot, which item 2 touches), and the observation recorded in #1331's spec that
check-symbol-anchors.py'sCITATION_REmatches onlypath::Symbol, leavingpath:lineanchors an entirely uncovered class.