cross-tab-worker-databus 0.21.38 → 0.21.39

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,3 +1,15 @@
1
+ ## [0.21.39] - 2026-09-25
2
+
3
+ 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.
4
+
5
+ ### Fixed
6
+
7
+ - **`## [0.20.10]` said 2026-09-02; that release is 2026-09-03.** Its tag reads `2026-09-03T12:27:29+08:00` and the registry recorded the version at `2026-09-03T04:28:11Z` — the same instant, and the same calendar day under either frame, so no reading of either authority produces `09-02`. The neighboring `0.20.9` was tagged 2026-09-02T21:33+08:00, which is what the heading should have advanced past and did not. Correcting it is not a dated record being rewritten: the exemption in `AGENTS.md` covers numbers *measured* at the time (test counts, lag samples), whereas a release date has one answer that the repository and the registry both hold. Of the 151 sections that carry a tag, this was the only one dated outside both readings of its tag instant.
8
+
9
+ ### Added
10
+
11
+ - **`tests/documentation.test.ts` now compares every dated section with its tag.** For each `## [<version>] - <date>`, the date must be the calendar day of `v<version>`'s creation instant read either in UTC or in `+08:00`. The **tag** is the authority and not `time[<version>]`, because publishing lags tagging across a UTC midnight: `0.4.0`'s tag reads `2026-08-30T21:28Z` while its registry record reads `2026-08-31T00:03Z`, and `0.20.85` has the same shape — so a registry-keyed rule reports three bad sections where the tag reports one, and two of its three findings are the gate being wrong. Both frames are accepted because the prose genuinely uses both: over the tag-dated sections, 84 agree whichever frame is read, 46 only in `+08:00` and 20 only in UTC, so a single-frame rule would fail 66 rows that each describe a real event. Three controls ride along: a floor on how many sections were checked (a clone without tags would skip all of them and report a clean pass), an empty-instant case reported as a broken read rather than a skip, and an assertion that the checked rows span **both** tag object types — this repository tags releases both ways (92 lightweight, 59 annotated), and `%(creatordate)` is the only field that answers for the two, so `%(creatordate)` → `%(*creatordate)` reddens 92 sections rather than quietly emptying them. Mutation record in `docs/progress.md`. The same case also reads `docs/roadmap.md` and its Chinese mirror, because the release date ships *twice*: as this file's ISO section heading and as the roadmap preamble's written-out `September 25, 2026` / `2026 年 9 月 25 日`. The preamble is required to name the newest **tagged** release rather than `package.json`'s version, since while a release is being prepared the pending version legitimately has no tag yet, and a pattern that stops matching either language's preamble fails rather than skipping.
12
+
1
13
  ## [0.21.38] - 2026-09-25
2
14
 
3
15
  One English sentence in the shipped roadmap described a ratio backwards while its Chinese mirror had the direction right — the class of defect only a two-language comparison finds. No library behavior, export, option, default, frame or storage key changed; the coverage floors and the zero-count arm ledger are `0.21.37`'s.
