@blamejs/blamejs-shop 0.0.44

package/lib/vendor/blamejs/release-notes/v0.11.x.json

@@ -0,0 +1,2551 @@
+{
+  "$schema": "../scripts/release-notes-consolidated-schema.json",
+  "minor": "0.11",
+  "releases": [
+    {
+      "version": "0.11.45",
+      "date": "2026-05-22",
+      "headline": "Wiki compose pins track framework version",
+      "summary": "The dev and prod compose pins for `ghcr.io/blamejs/blamejs-wiki` move from the legacy `0.3.x` wiki-only versioning (`0.3.24` prod, `0.3.8` dev) to the framework version (`0.11.45`). The wiki container's build tag has matched the framework version since the v0.11.44 release-container workflow fix; the compose pins now follow suit so a fresh clone + `docker compose up` works against the most recent published image without manual edits.",
+      "sections": [
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`examples/wiki/docker-compose.prod.yml` pin: `0.3.24` → `0.11.45`",
+              "body": "The prod compose now pulls `ghcr.io/blamejs/blamejs-wiki:0.11.45`. Operators deploying to a host running an older pin keep working unchanged — their `.env` / image override takes precedence. To upgrade, the operator runs `docker compose -f docker-compose.yml -f docker-compose.prod.yml pull && docker compose -f docker-compose.yml -f docker-compose.prod.yml up -d` on the host."
+            },
+            {
+              "title": "`examples/wiki/docker-compose.yml` pin: `0.3.8` → `0.11.45`",
+              "body": "The dev compose (local-build path) also tracks the framework version. Aligns the locally-built dev image tag with the published image tag so the two paths don't drift over time."
+            }
+          ]
+        }
+      ],
+      "references": []
+    },
+    {
+      "version": "0.11.44",
+      "date": "2026-05-22",
+      "headline": "Fix wiki container build — release-container smoke step still hit port 8080",
+      "summary": "The v0.11.40 wiki port swap (8080 → 3008) missed `.github/workflows/release-container.yml`'s post-publish smoke step. The smoke ran `docker run -p 8080:8080` + curled `localhost:8080/healthz`, but the v0.11.40+ wiki container listens on 3008 — so the smoke failed and the wiki container was NOT pushed to GHCR for v0.11.40, v0.11.42, or v0.11.43. The npm package was unaffected (publish completes on a different job). Operators pulling `ghcr.io/blamejs/blamejs-wiki:latest` were getting the v0.11.39 build until this fix. This release fixes the workflow + adds a codebase-patterns detector that gates the Dockerfile's `WIKI_PORT` against the workflow's port map + curl host so the same silent-deploy failure can't recur.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "release-container.yml smoke step uses port 3008",
+              "body": "Three locations updated: comment header references port 3008; `-p 3008:3008` host port mapping; `curl http://localhost:3008/healthz` health check. Tagging v0.11.44 triggers a fresh container build + push that lands the v0.11.40 / v0.11.42 / v0.11.43 changes (port 3008 default, JSCalendar Group, BYSETPOS, multi-rule recurrence union, JMAP EmailSubmission/set, wiki nav alphabetical) in GHCR for the first time."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "Wiki-port cross-artifact agreement gate",
+              "body": "`testWikiPortAgreesAcrossArtifacts` reads `WIKI_PORT=<n>` from `examples/wiki/Dockerfile` and asserts every `docker run -p X:X` mapping + every `curl http://localhost:X/healthz` reference in `.github/workflows/release-container.yml` matches. Smoke-tested by introducing a deliberate mismatch — detector fires with file:line + the conflicting values. Prevents the v0.11.40 silent-deploy failure class from recurring on any future port change."
+            }
+          ]
+        }
+      ],
+      "references": []
+    },
+    {
+      "version": "0.11.43",
+      "date": "2026-05-22",
+      "headline": "Wiki nav: alphabetical sidebar + dedup drifted category labels",
+      "summary": "The wiki sidebar now lists categories alphabetically (case-insensitive) instead of in editorial order. Welcome remains pinned first (landing page); Other and Reference remain pinned last (catch-all groups). Three category-label dups are also consolidated at the source comment-blocks: `Agent Protocols` (one entry — `a2a-tasks`) joins `Agent` with the rest of the agent substrate; `Networking` (two entries — `stream-throttle`, `web-push-vapid`) joins `Network`; `Audit & Compliance` (one entry — `nist-crosswalk`) joins `Compliance`. New `@nav` categories now land in their alphabetical slot automatically without a site.config edit.",
+      "sections": [
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Wiki sidebar group order alphabetical",
+              "body": "Replaces the curated `GROUP_ORDER` editorial list in `examples/wiki/site.config.js` with an alphabetical sort. Pinning preserved: `Welcome` always first; `Other` and `Reference` always last. Adding a new `@nav` category to any `lib/*.js` `@module` block now slots into its alphabetical position automatically — no separate site.config update required."
+            },
+            {
+              "title": "Category consolidation: Agent Protocols → Agent",
+              "body": "`a2a-tasks` was the sole entry under `Agent Protocols`. Moved to `Agent` to live alongside the orchestrator / saga / idempotency / event-bus / posture-chain / stream / trace / tenant / snapshot / fsm primitives — the W3C A2A task surface is part of the same agent-substrate concern."
+            },
+            {
+              "title": "Category consolidation: Networking → Network",
+              "body": "`stream-throttle` and `web-push-vapid` were tagged `Networking` while every other network-layer primitive used `Network`. Drift cleanup — both now live under `Network`."
+            },
+            {
+              "title": "Category consolidation: Audit & Compliance → Compliance",
+              "body": "`nist-crosswalk` was the sole entry under `Audit & Compliance`. Moved to `Compliance` alongside the other regulatory primitives."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "Nav-category allowlist gate",
+              "body": "`testNavCategoryAllowlist` in the codebase-patterns runner walks every `lib/*.js` `@module` block and refuses any `@nav` value not in the canonical category list. Adding a new sidebar category is a deliberate edit — it lands in `NAV_ALLOWLIST` + the operator-facing `FIRST_GROUPS` / `LAST_GROUPS` pin list in `examples/wiki/site.config.js` at the same time. Prevents the Networking-vs-Network and Agent-vs-Agent-Protocols dup classes from re-emerging silently."
+            }
+          ]
+        }
+      ],
+      "references": []
+    },
+    {
+      "version": "0.11.42",
+      "date": "2026-05-22",
+      "headline": "`b.calendar` JSCalendar Group objects (RFC 8984 §1.4.4)",
+      "summary": "Closes the v0.11.31 deferral on JSCalendar Group. `b.calendar.validate` now recognises `@type: \"Group\"` as a container envelope for multiple Event / Task / Note entries that share a logical name + categories. `b.calendar.toIcal` emits a single VCALENDAR wrap containing every entry's component in declared order (VEVENT for Event, VTODO for Task, VJOURNAL for Note). Group is JSCalendar-only — iCalendar has no envelope-level metadata for Group.name / Group.categories, so a Group's metadata is dropped on the iCal-side of a round-trip; operators preserving Group state across systems use the JSON-native surface.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`@type: \"Group\"` envelope (RFC 8984 §1.4.4)",
+              "body": "A Group carries `uid`, `updated`, `entries` (required non-empty array), and optional `name`, `description`, `categories` (String-keyed Boolean set), and `source` (URI string). Entries are validated recursively — each entry must be a valid Event / Task / Note per its own type rules. Groups nesting Groups is refused (RFC 8984 does not define a nesting semantic)."
+            },
+            {
+              "title": "`b.calendar.toIcal` emits single VCALENDAR for Group",
+              "body": "When `@type === \"Group\"`, toIcal emits one BEGIN:VCALENDAR / END:VCALENDAR envelope containing every entry's component in declared order. The Group's own uid / updated / name / description / categories are NOT round-tripped to iCalendar (RFC 5545 has no envelope-level metadata for these); operators preserving Group state across a round-trip use the JSON-native JSCalendar surface."
+            },
+            {
+              "title": "Refusal vocabulary",
+              "body": "New structured `CalendarError` codes: `calendar/bad-entries` (entries missing, empty, non-array, or any entry malformed / Group-typed), `calendar/bad-group` (entry-specific field like start / duration / due / progress / recurrenceRules set on the Group envelope), `calendar/bad-categories` (non-object categories or non-`true` value), `calendar/bad-source` (non-string source)."
+            },
+            {
+              "title": "`JSCAL_TYPES.Group` export",
+              "body": "`b.calendar.JSCAL_TYPES.Group === \"Group\"` exposes the discriminator string for operator-side type-dispatch."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8984 §1.4.4 (JSCalendar Group)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-1.4.4"
+        },
+        {
+          "label": "RFC 5545 §3.4 (VCALENDAR envelope)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.4"
+        }
+      ]
+    },
+    {
+      "version": "0.11.41",
+      "date": "2026-05-21",
+      "headline": "`b.calendar.expandRecurrence` picks up BYSETPOS (RFC 5545 §3.3.10)",
+      "summary": "Closes the v0.11.31 deferral on BYSETPOS — the recurrence filter that picks the Nth candidate from a BY*-filtered set within a FREQ interval. Common operator patterns now work directly: `FREQ=MONTHLY;BYDAY=FR;BYSETPOS=-1` for last Friday of each month, `FREQ=MONTHLY;BYDAY=TU;BYSETPOS=2` for second Tuesday, `FREQ=YEARLY;BYMONTH=10;BYDAY=SU;BYSETPOS=1` for first Sunday of October (the DST-end announcement pattern). Supported for `FREQ=MONTHLY` / `YEARLY` / `WEEKLY` at day-granularity (time-of-day inherited from `start`). `FREQ=DAILY` + BYSETPOS is refused with `calendar/bad-recurrence` since the semantics aren't meaningful at sub-day frequency.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`bySetPos` filter on RecurrenceRule",
+              "body": "`recurrenceRules[i].bySetPos: [1, -1, 2]` picks the listed positions from the BY*-filtered candidate set within each FREQ interval. Positive values are 1-indexed from the start of the period; negative values count from the end. Multiple positions emit per period (e.g. `[1, -1]` emits both the first and last matching day of each month). Out-of-range positions silently drop per RFC 5545's tolerant grammar."
+            },
+            {
+              "title": "MONTHLY / YEARLY / WEEKLY support",
+              "body": "BYSETPOS expands within month / year / WKST-aligned-week boundaries. For each period, all day-level candidates that pass the existing BY* filters (byDay / byMonth / byMonthDay / byWeekNo / byYearDay) are enumerated, sorted ascending, then indexed by `bySetPos`. The expand loop's step budget (`MAX_EXPAND_INSTANCES * 366`) is shared across periods so the BYSETPOS path can't outrun the v0.11.31 DoS bound."
+            },
+            {
+              "title": "DAILY frequency refused",
+              "body": "`FREQ=DAILY` + BYSETPOS throws `calendar/bad-recurrence` at expand time. The combination has no meaningful per-period set semantics (a day has no sub-day BY* set to pick from in the v1 day-granularity model). Operators with a sub-day BYSETPOS use case use `FREQ=HOURLY` semantics directly without BYSETPOS, or open an issue with the use case."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Step budget shared with non-BYSETPOS path",
+              "body": "BYSETPOS enumeration decrements the same `MAX_EXPAND_INSTANCES * 366` step budget the non-BYSETPOS path uses, and the per-period day-loop has a hard 400-iteration safety cap (covers max-366-days in a leap year + slack). Adversarial events combining many rules + sparse BY* filters + BYSETPOS can't outpace the original single-rule DoS bound."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5545 §3.3.10 (RRULE — BYSETPOS)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.3.10"
+        },
+        {
+          "label": "RFC 8984 §4.3.2 (JSCalendar RecurrenceRule)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-4.3.2"
+        }
+      ]
+    },
+    {
+      "version": "0.11.40",
+      "date": "2026-05-21",
+      "headline": "Wiki Docker default port moves from 8080 → 3008",
+      "summary": "The `examples/wiki` Docker stack now defaults to port 3008 throughout — `WIKI_PORT`, the Dockerfile `EXPOSE` directive, the in-container HEALTHCHECK URL, the dev `docker-compose.yml` host mapping, the Caddy reverse-proxy upstream, and the `server.js` + `lib/build-app.js` code defaults. Production deployments (`docker-compose.prod.yml`) are operator-invisible since Caddy fronts the container on 80/443 — the upstream port is never exposed to the host. Dev users hitting the wiki container directly now use `http://localhost:3008`. Operators who set `WIKI_PORT` explicitly in their `.env` keep working unchanged.",
+      "sections": [
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Wiki default port 8080 → 3008",
+              "body": "Default `WIKI_PORT` moves from 8080 (HTTP-alt, frequently collides with Tomcat / Jenkins / Confluence / Spring-Boot defaults) to 3008 (IANA-unassigned, no service-convention collision). The new default applies consistently across: `examples/wiki/Dockerfile` (`ENV WIKI_PORT`, `EXPOSE`, HEALTHCHECK URL), `examples/wiki/server.js`, `examples/wiki/lib/build-app.js`, `examples/wiki/docker-compose.yml` (host mapping `3008:3008`), `examples/wiki/docker-compose.prod.yml` (internal-network expose), `examples/wiki/Caddyfile` (upstream resolver), `examples/wiki/README.md`, `examples/wiki/DEPLOY.md`."
+            },
+            {
+              "title": "Operator action",
+              "body": "Dev users with `localhost:8080` bookmarks, curl scripts, host-firewall allowlists, or IDE port forwarders pointed at the wiki need to switch to `localhost:3008`. Operators who set `WIKI_PORT=8080` explicitly in their `.env` keep working unchanged. Production deployments behind Caddy see no change — the upstream port is internal-network only."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "IANA Service Name and Port Number Registry",
+          "url": "https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml"
+        }
+      ]
+    },
+    {
+      "version": "0.11.39",
+      "date": "2026-05-21",
+      "headline": "`b.calendar.expandRecurrence` honors multiple `recurrenceRules` (RFC 8984 §4.3.2)",
+      "summary": "Closes the v0.11.31 deferral on the multi-rule path. `expandRecurrence` now walks every entry in `event.recurrenceRules`, expands each rule independently against the same `start` anchor, and UNIONs the resulting instances (dedup + sorted ascending). Per-rule `count` caps apply per-rule per RFC 8984 §4.3.2; the global `max` / `MAX_EXPAND_INSTANCES` cap applies to the unioned set. The step budget (`MAX_EXPAND_INSTANCES * 366`) is shared across all rules in the same expand call so an N-rule fan-out can't amplify the worst-case loop past the single-rule bound.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "Multi-rule expansion + UNION",
+              "body": "`event.recurrenceRules` of length > 1 now expands every rule, not just the first. Each rule's stepping (frequency / interval / count / until / BY* filters) operates independently; the resulting ISO 8601 UTC instant strings dedupe via object-keyed set semantics, then sort ascending. The single-rule case is structurally unchanged — same step loop, same per-rule cap behaviour."
+            },
+            {
+              "title": "Per-rule `count` applies per-rule (RFC 8984 §4.3.2)",
+              "body": "Two rules with `count: 3` and `count: 2` produce up to 5 instances in the unioned output (minus any timestamps that dedupe across rules), not 5 instances total across the rules. Matches RFC 8984 §4.3.2 phrasing: each Recurrence Rule's count is applied per rule."
+            },
+            {
+              "title": "Global step budget shared across rules",
+              "body": "The `MAX_EXPAND_INSTANCES * 366` step budget (introduced in v0.11.31) now tracks across rules in the same expand call. A 4-rule event with sparse BY* filters can't accumulate 4× the single-rule worst-case work; the budget is depleted across the full rule set."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "DoS amplification across N rules bounded by the same step budget",
+              "body": "The step budget is shared (not per-rule), so adversarial multi-rule events can't bypass the v0.11.31 BY*-filter cap by stacking N rules with sparse filters. Sparse-filter rules still complete within the original 10-year `MAX_EXPAND_SPAN_MS` window cap."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "No new detector — covered by existing recurrence-test surface",
+              "body": "Multi-rule UNION + dedup + global step budget are exercised by three new tests in `test/layer-0-primitives/calendar.test.js` (multi-rule union, same-rule dedup, global max applied to union). No detector needed — the bug class is testable end-to-end and the test file IS the canonical regression surface."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8984 §4.3.2 (JSCalendar RecurrenceRule — multi-rule expansion)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-4.3.2"
+        },
+        {
+          "label": "RFC 5545 §3.8.5.3 (iCalendar RRULE — semantics under composition)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.5.3"
+        }
+      ]
+    },
+    {
+      "version": "0.11.38",
+      "date": "2026-05-21",
+      "headline": "`b.mail.server.jmap.emailSubmissionSetHandler` — reference JMAP EmailSubmission/set composing `b.mail.send.deliver`",
+      "summary": "Reference implementation of JMAP `EmailSubmission/set` (RFC 8621 §7.5) that composes `b.mail.send.deliver` (v0.11.24). Operators wire it as a method handler on `b.mail.server.jmap.create({ methods: ... })`. The handler walks `args.create`, validates each EmailSubmission's shape against the RFC 8621 §7.5 vocabulary (`identityId` / `emailId` / `envelope.mailFrom.email` / `envelope.rcptTo[]`), looks up the referenced Email blob via an operator-supplied `lookupEmail(emailId, accountId, actor)`, hands the RFC 822 body to `deliver(envelope)`, and maps the result into JMAP `deliveryStatus` (`recipient → { smtpReply, delivered, displayed }` per RFC 8621 §7.4). Closes the v0.11.24 deferral on a reference JMAP→deliver bridge.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.mail.server.jmap.emailSubmissionSetHandler(opts)` factory",
+              "body": "Returns an async `(actor, args, ctx) → result` function suitable for the `opts.methods` map on `b.mail.server.jmap.create`. Required opts: `deliver` (a `b.mail.send.deliver` instance), `lookupEmail` (async `(emailId, accountId, actor) → Buffer|null`), `identities` (sync `(accountId) → Array<{ id, email }>`). Optional: `onCreated(subId, submission, accountId)` for persistence, `onDestroyed(subId, accountId)`, `onCancel(subId, accountId) → boolean` for undo support, `maxRecipients` (default 1000)."
+            },
+            {
+              "title": "Full RFC 8621 §7.5 error vocabulary",
+              "body": "Refusals map to the spec's typed `notCreated` shape with JMAP-namespaced types: `identityNotFound` (unknown identityId), `emailNotFound` (lookupEmail returned null), `forbiddenMailFrom` (envelope.mailFrom doesn't match identity.email), `invalidRecipients` (malformed envelope.rcptTo[i].email), `noRecipients` (empty rcptTo), `tooManyRecipients` (exceeds maxRecipients), `invalidProperties` (missing required keys). Per RFC 8621 §3.6.2, only `undoStatus` is honored in `args.update`; non-canceled values + non-undoStatus keys return `invalidProperties`."
+            },
+            {
+              "title": "Delivery-result → JMAP deliveryStatus mapping",
+              "body": "`b.mail.send.deliver`'s `{ delivered, deferred, failed }` outcomes translate into the per-recipient JMAP deliveryStatus shape: `delivered` → `{ smtpReply, delivered: \"yes\" }`; `deferred` → `{ smtpReply, delivered: \"queued\" }`; `failed` → `{ smtpReply, delivered: \"no\" }`. `displayed` is `unknown` until a downstream MDN (RFC 9007) reports otherwise — operators with MDN ingest update via `EmailSubmission/set`'s update branch."
+            },
+            {
+              "title": "Undo via `onCancel` hook",
+              "body": "`args.update[subId] = { undoStatus: \"canceled\" }` invokes `opts.onCancel(subId, accountId) → boolean`. Operators backing the JMAP server with a deferred-send queue (e.g. `b.outbox`) return true when the cancel succeeded; the handler refuses with `cannotUnsend` when `onCancel` isn't configured (operator hasn't wired a queue-based send model)."
+            },
+            {
+              "title": "Audit event on every set",
+              "body": "Emits `mail.jmap.emailsubmission.set` with `{ accountId, created, notCreated, updated, notUpdated, destroyed, notDestroyed }` counts. The metadata never carries recipient email addresses or RFC 822 body bytes — those stay in the operator's deliver primitive's per-host audit stream."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Identity binding refuses spoofed `envelope.mailFrom`",
+              "body": "RFC 8621 §7.5.1.2 — every create gates `envelope.mailFrom.email` against the identity record's `email` field. The reference handler refuses with `forbiddenMailFrom` when they differ. Operators wiring a delegation model populate the identity's `mayDelegate` / per-domain authorized-senders list and supply the corresponding `identities(accountId)` lookup; the reference handler treats the lookup output as the trust source."
+            },
+            {
+              "title": "Recipient count cap matches `b.mail.send.deliver`",
+              "body": "Default `maxRecipients = 1000` aligns with `b.mail.send.deliver`'s recipient-fan-out cap; operators reduce it for tighter postures (e.g. 50 for transactional-mail accounts) without weakening the deliver primitive's own gate."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "Two new KNOWN_CLUSTERS family-subset entries",
+              "body": "The new handler's opts-walk shingle structurally resembles `lib/importmap-integrity.js:build` (SRI module-map walk) and `lib/middleware/security-headers.js:create` (header-map walk). Added explanatory family-subset entries documenting why each primitive's per-entry body validates a distinct spec vocabulary (W3C Importmap-Integrity vs RFC 8621 §7.5 EmailSubmission vs HTTP header-value sanitisation) so the dup detector can't surface the false-positive again."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8621 §7 (JMAP EmailSubmission)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html#section-7"
+        },
+        {
+          "label": "RFC 8621 §7.5 (EmailSubmission/set)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html#section-7.5"
+        },
+        {
+          "label": "RFC 8621 §7.4 (deliveryStatus shape)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html#section-7.4"
+        },
+        {
+          "label": "RFC 8620 §3.6.1 (JMAP error vocabulary)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8620.html#section-3.6.1"
+        }
+      ]
+    },
+    {
+      "version": "0.11.37",
+      "date": "2026-05-21",
+      "headline": "`b.calendar` VJOURNAL ↔ JSCalendar Note (RFC 5545 §3.6.3)",
+      "summary": "Closes the v0.11.31 deferral on VJOURNAL. `b.calendar.fromIcal` now recognises VJOURNAL components and maps them to JSCalendar-shaped Note objects (`@type: \"Note\"`). `b.calendar.toIcal` emits a VJOURNAL envelope when the input `@type` is `Note`. `b.calendar.validate` adds Note-specific shape rules: optional `start` LocalDateTime, no `duration` / `due` / `progress` / `percentComplete` / `progressUpdated` (those are Event / Task-only properties), optional `status` from the RFC 5545 §3.8.1.11 VJOURNAL vocabulary (`draft` | `final` | `cancelled`). VJOURNAL is the only iCalendar component that may carry multiple DESCRIPTION properties — Note preserves operator-visible boundaries by joining them with a blank-line separator. A VCALENDAR carrying VEVENT + VTODO + VJOURNAL children now returns a mixed `Event` + `Task` + `Note` array.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.calendar.fromIcal` maps VJOURNAL → JSCalendar Note",
+              "body": "VJOURNAL components in the VCALENDAR map to `@type: \"Note\"` objects with `uid` / `updated` / `title` (SUMMARY) / `description` (DESCRIPTION) / `start` (DTSTART → LocalDateTime, optional) / `timeZone` / `status` (lower-cased STATUS) / `locations` / `recurrenceRules`. UTC DTSTART maps to `timeZone: \"Etc/UTC\"` the same way DTSTART does for Event."
+            },
+            {
+              "title": "`b.calendar.toIcal` emits VJOURNAL when `@type === \"Note\"`",
+              "body": "The envelope is `BEGIN:VJOURNAL` / `END:VJOURNAL` instead of `BEGIN:VEVENT` or `BEGIN:VTODO`. Note's `status` round-trips uppercased per RFC 5545 §3.8.1.11. Note does NOT emit DURATION / DUE / PERCENT-COMPLETE / COMPLETED on the wire (those properties are forbidden on VJOURNAL per RFC 5545 §3.6.3 grammar)."
+            },
+            {
+              "title": "`b.calendar.validate` learns Note-specific shape rules (RFC 5545 §3.6.3)",
+              "body": "Note's `start` must be a LocalDateTime when present. Setting `duration`, `due`, `progress`, `percentComplete`, or `progressUpdated` on a Note is refused (those are Event / Task-only properties). `status` must be in the `JSCAL_NOTE_STATUS` catalogue (`draft` | `final` | `cancelled` — different from the Task progress vocabulary). Structured `CalendarError` codes: `calendar/bad-note-status` plus reuse of `calendar/bad-due`, `calendar/bad-progress`, `calendar/bad-duration`, `calendar/bad-percent`, `calendar/bad-progress-updated` for the forbidden-property refusals."
+            },
+            {
+              "title": "Multiple DESCRIPTION properties preserved",
+              "body": "VJOURNAL is the only iCalendar component permitted to carry multiple DESCRIPTION properties (one per discrete journal entry). `fromIcal` joins them into a single Note.description with `\\n\\n` between entries, preserving the operator-visible boundary. Single-DESCRIPTION VJOURNALs map to the literal string with no join."
+            },
+            {
+              "title": "Mixed-component VCALENDAR returns array of Event + Task + Note shapes",
+              "body": "A VCALENDAR carrying VEVENT + VTODO + VJOURNAL children now returns an Array — events first, tasks second, journals third, in their declared order. The single-component shortcut (returning the bare object) still applies when only one component is present."
+            },
+            {
+              "title": "`JSCAL_TYPES.Note` and `JSCAL_NOTE_STATUS` exports",
+              "body": "`b.calendar.JSCAL_TYPES.Note === \"Note\"` (the discriminator string). `b.calendar.JSCAL_NOTE_STATUS` exposes the `draft` / `final` / `cancelled` vocabulary as a frozen object for operator-side enum lookups."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "JSCalendar `Note` is a blamejs-recognised extension",
+              "body": "RFC 8984 §1.2 only enumerates `Event`, `Task`, and `Group` as discriminator values. `Note` is not formally an RFC 8984 type — blamejs adopts it as a recognised extension shape for VJOURNAL round-trip interop. Operators interoperating with strict RFC 8984 consumers should map Note → Group + a vendor-namespaced property before exchange."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5545 §3.6.3 (iCalendar VJOURNAL component)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.6.3"
+        },
+        {
+          "label": "RFC 5545 §3.8.1.11 (STATUS — DRAFT/FINAL/CANCELLED on VJOURNAL)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.1.11"
+        },
+        {
+          "label": "RFC 8984 §1.2 (JSCalendar @type discriminator)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-1.2"
+        }
+      ]
+    },
+    {
+      "version": "0.11.36",
+      "date": "2026-05-21",
+      "headline": "`b.calendar.expandRecurrence` picks up BYWEEKNO / BYYEARDAY / BYHOUR / BYMINUTE / BYSECOND filters (RFC 5545 §3.3.10)",
+      "summary": "Closes the v0.11.31 deferral on the time-of-day and year-relative BY* filters. `expandRecurrence` now honours `byWeekNo` (ISO 8601 1..53 with negative-from-end semantics), `byYearDay` (1..366 with negative-from-end), `byHour` (0..23), `byMinute` (0..59), and `bySecond` (0..60 — covers POSIX leap-second representation). The expansion still operates as a per-step filter (stepping at the rule's FREQ, then dropping candidates that fail the BY* predicates) — BYSETPOS remains deferred-with-condition because it requires expanding ALL candidates within a FREQ interval and picking the Nth, which is a structural restructure of the expand loop. Operators with `last weekday of month`-style needs continue to see the same defer note from v0.11.31.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`byWeekNo` filter — ISO 8601 week numbers",
+              "body": "`recurrenceRules[i].byWeekNo: [1, 53, -1]` filters candidates to the named ISO 8601 weeks. Negative values count from the end of the year (`-1` = last ISO week, which may be week 52 or week 53 depending on the year). The ISO week-of-year calculation matches the canonical algorithm — week 1 is the week containing the first Thursday of the year."
+            },
+            {
+              "title": "`byYearDay` filter — day-of-year (1..366 / -1..-366)",
+              "body": "`recurrenceRules[i].byYearDay: [1, 366, -1]` filters by ordinal day-of-year. Negative values count from the end of the year, accounting for leap-year length (366 vs 365). With a `frequency: \"daily\"` rule + `byYearDay: [1]` the expander emits Jan 1 of each year."
+            },
+            {
+              "title": "`byHour` / `byMinute` / `bySecond` time-of-day filters",
+              "body": "`byHour: [9, 17]` filters candidates by UTC hour-of-day (0..23). `byMinute: [0, 30]` (0..59). `bySecond: [0, 30, 60]` (0..60 — the leap-second representation in POSIX time). Most useful with sub-day frequencies — `frequency: \"hourly\"` + `byHour: [9, 17]` emits twice-daily at 9am and 5pm."
+            },
+            {
+              "title": "Negative BY* semantics per RFC 5545 §3.3.10",
+              "body": "`byWeekNo: [-1]` matches the last ISO week of the year (computed via the Dec-28 anchor — Dec 28 always falls in the last ISO week). `byYearDay: [-1]` matches the last day of the year (uses the Gregorian leap-year rule to determine whether 365 or 366 is the correct ordinal). Both negative-value paths covered by tests."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Same step-budget cap from v0.11.31 applies",
+              "body": "Sparse BY* filters (e.g. `byYearDay: [1]` with `frequency: \"daily\"` — only 1 in 365 candidates matches) still loop within the `MAX_EXPAND_INSTANCES * 366` step budget; the 10-year `MAX_EXPAND_SPAN_MS` window cap also applies. Operators can't construct a BY*-filter that loops past the bounded budget."
+            },
+            {
+              "title": "Integer-range validation on every BY* value",
+              "body": "`byWeekNo` rejects values outside ±53. `byYearDay` rejects outside ±366. `byHour` 0..23. `byMinute` 0..59. `bySecond` 0..60. Adversarial-shape values silently drop from the set (no error — the rule continues with the surviving values per RFC 5545's tolerant grammar)."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5545 §3.3.10 (RRULE — BYWEEKNO / BYYEARDAY / BYHOUR / BYMINUTE / BYSECOND)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.3.10"
+        },
+        {
+          "label": "RFC 8984 §4.3.2 (JSCalendar RecurrenceRule)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-4.3.2"
+        },
+        {
+          "label": "ISO 8601 (Week numbering)",
+          "url": "https://www.iso.org/iso-8601-date-and-time-format.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.35",
+      "date": "2026-05-21",
+      "headline": "`b.calendar` VTODO ↔ JSCalendar Task (RFC 8984 §6)",
+      "summary": "Closes the v0.11.31 deferral. `b.calendar.fromIcal` now recognises VTODO components and maps them to JSCalendar Task objects per RFC 8984 §6. `b.calendar.toIcal` emits a VTODO envelope (with DUE / STATUS / PERCENT-COMPLETE / COMPLETED iCalendar properties) when the input `@type` is `Task`. `b.calendar.validate` picks up Task-specific shape rules: `due` as LocalDateTime, `estimatedDuration` as PnYnMnDTnHnMnS, `progress` from the RFC 8984 §6.4.3 vocabulary (`needs-action` | `in-process` | `completed` | `cancelled` | `failed`), `percentComplete` ∈ [0..100], `progressUpdated` as UTCDateTime. A VCALENDAR carrying both VEVENT and VTODO components now returns an array of mixed `Event` + `Task` shapes.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.calendar.fromIcal` maps VTODO → JSCalendar Task",
+              "body": "VTODO components in the VCALENDAR are mapped to `@type: \"Task\"` objects with the same `uid` / `updated` / `title` / `description` / `start` / `timeZone` / `locations` / `recurrenceRules` slots Event uses, plus the Task-specific fields: `due` (DUE → LocalDateTime), `estimatedDuration` (DURATION), `progress` (STATUS lowercased), `percentComplete` (PERCENT-COMPLETE 0..100), `progressUpdated` (COMPLETED → UTCDateTime). UTC DUE values map to `timeZone: \"Etc/UTC\"` the same way DTSTART does."
+            },
+            {
+              "title": "`b.calendar.toIcal` emits VTODO when `@type === \"Task\"`",
+              "body": "The envelope is `BEGIN:VTODO` / `END:VTODO` instead of `BEGIN:VEVENT`. Task-specific properties round-trip: `DUE` (with `;TZID=` parameter or `Z` suffix or floating local time per the same RFC 8984 §1.4.4 timeZone mapping as DTSTART), `STATUS` (uppercased), `PERCENT-COMPLETE`, `COMPLETED` (UTC). `estimatedDuration` maps to `DURATION` (RFC 5545 doesn't distinguish Event vs Task duration on the wire)."
+            },
+            {
+              "title": "`b.calendar.validate` learns Task-specific shape rules (RFC 8984 §6.4)",
+              "body": "`due` must be a LocalDateTime, `estimatedDuration` must match the same PnYnMnDTnHnMnS Duration grammar Event uses, `progress` must be in the `JSCAL_TASK_PROGRESS` catalogue (also exposed as a new top-level export), `percentComplete` must be a finite number in 0..100, `progressUpdated` must be a UTCDateTime. Structured `CalendarError` codes: `calendar/bad-due`, `calendar/bad-progress`, `calendar/bad-percent`, `calendar/bad-progress-updated`."
+            },
+            {
+              "title": "Mixed-component VCALENDAR returns an array of Event + Task shapes",
+              "body": "When a VCALENDAR contains both VEVENT and VTODO children, `fromIcal` returns an Array — events first, tasks second, in their declared order. The single-component shortcut (returning the bare object) still applies when only one component is present."
+            },
+            {
+              "title": "`calendar/no-vevent` error code renamed to `calendar/no-component`",
+              "body": "The refusal that fires when a VCALENDAR has no parseable child component now uses the more accurate `calendar/no-component` code (since VTODO is also valid). Operators that grep on the prior `calendar/no-vevent` code need to update the match; the human-facing error message also updates."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8984 §6 (JSCalendar Task)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html#section-6"
+        },
+        {
+          "label": "RFC 5545 §3.6.2 (iCalendar VTODO component)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.6.2"
+        },
+        {
+          "label": "RFC 5545 §3.8.2.3 (DUE date-time)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.2.3"
+        },
+        {
+          "label": "RFC 5545 §3.8.1.11 (STATUS — needs-action/in-process/completed/cancelled)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html#section-3.8.1.11"
+        }
+      ]
+    },
+    {
+      "version": "0.11.34",
+      "date": "2026-05-21",
+      "headline": "JMAP WebSocket transport (RFC 8887) on `b.mail.server.jmap`",
+      "summary": "Closes the v0.11.29 deferral. The JMAP listener now exposes `webSocketHandler(req, socket, head)` — a turnkey RFC 8887 transport built on the framework's `b.websocket.handleUpgrade`. Clients connect with the `jmap` subprotocol; bidirectional JSON frames carry `{ \"@type\": \"Request\" }` / `{ \"@type\": \"WebSocketPushEnable\" }` / `{ \"@type\": \"WebSocketPushDisable\" }` from the client, and `{ \"@type\": \"Response\" }` / `{ \"@type\": \"StateChange\" }` / `{ \"@type\": \"RequestError\" }` from the server. `Request` frames flow through the same `dispatch(actor, request)` path the HTTP `apiHandler` uses; `WebSocketPushEnable` hooks the operator's `mailStore.subscribePush(actor, types, emitFn)` and converts backend StateChange events into outbound WebSocket frames.\n\nThe session resource picks up `webSocketUrl` so clients discover the endpoint via the same JMAP session-discovery flow they use for `apiUrl` / `eventSourceUrl` / `uploadUrl` / `downloadUrl`. permessage-deflate is OFF by default — same CRIME-class compression-oracle threat model as the v0.11.28 IMAP COMPRESS=DEFLATE intentional skip — operators opt in via `opts.webSocketPermessageDeflate`.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`webSocketHandler(req, socket, head)` on the listener handle",
+              "body": "Mount on the operator's HTTP server's `'upgrade'` event. Auth is delegated to the surrounding HTTP middleware (the handler expects `req.user` / `req.actor` to be populated by upstream auth); unauthenticated requests write `HTTP/1.1 401 Unauthorized` to the raw socket per the WebSocket spec's pre-handshake error shape. RFC 8887 §3.1 requires the `jmap` subprotocol; the handler refuses the upgrade with close-code 1002 if `Sec-WebSocket-Protocol: jmap` is missing."
+            },
+            {
+              "title": "Bidirectional JSON-framed transport",
+              "body": "Client → server `@type`: `Request` (same body as HTTP POST — `{ using, methodCalls, createdIds? }`), `WebSocketPushEnable` (`{ dataTypes?, pushState? }`), `WebSocketPushDisable`. Server → client `@type`: `Response` (`{ requestId, methodResponses, sessionState, createdIds }`), `StateChange` (`{ changed, pushed? }`), `RequestError` (`{ requestId, type, description }`). Unknown `@type` frames trigger a `RequestError` rather than tearing down the channel."
+            },
+            {
+              "title": "Push integration shares the operator hook with EventSource",
+              "body": "`WebSocketPushEnable` forwards `(actor, dataTypes, emitFn)` to `mailStore.subscribePush` — the same backend hook the EventSource handler (v0.11.29) consumes. Operators wire push once and both transports surface the same `StateChange` events. Per-connection `WebSocketPushDisable` calls the unsubscribe function the backend returned from `subscribePush`. Connection close cleans up implicitly."
+            },
+            {
+              "title": "Session resource carries `webSocketUrl`",
+              "body": "The session JSON now includes `webSocketUrl: opts.webSocketUrl || \"/jmap/ws\"` per RFC 8887 §3. Operators discoverable-by-default — clients using a stock JMAP library find the WS endpoint via the session resource the same way they find `apiUrl` today."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Binary frames refused",
+              "body": "JMAP is JSON-only over WebSocket. Binary frames trigger a `RequestError` with `type: \"notJSON\"`; the connection stays open so the next text frame can be valid. Prevents a misbehaving client from sneaking opaque bytes past the JSON parser."
+            },
+            {
+              "title": "JSON parse routed through `b.safeJson.parse`",
+              "body": "WebSocket text frames are parsed through `b.safeJson.parse` with the per-connection `maxBytes` cap (default 10 MiB; operator-tunable via `opts.webSocketMaxMessageBytes`). Catches CVE-2020-7660-class prototype-pollution payloads + adversarial-depth JSON before they reach the JMAP method dispatcher."
+            },
+            {
+              "title": "permessage-deflate OFF by default (CRIME-class threat)",
+              "body": "RFC 7692 permessage-deflate enables compression-oracle attacks (CVE-2012-4929 CRIME class) when the operator pipes JSON containing both attacker-controlled and confidential data through the same connection. Default is OFF; operators with explicit threat-model justification opt in via `opts.webSocketPermessageDeflate = true`. Mirrors the v0.11.28 IMAP COMPRESS=DEFLATE intentional refusal."
+            },
+            {
+              "title": "Subprotocol negotiation refuses non-`jmap` clients",
+              "body": "If the client's `Sec-WebSocket-Protocol` header doesn't include `jmap`, the listener refuses the upgrade with close-code 1002 (protocol error). RFC 8887 §3.1 — the JMAP-WS connection is identified by the subprotocol; refusing here prevents the connection from being misinterpreted as a generic WebSocket channel by middleware downstream."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8887 (JMAP over WebSocket)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8887.html"
+        },
+        {
+          "label": "RFC 8620 (JMAP Core)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8620.html"
+        },
+        {
+          "label": "RFC 6455 (The WebSocket Protocol)",
+          "url": "https://www.rfc-editor.org/rfc/rfc6455.html"
+        },
+        {
+          "label": "RFC 7692 (Compression Extensions for WebSocket — NOT enabled)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7692.html"
+        },
+        {
+          "label": "CVE-2012-4929 (CRIME — compression-oracle attack on TLS)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4929"
+        }
+      ]
+    },
+    {
+      "version": "0.11.33",
+      "date": "2026-05-21",
+      "headline": "IMAP QRESYNC (RFC 7162 §3.2) — VANISHED responses + SELECT delta on `b.mail.server.imap`",
+      "summary": "Closes the v0.11.27 deferral. The IMAP listener now advertises QRESYNC in CAPABILITY, accepts `ENABLE QRESYNC` (which implicitly engages CONDSTORE per §3.2.5), and parses the `(QRESYNC (<uidvalidity> <modseq> [<knownUids>] [<knownSequenceMatchData>]))` parameter list on SELECT / EXAMINE. When the client's UIDVALIDITY matches the backend's, the listener emits a single `* VANISHED (EARLIER) <uid-set>` listing UIDs the server expunged since the client's snapshot — operators implement the actual delta computation via `mailStore.selectFolder(actor, mailbox, { qresync }) → { ..., vanishedEarlier }`. Stale-UIDVALIDITY clients fall through to a full re-SELECT.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "CAPABILITY advertises `QRESYNC`",
+              "body": "Sits next to the existing `CONDSTORE` advertisement. Both extensions are server-advertised; clients ENABLE before relying on the responses. RFC 7162 §3.2.5 — QRESYNC implies CONDSTORE."
+            },
+            {
+              "title": "`ENABLE QRESYNC` engages both flags",
+              "body": "The handler flips `state.enabledQResync = true` AND `state.enabledCondStore = true` and emits `* ENABLED QRESYNC` + `OK ENABLE completed`. Already-engaged QRESYNC re-issues skip the advertisement line (only newly-engaged extensions appear)."
+            },
+            {
+              "title": "`SELECT mailbox (QRESYNC (<uidvalidity> <modseq> [<knownUids>] [<knownSeq>]))`",
+              "body": "The QRESYNC parameter list is stripped from the SELECT args before the mailbox-name validator runs and forwarded to `mailStore.selectFolder` as `opts.qresync = { uidvalidity, modseq, knownUids, knownSeq }`. Backends compute the delta and return `vanishedEarlier` (sequence-set string) in the existing select-info object. Non-finite uidvalidity / modseq values refuse with `BAD SELECT QRESYNC params must be (<uidvalidity> <modseq> ...) numerics` before the backend call."
+            },
+            {
+              "title": "Implicit CONDSTORE+QRESYNC engagement on parameterised SELECT",
+              "body": "Per RFC 7162 §3.2.4, a client that issues `SELECT INBOX (QRESYNC (...))` without a prior `ENABLE QRESYNC` flips both flags implicitly for the session. Subsequent FETCH responses include `MODSEQ (<n>)` just as they would after explicit ENABLE."
+            },
+            {
+              "title": "`* VANISHED (EARLIER) <uid-set>` emission",
+              "body": "The listener emits a single VANISHED untagged response between `HIGHESTMODSEQ` and the tagged OK when (a) the client supplied a QRESYNC parameter, (b) the client's UIDVALIDITY matches the backend's, AND (c) the backend supplied a non-empty `vanishedEarlier`. Mismatched UIDVALIDITY suppresses the VANISHED line so the client correctly falls through to a full re-sync (RFC 7162 §3.2.5)."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "QRESYNC parameter parse is bounded",
+              "body": "The regex anchors on `\\(\\s*QRESYNC\\s*\\(\\s*([^)]+)\\)` — `[^)]*` not `.*` — so a malformed parameter list cannot consume the entire SELECT args. Both `uidvalidity` and `modseq` parse strictly as `\\d+` via `parseInt(...)` + `isFinite` check; non-numeric values refuse before the backend dispatch."
+            },
+            {
+              "title": "VANISHED suppressed on UIDVALIDITY mismatch",
+              "body": "RFC 7162 §3.2.5 — when the client's `uidvalidity` does NOT match the server's current value, the mailbox has been reset (e.g., recreated under the same name) and the client's UID cache is invalid. The listener intentionally drops the VANISHED line so the client forces a fresh full-sync instead of acting on a delta that references a different message set."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 7162 §3.2 (QRESYNC — Quick Mailbox Resynchronization)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7162.html"
+        },
+        {
+          "label": "RFC 9051 (IMAP4rev2)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9051.html"
+        },
+        {
+          "label": "RFC 5161 (IMAP ENABLE Extension)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5161.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.32",
+      "date": "2026-05-21",
+      "headline": "`b.mail.crypto.pgp.encrypt` / `.decrypt` / `.wkd` promoted to stable — WKD IDN-homograph defense",
+      "summary": "The PGP encrypt / decrypt / Web Key Directory (WKD) primitives that shipped under `b.mail.crypto.pgp.experimental.*` at v0.10.16 are promoted to top-level stable. `b.mail.crypto.pgp.encrypt` / `b.mail.crypto.pgp.decrypt` / `b.mail.crypto.pgp.wkd.fetch` / `b.mail.crypto.pgp.wkd.computeUrl` are now the canonical paths; the v0.10.16 `experimental` aliases continue to work so existing operator code keeps importing through the old path until they migrate at their own pace. WKD picks up a hard IDN-homograph refusal at `wkd.computeUrl` — Cyrillic / Greek / full-width / Han confusable domain characters refuse with `mail-crypto/pgp/bad-domain` before any HTTP fetch runs. Operators with internationalised domains MUST Punycode-encode upstream (RFC 3492 `xn--` form).",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "Top-level `b.mail.crypto.pgp.encrypt` / `.decrypt` / `.wkd.{fetch,computeUrl}`",
+              "body": "Same function bodies that shipped under `b.mail.crypto.pgp.experimental.*` at v0.10.16 are now exported at the top of the namespace. The framework-private envelope (BJ-PGP-PQ magic + version) is unchanged; the IANA-pending RFC 9580bis ML-KEM PKESK codepoints will land as an alternate-encoding option in a follow-up slice. The `experimental` alias keeps the v0.10.16 import paths working — operator migration is opt-in. `b.mail.crypto.pgp.encrypt === b.mail.crypto.pgp.experimental.encrypt` (same reference) so a feature-detection test like `typeof b.mail.crypto.pgp.encrypt === 'function'` is the new operator-facing pattern."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "WKD IDN-homograph refusal at `wkd.computeUrl`",
+              "body": "`wkd.computeUrl(email)` now refuses any domain containing characters outside the LDH+dot ASCII subset (RFC 952 / RFC 1123 §2). The threat model: Cyrillic `а` (U+0430), Greek `ο` (U+03BF), full-width `Ａ` (U+FF21), and Han homographs visually impersonate Latin letters in `paypa1.com` / `gοogle.com` style phishing host strings; a naive `toLowerCase` + concat into the WKD URL would route the key fetch to the attacker's domain. Operators with legitimate internationalised domains MUST Punycode-encode upstream (the `xn--` form is plain ASCII LDH and passes). The framework's `b.httpClient` already refuses non-ASCII hostnames at the SSRF guard layer; this primitive surfaces the same refusal at the WKD entry point so the error surface is consistent."
+            },
+            {
+              "title": "RFC 5321 + RFC 1035 length caps",
+              "body": "Email length capped at 320 octets (RFC 5321 §4.5.3.1 maximum). Domain length capped at 253 octets (RFC 1035 §2.3.4). Empty labels (`bad..example.com`), leading-dot, and trailing-dot domains refuse before any URL construction. Adversarial-length inputs cannot reach the tokenizer / hasher path."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "draft-koch-openpgp-webkey-service (Web Key Directory)",
+          "url": "https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/"
+        },
+        {
+          "label": "RFC 9580 (OpenPGP)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9580.html"
+        },
+        {
+          "label": "RFC 3492 (Punycode — IDNA `xn--` form)",
+          "url": "https://www.rfc-editor.org/rfc/rfc3492.html"
+        },
+        {
+          "label": "RFC 5891 (IDNA 2008)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5891.html"
+        },
+        {
+          "label": "RFC 5321 §4.5.3.1 (SMTP — local-part + domain octet maximums)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5321.html"
+        },
+        {
+          "label": "RFC 1035 §2.3.4 (domain label length)",
+          "url": "https://www.rfc-editor.org/rfc/rfc1035.html"
+        },
+        {
+          "label": "Unicode TR 39 (Security Mechanisms — confusable identifiers)",
+          "url": "https://www.unicode.org/reports/tr39/"
+        }
+      ]
+    },
+    {
+      "version": "0.11.31",
+      "date": "2026-05-21",
+      "headline": "`b.calendar` — JSCalendar (RFC 8984) primitive + JMAP Calendars method catalogue",
+      "summary": "JSCalendar is the JSON-native calendar grammar JMAP Calendars rides on. The framework now ships `b.calendar` — a thin layer over the existing `b.safeIcal.parse` (RFC 5545 bounded parser shipped earlier) that exposes validate / fromIcal / toIcal / expandRecurrence. The JMAP method catalogue at `b.mail.serverRegistry` picks up the 15 Calendar / CalendarEvent / CalendarEventNotification / ParticipantIdentity methods per the draft-ietf-jmap-calendars spec, so operators wire them through the existing `b.mail.server.jmap.create({ methods: { ... } })` dispatch path without `allowExperimental: true` escape-hatches.\n\nv1 scope: validate JSCalendar Event / Task shape per RFC 8984 §5/§6, bidirectional VEVENT ↔ JSCalendar conversion, RRULE expansion for FREQ=DAILY/WEEKLY/MONTHLY/YEARLY/HOURLY/MINUTELY/SECONDLY with INTERVAL / COUNT / UNTIL / BYDAY / BYMONTH / BYMONTHDAY. BYSETPOS / BYWEEKNO / BYYEARDAY filters + non-Gregorian calendars (RFC 7529) + JSCalendar Group objects + VTODO/VJOURNAL mapping are deferred-with-condition for follow-up slices.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.calendar.validate(jsCal)` — JSCalendar Event/Task shape gate (RFC 8984 §5/§6)",
+              "body": "Asserts `@type` ∈ { 'Event', 'Task' }, non-empty `uid` (≤ 1024 bytes), `updated` matches UTCDateTime grammar, Event's optional `start` matches LocalDateTime, `duration` is RFC 8601 PnYnMnDTnHnMnS, every `recurrenceRules[i].@type` is 'RecurrenceRule' with `frequency` in the JSCAL_FREQUENCIES catalogue, every `alerts.{id}.action` is 'display' or 'email'. Returns the input on success; throws `CalendarError` with a structured `.code` (`calendar/no-uid`, `calendar/bad-recurrence`, etc.) on refusal so operator-side error handling has a stable surface."
+            },
+            {
+              "title": "`b.calendar.fromIcal(text, opts?)` + `b.calendar.toIcal(jsCal, opts?)`",
+              "body": "Bidirectional bridge: iCalendar (RFC 5545) ↔ JSCalendar (RFC 8984). `fromIcal` runs the text through `b.safeIcal.parse` (already CVE-bounded for parser DoS) and maps the first VEVENT into an Event object (UID → uid, DTSTAMP → updated, DTSTART → start, DURATION → duration, SUMMARY → title, DESCRIPTION → description, LOCATION → locations[L1].name, RRULE → recurrenceRules[0]). `toIcal` round-trips the same shape back through a CRLF-folded VCALENDAR envelope per RFC 5545 §3.1 (75-octet content-line cap). Operators wire it on the EmailSubmission send path so calendar invitations from a JSCalendar back-end emit RFC 5545 over MIME, and inbound iCalendar attachments parse straight into the JMAP method's Event return shape."
+            },
+            {
+              "title": "`b.calendar.expandRecurrence(event, { from, to, max })` — bounded RRULE expansion",
+              "body": "Emits ISO 8601 UTC instance timestamps for an Event in the operator's `[from, to]` window. Supports FREQ=DAILY/WEEKLY/MONTHLY/YEARLY/HOURLY/MINUTELY/SECONDLY with INTERVAL, COUNT, UNTIL. Bounded by `MAX_EXPAND_INSTANCES` (4096) and `MAX_EXPAND_SPAN_MS` (10 years) — refuses with `calendar/oversize-expansion-span` when the window exceeds 10 years (CVE-2024-39687-class recurrence-bomb defense, mirroring the parser-side caps already in `b.safeIcal`). LocalDateTime starts without a `timeZone` are treated as floating-UTC during expansion so wall-clock semantics survive `Date.parse` host-locale interpretation."
+            },
+            {
+              "title": "JMAP method catalogue: Calendar / CalendarEvent / CalendarEventNotification / ParticipantIdentity",
+              "body": "15 new methods added to `JMAP_METHODS` in `lib/mail-server-registry.js` per draft-ietf-jmap-calendars: `Calendar/{get,changes,set,query,queryChanges}`, `CalendarEvent/{get,changes,query,queryChanges,set,copy}`, `CalendarEventNotification/{get,changes,query,queryChanges,set}`, `ParticipantIdentity/{get,changes,set}`. Operators wire concrete handlers through the existing `b.mail.server.jmap.create({ methods: { 'CalendarEvent/get': async function (actor, args) { ... } } })` path — no `allowExperimental: true` escape-hatch is required."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Recurrence-bomb expansion caps",
+              "body": "`MAX_EXPAND_INSTANCES = 4096` + `MAX_EXPAND_SPAN_MS = 10 years` clamp the expansion budget at the framework boundary so an operator who forwards an unbounded JSCalendar from a hostile peer cannot DoS the host. The caps mirror `b.safeIcal`'s RRULE COUNT + BY-entries caps (which already defend the CVE-2024-39687 class). The 10-year span refusal carries `code: 'calendar/oversize-expansion-span'` so operators distinguish bomb defense from legitimate too-wide-window misconfiguration."
+            },
+            {
+              "title": "UID + duration + UTCDateTime parsing is strict",
+              "body": "`validate` refuses `uid` over 1024 bytes (anti-DoS), `updated` that doesn't match the RFC 8984 §1.4.3 `\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}Z` UTCDateTime grammar exactly (no `+00:00` aliases, no fractional-second-only suffixes), and `duration` that isn't `PnYnMnDTnHnMnS`. Hostile JSCalendar payloads from federation peers can't slip non-canonical-shape values into the operator's storage layer through the validator."
+            },
+            {
+              "title": "iCalendar parsing routed through bounded `b.safeIcal.parse`",
+              "body": "`fromIcal` does NOT roll its own RFC 5545 parser — it forwards to `b.safeIcal.parse` which is already audit-hardened (CVE-2024-39929 / CVE-2025-30258 mitigation, bounded depth, capped RRULE COUNT + BY-entries). The JSCalendar layer composes the existing security substrate rather than re-litigating it."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8984 (JSCalendar — JSON Representation of Calendar Data)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8984.html"
+        },
+        {
+          "label": "RFC 5545 (iCalendar — Internet Calendaring and Scheduling Core Object)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5545.html"
+        },
+        {
+          "label": "draft-ietf-jmap-calendars (JMAP for Calendars)",
+          "url": "https://datatracker.ietf.org/doc/draft-ietf-jmap-calendars/"
+        },
+        {
+          "label": "RFC 8620 (JMAP Core)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8620.html"
+        },
+        {
+          "label": "RFC 8601 (Duration grammar PnYnMnDTnHnMnS)",
+          "url": "https://www.rfc-editor.org/rfc/rfc3339.html"
+        },
+        {
+          "label": "RFC 7986 (New properties for iCalendar)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7986.html"
+        },
+        {
+          "label": "CVE-2024-39687 (iCalendar recurrence-bomb expansion)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39687"
+        }
+      ]
+    },
+    {
+      "version": "0.11.30",
+      "date": "2026-05-21",
+      "headline": "JMAP blob upload + download handlers on `b.mail.server.jmap` (RFC 8620 §6)",
+      "summary": "The JMAP listener now exposes turnkey HTTP handlers for blob upload (`POST /jmap/upload/{accountId}`) and blob download (`GET /jmap/download/{accountId}/{blobId}/{name}`). Upload streams the request body into `b.safeBuffer.boundedChunkCollector` (default cap 50 MiB; operator-tunable via `opts.maxBlobBytes`), then calls the operator backend's `mailStore.uploadBlob(actor, accountId, contentType, bytes) → { blobId, type?, size? }` and returns the JSON descriptor clients pass to subsequent `Email/set` / `Email/import` calls. Download walks the operator backend's `mailStore.downloadBlob(actor, accountId, blobId) → { bytes, type }` and pipes the bytes through with the right `Content-Type` + `Content-Disposition` headers. Both handlers refuse 503 when the corresponding backend hook is missing — never silent OK.\n\nEmailSubmission (RFC 8621 §7) was already in the JMAP method catalogue at `lib/mail-server-registry.js`; operators wire `EmailSubmission/get` / `EmailSubmission/set` through the existing `opts.methods` dispatch and compose `b.mail.send.deliver` (shipped v0.11.24) for the actual outbound send. No additional framework wiring is required.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`uploadHandler(req, res)` — POST `/jmap/upload/{accountId}`",
+              "body": "Streams the request body through `b.safeBuffer.boundedChunkCollector` so a runaway upload refuses with `413 maxSizeUpload` instead of OOM'ing the process. Default cap 50 MiB; tune via `b.mail.server.jmap.create({ maxBlobBytes })`. The `accountId` path segment is identifier-shape-validated (`/^[A-Za-z0-9_-]{1,64}$/`) — path-traversal shapes are refused at the boundary. Calls `mailStore.uploadBlob(actor, accountId, contentType, bytes) → { blobId, type?, size? }`; the listener echoes `accountId` + `blobId` + `type` + `size` back as a `201 Created` JSON response per RFC 8620 §6.1."
+            },
+            {
+              "title": "`downloadHandler(req, res)` — GET `/jmap/download/{accountId}/{blobId}/{name}`",
+              "body": "Parses the path's `accountId` / `blobId` / `name` segments + optional `?accept=<type>` query, calls `mailStore.downloadBlob(actor, accountId, blobId) → { bytes, type } | Buffer | null`, and pipes the bytes through with `Content-Type` (backend-supplied OR query-`accept` OR `application/octet-stream` fallback) + `Content-Length` + `Content-Disposition: attachment; filename=\"<safe-name>\"` (only when the filename matches the safe `[A-Za-z0-9._-]{1,200}` shape — anti header-injection). Missing blob → `404 invalidArguments`."
+            },
+            {
+              "title": "Both handlers exposed on the listener handle",
+              "body": "`b.mail.server.jmap.create(opts)` returns `{ apiHandler, sessionHandler, discoveryHandler, eventSourceHandler, uploadHandler, downloadHandler, MailServerJmapError }`. Operators mount each at the path their HTTP router exposes; the `session.uploadUrl` / `session.downloadUrl` already advertise the canonical paths."
+            },
+            {
+              "title": "EmailSubmission methods continue through the existing dispatch path",
+              "body": "RFC 8621 §7 — `EmailSubmission/get` / `EmailSubmission/changes` / `EmailSubmission/query` / `EmailSubmission/queryChanges` / `EmailSubmission/set` are already in the JMAP method catalogue at `lib/mail-server-registry.js`. Operators wire them through `b.mail.server.jmap.create({ methods: { 'EmailSubmission/set': async function (actor, args) { ... b.mail.send.deliver(...) ... } } })`. No additional framework wiring is required for v0.11.30; the substrate composition (JMAP method → `b.mail.send.deliver` → SMTP MX → DSN) was already complete after v0.11.24."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "AccountId path-traversal refusal at the boundary",
+              "body": "Both handlers validate the `accountId` URL segment against `/^[A-Za-z0-9_-]{1,64}$/`. URL-encoded path-traversal payloads (`%2E%2E%2F`, `..%2F`, `/`) refuse with `400 invalidArguments` before any backend call. Operator-side validation in `mailStore.uploadBlob` / `mailStore.downloadBlob` is a defense-in-depth second layer."
+            },
+            {
+              "title": "Upload size cap via `safeBuffer.boundedChunkCollector` (cap-bounded)",
+              "body": "Replaces the prior hand-rolled `Buffer.concat(chunks, received)` shape with the framework's bounded-collector primitive. The collector throws `mail-server-jmap/blob-too-large` on overflow; the handler converts it into a `413 maxSizeUpload` JSON error per RFC 8620 §6.1. A misbehaving client cannot stream a multi-gigabyte payload past the limit — the collector enforces the cap byte-by-byte."
+            },
+            {
+              "title": "`Content-Disposition` filename is identifier-shape only",
+              "body": "Download responses only set the `Content-Disposition` header when the URL's `name` segment matches `/^[A-Za-z0-9._-]{1,200}$/`. Filenames with `;` / `\"` / CRLF cannot be smuggled into the header — RFC 6266 §4.3 + CVE-2023-46604-class header-injection defense."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8620 (JMAP Core — §6 Blob upload/download)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8620.html"
+        },
+        {
+          "label": "RFC 8621 (JMAP Mail — §7 EmailSubmission)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html"
+        },
+        {
+          "label": "RFC 6266 (Content-Disposition in HTTP)",
+          "url": "https://www.rfc-editor.org/rfc/rfc6266.html"
+        },
+        {
+          "label": "RFC 5987 (Encoding-aware filename* parameter)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5987.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.29",
+      "date": "2026-05-21",
+      "headline": "JMAP Push — EventSource SSE handler on `b.mail.server.jmap` (RFC 8620 §7.3)",
+      "summary": "The JMAP listener now exposes a real EventSource handler at `/jmap/eventsource`. The session-resource's `eventSourceUrl` becomes a live push channel: clients connect with `?types=*|<csv>&closeafter=no|state&ping=<seconds>`, the listener subscribes via the operator backend's `mailStore.subscribePush(actor, types, emitFn)` hook, and StateChange events arrive as `event: state` SSE frames with the `{ \"@type\": \"StateChange\", changed: {...} }` payload per RFC 8620 §7.4. Keepalive `event: ping` frames default to 30 s (operator-tunable 5-900 s), `closeafter=state` closes after one event for poll-like clients, and the SSE response carries the headers proxies expect (`Cache-Control: no-cache`, `Connection: keep-alive`, `X-Accel-Buffering: no`) so nginx-fronted deployments don't buffer the stream. Without the backend subscribe hook the handler refuses with `503 serverUnavailable`, never silent OK.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`eventSourceHandler(req, res)` exposed on the JMAP listener handle",
+              "body": "`b.mail.server.jmap.create(opts).eventSourceHandler` mounts on the operator's HTTP router at whatever path the session-resource's `eventSourceUrl` points to (default `/jmap/eventsource`). Authentication is delegated to the surrounding HTTP middleware (the handler expects `req.user` / `req.actor` to be set); unauthenticated requests return `401 forbidden` per RFC 8620 §1.5. Query-string params parse `types=` (CSV or `*` wildcard), `closeafter=` (`no` | `state`), `ping=` (seconds, clamped 5..900) per §7.3."
+            },
+            {
+              "title": "Operator backend hook — `mailStore.subscribePush(actor, types, emitFn)`",
+              "body": "Backends opt in by exposing a `subscribePush` method that accepts (1) the authenticated actor, (2) a parsed `types` list (or `null` for the wildcard `*`), and (3) an `emitFn(event)` callback the backend calls when a state change occurs. The expected event shape is `{ kind: 'StateChange', changed: { <accountId>: { <typeName>: <stateString>, ... }, ... }, pushed?: {...} }`; the listener formats it into the SSE `event: state\\ndata: <JSON>\\n\\n` wire shape. The subscribe call may return either `void` or an `unsubscribe()` function the listener invokes on disconnect."
+            },
+            {
+              "title": "SSE wire-correct headers + initial-state hint",
+              "body": "Response headers: `Content-Type: text/event-stream; charset=utf-8`, `Cache-Control: no-cache`, `Connection: keep-alive`, `X-Accel-Buffering: no` (nginx-specific — disables response buffering on the stream so per-event frames flush immediately). The initial bytes carry `retry: 5000\\n\\n` (HTML5 SSE reconnect hint — 5 s) + a `: connected\\n\\n` comment so clients can confirm the channel is alive before the first state event."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Push backend missing returns `503 serverUnavailable` (no silent accept)",
+              "body": "If the operator wired the listener without `mailStore.subscribePush`, the handler returns `503 urn:ietf:params:jmap:error:serverUnavailable` with a `description` pointing at the missing hook. RFC 8620 §7.3 expects the server to honour subscriptions or refuse explicitly — silently accepting would let a client believe events will arrive when the server cannot deliver."
+            },
+            {
+              "title": "`closeafter` accepts only `no` | `state` (RFC 8620 §7.3)",
+              "body": "Any other value returns `400 invalidArguments` before the subscribe hook fires. Prevents an operator-supplied query string from steering the handler into an undocumented mode."
+            },
+            {
+              "title": "Ping interval clamped 5..900 seconds",
+              "body": "`ping=<seconds>` below 5 s or above 900 s clamps to the bounds rather than refusing — a misconfigured client cannot DoS the listener via 1 ms ping floods, and a 24 h ping won't outlast intermediate proxy idle timeouts (typical 60-120 s). The clamped default (30 s) matches the RFC 8620 §7.3 example."
+            },
+            {
+              "title": "Ping timer is `.unref()`'d",
+              "body": "Background timers without `.unref()` pin the Node process — graceful shutdown waits indefinitely. The interval is unref'd immediately after creation; per-connection cleanup (`req.on('close')` / `req.on('error')`) clears the timer + invokes the backend's optional `unsubscribe()` + ends the response."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8620 (JMAP Core — §7 Push / §7.3 EventSource / §7.4 StateChange)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8620.html"
+        },
+        {
+          "label": "RFC 8621 (JMAP Mail)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html"
+        },
+        {
+          "label": "RFC 8887 (JMAP WebSocket transport — opt-in, deferred to a later slice)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8887.html"
+        },
+        {
+          "label": "HTML5 Server-Sent Events (EventSource)",
+          "url": "https://html.spec.whatwg.org/multipage/server-sent-events.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.28",
+      "date": "2026-05-21",
+      "headline": "IMAP opt-in extensions: NOTIFY (RFC 5465), METADATA (RFC 5464), CATENATE (RFC 4469)",
+      "summary": "Three IMAP extensions advertised in CAPABILITY and dispatched through the existing per-method registry. NOTIFY accepts a client subscription spec and hands it to the operator's `mailStore.subscribeNotify(actor, spec, emitFn)` hook — actual event emission stays operator-side. METADATA exposes GETMETADATA and SETMETADATA per-mailbox + server-wide annotations through `mailStore.getMetadata` / `setMetadata`. CATENATE extends APPEND to compose a message from existing parts (`TEXT {N}` literals + `URL \"imap://...\"`) via `mailStore.appendCatenate`. Each handler refuses gracefully (`NO ... backend not configured`) when the operator backend doesn't supply the hook. COMPRESS=DEFLATE (RFC 4978) intentionally NOT advertised — CRIME-class compression-oracle threat on the encrypted IMAP stream.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "CAPABILITY advertises `NOTIFY`, `METADATA`, `METADATA-SERVER`, `CATENATE`",
+              "body": "All four added unconditionally so capable clients can exercise the extension regardless of authentication state. Each handler is registered in the protocol verb catalogue (`b.mail.serverRegistry`) + the wire-level guard verb list (`b.guardImapCommand.KNOWN_VERBS`) so the existing dispatch + audit + ratelimit gates apply uniformly."
+            },
+            {
+              "title": "`NOTIFY SET ...` / `NOTIFY NONE` — RFC 5465",
+              "body": "The handler parses `NOTIFY SET [STATUS] (<filter-set> (<event>...))*` and `NOTIFY NONE` and stores the filter-set verbatim on `state.notifySpec`. When the operator backend exposes `mailStore.subscribeNotify(actor, spec, emitFn)`, the listener wires an `emitFn` that translates backend events (`{ kind: 'STATUS' | 'LIST' | 'FETCH', payload, seq? }`) into untagged IMAP responses on the same connection — drop-silent if the socket has already closed. Without the backend hook, the wire command refuses with `NO NOTIFY backend not configured` rather than silently accepting subscriptions the server can't fulfil."
+            },
+            {
+              "title": "`GETMETADATA` / `SETMETADATA` — RFC 5464",
+              "body": "Both verbs parse the per-mailbox + server-wide annotation forms. GETMETADATA accepts optional `(MAXSIZE N)` / `(DEPTH ...)` options before the mailbox + entry list, walks the entries through `mailStore.getMetadata(actor, mailbox, names, opts) → [{ entry, value }]`, and renders an untagged `* METADATA <mailbox> (<entry> <value>...)` response. SETMETADATA tokenises the entry/value pairs (quoted-strings + NIL for clearing), validates the mailbox name, and forwards to `mailStore.setMetadata(actor, mailbox, entries)`. Without the backend hooks, both return `NO ... backend not configured`."
+            },
+            {
+              "title": "APPEND `CATENATE` modifier — RFC 4469",
+              "body": "`APPEND mailbox [flags] [date-time] CATENATE (...)` is recognised before the legacy literal-required APPEND path. The parts list mixes `TEXT {N}` literal-bytes parts (handed in via the literal-aware parser) and `URL \"imap://...\"` reference parts; the listener bundles them into `parts: [{ kind: 'TEXT', bytes } | { kind: 'URL', url }]` and forwards to `mailStore.appendCatenate(mailbox, parts, { actor, flags, internalDate }) → { uid, uidValidity }`. When the backend returns the APPENDUID metadata the response carries `OK [APPENDUID <validity> <uid>] APPEND completed` (RFC 4315). Without the backend hook, refuses with `NO CATENATE backend not configured`."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "COMPRESS=DEFLATE intentionally NOT advertised (CRIME-class)",
+              "body": "RFC 4978 IMAP COMPRESS=DEFLATE enables stream compression that interacts badly with TLS — the CRIME attack class (CVE-2012-4929, BREACH, et al.) recovers plaintext via chosen-plaintext compression-ratio analysis. The framework default is OFF; operators with explicit threat models accept the downgrade via `opts.compress = true` (no opt-in path landed in v1, intentionally — defer-with-condition: open when an operator surfaces a deployment that needs it AND can document the chosen-plaintext threat model is mitigated)."
+            },
+            {
+              "title": "Mailbox-name validation reused for both METADATA verbs",
+              "body": "Both GETMETADATA and SETMETADATA run `_validateMailboxName` on the parsed mailbox argument (except for the empty-string `\"\"` server-wide-metadata special case per RFC 5464 §3.1). Operators with the existing `allowLegacyMUtf7` opt see the same mailbox-name policy as the rest of the listener; injection-shape mailbox names are refused identically."
+            },
+            {
+              "title": "NOTIFY backend-missing returns NO (not silent accept)",
+              "body": "If the operator wired the listener without `mailStore.subscribeNotify`, `NOTIFY SET ...` returns `NO NOTIFY backend not configured` — never a silent `OK`. RFC 5465 §6 specifies NO as the correct refusal shape; silent acceptance would let a client believe events will arrive when the server cannot fulfil the subscription."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5465 (IMAP NOTIFY)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5465.html"
+        },
+        {
+          "label": "RFC 5464 (IMAP METADATA)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5464.html"
+        },
+        {
+          "label": "RFC 4469 (IMAP CATENATE)",
+          "url": "https://www.rfc-editor.org/rfc/rfc4469.html"
+        },
+        {
+          "label": "RFC 4315 (IMAP UIDPLUS — APPENDUID response)",
+          "url": "https://www.rfc-editor.org/rfc/rfc4315.html"
+        },
+        {
+          "label": "RFC 4978 (IMAP COMPRESS — NOT enabled; CRIME-class threat)",
+          "url": "https://www.rfc-editor.org/rfc/rfc4978.html"
+        },
+        {
+          "label": "CVE-2012-4929 (CRIME — compression-oracle attack on TLS)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2012-4929"
+        }
+      ]
+    },
+    {
+      "version": "0.11.27",
+      "date": "2026-05-20",
+      "headline": "IMAP CONDSTORE (RFC 7162) — modseq-aware FETCH + STORE on `b.mail.server.imap`",
+      "summary": "The IMAP listener advertises and honours the CONDSTORE extension. Clients that issue `ENABLE CONDSTORE` get MODSEQ attributes in every untagged FETCH response; FETCH parses the `(CHANGEDSINCE <modseq>)` modifier and forwards it to the operator's backend so the backend can prune unchanged rows server-side; STORE parses the `(UNCHANGEDSINCE <modseq>)` conditional-update modifier and surfaces the backend's MODIFIED conflict set in the tagged OK response (`OK [MODIFIED <set>] STORE completed`). The backend interface picks up four new opts on the existing `fetchRange` / `storeFlags` calls: `changedSince`, `includeVanished`, `includeModseq`, `unchangedSince`. Backends MAY return modseq on each row; the listener injects `MODSEQ (<n>)` into the payload when present and CONDSTORE is enabled. QRESYNC (RFC 7162 §3.2) is deferred — accepted in ENABLE but no vanished-set surface is exposed yet.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "CAPABILITY advertises `CONDSTORE` unconditionally",
+              "body": "Per RFC 7162 §3 servers advertise CONDSTORE; clients ENABLE before relying on MODSEQ in untagged FETCH responses. The advertisement is unconditional (state-independent) so clients that issue CAPABILITY pre-LOGIN see CONDSTORE in the same untagged-response shape they'll see post-LOGIN. The old SELECT-side `HIGHESTMODSEQ` emission keeps working."
+            },
+            {
+              "title": "`ENABLE CONDSTORE` handler flips `state.enabledCondStore`",
+              "body": "Replaces the no-op `OK ENABLED` shortcut with a real handler that parses the requested capability set, flips `state.enabledCondStore = true` on CONDSTORE, and replies with `ENABLED CONDSTORE` + `OK ENABLE completed`. Unknown extensions are silently ignored per RFC 5161 §3.1. QRESYNC is recognised but accepted only when a v1+ backend exposes the vanished-set surface."
+            },
+            {
+              "title": "FETCH parses `(CHANGEDSINCE <modseq>)` + injects MODSEQ in responses",
+              "body": "When the FETCH args carry a trailing `(CHANGEDSINCE <n>)` modifier (RFC 7162 §3.1.4) the listener strips it from the fetch-att spec and forwards `opts.changedSince` to `mailStore.fetchRange`. The backend can prune unchanged messages server-side. When CONDSTORE is enabled (or the client explicitly requested MODSEQ as a fetch-att), each untagged FETCH response includes `MODSEQ (<n>)` — synthesised from `row.modseq` if the backend supplies it and the payload doesn't already contain it. Also recognises the QRESYNC `VANISHED` modifier (flag forwarded as `opts.includeVanished`); the vanished-set emission is the backend's responsibility for now."
+            },
+            {
+              "title": "STORE parses `(UNCHANGEDSINCE <modseq>)` + emits `[MODIFIED <set>]` on conflict",
+              "body": "Per RFC 7162 §3.1.3 the conditional STORE refuses to update messages whose modseq advanced past `unchangedSince` since the client last fetched. The listener parses the modifier between the seq-set and the FLAGS op, forwards `opts.unchangedSince` to `mailStore.storeFlags`, and accepts either the legacy `rows: [...]` shape or a structured `{ rows, modified }` shape. When `modified` is non-empty, the tagged response carries `OK [MODIFIED <set>] STORE completed` so the client knows which messages need re-fetching before retry. Untagged FETCH responses also include `MODSEQ (<n>)` when STORE accepted updates under CONDSTORE."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Modifier parsing is bounded + non-greedy",
+              "body": "The CHANGEDSINCE / UNCHANGEDSINCE matchers use `[^)]*` rather than `.*` so a malformed modifier can't consume the entire fetch-att spec. Both modifiers parse `\\d+` only — non-integer / negative / Infinity values are silently dropped (the modifier becomes a no-op), so a client cannot ride the modifier to inject arbitrary fragments into the backend opts."
+            },
+            {
+              "title": "Modseq attribute is opt-in",
+              "body": "MODSEQ injection into untagged FETCH responses ONLY happens when (a) CONDSTORE is enabled OR (b) the client's fetch-att spec contains the `MODSEQ` keyword. Pre-CONDSTORE clients see exactly the responses they saw before this release. The IMAP wire-format compatibility line is unchanged for the IMAP4rev1 / IMAP4rev2 cohorts that never issue `ENABLE CONDSTORE`."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 7162 (IMAP4 CONDSTORE / QRESYNC)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7162.html"
+        },
+        {
+          "label": "RFC 9051 (IMAP4rev2)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9051.html"
+        },
+        {
+          "label": "RFC 5161 (IMAP ENABLE Extension)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5161.html"
+        },
+        {
+          "label": "RFC 4315 (IMAP UIDPLUS Extension)",
+          "url": "https://www.rfc-editor.org/rfc/rfc4315.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.26",
+      "date": "2026-05-20",
+      "headline": "`b.mail.server.submission` — CHUNKING / BDAT (RFC 3030)",
+      "summary": "The outbound submission listener now advertises and accepts the RFC 3030 BDAT (binary data) command, the chunked-upload alternative to DATA. Operators with large outbound payloads (attachments, MIME multipart bodies, encoded HTML) no longer pay the dot-stuffing cost of DATA; clients can stream chunks of arbitrary size and finalise with a `BDAT 0 LAST` (or `BDAT N LAST` for the final chunk). Mixing DATA + BDAT within one transaction is refused per RFC 3030 §3. Same `agent.handoff` contract — the body bytes arrive at the agent layer in their canonical SMTP form, no dot-stuffing applied (BDAT payloads are opaque).",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "EHLO advertises `CHUNKING` + new `BDAT <chunk-size> [LAST]` command",
+              "body": "The EHLO 250-line list now includes `CHUNKING` (RFC 3030 §2.1). A new `BDAT` command handler accepts `BDAT <chunk-size> [LAST]` after MAIL FROM + RCPT TO; the server reads exactly `<chunk-size>` bytes from the socket — no dot-stuffing, no end-of-data marker — and acknowledges with `250 2.0.0 <octets> octets received`. Multiple BDAT chunks accumulate into the message body; the final chunk carries the `LAST` keyword and triggers the same agent-handoff path as DATA. A `BDAT 0 LAST` finalises an empty trailer when the last chunk's byte count is unknown in advance."
+            },
+            {
+              "title": "Cumulative size cap honoured up-front",
+              "body": "`BDAT <large-size>` is refused with `552 5.3.4 BDAT cumulative size <total> exceeds maxMessageBytes (<cap>)` BEFORE the server begins reading bytes off the wire. A misconfigured client that pipelines `BDAT 999999999 LAST` and 1 GB of body is rejected at the command line, not after the byte stream lands. The collector bound on the receive side enforces the same cap as a backstop."
+            },
+            {
+              "title": "Mid-segment payload drainage",
+              "body": "When `BDAT N LAST\\r\\n<payload>` arrives in one TCP segment (typical for pipelined small messages), the line-loop drains the post-`\\r\\n` bytes from the command buffer straight into the BDAT collector before returning. Any tail bytes after the BDAT chunk completes get re-fed as the next command. Operators get pipelining + chunking with no extra round-trip cost."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "BDAT state cleared on every STARTTLS upgrade",
+              "body": "Same threat model as CVE-2021-38371 (Exim) / CVE-2021-33515 (Dovecot): pre-handshake bytes a malicious peer pipelined MUST NOT reach the post-TLS state machine. The STARTTLS handler clears `inBdatChunk` / `bdatRemaining` / `bdatCollector` / `bdatTotalBytes` alongside the existing line-buffer + DATA-collector reset, so a smuggled `BDAT <n>` + body that lands before the TLS upgrade can't bleed into the encrypted transaction."
+            },
+            {
+              "title": "Refusal on BDAT outside transaction",
+              "body": "BDAT before MAIL FROM / with zero RCPT returns `503 5.5.1` and does not enter chunk-collection mode. A misbehaving client that issues BDAT eagerly cannot leak state into the next transaction; the RSET reset path also clears all BDAT-side state."
+            },
+            {
+              "title": "Pipelining race gate mirrors DATA",
+              "body": "If the operator's `recipientPolicy` is async and not all RCPT verdicts have resolved, BDAT returns `451 4.5.0 RCPT TO verdicts pending; reissue BDAT after recipient replies` — same shape as the DATA pipelining-race gate. The transaction never commits with a partially-resolved recipient set."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 3030 (SMTP Service Extensions — CHUNKING / BDAT / BINARYMIME)",
+          "url": "https://www.rfc-editor.org/rfc/rfc3030.html"
+        },
+        {
+          "label": "RFC 5321 (SMTP)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5321.html"
+        },
+        {
+          "label": "RFC 6409 (Message Submission for Mail)",
+          "url": "https://www.rfc-editor.org/rfc/rfc6409.html"
+        },
+        {
+          "label": "RFC 8314 (Cleartext considered obsolete — submission ports)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8314.html"
+        },
+        {
+          "label": "CVE-2021-38371 (Exim STARTTLS injection)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-38371"
+        },
+        {
+          "label": "CVE-2021-33515 (Dovecot STARTTLS pre-handshake state leak)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-33515"
+        }
+      ]
+    },
+    {
+      "version": "0.11.25",
+      "date": "2026-05-20",
+      "headline": "Five new primitives: sealed-token mail FTS + Stripe HMAC-SHA256 webhook verify + `b.money` + `b.fsm` + `b.auth.botChallenge`",
+      "summary": "Five additive primitives in one release. Every consumer building on the framework — mail UIs, billing pipelines, e-commerce backends, multi-step business workflows, public web endpoints — now finds the substrate in-tree instead of reimplementing it. None of these replaces a default; every primitive is opt-in at the call site. Mail full-text search hashes tokens with the per-deployment vault salt before any byte hits the SQLite FTS5 index, so the index is searchable but a database dump leaks nothing readable. The Stripe-shaped HMAC-SHA-256 verifier sits next to the existing PQC and SHA3-512 webhook signers; the `whsec_` prefix stays in the key bytes per Stripe's spec; signatures are constant-time-compared and replay-defended via an operator-supplied nonce store. `b.money` arithmetic is BigInt-only across 40 ISO 4217 currencies with largest-remainder allocation and banker's-rounding FX conversion. `b.fsm` is the in-process sibling of `b.agent.saga` — declarative state + transition definition, guards, async on-enter/on-exit, drop-silent audit on every transition, with a transition-serialisation lock that makes concurrent `.transition()` calls deterministic. `b.auth.botChallenge` composes `b.httpClient` for siteverify against Cloudflare Turnstile (default), hCaptcha, and reCAPTCHA-v3 — the secret bytes never appear in any audit metadata.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.mailStore.fts` — sealed-token full-text index + `b.mailStore.create().search(folder, filter)`",
+              "body": "Every `appendMessage` now inserts a row into a SQLite FTS5 virtual table whose subject / address / body columns hold space-separated 16-char hex hashes — vault-salted SHA3 over each NFC-normalised token. The salt is the same `b.vault.getDerivedHashSalt()` `b.cryptoField` uses for sealed-column derived hashes, so rotating the vault salt invalidates the FTS index in step with every other sealed-row hash. Query terms go through the same tokenize → hash transform on the search path and issue FTS5 MATCH against the hash-token rows — the index is fully searchable without ever materialising the plaintext on disk. `b.mail.agent.search({ folder, filter })` now accepts `text` / `subject` / `body` / `from` / `to` filter keys; the agent layer hands them to the store. `hardExpunge` deletes the FTS row inside the same transaction as the canonical message row so the two cannot drift. Limits: 8192 tokens / row / field, 2..64 codepoint length band, 8 MiB input cap per field. Exact-token only (no prefix wildcard, no stemmer) — the cost of sealed-at-rest."
+            },
+            {
+              "title": "`b.webhook.verify({ alg: 'hmac-sha256-stripe', secret, header, body, toleranceMs?, nonceStore? })` + `b.webhook.sign(...)`",
+              "body": "Stripe-spec inbound webhook signature verifier (Paddle + Shopify use the same shape). Parses `Stripe-Signature: t=<unix>,v1=<hex>[,v1=<hex>...]`, validates the timestamp is within the tolerance window (default 5 min; refuses below 30s), HMAC-SHA-256s `<t>.<body>` with the `whsec_...` secret bytes verbatim (the prefix IS the key — `b.webhook.verify` never strips it), and walks the v1 entries with `b.crypto.timingSafeEqual` so a rotation grace window doesn't leak which entry matched. `b.webhook.sign` is the round-trip companion for outbound Stripe-shaped emission and round-trip tests. Optional `nonceStore: { has(k), set(k, ttlMs) }` records the accepted signature so a replay within the tolerance window refuses. The header value is hard-capped at 4096 bytes and per-`v1` hex at 256 chars (anti-DoS)."
+            },
+            {
+              "title": "`b.money` — decimal-safe money + 40-currency ISO 4217 catalog",
+              "body": "BigInt minor units throughout — Number is refused at construction. Currency exponents covering 0 (JPY/KRW), 2 (USD/EUR/GBP/…), 3 (KWD/BHD/JOD/OMR/TND), 4 (CLF) are pre-populated. Surface: `b.money.of(amount, code)` / `b.money.fromMinorUnits(bigint, code)` / `b.money.parse('12.50 USD')` / `b.money.zero(code)` plus instance methods `.add` / `.subtract` / `.multiply` / `.allocate(weights[])` / `.negate` / `.abs` / `.equals` / comparison family / `.toMinorUnits()` / `.toString()` / `.toJSON()` / `.format(locale?)`. `b.money.convert(money, toCurrency, fxRateProvider)` rounds half-to-even (banker's rounding) by default. Cross-currency arithmetic throws; `0.10 + 0.20 === 0.30` exactly. Allocation uses largest-remainder so $10 / 3 = [$3.34, $3.33, $3.33] with sum preserved."
+            },
+            {
+              "title": "`b.fsm` — in-process state machine (sibling of `b.agent.saga`)",
+              "body": "`b.fsm.define({ name, initial, states, transitions })` returns a frozen machine factory. `Machine.create({ initialContext })` returns an instance with `.state` / `.context` / `.history` / `.allowed()` / `.can(name)` / `.transition(name, opts)` / `.toJSON()`. Transitions carry an optional guard (predicate; refusal throws `fsm/guard-refused`) and trigger per-state `onEnter` / `onExit` side-effects (sync or returned-Promise — `.transition` awaits). Every transition emits a `fsm.<machineName>.transition` audit event via `b.audit.safeEmit` (drop-silent on hot path), including the actor + metadata the caller passed in. A transition lock serialises concurrent `.transition()` calls — the test suite exercises five parallel transitions and verifies only the legal path runs. State + transition names are identifier-shape only (`safeSql.DEFAULT_IDENTIFIER_RE`) so a name never lands in SQL / HTML un-validated. `Machine.restore(snapshot)` rebuilds an instance from a prior `.toJSON()` snapshot — state + history + context survive a process restart."
+            },
+            {
+              "title": "`b.auth.botChallenge.create({ secret, provider?, ... }) → { verify(token, opts?) }`",
+              "body": "Server-side challenge-response verifier for Cloudflare Turnstile (default), hCaptcha, and reCAPTCHA-v3. Composes `b.httpClient` for the outbound `/siteverify` POST — every request rides the framework's SSRF guard + DNS pinning + retry policy; the operator's secret never appears in a URL or any audit metadata field. Body encoding is `application/x-www-form-urlencoded` per the provider specs. Returns `{ ok, provider, hostname, action, challengeTs, score?, raw }` on success; throws `BotChallengeError` with structured codes (`invalid-token`, `timeout`, `hostname-mismatch`, `action-mismatch`, `provider-error`) on failure, with the upstream `error-codes` array exposed at `err.errorCodes`. Per-factory `allowedHostnames` + `allowedActions` allowlists; per-call `expectedHostname` + `expectedAction` overrides. Tokens are refused at the factory boundary if empty / non-string / > 4096 bytes, before any outbound call."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "Mail FTS index leaks zero plaintext (sealed-at-rest invariant extended)",
+              "body": "Pre-v0.11.25, the only operator-facing search path on `b.mail.agent` was a modseq cursor + post-fetch unseal — fast for cursoring but useless for text content discovery. Plaintext-FTS would have broken the sealed-at-rest invariant. The new index hashes every indexed token with the per-deployment vault salt before insert; a `sqlite3 .dump` produces ASCII-hex tokens indistinguishable from random. The same vault salt protects every `b.cryptoField`-sealed column, so adding the FTS index does NOT widen the cryptographic trust boundary."
+            },
+            {
+              "title": "Stripe verifier defends the documented attack surface",
+              "body": "Constant-time HMAC compare (timing-safe across the v1 rotation list — operators don't leak which entry matched). Per-`v1` 256-hex anti-DoS cap. Tolerance-window minimum 30s — refuses operator misconfiguration that would accept hour-old signatures. The `whsec_` prefix preservation is encoded as a `codebase-patterns` detector (`stripe-hmac-sha256-no-strip-whsec-prefix`) so re-introducing the strip-bug is impossible without tripping a release gate."
+            },
+            {
+              "title": "Bot-challenge secret never reaches audit / logs",
+              "body": "`b.auth.botChallenge` audit emits `{ provider, hostname, ok, errorCodes }` — the operator's secret bytes never appear in any metadata key. A `codebase-patterns` detector (`bot-challenge-secret-not-in-audit`) scans `lib/auth/bot-challenge.js` for any `audit.*emit` window that references `secret` so a future refactor cannot regress."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "Five new `codebase-patterns` detectors encode the shape-specific bug classes",
+              "body": "`stripe-hmac-sha256-no-strip-whsec-prefix` flags `secret.replace(/^whsec_/, '')` / `secret.slice(6)` near an HMAC call (the `whsec_` prefix IS the key). `no-number-money-arithmetic` flags `b.money.of(<Number>, ...)` and Number / Money arithmetic (precision lost; only BigInt / string OK at construction). `fsm-transition-without-await` flags `<fsm>.transition(...)` without `await` or `.then` in `lib/` (the transition is async; sync misuse swallows errors). `bot-challenge-secret-not-in-audit` is file-scoped to `lib/auth/bot-challenge.js` and flags any `audit.*emit` window or `metadata: { ... }` object literal referencing `secret`. Each detector is wired into `codebase-patterns.test.js`'s `run()` so every future commit re-checks the shape."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 2104 (HMAC)",
+          "url": "https://www.rfc-editor.org/rfc/rfc2104.html"
+        },
+        {
+          "label": "RFC 6234 (US Secure Hash Algorithms — SHA-256)",
+          "url": "https://www.rfc-editor.org/rfc/rfc6234.html"
+        },
+        {
+          "label": "Stripe webhook signature spec",
+          "url": "https://docs.stripe.com/webhooks/signature"
+        },
+        {
+          "label": "Paddle webhook signature verification",
+          "url": "https://developer.paddle.com/webhooks/signature-verification"
+        },
+        {
+          "label": "Shopify webhooks — HMAC verification",
+          "url": "https://shopify.dev/docs/apps/webhooks/configuration/https"
+        },
+        {
+          "label": "ISO 4217 (Currency codes + minor unit catalog)",
+          "url": "https://www.iso.org/iso-4217-currency-codes.html"
+        },
+        {
+          "label": "IEEE 754 (the float-precision problem `b.money` avoids)",
+          "url": "https://standards.ieee.org/standard/754-2019.html"
+        },
+        {
+          "label": "Cloudflare Turnstile — server-side validation",
+          "url": "https://developers.cloudflare.com/turnstile/get-started/server-side-validation/"
+        },
+        {
+          "label": "hCaptcha — verify the user response server-side",
+          "url": "https://docs.hcaptcha.com/"
+        },
+        {
+          "label": "reCAPTCHA-v3 — server-side verification",
+          "url": "https://developers.google.com/recaptcha/docs/v3"
+        },
+        {
+          "label": "OWASP ASVS v5 §11.5 — bot defense controls",
+          "url": "https://owasp.org/www-project-application-security-verification-standard/"
+        },
+        {
+          "label": "RFC 9051 (IMAP4rev2 — SEARCH semantics)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9051.html"
+        },
+        {
+          "label": "RFC 8621 (JMAP Mail — Email/query)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html"
+        },
+        {
+          "label": "SQLite FTS5",
+          "url": "https://www.sqlite.org/fts5.html"
+        },
+        {
+          "label": "UML State Machine (OMG UML 2.5.1 §14)",
+          "url": "https://www.omg.org/spec/UML/2.5.1"
+        }
+      ]
+    },
+    {
+      "version": "0.11.24",
+      "date": "2026-05-20",
+      "headline": "`b.mail.send.deliver` — turnkey outbound SMTP composer (MX → MTA-STS → DANE → REQUIRETLS → DSN)",
+      "summary": "One factory wires together the full outbound mail chain. The operator hands the primitive an envelope (`{ from, to, rfc822 }`) and gets back per-recipient outcomes: `delivered`, `deferred` (with retry budget), or `failed` (with the corresponding RFC 3464 DSN already composed and the configured DSN sink invoked). Per-recipient handling is independent — one recipient permanently failing does not interfere with another's delivery or retry. MX records are resolved live (operator may inject a resolver for testing), MTA-STS policy (RFC 8461) is fetched + matched against the resolved MX before TLS, DANE TLSA records (RFC 7672) are consulted when present, REQUIRETLS (RFC 8689) is honored, and the per-host SMTP transport is the framework's `b.mail.smtpTransport`. SMTP outcomes are classified deterministically: hard 5xx + null-MX → permanent (with DSN); soft 4xx + DNS / connect / TLS errors → transient (with backoff budget). Recipient cap (1000 per call) and per-host / per-lookup timeout caps are baked in.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.mail.send.deliver.create(opts) → async deliver(envelope)` — composed outbound delivery",
+              "body": "Factory returns a `deliver(envelope)` async function. `envelope = { from, to[], rfc822 }`. Returns `{ delivered: [{...}], deferred: [{...}], failed: [{...}] }`. Composes `b.network.smtp.policy.mtaSts.fetch` + `.matchMx`, `b.network.smtp.policy.dane.tlsa` + `.verifyChain`, `b.mail.smtpTransport.create`, and `b.audit.safeEmit`. Required opts: `hostname` (EHLO + MAIL FROM identity). Optional: `resolver` (object exposing `resolveMx` / `resolve` — defaults to node:dns/promises); `policy.mtaSts.enabled` (default true); `policy.dane.enabled` (default true); `retry.maxAttempts` (default 5); `retry.backoffMs` (default exponential 60s/5m/30m/2h/12h); `dsn.from` + `dsn.onPermanentFailure(messageBuffer, ctx)` (required only when DSN delivery is desired); `timeouts.mxLookupMs` (default 5s); `timeouts.perHostMs` (default 60s); `transportFactory` (test-injection override)."
+            },
+            {
+              "title": "Per-recipient outcome classifier (`_classifySmtpOutcome`)",
+              "body": "Maps SMTP reply codes + Node socket / TLS errors onto the `permanent` / `transient` axis. Permanent: SMTP 5xx (any subclass), null-MX RFC 7505 sentinel `.`, no-MX-records, RFC 5321 §3.6.2 unrouteable. Transient: SMTP 4xx (any subclass), TCP connection refused / reset / timeout, TLS handshake failure (when MTA-STS / DANE is not enforce-mode), DNS NXDOMAIN at lookup time. Once `retry.maxAttempts` is exhausted, transient is escalated to permanent with reason `retry exhausted (after N attempts)`."
+            },
+            {
+              "title": "RFC 3464 DSN composer (`_buildDsnMessage`)",
+              "body": "Builds a `multipart/report; report-type=delivery-status` message with three parts: human-readable explanation, `message/delivery-status` block (Reporting-MTA, Original-Recipient, Final-Recipient, Action: failed, Status: 5.x.x), and a `message/rfc822-headers` block carrying the failed message's headers. Boundary token is generated via `b.crypto.generateToken(12)` so it can't collide with attacker-chosen header / body bytes. The composed DSN is passed to the operator-supplied `dsn.onPermanentFailure(message, ctx)` sink — the primitive does not itself send the DSN, keeping the operator in control of which transport carries DSNs (typically the same submission service)."
+            },
+            {
+              "title": "MX failover + per-host audit",
+              "body": "MX records are walked in priority order. A failed connect / TLS / 4xx on the first host falls over to the next; only when every MX has been tried does the recipient receive its final outcome. Each per-host failure emits a structured audit event (`mail.send.deliver.host-fail` with `recipient` + `mxHost` + `priority` + `reason`); the final outcome emits `mail.send.deliver.delivered` / `.deferred` / `.permanent-fail`. Audit is drop-silent on the hot path (catch + ignore)."
+            },
+            {
+              "title": "Recipient + envelope hard caps",
+              "body": "`MAX_RECIPIENTS_PER_CALL = 1000` refuses oversized fan-out at the factory boundary (5xx-style DoS prevention). `envelope.rfc822` accepts a Buffer or UTF-8 string — strings are converted at the boundary so downstream byte-level reasoning (DKIM, REQUIRETLS, length headers) sees stable bytes. Bad-envelope refusals carry `DeliverError` codes `deliver/bad-envelope`, `/bad-envelope-from`, `/bad-envelope-to`, `/too-many-recipients`, `/bad-envelope-rfc822` — operators get structured surface for each refusal class."
+            }
+          ]
+        },
+        {
+          "heading": "Security",
+          "items": [
+            {
+              "title": "MTA-STS enforcement before TLS handshake (RFC 8461)",
+              "body": "When `policy.mtaSts.enabled` (default), MTA-STS policy is fetched for the recipient domain. If the policy mode is `enforce` and a resolved MX hostname does not match an `mx:` entry, the host is refused without attempting TLS. This closes the MX-substitution attack window (`b.mail.send.deliver` cannot be diverted to an attacker-controlled MX even when DNS is hijacked, as long as the recipient publishes MTA-STS)."
+            },
+            {
+              "title": "DANE TLSA verification when present (RFC 7672)",
+              "body": "When `policy.dane.enabled` (default) and the recipient domain publishes TLSA records, the SMTP transport's TLS certificate chain is verified against the TLSA hash before the SMTP command pipeline starts. TLSA records take precedence over PKIX trust roots for SMTP — RFC 7672 §2.2."
+            },
+            {
+              "title": "Boundary token unguessable (DSN boundary-injection defense)",
+              "body": "MIME boundary token in composed DSNs is 12 random bytes hex-encoded via `b.crypto.generateToken` (SHAKE256 over OS-RNG) — not `Date.now()` + `Math.random()`. The boundary appears verbatim in the message; a predictable boundary would let an attacker who controls the failed message's headers craft byte sequences that close the boundary early + inject MIME parts."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`per-recipient-loop-fallthrough-to-failed` (codebase-patterns)",
+              "body": "A new detector flags per-recipient delivery loops where the `delivered` branch does not exit the iteration before falling into the permanent-failure / DSN-emit path. Encodes the bug class that was caught during this slice's bring-up — a recipient delivering successfully also being added to `failed[]` because the `if (delivered)` branch lacked an explicit `continue`."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5321 (Simple Mail Transfer Protocol)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5321.html"
+        },
+        {
+          "label": "RFC 3464 (Extensible Message Format for Delivery Status Notifications)",
+          "url": "https://www.rfc-editor.org/rfc/rfc3464.html"
+        },
+        {
+          "label": "RFC 7505 (Null MX no-service resource record)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7505.html"
+        },
+        {
+          "label": "RFC 8461 (SMTP MTA Strict Transport Security — MTA-STS)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8461.html"
+        },
+        {
+          "label": "RFC 7672 (SMTP Security via Opportunistic DANE TLS)",
+          "url": "https://www.rfc-editor.org/rfc/rfc7672.html"
+        },
+        {
+          "label": "RFC 8689 (SMTP REQUIRETLS option)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8689.html"
+        },
+        {
+          "label": "RFC 3463 (Enhanced Mail System Status Codes)",
+          "url": "https://www.rfc-editor.org/rfc/rfc3463.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.23",
+      "date": "2026-05-20",
+      "headline": "`b.mail.agent.expunge` — hard EXPUNGE with legal-hold + retention-floor refusal gates",
+      "summary": "Operators (and the future IMAP EXPUNGE + JMAP Email/set destroyed wire-protocol adapters) get a single canonical path for permanent message removal that refuses to delete anything currently under legal hold or still inside the regulator-mandated retention window. The gate runs per-message; refused ids carry an explicit reason (`legal-hold` / `retention-floor` / `not-in-folder`) plus the floor + age + posture metadata that drove the refusal — wire adapters mirror those reasons to operators verbatim. The destructive SQL runs only on the surviving id set, inside a backend transaction that also bumps folder modseq + decrements quota atomically.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.mail.agent.expunge({ actor, folder, objectIds })` — hard EXPUNGE primitive",
+              "body": "Composes two refusal gates before the destructive SQL runs. (1) Legal-hold gate: any message whose `legal_hold` flag is set refuses with reason `legal-hold`. The mail-store layer surfaces the flag in per-row metadata; this layer maps it to the operator-facing refusal. (2) Retention-floor gate: under a configured compliance posture (`hipaa` / `pci-dss` / `gdpr` / `soc2`), the regulator-mandated minimum retention TTL is read from `b.retention.COMPLIANCE_RETENTION_FLOOR_MS[posture]` and any message whose age (`now - receivedAt`) is below the floor refuses with reason `retention-floor` plus `floorMs` + `ageMs` + `posture` metadata. Returns `{ deleted: <ids>, refused: [{ id, reason, ... }] }`. Audit event `mail.agent.expunge.success` carries the requested / deleted / refused counts and a reason histogram so dashboards can spot abnormal refusal patterns without parsing per-id detail."
+            },
+            {
+              "title": "`b.mailStore.create(...).hardExpunge(folder, objectIds)` — destructive SQL primitive",
+              "body": "Removes messages permanently from a folder inside a single backend transaction: deletes the message row + its flag rows, bumps the folder modseq, decrements the per-folder quota by the freed bytes / count. Returns `{ rows, deleted, refused }` where `refused` carries `{ id, reason: 'legal-hold' | 'not-in-folder' }` for each id the SQL gate refused (legal-hold is mirrored from the column; not-in-folder catches stale ids). The agent layer (`b.mail.agent.expunge`) is responsible for the retention-floor gate; this primitive is the wire-protocol-shaped backend surface."
+            },
+            {
+              "title": "`b.mailStore.create(...).fetchByObjectId` returns `legalHold: boolean`",
+              "body": "Pre-existing fetch path now consistently exposes the legal-hold flag in its return shape. Previously the field existed in the returned object via a separate path; this commit consolidates the duplicate exports into a single canonical `legalHold` boolean derived from the SQLite `legal_hold` INTEGER column."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 9051 (IMAP4rev2 — EXPUNGE semantics, §6.4.3)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9051.html"
+        },
+        {
+          "label": "RFC 8621 (JMAP Mail — Email/set destroyed)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8621.html"
+        },
+        {
+          "label": "45 CFR §164.316 (HIPAA — retention of records)",
+          "url": "https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C/section-164.316"
+        },
+        {
+          "label": "PCI-DSS v4.0.1 §3.5.1.1 (retention of cardholder data)",
+          "url": "https://www.pcisecuritystandards.org/document_library"
+        },
+        {
+          "label": "GDPR Art. 17 (right to erasure — operator-side accountability)",
+          "url": "https://gdpr-info.eu/art-17-gdpr/"
+        }
+      ]
+    },
+    {
+      "version": "0.11.22",
+      "date": "2026-05-20",
+      "headline": "`b.cert.create` — turnkey TLS-certificate manager composing ACME + sealed persistence + renewal scheduler + SNI + key escrow",
+      "summary": "Operators wiring TLS no longer have to glue ACME + key generation + cert persistence + renewal scheduling + SNI dispatch + escrow by hand. `b.cert.create({ storage, acme, certs, renew, ocsp, audit, compliance })` accepts a declarative manifest of certificates plus the operator's choice of ACME challenge solver, and the manager owns the rest of the lifecycle: ACME RFC 8555 order + RFC 9773 ARI-aware renewal, leaf key rotation on renew, OCSP refresh scheduling, sealed-disk persistence via `b.vault.seal`, optional break-glass key escrow encrypted to an operator-supplied recipient via `b.crypto.encryptEnvelope`, and SNI dispatch for `https.createServer({ SNICallback })`. Composes existing primitives — `b.acme.create` (extended this release with per-challenge methods), `b.vault.seal`, `b.safeAsync.repeating`, `b.network.tls`, `b.audit` — so the operator-facing surface is one factory call.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.cert.create(opts)` — turnkey certificate manager",
+              "body": "New top-level primitive. Storage backend: `sealed-disk` (default; sealed via `b.vault.seal`). ACME: directory URL + contact + auto-generated account key (sealed on disk; operator can override with explicit key material). Certs manifest: per-cert name + domains + keyAlg (ecdsa-p256 / ecdsa-p384 / rsa-2048 / rsa-3072 / rsa-4096) + challenge `{ type, provision, cleanup }` callbacks (http-01 / dns-01 / tls-alpn-01). Renewal: ARI-respecting scheduler with configurable `intervalMs` + `minDaysBeforeExpiry` thresholds. OCSP: `stapling: true` schedules periodic OCSP refresh via `b.network.tls.ocsp`. Key escrow: optional `keyEscrow: { recipient }` encrypts each renewed private key to the recipient public key via `b.crypto.encryptEnvelope` and persists alongside the sealed key — break-glass-only recovery path, NOT routine access. Surface: `start()` / `stop()` / `getContext(name)` / `sniCallback` / `refresh(name)` / event-emitter `on('cert.issued' | 'cert.renewed' | 'cert.renew-failed', handler)`."
+            },
+            {
+              "title": "`b.acme.create.fetchAuthorization(authUrl)` — RFC 8555 §7.5 authorization GET",
+              "body": "POST-as-GET an authorization URL; returns the parsed authorization object with the challenge array. The challenge entries carry `{ type, url, token, status }` for each offered challenge type. Required by the cert manager's per-challenge flow but useful to operators implementing custom ACME wrappers."
+            },
+            {
+              "title": "`b.acme.create.notifyChallengeReady(challengeUrl)` — RFC 8555 §7.5.1 ready-notification",
+              "body": "POST an empty JSON object to a challenge URL to signal the operator has provisioned the response. Returns the updated challenge object; the CA's validation runs asynchronously and the operator polls via `waitForAuthorization` afterwards."
+            },
+            {
+              "title": "`b.acme.create.waitForAuthorization(authUrl, opts?)` — authorization status polling",
+              "body": "Polls an authorization until `status === 'valid'` (success) or `status === 'invalid'` (CA refused). Honors the client's `pollIntervalMs` + `pollMaxMs` defaults; per-call `opts.intervalMs` + `opts.timeoutMs` override available. Throws typed `acme/auth-invalid` on CA refusal and `acme/auth-timeout` on poll-budget exhaustion."
+            },
+            {
+              "title": "`b.acme.create.buildCsr({ privateKey, publicKey, domains })` — RFC 2986 PKCS#10 CSR builder",
+              "body": "Builds a CertificationRequest signed with the leaf private key. Subject `CN=<first domain>`, all domains as `dNSName` entries in the SubjectAltName extension. Supports ECDSA P-256 (signed sha256), ECDSA P-384 (signed sha384), RSA 2048 / 3072 / 4096 (signed sha256). Ed25519 is rejected at the CSR layer because CA support is uneven — operators wanting Ed25519 certs build the CSR externally. PEM-encoded output ready to feed to `finalize(order, csrPem)`."
+            },
+            {
+              "title": "`b.asn1Der` write primitives — `writeBitString` / `writeSet` / `writeUtf8String` / `writePrintableString` / `writeIa5String` / `writeBoolean` / `writeContextImplicit`",
+              "body": "ASN.1 DER encoder extensions needed for PKCS#10 CSR construction. PrintableString refuses input outside the RFC 5280 character set; IA5String refuses non-ASCII; UTF8String refuses non-string input. SET-OF encoding sorts children by their encoded bytes per DER. Internal-only today (consumed by `b.acme.create.buildCsr`); operators with their own ASN.1 needs can compose them."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`b.audit.FRAMEWORK_NAMESPACES` adds `cert`",
+              "body": "The cert-manager lifecycle emits `cert.account.generated` / `cert.issued` / `cert.renewed` / `cert.renew-failed` / `cert.challenge-cleanup` audit events; the audit-namespace coverage check at smoke-time now recognizes the `cert` namespace."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 8555 (ACME)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8555.html"
+        },
+        {
+          "label": "RFC 9773 (ACME Renewal Information / ARI)",
+          "url": "https://www.rfc-editor.org/rfc/rfc9773.html"
+        },
+        {
+          "label": "RFC 2986 (PKCS#10 Certification Request Syntax)",
+          "url": "https://www.rfc-editor.org/rfc/rfc2986.html"
+        },
+        {
+          "label": "RFC 5280 (X.509 Internet PKI)",
+          "url": "https://www.rfc-editor.org/rfc/rfc5280.html"
+        },
+        {
+          "label": "RFC 8737 (TLS-ALPN-01 challenge)",
+          "url": "https://www.rfc-editor.org/rfc/rfc8737.html"
+        },
+        {
+          "label": "OpenSSL CSR roundtrip — local OpenSSL validation",
+          "url": "https://www.openssl.org/docs/man3.5/man1/openssl-req.html"
+        }
+      ]
+    },
+    {
+      "version": "0.11.21",
+      "date": "2026-05-20",
+      "headline": "Supply-chain hardening — pinact + zizmor + actionlint gate, sha-to-tag tag-integrity verifier, GOVERNANCE.md",
+      "summary": "Closes the input + tag-integrity halves of the supply-chain trust boundary. `pinact` refuses any `uses:` reference that isn't pinned to a 40-char SHA with a verified version-comment (defense against the CVE-2025-30066 retroactive-tag-rewrite class). `zizmor` audits every workflow for the documented security anti-pattern catalog (template-injection / excessive-permissions / cache-poisoning / impostor-commit / unredacted-secrets / etc.). The new `sha-to-tag-verify` workflow refuses to let the publish workflow proceed if a release tag's commit SHA isn't on `main`'s first-parent history OR wasn't the result of a merged PR — the source-side gate that TanStack's 2026-05-11 attack (84 malicious `@tanstack/*` versions published with valid SLSA L3 provenance) demonstrated as a structural defense alongside provenance verification. SECURITY.md gains operator-facing `slsa-verifier` and tag-SHA-integrity recipes. New top-level `GOVERNANCE.md` documents the solo-maintainer governance model, succession plan, key-loss recovery, and dependent-notification protocol.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`.github/workflows/actions-lint.yml` — pinact + zizmor + actionlint gate",
+              "body": "Three tools, three layers per the arxiv.org \"Unpacking Security Scanners for GitHub Actions Workflows\" taxonomy. `pinact run --check` refuses any `uses:` reference that isn't SHA-pinned with a matching version-comment; `pinact run --verify` re-resolves each pinned SHA's registered tag at check time and refuses if the workflow's version-comment disagrees (catches retroactive tag rewrites). `zizmor` audits at `--min-severity low` across every documented rule class (template-injection, excessive-permissions, dangerous-triggers, unpinned-uses, cache-poisoning, github-env, hardcoded-container-credentials, impostor-commit, known-vulnerable-actions, obfuscation, ref-confusion, secrets-inherit, self-hosted-runner, unredacted-secrets, unsound-contains, use-trusted-publishing); SARIF emitted to GitHub Code Scanning. `actionlint` runs YAML + expression validation + shellcheck on every `run:` block. Single documented exception in `.pinact.yaml` — the SLSA reusable workflow MUST be tag-pinned because its internal builder-fetch step refuses non-tag refs."
+            },
+            {
+              "title": "`.github/workflows/sha-to-tag-verify.yml` — tag-SHA integrity gate",
+              "body": "Runs on every `v*` tag push and refuses to let the publish workflow start if the tag's commit SHA isn't on `main`'s first-parent history OR wasn't the result of a merged PR. Defends against the tag-mutation class (CVE-2025-30066: 23,000+ affected repos in March 2025) and the source-side-malicious-publish class (TanStack 2026-05-11: 84 valid-SLSA-L3-provenance malicious versions). The same chain is documented for operator-side re-verification in SECURITY.md's new \"Verifying release-commit integrity\" subsection."
+            },
+            {
+              "title": "`GOVERNANCE.md` — solo-maintainer governance, succession, key-loss recovery, dependent-notification",
+              "body": "New top-level document covering: (a) current governance model (solo maintainer pre-1.0, maintainer-final on technical direction); (b) succession plan with TBD-successor-with-documented-re-open-trigger, repository ownership, npm publish credentials, SSH signing key rotation procedure, Sigstore identity rotation; (c) key-loss recovery for every asset (npm publish, GitHub org, SSH signing key, Sigstore, domain); (d) dependent-notification protocol via `security@blamejs.com` with 30-day no-activity escalation. Bus-factor-1 is the largest non-technical risk pre-1.0; this document makes the recovery path defensible."
+            },
+            {
+              "title": "SECURITY.md — `slsa-verifier` and tag-SHA-integrity operator-verification recipes",
+              "body": "\"Verifying release authenticity\" gains a `slsa-verifier verify-artifact` recipe (pinned to v2.7.1) for offline / API-independent provenance verification — `gh attestation verify` walks the chain via the GitHub API; `slsa-verifier` does it from disk. The recipe explicitly states the limit: SLSA provenance binds the tarball bytes to a workflow+commit+tag, but does NOT prove the source is clean (the TanStack incident shipped valid-provenance malicious versions because the source side was compromised). A new \"Verifying release-commit integrity\" subsection documents the sha-to-tag chain operators run alongside provenance verification — the source-side gate."
+            },
+            {
+              "title": "`.pinact.yaml` — pinact configuration with documented SLSA exception",
+              "body": "Defines a single tag-pin exception for `slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml`. The SLSA reusable workflow's internal builder-fetch step refuses non-tag `BUILDER_REF` values, so the call MUST be tag-pinned; mitigated by slsa-framework's upstream tag-protection + immutable-release rules. The same exception also appears as a per-line `# allow:slsa-framework-action-not-sha-pinned` marker in `npm-publish.yml` for the framework's own codebase-patterns gate."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Workflow version-comment integrity — every pinned action's `# vX.Y.Z` comment now matches the registered tag for that SHA",
+              "body": "Pre-existing pins carried stale version-comments (`actions/checkout@de0fac2e... # v6.0.0` where that SHA is actually `v6.0.2`, `actions/setup-node@48b55a01... # v6.0.0` where the SHA is `v6.4.0`, `actions/download-artifact@3e5f45b2... # v7.0.1` where the SHA is `v8.0.1`, `github/codeql-action@9e0d7b8d... # v3.30.9` where the SHA is `v4.35.5`). The SHAs themselves stay (they're the actual-released versions); the comments now match. This is what pinact's `--verify` check enforces structurally going forward — a stale version-comment is the early-warning signal that a retroactive tag rewrite landed without operator notice."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "CVE-2025-30066 (tj-actions/changed-files retroactive tag rewrite)",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-30066"
+        },
+        {
+          "label": "TanStack npm publish incident 2025-05-11",
+          "url": "https://blog.tanstack.com/the-tanstack-may-2025-supply-chain-attack/"
+        },
+        {
+          "label": "pinact",
+          "url": "https://github.com/suzuki-shunsuke/pinact"
+        },
+        {
+          "label": "zizmor",
+          "url": "https://github.com/woodruffw/zizmor"
+        },
+        {
+          "label": "actionlint",
+          "url": "https://github.com/rhysd/actionlint"
+        },
+        {
+          "label": "slsa-verifier",
+          "url": "https://github.com/slsa-framework/slsa-verifier"
+        }
+      ]
+    },
+    {
+      "version": "0.11.20",
+      "date": "2026-05-20",
+      "headline": "`b.backup.localStorage` legacy alias removed + test-discipline backlog fully drained",
+      "summary": "Two pieces bundled into one patch. (1) The `b.backup.localStorage` legacy alias introduced in v0.11.2 as a deprecation cycle for the rename to `b.backup.diskStorage` is removed entirely — pre-v1 the project's stated policy is no backwards-compat shims, and the cleanup no longer needs to wait for the Node 26 floor-bump. (2) Every test file in the `test-promise-settimeout-sleep` detector's 49-file migration backlog is converted from `await new Promise(r => setTimeout(r, N))` sleeps to `helpers.waitUntil(predicate, opts)` (condition-waits) or the new `helpers.passiveObserve(ms, label)` (verify-absence-of-event windows). The previously-split `test-codebase-patterns.test.js` catalog is folded into the main `codebase-patterns.test.js` `KNOWN_ANTIPATTERNS` array with `scanScope: \"test\"`.",
+      "sections": [
+        {
+          "heading": "Removed",
+          "items": [
+            {
+              "title": "`b.backup.localStorage` — the legacy alias is gone",
+              "body": "The property no longer resolves on `b.backup` and the one-time deprecation warning is no longer emitted. Migration is a literal-name find-and-replace: `b.backup.localStorage({ root: ... })` becomes `b.backup.diskStorage({ root: ... })`. The returned storage backend object, its options shape, and its wire contract with `b.backupBundle.create` are unchanged. See SECURITY.md's Node 26 compatibility section for the original rename rationale."
+            }
+          ]
+        },
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`helpers.passiveObserve(ms, label)` — real-time observation budget",
+              "body": "Distinct from `helpers.waitUntil`: the goal is NOT to poll until a condition is truthy, but to let real time elapse so the test can verify ABSENCE of an event over a window. Required `label` (string) surfaces in audit logs / future flake diagnostics so a grep through a CI log immediately identifies which observation budget was consumed. Throws TypeError on non-positive `ms` or missing label. Use sparingly — if there IS an observable predicate, `waitUntil` is the right primitive (faster on fast platforms; passive observation always burns the full budget)."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Test-discipline catalog unified — `codebase-patterns.test.js` is now the single source of truth",
+              "body": "The previously-split `test-codebase-patterns.test.js` runner is merged into the main `codebase-patterns.test.js` catalog. Six test-side detectors are now inline `KNOWN_ANTIPATTERNS` entries with `scanScope: \"test\"`: `test-promise-settimeout-sleep` (broadened regex catches block-bodied arrows + multi-arg arrows + function bodies with leading statements), `test-uses-stream-pipeline-without-withtesttimeout` (per-test wall-clock ceiling for node:stream.pipeline tests), `release-named-test-file` (basename-mode; refuses `v0-8-41-additions.test.js` / `slot-19-enhancements.test.js` / `batch-N.test.js`), `test-hardcoded-server-bind-port` (`.listen(0)` + `server.address().port`), `test-fs-watch-direct-call` (`helpers.backdateFile` + `helpers.waitForWatcher` instead), `test-future-utimes-without-backdated-baseline` (pair future-mtime writes with `backdateFile`), `test-creates-db-handle-without-isolation` (`b.db.create()` must compose `setupTestDb` / `setupVaultOnly` / `mkdtempSync`). The test-scope walker now also includes `examples/*/test/` so wiki integration tests share the same discipline. Single catalog means a single allowlist per detector, single migration backlog, and one runner to invoke from CI."
+            },
+            {
+              "title": "Test-discipline migration — `setTimeout(r, N)` backlog fully drained (49 → 0 migration entries)",
+              "body": "Converted every test file in the migration backlog to `helpers.waitUntil` / `helpers.passiveObserve`: `a2a`, `a2a-tasks`, `agent-event-bus`, `agent-idempotency`, `agent-orchestrator`, `agent-snapshot`, `api-encrypt`, `app-shutdown`, `audit-segregation`, `break-glass`, `config`, `cors`, `daily-byte-quota`, `dsr`, `external-db-routing`, `guard-csv`, `http-client-cache`, `log-stream-cloudwatch`, `log-stream-otlp` (dead `_sleep` helper removed), `log-stream-otlp-grpc`, `mail-greylist`, `middleware-compose-pipeline`, `network`, `network-dns-resolver`, `network-heartbeat-passive`, `notify`, `observability-tracing`, `promise-pool`, `pubsub`, `queue-dlq-extend-lease`, `queue-flow-repeat`, `queue-priority-rate-progress`, `require-auth-cache-control`, `retry`, `safe-async-loops`, `safe-async-parallel`, `scim-server`, `sse`, `vault-seal-pem-file`, `watcher` (3 fs.watchFile poll-event waits), `webhook`, `websocket-channels`, `ws-client`, `api-key` (layer-1), and integration tests `cache`, `cluster-provider-mysql`, `log-stream`, `network-heartbeat`, `object-store-sigv4`, `pubsub`, `queue-redis`, `websocket-permessage-deflate`, `ws-client-roundtrip`. Each condition-wait now has a grep'able label and an automatic 5000ms ceiling. Two files are permanent structural FPs (not migration backlog): `test/helpers/services.js` (TCP/TLS/UDP probe primitives — race-with-socket-event pattern, not condition-wait) and `examples/wiki/test/integration.js` (consumes `@blamejs/core` via npm symlink, doesn't have access to the framework's internal test helpers; single 100ms post-shutdown flush window)."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "Node.js 26 release notes (localStorage global)",
+          "url": "https://nodejs.org/en/blog/release/v26.0.0"
+        }
+      ]
+    },
+    {
+      "version": "0.11.18",
+      "date": "2026-05-20",
+      "headline": "ML-DSA-65 release-signing key onboarded — `.mldsa.sig` sidecar lights up",
+      "summary": "v0.11.17 was the first release the new pipeline published end-to-end, but the `.mldsa.sig` PQC sidecar was missing because the operator-side `RELEASE_PQC_SIGNING_KEY` setup hadn't been done yet. v0.11.18 onboards the keypair: `keys/release-pqc-pub.json` is committed in-tree, the matching private key lives only in the `npm-publish` environment's `RELEASE_PQC_SIGNING_KEY` secret, and `SECURITY.md` documents the SHA3-512 fingerprint + the operator-side verification recipe (no external verifier binary required — verifies via the framework's own vendored noble-post-quantum primitive).",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`keys/release-pqc-pub.json` — ML-DSA-65 release-signing public key committed in-tree",
+              "body": "Generated locally via `node scripts/generate-release-signing-key.js`; the matching private key was set as the `RELEASE_PQC_SIGNING_KEY` secret in the `npm-publish` GitHub Actions environment (same scope as `NPM_TOKEN`). The publish workflow's PQC sidecar step now finds both pieces present and computes a `<tarball>.mldsa.sig` for every release tarball. Self-verify-before-write inside `sign-release-artifact.js` catches a stale env-secret-vs-in-tree-pubkey mismatch — refuses to write a non-verifiable sig."
+            },
+            {
+              "title": "`SECURITY.md` — `PQC release-signing key` fingerprint + verification recipe",
+              "body": "New SECURITY.md table records the algorithm (ML-DSA-65, FIPS 204), the in-tree public-key file path, and the SHA3-512 fingerprint (`ad6bee96…2ede`). Verification recipe uses the framework's own `b.pqcSoftware.ml_dsa_65.verify` — no external verifier binary required, no dependency on Sigstore's classical-crypto chain. Operators with a PQC-only verification posture have a self-contained path: `gh release download`, then `node -e` against the vendored noble-post-quantum primitive."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`Verifying release authenticity` — four trust roots, not three",
+              "body": "SECURITY.md's closing summary updated to count the ML-DSA-65 release-signing sidecar as the fourth independently-verifiable trust root, alongside SLSA L3 npm provenance + Sigstore-keyless SBOM signing + SSH-signed tags. Each remains verifiable without trusting any of the others; tampering with one is detected by the others."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "FIPS 204 — ML-DSA",
+          "url": "https://csrc.nist.gov/pubs/fips/204/final"
+        },
+        {
+          "label": "FIPS 202 — SHA-3 + SHAKE",
+          "url": "https://csrc.nist.gov/pubs/fips/202/final"
+        },
+        {
+          "label": "RFC 9909 — ML-DSA in X.509 + CMS",
+          "url": "https://www.rfc-editor.org/rfc/rfc9909.html"
+        },
+        {
+          "label": "noble-post-quantum (vendored under lib/vendor)",
+          "url": "https://github.com/paulmillr/noble-post-quantum"
+        }
+      ]
+    },
+    {
+      "version": "0.11.17",
+      "date": "2026-05-20",
+      "headline": "SLSA reusable workflow tag-pinned (the call requires a tag ref internally)",
+      "summary": "v0.11.7 through v0.11.16 each ship'd with the SLSA `generator_generic_slsa3` reusable workflow SHA-pinned and the publish workflow failed identically every time — masked by the SLSA workflow's cascading `continue-on-error: true` on each step until v0.11.16's diagnostic finally surfaced the real error: `Invalid ref: <40-hex>. Expected ref of the form refs/tags/vX.Y.Z`. The SLSA workflow's internal builder-fetch step refuses anything other than a tag ref for `BUILDER_REF`. Tag-pinned the callsite to `@v2.1.0`; updated the codebase-patterns `slsa-framework-action-not-sha-pinned` detector to allowlist this one callsite with the upstream-mitigation reasoning documented inline.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "SLSA reusable workflow callsite pinned to `@v2.1.0` (tag) instead of `@<sha>`",
+              "body": "The SLSA `generate-builder` action's builder-fetch step refuses non-tag refs for `BUILDER_REF` — the SHA we'd been pinning to since v0.11.7 was always failing here, hidden behind the SLSA workflow's step-level + workflow-level `continue-on-error: true` cascades. v0.11.16's diagnostic finally surfaced the actual error message. Switched to `@v2.1.0`. The repo-level `sha_pinning_required` actions policy was relaxed earlier so the tag pin is permitted. The `slsa-action-not-sha-pinned` codebase-patterns detector allowlists this one callsite — slsa-framework's tag-protection + immutable-release rules at their own org level mitigate the upstream-mutation risk the detector was originally guarding against."
+            },
+            {
+              "title": "`slsa-action-not-sha-pinned` detector allowlists the npm-publish workflow callsite",
+              "body": "The detector continues to enforce SHA-pinning on every OTHER `slsa-framework/*` reusable-workflow callout repository-wide. Only the npm-publish workflow's `provenance` job is allowlisted, with the upstream tag-protection mitigation documented at the allowlist entry. New callsites still trip the detector."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "SLSA `generate-builder` action — `Invalid ref` refusal",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/actions/generate-builder/action.yml"
+        },
+        {
+          "label": "slsa-framework `generator_generic_slsa3.yml` v2.1.0",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/workflows/generator_generic_slsa3.yml"
+        }
+      ]
+    },
+    {
+      "version": "0.11.16",
+      "date": "2026-05-20",
+      "headline": "SLSA generator `private-repository: true` to override the false-positive privacy halt",
+      "summary": "v0.11.15 cleared the SLSA outcome-AND chain via `continue-on-error: true`, then the underlying provenance generation FAILED with `Repository is private. The workflow has halted in order to keep the repository name from being exposed in the public transparency log. Set 'private-repository' to override.` — but `continue-on-error: true` masked it, the SLSA workflow reported success, no artifact was actually uploaded, and the downstream `publish-and-release` job's `Download SLSA provenance` step then failed. github.com/blamejs/blamejs is in fact public (gh api confirms `private: false, visibility: public`); SLSA's detection appears to walk workflow permissions rather than the repo's actual visibility. Passing `private-repository: true` overrides the detection and lets the workflow proceed to the Sigstore transparency-log write — which is the operator-desired behavior for a public-repo release.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`SECURITY.md` — `Supply-chain transparency posture` subsection",
+              "body": "New SECURITY.md subsection documenting the Sigstore Rekor transparency-log writes (SLSA L3 attestation + cosign SBOM signatures), the operator-side rationale for the `private-repository: true` override, and the fork-operator escape hatch (set the input to `false` to halt transparency-log writes for private mirrors). Also calls out the framework's no-telemetry posture: every external endpoint primitive (DoH / ACME / OCSP / NTP / OSV-Scanner) runs through operator-supplied infrastructure; there is no framework-owned ingest channel."
+            }
+          ]
+        },
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "Pass `private-repository: true` to the SLSA reusable workflow",
+              "body": "The SLSA generic generator halts when its internal privacy detection thinks the repo is private. github.com/blamejs/blamejs is public per gh api repos/blamejs/blamejs's `visibility: public`, but SLSA's detection halts anyway (likely walking workflow permissions). Setting `private-repository: true` acknowledges the operator-side decision to write the transparency log entry regardless of detection. v0.11.15 cleared the outcome-AND chain but the upstream attest step was failing for this reason — `continue-on-error: true` masked it, the artifact never uploaded, and the downstream download failed."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "SLSA generic generator inputs",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/workflows/generator_generic_slsa3.yml"
+        },
+        {
+          "label": "Sigstore Rekor transparency log",
+          "url": "https://docs.sigstore.dev/logging/overview/"
+        }
+      ]
+    },
+    {
+      "version": "0.11.15",
+      "date": "2026-05-20",
+      "headline": "SLSA reusable workflow `continue-on-error: true` so `upload-assets: false` doesn't fail the workflow",
+      "summary": "v0.11.14 finally reached the SLSA provenance generation step end-to-end — the `validate` and `generator` jobs both succeeded, the provenance artifact uploaded — but the SLSA workflow's `final` step exited 27 because its outcome-AND chain evaluates `needs.upload-assets.outputs.outcome != 'failure'` against an empty value (the `upload-assets` job's `if:` short-circuited via `upload-assets: false`). The empty value evaluates falsy in the AND chain, the SLSA workflow marks itself failed, and the dependent `publish-and-release` job skips. `continue-on-error: true` on the SLSA reusable workflow call tells it to report success regardless of the final-step outcome computation; the `publish-and-release` job's `Download SLSA provenance` step catches a real missing-artifact failure independently.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "Pass `continue-on-error: true` to the SLSA reusable workflow",
+              "body": "The SLSA `generator_generic_slsa3.yml` workflow has four nested jobs (`detect-env`, `generator`, `upload-assets`, `final`). When the caller passes `upload-assets: false`, the `upload-assets` job's `if:` short-circuits to skip — but its outputs evaluate empty, and the `final` job's outcome-AND chain treats that empty value as falsy, exits 27, and marks the entire SLSA workflow failed even though `generator` produced the provenance artifact successfully. `continue-on-error: true` is the documented escape hatch — the SLSA workflow now reports success when the underlying provenance generation succeeded regardless of the `final` step's strict-AND outcome computation. The `publish-and-release` job's `Download SLSA provenance` step is the real safety check — a missing artifact would surface there with an `actions/download-artifact` not-found error rather than being hidden behind the SLSA workflow's overly-strict `final` outcome."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "SLSA generic generator v2.1.0 `continue-on-error` input",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/blob/v2.1.0/.github/workflows/generator_generic_slsa3.yml"
+        }
+      ]
+    },
+    {
+      "version": "0.11.14",
+      "date": "2026-05-20",
+      "headline": "`helpers.backdateFile` + `helpers.waitForWatcher` — shared test primitives for `fs.watch` / `fs.watchFile`-driven tests",
+      "summary": "v0.11.13 inlined the backdate + widened-wait fix in `vault-seal-pem-file.test.js` directly; v0.11.14 lifts the discipline into `test/helpers/fs-watch.js` so every existing + future fs.watch-driven test composes it the same way. Two test-side codebase-patterns detectors enforce the composition: `test-fs-watch-direct-call` (no raw `fs.watch*` calls in tests) and `test-future-utimes-without-backdated-baseline` (future-mtime via fs.utimesSync MUST pair with a prior `helpers.backdateFile` call). The existing `watcher.test.js` migrates off three fixed-budget `setTimeout(r, N)` sleeps to `helpers.waitForWatcher(predicate)`.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`helpers.backdateFile(path, msAgo?)` — shift a file's mtime/atime into the past",
+              "body": "Use immediately before starting an fs.watchFile-based watcher so the watcher's first-poll baseline is unambiguously older than any subsequent mutation. Default backdate is one hour (`3_600_000` ms), which dwarfs any clock-skew or poll-cadence drift the runner might exhibit. Solves the recurring class of flakes where the watcher's first poll lands AFTER the test mutates the source — recording the post-mutation mtime as `prev` and never seeing the transition."
+            },
+            {
+              "title": "`helpers.waitForWatcher(predicate, opts?)` — polling wait helper for fs.watch / fs.watchFile observations",
+              "body": "Same predicate shape as `helpers.waitUntil` but widens the default timeout from 5s to 15s for fs.watch's known cross-platform event-delivery cadence drift (macOS FSEvents + Linux inotify both occasionally deliver 2-3s late under CI runner contention). Use `helpers.waitUntil` directly for tests that don't involve a filesystem watcher; the wider budget here is specifically for the fs-watch class."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`vault-seal-pem-file.test.js` migrates from inline backdate to `helpers.backdateFile`",
+              "body": "v0.11.13's inline fix is replaced with a single `backdateFile(src)` call. The local `_waitForGen` helper composes `helpers.waitForWatcher` with the watcher-generation predicate. Same behavior, but the discipline now lives at the helper instead of duplicated per-test."
+            },
+            {
+              "title": "`watcher.test.js` drops three fixed-budget `setTimeout(r, N)` sleeps for `helpers.waitForWatcher`",
+              "body": "The pre-write 200ms prime sleep, the 1500ms post-unlink sleep, and the 1500ms post-write sleep are all replaced with `helpers.waitForWatcher(predicate)` calls. Fast platforms (Linux/Windows) finish in milliseconds; macOS FSEvents under load gets the full 15s budget; the test no longer flakes on either end of the spectrum. The symlink-skip assertion uses a tight 2s window because it asserts the ABSENCE of an event, which requires a finite wait before checking."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`test-fs-watch-direct-call` (test-side catalog)",
+              "body": "Refuses direct `fs.watchFile(` or `fs.watch(` calls in test files. The framework exposes `b.watcher` (kernel-event-based) and `b.vault.sealPemFile` (poll-based) as the operator-facing watchers; tests of those primitives compose the helpers instead of re-deriving the fs.watch surface. Allowlists `test/helpers/fs-watch.js` (the helper itself documents the shape) and the catalog file (self-allowlist for the regex source)."
+            },
+            {
+              "title": "`test-future-utimes-without-backdated-baseline` (test-side catalog)",
+              "body": "Pairs the `fs.utimesSync(path, new Date(Date.now() + N), ...)` future-mtime idiom with a required companion `backdateFile(` call somewhere in the same file. Without the backdate, the watcher's first poll can record the future-mtime as `prev` and miss the transition. The `requires` companion-check passes the file when both shapes appear together; flags it as a violation when only the future-utimes is present."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "Node.js fs.watchFile docs",
+          "url": "https://nodejs.org/api/fs.html#fswatchfilefilename-options-listener"
+        },
+        {
+          "label": "Node.js fs.watch docs",
+          "url": "https://nodejs.org/api/fs.html#fswatchfilename-options-listener"
+        }
+      ]
+    },
+    {
+      "version": "0.11.13",
+      "date": "2026-05-20",
+      "headline": "`vault.sealPemFile` auto-reseal test now tolerant of contended runners",
+      "summary": "v0.11.12's smoke flaked on the publish workflow with `vault-seal-pem-file.test.js: FAIL: sealPemFile auto: gen incremented after source change`. Root cause: on contended `ubuntu-latest` CI runners, `fs.watchFile`'s initial poll could land AFTER the test's V2 + utimesSync calls, recording the post-change mtime as `prev` and missing the transition. Fix backdates V1's mtime by an hour before starting the watcher so any subsequent mtime change is detectable from any baseline the watcher might capture, and widens the wait budget from 5s to 15s for runner drift.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "`sealPemFile` auto-reseal test backdates V1 mtime + widens wait budget",
+              "body": "The test relied on writing V1, starting the watcher, then writing V2 with a future mtime — assuming the watcher's first poll would record V1's mtime as `prev`. On contended `ubuntu-latest` CI runners the first poll could land after both writes, recording the post-change mtime as `prev` and missing the transition. Backdating V1 by an hour via `fs.utimesSync` before watcher start makes the V2 mtime change unambiguous regardless of poll timing. The wait budget for the `gen >= 2` poll widens from 5s to 15s to absorb runner-cadence drift under load."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "Node.js fs.watchFile docs",
+          "url": "https://nodejs.org/api/fs.html#fswatchfilefilename-options-listener"
+        }
+      ]
+    },
+    {
+      "version": "0.11.12",
+      "date": "2026-05-19",
+      "headline": "SBOM step omits devDependencies so the zero-runtime-dep check stays accurate",
+      "summary": "v0.11.11's SBOM step wired in `npm sbom` correctly but didn't pass `--omit=dev`. The smoke gate installs `esbuild` + `postject` as devDependencies (needed for the bundler-output smoke check), and `npm sbom` reported them as components. The runtime-deps-greater-than-zero guard refused the publish with `SBOM lists 3 runtime dependency component(s)`. Adding `--omit=dev` to the `npm sbom` invocation gives the guard a clean view of just the runtime tree (which stays empty per the framework's zero-runtime-dep contract).",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "`npm sbom` invocation now passes `--omit=dev`",
+              "body": "The smoke gate's devDependency install step (esbuild + postject) showed up in the SBOM's `components` array because the npm-tree walk includes the installed devDependencies by default. `--omit=dev` filters them out so the runtime-deps guard sees the same zero-component view it's intended to enforce. The vendored SBOM (`sbom.vendored.cdx.json`) is unaffected — it's generated from `lib/vendor/MANIFEST.json`, never from the npm tree."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "npm sbom command",
+          "url": "https://docs.npmjs.com/cli/commands/npm-sbom"
+        }
+      ]
+    },
+    {
+      "version": "0.11.11",
+      "date": "2026-05-19",
+      "headline": "Release-workflow SBOM step calls the right script + cleanup script-path drift",
+      "summary": "v0.11.10 finally cleared the workflow-parse barrier (after the org allowlist gained `slsa-framework/slsa-github-generator/.github/{actions,workflows}/*` patterns and the SHA-pinning policy was relaxed to accept the SLSA reusable workflow's transitive `@v2.1.0` references), and then failed at the SBOM step because the workflow called `node scripts/generate-sbom.js` — a script that doesn't exist in the repo. The actual scripts are `npm sbom` (npm-tree CycloneDX, built into npm 10+) and `scripts/build-vendored-sbom.js` (the higher-value vendored-deps SBOM). v0.11.11 wires both into the workflow's SBOM step.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "Workflow SBOM step now calls the existing scripts",
+              "body": "Replaced the missing `node scripts/generate-sbom.js` invocation with `npm sbom --sbom-format=cyclonedx --sbom-type=application > sbom.cdx.json` (the npm-tree SBOM, built into npm 10+) plus `node scripts/build-vendored-sbom.js > sbom.vendored.cdx.json` (the vendored-deps SBOM that's been in `scripts/` all along). The runtime-deps-greater-than-zero guard still runs after both SBOMs are produced so the framework's zero-npm-deps contract stays enforced at publish time."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "CycloneDX SBOM 1.6 spec",
+          "url": "https://cyclonedx.org/specification/overview/"
+        },
+        {
+          "label": "npm sbom command",
+          "url": "https://docs.npmjs.com/cli/commands/npm-sbom"
+        }
+      ]
+    },
+    {
+      "version": "0.11.10",
+      "date": "2026-05-19",
+      "headline": "Release-workflow allowlist root cause + comment correction",
+      "summary": "v0.11.7, v0.11.8, and v0.11.9 each shipped with a hypothetical fix for the publish-workflow `startup_failure`, and each one failed for the same actual reason: the GitHub organization's actions allowlist did not include `slsa-framework/slsa-github-generator/*` (the SLSA L3 provenance reusable workflow) or `aquasecurity/setup-trivy/*` (a transitive of the `aquasecurity/trivy-action` we already allow). GitHub Actions surfaces this as `startup_failure` before any job runs, with no log file. Adding both patterns to the organization-level allowlist at https://github.com/organizations/blamejs/settings/actions is the operator-side prerequisite — the workflow file itself never had a parse-time defect.",
+      "sections": [
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`provenance` job comment rewritten to reflect the real root cause",
+              "body": "The earlier comment claimed GitHub Actions evaluates every called-workflow job's permissions at parse time (so `contents: read` would short-circuit even the skipped `upload-assets` job). That theory was wrong; the actual cause was the organization actions allowlist. The comment now points at the SLSA documented caller example as the authoritative reference and names the two allowlist patterns operators must add to the org settings. The `contents: write` permission stays in place — it matches the SLSA caller example default and future-proofs an `upload-assets: true` flip without a permissions-only patch."
+            }
+          ]
+        },
+        {
+          "heading": "Migration",
+          "items": [
+            {
+              "title": "Operator-side: add two patterns to the org actions allowlist",
+              "body": "Navigate to https://github.com/organizations/blamejs/settings/actions and add `slsa-framework/slsa-github-generator/*` AND `aquasecurity/setup-trivy/*` to the allowed-actions list. Both still SHA-pin at their call sites per the org policy. Without these, every release after v0.11.6 startup_failed at workflow parse with no log file. v0.11.7, v0.11.8, and v0.11.9 are tombstone tags — the git history records them but no GitHub Release pages exist and no npm registry entries shipped. v0.11.10 carries the same surface those tags would have shipped; `npm install @blamejs/core@latest` lands you on v0.11.10."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "GitHub Actions — managing allowed actions and reusable workflows",
+          "url": "https://docs.github.com/en/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization"
+        },
+        {
+          "label": "SLSA generic generator v2.1.0 caller example",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/tree/v2.1.0/internal/builders/generic"
+        }
+      ]
+    },
+    {
+      "version": "0.11.9",
+      "date": "2026-05-19",
+      "headline": "Release-workflow `contents: write` — actually fixes the startup_failure that blocked v0.11.7 and v0.11.8",
+      "summary": "v0.11.8 carried the wrong permission for the SLSA reusable workflow caller. GitHub Actions evaluates the entire reusable-workflow permission surface at workflow startup — including jobs that won't run because their `if:` short-circuits. The SLSA `upload-assets` job declares `permissions: contents: write`; `contents: read` in the caller failed the parse-time superset check before any job started, surfacing as `startup_failure` with no log file. Raising the caller to `contents: write` makes the caller's permission set a superset of every job the reusable workflow declares, regardless of which jobs end up running.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "Caller-level `contents: write` for the SLSA reusable workflow",
+              "body": "`.github/workflows/npm-publish.yml`'s `provenance` job now grants `contents: write` instead of `contents: read`. The change is parse-time-only — at runtime, `upload-assets: false` still skips the actual upload step, so the release-create flow remains the atomic-create-with-all-assets pattern v0.11.7 introduced. v0.11.7 and v0.11.8 are both `startup_failure` tags on the git history (no GH release, no npm publish); operators upgrading from `<= v0.11.6` should land directly on v0.11.9 — `npm install @blamejs/core@latest` lands you on v0.11.9."
+            }
+          ]
+        },
+        {
+          "heading": "Migration",
+          "items": [
+            {
+              "title": "v0.11.7 and v0.11.8 are tombstone tags",
+              "body": "The git tags for v0.11.7 and v0.11.8 exist in the repository but the publish workflow rejected at startup, so there are no corresponding GitHub Release pages and no npm registry entries. v0.11.9 carries everything those tags would have shipped: the workflow-driven release creation with SLSA L3 + Sigstore-keyless SBOM signatures + PQC sidecars (graceful-skip until the operator completes the one-time release-signing-key setup), the structured release-notes pipeline, and the CHANGELOG.md rebuild discipline."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "GitHub Actions — reusable-workflow permissions",
+          "url": "https://docs.github.com/en/actions/sharing-automations/reusing-workflows#supported-keywords-for-jobs-that-call-a-reusable-workflow"
+        },
+        {
+          "label": "SLSA generic generator v2.1.0 example caller",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/tree/v2.1.0/internal/builders/generic"
+        }
+      ]
+    },
+    {
+      "version": "0.11.8",
+      "date": "2026-05-19",
+      "headline": "Release-workflow startup-failure fix + graceful PQC sidecar skip + CHANGELOG.md becomes a derived artifact",
+      "summary": "The v0.11.7 npm-publish workflow rejected with `startup_failure` before any job ran because the `provenance` job's permissions block was a subset of what the called SLSA reusable workflow requires. The ML-DSA-65 sidecar step ALSO blocked when the operator hadn't yet generated the release-signing keypair. v0.11.8 fixes both — the workflow now passes parse-time validation, and the PQC sig step gracefully skips with a clear operator warning when the key/secret aren't set up yet. CHANGELOG.md is now generated end-to-end from `release-notes/*.json` (the single source of truth); the old hand-edit splice path is removed.",
+      "sections": [
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "`provenance` job carries the full permission superset the SLSA reusable workflow requires",
+              "body": "GitHub Actions refuses to start a workflow when the caller's job-level `permissions:` block is a subset of the called reusable workflow's job permissions, and the only diagnostic is `startup_failure` with no log file. The SLSA `generator_generic_slsa3.yml` workflow's `generator` job declares `id-token: write`, `contents: read`, `actions: read`; our `provenance` job declared the first and third but not `contents: read`. Added `contents: read` to the provenance job permissions."
+            },
+            {
+              "title": "PQC sidecar step skips gracefully when the release-signing key isn't yet set up",
+              "body": "The `RELEASE_PQC_SIGNING_KEY` environment secret and the committed `keys/release-pqc-pub.json` public-key file are an operator-side one-time setup. When either piece is missing, the workflow now logs a `::warning::` with the setup recipe and skips the ML-DSA-65 sig step; the release still ships with the SLSA L3 attestation, both Sigstore-keyless SBOM signatures, and the SHA-256 + SHA3-512 byte digests. The PQC sidecar lights up on the first release after the operator completes the setup."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Release-asset list built dynamically from per-step outputs",
+              "body": "The `gh release create` step builds its asset bundle from a bash array driven by the prior PQC-sig step's `outputs.available` flag. When PQC is skipped, the `.mldsa.sig` asset isn't referenced (otherwise `gh release create` would fail trying to attach a non-existent file)."
+            },
+            {
+              "title": "`CHANGELOG.md` is now a derived artifact rebuilt from `release-notes/*.json`",
+              "body": "`scripts/generate-changelog-entry.js` gains `--rebuild` (regenerate the whole `CHANGELOG.md` from the JSON tree) and `--check` (in-memory rebuild + diff against on-disk; non-mutating). The hand-edit `--write` / splice path is removed entirely — operators edit the JSON, run `--rebuild`, commit both. Smoke wires the `--check` gate so any release-notes change without a matching rebuild fails pre-push. The `version → new RegExp` data flow that CodeQL kept flagging is gone (the splice that needed it no longer exists), and so is the `existsSync → readFileSync` window the lookup used to traverse — the single rebuild path reads every JSON via `readFileSync` directly and lets `ENOENT` distinguish missing from malformed."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "GitHub Actions — permissions for reusable workflows",
+          "url": "https://docs.github.com/en/actions/sharing-automations/reusing-workflows#supported-keywords-for-jobs-that-call-a-reusable-workflow"
+        },
+        {
+          "label": "SLSA generic generator v2.1.0",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/releases/tag/v2.1.0"
+        }
+      ]
+    },
+    {
+      "version": "0.11.7",
+      "date": "2026-05-19",
+      "headline": "Workflow-driven release creation with SLSA L3 attestation + PQC sidecar signatures",
+      "summary": "The release pipeline now creates the GitHub release atomically with the full asset bundle attached at creation time — operators no longer run a manual `gh release create` step. Every release ships with SLSA L3 provenance (verifiable via `slsa-verifier`), Sigstore-keyless SBOM signatures, AND framework-native PQC sidecars: a SHA3-512 byte digest and an ML-DSA-65 signature over the tarball, verifiable with the framework's own vendored noble-post-quantum primitives.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "SLSA L3 provenance attached to every GitHub release",
+              "body": "The `npm-publish.yml` workflow now invokes `slsa-framework/slsa-github-generator` (pinned to a commit SHA) to produce a signed `*.intoto.jsonl` attestation describing the tarball + SBOM hashes, the workflow that built them, and the OIDC identity that signed them. The attestation is attached as a GitHub Release asset under the name `blamejs-X.Y.Z.intoto.jsonl`. Operators verify via `slsa-verifier verify-artifact <tarball> --provenance-path <jsonl> --source-uri github.com/blamejs/blamejs --source-tag vX.Y.Z`."
+            },
+            {
+              "title": "Byte-digest sidecars (SHA-256 + SHA3-512)",
+              "body": "Every release tarball ships with two checksum sidecars attached to the GitHub Release: `<tarball>.sha256` (the conventional `sha256sum`-compatible format operators expect — verify via `sha256sum -c`) and `<tarball>.sha3-512` (the framework's PQC-first hash, matching the audit chain and CMS-signing posture — verify via `openssl dgst -sha3-512`). Both digests cover the exact bytes the tarball ships."
+            },
+            {
+              "title": "PQC signature sidecar (ML-DSA-65)",
+              "body": "Every release tarball gets a `<tarball>.mldsa.sig` sidecar — an ML-DSA-65 signature over the tarball bytes, computed with the framework's vendored noble-post-quantum primitive. The signing key is stored as an environment secret in the `npm-publish` GitHub Actions environment; the matching public key is committed at `keys/release-pqc-pub.json` with a SHA3-512 fingerprint published in `SECURITY.md` for out-of-band verification. Operators with a PQC-only verification posture verify via the framework's own `b.pqcSoftware.ml_dsa_65.verify(sig, msg, pubKey)` — no dependency on Sigstore's classical-crypto chain. Three new helper scripts (`scripts/generate-release-signing-key.js` for one-time setup, `scripts/sign-release-artifact.js` for the workflow signer with self-verify-before-write defense, `scripts/sha3-digest.js` for the byte-digest sidecars) compose the existing `b.pqcSoftware` primitive."
+            },
+            {
+              "title": "Structured release-notes source",
+              "body": "Release notes are now generated from a structured JSON file at `release-notes/v<version>.json`. The generator (`scripts/generate-changelog-entry.js`) validates each field against an operator-facing-vocabulary check before emitting the `CHANGELOG.md` entry — internal-process narrative is refused at validation time so the discipline holds by construction. Operators edit the JSON, run the generator, commit both files."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Manual `gh release create` removed from the release workflow",
+              "body": "Operators previously ran `gh release create vX.Y.Z --notes \"...\"` after pushing the tag, then the workflow tried to attach assets via `gh release upload`. With the immutable-releases setting on, the upload would fail with HTTP 422 (the release locks at creation time, before the workflow finishes), so the framework's last 5 releases shipped with zero assets. The workflow now creates the release atomically with all assets attached at creation; the immutable-release setting stays on for the post-publish-swap protection it provides. Operators just push the tag and wait for the workflow."
+            },
+            {
+              "title": "Release notes extracted from CHANGELOG.md by the workflow",
+              "body": "The release-create step extracts the current version's CHANGELOG section using an awk script and passes it via `--notes-file`. Single source of truth — no separate heredoc duplicating the CHANGELOG content. The local static gate `scripts/check-changelog-extract.js` exercises the same extract pre-push so format drift fails fast."
+            }
+          ]
+        },
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "Code-comment references to an internal configuration file removed",
+              "body": "Source comments across `lib/`, `scripts/`, `.github/workflows/`, the codebase-patterns catalog, and historical `CHANGELOG.md` entries used to point at an internal maintainer-side configuration file. Operators reading those files saw pointers at an artifact they don't have. Every such reference is rewritten to carry the discipline inline (the comment describes what the rule says, not where to read it). A new codebase-patterns detector prevents re-introduction; its match pattern is constructed at runtime so the literal token strings don't appear in the catalog's prose either."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "slsa-framework-action-not-sha-pinned",
+              "body": "Catches any `slsa-framework/*` reusable workflow callout whose `@<ref>` is not exactly 40 hex characters. Tag-pinned references to the SLSA builder are mutable — the upstream maintainer can re-publish the tag — which silently rotates the builder root of trust. The new `scanScope: \"workflows\"` extends the codebase-patterns scanner to walk `.github/workflows/`."
+            },
+            {
+              "title": "internal-rulebook-vocabulary-in-source",
+              "body": "Catches the four leak shapes (the framework's internal config-file name plus three rule-shorthand variants) across `lib/`, `scripts/`, `test/`, and `.github/workflows/`. The catalog file allowlists itself since the runtime regex construction inevitably involves the patterns being detected."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "SLSA v1.0 spec",
+          "url": "https://slsa.dev/spec/v1.0/"
+        },
+        {
+          "label": "slsa-github-generator v2.1.0 release",
+          "url": "https://github.com/slsa-framework/slsa-github-generator/releases/tag/v2.1.0"
+        },
+        {
+          "label": "FIPS 204 ML-DSA",
+          "url": "https://csrc.nist.gov/pubs/fips/204/final"
+        },
+        {
+          "label": "RFC 9909 ML-DSA in X.509 / CMS",
+          "url": "https://www.rfc-editor.org/rfc/rfc9909.html"
+        },
+        {
+          "label": "NIST FIPS 202 SHA-3 / SHAKE",
+          "url": "https://csrc.nist.gov/pubs/fips/202/final"
+        },
+        {
+          "label": "OpenSSF Scorecard Signed-Releases check",
+          "url": "https://github.com/ossf/scorecard/blob/main/docs/checks.md#signed-releases"
+        }
+      ]
+    },
+    {
+      "version": "0.11.6",
+      "date": "2026-05-19",
+      "headline": "`b.safeMountInfo` — canonical `/proc/self/mountinfo` parser",
+      "summary": "New operator-facing primitive at `lib/safe-mount-info.js` that centralizes the field-4 parse discipline bind-mount detection requires. Existing inline parsers in `lib/watcher.js` are migrated; a new codebase-patterns detector blocks future direct reads of `/proc/self/mountinfo` outside the primitive.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.safeMountInfo.parse` / `read` / `bestMatch` / `isBindMount`",
+              "body": "The new primitive exposes `parse(text)` for line-oriented decoding, `read(opts)` for sandbox-safe filesystem access, `bestMatch(entries, path)` for longest-prefix selection, and `isBindMount(entry)` for the canonical bind-mount predicate. `isBindMount` consults field 4 (root within source FS) only — NOT the options string, which the kernel never emits as `bind` per Linux Documentation/filesystems/proc.rst §3.5. Ad-hoc parsers that scan options for the word `bind` miss every real bind-mount."
+            },
+            {
+              "title": "Typed refusal codes with audit emission",
+              "body": "Refusals surface as `safe-mount-info/read-failed` (non-Linux / restricted sandbox; returns `opts.fallback`, default `null`), `safe-mount-info/parse-failed` (single malformed line — silent-skip by default, `opts.strict: true` upgrades to throw), `safe-mount-info/too-many-lines` (line cap, default 4096), and `safe-mount-info/bad-input` (non-string / non-positive-integer arg). Every refusal emits `system.safe_mount_info.refused` drop-silent — hot-path observability sinks must not crash or stall the request that emitted them."
+            },
+            {
+              "title": "Fuzz harness at `fuzz/safe-mount-info.fuzz.js`",
+              "body": "Probes `parse` with adversarial bytes: malformed lines, oversize input, Unicode garbage, truncated headers. Catches any uncaught error class outside the documented refusal surface."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`lib/watcher.js` filesystem auto-probe routes through `b.safeMountInfo`",
+              "body": "The watcher's bind-mount detection now calls `b.safeMountInfo.read() + bestMatch() + isBindMount()` instead of parsing `/proc/self/mountinfo` inline. The single canonical parser means future container-escape detection, sealed-store path validation, and sandbox auto-probe call sites inherit the discipline automatically."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`mountinfo-not-via-safemountinfo`",
+              "body": "Flags direct `fs.readFileSync(\"/proc/self/mountinfo\", ...)` in `lib/` as a migration target. Only `lib/safe-mount-info.js` itself reaches the kernel surface; every other call site routes through the primitive."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "Linux Documentation/filesystems/proc.rst §3.5",
+          "url": "https://www.kernel.org/doc/Documentation/filesystems/proc.txt"
+        },
+        {
+          "label": "CVE-2024-21626 runc leaky-vessels",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-21626"
+        },
+        {
+          "label": "CVE-2022-0185 fsconfig",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-0185"
+        }
+      ]
+    },
+    {
+      "version": "0.11.5",
+      "date": "2026-05-19",
+      "headline": "`b.safeDecompress(buf, opts)` — bomb-resistant decompression primitive",
+      "summary": "New operator-facing primitive at `lib/safe-decompress.js` that centralizes bounded-output and bounded-ratio decompression defenses across the framework. `lib/websocket.js` permessage-deflate now routes through the primitive.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.safeDecompress(buf, opts)` with explicit algorithm allowlist",
+              "body": "Accepts `gzip` / `deflate` / `deflate-raw` (RFC 1951) / `brotli` under an explicit allowlist — unknown algorithms refuse with `safe-decompress/unsupported-algorithm`. Refuses bomb-class input via zlib's own `maxOutputLength` BEFORE allocation; AFTER decompression checks `output.length / input.length` against `maxRatio` (default 50:1) and overwrites + drops the buffer if the ratio is exceeded so operator-facing paths never see the bomb bytes. Pre-decompression input cap (`maxCompressedBytes`, default 4 MiB) defends against very-large compressed payloads whose zlib parse alone is expensive."
+            },
+            {
+              "title": "Typed refusal codes with audit emission",
+              "body": "Refusals surface as `safe-decompress/output-too-large`, `ratio-exceeded`, `decompress-failed`, `empty-input`, `oversized-input`, `unsupported-algorithm`, `bad-arg`, and `bad-input`. Operators wire `opts.audit` to receive the `system.safe_decompress.refused` event with `{ code, algorithm, ctx, reason }` metadata; emission is drop-silent — hot-path observability sinks must not crash or stall the request that emitted them."
+            },
+            {
+              "title": "Fuzz harness at `fuzz/safe-decompress.fuzz.js`",
+              "body": "Probes the four-algorithm allowlist with adversarial bytes (bomb / malformed / truncated / bogus dictionary) to catch any uncaught error class outside the documented refusal surface."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`lib/websocket.js` `_inflateMessage` routes through `b.safeDecompress`",
+              "body": "WebSocket per-message-deflate now calls `b.safeDecompress({ algorithm: \"deflate-raw\", maxRatio: 0, ... })`. WS already binds upstream via `maxMessageBytes` so the ratio cap is opt-out at this call site; future per-message-deflate sites adopt the same shape."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 1950 zlib",
+          "url": "https://www.rfc-editor.org/rfc/rfc1950"
+        },
+        {
+          "label": "RFC 1951 deflate",
+          "url": "https://www.rfc-editor.org/rfc/rfc1951"
+        },
+        {
+          "label": "RFC 1952 gzip",
+          "url": "https://www.rfc-editor.org/rfc/rfc1952"
+        },
+        {
+          "label": "RFC 7932 brotli",
+          "url": "https://www.rfc-editor.org/rfc/rfc7932"
+        },
+        {
+          "label": "CVE-2025-0725",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0725"
+        },
+        {
+          "label": "RFC 8460 §5.2 TLS-RPT decompression community guidance",
+          "url": "https://www.rfc-editor.org/rfc/rfc8460#section-5.2"
+        }
+      ]
+    },
+    {
+      "version": "0.11.4",
+      "date": "2026-05-19",
+      "headline": "`b.audit.useStore({ record })` shadow store + WebSocket permessage-deflate bomb fix + new detectors",
+      "summary": "Operators can now register a shadow audit store that receives a copy of every chain append after the framework's tamper-evident commit. The WebSocket inflate path gains a `maxOutputLength` cap. Five new codebase-patterns detectors and a token-aware shape-matcher land for future regex-bypass-resistant detectors.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.audit.useStore({ record })` shadow store registration",
+              "body": "Registers an operator-supplied shadow store that receives a copy of every audit chain append AFTER the framework's tamper-evident chain commits. The operator's `record(row)` async function receives the fully-formed row — `{ _id, recordedAt, monotonicCounter, prevHash, rowHash, action, outcome, actorUserId, ..., metadata }` — so external destinations (AWS QLDB / Azure Confidential Ledger / Google Cloud Audit Logs / in-house WORM appliances / SIEM forwarders) see identical hashes for cross-store reconciliation. Shadow failures are drop-silent — hot-path observability sinks must not crash or stall the request that emitted them — the framework chain is authoritative and already committed; an unreachable shadow surfaces via `b.observability` as the `audit.shadow_failed` event but never crashes the request path. Composes with HIPAA §164.312(b) / PCI-DSS Req 10.5.3 (separation-of-duties retention) / SOX §404 / SEC 17a-4 WORM postures. Pass `null` or `{ record: null }` to unregister."
+            },
+            {
+              "title": "Shape-matcher substrate at `test/helpers/_shape-match.js`",
+              "body": "Test-only token-aware traversal (never ships — `test/` is absent from package.json `files:` allowlist) that tracks paren / brace / bracket depth + string / template-literal / regex / comment state. Exposes `findCalls(source, calleeRegex)` / `findEnclosingTry(source, pos)` / `aliasesOf(source, chainRegex)`. Future releases convert the highest-bypass-risk regex-only detectors to AST-aware variants using this substrate, closing the class of regex-bypass via variable renaming / parens / line splits that surface-pattern detectors miss."
+            }
+          ]
+        },
+        {
+          "heading": "Fixed",
+          "items": [
+            {
+              "title": "WebSocket permessage-deflate decompression-bomb amplification",
+              "body": "`lib/websocket.js` `_inflateMessage` previously called `zlib.inflateRawSync` without `maxOutputLength` — a malicious peer could ship a small compressed frame that exploded into gigabytes BEFORE the framework's post-decompression `maxMessageBytes` check ran. The inflate now passes `maxOutputLength: this.maxMessageBytes` so zlib refuses mid-decompress; same amplification class the `gunzip-without-output-size-cap` detector defends elsewhere."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`test-promise-settimeout-sleep`",
+              "body": "Scans the `test/` tree — the first detector under the new test-scope walker — for the `await new Promise(r => setTimeout(r, N))` shape forbidden in tests. The framework's `helpers.waitUntil(predicate, opts?)` is the canonical replacement: polls the actual condition every 25ms up to a 5000ms cap, exiting early when truthy. Fast platforms finish in milliseconds; contended platforms get the full budget. The migration backlog is pre-allowlisted as a release-gate countdown."
+            },
+            {
+              "title": "`inflate-unzip-without-output-size-cap`",
+              "body": "Extends the v0.10.15 gunzip-cap detector to `zlib.inflateSync` / `inflateRawSync` / `unzipSync` / `createInflate` family. RFC 1951 deflate is the same bomb class."
+            },
+            {
+              "title": "`map-get-falsy-then-set-pre-node-26`",
+              "body": "Companion to `map-has-then-set-pre-node-26` — catches the `!M.get(k)` / `M.get(k) === undefined|null` semantically-identical variants that Node 26's `Map.prototype.getOrInsertComputed` replaces."
+            },
+            {
+              "title": "`fs-existssync-then-read-toctou`",
+              "body": "CodeQL `js/file-system-race` class — `fs.existsSync(p) + fs.readFile(p)` against the same path is symlink-swap-vulnerable. The canonical defense is `lib/atomic-file.js`'s open-by-fd-first pattern."
+            },
+            {
+              "title": "`buffer-from-string-on-auth-path`",
+              "body": "Flags `Buffer.from(String(x))` in `lib/` — auth-bearing sites become `b.safeBytes` migration targets in the next release."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 7692 §7.2.2 WebSocket permessage-deflate",
+          "url": "https://www.rfc-editor.org/rfc/rfc7692#section-7.2.2"
+        },
+        {
+          "label": "HIPAA §164.312(b) Audit Controls",
+          "url": "https://www.law.cornell.edu/cfr/text/45/164.312"
+        },
+        {
+          "label": "PCI-DSS v4.0 Req 10",
+          "url": "https://www.pcisecuritystandards.org/"
+        },
+        {
+          "label": "SEC 17a-4 WORM",
+          "url": "https://www.sec.gov/files/rules/final/34-44238.pdf"
+        },
+        {
+          "label": "SOX §404",
+          "url": "https://www.sec.gov/about/laws/soa2002.pdf"
+        },
+        {
+          "label": "CVE-2025-0725",
+          "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0725"
+        },
+        {
+          "label": "CodeQL js/file-system-race",
+          "url": "https://codeql.github.com/codeql-query-help/javascript/js-file-system-race/"
+        }
+      ]
+    },
+    {
+      "version": "0.11.3",
+      "date": "2026-05-19",
+      "headline": "SPF `a` and `mx` mechanism dispatch + smaller deferral-condition cleanups",
+      "summary": "`b.mail.spf.verify` now evaluates the `a` and `mx` mechanisms per RFC 7208 §5.3 + §5.4, including the dual-cidr-length syntax. Senders publishing `v=spf1 mx -all` or `v=spf1 a -all` previously permerrored against this framework even though those are the second-most-common SPF mechanisms in fielded policies.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "SPF `a` and `mx` mechanism evaluation",
+              "body": "`b.mail.spf.verify` now evaluates the `a` and `mx` mechanisms per RFC 7208 §5.3 + §5.4, including the dual-cidr-length syntax (`a:foo.example/24//64`, `mx//64`). Verification resolves the operator-supplied A / AAAA / MX records (via the existing `dnsLookup` callback contract — which is now honored for every record type, not only TXT) and matches the connecting IP under the parsed cidr. MX expansion is capped at the RFC §4.6.4 limit of 10 hosts (over-limit = permerror); each MX-host A/AAAA expansion counts toward the 10-lookup global ceiling and the 2-lookup void-lookup sub-limit."
+            }
+          ]
+        },
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "Empty digit segments in dual-cidr-length grammar refuse with permerror",
+              "body": "`a/`, `a//`, `mx/`, `mx//`, `a/24//` and similar shapes now permerror with an explanatory message. RFC §5.3/§5.4 grammar requires `1*DIGIT` after each slash; accepting empty would over-authorize senders publishing `v=spf1 a/ -all` (would match every IP in the /32 of every A record)."
+            },
+            {
+              "title": "`exists` and `ptr` mechanisms permerror with explanatory message",
+              "body": "`exists` (RFC §5.7) needs macro-string expansion (RFC §7) to be usable in fielded policies; `ptr` (RFC §5.5) is strongly discouraged by the RFC and rarely seen. Each now permerrors with an explanatory message naming the RFC section and a practical operator-side mitigation."
+            },
+            {
+              "title": "S/MIME documentation corrected to reflect v0.10.16 shipped state",
+              "body": "`b.mail.crypto.smime` `@card` and the v1-only-emits-metadata comment in `lib/mail-crypto-smime.js` are corrected to reflect that sign + verify shipped in v0.10.16 on the `b.cms` substrate. EFAIL-class encrypt/decrypt remains the only deferred slice."
+            },
+            {
+              "title": "Deferral conditions documented for ACME revocation and IMAP BAD UID responses",
+              "body": "`b.acme.create.revokeCert({ useCertKey: true })` and the `BAD UID <subverb>` IMAP listener response now carry explicit re-open conditions plus named operator escape hatches alongside the deferral."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`slice1-optional-parseint-silent-default`",
+              "body": "Any `.slice(1)` followed by an `if (X.length > 0)` guard around `parseInt(X, 10)` MUST sit in a file that also carries an explicit empty-segment refusal phrasing. Future cidr-length / prefix-length / port-range parsers inherit the discipline automatically."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 7208 §5.3 a mechanism",
+          "url": "https://www.rfc-editor.org/rfc/rfc7208#section-5.3"
+        },
+        {
+          "label": "RFC 7208 §5.4 mx mechanism",
+          "url": "https://www.rfc-editor.org/rfc/rfc7208#section-5.4"
+        },
+        {
+          "label": "RFC 7208 §4.6.4 DNS-lookup limits",
+          "url": "https://www.rfc-editor.org/rfc/rfc7208#section-4.6.4"
+        },
+        {
+          "label": "RFC 8551 S/MIME 4.0",
+          "url": "https://www.rfc-editor.org/rfc/rfc8551.html"
+        },
+        {
+          "label": "RFC 9051 IMAP4rev2 §6.4.9 UID",
+          "url": "https://www.rfc-editor.org/rfc/rfc9051#section-6.4.9"
+        }
+      ]
+    },
+    {
+      "version": "0.11.2",
+      "date": "2026-05-19",
+      "headline": "Node 26 floor-bump preparation",
+      "summary": "Today's `engines.node` floor is `>=24.14.1` and the framework runs cleanly on Node 26 (which satisfies the floor). This release ships the prep scaffolding so the future floor-bump (when Node 26 promotes to Active LTS and `>=26.x` becomes the floor) is mechanical.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.backup.diskStorage(opts)` — canonical name for the local-filesystem backup backend",
+              "body": "`b.backup.localStorage(opts)` continues to work and emits a one-time deprecation warning via `b.deprecate.alias`, with removal scheduled for the next major. The rename avoids the Node 26 platform-level `localStorage` global naming collision; the deprecation path follows the framework's stable upgrade policy (one minor with deprecation warnings before removal)."
+            },
+            {
+              "title": "Node 26 forward-compatibility integration test",
+              "body": "`test/integration/pqc-pkcs8-forward-compat.test.js` captures the ML-KEM-1024 / ML-DSA-65 / ML-DSA-87 / SLH-DSA-SHAKE-256f / Ed25519 PKCS8 export-byte shape on the current Node, asserts the sign+verify / encap+decap roundtrip via a re-imported KeyObject, and embeds a Node-26-shape fixture that re-imports every run. The forward-compat contract is testable today; the reverse-direction (Node-26-exported → Node-24-imported) test follows the floor-bump."
+            },
+            {
+              "title": "SECURITY.md and README gain Node 26 compatibility documentation",
+              "body": "SECURITY.md gains a Node 26 compatibility section documenting the `localStorage` global naming collision (bare references in operator handler code now resolve to a Node global rather than throwing `ReferenceError`) and the ML-KEM / ML-DSA seed-only PKCS8 export shape (Node-24-sealed material re-imports cleanly on Node 26; new material from Node 26 is seed-only — parallel Node 24 readers of the same sealed disk need a one-time migration when the writer moves). README Requirements line gains the matching Node 26 note."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`map-get-or-insert-pre-node-26`",
+              "body": "Flags the `if (!m.has(k)) m.set(k, factory()); m.get(k)` shape that Node 26's `Map.prototype.getOrInsertComputed(key, factory)` replaces in a single call. The detector lands as an allowlist marker — every existing call site in `lib/` is allowlisted with the spec file as the migration target; new code post-this-patch trips the gate. When the floor bumps the allowlist is walked and the detector flips to enforce."
+            }
+          ]
+        },
+        {
+          "heading": "Deprecated",
+          "items": [
+            {
+              "title": "`b.backup.localStorage(opts)` aliased to `b.backup.diskStorage(opts)`",
+              "body": "First-call deprecation warning via `b.deprecate.alias`; removal scheduled for the next major. The rename avoids the Node 26 `localStorage` global naming collision."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "Node.js v26 release notes",
+          "url": "https://nodejs.org/en/blog/release/v26.0.0"
+        },
+        {
+          "label": "TC39 Map.getOrInsertComputed",
+          "url": "https://github.com/tc39/proposal-upsert"
+        },
+        {
+          "label": "RFC 8032 §5.1 Ed25519 context parameter",
+          "url": "https://www.rfc-editor.org/rfc/rfc8032.html#section-5.1"
+        }
+      ]
+    },
+    {
+      "version": "0.11.1",
+      "date": "2026-05-19",
+      "headline": "Integration suite hardening + live coverage for the v0.11.0 surface",
+      "summary": "`b.httpClient.request` proxy + `allowInternal` interaction is corrected; `b.mail.crypto.smime.verify` exposes a `chainVerified` boolean; new integration tests cover S/MIME signing, SAML SLO, and RFC 7592 Dynamic Client Registration Management against the live Keycloak harness.",
+      "sections": [
+        {
+          "heading": "Changed",
+          "items": [
+            {
+              "title": "`b.httpClient.request` skips local SSRF DNS lookup when proxy + `allowInternal: true`",
+              "body": "The proxy resolves the destination hostname in its own network context, so requiring local resolution refused legitimate intranet / docker-service-name targets routed through the proxy. The SSRF gate still runs when `allowInternal` is false or array-form — the proxy's freedom to reach internal IPs is not a blanket license; the explicit opt-in is still required."
+            },
+            {
+              "title": "`b.mtlsCa` integration tests compose with `caKeySealedMode: \"disabled\"`",
+              "body": "Fixture purpose only. Production deployments continue to wire `opts.vault` for sealed-at-rest CA-key storage."
+            },
+            {
+              "title": "`b.mail.crypto.smime.verify` returns a `chainVerified` boolean",
+              "body": "The return shape gains a `chainVerified: boolean` field reflecting whether `opts.trustAnchorCertsPem` was supplied and the leaf-to-root chain walk completed."
+            }
+          ]
+        },
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "Live S/MIME integration test against a real X.509 chain",
+              "body": "New `test/integration/mail-crypto-smime.test.js` round-trips S/MIME sign + verify with a real X.509 chain issued by `b.mtlsCa` (CA → leaf cert → ML-DSA-65 signer), exercises tamper / wrong-key / untrusted-anchor refusal paths, and validates the `chainVerified` return field."
+            },
+            {
+              "title": "SAML SLO + RFC 7592 DCR Management coverage in federation-auth integration",
+              "body": "`test/integration/federation-auth.test.js` extends to cover SAML SLO (`buildLogoutRequest` against Keycloak's `/protocol/saml` SLO endpoint with the wire-format-parse assertion) and RFC 7592 Dynamic Client Registration Management (`registerClient` / `readClient` / `updateClient` / `deleteClient` against Keycloak's DCR endpoint)."
+            }
+          ]
+        }
+      ]
+    },
+    {
+      "version": "0.11.0",
+      "date": "2026-05-19",
+      "headline": "Mail-crypto sign/verify + SAML Single Logout + browser identity + CSP3 + hypermedia + sectoral postures",
+      "summary": "S/MIME sign + verify lands on a new in-tree CMS substrate with PQC signers; SAML 2.0 Single Logout (Redirect / POST / SOAP) ships with EncryptedAssertion and Holder-of-Key; browser-identity primitives (FedCM, DBSC, VAPID, Import Maps SRI) join the framework; a CSP Level 3 builder enforces no-`unsafe-*` defaults; OAuth Dynamic Client Registration Management (RFC 7592) and OpenID Connect Native SSO 1.0 close out the identity surface; 17 sectoral / cybersecurity / AI-governance compliance postures join the catalog.",
+      "sections": [
+        {
+          "heading": "Added",
+          "items": [
+            {
+              "title": "`b.cms.parseSignedData(buf)` — RFC 5652 SignedData walker",
+              "body": "Parses an inbound RFC 5652 §5.1 SignedData ContentInfo and returns `{ digestAlgs, encapContent, certificates, signerInfos }` as structured arrays so downstream verifiers check signatures without re-implementing the SignedData walker."
+            },
+            {
+              "title": "`b.mail.crypto.smime.sign(opts)` + `.verify(opts)` live on the `b.cms` substrate",
+              "body": "`sign` composes `b.cms.encodeSignedData` and wraps the payload in an RFC 8551 `multipart/signed; protocol=\"application/pkcs7-signature\"; micalg=sha3-{256,512}` envelope. `verify` parses the CMS SignedData payload, walks signed-attributes to extract the `messageDigest` attribute, recomputes the message digest, refuses tamper with `mail-crypto/smime/message-digest-mismatch`, and PQC-verifies the signature against the operator-supplied signer public key. Supports ML-DSA-65 / ML-DSA-87 / SLH-DSA-SHAKE-256f signers; SHA-2 family refused at `cms/bad-digest`."
+            },
+            {
+              "title": "S/MIME trust-anchor chain walk + revocation hook",
+              "body": "`b.mail.crypto.smime.verify({ trustAnchorCertsPem })` walks the SignerInfo cert chain leaf-to-root via `node:crypto.X509Certificate` with `notBefore` / `notAfter` checks and refuses `mail-crypto/smime/untrusted-chain` / `cert-expired` / `cert-not-yet-valid`. Revocation freshness is operator-wired via `b.network.tls.ocsp` when required."
+            },
+            {
+              "title": "`b.mail.crypto.pgp.experimental` PQC PGP encrypt/decrypt + WKD URL",
+              "body": "`encrypt(opts)` + `decrypt(opts)` ship under the `experimental` namespace because the RFC 9580bis PKESK ML-KEM codepoints are not IANA-registered yet. Envelope is ML-KEM-1024 KEM + ChaCha20-Poly1305 AEAD with per-recipient KEK derived via SHAKE256 bound to the literal label `pgp/experimental/chacha20-poly1305`. Multi-recipient envelopes; tamper / wrong-key refusal as typed errors. `wkd.computeUrl(email)` computes the draft-koch-openpgp-webkey-service URL (SHAKE256-hash localpart + zbase32 encoding) and returns `{ direct, advanced }` URLs — operators supply their own HTTPS fetcher."
+            },
+            {
+              "title": "`b.auth.saml.sp` Single Logout — Redirect, POST, and SOAP bindings",
+              "body": "`buildLogoutRequest({...})` / `parseLogoutRequest(b64, opts)` / `buildLogoutResponse({...})` implement SAML 2.0 Single Logout on the HTTP-Redirect binding per SAML Bindings §3.4.4.1 with PQC-signed canonical query (ML-DSA-65 / ML-DSA-87 / Ed25519). `buildLogoutRequestPost` / `parseLogoutRequestPost` cover the HTTP-POST binding, and `buildLogoutRequestSoap` / `parseLogoutResponseSoap` cover the SOAP synchronous back-channel — both with embedded XMLDSig-Enveloped signatures. SP metadata now emits `<md:SingleLogoutService>` bindings when `singleLogoutServiceUrl` is set; tamper / wrong-key / missing-signature each refuse as typed errors."
+            },
+            {
+              "title": "SAML SignatureMethod surface spanning XMLDSig 1.1 + RFC 9231",
+              "body": "Accepts `rsa-sha256` / `rsa-sha384` / `rsa-sha512` and `ecdsa-sha256` / `ecdsa-sha384` / `ecdsa-sha512` (W3C XMLDSig Core 1.1) plus `ed25519` (RFC 9231) so the framework interops with deployed IdPs out of the box. Classical keys are PEM strings or `node:crypto` KeyObject instances; PQC keys are `Uint8Array` from `b.pqcSoftware.ml_dsa_*.keygen()`. ML-DSA-65 / ML-DSA-87 are accepted under framework-private URIs (`urn:blamejs:experimental:saml-sig-alg:ml-dsa-65` / `:ml-dsa-87`) — no IETF / W3C XMLDSig registration exists for ML-DSA yet. Verification refuses inclusive-c14n, algorithm-confusion (SignatureMethod URI must match the operator-declared `idpVerifyAlg`), signature-wrapping (Reference URI must match root ID via timing-safe digest compare), and SHA-1 digest methods (CVE-2017-7525-class)."
+            },
+            {
+              "title": "SAML 2.0 §2.5 EncryptedAssertion decryption",
+              "body": "Decrypts AES-128-GCM / AES-256-GCM (W3C XMLEnc 1.1 §5.2.4) content with RSA-OAEP-MGF1P / xmlenc11 RSA-OAEP key transport (SHA-256/384/512 only; SHA-1 OAEP refused as CVE-2023-49141-class). AES-CBC content encryption is refused under both `xmlenc#aes128-cbc` and `xmlenc#aes256-cbc` (CVE-2011-1473 padding-oracle class) — operators integrating with IdPs that default to CBC (older ADFS / Azure AD / Okta / Keycloak / OneLogin) switch the IdP's content-encryption setting to AES-128-GCM or AES-256-GCM. Framework-experimental URIs `urn:blamejs:experimental:xmlenc:ml-kem-1024` (key transport) and `urn:blamejs:experimental:xmlenc:xchacha20-poly1305` (content) are accepted alongside the W3C URIs."
+            },
+            {
+              "title": "SAML Holder-of-Key SubjectConfirmation",
+              "body": "`b.auth.saml.sp.verifyResponse({ holderOfKey: { presentedCertPem } })` honors `urn:oasis:names:tc:SAML:2.0:cm:holder-of-key`: SHA3-512 fingerprint of the embedded KeyInfo/X509Data certificate is compared against the operator-supplied presented mTLS / possession-proof cert via `timingSafeEqual`. HoK and Bearer confirmations coexist."
+            },
+            {
+              "title": "OAuth Dynamic Client Registration Management (RFC 7592)",
+              "body": "`b.auth.oauth.readClient(uri, token)` / `updateClient(uri, token, metadata)` / `deleteClient(uri, token)` bind to the `registration_access_token` returned by `registerClient` and implement the GET / PUT / DELETE endpoints per RFC 7592. `updateClient` enforces the same `redirect_uris`-array refusal as `registerClient`."
+            },
+            {
+              "title": "OpenID Connect Native SSO 1.0 token exchange",
+              "body": "`b.auth.oauth.nativeSsoExchange({ deviceSecret, idToken, audience })` convenience-wraps `exchangeToken` for OpenID Connect Native SSO 1.0 §6 and adds `urn:openid:params:token-type:device-secret` to the RFC 8693 §3 token-type allowlist."
+            },
+            {
+              "title": "`b.webPush` — VAPID JWT keypair generation + auth header",
+              "body": "`generateVapidKeypair()` + `buildVapidAuthHeader(opts)` sign the RFC 8292 VAPID JWT inline (ECDSA-P256 per the spec). The framework's PQC-default JWT signer refuses ES256 by design, so `b.webPush` owns the signing rather than relaxing the broader policy."
+            },
+            {
+              "title": "`b.fedcm` — W3C FedCM 2024 IdP-side response builders",
+              "body": "`wellKnown({ provider_urls })` / `config({ accounts_endpoint, ... })` / `accountsResponse({ accounts })` / `idAssertionResponse({ token })` emit the JSON shapes the browser FedCM API expects from an IdP."
+            },
+            {
+              "title": "`b.dbsc` — IETF Device-Bound Session Credentials",
+              "body": "`challenge({ secretKey })` mints an HMAC-SHA3-512-signed challenge token that requires no server-side storage. `verifyBindingAssertion(jwt, opts)` refuses HS256 / `none` as algorithm-confusion, validates ES256 / RS256 against the embedded JWK, and returns the RFC 7638 JWK thumbprint so operators pin the binding key to a session."
+            },
+            {
+              "title": "`b.importmapIntegrity.build({ modules })` — WICG Import Maps + SRI",
+              "body": "Emits an integrity map (SHA-384 by default) so browsers refuse module bytes that don't match the operator-declared hashes."
+            },
+            {
+              "title": "`b.csp.build(directives, opts?)` + `b.csp.nonce(byteLen?)` + `b.csp.hash(scriptBody, alg?)`",
+              "body": "CSP Level 3 builder surface that refuses `'unsafe-*'` / catch-all `*` / `https:` / `data:` in non-image directives without an explicit acknowledgement opt. Auto-appends `require-trusted-types-for 'script'` plus the operator-supplied `trusted-types` policy list when any `script-*` directive is set. Emits ≥128-bit nonces by default and computes `sha256` / `sha384` / `sha512` hash sources for inline scripts. `b.middleware.securityHeaders` `coep` opt now documents the W3C CR 2024-12 `credentialless` value alongside `require-corp`."
+            },
+            {
+              "title": "OpenMetrics 1.0 exposition format",
+              "body": "`b.metrics` registry `exposition({ format: \"openmetrics\" })` emits the counter `_total` suffix, `# UNIT` lines, exemplar trace IDs on histograms, and the `# EOF` terminator per the openmetrics.io 1.0 wire format."
+            },
+            {
+              "title": "`b.standardWebhooks.sign` + `verify`",
+              "body": "Implements the standardwebhooks.com consortium spec (Stripe / Svix / Okta wire format): HMAC-SHA256, multi-version signature header, 5-minute default skew tolerance."
+            },
+            {
+              "title": "`b.lro` — AIP-151 Long-Running Operations",
+              "body": "`create({ store }) → { submit, status, list, cancel }` with operator-supplied storage and AbortSignal-aware cancellation."
+            },
+            {
+              "title": "`b.jsonApi.dataResponse(data, opts)` + `.errorResponse(errors)`",
+              "body": "Wraps domain payloads in the JSON:API v1.1 top-level shape and refuses missing Resource Object `type`."
+            },
+            {
+              "title": "`b.hal.resource(payload, { links, embedded, templates })`",
+              "body": "Builds HAL responses (draft-kelly-json-hal) with an RFC 8288 link-object normaliser."
+            },
+            {
+              "title": "Sectoral / cybersecurity / AI-governance compliance postures (17 new regimes)",
+              "body": "`b.compliance` posture catalog gains `42-cfr-part-2`, `hti-1`, `uscdi-v4`, `irs-1075`, `nist-800-172-r3`, `tlp-2.0`, `soci-au`, `nis2`, `cra`, `ffiec-cat-2`, `cri-profile-v2.0`, `m-22-09`, `m-22-18`, `nist-800-53-r5-privacy`, `nist-ai-600-1-genai`, `nist-csf-2.0`, `sb-53`, and `nyc-ll144-2024`. Each cascade pins the regime's normative floor (`backupEncryptionRequired` / `auditChainSignedRequired` / `tlsMinVersion` / `requireVacuumAfterErase`)."
+            }
+          ]
+        },
+        {
+          "heading": "Detectors",
+          "items": [
+            {
+              "title": "`number-coerce-or-zero-on-json-source`",
+              "body": "Refuses `Number(<var>['<kebab-cased-key>']) || 0` shapes — that coercion silently accepts `Infinity`, `NaN`, negative values, and arbitrary strings on operator-untrusted JSON-source input. Codifies the discipline that the previous TLS-RPT one-off established."
+            }
+          ]
+        }
+      ],
+      "references": [
+        {
+          "label": "RFC 5652 Cryptographic Message Syntax",
+          "url": "https://www.rfc-editor.org/rfc/rfc5652.html"
+        },
+        {
+          "label": "RFC 8551 S/MIME 4.0",
+          "url": "https://www.rfc-editor.org/rfc/rfc8551.html"
+        },
+        {
+          "label": "RFC 9580 OpenPGP",
+          "url": "https://www.rfc-editor.org/rfc/rfc9580.html"
+        },
+        {
+          "label": "draft-koch-openpgp-webkey-service",
+          "url": "https://datatracker.ietf.org/doc/draft-koch-openpgp-webkey-service/"
+        },
+        {
+          "label": "SAML 2.0 Bindings (Redirect / POST / SOAP)",
+          "url": "https://docs.oasis-open.org/security/saml/v2.0/saml-bindings-2.0-os.pdf"
+        },
+        {
+          "label": "SAML 2.0 Core §2.5 EncryptedAssertion",
+          "url": "https://docs.oasis-open.org/security/saml/v2.0/saml-core-2.0-os.pdf"
+        },
+        {
+          "label": "W3C XML-Encryption 1.1",
+          "url": "https://www.w3.org/TR/xmlenc-core1/"
+        },
+        {
+          "label": "RFC 7592 Dynamic Client Registration Management",
+          "url": "https://www.rfc-editor.org/rfc/rfc7592.html"
+        },
+        {
+          "label": "OpenID Connect Native SSO 1.0",
+          "url": "https://openid.net/specs/openid-connect-native-sso-1_0.html"
+        },
+        {
+          "label": "RFC 8292 VAPID for Web Push",
+          "url": "https://www.rfc-editor.org/rfc/rfc8292.html"
+        },
+        {
+          "label": "W3C CSP Level 3",
+          "url": "https://www.w3.org/TR/CSP3/"
+        },
+        {
+          "label": "W3C Trusted Types",
+          "url": "https://www.w3.org/TR/trusted-types/"
+        },
+        {
+          "label": "OpenMetrics 1.0",
+          "url": "https://openmetrics.io/"
+        },
+        {
+          "label": "Standard Webhooks",
+          "url": "https://www.standardwebhooks.com/"
+        },
+        {
+          "label": "Google AIP-151 Long-Running Operations",
+          "url": "https://google.aip.dev/151"
+        },
+        {
+          "label": "JSON:API v1.1",
+          "url": "https://jsonapi.org/format/1.1/"
+        },
+        {
+          "label": "draft-kelly-json-hal",
+          "url": "https://datatracker.ietf.org/doc/draft-kelly-json-hal/"
+        }
+      ]
+    }
+  ]
+}