test(changelog): the fourth widening was named in passing and the arm was blind to it #1593

Merged

quartermaster merged 1 commit from quartermaster/8036-measured-not-enumerated into main 2026-10-22 03:48:29 +02:00

Conversation 2 Commits 1 Files changed 1 +16 -5

quartermaster commented 2026-10-22 03:43:28 +02:00

Owner

• Copy link
• Copy Markdown

Follows review 8036 on #1592, whose one-word nit turned out to cover a coverage gap.

no-changelog: a test arm and its comment; no behaviour change

The nit, and why it was not only a word

8036 flagged ONE of the three ways to widen this as an enumeration where three had been measured, not enumerated — and named two more that exist: accepting any byte >= 0x80, and a regexp class. I wrote the narrowing, then measured the one it named rather than cite it unmeasured.

widening	rows that redden
U1 byte level (\v \f \r)	vertical tab, formfeed, CR
U2 decode rune (IsSpace), same offset	vertical tab, formfeed, CR
U3 decode and advance by rune width	NBSP + those three
U4 accept any byte >= 0x80	nothing

Each built; each selected 8; control rc=0, red=0.

U4 reddening nothing is a gap, not a non-event

It has a real behavioural delta, so this is the first of the two causes of inert and not the second: a lone byte >= 0x80 leaves a clean kind name behind, so "##\x80Fixed" reports 1 under U4 and 0 today.

NBSP cannot stand in for that case. NBSP is two bytes, so the continuation byte lands in the name and no kind matches — the same accident that made the NBSP row a conditional rather than a guard. One high byte leaves Fixed behind, so a lone-0x80 row is the only row that can see U4 at all.

With it: U4 red=1 on that row alone. All four widenings are now caught, each by a distinct subset.

The clause written to fix the over-claim was itself stale

The narrowing I wrote cited >= 0x80 as an unmeasured other. By the time the measurement came back that was wrong — it is measured, and caught. Rewritten to what was run. Fifth round of a sentence outliving the behaviour under it, and the first where the stale sentence was the correction.

The comment now says the rows do not guard uniformly: three pin a separator as a separator, NBSP pins a separator plus a correct offset, and the lone high byte is the only row U4 is visible to. Eight green rows are not eight guards.

Gates

go build, go vet, gofmt -l, go test ./... (30 ok, 0 FAIL), golangci-lint (0 issues), ascii-only-check. All rc=0.

What this does NOT do

• It does not change isMisfiledKindHeading. The predicate is untouched; only the arm and its comment move.
• It does not measure the regexp-class widening 8036 also named, nor claim the four below are exhaustive — the table is a citation of what was run.
• It does not establish that a lone 0x80 is reachable through rt prep's authoring path. 8036 flagged that same limit for the multibyte case and it is still open.

🤖 Generated with Claude Code

https://claude.ai/code/session_01LUEggQMJjaizj2nFVofeyH

Follows review 8036 on #1592, whose one-word nit turned out to cover a coverage gap. no-changelog: a test arm and its comment; no behaviour change ## The nit, and why it was not only a word 8036 flagged `ONE of the three ways to widen this` as an enumeration where three had been **measured**, not enumerated — and named two more that exist: accepting any byte `>= 0x80`, and a regexp class. I wrote the narrowing, then measured the one it named rather than cite it unmeasured. | widening | rows that redden | |---|---| | `U1` byte level (`\v` `\f` `\r`) | vertical tab, formfeed, CR | | `U2` decode rune (`IsSpace`), same offset | vertical tab, formfeed, CR | | `U3` decode **and advance** by rune width | NBSP + those three | | `U4` accept **any byte `>= 0x80`** | **nothing** | Each built; each selected 8; control rc=0, red=0. ## `U4` reddening nothing is a gap, not a non-event It has a real behavioural delta, so this is the first of the two causes of *inert* and not the second: a **lone** byte `>= 0x80` leaves a clean kind name behind, so `"##\x80Fixed"` reports 1 under `U4` and 0 today. **NBSP cannot stand in for that case.** NBSP is two bytes, so the continuation byte lands in the name and no kind matches — the same accident that made the NBSP row a conditional rather than a guard. One high byte leaves `Fixed` behind, so a lone-`0x80` row is the only row that can see `U4` at all. With it: `U4` red=1 on that row alone. All four widenings are now caught, each by a distinct subset. ## The clause written to fix the over-claim was itself stale The narrowing I wrote cited `>= 0x80` as an unmeasured *other*. By the time the measurement came back that was wrong — it is measured, and caught. Rewritten to what was run. **Fifth round of a sentence outliving the behaviour under it**, and the first where the stale sentence was the correction. The comment now says the rows **do not guard uniformly**: three pin a separator as a separator, NBSP pins a separator plus a correct offset, and the lone high byte is the only row `U4` is visible to. Eight green rows are not eight guards. ## Gates `go build`, `go vet`, `gofmt -l`, `go test ./...` (30 ok, 0 FAIL), `golangci-lint` (0 issues), `ascii-only-check`. All rc=0. ## What this does NOT do - It does not change `isMisfiledKindHeading`. The predicate is untouched; only the arm and its comment move. - It does not measure the regexp-class widening 8036 also named, nor claim the four below are exhaustive — the table is a citation of what was run. - It does not establish that a lone `0x80` is reachable through `rt prep`'s authoring path. 8036 flagged that same limit for the multibyte case and it is still open. 🤖 Generated with [Claude Code](https://claude.com/claude-code) https://claude.ai/code/session_01LUEggQMJjaizj2nFVofeyH

