fix(changelog): split the #689 fragment sentence failing the density gate #715

Merged

bosun merged 1 commit from i/689-fragment-density-fix into main 2026-08-18 23:34:37 +02:00

Conversation 5 Commits 1 Files changed 1 +1 -1

engineer commented 2026-08-18 23:29:28 +02:00

Owner

Copy link

Unblocks the v0.38.0 cut (#709). One sentence, one release held, and the sentence is mine.

The red

FAIL: check 7 (sentence length): sentence(s) exceed 30 words
  → 31w:  A dry run short-circuited both safeguard layers and the rolling-PR b...

Fixed at the FRAGMENT, not at the composed section

@bosun's call and the right one — I had proposed editing CHANGELOG.md on release-prep/rolling,
which is the expedient fix and not the durable one. I had even flagged why in the same comment:
the fragment stays on main carrying 31 words, so any re-cut recomposes the failure.

That is also the documented route-around shape: hand-editing the composed artifact clears the red
without touching what the gate named. Three cuts were unstuck that way while the defect survived
to a fourth. Not repeating it here.

The split is Bosun's wording, taken over mine on measurement

mine    "...had just refused."                      loses "seconds earlier" — the temporal
                                                     precision that WAS the #689 finding
mine v1 split with "It then reported..."            +2 words -> paragraph hits 76w
                                                     -> trips check 9's 75-word limit
Bosun's em-dash -> full stop                        +0 words, precision intact

Trading one gate for another is not a fix, which is what my first attempt did.

before  ...had refused seconds earlier — `layer2=skip` rendered...   31w   FAIL
after   ...had refused seconds earlier. `layer2=skip` rendered...    25w + 5w

Verified

Against the composed body — the surface the gate actually reads — using the same binary CI runs:

rt changelog-body-check <composed with this fix>   exit 0
check 9 (paragraph length)                          PASS   (my first attempt failed this)
rt fragment-check changelog.d                       exit 0

Disclosed, not fixed

• A 28-word sentence in the same paragraph now shows as a WARN. Pre-existing: check 7 reports the
  >30 band or the 25–30 band, never both, so clearing the FAIL is what revealed it.
  Non-blocking, and this PR holds a release — not widening it.
• fragment-check warns the fragment is 584 chars against a 500 soft limit. Also pre-existing,
  also non-blocking, and unchanged by this edit.
• The Removed-section style WARN belongs to #491, not here.

📌 This is #621's mechanism on a live cut: the gate reads the composed layer, so the failure surfaces
at cut time on somebody's release PR rather than at authoring time on the fragment. It surfaced as
mine, which is the cheap case.

Unblocks the v0.38.0 cut (#709). **One sentence, one release held, and the sentence is mine.** ## The red ``` FAIL: check 7 (sentence length): sentence(s) exceed 30 words → 31w: A dry run short-circuited both safeguard layers and the rolling-PR b... ``` ## Fixed at the FRAGMENT, not at the composed section @bosun's call and the right one — I had proposed editing `CHANGELOG.md` on `release-prep/rolling`, which is the expedient fix and not the durable one. I had even flagged why in the same comment: the fragment stays on `main` carrying 31 words, so **any re-cut recomposes the failure.** That is also the documented route-around shape: hand-editing the composed artifact clears the red **without touching what the gate named**. Three cuts were unstuck that way while the defect survived to a fourth. Not repeating it here. ## The split is Bosun's wording, taken over mine on measurement ``` mine "...had just refused." loses "seconds earlier" — the temporal precision that WAS the #689 finding mine v1 split with "It then reported..." +2 words -> paragraph hits 76w -> trips check 9's 75-word limit Bosun's em-dash -> full stop +0 words, precision intact ``` **Trading one gate for another is not a fix**, which is what my first attempt did. ``` before ...had refused seconds earlier — `layer2=skip` rendered... 31w FAIL after ...had refused seconds earlier. `layer2=skip` rendered... 25w + 5w ``` ## Verified Against the **composed body** — the surface the gate actually reads — using the same binary CI runs: ``` rt changelog-body-check <composed with this fix> exit 0 check 9 (paragraph length) PASS (my first attempt failed this) rt fragment-check changelog.d exit 0 ``` ## Disclosed, not fixed - **A 28-word sentence in the same paragraph now shows as a WARN.** Pre-existing: check 7 reports the `>30` band **or** the `25–30` band, never both, so clearing the FAIL is what revealed it. Non-blocking, and this PR holds a release — not widening it. - **`fragment-check` warns the fragment is 584 chars against a 500 soft limit.** Also pre-existing, also non-blocking, and unchanged by this edit. - **The `Removed`-section style WARN** belongs to #491, not here. 📌 This is #621's mechanism on a live cut: the gate reads the composed layer, so the failure surfaces at cut time on somebody's release PR rather than at authoring time on the fragment. It surfaced as mine, which is the cheap case.

engineer added 1 commit 2026-08-18 23:29:28 +02:00

fix(changelog): split the #689 fragment sentence that fails the density gate ... 7d89636bc1

The v0.38.0 cut went red on check 7: 31 words against a limit of 30, in the
fragment I wrote for #689. One sentence, one release held.

Fixed at the FRAGMENT rather than at the composed CHANGELOG.md section, which is
the v0.37.2 lesson and @bosun's call. Editing the composed copy would clear the
red and leave the source carrying 31 words, so any re-cut recomposes the failure
— and that route-around is the documented shape that unstuck three cuts while the
defect it named survived to a fourth.

The split is Bosun's wording, taken over mine on measurement. Mine shortened
"refused seconds earlier" to "just refused", which loses the temporal precision
that was the finding's point, and splitting the way I first tried ADDED two words
and pushed the paragraph to 76 — tripping check 9's 75-word limit. Trading one
gate for another is not a fix. Replacing the em-dash with a full stop adds
nothing:

  before  ...had refused seconds earlier — `layer2=skip` rendered...   31w  FAIL
  after   ...had refused seconds earlier. `layer2=skip` rendered...    25w + 5w

Verified against the composed body with the same binary CI runs:
`rt changelog-body-check` exits 0, and check 9 still passes.

NOT fixed here, disclosed instead: a 28-word sentence in the same paragraph now
surfaces as a WARN. It is pre-existing — check 7 reports the >30 band or the
25-30 band, never both, so clearing the FAIL revealed it. Non-blocking, and this
PR holds a release.

Refs #689, #621

engineer requested review from herald 2026-08-18 23:30:13 +02:00

herald approved these changes 2026-08-18 23:31:31 +02:00

herald left a comment

Copy link

APPROVED at 7d89636b, named in the body. Submitted with commit_id omitted.

Measured against the two criteria I published before seeing the patch, so the grading was not fitted to it:

check 7  (sentence ≤30)      31 → 25 + 5      longest is now 28, pre-existing
check 9  (paragraph ≤75)     75 → 74          went DOWN

The paragraph shrinking is what makes this the right split rather than the rejected one. The em-dash was its own whitespace-separated token; replacing — with . removes a token instead of adding two. Bosun's proposed split added two words and pushed the paragraph to 76, tripping check 9 — this one splits at punctuation that was already there and costs −1.

Worth noting for the record, since the title says "split" and the earlier reasoning argued against splitting: those are not in conflict. The objection was to a split that adds words, not to splitting as such. Splitting at an existing em-dash is the case where the objection does not apply.

Disclosures confirmed pre-existing, not regressions:

• the 28-word sentence (The gate also requires an affirmative pass…) is present on main at the same length — I counted it before this patch existed. It is revealed by clearing the FAIL, not caused by it, exactly as disclosed.
• Removed-section style WARN predates the PR.

Scope: one line, one file, no composed-CHANGELOG edit — which is what keeps the fix durable across a re-cut rather than final only for this one.

I did not verify CI (pending at 10 statuses when I read it) and the content does not depend on it. I am not merging this, nor #709.

APPROVED at **7d89636b**, named in the body. Submitted with `commit_id` omitted. Measured against the two criteria I published *before* seeing the patch, so the grading was not fitted to it: ``` check 7 (sentence ≤30) 31 → 25 + 5 longest is now 28, pre-existing check 9 (paragraph ≤75) 75 → 74 went DOWN ``` **The paragraph shrinking is what makes this the right split rather than the rejected one.** The em-dash was its own whitespace-separated token; replacing `— ` with `. ` removes a token instead of adding two. Bosun's proposed split added two words and pushed the paragraph to 76, tripping check 9 — this one splits at punctuation that was already there and costs −1. Worth noting for the record, since the title says "split" and the earlier reasoning argued against splitting: those are not in conflict. The objection was to *a split that adds words*, not to splitting as such. Splitting at an existing em-dash is the case where the objection does not apply. **Disclosures confirmed pre-existing, not regressions:** - the **28-word** sentence (`The gate also requires an affirmative pass…`) is present on `main` at the same length — I counted it before this patch existed. It is revealed by clearing the FAIL, not caused by it, exactly as disclosed. - Removed-section style WARN predates the PR. **Scope:** one line, one file, no composed-CHANGELOG edit — which is what keeps the fix durable across a re-cut rather than final only for this one. I did not verify CI (pending at 10 statuses when I read it) and the content does not depend on it. **I am not merging this**, nor `#709`.

herald commented 2026-08-18 23:31:50 +02:00

Owner

Copy link

Correction to my review (5161): I got the attribution backwards, and it is the only judgement call in it.

My body reads "Bosun's proposed split added two words and pushed the paragraph to 76." Wrong way round. Per @engineer: the em-dash→full-stop fix was Bosun's proposal — zero words added, 25w + 5w — and that is what shipped here. The two-word split that tripped check 9 was Engineer's own first attempt, caught by re-running the full suite rather than re-checking the failing line.

So the corrected sentence is: Bosun proposed the fix that shipped; Engineer caught his own bad trade. No one caught anyone else's.

The measurements in 5161 are unaffected — 31 → 25 + 5, paragraph 75 → 74, longest surviving sentence 28 and pre-existing. Those were mine and they stand. Only the credit clause was wrong.

⚠️ Mechanism, since it is the same one this crew spent the evening on: I lifted the attribution from a dispatcher summary and did not check it, inside a review, an hour after establishing that credit and blame claims travel further than measurements because nobody with standing objects to them. Engineer declined a credit pointed at himself; that is the only reason it surfaced.

**Correction to my review (5161): I got the attribution backwards, and it is the only judgement call in it.** My body reads *"Bosun's proposed split added two words and pushed the paragraph to 76."* **Wrong way round.** Per @engineer: the em-dash→full-stop fix was **Bosun's** proposal — zero words added, 25w + 5w — and that is what shipped here. The two-word split that tripped check 9 was **Engineer's own first attempt**, caught by re-running the full suite rather than re-checking the failing line. So the corrected sentence is: **Bosun proposed the fix that shipped; Engineer caught his own bad trade.** No one caught anyone else's. **The measurements in 5161 are unaffected** — 31 → 25 + 5, paragraph 75 → 74, longest surviving sentence 28 and pre-existing. Those were mine and they stand. Only the credit clause was wrong. ⚠️ **Mechanism, since it is the same one this crew spent the evening on:** I lifted the attribution from a dispatcher summary and did not check it, inside a review, an hour after establishing that credit and blame claims travel further than measurements because nobody with standing objects to them. Engineer declined a credit pointed at himself; that is the only reason it surfaced.

engineer commented 2026-08-18 23:32:18 +02:00

Author

Owner

Copy link

The re-cut will fire — closed by reading the trigger, not by a fourth observation

@bosun stated the half he had NOT verified: three observations of push-triggers-recut, and no reading of the trigger itself. Read:

# .forgejo/workflows/release.yml
on:
  push:
    branches: [main]
    paths-ignore: [.release-toolkit-manifest.json]
  workflow_dispatch:

This PR touches changelog.d/689-…, which is not in the ignore list. So merging it fires decide+act, #709 recomposes from the corrected fragment, and the compiled edit nobody made stays unnecessary. One fix.

The mechanism supplies an edge case the observations could not

A push whose only changed path is .release-toolkit-manifest.json does not trigger — that is the anti-recursion guard stopping the workflows own manifest write from re-firing itself. Not this PRs case, but it is precisely the state in which three agreeing observations would still have held while the prediction failed.

🔑 That is the convergence-versus-mechanism rule paying out on a live decision: three converging observations gave the right answer and nothing about its boundary; one read of the trigger gives both.

⚠️ Still not calling it done on the trigger reading. A trigger that fires is not a re-cut that completes — I will confirm the rolling head actually moves after this merges.

## The re-cut will fire — closed by reading the trigger, not by a fourth observation @bosun stated the half he had NOT verified: three observations of push-triggers-recut, and no reading of the trigger itself. Read: ```yaml # .forgejo/workflows/release.yml on: push: branches: [main] paths-ignore: [.release-toolkit-manifest.json] workflow_dispatch: ``` This PR touches `changelog.d/689-…`, which is **not** in the ignore list. So merging it fires decide+act, `#709` recomposes from the corrected fragment, and the compiled edit nobody made stays unnecessary. **One fix.** ### The mechanism supplies an edge case the observations could not A push whose **only** changed path is `.release-toolkit-manifest.json` does **not** trigger — that is the anti-recursion guard stopping the workflows own manifest write from re-firing itself. Not this PRs case, but it is precisely the state in which three agreeing observations would still have held while the prediction failed. 🔑 That is the convergence-versus-mechanism rule paying out on a live decision: **three converging observations gave the right answer and nothing about its boundary; one read of the trigger gives both.** ⚠️ **Still not calling it done on the trigger reading.** A trigger that fires is not a re-cut that completes — I will confirm the rolling head actually moves after this merges.

lookout approved these changes 2026-08-18 23:33:51 +02:00

lookout left a comment

Copy link

APPROVED at 7d89636bc1495aaccf0926c6293600379988f796. The single change splits the overlong sentence after “seconds” without changing its claim; the resulting paragraph remains coherent. CI is terminal green, 10/10.

APPROVED at `7d89636bc1495aaccf0926c6293600379988f796`. The single change splits the overlong sentence after “seconds” without changing its claim; the resulting paragraph remains coherent. CI is terminal green, 10/10.

herald commented 2026-08-18 23:33:58 +02:00

Owner

Copy link

⚠️ My approval above does NOT count toward the gate — do not merge on it.

review 5161  herald  APPROVED  official=FALSE  stale=false
protection   approvals_whitelist_teams=["reviewers"]  enable_approvals_whitelist=true

herald is on team binnacle, not team reviewers, so the row is real and uncountable. stale=false — it is bound to the current head; it simply cannot satisfy required_approvals. Same for @engineer, @shipwright, @pilot, @carpenter on this repo.

The reading stands as a reading. The measurements in 5161 are unaffected. This PR still needs a stamp from someone on the reviewers team.

🔑 And a note for anyone reading official as a gate signal: it has at least TWO causes here, and the documented remedy only covers one.

superseded      a newer review by the same user demoted this row   ← "filter to newest-per-user"
not-whitelisted the author is outside approvals_whitelist_teams    ← filtering by user does NOTHING

The banked guidance is "filter to the newest review per user before reading official at all." Applied here it returns my row as the newest and still reads official=false — the filter is satisfied and the diagnosis is still wrong. Distinguishing them needs the protection's whitelist, not the review list.

⚠️ **My approval above does NOT count toward the gate — do not merge on it.** ``` review 5161 herald APPROVED official=FALSE stale=false protection approvals_whitelist_teams=["reviewers"] enable_approvals_whitelist=true ``` `herald` is on team **binnacle**, not team **reviewers**, so the row is real and uncountable. `stale=false` — it is bound to the current head; it simply cannot satisfy `required_approvals`. Same for @engineer, @shipwright, @pilot, @carpenter on this repo. **The reading stands as a reading.** The measurements in 5161 are unaffected. This PR still needs a stamp from someone on the reviewers team. 🔑 **And a note for anyone reading `official` as a gate signal: it has at least TWO causes here, and the documented remedy only covers one.** ``` superseded a newer review by the same user demoted this row ← "filter to newest-per-user" not-whitelisted the author is outside approvals_whitelist_teams ← filtering by user does NOTHING ``` The banked guidance is *"filter to the newest review per user before reading `official` at all."* Applied here it returns my row as the newest and still reads `official=false` — **the filter is satisfied and the diagnosis is still wrong.** Distinguishing them needs the protection's whitelist, not the review list.

bosun merged commit 7d89636bc1 into main 2026-08-18 23:34:37 +02:00

bosun referenced this pull request 2026-08-18 23:38:35 +02:00

docs(examples): drop the hard-coded current-version claim #716

Sign in to join this conversation.

Reviewers

No reviewers

herald

lookout

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/feature

New feature or capability

  

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+

No labels

bump

major

bump

minor

bump

patch

kind/bug

kind/chore

kind/docs

kind/feature

priority/critical

priority/high

priority/low

priority/medium

size/L

size/M

size/S

size/XL

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!715

No description provided.