cross-tab-worker-databus 0.21.11 → 0.21.12

package/CHANGELOG.md

@@ -1,6 +1,13 @@
 ## [Unreleased]
 
 
+## [0.21.12] - 2026-09-23
+
+### Documentation
+- `README.md` and `README.zh.md` promised that "the persistence layer does not store connection addresses, raw Topic text, or message content" — two bullets below the line advertising the durable replay persistence that does exactly that. `replay-persistence.ts` creates its IndexedDB object store with `keyPath: 'topic'` and writes `{ topic, messages }` rows, so the plaintext topic is the store key and the publication payloads are its values, and `createIndexedDbReplayPersistence` is a public export named by the published-consumer verification script. The sentence now scopes itself to what it is true of (the worker/route/subscriber coordination records) and names both opt-ins that persist real content: `replay.persistence`, and `channelFallback: 'storage-event'`, which writes every coordination frame it carries — topic plaintext, and payloads on `PUBLISH` frames — into localStorage until the channel closes. The Chinese README additionally listed neither feature, so its reader received the privacy promise with no disclosure paired to it; both bullets are now present in both languages. This closes the `docs/` + README prose surface that the 0.21.11 sweep had named as unread; the per-file typedoc in `src/**` ships by a different route (bundled into `dist/`) and remains unaudited. Fourth release in this class after 0.21.7, 0.21.8 and 0.21.11 — and the second in a row.
+- `docs/release-checklist.md` (and its Chinese counterpart, which also ships) carried three claims that would misdirect a maintainer at the moment they most need the file to be accurate. **The published-consumer gate was documented as running "with the same budget as a manual run"; it does not** — the workflow passes `PUBLISHED_VERIFY_ATTEMPTS=48` / `PUBLISHED_VERIFY_DELAY_MS=7500` as its own env while `scripts/verify-published-consumer.mjs` defaults to 6 × 5000 ms, so a hand-run repeat reports `ETARGET` after 30 seconds against a tag whose CI run was green, which is indistinguishable from a failed publish. Measured on this very release: `v0.21.11` took 39 retries of 48 in a successful run and the offline repeat passed on its first attempt, so the checklist now states both budgets and how to reproduce the CI one. **CI was said to run "on every push and pull request"**, while both triggers in `ci.yml` are filtered to `branches: [main]` — a topic-branch push runs nothing, and the work is first covered when its PR opens. **And `bench:trend` was missing from the local-only list**, though it rewrites `docs/benchmarks.md` from the local archive and appears in no workflow, so a maintainer could conclude CI refreshes the trend doc.
+- The coverage-floors comment in `ci.yml` still named the pre-0.21.7 values (96/92/96/97) as what `vitest.config.ts` carries; the config, the shipped checklist and `AGENTS.md` all say 98/96/98/99, and only the workflow comment had drifted. Corrected. No behaviour, wire-format, storage-layout or cluster-protocol change, and no coverage movement: this release touches no `src/` or `tests/` file.
+
 ## [0.21.11] - 2026-09-23
 
 ### Documentation

package/README.md

@@ -38,7 +38,7 @@ By default each tab holds its own Dedicated Worker; when configured with `worker
 - Opt-in coordination fallback over localStorage storage events when BroadcastChannel is unavailable
 - After a tab exits abnormally, automatic migration happens via heartbeat TTL
 - Automatically degrades to local mode when BroadcastChannel or localStorage is unavailable
-- The persistence layer does not store connection addresses, raw Topic text, or message content
+- The coordination records in localStorage hold opaque keys only — no connection addresses, raw Topic text, credentials, or message content. Two opt-ins persist real content and are documented as trade-offs, not exceptions you can ignore: `replay.persistence` writes published payloads to IndexedDB in a store keyed by the plaintext Topic name, and `channelFallback: 'storage-event'` writes every coordination frame it carries — Topic names, and payloads on publications — into localStorage until that channel closes
 
 See the [Capabilities Matrix](./docs/capabilities.md) for the full list of implemented, unimplemented, and planned capabilities.
 
@@ -221,7 +221,7 @@ Only if you use the built-in Centrifuge backend (`cross-tab-worker-databus/centr
 
 ```bash
 pnpm install
-pnpm check          # typecheck + unit tests + build
+pnpm check          # typecheck + build + unit tests + the perf gates (run separately from `pnpm test`, and timing-sensitive)
 pnpm test:e2e       # Playwright multi-tab browser tests (requires Google Chrome)
 pnpm pack --pack-destination /tmp
 ```