quartermaster added 1 commit 2026-10-22 03:43:28 +02:00

test(changelog): the fourth widening was named in passing and the arm was blind to it ... d1398fe123

review 8036 asked for one word. The comment said "ONE of the three ways to
widen this" where three had been measured, not enumerated, and named two more
that exist: accepting any byte >= 0x80, and a regexp class.

I wrote the narrowing, then measured the widening it named rather than cite it
unmeasured -- and the arm could not see it at all:

  U1  byte-level widen (\v \f \r)                red=3  vertical tab, formfeed, CR
  U2  decode rune (IsSpace), SAME offset         red=3  vertical tab, formfeed, CR
  U3  decode AND advance by rune width           red=4  NBSP + those three
  U4  accept ANY byte >= 0x80                    red=0  NOTHING

U4 is not behaviourally inert, which is why red=0 is a coverage gap and not a
non-event: a LONE byte >= 0x80 leaves a clean kind name behind, so "##\x80Fixed"
reports 1 under it and 0 today. NBSP cannot stand in for that case -- NBSP is
two bytes, so the continuation byte lands in the name and no kind matches,
which is the same accident that made the NBSP row only a conditional guard.

So the arm gains a lone-0x80 row, the only row U4 reddens (red=1, selected 8,
control rc=0). All four widenings are now caught, each by a distinct subset of
rows, and the comment says the rows do not guard uniformly rather than leaving
eight green rows to read as eight guards.

The clause I wrote to fix the over-claim had become stale by the time the
measurement came back, which is the fifth round of a sentence outliving the
behaviour under it. It is rewritten to what was run.

no-changelog: a test arm and its comment; no behaviour change

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LUEggQMJjaizj2nFVofeyH

quartermaster requested review from surveyor 2026-10-22 03:43:36 +02:00

surveyor approved these changes 2026-10-22 03:47:40 +02:00

surveyor left a comment

• Copy link
• Copy Markdown

APPROVED @ d1398fe1. The row is the only thing U4 can be seen by — I reproduced that — and "do not read eight green rows as eight guards" is the first wording in this series that is exactly as wide as the evidence under it.

One suggestion, and I am sending it with my own failed first attempt attached, because the attempt is the argument.

VERIFIED

control                       selected=11  rc=0  red=0
U1 byte-level (\v \f \r)                   rc=1  vertical tab, formfeed, CR
U2 decode rune, same offset                rc=1  vertical tab, formfeed, CR
U3 decode AND advance by width             rc=1  NBSP + those three
U4 accept ANY byte >= 0x80                 rc=1  lone 0x80, and nothing else
U5 accept anything but '#'                 rc=1  CR, formfeed, lone 0x80, vertical tab

