@takazudo/zfb-md-wasm 2.15.0 → 2.16.0

package/README.md

@@ -717,6 +717,9 @@ three-step repair sequence:
    `BUILD_LOG=/tmp/zfb-md-wasm-build.log; node crates/zfb-md-wasm/npm/scripts/build.mjs 2>&1 | tee "$BUILD_LOG"`.
 2. Run `node scripts/assert-zfb-md-wasm-budgets.mjs --build-log "$BUILD_LOG" --dist crates/zfb-md-wasm/npm/dist --update-manifest`.
 3. Run `node scripts/assert-md-wasm-size-docs.mjs --fix`, then `pnpm format:mdx`.
+   `gzip-9` and `glue gzip-9` are compared with a 64-byte tolerance because
+   they are compressor output (CI prints a warning inside the band), while
+   final wasm and glue remain byte-exact.
 
 These are the shipped **2.15.0** artifact rows — optimized final wasm after
 wasm-bindgen and wasm-opt, Node `gzipSync(..., { level: 9 })`, and glue
@@ -739,6 +742,15 @@ permanent promises — re-measure against the version you actually install.
 The clean four-step production ceiling is 210 seconds; the selected #2447
 median was 155.015 s [153.496, 165.977].
 
+**Sizes are guarded; content digests are not.** The byte sizes above are held by
+`shipped-sizes.json` and asserted in CI, so they move only on a deliberate
+artifact change. SHA-256 digests are a different matter: every release stamps
+its own version string into each `.wasm` — the value `version()` returns — so
+all four digests change on **every** release, including a documentation-only
+patch whose compiled code is identical and whose byte sizes do not move at all.
+If you verify these artifacts by content digest rather than by semver, re-pin on
+every upgrade; never read "sizes unchanged" as "nothing to re-verify".
+
 Gating `swc_core` out of the highlight graph (#2449/#2450) was a
 **provability win, not a size win**. The #2447 SWC-retaining baseline was
 1,484,705 B raw and 767,009 B gzip-9; the #2450 result was 7,965 B smaller

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@takazudo/zfb-md-wasm",
-  "version": "2.15.0",
+  "version": "2.16.0",
   "private": false,
   "type": "module",
   "description": "zfb's md/mdx -> JS/HTML conversion pipeline compiled to WebAssembly, for browser-side dynamic conversion (CMS live preview with parity to zfb's production output).",