package/README.zh.md

@@ -34,7 +34,9 @@
 - Transport 重连自动恢复当前 owner 的 Topic
 - Tab 异常退出后通过心跳 TTL 自动迁移
 - BroadcastChannel 或 localStorage 不可用时自动降级为本地模式
-- 持久层不存储连接地址、原始 Topic 文本和消息内容
+- 可选的 durable 回放持久化（`replay.persistence`），支持 `appendBatch` 批量写入（IndexedDB 事务合并；清理策略 `count` / `age` / `both`）
+- BroadcastChannel 不可用时，可选的 localStorage storage-event 协调降级通道（`channelFallback: 'storage-event'`）
+- localStorage 中的协调记录只保存不透明 key——不含连接地址、原始 Topic 文本、凭证或消息内容。两个需要显式开启的选项会写入真实内容，且被作为取舍记录在文档中而非可以忽略的例外：`replay.persistence` 把已发布的 payload 写进 IndexedDB，其对象仓以明文 Topic 为 key；`channelFallback: 'storage-event'` 则把它承载的每一帧协调消息——含 Topic 明文与 publication payload——写进 localStorage，直到该 channel 关闭
 
 完整能力清单见 [能力矩阵](./docs/zh/capabilities.md)。
 

package/dist/centrifuge.js

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

package/dist/{chunk-UO57SLQD.js → chunk-TSTV3SDC.js}

@@ -2390,7 +2390,7 @@ var DedupManager = class {
 };
 
 // src/core/version.ts
-var SDK_VERSION = true ? "0.21.11" : "";
+var SDK_VERSION = true ? "0.21.12" : "";
 
 // src/core/data-bus.ts
 var DEFAULT_REPLAY_MAX_PER_TOPIC = 100;
@@ -3592,4 +3592,4 @@ export {
   parseDataBusPublication,
   selectWorkerBackend
 };
-//# sourceMappingURL=chunk-UO57SLQD.js.map
+//# sourceMappingURL=chunk-TSTV3SDC.js.map

package/dist/cjs/centrifuge.cjs

@@ -2519,7 +2519,7 @@ var DedupManager = class {
 };
 
 // src/core/version.ts
-var SDK_VERSION = true ? "0.21.11" : "";
+var SDK_VERSION = true ? "0.21.12" : "";
 
 // src/core/data-bus.ts
 var DEFAULT_REPLAY_MAX_PER_TOPIC = 100;

package/dist/cjs/index.cjs

@@ -2485,7 +2485,7 @@ var DedupManager = class {
 };
 
 // src/core/version.ts
-var SDK_VERSION = true ? "0.21.11" : "";
+var SDK_VERSION = true ? "0.21.12" : "";
 
 // src/core/data-bus.ts
 var DEFAULT_REPLAY_MAX_PER_TOPIC = 100;

package/dist/index.js

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

package/docs/release-checklist.md

@@ -11,9 +11,9 @@ Use this checklist for each pre-1.0 release. Pushing the version tag *is* the pu
 
 ## Automated gates (CI)
 
