cross-tab-worker-databus 0.21.39 → 0.21.40

package/CHANGELOG.md

@@ -1,3 +1,16 @@
+## [0.21.40] - 2026-09-25
+
+`0.21.39` added a gate, then replaced that gate's rule in the test -- and the prose describing the gate, written a day earlier by the release-prep PR, was in a file the fix never opened. So the notes that shipped with `0.21.39` state the requirement its own fix deleted. No library behavior, export, option, default, frame or storage key changed; the coverage floors and the zero-count arm ledger are `0.21.39`'s.
+
+### Fixed
+
+- **Both roadmap languages still required the preamble to name the newest \*tagged\* release.** That is the rule which killed Release run 159, and PR #328 replaced it in `tests/documentation.test.ts` with the set that holds at every buildable moment: the greatest tag strictly below `package.json`'s version, plus that version once its own tag exists. The sentence fails in exactly the state the fix was for -- a release's own tag build, where `package.json`'s tag *is* the newest tag while the preamble legitimately still names the previous release, because the record commit that advances it lands after the tag. Corrected here in `docs/roadmap.md` and `docs/zh/roadmap.md`, inside the `0.21.39` block where the claim sits. The third copy -- this file's own `0.21.39` `### Added` bullet -- stands, and the line to state is why that does not contradict `0.20.10`'s heading being corrected in the section below: that heading was never true of anything -- no event of that release happened on the day it names -- whereas this sentence was true of the release that shipped it and was superseded inside its own version's lifecycle. A wrong record is corrected; a superseded one is left standing, and the correction is filed against the copies that still instruct a reader. `0.21.35`'s three-sample sentence sits on the second footing, and note how thinly that precedent is actually honoured here: nothing in this file retracts it. The only later text that contradicts it is `0.21.37`'s series bullet, which prints `127.3` and `126.4` beside the three without naming the claim those two falsify -- the retraction itself went into `AGENTS.md` and `docs/progress.md`, neither of which is in the tarball.
+
+### Added
+
+- **The preamble rule's release-cycle moments are tabulated, because the live case can only ever see the one the repository happens to be in.** `allowedPreambleVersions(packageVersion, tagRefs)` is extracted from that case and exercised over ten synthetic rows: prep, tag build, record commit, two-releases-behind in each of the first two, a preamble naming an untagged version, a clone carrying a *newer* tag, and double-digit minors where a lexical sort would pick the wrong winner. That the table was needed is measured, not asserted: against the live case alone (probe and mutation record in `docs/progress.md`), deleting the "own tag counts" member reddens it, while deleting the filter that keeps tags at-or-above `packageVersion` out of the previous tag does **not**, and neither does turning `>=` into `>` -- two of the rule's three legs had no test that could see them, and one of those two *is* the run-159 bug. After the extraction all four mutants die, and the probe records where each one lands: M2 and M3 both fail the tag-build row (`>=` widened to `>`, and the filter dropped, produce the same wrong `previousTag` there), M4 -- numeric sort made lexical -- fails the double-digit-minor row with `allowed [0.9.0]`, and M1 fails only the table's record-commit row, `allowed [0.21.38]`. That last asymmetry is the finding rather than a detail: on a *prep* tree, where `package.json`'s version has no tag yet, the own-tag member contributes nothing to the live case at all, so the leg that decides whether a released version may name itself is visible only in the synthetic moment. Which is the argument for the table.
+- **The lag sweep's `p50` is named and pinned.** `scripts/publication-lag.mjs` reports the upper-middle element (`sorted[floor(n/2)]`), not the mean of the two middle values; the two coincide at odd `n` and not at even `n`, so one added sample moves the printed figure with nothing changed in what is measured -- the modern gap window read `p50=97.3` at `n=45` and `p50=126.4` at `n=46`, where the interpolated median of those same values is `111.85`. `tests/publication-lag.test.ts` now pins which convention the line uses, and the header's `EXCLUDED-NON-SUCCESS` note is corrected to say it names a run the sweep passed over rather than a verdict on the tag: `v0.21.39` prints that line *and* its own reading, having shipped from a re-pointed ref.
+
 ## [0.21.39] - 2026-09-25
 
 One section of this file carried a date on which no release event happened — not a figure that aged, but a line written a day behind the one above it. The check that now reads every section date does so against the tag rather than against npm, and the two rows that forced that choice are recorded below. No library behavior, export, option, default, frame or storage key changed; the coverage floors and the zero-count arm ledger are `0.21.38`'s.