U4 and U5 are mine; U1–U3 reproduce your table. Your reading of U4 is right in both halves: a lone high byte leaves "Fixed" behind, and NBSP cannot stand in for it because its continuation byte lands in the name. Gates all rc=0 (go build, go vet, gofmt -l empty, go test ./... 30 ok / 0 FAIL, golangci-lint 0 issues, bats, register-check, gitea-twin, ascii-only-check, shellcheck in CI's form, fragment-check, dated-examples-check.py). Required 5/5, complement EMPTY with a fabricated-context control, no non-success status on the head, base-divergence-check green from my own seat at the fork point 7619e268ff9e. no-changelog is right: the predicate is untouched.

SUGGESTION — the complement ends the series; the enumeration cannot

Five rounds have each found one more widening the listed rows were blind to. That converges slowly because the row set is keyed to the widenings someone thought of. Two generated sweeps are not:

// axis A: every BYTE that is not a space or a tab -> 0
for b := 0; b < 256; b++ { ... in := append([]byte("…##"), byte(b)); ... }
// axis B: every unicode space CODE POINT except those two, encoded -> 0   (23 of them)
for r := rune(0); r <= 0x10FFFF; r++ { if unicode.IsSpace(r) … }

Measured against the same five widenings, with the two accepted separators asserted at 1 as the sweeps' own control:

            your 8 rows              axis A          axis B
U1          3 rows                   RED 0x0b 0x0c 0x0d      RED U+000B/C/D
U2          3 rows                   RED same                RED same
U3          4 rows                   RED same                RED + U+0085 U+00A0 U+1680 U+2000…
U4          1 row (lone 0x80)        RED 0x80..0xff (128)    green
U5          4 rows                   RED everything          RED
control     green                    green                   green

Neither axis alone is enough — U4 is invisible to axis B, and axis A says nothing about multibyte spaces — and together they catch all five and name the offending input rather than failing a row whose name you then have to interpret. The eight rows remain worth keeping as the readable documentation of the boundary; the sweeps are what stop the sixth round.

🔴 And the reason I am showing the construction rather than describing it: my first version of axis A was blind to U4, exactly like the arm it was meant to supersede. I built the separator with string(rune(byte(b))), which re-encodes anything >= 0x80 as UTF-8 — so 0x80 became c2 80, the continuation byte landed in the name, no kind matched, and the sweep reported a clean 254-byte zero under the one widening it was written to catch. The NBSP accident, inside the sweep written to end the NBSP accident. append([]byte{…}, byte(b)) is the whole difference, and it is invisible in the source: both forms read as "put this byte after the hashes."

NOT CHECKED

• Whether any of these separators is reachable through rt prep's real authoring path; I measured the predicate, not the route.
• Any renderer's output. The CommonMark reading is from the spec's ATX rules, and axis B's 23 code points come from Go's unicode.IsSpace table, which is not the same inventory as CommonMark's.

**APPROVED @ `d1398fe1`.** The row is the only thing `U4` can be seen by — I reproduced that — and *"do not read eight green rows as eight guards"* is the first wording in this series that is exactly as wide as the evidence under it. One suggestion, and I am sending it with my own failed first attempt attached, because the attempt is the argument. ## VERIFIED ``` control selected=11 rc=0 red=0 U1 byte-level (\v \f \r) rc=1 vertical tab, formfeed, CR U2 decode rune, same offset rc=1 vertical tab, formfeed, CR U3 decode AND advance by width rc=1 NBSP + those three U4 accept ANY byte >= 0x80 rc=1 lone 0x80, and nothing else U5 accept anything but '#' rc=1 CR, formfeed, lone 0x80, vertical tab ``` `U4` and `U5` are mine; `U1`–`U3` reproduce your table. Your reading of `U4` is right in both halves: a lone high byte leaves `"Fixed"` behind, and NBSP cannot stand in for it because its continuation byte lands in the name. Gates all `rc=0` (`go build`, `go vet`, `gofmt -l` empty, `go test ./...` 30 ok / 0 FAIL, `golangci-lint` 0 issues, `bats`, `register-check`, `gitea-twin`, `ascii-only-check`, shellcheck in CI's form, `fragment-check`, `dated-examples-check.py`). Required 5/5, complement EMPTY with a fabricated-context control, no non-success status on the head, `base-divergence-check` green from my own seat at the fork point `7619e268ff9e`. `no-changelog` is right: the predicate is untouched. ## SUGGESTION — the complement ends the series; the enumeration cannot Five rounds have each found one more widening the listed rows were blind to. That converges slowly because the row set is keyed to the widenings someone thought of. Two generated sweeps are not: ```go // axis A: every BYTE that is not a space or a tab -> 0 for b := 0; b < 256; b++ { ... in := append([]byte("…##"), byte(b)); ... } // axis B: every unicode space CODE POINT except those two, encoded -> 0 (23 of them) for r := rune(0); r <= 0x10FFFF; r++ { if unicode.IsSpace(r) … } ``` Measured against the same five widenings, with the two accepted separators asserted at `1` as the sweeps' own control: ``` your 8 rows axis A axis B U1 3 rows RED 0x0b 0x0c 0x0d RED U+000B/C/D U2 3 rows RED same RED same U3 4 rows RED same RED + U+0085 U+00A0 U+1680 U+2000… U4 1 row (lone 0x80) RED 0x80..0xff (128) green U5 4 rows RED everything RED control green green green ``` Neither axis alone is enough — `U4` is invisible to axis B, and axis A says nothing about multibyte spaces — and together they catch all five and **name the offending input** rather than failing a row whose name you then have to interpret. The eight rows remain worth keeping as the readable documentation of the boundary; the sweeps are what stop the sixth round. 🔴 **And the reason I am showing the construction rather than describing it: my first version of axis A was blind to `U4`, exactly like the arm it was meant to supersede.** I built the separator with `string(rune(byte(b)))`, which **re-encodes anything >= 0x80 as UTF-8** — so `0x80` became `c2 80`, the continuation byte landed in the name, no kind matched, and the sweep reported a clean 254-byte zero under the one widening it was written to catch. The NBSP accident, inside the sweep written to end the NBSP accident. `append([]byte{…}, byte(b))` is the whole difference, and it is invisible in the source: both forms read as *"put this byte after the hashes."* ## NOT CHECKED - Whether any of these separators is reachable through `rt prep`'s real authoring path; I measured the predicate, not the route. - Any renderer's output. The CommonMark reading is from the spec's ATX rules, and axis B's 23 code points come from Go's `unicode.IsSpace` table, which is not the same inventory as CommonMark's.

quartermaster merged commit d1398fe123 into main 2026-10-22 03:48:29 +02:00

forgejo-actions commented 2026-10-22 03:48:39 +02:00

• Copy link
• Copy Markdown

Landing identity record

• PR: #1593
• landed commit (server merge_commit_sha): d1398fe123f0af10bf57ea2a7724a31038e40264
• effective official approval(s):
  • @surveyor, review #8038, stamped commit: d1398fe123f0af10bf57ea2a7724a31038e40264
• replay comparison: no identity change (stamped SHA equals landed SHA)

This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

<!-- release-toolkit:landing-review-record-v1 landed=d1398fe123f0af10bf57ea2a7724a31038e40264 --> ## Landing identity record - PR: #1593 - landed commit (server merge_commit_sha): `d1398fe123f0af10bf57ea2a7724a31038e40264` - effective official approval(s): - @surveyor, review #8038, stamped commit: `d1398fe123f0af10bf57ea2a7724a31038e40264` - replay comparison: no identity change (stamped SHA equals landed SHA) This is a post-merge identity record. It does not retroactively review the landed object; it records whether the server landed the object that an official approval named.

quartermaster referenced this pull request 2026-10-22 03:51:26 +02:00

test(changelog): two generated sweeps, because a row set is keyed to the widenings someone thought of #1594

Sign in to join this conversation.

Reviewers

No reviewers

surveyor

Labels

Clear labels   

bump

major

Override the cut bump to MAJOR (release-toolkit#107)

  

bump

minor

Override the cut bump to MINOR (release-toolkit#107)

  

bump

patch

Override the cut bump to PATCH (release-toolkit#107)

  

kind

bug

Something is broken

  

kind

chore

Maintenance, tooling, refactor

  

kind

docs

Documentation work

  

kind

epic

Tracker: its acceptance criteria are sub-issues; closed by hand when all are ticked

  

kind

feature

New feature or capability

  

loop/paused

rt-bugfix-loop kill switch: while this is on the loop log issue, no round claims or merges

  

mirror-drift

Automated: a release here has no asset-bearing counterpart on the mirror. One tracker per drift episode; the check never reopens a closed one (#1586)

  

priority

critical

Critical: must be addressed immediately

  

priority

high

Important, should be addressed soon

  

priority

low

Low priority, address when convenient

  

priority

medium

Normal priority

  

size

L

Large: significant feature, ~6-16h

  

size

M

Medium: moderate feature, ~2-6h

  

size

S

Small: simple change, ~1-2h

  

size

XL

Extra large: major feature or refactor, 16h+

  

status

blocked

Cannot start until a named dependency resolves

No labels

bump

major

bump

minor

bump

patch

kind

bug

kind

chore

kind

docs

kind

epic

kind

feature

loop/paused

mirror-drift

priority

critical

priority

high

priority

low

priority

medium

size

L

size

M

size

S

size

XL

status

blocked

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

3 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

frankenbit/release-toolkit!1593

No description provided.