cross-tab-worker-databus 0.21.52 → 0.21.53

package/CHANGELOG.md

@@ -1,3 +1,20 @@
+## [0.21.53] - 2026-10-24
+
+The release checklist tells the reader to re-derive the publish-lag series after cutting a release. Until now it never said what the tool's failure words mean, and two of the seven it can print read as "your release did not publish" when the instrument is actually saying "this read is not usable". Documentation only; no behavior, API shape, export, default, frame or storage key changed, and the coverage floors and the zero-count arm ledger are `0.21.51`'s.
+
+### Documentation
+
+- **The lag sweep's verdict vocabulary, in both languages.** Four labels — `API-FAIL`, `NO-STEP`, `NO-PUBLISH`, `PENDING-STEP` — are claims about the *read* and say nothing about the publish; `PENDING-STEP` in particular is fixed by re-running, because GitHub backfills per-step metadata after the run row closes, so a series re-derived in the minute after a release cannot see the ack it is measuring. `NEGATIVE` is a real reading in a different regime (the registry stamped before the ack returned). Only `EXCLUDED-NON-SUCCESS` and `NO-RECORD` name genuine absences, and they name two different ones: a run that did not end green, and a version the registry never recorded.
+
+### Added
+
+- **A gate over that vocabulary.** A documentation case now reads the verdict labels out of `scripts/publication-lag.mjs` itself and requires each one to appear in both checklists, with a floor on the script side so an extraction that found nothing cannot pass vacuously. The gap this closes was created by the previous release cycle's own fix, which is the reason the set is derived rather than listed: `0.21.48` established that no check catches an item missing from a set, only a wrong one present in it.
+
+### Verification
+
+- `pnpm check` — 40 files and **1039 tests** (+1 case), plus the 5 perf gates; `pnpm lint`; `tests/documentation.test.ts` at 26 in both languages.
+- Both directions of the new gate were killed by one mutant each — deleting a label from the English checklist, and renaming a verdict in the script — with the inserted-diff count asserted before every run. The added sentences' digit multisets were compared after isolating them from the surrounding paragraph (identical, two tokens each, non-empty on both sides).
+
 ## [0.21.52] - 2026-10-24
 
 `npm publish` has been re-running the entire gate set on every release, and no check in this repository could see it. The finding is an omission rather than a bug — which is why it survived until the question was asked in the inverse direction. No behavior, API shape, export, default, frame or storage key changed; the coverage floors and the zero-count arm ledger are `0.21.51`'s.

package/dist/centrifuge.js

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

package/dist/{chunk-6ZYMKR6J.js → chunk-PCBQYYOA.js}

@@ -2548,7 +2548,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.52" : ""
+  true ? "0.21.53" : ""
 );
 
 // src/core/data-bus.ts
@@ -3801,4 +3801,4 @@ export {
   parseDataBusPublication,
   selectWorkerBackend
 };
-//# sourceMappingURL=chunk-6ZYMKR6J.js.map
+//# sourceMappingURL=chunk-PCBQYYOA.js.map

package/dist/cjs/centrifuge.cjs

@@ -2677,7 +2677,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.52" : ""
+  true ? "0.21.53" : ""
 );
 
 // src/core/data-bus.ts

package/dist/cjs/index.cjs

@@ -2643,7 +2643,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.52" : ""
+  true ? "0.21.53" : ""
 );
 
 // src/core/data-bus.ts

package/dist/index.js

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

package/docs/release-checklist.md