package/dist/centrifuge.js

@@ -7,7 +7,7 @@ import {
   publicationMetadata,
   selectWorkerBackend,
   serializeError
-} from "./chunk-6DLLPWNT.js";
+} from "./chunk-HWGWX4M4.js";
 import {
   CENTRIFUGE_INPUT_TYPE,
   CENTRIFUGE_OUTPUT_TYPE,

package/dist/{chunk-6DLLPWNT.js → chunk-HWGWX4M4.js}

@@ -2475,7 +2475,7 @@ var SDK_VERSION = (
   // declaration's type is `string | undefined` and the export's is `string`
   // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
   // as a shape the harness cannot reach rather than as a case nobody exercised.
-  true ? "0.21.39" : ""
+  true ? "0.21.40" : ""
 );
 
 // src/core/data-bus.ts
@@ -3715,4 +3715,4 @@ export {
   parseDataBusPublication,
   selectWorkerBackend
 };
-//# sourceMappingURL=chunk-6DLLPWNT.js.map
+//# sourceMappingURL=chunk-HWGWX4M4.js.map

package/dist/cjs/centrifuge.cjs

@@ -2604,7 +2604,7 @@ var SDK_VERSION = (
   // declaration's type is `string | undefined` and the export's is `string`
   // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
   // as a shape the harness cannot reach rather than as a case nobody exercised.
-  true ? "0.21.39" : ""
+  true ? "0.21.40" : ""
 );
 
 // src/core/data-bus.ts

package/dist/cjs/index.cjs

@@ -2570,7 +2570,7 @@ var SDK_VERSION = (
   // declaration's type is `string | undefined` and the export's is `string`
   // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
   // as a shape the harness cannot reach rather than as a case nobody exercised.
-  true ? "0.21.39" : ""
+  true ? "0.21.40" : ""
 );
 
 // src/core/data-bus.ts

package/dist/index.js

@@ -20,7 +20,7 @@ import {
   selectRebalanceTarget,
   selectWorkerBackend,
   topicMatchesPattern
-} from "./chunk-6DLLPWNT.js";
+} from "./chunk-HWGWX4M4.js";
 import {
   DEFAULT_STORAGE_PREFIX,
   PRUNE_STRATEGY,

package/docs/roadmap.md

@@ -1,12 +1,18 @@
 # Roadmap
 
-0.21.38 was released on September 25, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
+0.21.39 was released on September 25, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
+
+## 0.21.40 delivered scope
+
+- **The release notes described the rule their own fix had deleted.** `0.21.39`'s third bullet required the roadmap preamble to name the newest *tagged* release; PR #328 — the reason `0.21.39` exists at all — replaced that with "the greatest tag below `package.json`'s version, or that version once it is tagged", and changed only the test and `AGENTS.md`. Both roadmap copies are corrected where they stand; the `CHANGELOG.md` copy is left as that release published it, on the same footing as `0.21.35`'s three-sample sentence.
+- **The rule is now exercised across the release cycle, not at whatever moment the clone happens to sit in.** `allowedPreambleVersions()` is extracted from the live-file case and tabled over ten rows: prep, the tag build, the record commit, two releases behind, a preamble naming a version that was never tagged, a clone carrying a newer tag, and double-digit minors where a lexical sort picks the wrong winner. Before and after, measured: with only the live case, two of the rule's three legs — including the one that broke release run 159 — survived every mutant tried against them. After the table all four die, and where they die is itself the point: two land on the tag-build row, one on the double-digit-minor row, and the member that admits a released version's own tag fails **nowhere in the live files** — on a prep tree, where `package.json`'s version is not tagged yet, that leg contributes nothing an end-state read can see, so it is decidable only in a synthesized moment.
+- **The lag sweep's printed median is named for what it is.** Its `p50` is the upper-middle element rather than the mean of the middle two, so adding one sample to an odd-length series moves the figure on its own: the modern gap window went `97.3 → 126.4`, where the interpolated median of those same values is `111.85`. Pinned in `tests/publication-lag.test.ts`, whose `n=2` fixture is the only shape that exposes the whole sorted list.
 
 ## 0.21.39 delivered scope
 
 - **One release in this changelog was dated on a day nothing happened.** `## [0.20.10]` said 2026-09-02 while its tag (`2026-09-03T12:27:29+08:00`) and its registry record (`2026-09-03T04:28:11Z`) are the same instant on the same day under either reading; the release before it was tagged at 21:33 on 09-02, so the heading simply never advanced. It is corrected, and of the 151 dated sections that carry a tag it was the only one outside both readings of its own tag.
 - **The new check keys on the tag, not on npm, and that choice is measured.** `tests/documentation.test.ts` now requires each section date to be the calendar day of its tag instant in either the UTC or the `+08:00` frame. Keying the same rule on `time[<version>]` would report three bad sections instead of one, because publishing finishes after midnight UTC far often enough to matter: `0.4.0` is tagged 2026-08-30T21:28Z and recorded 2026-08-31T00:03Z, and `0.20.85` has the same shape. Two of those three "findings" would have been the gate being wrong.
-- **Why both frames, and what stops an empty read from passing.** Accepting only one frame fails dozens of sections that each describe a real event (measured: 84 agree in either frame, 46 only in `+08:00`, 20 only in UTC), so the rule is "some reading of the tag", not "the local day". A floor on the number of sections checked turns a clone with no tags into a failure instead of a clean pass, and an assertion that the checked rows span both tag object types catches the silent version of that — this repository tags releases both ways, and only `%(creatordate)` answers for the two. A sibling case reads the same claim from both roadmap languages, where the date is written out (`September 25, 2026` / `2026 年 9 月 25 日`) rather than as an ISO heading, and requires the named version to be the newest *tagged* one — not `package.json`'s, which is ahead of the tag for the whole duration of a release prep.
+- **Why both frames, and what stops an empty read from passing.** Accepting only one frame fails dozens of sections that each describe a real event (measured: 84 agree in either frame, 46 only in `+08:00`, 20 only in UTC), so the rule is "some reading of the tag", not "the local day". A floor on the number of sections checked turns a clone with no tags into a failure instead of a clean pass, and an assertion that the checked rows span both tag object types catches the silent version of that — this repository tags releases both ways, and only `%(creatordate)` answers for the two. A sibling case reads the same claim from both roadmap languages, where the date is written out (`September 25, 2026` / `2026 年 9 月 25 日`) rather than as an ISO heading. The version it names must be either the release before `package.json`'s, or `package.json`'s own once that tag exists — because the preamble is advanced by the record commit, which lands *after* the tag, so on the build of a release's own tag the newest tag is exactly the version the preamble has not reached. Corrected in `0.21.40`: this sentence first read "the newest *tagged* release, not `package.json`'s", which is the rule that killed release run 159 and that the same release's fix replaced, in the test only.
 
 ## 0.21.38 delivered scope
 

package/docs/zh/roadmap.md

@@ -1,12 +1,18 @@
 # 路线图
 
-0.21.38 已于 2026 年 9 月 25 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
+0.21.39 已于 2026 年 9 月 25 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
+
+## 0.21.40 已完成范围
+
+- **发布说明描述的是它自己的修复已经删掉的那条规则。** `0.21.39` 的第三条要求路线图的 preamble 写出*已打标*的最新版本；而 PR #328 —— `0.21.39` 之所以存在的理由 —— 把它换成了"`package.json` 版本之下最大的那个标签，或者等它打上标签之后就是它自己"，并且只改了测试和 `AGENTS.md`。两种语言的路线图副本都在原处更正；`CHANGELOG.md` 里的那一份照它发布时的样子留着，和 `0.21.35` 那句三个样本的结论同等对待。
+- **这条规则现在跨越整个发布周期被检验，而不是停在克隆恰好处于的那一瞬间。** `allowedPreambleVersions()` 从读真实文件的用例里抽出来，铺成十行：准备、标签构建、记录提交、落后两个发布、preamble 写了一个从未打标的版本、克隆里带着一个更新的标签，以及两位数小版本号（按字典序排序会挑错赢家）。前后都是量出来的：只有真实文件用例时，这条规则三条腿里的两条 —— 包括让 Release run 159 失败的那一条 —— 对所有朝它们下的变异都存活。写成表里的行之后，四个变异都会死，而死在哪儿本身就是结论：两个落在"标签构建"那一行，一个落在"两位数小版本号"那一行，而"承认某个已发布版本自己的标签"这一条，在真实文件里**哪儿都不死** —— 在准备阶段的那棵树上，`package.json` 的版本还没打标签，这条腿对任何终态读取都不产生可见贡献，所以它只能在合成出来的瞬间里被判定。
+- **滞后扫描打印的中位数，按它本来的名字说明。** 那里的 `p50` 是中间偏上的那一个元素，不是中间两个的平均值，所以往奇数长度的序列里再加一个样本，数字自己就会动：现代窗口从 `97.3` 到 `126.4`，而同样那批值的插值中位数是 `111.85`。钉在 `tests/publication-lag.test.ts` 里 —— 那里 `n=2` 的 fixture 是唯一能把排序后的列表整个暴露出来的形状。
 
 ## 0.21.39 已完成范围
 
 - **变更日志里有一个发布被标成了一个什么都没发生的日期。** `## [0.20.10]` 写的是 2026-09-02，而它的标签（`2026-09-03T12:27:29+08:00`）和它的 registry 记录（`2026-09-03T04:28:11Z`）是同一个瞬间，且在两种读法下同一天；它前一个发布的标签打在 09-02 的 21:33，所以那行标题只是没跟着往前走。这条已经改正，而在带标签的 151 个有日期的段落里，它是唯一一个落在自己标签两种读法之外的。
 - **新增的检查以标签为准，而不是以 npm 为准，而且这个选择是量出来的。** `tests/documentation.test.ts` 现在要求每个段落日期，是其标签瞬间在 UTC 或 `+08:00` 任一框架下的日历日。把同一条规则改成用 `time[<version>]`，会报出三个错段落而不是一个，因为发布完成的时间跨过 UTC 零点的情况多到不能忽略：`0.4.0` 的标签是 2026-08-30T21:28Z，记录却是 2026-08-31T00:03Z，`0.20.85` 同形。那三个"发现"里有两个是检查自己错了。
-- **为什么两种框架都收，以及一次空读取为什么骗不过去。** 只收一种框架会让几十段各自描述真实事件的段落被判错（实测：84 段两种框架都对，46 段只在 `+08:00` 对，20 段只在 UTC 对），所以规则是"标签的某一种读法"，不是"本地那一天"。对被检查段落数的下限，会把一个没有标签的克隆变成失败而不是干净通过；而要求被检查的行同时覆盖两种标签对象类型，挡住的正是它的静默版本——本仓库两种打标签方式都有，而只有 `%(creatordate)` 对两者都给出答案。 同级用例如从两种语言的路线图中读出同一个说法。那里的日期是写出来的（`September 25, 2026` / `2026 年 9 月 25 日`）而不是 ISO 标题，并且要求所写的版本是**已打标**的最新版本 —— 不是 `package.json` 的那个，因为在整个发布准备期间，待发布的版本还没有标签。
+- **为什么两种框架都收，以及一次空读取为什么骗不过去。** 只收一种框架会让几十段各自描述真实事件的段落被判错（实测：84 段两种框架都对，46 段只在 `+08:00` 对，20 段只在 UTC 对），所以规则是"标签的某一种读法"，不是"本地那一天"。对被检查段落数的下限，会把一个没有标签的克隆变成失败而不是干净通过；而要求被检查的行同时覆盖两种标签对象类型，挡住的正是它的静默版本——本仓库两种打标签方式都有，而只有 `%(creatordate)` 对两者都给出答案。 同级用例如从两种语言的路线图中读出同一个说法。那里的日期是写出来的（`September 25, 2026` / `2026 年 9 月 25 日`）而不是 ISO 标题。它所写的版本必须是 `package.json` 那一个之前最新的已打标发布，或者在它的标签已经存在之后，就是 `package.json` 自己 —— 因为 preamble 由记录提交推进，而那次提交落在标签**之后**，所以在某一个发布自己的标签构建上，最新的标签恰恰是 preamble 还没写到的那个版本。`0.21.40` 更正：这句话最初要求的是"已打标的最新版本，而不是 `package.json` 的那个"，而那正是让 Release run 159 失败、并由同一个版本的修复只在测试里替换掉的规则。
 
 ## 0.21.38 已完成范围
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cross-tab-worker-databus",
-  "version": "0.21.39",
+  "version": "0.21.40",
   "description": "Framework-agnostic cross-tab data bus with Dedicated/Shared Worker clustering and Centrifuge support.",
   "type": "module",
   "license": "MIT",