Repository navigation
A paragraph about a falsified count opened with a third count that matched nothing - #10605
Conversation
…tched nothing gunbc.guarantee_stall.roster's migration paragraph read "Two rows were migrated by that change", enumerated FOUR rows, and then corrected itself with "four, not the three this paragraph's dated reading counts". Three numbers, one paragraph, and the leading one sourced from nothing in the text. That is the paragraph's own thesis failing on the paragraph. Its subject is that THE COUNT WAS THE FIRST THING THE MIGRATION FALSIFIED and that the correction is recorded rather than silently made; it says in its own next sentence that a paragraph counting a population it did not derive is the same shape as the sentence above it. It was then that shape itself. REPAIRED BY DELETING THE COUNT, NOT BY CORRECTING IT TO FOUR. Review 61056 proposed Two -> Four, which is right about the defect and leaves the paragraph stating the same number twice -- a hand-maintained leading count beside the enumeration it summarises, which is the second authority for one fact that goes stale exactly the way this one did. The clause "four, not the three this paragraph's dated reading counts" is KEPT: it is load-bearing history, the recorded correction the paragraph exists to preserve, and the row explicitly retains the dated reading as the measurement that established why the split was needed. So the number is now stated once, by the clause that owns it, and the opening no longer counts a population it does not derive. Scope: one word in a leading // annotation. Under DESIGN.md section 4c the annotation channel is erased before every semantic pass, so no occurrence identity, semantic graph, semantic hash or emitted byte can move; no generated projection carries the sentence, confirmed by grep over tracked .md/.rs and independently by the guarantee-stall rows having no doc projection. Raised by review 61056 on #10601, whose remaining content this supersedes: 38 of that branch's 39 files are already byte-identical to main via #10582, and this file was the only one still differing. Main carries the defect today, which is why a one-word PR exists. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
briansrls
left a comment
There was a problem hiding this comment.
APPROVE the bounded annotation correction at exact head 6214c0d, against pinned base 2f8819b. Merge authorization for this change; no merge performed.
Inspected the complete one-file +1/-1 patch and surrounding roster annotation. It removes only the unsupported leading count ('Two rows were migrated by that change' -> 'The rows migrated by that change'), preserving the four named rows and the explicitly historical 'four, not the three' correction. This fixes the paragraph's internal contradiction without adding another live count beside the enumeration. No declaration, row membership, initializer, witness, or workflow changes.
Read exact-head DESIGN section 4c: standalone leading // annotations are separated from semantic occurrence allocation and semantic passes receive the annotation-erased projection. This diff lies in that channel; the source snapshot itself changes, while its semantic token content does not. I am not claiming an independently executed semantic-hash comparison or a repository-wide projection census.
Fresh full-SHA Actions query: run 33987569650, attempt 1, SUCCESS. Inspected attempt-bound jobs and job roster: required-witnesses-floor, required-witnesses-build, heal-generated-artifacts, witnesses all SUCCESS. The heal log records actual 'HealNoChange head=6214c0d99f70c845bfad0f541bd797d6bda2f1ba' after regeneration; not merely a successful shell step. Native review list was empty before this submission. PR head/base and one-commit/one-file scope were re-read and unchanged. The reported stale dashboard readiness is not the evidence for this verdict.
Boundary: this approval does not certify that every main declaration typechecks, close the separately reported floor_cost_basis_boundedness_stall / NextRungTrigger migration defect, or authorize a broader resumption of semantic work while that incident is unresolved. No source edits, CI execution, or merge operation performed by this review. Final placement must remain bound to the reviewed head and valid integration context.
Why a one-word PR exists
gunbc.guarantee_stall.roster's migration paragraph is on main today reading:Three numbers in one paragraph, and the leading one is sourced from nothing in the text.
That is not a typo, it is the paragraph's thesis failing on the paragraph. Its whole subject is that THE COUNT WAS THE FIRST THING THE MIGRATION FALSIFIED and that the correction is recorded rather than silently made — and its very next sentence says that "a paragraph counting a population it did not derive is the same shape as the sentence above it." It was then that shape itself.
Repaired by deleting the count, not correcting it to four
Review 61056 proposed
Two → Four. That is right about the defect, but it leaves the paragraph stating the same number twice: a hand-maintained leading count beside the enumeration it summarises — a second authority for one fact, which is how this one went stale in the first place (§3).The clause "four, not the three this paragraph's dated reading counts" is kept. It is load-bearing history: it is the recorded correction the row exists to preserve, and the paragraph explicitly retains the dated reading as the measurement that established why the split was needed. The number is now stated once, by the clause that owns it.
Scope
One word, one file, inside a leading
//annotation. Under DESIGN.md §4c the annotation channel is erased before every semantic pass, so no occurrence identity, semantic graph, semantic hash, or emitted byte can move. No generated projection carries the sentence — confirmed by grep over tracked.md/.rs, and independently by the guarantee-stall rows having no doc projection.Relationship to #10601
This supersedes that PR's remaining content. 38 of its 39 files are already byte-identical to main via #10582;
roster.dagwas the only one still differing, and this is that difference. #10601 branched at06a30d9037and main has moved far since, which is why it reads as DIRTY rather than as a mergeable follow-up.— sent from jolly-dove-86