-The `CI` workflow's `verify` job runs `pnpm check`, `pnpm lint`, `pnpm test:coverage` (the `vitest.config.ts` floors: 98% statements / 96% branches / 98% functions / 99% lines), `pnpm verify:compat`, `pnpm verify:pack`, `pnpm bench`, and `pnpm audit` on every push and pull request; the `browser` job runs the Playwright E2E suite. The `Release` workflow repeats `verify:compat` and `verify:pack` before publishing, then runs the blocking `verify:published` gate. The checkout in both workflows uses `fetch-depth: 0` + `fetch-tags: true` because `verify:compat` resolves its baseline from the most recent release tag.
+The `CI` workflow's `verify` job runs `pnpm check`, `pnpm lint`, `pnpm test:coverage` (the `vitest.config.ts` floors: 98% statements / 96% branches / 98% functions / 99% lines), `pnpm verify:compat`, `pnpm verify:pack`, `pnpm bench`, and `pnpm audit` on pushes and pull requests **that target `main`** — both triggers are filtered to `branches: [main]` in `ci.yml`, so pushing a topic branch runs nothing and CI first covers the work when its PR opens (a PR based on another branch is not covered either); the `browser` job runs the Playwright E2E suite. The `Release` workflow repeats `verify:compat` and `verify:pack` before publishing, then runs the blocking `verify:published` gate. The checkout in both workflows uses `fetch-depth: 0` + `fetch-tags: true` because `verify:compat` resolves its baseline from the most recent release tag.
 
-Only `pnpm bench:browser` / `pnpm bench:compare` stay local-only: shared-runner timing noise makes numeric CI gates unreliable.
+Only `pnpm bench:browser` / `pnpm bench:compare` / `pnpm bench:trend` stay local-only: shared-runner timing noise makes numeric CI gates unreliable, and `bench:trend` rewrites `docs/benchmarks.md` from the local archive, which CI must not do.
 
 ## Before tagging
 