@@ -1489,7 +1501,7 @@ No behavior, wire-format, storage-layout or cluster-protocol change: `git diff -
1489
1501
 
1490
1502
  - Release workflow runs one serialized job per tag and records the exact npm version, tag, and commit in the GitHub step summary for easier failure diagnosis.
1491
1503
 
1492
- ## [0.20.10] - 2026-09-02
1504
+ ## [0.20.10] - 2026-09-03
1493
1505
 
1494
1506
  ### Added
1495
1507
 
@@ -7,7 +7,7 @@ import {
7
7
  publicationMetadata,
8
8
  selectWorkerBackend,
9
9
  serializeError
10
- } from "./chunk-VWFEH3OS.js";
10
+ } from "./chunk-6DLLPWNT.js";
11
11
  import {
12
12
  CENTRIFUGE_INPUT_TYPE,
13
13
  CENTRIFUGE_OUTPUT_TYPE,
@@ -2475,7 +2475,7 @@ var SDK_VERSION = (
2475
2475
  // declaration's type is `string | undefined` and the export's is `string`
2476
2476
  // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
2477
2477
  // as a shape the harness cannot reach rather than as a case nobody exercised.
2478
- true ? "0.21.38" : ""
2478
+ true ? "0.21.39" : ""
2479
2479
  );
2480
2480
 
2481
2481
  // src/core/data-bus.ts
@@ -3715,4 +3715,4 @@ export {
3715
3715
  parseDataBusPublication,
3716
3716
  selectWorkerBackend
3717
3717
  };
3718
- //# sourceMappingURL=chunk-VWFEH3OS.js.map
3718
+ //# sourceMappingURL=chunk-6DLLPWNT.js.map
@@ -2604,7 +2604,7 @@ var SDK_VERSION = (
2604
2604
  // declaration's type is `string | undefined` and the export's is `string`
2605
2605
  // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
2606
2606
  // as a shape the harness cannot reach rather than as a case nobody exercised.
2607
- true ? "0.21.38" : ""
2607
+ true ? "0.21.39" : ""
2608
2608
  );
2609
2609
 
2610
2610
  // src/core/data-bus.ts
@@ -2570,7 +2570,7 @@ var SDK_VERSION = (
2570
2570
  // declaration's type is `string | undefined` and the export's is `string`
2571
2571
  // (dropping the conditional is TS2322, measured). Recorded here so the leg reads
2572
2572
  // as a shape the harness cannot reach rather than as a case nobody exercised.
2573
- true ? "0.21.38" : ""
2573
+ true ? "0.21.39" : ""
2574
2574
  );
2575
2575
 
2576
2576
  // src/core/data-bus.ts
package/dist/index.js CHANGED
@@ -20,7 +20,7 @@ import {
20
20
  selectRebalanceTarget,
21
21
  selectWorkerBackend,
22
22
  topicMatchesPattern
23
- } from "./chunk-VWFEH3OS.js";
23
+ } from "./chunk-6DLLPWNT.js";
24
24
  import {
25
25
  DEFAULT_STORAGE_PREFIX,
26
26
  PRUNE_STRATEGY,
package/docs/roadmap.md CHANGED
@@ -1,6 +1,12 @@
1
1
  # Roadmap
2
2
 
3
- 0.21.37 was released on September 25, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
3
+ 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.
4
+
5
+ ## 0.21.39 delivered scope
6
+
7
+ - **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.
8
+ - **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.
9
+ - **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.
4
10
 
5
11
  ## 0.21.38 delivered scope
6
12
 
@@ -1,6 +1,12 @@
1
1
  # 路线图
2
2
 
3
- 0.21.37 已于 2026 年 9 月 25 日发布。项目会先持续完成可靠性发布,再进入 1.0.0 稳定性冻结。
3
+ 0.21.38 已于 2026 年 9 月 25 日发布。项目会先持续完成可靠性发布,再进入 1.0.0 稳定性冻结。
4
+
5
+ ## 0.21.39 已完成范围
6
+
7
+ - **变更日志里有一个发布被标成了一个什么都没发生的日期。** `## [0.20.10]` 写的是 2026-09-02,而它的标签(`2026-09-03T12:27:29+08:00`)和它的 registry 记录(`2026-09-03T04:28:11Z`)是同一个瞬间,且在两种读法下同一天;它前一个发布的标签打在 09-02 的 21:33,所以那行标题只是没跟着往前走。这条已经改正,而在带标签的 151 个有日期的段落里,它是唯一一个落在自己标签两种读法之外的。
8
+ - **新增的检查以标签为准,而不是以 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` 同形。那三个"发现"里有两个是检查自己错了。
9
+ - **为什么两种框架都收,以及一次空读取为什么骗不过去。** 只收一种框架会让几十段各自描述真实事件的段落被判错(实测:84 段两种框架都对,46 段只在 `+08:00` 对,20 段只在 UTC 对),所以规则是"标签的某一种读法",不是"本地那一天"。对被检查段落数的下限,会把一个没有标签的克隆变成失败而不是干净通过;而要求被检查的行同时覆盖两种标签对象类型,挡住的正是它的静默版本——本仓库两种打标签方式都有,而只有 `%(creatordate)` 对两者都给出答案。 同级用例如从两种语言的路线图中读出同一个说法。那里的日期是写出来的(`September 25, 2026` / `2026 年 9 月 25 日`)而不是 ISO 标题,并且要求所写的版本是**已打标**的最新版本 —— 不是 `package.json` 的那个,因为在整个发布准备期间,待发布的版本还没有标签。
4
10
 
5
11
  ## 0.21.38 已完成范围
6
12
 
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "cross-tab-worker-databus",
3
- "version": "0.21.38",
3
+ "version": "0.21.39",
4
4
  "description": "Framework-agnostic cross-tab data bus with Dedicated/Shared Worker clustering and Centrifuge support.",
5
5
  "type": "module",
6
6
  "license": "MIT",