docs(changelog) astubbs#197: finalise the 0.6.0.0 section as the release notes

[astubbs]

Serves #197, the release tracker. Closes nothing: the tracker closes with the tag.

changelog-ref: N/A - release-time generation per docs/releasing.md

Description

The release-time rewrite of CHANGELOG.adoc's == 0.6.0.0 section, so that it is the published release notes rather than the working text it has been since the fork. docs/releasing.md says the section for the release being cut is generated at release time, replacing what is there; there is no generator in bin/, so this PR is that generation, done by hand from the commit log and the release documents. It is the one deliberate exception to the "a PR never adds a changelog entry" rule, which exists precisely so this rewrite can be written as a set.

What the section is generated from

• The first-parent commit log from the fork point to master, every fix, fix!, feat, feat! and deps body read in full.
• The v6 burn-down note on docs(release) astubbs#197: v6 is a bug release, overdue - the burn-down to cut it #475 (docs/inflight/release-v6-scope.md): its decisions, its Paused consumption across multiple consumers confluentinc/parallel-consumer#857 and data-loss dispositions, its known unknowns, and its tag-day checks. Those dispositions are treated as decided.
• docs/inflight/release-0.6.0.0.md on master: the stability-release framing, the breaking-change record, the fix(core) astubbs#177: report the poll thread's real error, not the commit-response timeout (confluentinc#833) #204 API change.
• docs/data/roadmap.yaml and the open PR list, for the "What comes next" section.

Shape of the new section

• Opening: the fork, the coordinates, the stability-release argument in one paragraph, that the upgrade is the pom and the imports for most users but is not source-compatible beyond that, and that two known critical defects sit outside the bar, both transactional-mode only.
• The size of this release: merged PRs, main and test Java lines and new files since upstream's last published release, measured with rename detection.
• Breaking, as nested bullets: the coordinates and Java packages, the commit-budget exception, JStream blocking until close, the metadata-policy default, the exception rename and removed listener getter, identity equality for RecordContext, the two controller narrowings, the Mutiny Java 17 floor.
• Fixes in three subsections: priority 1, correctness - the records lost or duplicated; consumption stopped after a rebalance, which tells the Paused consumption across multiple consumers confluentinc/parallel-consumer#857 story (the mechanisms closed, the detector lines demoted to timing proxies, the one unattributed chaos-only arm); other fixes.
• Known limitations, stated so the release claims no more than it can show: the transactional revoke wait, the poisoned-transaction wedge, the retry-forever intake stall test(soak) astubbs#119: any retry-forever instance eventually stops fetching, at a threshold you can compute #487 measured with its two workarounds and the new WARN, producer fencing, the per-shard liveness blind spot, the never-reproduced commit-response timeout, revocation redelivery by design, and the unbounded JStream queue.
• What comes next, by state: implemented and on an open PR; designed and not yet built; toward 1.0.
• Dependencies, re-read against the poms. Examples. Build and CI, naming every lane that runs on a PR (SpotBugs, Error Prone with NullAway and GuardedBy, Infer with RacerD, CodeQL, dependency review, mutation, coverage with history, throughput against master, duplicate-code, CVE scan, hygiene gates), and Fray as the next concurrency lane.

Claims removed or corrected from the old text (each with its reason in the commit bodies): the "source-compatible" claim, which the Breaking list itself contradicted, removed from the changelog and from the README template in two places, with README.adoc regenerated; the wrong upstream attribution on the null-epoch fix that #217 asked to be dropped; "upstream's last release 0.5.3.3" corrected to 0.5.3.2 published; the Reactor version, which said 3.8.6 while the pom says 3.8.7; the self-hosted lane described as per-PR; the quarantine state; two counts restated as shape; two upstream bullets folded into the fork entries that carry them.

The heading loses its (unreleased) suffix in the same change. release.yml's exact heading match now finds the section. The release page body is still posted by hand on the day from the converter's Markdown, per the burn-down's tier 3; #199 follows the tag.