@@ -30,7 +30,7 @@ The repository runs CodeQL (`javascript-typescript`; on push, on pull request, a
 
 ## Tagged-release workflow
 
-Pushing a version tag triggers the `Release` GitHub Action: it runs `pnpm check` and `pnpm lint` (a tag can point at a commit that never passed CI's lint step), runs `verify:compat` and `verify:pack`, opens the GitHub release from the `CHANGELOG` section, publishes to npm when the `NPM_TOKEN` secret is set, and then runs the **blocking** published-consumer verification with the same budget as a manual run (`PUBLISHED_VERIFY_ATTEMPTS=48`, `PUBLISHED_VERIFY_DELAY_MS=7500`, a 6-minute ceiling). A release whose published package cannot be imported by a clean consumer fails the workflow — treat every `verify:published` failure as a failed release. For registry propagation or infrastructure failures, rerun the workflow against the unchanged tag; for artifact defects, ship a new patch version. Never move or reuse a published tag. When no token is configured the publish step is skipped, but verification still passes against whatever version is already on npm (e.g. one published manually).
+Pushing a version tag triggers the `Release` GitHub Action: it runs `pnpm check` and `pnpm lint` (a tag can point at a commit that never passed CI's lint step), runs `verify:compat` and `verify:pack`, opens the GitHub release from the `CHANGELOG` section, publishes to npm when the `NPM_TOKEN` secret is set, and then runs the **blocking** published-consumer verification at a budget **twelve times the manual default** — the workflow sets `PUBLISHED_VERIFY_ATTEMPTS=48` and `PUBLISHED_VERIFY_DELAY_MS=7500` (a ~6-minute ceiling) in its own env, while `scripts/verify-published-consumer.mjs` defaults to 6 × 5000 ms = 30 s when run by hand. A release whose published package cannot be imported by a clean consumer fails the workflow — treat every `verify:published` failure as a failed release. For registry propagation or infrastructure failures, rerun the workflow against the unchanged tag; for artifact defects, ship a new patch version. Never move or reuse a published tag. When no token is configured the publish step is skipped, but verification still passes against whatever version is already on npm (e.g. one published manually).
 
 ## Publishing
 
@@ -42,4 +42,4 @@ For a manual release (no `NPM_TOKEN` in the workflow), run `npm publish --access
 2. Install the published tarball or version in a clean consumer and import the root plus every public subpath.
 3. Record the result in the release notes. Do not advance to `1.0.0` until the public API and protocol deprecation policy are explicitly frozen.
 
-The tagged-release workflow already ran the consumer verification above. Run `PUBLISHED_VERSION=<version> pnpm verify:published` by hand only when you need an offline repeat. The workflow's 6-minute ceiling absorbs normal npm CDN propagation lag (the 0.20.89 tag run exhausted the older 2-minute budget after a successful publish); raise `PUBLISHED_VERIFY_ATTEMPTS` / `PUBLISHED_VERIFY_DELAY_MS` further only for unusually slow mirrors.
+The tagged-release workflow already ran the consumer verification above. Run `PUBLISHED_VERSION=<version> pnpm verify:published` by hand only when you need an offline repeat. The workflow's 6-minute ceiling absorbs normal npm CDN propagation lag (the 0.20.89 tag run exhausted the older 2-minute budget after a successful publish); raise `PUBLISHED_VERIFY_ATTEMPTS` / `PUBLISHED_VERIFY_DELAY_MS` further only for unusually slow mirrors. Note the asymmetry when repeating by hand: `verify-published-consumer.mjs` defaults to `6` attempts × `5_000` ms — 30 seconds, not 6 minutes — because the tag run passes the larger pair as env rather than the script owning it. So a manual repeat can report `ETARGET` on a version whose CI run was green, which reads like a failed publish and is not one; reproduce the CI budget explicitly with `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=48 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`, or judge a manual failure against the 30 s budget you actually ran. Expect ~39 retries of 48 in a *green* tag run: registry propagation, not a symptom.

package/docs/roadmap.md

@@ -1,7 +1,32 @@
 # Roadmap
 
-0.21.11 was released on September 23, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
-
+0.21.12 was released on September 23, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
+
+## 0.21.12 delivered scope
+
+- The prose sweep finished where it started: the README. `README.md` and `README.zh.md` promised
+  "the persistence layer does not store connection addresses, raw Topic text, or message content"
+  two bullets under the line advertising the durable replay persistence that does precisely that —
+  its IndexedDB store is created with `keyPath: 'topic'` and its rows carry the publication payloads,
+  and the factory is a public export. The claim is now scoped to the coordination records it is true
+  of, and both opt-ins that persist real content are named beside it. The Chinese list also gained
+  the two feature bullets it never had, so the promise no longer stands without its disclosure.
+- `docs/release-checklist.md`, which ships in the tarball, held three traps. The published-consumer
+  gate was said to run "with the same budget as a manual run" — the workflow passes 48 × 7500 ms as
+  its own env while the script defaults to 6 × 5000 ms, so a hand-run repeat hits `ETARGET` after 30
+  seconds on a tag whose CI run was green. Measured on `v0.21.11`: 39 retries of 48 in a successful
+  run, and the offline repeat passed first try. Both budgets are now stated, with the command that
+  reproduces the CI one. CI was described as running on "every push and pull request" although both
+  triggers are filtered to `branches: [main]`, and `bench:trend` was missing from the local-only list
+  despite rewriting `docs/benchmarks.md` from the local archive.
+- The `ci.yml` comment naming the coverage floors still said 96/92/96/97 after 0.21.7 raised them to
+  98/96/98/99; the config, the shipped checklist and `AGENTS.md` already agreed, so only the comment
+  had drifted. Corrected, and `AGENTS.md` now records how the sweep concluded: an audit of "the option
+  surface" covers the tables, while the paragraph under the same heading and the README's summary
+  bullets are separate claims — and the sentence shape worth hunting first is an absolute about
+  storage, because one opt-in is enough to break it.
+- No behaviour, wire-format, storage-layout or cluster-protocol change, and no `src/` or `tests/`
+  file was touched. Coverage stays at 99.01 / 96.90 / 99.26 / 99.69 over **895** tests.
 ## 0.21.11 delivered scope
 
 - A prose audit of the four docs files no earlier sweep had covered — `architecture.md`,

package/docs/zh/release-checklist.md

@@ -11,9 +11,9 @@
 
 ## 自动化门禁（CI）
 
-`CI` 工作流的 `verify` job 在每次 push 与 pull request 上运行 `pnpm check`、`pnpm lint`、`pnpm test:coverage`（`vitest.config.ts` 中的下限：语句 98% / 分支 96% / 函数 98% / 行 99%）、`pnpm verify:compat`、`pnpm verify:pack`、`pnpm bench` 与 `pnpm audit`；`browser` job 运行 Playwright E2E 套件。`Release` 工作流在发布前重跑 `verify:compat` 与 `verify:pack`，随后执行阻塞式 `verify:published` 门禁。两个工作流的 checkout 均使用 `fetch-depth: 0` + `fetch-tags: true`，因为 `verify:compat` 需要从最近的发布 tag 解析基线。
+`CI` 工作流的 `verify` job 在**以 `main` 为目标分支**的 push 与 pull request 上运行 `pnpm check`、`pnpm lint`、`pnpm test:coverage`（`vitest.config.ts` 中的下限：语句 98% / 分支 96% / 函数 98% / 行 99%）、`pnpm verify:compat`、`pnpm verify:pack`、`pnpm bench` 与 `pnpm audit`——`ci.yml` 里两个触发器都被过滤为 `branches: [main]`，因此推送 topic 分支什么都不会跑，这项工作要到开出 PR 时才第一次进入 CI（base 不是 main 的 PR 同样不在覆盖范围内）；`browser` job 运行 Playwright E2E 套件。`Release` 工作流在发布前重跑 `verify:compat` 与 `verify:pack`，随后执行阻塞式 `verify:published` 门禁。两个工作流的 checkout 均使用 `fetch-depth: 0` + `fetch-tags: true`，因为 `verify:compat` 需要从最近的发布 tag 解析基线。
 
-只有 `pnpm bench:browser` / `pnpm bench:compare` 保持仅本地执行：共享 runner 的计时噪声会让数值型 CI 门禁不可靠。
+只有 `pnpm bench:browser` / `pnpm bench:compare` / `pnpm bench:trend` 保持仅本地执行：共享 runner 的计时噪声会让数值型 CI 门禁不可靠，而 `bench:trend` 会依据本地归档重写 `docs/benchmarks.md`，这本就不该由 CI 来做。
 
 ## 打 tag 前
 
@@ -30,7 +30,7 @@
 
 ## 打 tag 的发布工作流
 
-推送版本 tag 会触发 `Release` GitHub Action：先跑 `pnpm check` 与 `pnpm lint`（tag 可能指向从未通过 CI lint 步骤的提交），再跑 `verify:compat` 与 `verify:pack`，从 `CHANGELOG` 对应章节生成 GitHub release，配置了 `NPM_TOKEN` 时自动发布到 npm，然后运行与手动执行相同预算的**阻塞式**消费者验证（`PUBLISHED_VERIFY_ATTEMPTS=48`、`PUBLISHED_VERIFY_DELAY_MS=7500`，即 6 分钟上限）。已发布包若无法被干净消费者导入，工作流即失败——任何 `verify:published` 失败都应视为发布失败。若为 registry 传播延迟或基础设施故障，针对不变的 tag 重跑工作流；若为产物缺陷，发布新的 patch 版本。禁止移动或重用已发布 tag。未配置 token 时跳过发布步骤，但验证仍会针对 npm 上已有的版本（例如手动发布的）通过。
+推送版本 tag 会触发 `Release` GitHub Action：先跑 `pnpm check` 与 `pnpm lint`（tag 可能指向从未通过 CI lint 步骤的提交），再跑 `verify:compat` 与 `verify:pack`，从 `CHANGELOG` 对应章节生成 GitHub release，配置了 `NPM_TOKEN` 时自动发布到 npm，然后运行**阻塞式**消费者验证，其预算是手动默认值的十二倍——工作流在自己的 env 里设置 `PUBLISHED_VERIFY_ATTEMPTS=48`、`PUBLISHED_VERIFY_DELAY_MS=7500`（约 6 分钟上限），而手动运行 `scripts/verify-published-consumer.mjs` 时的默认值是 6 × 5000 ms = 30 秒。已发布包若无法被干净消费者导入，工作流即失败——任何 `verify:published` 失败都应视为发布失败。若为 registry 传播延迟或基础设施故障，针对不变的 tag 重跑工作流；若为产物缺陷，发布新的 patch 版本。禁止移动或重用已发布 tag。未配置 token 时跳过发布步骤，但验证仍会针对 npm 上已有的版本（例如手动发布的）通过。
 
 ## 发布（手动场景）
 
@@ -42,4 +42,4 @@
 2. 在干净消费者中安装已发布版本或 tarball，并导入主入口及所有公开子路径。
 3. 将结果记录到发布说明。在公开 API 和协议弃用策略明确冻结前，不进入 `1.0.0`。
 
-打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流默认的 6 分钟上限足以吸收 npm CDN 的正常传播延迟（0.20.89 tag 首次运行在发布成功后排空了旧的 2 分钟预算）；只有遇到异常慢的镜像才需要继续调大 `PUBLISHED_VERIFY_ATTEMPTS` 和 `PUBLISHED_VERIFY_DELAY_MS`。
+打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流默认的 6 分钟上限足以吸收 npm CDN 的正常传播延迟（0.20.89 tag 首次运行在发布成功后排空了旧的 2 分钟预算）；只有遇到异常慢的镜像才需要继续调大 `PUBLISHED_VERIFY_ATTEMPTS` 和 `PUBLISHED_VERIFY_DELAY_MS`。手动复验时要注意这个不对称：`verify-published-consumer.mjs` 的默认值是 `6` 次 × `5_000` ms——30 秒而不是 6 分钟——因为更大的那一对是由 tag 工作流以 env 传入、而非脚本自带。于是手动复跑可能在一个 CI 全绿的版本上报出 `ETARGET`，这看起来像发布失败而实际不是；要对齐 CI 预算就显式执行 `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=48 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`，否则请按你实际跑到的 30 秒预算来判断手动失败。*绿色*的 tag 运行里出现约 39/48 次重试是预期内的：那是 registry 传播，不是症状。

package/docs/zh/roadmap.md

@@ -1,7 +1,26 @@
 # 路线图
 
-0.21.11 已于 2026 年 9 月 23 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
-
+0.21.12 已于 2026 年 9 月 23 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
+
+## 0.21.12 已完成范围
+
+- 文案审计回到了它的起点：README。`README.md` 与 `README.zh.md` 承诺"持久层不存储连接地址、原始
+  Topic 文本和消息内容"，而这句话的两条之上正是在宣传那份 durable 回放持久化——它的 IndexedDB 对象仓以
+  `keyPath: 'topic'` 创建，行里保存着 publication payload，而工厂函数是公开导出。该说法现在被收敛到它确实
+  成立的范围（协调记录），并把两个会写入真实内容的可选开关点名列出。中文特性列表还补上了它此前完全缺失的两条
+  feature 条目，于是不再出现"只有隐私承诺、没有对应披露"的读法。
+- 随包分发的 `docs/release-checklist.md` 里有三处会在关键时刻误导维护者。发布后消费者验证门禁被描述为"与手动
+  执行相同预算"——实际上工作流以自身 env 传入 48 × 7500 ms，而脚本默认是 6 × 5000 ms，于是手动复跑会在一个 CI
+  全绿的 tag 上 30 秒后报 `ETARGET`。以 `v0.21.11` 实测：成功的那次运行重试了 48 次中的 39 次，而离线复验首次即
+  通过。现在两个预算都已写明，并给出复现 CI 预算的命令。CI 被写成"在每次 push 与 pull request 上运行"，而两个
+  触发器都被过滤为 `branches: [main]`；`bench:trend` 也从"仅本地"清单里漏掉了，尽管它会依据本地归档重写
+  `docs/benchmarks.md`。
+- `ci.yml` 中记录覆盖率下限的注释在 0.21.7 把下限提升到 98/96/98/99 之后仍写着 96/92/96/97；配置、随包的分发
+  清单与 `AGENTS.md` 早已一致，只有注释发生了漂移，现已修正。`AGENTS.md` 同时记录了这轮扫描的结论：审计"选项
+  面"覆盖的是表格，而同一标题下的段落与 README 的摘要条目是彼此独立的说法——最值得优先搜寻的句式是关于存储的绝对
+  表述，因为一个可选开关就足以把它击穿。
+- 无行为、wire 格式、存储布局或集群协议变更，且本发布未触碰任何 `src/` 或 `tests/` 文件。覆盖率保持
+  99.01 / 96.90 / 99.26 / 99.69，共 **895** 个测试。
 ## 0.21.11 已完成范围
 
 - 一轮针对此前从未被扫过的四个文档文件（`architecture.md`、`capabilities.md`、`getting-started.md`、

package/package.json

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