@@ -53,6 +53,6 @@ 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 12-minute ceiling is not padding, and the number is a sum of two measured lags. First: the registry records the publish minutes after `npm publish` returns — and **read that series off the runs rather than off a list in this file**. `node scripts/publication-lag.mjs` walks every release tag, subtracts the `Publish to npm` step's `completed_at` from `time[<version>]` on the packument, prints which attempt each non-first reading came from, and names every tag its denominator drops. Re-run there at `0.21.36`: **43** releases from `0.20.92` on, record lag **74.8–310.0 s**, none over 310 s. Re-run at `0.21.50`: **57** releases from `0.20.92` on, record lag **56.5–310.0 s**, still none over 310 s — the *low* end is what moved (the 310 s that sizes the budget is the maximum, untouched since `0.21.30`), which is why reading the printed `modern floor:` line is right and copying a floor into prose as a bound is the thing to avoid. This note used to carry the per-version values, and two consecutive releases then refuted the regularity those values had been read as: three records at 76.1 / 75.5 / 75.8 s looked like a stable lag, then `0.21.35` came back at 127.3 s and `0.21.36` at 126.4 s. So the tight run was three samples in a wide distribution, and the enumeration was both a maintenance liability — it needs an edit every release, and it was stale the moment it shipped twice — and the vehicle of an inference the data never supported. The list is gone; the range above is what the ceiling is sized from, and it is re-derivable in one command. What the series does support is weaker and is all the ceiling needs: while the *record* lag spans four minutes, every green release whose consumer step actually waited took **301–309 s** (42 measurements inside 300–310 s, `0.21.30`'s 364 s exhausted budget the only outlier above it, and the two rows below it — `0.20.86` and `0.20.87` at 1.0 s — are the only pre-`0.20.92` releases the sweep measures at all, the other four of that window printing as `NEGATIVE` and so sitting outside the 45) — so the varying quantity is how long the reader stays blind to a record that already exists, which is the second lag, not this one. Second: the packument that `npm pack` resolves against is served with `cache-control: public, max-age=300`, so a copy of it anywhere in the path is allowed to be up to five minutes stale, and resolution cannot be trusted to beat one cache lifetime after a write that lands inside that window. Which copy — npm's local cache or an intermediate — served the stale views below is *not* established, and the counter-observation this note used to offer against a purely local account does not survive being read carefully, because it joins two machines: the 21:44:34Z "fresh fetch" was a `npm pack` run on a laptop, while the 1 s green at 21:47:10Z was a *new runner job*, and a new job's npm cache starts empty — which is what the local account predicts rather than what contradicts it. What a purely-local account still cannot explain is one specific reading: the runner's own `ETARGET` at 21:45:07Z — 364 s after the step that opened its first poll (21:39:03Z), so ~60 s *after* the point where a copy taken then must have gone stale (21:44:03Z, give or take the second the request actually left). The ceiling is therefore arithmetic rather than a model: worst-case ack→`time[]` gap plus one cache lifetime. That sum is not theoretical: the previous 6-minute ceiling was exhausted by a *successful* publish, the 0.21.30 tag run spending its whole 360 s budget (48 × 7.5 s) on `ETARGET` while that version's tarball HEAD and a local `npm pack` had both already succeeded, and the same step 123 s later taking 1 s. The 0.20.89 run had shown the same shape against that release's 2-minute budget. So a long retrying verify is normal propagation, not an unusually slow mirror — raise `PUBLISHED_VERIFY_ATTEMPTS` / `PUBLISHED_VERIFY_DELAY_MS` further only if the ack→`time[]` gap has itself grown. Note the asymmetry when repeating by hand: `verify-published-consumer.mjs` defaults to `6` attempts × `5_000` ms — 30 seconds, not 12 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=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`, or judge a manual failure against the 30 s budget you actually ran. Read the step's duration as a diagnostic rather than a mood: one 300 s cache lifetime plus a few seconds of command time predicts a tight cluster just above 300 s, and that is what the sweep prints — 42 of its 45 measurements land inside 300–310 s, `0.21.30`'s 364 s budget exhaustion is the only outlier above it, and every sub-2 s row belongs to a release before `0.20.92` where nothing had to propagate. Take the per-release numbers from that run's `Verify published npm consumers` step (`steps[].started_at` / `completed_at`, from the same `gh api` call the attempt selection above uses); this file no longer lists them, because its last enumeration named a 304–308 s band that the whole series widens to 301–309 s, and a number copied out of a subset is how a claim like that survives being false. 0.21.31 through 0.21.34 are the first four releases to run under the raised 720 s ceiling, and their lags split differently, which is the useful contrast: 127.2 s of record plus ~181 s of cache for the first, 76.1 s of record plus ~228 s before the runner saw it for the next, 75.5 s plus ~229 s for the third, and 75.8 s plus ~228 s for the fourth — on 0.21.32 a `no-cache` packument read from a laptop reported the new `latest` 151 s in, while the runner's own poll kept failing until 304 s, i.e. one lifetime after *its* first fetch. So the sample that set the previous ceiling has not been beaten: if the *ack→`time[]`* figure grows past 310 s, raise `PUBLISHED_VERIFY_ATTEMPTS` again; a verify that finishes in seconds means whatever copy it read already carried the new version.
+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 12-minute ceiling is not padding, and the number is a sum of two measured lags. First: the registry records the publish minutes after `npm publish` returns — and **read that series off the runs rather than off a list in this file**. `node scripts/publication-lag.mjs` walks every release tag, subtracts the `Publish to npm` step's `completed_at` from `time[<version>]` on the packument, prints which attempt each non-first reading came from, and names every tag its denominator drops. **Its verdict vocabulary, because some of the seven labels read as a failed release and are not:** `API-FAIL`, `NO-STEP`, `NO-PUBLISH` and `PENDING-STEP` are all statements about the *read*, not about the publish — `PENDING-STEP <version>` in particular means GitHub has not backfilled the step's `completed_at` yet (it lands after the run row closes; measured on `0.21.52`, whose release printed `NO-PUBLISH` minutes after finishing and the correct row a minute later on the unchanged tree), and the remedy is to re-run rather than to investigate a publish that did happen. `NEGATIVE` is a real reading in another regime (the registry stamped before the ack returned). Only `EXCLUDED-NON-SUCCESS` and `NO-RECORD` name genuine absences, and they name two different ones: a run that did not end green, and a version the registry never recorded. Re-run there at `0.21.36`: **43** releases from `0.20.92` on, record lag **74.8–310.0 s**, none over 310 s. Re-run at `0.21.50`: **57** releases from `0.20.92` on, record lag **56.5–310.0 s**, still none over 310 s — the *low* end is what moved (the 310 s that sizes the budget is the maximum, untouched since `0.21.30`), which is why reading the printed `modern floor:` line is right and copying a floor into prose as a bound is the thing to avoid. This note used to carry the per-version values, and two consecutive releases then refuted the regularity those values had been read as: three records at 76.1 / 75.5 / 75.8 s looked like a stable lag, then `0.21.35` came back at 127.3 s and `0.21.36` at 126.4 s. So the tight run was three samples in a wide distribution, and the enumeration was both a maintenance liability — it needs an edit every release, and it was stale the moment it shipped twice — and the vehicle of an inference the data never supported. The list is gone; the range above is what the ceiling is sized from, and it is re-derivable in one command. What the series does support is weaker and is all the ceiling needs: while the *record* lag spans four minutes, every green release whose consumer step actually waited took **301–309 s** (42 measurements inside 300–310 s, `0.21.30`'s 364 s exhausted budget the only outlier above it, and the two rows below it — `0.20.86` and `0.20.87` at 1.0 s — are the only pre-`0.20.92` releases the sweep measures at all, the other four of that window printing as `NEGATIVE` and so sitting outside the 45) — so the varying quantity is how long the reader stays blind to a record that already exists, which is the second lag, not this one. Second: the packument that `npm pack` resolves against is served with `cache-control: public, max-age=300`, so a copy of it anywhere in the path is allowed to be up to five minutes stale, and resolution cannot be trusted to beat one cache lifetime after a write that lands inside that window. Which copy — npm's local cache or an intermediate — served the stale views below is *not* established, and the counter-observation this note used to offer against a purely local account does not survive being read carefully, because it joins two machines: the 21:44:34Z "fresh fetch" was a `npm pack` run on a laptop, while the 1 s green at 21:47:10Z was a *new runner job*, and a new job's npm cache starts empty — which is what the local account predicts rather than what contradicts it. What a purely-local account still cannot explain is one specific reading: the runner's own `ETARGET` at 21:45:07Z — 364 s after the step that opened its first poll (21:39:03Z), so ~60 s *after* the point where a copy taken then must have gone stale (21:44:03Z, give or take the second the request actually left). The ceiling is therefore arithmetic rather than a model: worst-case ack→`time[]` gap plus one cache lifetime. That sum is not theoretical: the previous 6-minute ceiling was exhausted by a *successful* publish, the 0.21.30 tag run spending its whole 360 s budget (48 × 7.5 s) on `ETARGET` while that version's tarball HEAD and a local `npm pack` had both already succeeded, and the same step 123 s later taking 1 s. The 0.20.89 run had shown the same shape against that release's 2-minute budget. So a long retrying verify is normal propagation, not an unusually slow mirror — raise `PUBLISHED_VERIFY_ATTEMPTS` / `PUBLISHED_VERIFY_DELAY_MS` further only if the ack→`time[]` gap has itself grown. Note the asymmetry when repeating by hand: `verify-published-consumer.mjs` defaults to `6` attempts × `5_000` ms — 30 seconds, not 12 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=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`, or judge a manual failure against the 30 s budget you actually ran. Read the step's duration as a diagnostic rather than a mood: one 300 s cache lifetime plus a few seconds of command time predicts a tight cluster just above 300 s, and that is what the sweep prints — 42 of its 45 measurements land inside 300–310 s, `0.21.30`'s 364 s budget exhaustion is the only outlier above it, and every sub-2 s row belongs to a release before `0.20.92` where nothing had to propagate. Take the per-release numbers from that run's `Verify published npm consumers` step (`steps[].started_at` / `completed_at`, from the same `gh api` call the attempt selection above uses); this file no longer lists them, because its last enumeration named a 304–308 s band that the whole series widens to 301–309 s, and a number copied out of a subset is how a claim like that survives being false. 0.21.31 through 0.21.34 are the first four releases to run under the raised 720 s ceiling, and their lags split differently, which is the useful contrast: 127.2 s of record plus ~181 s of cache for the first, 76.1 s of record plus ~228 s before the runner saw it for the next, 75.5 s plus ~229 s for the third, and 75.8 s plus ~228 s for the fourth — on 0.21.32 a `no-cache` packument read from a laptop reported the new `latest` 151 s in, while the runner's own poll kept failing until 304 s, i.e. one lifetime after *its* first fetch. So the sample that set the previous ceiling has not been beaten: if the *ack→`time[]`* figure grows past 310 s, raise `PUBLISHED_VERIFY_ATTEMPTS` again; a verify that finishes in seconds means whatever copy it read already carried the new version.
 
 **Do not adjudicate a publish from `dist-tags.latest`.** The package document endpoint and the tarball URL are two different read paths, and their timestamps are worth more than the impression they first give. Read during the 0.21.30 release, in order: `npm publish` returned success at `21:39:03Z`; a `curl -s -H "Cache-Control: no-cache" https://registry.npmjs.org/<pkg>` at `21:43:15Z` reported `latest` still on the previous version, no `0.21.30` in `versions`, and no `time['0.21.30']`; npm's own stamp for that version is `21:44:12.987Z` and the document's `last-modified` is `21:44:14 GMT`. So the 21:43:15 read was **not** a replica refusing an artifact that already existed — the registry had not finished recording the publish, and `no-cache` could not have made it see a version that did not exist yet. Absence from `versions` and from `latest`, minutes after a green publish step, is the expected state of a successful release from `0.20.92` on — **43** of them as of `0.21.36`, every one of *those* recorded at least 74.8 s after its ack — a floor `0.21.50` then widened down to 56.5 s. The floor is not what the ceiling is built from, so a reading below it costs nothing; only the *upper* bound is load-bearing, and the sweep still prints `ceiling contribution unchanged if max <= 310.0: true`. Take the count from `CHANGELOG.md`'s version headings intersected with the packument's `time` map and the floor from the same sweep that yields the lag range above: that set gains a member at every release, which is the whole reason a value in this sentence is the wrong thing to memorize — while the five just before the window (`0.20.86`, `0.20.87`, `0.20.88`, `0.20.90`, `0.20.91`) recorded within ±0.6 s of their acks and resolved in 1 s. So the sentence describes this window and not npm; what to do when it holds is unchanged. The genuine read-path disagreement came 60 s later: between `21:44:14Z` and `21:44:35Z`, `curl -I …/-/<pkg>-0.21.30.tgz` returned `HTTP 200` and a local `npm pack <pkg>@0.21.30 --registry https://registry.npmjs.org` completed and wrote the tarball, while the workflow runner's own `npm pack` kept returning `ETARGET` until it exhausted its budget at `21:45:07Z`. Same version, two machines, opposite answers a minute apart. To answer "did the publish happen", HEAD the tarball URL and try the pack — those reach the artifact — and try it **from the place that is failing**, because "fetchable" is a per-machine answer; read `latest` only for the question "which version do consumers get by default", which is a different one and settles later. `npm view <pkg> version` adds a third path on top: it can be served from npm's *local* packument cache, so on a machine that queried the registry before the publish it can return the superseded version even after the global `latest` has moved (that is why this gate resolves its target from `PUBLISHED_VERSION` and refuses an inferred version that disagrees with `package.json`). Never re-push, move, or replace a tag because a metadata read looked stale; the tag is immutable once published.

package/docs/roadmap.md

@@ -1,6 +1,6 @@
 # Roadmap
 
-0.21.51 was released on October 24, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
+0.21.52 was released on October 24, 2026. The project is intentionally continuing through reliability-focused releases before a 1.0.0 stability freeze.
 
 ## 0.21.44 delivered scope
 

package/docs/zh/release-checklist.md

@@ -54,6 +54,6 @@
 2. 在干净消费者中安装已发布版本或 tarball，并导入主入口及所有公开子路径。
 3. 将结果记录到发布说明。在公开 API 和协议弃用策略明确冻结前，不进入 `1.0.0`。
 
-打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流的 12 分钟上限不是凑数，而是两段实测延迟之和。第一段：`npm publish` 返回成功后，registry 还要几分钟才把这条版本记进去——而**这份序列要从运行记录里读，不要从本文件抄来的清单里读**。`node scripts/publication-lag.mjs` 会走一遍所有 release tag，用 packument 上的 `time[<version>]` 减去 `Publish to npm` 步骤的 `completed_at`，打印每条非首次读出的数取自第几次 attempt，并把它从分母里丢掉的 tag 逐个点名。在 `0.21.36` 处重跑的答案：从 `0.20.92` 起共 **43** 个发布，落库延迟 **74.8–310.0 秒**，没有一次越过决定预算的 310 秒。在 `0.21.50` 处重跑：共 **57** 个发布，落库延迟 **56.5–310.0 秒**，仍然没有一次越过 310 秒——移动的是*下界*（给预算定尺寸的那个 310 秒是自 `0.21.30` 以来的最大值，未被触及），这正是「该读扫描打印的 `modern floor:` 那行，而不是把下限抄进散文当成界」的原因。本段以前逐个抄录过这些数值，而紧接着的两次发布接连推翻由那串数值读出的规律：连续三次落在 76.1 / 75.5 / 75.8 秒，看着像"落库很稳"，随后 `0.21.35` 回到 127.3 秒、`0.21.36` 是 126.4 秒。所以那段紧凑只是宽分布里的三个样本；而那份枚举既是维护负担（每次发布都要改，两次刚写下就已过期），也承载了一个数据从来不支持的推论。清单已删，上面这个区间才是预算的来源，而且一条命令就能重取。这套数据真正支持的结论更弱、也更够用：落库延迟横跨四分钟，可绿色发布里真正等待过的消费者步骤一律是 **301–309 秒**（45 个读数里 42 个落在 300–310 秒内，唯一的上方异常是 `0.21.30` 耗尽预算的 364 秒；下方两条各 1.0 秒，是 `0.20.86` 和 `0.20.87`，也正是 `0.20.92` 之前唯二被这条序列量到的发布——那个窗口里另外四条以 `NEGATIVE` 打印，不在这 45 条之内——那时根本没有东西需要传播）——会变的其实是"记录已经存在之后，读者还要瞎多久"，那是第二段，不是这一段。第二段：`npm pack` 用来解析版本的 packument 是以 `cache-control: public, max-age=300` 提供的，也就是说路径上任何一份副本按设计都可以旧五分钟，落在这一窗口内写入的版本，解析不太可能快过一整个缓存生命周期。究竟是哪个副本（npm 本地缓存，还是中间的 CDN）在下面提供了过期视图**并未确立**，而这段文字此前用作"反对纯本地解释"的那个观测，仔细读过之后站不住，因为它把两台机器拼成了一句话：21:44:34Z 那次"新鲜读取"是在笔记本上跑 `npm pack`，而 21:47:10Z 一秒就绿的是一次*全新的 runner 任务*，新任务的 npm 缓存本来是空的——这恰好是纯本地模型预测的结果，不是反驳它的结果。纯本地模型仍然解释不了的，只有一个读数：runner 自己在 21:45:07Z 仍然报 `ETARGET`——距离开始轮询的那一步（21:39:03Z）已经 364 秒，也就是比"那一刻抓到的副本必然已过期"的时间点（21:44:03Z，误差在请求真正发出的那一秒之内）还要晚约 60 秒。因此上限靠的是算术而不是模型：最坏情况的"确认 → `time[]`"间隔，加上一个缓存生命周期。这个和并非理论值——上一个 6 分钟上限被一次*成功*的发布排空过：0.21.30 的 tag 运行把整整 360 秒预算（48 × 7.5 秒）花在 `ETARGET` 上，而那时该版本的 tarball HEAD 和本地 `npm pack` 都已经成功；123 秒后同一步骤只用了 1 秒。0.20.89 针对它当时的 2 分钟预算也是同一形状。所以长时间的反复重试是正常的传播延迟，不是镜像异常慢——只有"确认 → `time[]`"间隔本身变长了，才需要继续调大 `PUBLISHED_VERIFY_ATTEMPTS` 和 `PUBLISHED_VERIFY_DELAY_MS`。手动复验时要注意这个不对称：`verify-published-consumer.mjs` 的默认值是 `6` 次 × `5_000` ms——30 秒而不是 12 分钟——因为更大的那一对是由 tag 工作流以 env 传入、而非脚本自带。于是手动复跑可能在一个 CI 全绿的版本上报出 `ETARGET`，这看起来像发布失败而实际不是；要对齐 CI 预算就显式执行 `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`，否则请按你实际跑到的 30 秒预算来判断手动失败。把这个步骤的耗时当诊断读数而不是情绪指标：整条序列自己取——`node scripts/publication-lag.mjs` 会打印每个发布运行里这一步的墙钟时间（`steps[].started_at`/`completed_at`，和上面选 attempt 用的是同一个 `gh api` 调用）。45 个读数里 42 个落在 300–310 秒内，`0.21.30` 耗尽预算的 364 秒是唯一的上方异常，1 秒以内的两条都属于 `0.20.92` 之前的发布——那时没有东西需要传播。这正是"一个 300 秒缓存生命周期 + 几秒命令时间"会预测出的形状，所以本文件不再抄录逐个数：上一份枚举写下的是 304–308 秒的区间，而整条序列把它放宽成 301–309 秒——从子集里抄一个数，就是这么让一个错说法活得比它的样本更久。0.21.31 到 0.21.34 是头四个跑在提高后的 720 秒上限下的发布，而它们几段延迟的切分方式不同，这个对照正是有用的地方：第一次是 127.2 秒落库 + 约 181 秒缓存；第二次是 76.1 秒落库 + 之后约 228 秒 runner 仍看不见它；第三次是 75.5 秒落库 + 约 229 秒；第四次是 75.8 秒落库 + 约 228 秒——在 0.21.32 上，笔记本在 151 秒时用 `no-cache` 读 packument 已经能看到新的 `latest`，而 runner 自己的轮询一直到 304 秒才成功，也就是从*它自己*首次抓取算起整整一个生命周期。所以当初定这个上限的那个样本至今没有被超过：如果*确认 → `time[]`*这一段自己长过了 310 秒，就再调大 `PUBLISHED_VERIFY_ATTEMPTS`；而几秒就结束的 verify 只说明它读到的那份副本已经带上了新版本。
+打 tag 的发布工作流已自动执行上述消费者验证；仅在需要离线复验时才手动运行 `PUBLISHED_VERSION=<version> pnpm verify:published`。工作流的 12 分钟上限不是凑数，而是两段实测延迟之和。第一段：`npm publish` 返回成功后，registry 还要几分钟才把这条版本记进去——而**这份序列要从运行记录里读，不要从本文件抄来的清单里读**。`node scripts/publication-lag.mjs` 会走一遍所有 release tag，用 packument 上的 `time[<version>]` 减去 `Publish to npm` 步骤的 `completed_at`，打印每条非首次读出的数取自第几次 attempt，并把它从分母里丢掉的 tag 逐个点名。**它的裁决词表，因为七个标签里有几个会被读成「发布失败」而其实不是：** `API-FAIL`、`NO-STEP`、`NO-PUBLISH`、`PENDING-STEP` 说的都是*这次读取*，而不是这次发布——尤其 `PENDING-STEP <version>` 表示 GitHub 还没有回填该步骤的 `completed_at`（它在 run 行关闭之后才落地；在 `0.21.52` 上实测：发布刚结束时打印 `NO-PUBLISH`，一分钟之后在未改动的工作树上重跑就是正确的行），处置办法是重跑，而不是去查一次并不存在的发布失败。`NEGATIVE` 是另一区制下的真实读数（registry 在 ack 返回之前就盖了时间戳）。只有 `EXCLUDED-NON-SUCCESS` 与 `NO-RECORD` 指向真正的缺失，而且是两种不同的缺失：一次没有以绿色结束的 run，和一个 registry 从未记录的版本。在 `0.21.36` 处重跑的答案：从 `0.20.92` 起共 **43** 个发布，落库延迟 **74.8–310.0 秒**，没有一次越过决定预算的 310 秒。在 `0.21.50` 处重跑：共 **57** 个发布，落库延迟 **56.5–310.0 秒**，仍然没有一次越过 310 秒——移动的是*下界*（给预算定尺寸的那个 310 秒是自 `0.21.30` 以来的最大值，未被触及），这正是「该读扫描打印的 `modern floor:` 那行，而不是把下限抄进散文当成界」的原因。本段以前逐个抄录过这些数值，而紧接着的两次发布接连推翻由那串数值读出的规律：连续三次落在 76.1 / 75.5 / 75.8 秒，看着像"落库很稳"，随后 `0.21.35` 回到 127.3 秒、`0.21.36` 是 126.4 秒。所以那段紧凑只是宽分布里的三个样本；而那份枚举既是维护负担（每次发布都要改，两次刚写下就已过期），也承载了一个数据从来不支持的推论。清单已删，上面这个区间才是预算的来源，而且一条命令就能重取。这套数据真正支持的结论更弱、也更够用：落库延迟横跨四分钟，可绿色发布里真正等待过的消费者步骤一律是 **301–309 秒**（45 个读数里 42 个落在 300–310 秒内，唯一的上方异常是 `0.21.30` 耗尽预算的 364 秒；下方两条各 1.0 秒，是 `0.20.86` 和 `0.20.87`，也正是 `0.20.92` 之前唯二被这条序列量到的发布——那个窗口里另外四条以 `NEGATIVE` 打印，不在这 45 条之内——那时根本没有东西需要传播）——会变的其实是"记录已经存在之后，读者还要瞎多久"，那是第二段，不是这一段。第二段：`npm pack` 用来解析版本的 packument 是以 `cache-control: public, max-age=300` 提供的，也就是说路径上任何一份副本按设计都可以旧五分钟，落在这一窗口内写入的版本，解析不太可能快过一整个缓存生命周期。究竟是哪个副本（npm 本地缓存，还是中间的 CDN）在下面提供了过期视图**并未确立**，而这段文字此前用作"反对纯本地解释"的那个观测，仔细读过之后站不住，因为它把两台机器拼成了一句话：21:44:34Z 那次"新鲜读取"是在笔记本上跑 `npm pack`，而 21:47:10Z 一秒就绿的是一次*全新的 runner 任务*，新任务的 npm 缓存本来是空的——这恰好是纯本地模型预测的结果，不是反驳它的结果。纯本地模型仍然解释不了的，只有一个读数：runner 自己在 21:45:07Z 仍然报 `ETARGET`——距离开始轮询的那一步（21:39:03Z）已经 364 秒，也就是比"那一刻抓到的副本必然已过期"的时间点（21:44:03Z，误差在请求真正发出的那一秒之内）还要晚约 60 秒。因此上限靠的是算术而不是模型：最坏情况的"确认 → `time[]`"间隔，加上一个缓存生命周期。这个和并非理论值——上一个 6 分钟上限被一次*成功*的发布排空过：0.21.30 的 tag 运行把整整 360 秒预算（48 × 7.5 秒）花在 `ETARGET` 上，而那时该版本的 tarball HEAD 和本地 `npm pack` 都已经成功；123 秒后同一步骤只用了 1 秒。0.20.89 针对它当时的 2 分钟预算也是同一形状。所以长时间的反复重试是正常的传播延迟，不是镜像异常慢——只有"确认 → `time[]`"间隔本身变长了，才需要继续调大 `PUBLISHED_VERIFY_ATTEMPTS` 和 `PUBLISHED_VERIFY_DELAY_MS`。手动复验时要注意这个不对称：`verify-published-consumer.mjs` 的默认值是 `6` 次 × `5_000` ms——30 秒而不是 12 分钟——因为更大的那一对是由 tag 工作流以 env 传入、而非脚本自带。于是手动复跑可能在一个 CI 全绿的版本上报出 `ETARGET`，这看起来像发布失败而实际不是；要对齐 CI 预算就显式执行 `PUBLISHED_VERSION=<version> PUBLISHED_VERIFY_ATTEMPTS=96 PUBLISHED_VERIFY_DELAY_MS=7500 pnpm verify:published`，否则请按你实际跑到的 30 秒预算来判断手动失败。把这个步骤的耗时当诊断读数而不是情绪指标：整条序列自己取——`node scripts/publication-lag.mjs` 会打印每个发布运行里这一步的墙钟时间（`steps[].started_at`/`completed_at`，和上面选 attempt 用的是同一个 `gh api` 调用）。45 个读数里 42 个落在 300–310 秒内，`0.21.30` 耗尽预算的 364 秒是唯一的上方异常，1 秒以内的两条都属于 `0.20.92` 之前的发布——那时没有东西需要传播。这正是"一个 300 秒缓存生命周期 + 几秒命令时间"会预测出的形状，所以本文件不再抄录逐个数：上一份枚举写下的是 304–308 秒的区间，而整条序列把它放宽成 301–309 秒——从子集里抄一个数，就是这么让一个错说法活得比它的样本更久。0.21.31 到 0.21.34 是头四个跑在提高后的 720 秒上限下的发布，而它们几段延迟的切分方式不同，这个对照正是有用的地方：第一次是 127.2 秒落库 + 约 181 秒缓存；第二次是 76.1 秒落库 + 之后约 228 秒 runner 仍看不见它；第三次是 75.5 秒落库 + 约 229 秒；第四次是 75.8 秒落库 + 约 228 秒——在 0.21.32 上，笔记本在 151 秒时用 `no-cache` 读 packument 已经能看到新的 `latest`，而 runner 自己的轮询一直到 304 秒才成功，也就是从*它自己*首次抓取算起整整一个生命周期。所以当初定这个上限的那个样本至今没有被超过：如果*确认 → `time[]`*这一段自己长过了 310 秒，就再调大 `PUBLISHED_VERIFY_ATTEMPTS`；而几秒就结束的 verify 只说明它读到的那份副本已经带上了新版本。
 
 **不要用 `dist-tags.latest` 来判断发布是否发生。** 包文档端点与 tarball URL 是两条不同的读取路径，而它们的时间戳比这两条路径给的第一手印象更值得读。0.21.30 发布期间按顺序读到：`npm publish` 在 `21:39:03Z` 返回成功；`21:43:15Z` 的一次 `curl -s -H "Cache-Control: no-cache" https://registry.npmjs.org/<pkg>` 仍报 `latest` 是上一个版本、`versions` 里没有 `0.21.30`、`time['0.21.30']` 也不存在；而 npm 自己给这个版本盖的时间戳是 `21:44:12.987Z`，文档的 `last-modified` 是 `21:44:14 GMT`。所以 21:43:15 那次读取**不是**一份副本在拒绝已经存在的产物——registry 当时确实还没把这次发布记完，`no-cache` 也不可能让它看见尚不存在的版本；在发布步骤全绿之后的几分钟里，`versions` 与 `latest` 里没有这个版本，对 `0.20.92` 起的每一次成功发布都是正常状态——截至 `0.21.36` 共 **43** 个，其中*那四十三次*被记下的延迟都不小于 74.8 秒——这个下限随后被 `0.21.50` 向下放宽到 56.5 秒。下限并不是预算的推导来源，所以它变小并不损失什么；真正承重的是*上界*，而扫描仍然打印 `ceiling contribution unchanged if max <= 310.0: true`。（计数取 `CHANGELOG.md` 的版本标题与 packument `time` 映射的交集，下限由上面那条同一命令给出；这个集合每次发布都会 +1，所以值得记住的是取法而不是那个数）——而窗口之前的那五次（`0.20.86`、`0.20.87`、`0.20.88`、`0.20.90`、`0.20.91`）在 ack 前后 ±0.6 秒内就记录好了，1 秒即可解析。所以这句话描述的是这个窗口，而不是 npm 本身；当它成立时，该怎么判断并没有变。真正的读取路径分歧出现在 60 秒之后：`21:44:14Z` 到 `21:44:35Z` 之间，`curl -I …/-/<pkg>-0.21.30.tgz` 返回 `HTTP 200`，本地一次 `npm pack <pkg>@0.21.30 --registry https://registry.npmjs.org` 也成功写出了 tarball，而工作流 runner 自己的 `npm pack` 一直 `ETARGET` 到 `21:45:07Z` 把预算排空。同一个版本、两台机器、相隔一分钟给出相反答案。要回答"发布到底成没成"，去 HEAD 那个 tarball URL 并试一次 pack——它们摸到的是产物本身——而且要从**正在失败的那台机器**上去试，因为"能取到"是一台机器才有的答案；`latest` 只回答"消费者默认拿到哪个版本"，那是另一个问题，而且会更晚才稳定。`npm view <pkg> version` 在这之上还有第三条路径：它可能来自 npm 的**本地** packument 缓存，于是在发布前查过一次的机器上，即使全局 `latest` 已经前进，它仍会返回被取代的旧版本——这正是本门禁把目标版本固定取自 `PUBLISHED_VERSION`、并拒绝与 `package.json` 不一致的推断值的原因。不要因为一次元数据读取看起来过期就重推、移动或替换 tag；发布出去的 tag 是不可变的。

package/docs/zh/roadmap.md

@@ -1,6 +1,6 @@
 # 路线图
 
-0.21.51 已于 2026 年 10 月 24 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
+0.21.52 已于 2026 年 10 月 24 日发布。项目会先持续完成可靠性发布，再进入 1.0.0 稳定性冻结。
 
 ## 0.21.44 已完成范围
 

package/package.json

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