Tag-day checks this PR adds (beside the burn-down's own):

• fix(core) astubbs#119: the intake load gate says so when it has latched with nothing retiring #497 must be merged, or the WARN sentence in the intake-stall limitation comes out and "silently" goes back. An AsciiDoc comment beside the bullet says the same.
• The figures under "The size of this release" are recomputed at the tag with the commands in the comment beside them.

Also touched: docs/inflight/release-0.6.0.0.md gains the settled release-condition wording at the same insertion point #475 amends it; whichever merges second keeps the settled paragraph. A stale quarantine claim there is corrected in place. docs/releasing.md no longer says the section's generation is undecided. src/docs/README_TEMPLATE.adoc and the regenerated README.adoc lose the source-compatibility claim.

Checklist

• Docs updated - this PR is the doc change
• User-facing feature documentation data added under docs/features/ - N/A - release notes, no feature
• Tests added/updated - N/A - prose only; the converter's self-test from ci(release) astubbs#197: publish the curated changelog section as the GitHub Release body #199 was run against the finalised section in strict mode and passes
• docs/inflight/ working note (pr-/branch-) started at the PR's first commit - N/A - the burn-down note on docs(release) astubbs#197: v6 is a bug release, overdue - the burn-down to cut it #475 is the working note for the release, and this PR's commit bodies record what was generated from where
• Title & body reflect the final content of this PR
• Ran ce-simplify and ce-code-review locally - N/A - docs only; bin/check-all.sh clean, and asked for @claude review this on the PR instead

🤖 Generated with Claude Code

https://claude.ai/code/session_019XS64Xttx4vF5datYh7fmk

[astubbs]

@claude review this

[claude]

Claude finished @astubbs's task in 3m 6s —— View job

---

Review

• Gather context (PR body, branch commits, changed files)
• Read CHANGELOG.adoc diff in full
• Read docs/inflight/release-0.6.0.0.md diff
• Read docs/releasing.md diff
• Cross-check claimed corrections (upstream attribution, version numbers, Reactor version, etc.) against source of truth
• Check heading change ((unreleased) suffix removal) against release.yml's matcher
• Post review

No correctness issues found. This is an unusually well-substantiated docs PR, and it holds up under fact-checking, not just reading:

• release.yml's heading match is genuinely fixed by this PR. .github/workflows/release.yml does awk -v h="== ${{ inputs.releaseVersion }}" '$0 == h {grab=1; ...}' — an exact line match. The old heading == 0.6.0.0 (unreleased) would never have matched == 0.6.0.0, so cutting the tag today would have silently fallen through to the ::warning::No CHANGELOG section... branch and shipped auto-generated notes instead of this text. Dropping the suffix is not cosmetic, it's the thing that makes the release page pick up the curated notes at all.
• Verified every version claim in the "Dependencies" section against the current poms, not just against the PR's own commit body: kafka.version 3.9.2, micrometer-core.version 1.13.15, netty.version 4.1.137.Final, logback.version 1.6.1, and parallel-consumer-reactor/pom.xml's reactor-core 3.8.7 (whose inline comment independently confirms "3.8.7, not 3.8.6: CVE-2026-47857 and CVE-2026-47863" — matching the changelog's "closing two advisories" wording exactly). docs/inflight/deps-cve-backlog.md and deps-deferred-majors.md, both cited, exist.
• Verified the removed/corrected claims against their sources, not just trusted the commit body's account:
  • fix(core) #118: foreign offset metadata no longer kills the consumer on assignment #217's PR body literally asks for the afde8c5e null-epoch fix's "relates to upstream test(arch): forbid one-character method names, close the ArchUnit module gap, and gate inflight notes that describe their own PR #326" attribution to be dropped at generation ("that attribution is speculative and wrong... should be dropped"). The new text does exactly that — the bullet survives under "Other fixes" with no upstream reference.
  • fix(core): the revoke sweep names the registration it means, not whatever holds the offset #492's PR body describes the fix as closing fix(core)!: WorkContainer equality is identity, so the stale sweep removes only the container it inspected #468's defect class at a second site (a live container from another registration surviving a revoke sweep) — consistent with the changelog folding fix(core)!: WorkContainer equality is identity, so the stale sweep removes only the container it inspected #468 and fix(core): the revoke sweep names the registration it means, not whatever holds the offset #492 into one "Two sweeps removed work by offset..." bullet.
  • docs/quarantined-tests.md has zero - [ ] entries in the working tree right now — the "registry is empty at this release" claim is currently true, not just asserted.
• The "not in the notes, deliberately" exclusions (fix(core)! astubbs#311: reject a batch size below one, instead of starting cleanly and processing nothing #496, fix(core) astubbs#119: the intake load gate says so when it has latched with nothing retiring #497) are still both OPEN as of this review, so that claim hasn't gone stale between when the PR was written and now.
• Line-length claim holds for the part it's scoped to. 23 lines in CHANGELOG.adoc exceed 120 chars, but all of them are either the pre-existing top-of-file NOTEs (untouched by this diff) or in the legacy 0.5.3.3-and-below sections (lines 511+, hand-written legacy, out of scope). Every line inside the new == 0.6.0.0 section (lines 21–510) is ≤120 chars, matching the commit body's claim about "the section," not the whole file.
• docs/releasing.md's diff is a clean, consistent tightening of the table row and the two-reading paragraph — no residual references to the old "not yet decided" framing were left behind.
• docs/inflight/release-0.6.0.0.md's edits are all "mark this instruction settled, cite where it landed" — none of them delete evidence or an open decision, they just point at where it's now recorded in CHANGELOG.adoc. Consistent with that directory's "not a place knowledge goes to die" rule.

One thing worth the author's own judgment call rather than mine, since it's a policy question, not a bug: docs/releasing.md's new wording says the one edit the section may still take before the tag is "a correction for work that lands after generation" — worth double-checking that's exactly the carve-out you want if #496/#497 land before the tag, versus a fuller regeneration.

Spot-checked a representative sample of the ~90 PR/issue links (not all of them) against gh pr view/gh issue view; titles and described behavior matched in every case checked.
· branch docs/v6-changelog-and-release-notes

[github-actions]

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

[github-actions]

✅ Duplicate Code Report

Two engines run in parallel for cross-validation. Each has its own thresholds tuned to its baseline - the real safety net is the per-engine "max increase vs base" check.

✅ PMD CPD

	PR	Base	Change
Clones	27	27	➖ 0
Duplicated lines	949	949	➖ 0
Duplication	0.37%	0.37%	➖ 0

Rule	Limit	Status
Max duplication	0.5%	✅ Pass (0.37%)
Max increase vs base	+0.1%	✅ Pass (+0.00%)

No new clones introduced by this PR.

✅ jscpd (language-agnostic)

	PR	Base	Change
Clones	106	106	➖ 0
Duplicated lines	1503	1503	➖ 0
Duplication	0.82%	0.82%	➖ 0

Rule	Limit	Status
Max duplication	2%	✅ Pass (0.82%)
Max increase vs base	+0.1%	✅ Pass (+0.00%)

No new clones introduced by this PR.

_{Powered by astubbs/duplicate-code-cross-check}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 83.15%. Comparing base (e8bd2cb) to head (941eb5d).
⚠️ Report is 1 commits behind head on master.
✅ All tests successful. No failed tests found.

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #498      +/-   ##
============================================
+ Coverage     82.67%   83.15%   +0.47%     
- Complexity     1586     1593       +7     
============================================
  Files            96       96              
  Lines          5444     5444              
  Branches        549      549              
============================================
+ Hits           4501     4527      +26     
+ Misses          746      723      -23     
+ Partials        197      194       -3     

Flag	Coverage Δ
chaos	53.37% <ø> (?)
integration	62.89% <ø> (-0.06%)	⬇️
performance	47.65% <ø> (?)
unit	79.40% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[github-actions]

🟢 Throughput — OK

This branch measured the same speed as master, on the one test this measures.

What	Value	Meaning
Compared with master	1.000	above 1.00 is faster, below is slower
Subject test took	55.4s	the test under measurement
Control tests took	30.5s	the other tests in this same run
Subject ÷ controls, here	1.818	not a speed - a shape that cancels machine speed
Subject ÷ controls, master	1.817	median of recent master runs
Reported rate	74887 rec/s	this machine only; not comparable across runners

Allowable range 🟢 ≥ 0.70 · 🟡 0.50–0.70 (about a 30% loss) · 🔴 < 0.50 (about a 50% loss)

What the numbers mean, and what they cannot tell you

The one that gets misread. Subject ÷ controls is a shape, not a speed. 1.7 means the subject took 1.7 times as long as the control tests in the same run - it says nothing about master on its own, and a reviewer has already read it as "1.7x faster than master". Only Compared with master answers that question.

Why a shape and not a rate. A rate depends on which runner you drew. A shape does not: every test here processes a fixed number of records, so a runner twice as slow doubles the subject and the controls together and leaves their ratio alone. That is the whole trick, and it is why the reported rate is shown last and labelled as this machine only.

Reading the comparison. master ÷ this run. Above 1.00 the subject is proportionally quicker here than on master; below 1.00 it is slower. 0.50 means it takes twice as long relative to its controls - that is the failing bound, not a small one.

By conservation, not by correction. Every test in this lane processes a fixed number of records, so within one run the ratio of one test's time to another's is invariant under machine speed — a runner twice as slow doubles both terms and leaves the ratio alone. There is no machine-index correction to be wrong, because nothing needed correcting. share = subjectSeconds / controlSeconds, both from this same run.

Per-method times, not class times. A class time is work + setup, and container startup and @BeforeAll do not scale with work — they are the non-conserved term, and leaving them in breaks the invariant.

Reference is the median of 10 recent perf baseline (master) run(s), read from their artifacts. There is no committed baseline to go stale, and a share is dimensionless, so an old entry stays comparable to a new one without re-baselining. Shares observed: 1.613 – 1.915.

What this still cannot do. It removes machine-to-machine variance. It does not remove this test's own run-to-run variance, measured at about 30% on a single unchanged commit while its controls stayed within 5%. That is a property of the test, not of the comparison, and no arithmetic here can touch it — which is why the reference is a median and the bounds are deliberately coarse. 🟡 means look at this; only 🔴 is outside the measured spread.

Runs used: a37d148, e8bd2cb, 1743297, 4bc6e7a, b62c310, c381310, c79424a, 9c67c89, f1aa5eb, eb9fdb0

Since the previous push: ratio 1.009 -> 1, share 1.834 -> 1.818, rate 68206 -> 74887 (+9.8%). One push of difference sits inside this test's measured spread - read it as movement, not as a result.

_{Updated for 941eb5d · run 34315269727 · 2026-09-09 05:43 UTC}

[github-actions]

⚠️ SpotBugs Report

354 bug(s) found (rule-level exclusions only - see docs/inflight/static-spotbugs-rule-registry.md). See the annotations on the Files Changed tab for details.

_{Updated for 941eb5d · run 34315269727 · 2026-09-09 05:43 UTC}

[astubbs]

@claude review this

[claude]

Claude finished @astubbs's task in 2m 51s —— View job

---

Review

• Gather context (PR body, branch commits, prior review, changed files)
• Read what's changed since the last @claude review this (commits d160be5, 74c68a3)
• Re-check the fix(core)! astubbs#311: reject a batch size below one, instead of starting cleanly and processing nothing #496 batch-size claim against master
• Check the Build & CI section against the actual CI lanes
• Sanity-check line lengths and citations again

No correctness issues found in the two commits added since the last review. Both are owner-driven follow-ups to that review and check out against the current tree:

74c68a3 — the batchSize bullet. Verified the new "Breaking" bullet against ParallelConsumerOptions.batchSizeValidation() (parallel-consumer-core/src/main/java/bz/stub/parallelconsumer/ParallelConsumerOptions.java): batchSize == null and batchSize < 1 both throw IllegalArgumentException naming the field via Fields.batchSize, exactly as the changelog states — including the "nothing changes for one or more" claim and the pre-existing failure modes it replaces (silent no-op consumer, or a bare ArithmeticException only when messageBufferSize is set, per the class javadoc's own account of the old behavior).

d160be5 — the expanded Build & CI section. Spot-checked the specific additions against the actual workflows/config rather than just the commit body's claim:

• RacerD and Error Prone's @GuardedBy at ERROR: confirmed in bin/infer-test.sh (full checker set, not --racerd-only) and pom.xml's comment on the @GuardedBy dependency.
• CodeQL and dependency review: present (dependency-audit.yml, repo-hygiene.yml, maven.yml).
• Tag-as-truth release: release.yml does exactly what's claimed — checks the latest CI run on master for conclusion == success before running release:prepare, and the antipattern comment about re-releasing an ancient commit is in the workflow's own header.
• Dependabot-held-back majors: JUnit 6, Testcontainers 2, Vert.x 5, Mutiny 3, WireMock 3 are all in docs/inflight/deps-deferred-majors.md with reasons; Kafka 4 is ignored in .github/dependabot.yml (org.apache.kafka:* — "needs Java 11 baseline") with its own reasoning in docs/inflight/pr-53-java-baseline-kafka4.md. All six are accounted for, just split across two docs.
• Fray is only mentioned in CHANGELOG.adoc itself (nowhere else in the tree) — consistent with the commit body's own framing ("on the owner's word," i.e. a forward-looking claim, not something already wired up).
• Line-length check re-run after both commits: every line >120 chars is still confined to the pre-existing top-of-file NOTEs or the legacy sections (≥685), none inside the == 0.6.0.0 section the new bullets landed in.

Nothing here reopens or contradicts anything flagged in the previous review pass — the section still holds up.
· branch docs/v6-changelog-and-release-notes

[astubbs]

lgtm

[astubbs]

lgtm

[astubbs]

@claude review this

[claude]

Claude finished @astubbs's task in 2m 3s —— View job

---

Review

• Gather context (PR body, prior two reviews, branch commits, comments)
• Identify what's new since the last @claude review this (03:36:30Z) — commit 363796c
• Read the diff of 363796c in full
• Verify the new batchSize Breaking bullet against ParallelConsumerOptions
• Verify fix(core)! astubbs#311: reject a batch size below one, instead of starting cleanly and processing nothing #496 / Batching requests a full extra in-flight target of work, and batchSize is unvalidated #311 status
• Check the Build & CI trim for dangling references elsewhere in the file
• Post review

No correctness issues found. The only change since the last review pass is commit 363796c ("the batchSize bound joins Breaking, and Build & CI keeps only the testing lanes"), and it holds up:

• The batchSize Breaking bullet (CHANGELOG.adoc:101-106) matches the code exactly. Verified against ParallelConsumerOptions.batchSizeValidation(): batchSize == null and batchSize < 1 both throw IllegalArgumentException naming the field via Fields.batchSize, at validate()/construction time — matching the bullet's claims about the old failure modes too (silent no-op consumer, or a bare ArithmeticException only when messageBufferSize was set), which the field's own javadoc corroborates (ParallelConsumerOptions.java:500-506, citing Batching requests a full extra in-flight target of work, and batchSize is unvalidated #311).
• The link targets are correct and current. gh pr view 496 confirms MERGED; gh issue view 311 confirms OPEN — matching the bullet's pull/496 + issues/311 split (a PR link for the fix, an issue link for the still-open tracker) rather than treating both as the same kind of reference.
• The Build & CI trim is a clean removal, not a rewrite. It deletes the "Two reviews before a merge," "Releases are tag-as-truth," "self-hosted lane," "upstream issue mirrors," "solutions write-ups," and "dependencies move on their own" bullets, leaving the section running straight from the intro ("parts that say something about how carefully the library is tested") to "Repository hygiene as a required check," which is now the last bullet — exactly what the commit body describes ("ends at the CVE scan and the hygiene gates"). Grepped the whole file for the removed bullets' distinctive text (tag-as-truth, self-hosted, Two reviews before a merge, issue mirrors, Dependencies move on their own) — no dangling cross-references or orphaned mentions elsewhere in CHANGELOG.adoc.
• Fray, the concurrency-lane forward-looking claim flagged in the previous review, is untouched by this trim — still present at line 601-602, unaffected since it sits in the retained "Concurrency testing" bullet, not the removed ones.
• Nothing else changed in this commit — README.adoc, docs/releasing.md, docs/inflight/release-0.6.0.0.md, and src/docs/README_TEMPLATE.adoc are unchanged since the prior review, which already covered them.

Consistent with the two prior review passes on this PR and both lgtm reviews from the author — nothing here reopens or contradicts either.
· branch docs/v6-changelog-and-release-notes

[astubbs]

@claude review this

[claude]

Claude finished @astubbs's task in 2m 1s —— View job

---

Review

• Gather context (PR body, prior reviews, branch commits)
• Identify what's changed since the last @claude review this pass (which covered through d160be5)
• Read and verify the new commits (363796c, 86e8c56) against the codebase
• Post review

No correctness issues found. Only two new commits landed since the previous review pass, both owner-driven tightenings of the "Breaking" and "Build & CI" sections, and both check out:

363796c — the batchSize bullet. #496 merged after this branch was cut (confirmed MERGED, subject fix(core)! astubbs#311: reject a batch size below one...). The new bullet's claims match ParallelConsumerOptions.batchSizeValidation(): batchSize == null and batchSize < 1 both throw IllegalArgumentException naming the option via Fields.batchSize, and the class's own javadoc (lines ~604-608) confirms the pre-existing ArithmeticException-only-when-messageBufferSize-is-set failure mode the bullet describes as the old behavior. This commit also trims the "Two reviews before a merge" / "tag-as-truth releases" / "self-hosted lane" / "how the project itself is run" bullets from Build & CI — read the surrounding section afterward and it's still coherent: the "the library is tested:" lead-in flows straight into the remaining static-analysis/CI bullets with no orphaned reference to what was cut.

86e8c56 — the coordinates bullet. This is a real fix, not just a rewording: bin/rename-packages.sh (line 550-551) carries a literal prose guard over CHANGELOG.adoc requiring either the old claim or the exact phrases "two changes are required" / "Rewrite your imports". The prior wording in this PR ("Update the dependency, then find-and-replace the imports") satisfied neither, which would have failed bin/test-rename-packages.sh and gone red on repo: hygiene/shell: macos — exactly as the commit body describes. The new text contains both required phrases verbatim.

Re-checked line lengths across the whole == 0.6.0.0 section (through line 645, where == 0.5.3.3 starts) after both edits — the only lines over 120 chars are the pre-existing top-of-file NOTEs; nothing introduced by these two commits crosses it.

No dangling references. The merge commit 752ab11 that brought #496 in from master doesn't touch CHANGELOG.adoc itself (that edit is 363796c's), and there's no leftover mention of #496 anywhere in this PR's files as a still-pending tag-day item — it's now folded into the merged-PR citation as expected.

Nothing here reopens or contradicts either of the two prior review passes. Combined with the two lgtm reviews already on this PR, I don't see anything blocking merge.
· branch docs/v6-changelog-and-release-notes

[astubbs]

@claude review this

[claude]

Claude finished @astubbs's task in 1m 9s —— View job

---

Review

• Gather context (prior 4 review passes, branch commits, PR comments)
• Identify what's changed since the last @claude review this pass (covered through 86e8c56)
• Read and verify any new commits against the codebase
• Post review

No correctness issues found. The only commit added since the last review pass is 941eb5d ("Merge origin/master into docs/v6-changelog-and-release-notes"), and it's a pure sync merge — confirmed with git diff 86e8c56 941eb5d -- CHANGELOG.adoc README.adoc docs/inflight/release-0.6.0.0.md docs/releasing.md src/docs/README_TEMPLATE.adoc, which is empty. Everything the merge pulled in (.github/workflows/maven.yml, the chaos-test/docs/inflight changes for confluentinc#857) lands in files this PR doesn't touch, so none of it changes what's under review.

This PR's five files (CHANGELOG.adoc, README.adoc, docs/inflight/release-0.6.0.0.md, docs/releasing.md, src/docs/README_TEMPLATE.adoc) are unchanged since the previous review pass at 86e8c56, which already verified:

• the (unreleased) heading removal against release.yml's exact-match awk,
• the dependency version claims (Kafka, Micrometer, Netty, Logback, Reactor) against the current poms,
• the removed/corrected claims (fix(core) #118: foreign offset metadata no longer kills the consumer on assignment #217's attribution ask, the fix(core): the revoke sweep names the registration it means, not whatever holds the offset #492 fold, the empty quarantine registry) against their sources,
• the batchSize Breaking bullet against ParallelConsumerOptions.batchSizeValidation(),
• the trimmed Build & CI section for dangling references, and
• the coordinates bullet's wording against bin/rename-packages.sh's literal prose guard.

Nothing here reopens or contradicts any of the four prior review passes, and both lgtm reviews from the author still stand against the current tip.
· branch docs/v6-changelog-and-release-notes