docs(release) astubbs#197: v6 is a bug release, overdue - the burn-down to cut it

docs/data/roadmap.yaml

@@ -86,10 +86,13 @@ entries:
       one term, on both rebalance assignors, with the pre-fix arm failing every repetition and the
       fixed arm none. The family is not closed by it - the transactional revoke wait (astubbs#44,
       which carries upstream's verified-bug label) is a separate defect in a commit mode that fix
-      cannot reach, a third mechanism (a closing instance polling too little to leave its group
-      cleanly) has an open fix attempt in astubbs#444, and the family ledger
-      (`docs/inflight/bug-857-family.md`) still carries unattributed stall sightings reproducing on
-      trees that already carry astubbs#29's fix.
+      cannot reach - and on 2026-09-07 the owner placed it outside 0.6.0.0 for now, so the release
+      claim names it as the known exception rather than the release waiting on it. The suspected
+      third mechanism (a closing instance polling too little to leave its group cleanly) was measured
+      by astubbs#444 as the consumer-group protocol under the test's churn rate, not a PC defect. The
+      family ledger (`docs/inflight/bug-857-family.md`) still carries stall sightings on trees that
+      already carry astubbs#29's fix; the ones since classified are calibration and worker
+      saturation, not wedges.
     why_now: The release claim rests on it, and the evidence has to be inspectable rather than asserted.
     done_when: >-
       No known critical defect open in release scope, and each resolution has a named guard that
@@ -100,7 +103,7 @@ entries:
   - id: streams-parallelism-preview
     title: Give a Kafka Streams topology the per-key parallelism of Parallel Consumer
     serves: [flexibility, performance]
-    horizon: "0.6.0.0"
+    horizon: next-0x
     blocks_1_0: false
     stage: limited-poc
     stage_delivery: draft
@@ -117,7 +120,7 @@ entries:
   - id: connect-integration-preview
     title: Run a Kafka Connect sink with Parallel Consumer underneath
     serves: [flexibility]
-    horizon: "0.6.0.0"
+    horizon: next-0x
     blocks_1_0: false
     stage: limited-poc
     stage_delivery: draft

docs/inflight/ci-the-coverage-uploads-still-use-the-inert-glob.md

@@ -2,6 +2,7 @@
 
 <!-- inflight-type: bug -->
 <!-- inflight-impact: misdirection -->
+<!-- post-merge: checked - astubbs#475 is cited as the docs-only PR whose coverage flags both went green, which stays true after it merges -->
 <!-- inflight-state: closed - the stated delete-when now holds. Master's own two flags report DIFFERENT figures (at 49f81f155, `codecov/project/unit` 78.95% against `codecov/project/integration` 61.44%), which the identical-figure tell said could not happen while both flags held the same data; and astubbs#475, a PR with no `.java` in its diff, shows `codecov/project/unit` and `codecov/project/integration` both green. `maven.yml` carries the repair: `find`-built comma lists through `$GITHUB_OUTPUT`, `disable_search: true` on every `codecov/codecov-action` call, the master collector no longer on `always()`, and push runs keyed per SHA. Kept rather than deleted because [`docs/ci.md`](../ci.md) cites it and the files-count tell that separates the two causes is the part a later reader wants. -->
 <!-- inflight-vetted: 2026-09-08 - applied: closed per the accepted proposal, state marker added, body left as the record; checked: `maven.yml` has `disable_search: true` on each upload, the per-SHA push `concurrency` group, and the master collector without `always()`; `gh pr checks 475 -R astubbs/parallel-consumer` shows both per-flag gates passing -->
 

docs/inflight/process-candidate-ranking.md

@@ -55,16 +55,32 @@ astubbs/parallel-consumer#29 carried.
 
 ## What gates v6, as the sweep read it
 
-[`release-when-is-v6-good-enough.md`](release-when-is-v6-good-enough.md) set the bar as "the bugs
-that are already open". Six area sweeps each named what they read as gating (the owner's pass over
+Moved into `release-v6-scope.md` on 2026-09-08 and back here on 2026-09-09, because it is the
+sweep's dated reading rather than a decision; the burn-down's tiers override it where they
+disagree and say so there. Kept whole as the record.
+
+### The sweep's list, 2026-09-07
+
+Moved here from `process-candidate-ranking.md` on 2026-09-08 (it was written by the six-agent sweep
+on 2026-09-07 and is the agents' reading, with their stated confidence - not the owner's decision).
+Where it disagrees with the tiers above, the tiers say so: the poisoned-transaction pair (the sweep:
+not gating; the owner named it the second exception on 2026-09-09), the transactional revoke wait (the sweep read
+astubbs#466 as having replaced the unbounded wait, which is right, and astubbs#408 as owning the
+bound), and the `batchSize` validation bound (the sweep: cheapest real fix; the triage had filed
+it as 0.6.0.x, and the owner moved it into tier 1 on 2026-09-09). Item 2 in its list, the dead poll thread, is
+astubbs#477, merged.
+
+The bar above is "the bugs that are already open". Six area sweeps each named what they read as gating (the owner's pass over
 the sweep's proposals is done - [`process-inflight-vet-sweep.md`](process-inflight-vet-sweep.md)
 records it); this is the union,
 ordered by user-visible consequence, with the confidence each agent stated. The mechanical gate
 comes first because nothing else matters until it clears.
 
-- **The quarantine registry is non-empty, and every entry is unowned.** `release.yml` refuses the
-  cut while [`docs/quarantined-tests.md`](../quarantined-tests.md) lists anything; read that file,
-  not this line.
+- ~~**The quarantine registry is non-empty, and every entry is unowned.**~~ *The sweep's reading on
+  2026-09-07; the registry is empty on master (astubbs#80 emptied it and nothing has joined since),
+  which this note says in its tag-day checks.* `release.yml` refuses the cut while
+  [`docs/quarantined-tests.md`](../quarantined-tests.md) lists anything; read that file, not this
+  line.
 - **Verified defects, in the code as written today:**
   1. `bug-857-transactional-revoke-wait.md` - was the unbounded wait inside the revoke callback,
      with a user report carrying upstream's verified-bug label. astubbs#466 (merged the day the sweep
@@ -73,14 +89,15 @@ comes first because nothing else matters until it clears.
      `core-revoke-commit-skips-the-work-mailbox-drain.md` as gating - a deterministic exactly-once
      break with C9 refuted - and the same commit fixed it; the note is gone and the record is in
      `docs/solutions/logic-errors/`.
-  2. A dead poll thread holding its partitions for `max.poll.interval.ms` in the default commit mode -
-     read as gating, and traced end to end but untested and unfixed when the sweep ran. Now tested
-     and fixed: `maybeCloseConsumer` gained an arm for a poll thread that ended without closing the
-     consumer, the note is gone, and the record is in
-     `docs/solutions/logic-errors/a-duty-assigned-by-role-is-unassigned-when-the-role-holder-dies-2026-09-08.md`.
+  2. A dead poll thread holding its partitions for `max.poll.interval.ms` in the default commit
+     mode - read as gating, traced end to end but untested and unfixed when the sweep ran. Now
+     tested and fixed by astubbs#477 (merged): `maybeCloseConsumer` gained an arm for a poll thread
+     that ended without closing the consumer; the note is gone and the record is in
+     `docs/solutions/logic-errors/`.
   3. `pr-431-must-pair-its-queue-removal-with-the-shard-removal.md` with
      `bug-retry-queue-write-lock-on-the-rebalance-path.md` - the retry-queue orphan window; master
-     is still shard-first and astubbs#431 is a draft.
+     is still shard-first and astubbs#431 is a draft. *(Since overtaken: astubbs#431 closed as
+     superseded by the owner's astubbs#481, ready and green, which is what tier 1 lists.)*
   4. `batchSize(0)` silently processing nothing - read as the cheapest real fix in the set, and it
      was. Now fixed: `validate()` rejects zero, a negative and null, which is astubbs#311's
      validation half; the arithmetic half stays open in `bug-batch-quantity-over-request.md`. The
@@ -117,6 +134,66 @@ comes first because nothing else matters until it clears.
   by the shared-nothing rework); and the poisoned-transaction pair, where today's behaviour is
   strictly better than what it replaced.
 
+### Every open bug note's disposition against the v6 bar, as of 2026-09-08
+
+The sweep's reading above agrees with the look-at items below and added one this section had filed
+as 0.6.0.x: `batchSize(0)` silently processes nothing, and the sweep calls the `validate()` bound
+"the cheapest real fix in the set" (astubbs#311) - now in tier 1 by the owner's 2026-09-09 decision. Its list of instruments the release decision is
+read through that are currently lying or unproven is worth reading before trusting a green.
+
+"Gate on open bugs" only works if every open bug has a disposition, so this is every `bug-` note on
+master that no queue PR addresses (`ls docs/inflight/bug-*.md` is the list; the impact tag on each
+is the sort key). Re-derive it before the tag rather than trusting it: a note can gain a PR or lose
+its subject at any merge.
+
+**Look at before the tag - these contradict the release claim if left silent:**
+
+- ~~The eager-mode stall that reproduces with the fixes applied~~ - **withdrawn, astubbs#478 (merged)**
+  (2026-09-08): not a defect, a timing bound crossing on processor count. Nothing to ship or name.
+- ~~Poller death leaves the consumer open in consumer-commit modes~~ - **now astubbs#477 in tier 1**
+  (2026-09-08). The fix was as small as the note proposed, and its defect-class sweep - cleanup gated
+  on "am I the role-holder?" where the holder may be dead - found no other instance across the four
+  modules' `close()` paths.
+
+**Owner's decision - taken 2026-09-08: in v6, as astubbs#480 (tier 1).**
+
+- ~~Run-length plausibility ceiling~~ - a readable but absurd run length marked a vast range complete
+  and PC silently skipped it; data-loss class, reachable only through a corrupt or foreign payload,
+  which is why astubbs#207 did not cover it. astubbs#480 bounds every decoded run and bitset by the
+  partition's log end offset - the one bound that cannot reject a real map, since PC only encodes
+  offsets it polled - routed through `invalidOffsetMetadataPolicy` with no parallel policy, failing
+  open with a warn if the broker will not answer. The same defect class was found and fixed in the
+  bitset decoder; the simple serialisation has no declared count and is clean. The inflight note is
+  retired into `docs/solutions/`.
+
+**0.6.0.x - open, real, not a gate for a bug release:**
+
+- Config lies: `maxFailureHistory` is read nowhere; `offsetCommitTimeout` bounds two different
+  waits; `batchSize`'s over-request arithmetic (astubbs#311's other half, deferred) - its validation
+  bound is in tier 1 since 2026-09-09.
+- Blind spots: the racy and uncalled pause API; no metric for a discarded offset map under the
+  default `IGNORE` policy; the worker future swallowing framework exceptions.
+- Misdirection: the plain-`int` out-for-processing counter; the module's processor reference
+  overwritten before the owner guard; the rest of the unbounded-log-lines class; the two 857 mirror
+  attributions never verified against the reporter's environment.
+- Deferred with a reason in the note, and outside a bug release: the shard's available-work
+  counter undercounting after a stale replacement
+  ([`bug-processing-shard-available-work-undercount.md`](bug-processing-shard-available-work-undercount.md)
+  - a gauge inaccuracy that loses no records; the decision is whether the counter is worth keeping);
+  the deferred-commit WARN naming no offsets
+  ([`bug-deferred-commit-warn-names-no-offsets.md`](bug-deferred-commit-warn-names-no-offsets.md) -
+  astubbs#352 owns the method and adds the field the fix needs); and batching requesting a full
+  extra in-flight target ([`bug-batch-quantity-over-request.md`](bug-batch-quantity-over-request.md)
+  - throughput only).
+- The shutdown teardown race; the test-only `close()` shadowing; and
+  [`bug-shared-collections-across-the-poll-boundary.md`](bug-shared-collections-across-the-poll-boundary.md),
+  which is mostly stale - the metrics set and the shared empty set it names are both fixed on master
+  and the note needs shrinking to whatever remains.
+
+**Not a bug note, but a signal - settled:** the `simpleBatchTest` failures across the Reactor,
+Mutiny and Vert.x modules were the test's own randomised key draw, not the batcher (astubbs#482,
+see the known-unknowns section). The register's most-sighted row is retired.
+
 ## Ready picks
 
 Collisions are in `pr-blockers-and-collisions.md`. The ranked backlog and full verdicts live in

docs/inflight/release-0.6.0.0.md

@@ -127,7 +127,7 @@ worth.
 
 At release, when the changelog section is regenerated, check both survived into `=== Breaking`:
 generation reads the commit log, so they are only as findable as those commit bodies. The rename side
-of that same check is in [`release-0600-blockers.md`](release-0600-blockers.md).
+of that same check is in [`release-v6-scope.md`](release-v6-scope.md), under the tag-day artefact checks.
 
 ## Public API change landing with astubbs#204: the commit give-up exception
 
@@ -212,6 +212,22 @@ Evidence is in `docs/data/testing-evidence.yaml`; the checks to run are in
 `docs/data/module-maturity.yaml` under `release_validation`. If a check fails, amend the claim rather
 than waive the item.
 
+**The claim is amended, 2026-09-07: one known critical defect is outside 0.6.0.0's scope, and the
+release notes must name it.** The transactional revoke wait - astubbs#44, upstream's only
+verified-bug label, `PERIODIC_TRANSACTIONAL_PRODUCER` only; **bounded since astubbs#466 by
+`commitLockAcquisitionTimeout`, not yet declined** (astubbs#408 measures that bound and holds the decline seam; astubbs#466 refuted declining as the fix, so it is only the deadline fallback), so the release
+note says "bounded, not yet declined" rather than "unbounded" - detail in
+[`bug-857-transactional-revoke-wait.md`](bug-857-transactional-revoke-wait.md) - has its fix in
+astubbs#408, which depends on producer-fencing recovery (astubbs#410) by design, and the owner has
+placed that work after v6 for now. So the published sentence is not "every known critical defect",
+it is "every known critical defect except this one, which is named, reproduced, and fixed on a
+branch". **Amended again 2026-09-09: a second named exception, the poisoned-transaction wedge** -
+in `PERIODIC_TRANSACTIONAL_PRODUCER` mode a single record the producer rejects as too large is
+never aborted while the instance runs, so its partition stops for the life of the process; fixed
+by astubbs#434 on the same stack, outside 0.6.0.0 by the same decision, and named beside
+astubbs#44 rather than carried as a standalone abort. The standard is unchanged; the claim is what moved, which is the order this paragraph asks
+for. If astubbs#410 lands before the tag, delete this paragraph.
+
 **Deliberately not in this release:** virtual threads, micro-batching and the dead letter queue. These
 are new capabilities rather than known-defect exceptions, so deferring them does not weaken the gate.
 They carry horizons in `docs/data/roadmap.yaml`.