@blamejs/blamejs-shop 0.5.5 → 0.5.7

package/lib/vendor/blamejs/release-notes/v0.15.23.json

@@ -1,22 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.23",
-  "date": "2026-06-24",
-  "headline": "`b.wsClient` error objects now carry a usable terminal-vs-transient signal (and the client's auto-reconnect, previously dead, works again), and `b.safePath` resolves cross-platform containment with the target platform's path semantics — fixing both a false refusal of in-base paths and a backslash-traversal escape when validating for Windows on a POSIX host",
-  "summary": "Two correctness fixes. b.wsClient marked every WsClientError permanent, so a consumer driving its own reconnect loop could not tell a terminal handshake failure (a bad URL, a 4xx rejection, an accept-mismatch, a protocol-violation frame) from a transient one (a 5xx handshake rejection, a pong/handshake timeout, a dropped socket) and had to re-derive the taxonomy from error codes. err.permanent now reflects the actual transience of each error, the single bad-status code is split by the carried HTTP status (4xx terminal, 5xx transient) with the status exposed as err.statusCode, and — because the client's own auto-reconnect keyed off the same always-true flag — auto-reconnect was silently disabled for every transient failure and now fires correctly. Separately, b.safePath.resolve / resolveOrNull / validate performed its lexical containment with the runtime path module while the per-segment naming walk used opts.platform. The two disagreeing broke cross-platform validation both ways: every legitimate in-base path was refused with safe-path/escapes-base when opts.platform differed from the host, and — more seriously — a POSIX host validating opts.platform: \"windows\" accepted a backslash traversal (ok\\..\\..\\outside), because the runtime resolver treats \\ as an ordinary filename character and never collapsed the .. segments, so the path escaped the base once a Windows consumer read the backslashes. The lexical resolve and containment boundary now use the target platform's path module (node:path.win32 / node:path.posix), matching the segment walk, so in-base paths resolve and cross-platform traversals are refused under any opts.platform override; the realpath check, which touches the live filesystem, keeps its runtime resolve.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "b.wsClient: WsClientError carries a real terminal/transient signal, and auto-reconnect works again",
-          "body": "WsClientError was declared always-permanent, so err.permanent was true for every error — a consumer's reconnect loop could not distinguish a terminal handshake failure (bad URL, bad subprotocol, malformed handshake header, accept-mismatch, bad upgrade, bad status line, a 4xx rejection, an oversized/protocol-violation frame) from a transient one (a 5xx handshake rejection, a pong- or handshake-timeout, a dropped socket) and had to maintain its own error-code list tracking the framework's taxonomy. err.permanent now reflects each error's actual transience, derived from its code (a new/unknown code defaults to terminal, so it fails closed rather than redialing a hopeless target forever); the single ws-client/bad-status code is split by the response status (4xx terminal, 5xx transient) and the status is exposed as err.statusCode (the existing err.status alias is preserved). The same always-permanent flag also drove the client's built-in auto-reconnect, which therefore never retried any framework-surfaced transient failure (a 5xx handshake or a keepalive timeout); reconnect now fires for transient failures and still skips terminal ones."
-        },
-        {
-          "title": "b.safePath: cross-platform containment resolves with the target platform's path semantics",
-          "body": "b.safePath.resolve / resolveOrNull / validate performed its lexical containment (resolve rel under base, then bound the result with a separator slice) using the runtime path module, while the per-segment naming walk used opts.platform. When the two disagreed, validation broke both ways. Benign direction: a Linux service validating server-origin names against the stricter Windows ruleset (the recommended cross-platform pattern) had every legitimate in-base path refused with safe-path/escapes-base, because the runtime-separated resolved path could never match a Windows-separator boundary. Security direction: a POSIX host validating opts.platform: \"windows\" accepted a backslash traversal such as ok\\..\\..\\outside — the segment walk splits on \\ for Windows, but the runtime resolver on POSIX treats \\ as an ordinary filename character and never collapsed the .. segments, so the path passed containment and resolved to <base>/ok\\..\\..\\outside, which escapes the base once a Windows consumer interprets the backslashes. The lexical resolve and the containment boundary now use the target platform's path module (node:path.win32 when validating for Windows, node:path.posix otherwise), matching the segment walk, so in-base paths resolve correctly and a genuine traversal is refused under any opts.platform override. The realpath check, which resolves symlinks on the live filesystem, keeps a separate runtime resolve because a foreign-platform path cannot be symlink-resolved on the host. opts.platform continues to gate the per-segment naming rules (reserved names, trailing dot/space, NTFS ADS colon)."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.24.json

@@ -1,22 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.24",
-  "date": "2026-06-25",
-  "headline": "Supply-chain hardening for the build: the example wiki container's base images are digest-pinned (and tracked for patches by Dependabot), and the SEA-build esbuild binary pin is centralized and release-enforced so a version bump can't silently lose its reviewed hash",
-  "summary": "A build supply-chain hardening release; no runtime API changes. The example wiki container's Chainguard base images are now pinned by digest (tag@sha256) for reproducible builds and provenance, with Dependabot's docker updater bumping the digests so they keep tracking Chainguard's continuous CVE rebuilds; the published multi-arch image is unaffected because the release workflow still resolves the rolling tag to a fresh digest at build time, so the scanned image equals the published image and the committed digest never reaches the image-scan gate. The esbuild native-binary supply-chain pin — the reviewed per-platform SHA-256 the bundler smoke gate checks the on-disk compiler against — is centralized in one file and enforced both at release time and in the pattern gate by a single shared verifier: the version package.json and the CI/publish workflows install must carry a complete reviewed-hash entry, so bumping esbuild without re-reviewing and re-pinning the binary now fails closed instead of silently degrading the verification to a skip.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "Wiki container base images are digest-pinned and patch-tracked",
-          "body": "examples/wiki/Dockerfile now pins its Chainguard base images by digest (cgr.dev/chainguard/node:<tag>@sha256:...) for reproducible local builds and supply-chain provenance, and Dependabot's docker updater bumps those digests so they keep tracking Chainguard's continuously-rebuilt CVE fixes instead of freezing. The published multi-arch image is unchanged: the release workflow still resolves the rolling tag to a fresh digest at build time and passes it as a build-arg, so the scanned image equals the published image and always carries current patches — the committed digest never reaches the image-scan gate."
-        },
-        {
-          "title": "esbuild SEA-build binary pin is centralized and fails closed on an un-reviewed bump",
-          "body": "The reviewed per-platform SHA-256 hashes that the bundler smoke gate verifies the esbuild native compiler against are now a single source of truth (scripts/esbuild-binary-pin.json), checked by one shared verifier that runs both at release time and in the pattern gate. It enforces that the esbuild version package.json declares and the CI/publish workflows install carries a complete reviewed-hash entry for every required platform. Previously a bump to a version with no reviewed hash made the smoke gate note-and-skip the binary verification; that omission now fails the release, so the binary pin can no longer be silently lost. The hashes remain captured by hand on each bump (diff the published tarballs, sha256 the binary) — the verifier checks the pin is present, it never derives it."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.25.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.25",
-  "date": "2026-06-25",
-  "headline": "`b.sandbox.run` no longer leaks the worker thread's MessagePort — it now waits for the worker to terminate before resolving",
-  "summary": "b.sandbox.run spawned a worker thread to execute untrusted code and called worker.terminate() on both the result and timeout paths, but it settled the caller's promise BEFORE the asynchronous terminate() completed — leaving the worker's MessagePort alive past the resolve. In a long-lived process that runs sandboxed code repeatedly, each call leaked a MessagePort handle, keeping the event loop populated and slowing graceful shutdown. The call now awaits worker.terminate() before settling, so the handle is released when the promise resolves. Behaviour and return values are unchanged.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "b.sandbox.run releases the worker MessagePort before resolving",
-          "body": "b.sandbox.run resolved (or rejected) the caller's promise as soon as the worker reported a result or the timeout fired, while worker.terminate() — which is asynchronous — was still in flight, so the worker thread's MessagePort outlived the call and lingered as an open handle. Repeated sandbox runs in a long-lived process accumulated leaked MessagePorts that kept the event loop alive and delayed shutdown. The result and timeout paths now defer settling until worker.terminate() resolves; the error and exit paths already imply the worker is gone. The return value, audit events, and timeout semantics are unchanged."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.26.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.26",
-  "date": "2026-06-25",
-  "headline": "Internal test-harness correctness only — the published library is byte-for-byte identical to 0.15.25",
-  "summary": "The smoke runner requires each test module and awaits its exported run(). Several tests were instead written as a top-level (async function () {...})() IIFE that runs detached at require-time, so the runner measured and reported the test's result before the IIFE's post-await assertions executed — those checks silently never ran (one parser test exercised 4 of its 26 assertions, and a failure after the first await would have gone unseen as a false pass). Those tests are converted to the exported-run form so the runner awaits their full assertion set, and a codebase-patterns detector now refuses a top-level async IIFE in a test file so the pattern cannot return. No shipped framework code changed; this release is byte-for-byte identical to 0.15.25 for operators.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "Detached-IIFE tests now run their full assertion set under the smoke runner",
-          "body": "A test written as a top-level (async function () {...})() IIFE runs detached when the runner requires it: the runner only awaits an exported run(), so it reported the file's result before the IIFE's awaited assertions executed, and every check after the first await silently did not count (one parsers test ran 4 of 26). Such tests are rewritten to define async function run(), export it, and invoke it under if (require.main === module), so the runner awaits the complete set; a detector refuses a re-introduced top-level async IIFE in a test file. This is test-harness correctness only — no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.27.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.27",
-  "date": "2026-06-25",
-  "headline": "Internal test-harness reliability only — the published library is byte-for-byte identical to 0.15.26",
-  "summary": "The legacy single-layer smoke files used fixed-duration setTimeout sleeps to wait for asynchronous conditions (a job processed, a lease TTL lapsing, an audit flush completing). On a contended CI runner a fixed sleep is both flake-prone (too short under load) and slow (it always burns the full budget). Those condition-waits are converted to the harness's polling helpers — waitUntil for observable predicates, passiveObserve for deliberate real-time elapses, withTestTimeout for hang guards — which exit early on fast platforms and give contended platforms the full budget. No shipped framework code changed; this release is byte-for-byte identical to 0.15.26 for operators.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "Smoke layer files poll for conditions instead of fixed setTimeout sleeps",
-          "body": "The single-layer smoke files waited on asynchronous conditions with fixed-duration setTimeout sleeps, which flake under SMOKE_PARALLEL load and always burn their full budget. The condition-waits are converted to the polling helpers (waitUntil / passiveObserve / withTestTimeout) so they exit early on fast platforms and stay robust on contended ones; non-wait timers (abort triggers, child/socket watchdogs, simulated-latency mocks) are unchanged. This is test-harness reliability only — no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.28.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.28",
-  "date": "2026-06-25",
-  "headline": "`b.network.dns` and `b.network.tls` errors now carry a usable terminal-vs-transient signal on `err.permanent`, so a caller's retry loop re-attempts only the failures a retry can fix",
-  "summary": "DnsError was declared always-transient and NetworkTlsError always-permanent, so a consumer driving its own retry loop got the wrong signal in both directions: it would retry a permanent DNS failure (a bad host, bad options, an unsupported query, an NXDOMAIN-style no-result, or a caller-shape/config error such as an unconfigured transport or an invalid resolver list) forever, and it would refuse to retry a transient TLS-over-network failure (an ECH connection failure, a handshake timeout, DNS momentarily unavailable). err.permanent now reflects each error's actual transience, derived from its code and failing closed (an unknown code is permanent, so a hopeless target is not retried indefinitely): for DnsError only a failed network round-trip (a lookup timeout, a resolve/reverse query that failed on the wire, a failed DoH/DoT exchange, a DDR discovery that found nothing) is transient — config, input, and environment errors raised before any network work are permanent; for NetworkTlsError only the network-layer ECH failures are transient. TlsTrustError remains always-permanent by design — a trust-verification failure (bad CA, fingerprint mismatch, OCSP not-good, CT violation, an unreachable OCSP responder) must never be silently retried past the trust decision.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "DnsError / NetworkTlsError expose a correct terminal/transient signal; TlsTrustError stays terminal",
-          "body": "b.network.dns's DnsError was always-transient and b.network.tls's NetworkTlsError always-permanent, so err.permanent misled a consumer's retry loop in both directions — retrying a permanent DNS error (bad host / options / unsupported type / no-result) indefinitely, and never retrying a transient TLS network error (ECH connect failure, handshake timeout, DNS unavailable). err.permanent now reflects each error's actual transience by code and fails closed (unknown codes are permanent): DnsError is transient only for a failed network round-trip (dns/lookup-timeout, dns/resolve-failed, dns/reverse-failed, dns/doh-failed, dns/dot-failed, dns/dot-handshake-failed, dns/ddr-not-discovered, dns/system-failed), and permanent otherwise — including the caller-shape / environment errors raised before any network work (dns/transport-unavailable for an unconfigured transport, dns/dnr-no-resolvers for an empty/invalid resolver list, dns/setservers-failed for an invalid address, dns/no-system-resolvers when none are configured). NetworkTlsError is transient only for the network-layer ECH failures (tls/ech-connect-failed, tls/ech-timeout, tls/ech-dns-unavailable), permanent otherwise. TlsTrustError remains always-permanent so a trust-verification failure is never silently retried."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.29.json

@@ -1,27 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.29",
-  "date": "2026-06-25",
-  "headline": "JSON parsing of operator and untrusted input is routed through `b.safeJson` everywhere, so a `\"__proto__\"` member is stripped and the parse is size-bounded — `b.openapi.parse`, `b.asyncapi.parse`, and `b.sandbox.run` were using a raw `JSON.parse`",
-  "summary": "b.openapi.parse and b.asyncapi.parse parsed an operator-supplied document string with a raw JSON.parse, which re-creates a \"__proto__\" member as an own key and imposes no size bound; b.sandbox.run parsed the untrusted sandboxed code's serialized result the same way (proto member kept, depth unbounded). All three now route through b.safeJson, which strips the prototype-pollution keys and applies the depth / key / size caps. A new b.safeJson.parseStringOrObject primitive captures the recurring \"accept a document as a JSON string OR a pre-built object\" shape (a string is parsed safely, an object passes through) that openapi and asyncapi had each hand-rolled, with each consumer's typed error class and a generous document size cap passed as data. Valid input parses identically to before; a malicious or oversized document is now defused rather than accepted.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "Operator and untrusted JSON parses strip __proto__ and bound size (no raw JSON.parse)",
-          "body": "A raw JSON.parse keeps a \"__proto__\" object member as an own key (a prototype-pollution gadget for any downstream merge) and parses unbounded input. b.openapi.parse and b.asyncapi.parse used it on operator document strings, and b.sandbox.run used it on the untrusted sandboxed code's JSON-serialized result. All now route through b.safeJson — the prototype-pollution keys are stripped and the depth / key / size caps apply (a 16 MiB document cap for openapi/asyncapi, the existing result-bytes cap for the sandbox). Internal JSON parses (the sealed DSR store payloads, the VEX canonical re-format) route through the same primitive too, so the guarantee cannot be bypassed one call site at a time. Valid input is unaffected; a \"__proto__\"-laden or oversized payload is defused."
-        }
-      ]
-    },
-    {
-      "heading": "Added",
-      "items": [
-        {
-          "title": "b.safeJson.parseStringOrObject(input, opts?)",
-          "body": "Accepts either a JSON string — parsed through b.safeJson.parse, so the prototype-pollution-key strip and depth / key / size caps apply — or an already-decoded plain object (returned unchanged). For the recurring \"operator hands me a document as a JSON string or a pre-built object\" surface (b.openapi / b.asyncapi). The consumer's typed error class, error codes, label, and size cap are passed as options, so a raw JSON.parse on operator input cannot be hand-rolled per consumer."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.3.json

@@ -1,39 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.3",
-  "date": "2026-06-12",
-  "headline": "DDL hardening in b.sql, schema-confined column introspection on Postgres and MySQL, and a classical-downgrade audit on proxy-tunneled TLS",
-  "summary": "This release hardens the data layer and closes a transport audit gap. The b.sql builder refuses an unrecognised column type that carries a statement terminator, quote, or comment marker - the one position in an otherwise quote-by-construction DDL builder where a verbatim string reached the emitted statement - and routes the finished CREATE TABLE through the same single-statement gate every other verb uses. The schema reconciler's column introspection is now confined to the schema or database the bare-named CREATE TABLE actually writes into (current_schema() on Postgres, DATABASE() on MySQL), so a same-named table in another schema no longer pollutes the column set, silently skipping an ADD COLUMN or fabricating false schema drift that refuses a regulated-posture boot. Two further builder gaps are fixed: a column-level primary key combined with a composite primaryKey now fails at build time with a clear error instead of producing invalid DDL, and a MySQL upsert read-back keyed by a cast or a server-evaluated function now renders the cast (or refuses the function) instead of binding an internal wrapper. Finally, an HTTPS request sent through a configured proxy now emits the tls.classical_downgrade audit when the handshake falls back to a classical group, the same as a direct connection.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "b.sql refuses an injection-bearing verbatim column type and gates every CREATE TABLE",
-          "body": "An unrecognised column type passed to b.sql.createTable / alterTable was emitted into the DDL verbatim - the single raw-emission position in a builder that otherwise quotes every identifier and guards every constraint fragment. A type such as \"text); DROP TABLE secrets; --\" could therefore smuggle a stacked statement. The builder now refuses, at build time, a verbatim type carrying a statement terminator or comment marker, and routes the finished CREATE TABLE / ALTER TABLE statement through the same single-statement / NUL / unterminated-quote / unbalanced-paren gate every SELECT / INSERT / UPDATE / DELETE / UPSERT already used - so an unbalanced quote is caught there. Legitimate types are unaffected: VARCHAR(255), NUMERIC(10,2), DOUBLE PRECISION, TIMESTAMP WITH TIME ZONE, and MySQL ENUM('a','b') / SET(...) (which need balanced quotes) all still pass."
-        }
-      ]
-    },
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "Schema reconciliation reads columns from the right schema on Postgres and MySQL",
-          "body": "The reconciler's column introspection queried information_schema with no schema filter, so on a Postgres instance or MySQL server hosting more than one schema/database with a same-named table, the live column set was the union across schemas. That could silently skip an ADD COLUMN the table needed, or report false drift that refuses a boot under a pinned regulated posture. Introspection is now confined to current_schema() (Postgres) / DATABASE() (MySQL) - the schema the bare-named CREATE TABLE lands in. SQLite (PRAGMA, per-file) is unchanged."
-        },
-        {
-          "title": "createTable rejects a contradictory primary-key declaration at build time",
-          "body": "Declaring both a column-level primary key (primaryKey / autoIncrement / serial) and a composite opts.primaryKey emitted two PRIMARY KEY clauses, which every dialect rejects at the driver mid-migration. The builder now refuses the contradiction at build time with a clear error; a single column PK, or a composite primaryKey with no column-level PK, is unaffected."
-        },
-        {
-          "title": "MySQL upsert read-back resolves a cast or function conflict key instead of binding a wrapper",
-          "body": "On MySQL, an upsert whose conflict key was a b.sql.cast(...) or b.sql.fn(...) built a read-back SELECT that bound the wrapper object, so the read-back matched no rows. A cast conflict key now renders as CAST(? AS type) binding the inner value; a server-evaluated function conflict key (which has no stable read-back identity) is refused with a clear error. Plain scalar conflict keys are unchanged."
-        },
-        {
-          "title": "Proxy-tunneled TLS emits the classical-downgrade audit",
-          "body": "An HTTPS upstream reached through a configured proxy performed its TLS handshake without emitting the tls.classical_downgrade audit on a classical-group fallback, leaving the post-quantum-readiness inventory incomplete for proxied requests. Both the upstream handshake and the proxy-leg handshake now emit the audit on a classical fallback, matching the direct connection path. The handshake itself is unchanged (still hybrid-preferred TLSv1.3)."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.30.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.30",
-  "date": "2026-06-26",
-  "headline": "Importing the webhook module for inbound signature verification no longer pulls the Node HTTP client (or its `node:http` / `node:https` / `node:http2` chain), so `b.webhook.verify` runs in a Worker / edge runtime when the module is imported directly",
-  "summary": "lib/webhook and its delivery store eagerly required the outbound HTTP client at module load — directly, and transitively through the persistence-backed dispatcher — so importing the webhook module threw in a Cloudflare Workers / edge runtime that has no node:http / node:net / node:tls, even though b.webhook.verify needs only HMAC-SHA-256 and a timing-safe compare. The HTTP client and the SQL-backed dispatcher are now resolved lazily, only on the outbound send / dispatch paths; importing the module for inbound verification loads no Node networking module. Verified by asserting no networking builtin appears in process.moduleLoadList on the verify path. The framework's aggregate entry point still initializes the networking stack eagerly, so the edge verify path is the webhook module imported directly rather than the aggregate b namespace.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "Inbound webhook verification loads without the Node networking stack (Worker / edge runtime)",
-          "body": "The webhook module and its dispatcher delivery store required the outbound HTTP client (node:http / node:https / node:http2) at module load, so importing the module threw in a runtime without those builtins — even though b.webhook.verify is HMAC-SHA-256 plus a timing-safe compare and the dispatcher (SQL-backed persistence) is only needed for outbound delivery. The HTTP client and the dispatcher are now resolved lazily, on the outbound send / dispatch paths only; the inbound verify path loads no Node networking module. An edge handler that imports the webhook module directly can pre-verify an inbound Stripe webhook signature with the primitive's hardening (Stripe-Signature size cap, v1-hex anti-DoS cap, minimum-tolerance floor, optional atomic replay store) instead of hand-rolling the t=/v1= parse, tolerance window, and timing-safe compare. The framework's aggregate entry still loads the networking stack eagerly; import the webhook module directly for the edge verify path."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.31.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.31",
-  "date": "2026-06-26",
-  "headline": "Internal test-suite hardening only — the published library's runtime behavior and public API are unchanged (source-comment marker text aside)",
-  "summary": "The codebase-patterns guard suite gains a gate that retires a renamed suppression-marker token: once a suppression class is re-verified and renamed, its old token cannot be silently re-registered, so a later suppression has to be re-examined under the new name instead of inheriting a stale approval. Eight suppression classes were re-verified and renamed to descriptive tokens this release, and their in-source marker comments were updated to match. No runtime code, public API, or wire format changed.",
-  "sections": [
-    {
-      "heading": "Detectors",
-      "items": [
-        {
-          "title": "Re-verification gate retires a renamed suppression-marker token",
-          "body": "A new guard refuses to re-register a retired suppression-marker token, and the orphan check points a stale marker at its current name. When a suppression class is re-verified, it is renamed to a descriptive token and the old name is recorded as retired, so the old approval cannot be quietly resurrected — a future suppression must be re-examined and re-stamped under the new name. This is test-suite tooling; no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.32.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.32",
-  "date": "2026-06-26",
-  "headline": "Internal test-suite hardening only — the published library's runtime behavior and public API are unchanged (source-comment marker text aside)",
-  "summary": "Three more suppression classes in the codebase-patterns guard suite were re-verified from scratch and renamed to descriptive tokens, with their old names recorded as retired so the prior approval cannot be silently resurrected and their in-source marker comments updated to match. No runtime code, public API, or wire format changed.",
-  "sections": [
-    {
-      "heading": "Detectors",
-      "items": [
-        {
-          "title": "Three more suppression-marker classes re-verified and their tokens retired",
-          "body": "Continuing the re-verification pass: each marked site for the process-exit, hand-rolled buffer-collect, and raw-outbound-http guard classes was re-read and confirmed (operator-opt-in exits; bounded protocol-framing / TLV assembly; framework-routed outbound calls), then the class was renamed to a descriptive token and its old name added to the retired-token set. This is test-suite tooling; no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.33.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.33",
-  "date": "2026-06-26",
-  "headline": "Internal test-suite hardening only — the published library's runtime behavior and public API are unchanged (source-comment marker text aside)",
-  "summary": "Three more suppression classes in the codebase-patterns guard suite were re-verified from scratch and renamed to descriptive tokens, with their old names recorded as retired and their in-source marker comments updated to match. No runtime code, public API, or wire format changed.",
-  "sections": [
-    {
-      "heading": "Detectors",
-      "items": [
-        {
-          "title": "Three more suppression-marker classes re-verified and their tokens retired",
-          "body": "Continuing the re-verification pass: each marked site for the math-random-noncrypto, raw-new-url, and dynamic-require guard classes was re-read and confirmed (non-security jitter/sampling; URL parsing for shape/origin inspection or behind the safe wrapper; operator-supplied module loads), then the class was renamed to a descriptive token and its old name added to the retired-token set. This is test-suite tooling; no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.34.json

@@ -1,27 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.34",
-  "date": "2026-06-26",
-  "headline": "`b.mail.crypto.pgp.verify` now accepts every valid RSA OpenPGP signature — one whose value happened to have a high zero byte (about 1 in 256) was being rejected",
-  "summary": "An OpenPGP RSA signature is an integer modulo the key's modulus, and ~1 in 256 signatures have a value that begins with a zero byte. The MPI encoding strips those leading zero bytes (RFC 9580 §3.2), but b.mail.crypto.pgp.verify passed the stripped value straight to the RSA verification, which requires a signature exactly the modulus byte length — so a perfectly valid signature was intermittently reported invalid. The signature is now left-padded back to the modulus width before verification, exactly as the Ed25519 path already pads its components. Verification of every valid RSA signature is now reliable, including signatures produced by other OpenPGP implementations. Also includes internal test-tooling: two more guard-suite suppression classes were re-verified and their tokens retired.",
-  "sections": [
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "RSA OpenPGP signatures with a high zero byte now verify reliably",
-          "body": "b.mail.crypto.pgp.verify read the RSA signature MPI (whose leading zero bytes the OpenPGP wire format strips) and handed it to the RSA verification without restoring the stripped bytes. Node's RSA verify requires the signature to be exactly the modulus byte length, so a signature whose value had one or more high zero bytes — about 1 in 256 of all signatures, for any key — was rejected as invalid even though it was correct. The signature is now left-padded to the modulus width before verification (the same correction the Ed25519 verification path already applied to its R/S components). This affects signatures the framework produces and signatures from other OpenPGP implementations alike. A deterministic regression test searches for a short-MPI signature and asserts it verifies."
-        }
-      ]
-    },
-    {
-      "heading": "Detectors",
-      "items": [
-        {
-          "title": "Two more suppression-marker classes re-verified and their tokens retired",
-          "body": "The raw-hash-compare and seal-without-aad guard classes were re-read and confirmed (a data-residency region tag compared with === — not a secret; and two intentional non-AEAD-bound seals — a non-regulated plain-mode column whose AAD is enforced by the posture seal-envelope floor where it matters, and a throwaway vault-readiness probe), then renamed to descriptive tokens with their old names added to the retired-token set. Test-suite tooling only."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.35.json

@@ -1,27 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.35",
-  "date": "2026-06-26",
-  "headline": "`b.metrics` shadow registry no longer lets a comma in a label value forge extra Prometheus label pairs — a label-injection that downstream tenant-scoping or authorization selectors could be tricked by",
-  "summary": "The shadow registry serialized a metric's label set into a `name=value,name=value` string key and re-split it on `,` to build the Prometheus exposition. A label VALUE containing a comma therefore split into multiple label pairs, so a single operator-set label could forge additional label pairs in the scrape output (for example turning one `route` label into a `route` plus an attacker-named label), which downstream tenant-scoping filters, authorization selectors, recording rules, and alerting trust as a boundary; two distinct label sets could also collide into one cardinality bucket. The label key now uses canonical-JSON of the string-coerced label set (the same approach the main registry already used) and the render path emits the structured label set kept alongside that key rather than splitting or re-parsing, so a `,` or `=` inside a label value stays inside the value and a label NAMED `constructor`, `prototype`, or `__proto__` (all valid Prometheus label names) is preserved instead of being dropped. Note: the cardinality keys exposed by `shadowRegistry().snapshot()` are now canonical-JSON strings (e.g. `{\"route\":\"/api\"}`) rather than `route=/api`.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "Label values can no longer forge extra Prometheus label pairs in the shadow registry",
-          "body": "b.metrics shadowRegistry built a metric's cardinality key by joining `name=value` pairs with commas, then split that string on commas when rendering the Prometheus exposition. A comma (and `=`) in a label value therefore broke one value into several forged label pairs in the scrape output, and two different label sets could collide into the same cardinality bucket. The key is now canonical-JSON of the string-coerced label set and the render emits the structured label set kept alongside that key rather than splitting or re-parsing, so a label value is emitted as a single quoted value with its commas/equals intact, distinct label sets get distinct keys, and a label NAMED `constructor`, `prototype`, or `__proto__` (each a valid Prometheus label name) is preserved rather than dropped. Deterministic regression tests assert a comma-bearing label value produces exactly one label pair and that the reserved-name labels survive render."
-        }
-      ]
-    },
-    {
-      "heading": "Changed",
-      "items": [
-        {
-          "title": "shadowRegistry().snapshot() cardinality keys are canonical-JSON",
-          "body": "As a consequence of the label-injection fix, the per-series cardinality keys in a shadow-registry snapshot are now canonical-JSON strings (e.g. `{\"tenant\":\"a\"}`) instead of the previous `tenant=a` form. Code that reads those keys directly from snapshot() should parse them as JSON; the Prometheus render output is unchanged for conforming label values."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.36.json

@@ -1,18 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.36",
-  "date": "2026-06-27",
-  "headline": "Internal test-suite hardening only — the published library's runtime behavior and public API are unchanged (source-comment marker text aside)",
-  "summary": "The codebase-patterns guard class that allows a bare comma/semicolon split on token-only RFC header grammars was re-verified from scratch and renamed to a descriptive token, with its old name recorded as retired. Each live marked site (RRULE, RFC 9421 component identifiers, TLS-RPT rua, SCIM attribute paths) was re-read and confirmed to split a grammar with no quoted-string members. Five marker comments that suppressed nothing were removed or turned into plain explanatory comments. No runtime code, public API, or wire format changed.",
-  "sections": [
-    {
-      "heading": "Detectors",
-      "items": [
-        {
-          "title": "Bare token-only header-split suppression class re-verified, renamed, and pruned of inert markers",
-          "body": "Each marked bare `.split(\",\")` / `.split(\";\")` on an RFC header value was re-read and confirmed to operate on a token-only grammar (no quoted-string members, so a quote-aware splitter is unnecessary): RFC 5545 RRULE, RFC 9421 signature component identifiers, RFC 8460 TLS-RPT rua, and RFC 7644 SCIM attribute paths. The guard class was renamed to a descriptive token and its old name added to the retired-token set. Five marker comments that the detector never actually evaluated (two sat on a date-normalizing `.replace`, three in header parsers the guard intentionally does not scan) were removed or converted to plain comments. This is test-suite tooling plus source-comment text; no shipped framework behavior changed."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.37.json

@@ -1,26 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.37",
-  "date": "2026-06-27",
-  "headline": "Several numeric options that silently accepted a non-finite value — disabling a clock-skew / freshness check or a resource cap — now reject it, so an `Infinity` skew or limit can no longer turn off the protection it configures",
-  "summary": "A number of configuration options validated a numeric value with a bare `typeof === \"number\" && value >= 0` check, which accepts `Infinity`. Where the value is a clock-skew tolerance or a resource cap, an `Infinity` (or `NaN`) silently disabled the very check it tunes: a CWT / OCSP-staple / ARC clock-skew of `Infinity` made the expiry, freshness, and expiration comparisons unsatisfiable (an expired token / a replayed pre-revocation \"good\" response / an expired ARC seal would be accepted); a WebSocket-client `maxMessageBytes` / `maxFrameBytes` / `handshakeTimeoutMs` of `Infinity` disabled the inbound-OOM and stalled-handshake defenses; and inbox / flag-cache / audit-chain size and count caps of `Infinity` admitted unbounded data. These options now route through the finite-bounds validator: a present non-finite value is refused at the entry point (or falls back to the safe default on the result-returning paths). Options where an unbounded value is a deliberate intent — reconnect \"retry indefinitely\", inbox \"retain indefinitely\" — continue to accept `Infinity`.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "A non-finite clock-skew no longer disables CWT / OCSP / ARC time checks",
-          "body": "b.cwt.verify, the OCSP-staple freshness check in b.network.tls, and b.mail.arc.verify each took an operator clock-skew tolerance validated as `typeof === \"number\" && >= 0`, which accepts `Infinity`. Because each check is of the form `now > deadline + skew`, a skew of `Infinity` made it unsatisfiable and silently turned the check off: an expired CWT verified, a stale (post-nextUpdate) OCSP \"good\" response — the exact reply an attacker replays after the certificate is revoked — was accepted, and an expired ARC seal passed. A present clock-skew that is not a non-negative finite integer is now refused (b.cwt.verify throws cwt/bad-clock-skew; the OCSP and ARC paths fall back to their safe default). Regression tests assert an expired token / stale staple / expired ARC seal is still rejected when the skew is `Infinity`."
-        },
-        {
-          "title": "WebSocket-client inbound caps can no longer be disabled by an Infinity value",
-          "body": "b.wsClient.connect validated maxMessageBytes, maxFrameBytes, and handshakeTimeoutMs (and the ping/pong keepalive intervals) with a bare numeric check that accepted `Infinity`, which disabled the inbound-message and frame size limits — the defenses against a malicious server sending an unbounded message — and the handshake timeout. A present non-finite value for these is now refused at connect time. The reconnect maxAttempts still accepts `Infinity` (a deliberate \"reconnect indefinitely\" intent)."
-        },
-        {
-          "title": "Inbox, flag-cache, and audit-chain caps reject a non-finite limit",
-          "body": "The inbox maxPayloadBytes / messageIdMaxLen / sourceMaxLen caps, the flag-cache ttlMs / maxEntries, and the audit-chain partition fan-out cap each accepted `Infinity`, disabling the cap (unbounded stored payloads, a never-expiring or unbounded cache, unbounded fan-out). These now require a positive finite integer — refused at create time, or clamped to the bounded default on the result-returning verify path. The inbox retentionDays still accepts `Infinity` (retain indefinitely)."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.38.json

@@ -1,26 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.38",
-  "date": "2026-06-27",
-  "headline": "Regex patterns supplied in feature-flag targeting rules and MCP tool input schemas are now screened for catastrophic-backtracking (ReDoS) shapes before compilation, so a pattern matched against request data can't pin a CPU",
-  "summary": "Two places compiled a caller-supplied regex pattern and `.test()`'d it against request-controlled input with only a length bound as the stated defense: a feature-flag targeting condition (`op: \"regex\"`) matched against runtime attribute values, and an MCP tool's input-schema `pattern` matched against tool-call arguments. A length bound is not a ReDoS defense — a catastrophic-backtracking pattern such as `(a+)+$` is six characters and pins a CPU on a crafted input. Both patterns now pass through `b.guardRegex` (strict profile) before compilation, which refuses nested-quantifier, alternation-with-quantifier, and quantifier-inside-lookaround shapes. A ReDoS-shaped flag pattern is refused when the rules are validated; a ReDoS-shaped MCP schema pattern fails tool-input validation. Patterns built from the framework's own static tables, operator-owned JSON Schema patterns, the Sieve glob translator (which cannot express nested quantifiers), and the I-Regexp translator (linear by dialect) are unchanged.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "Feature-flag regex targeting conditions are screened for ReDoS before compilation",
-          "body": "A flag targeting rule with `op: \"regex\"` compiled the operator-supplied pattern and `.test()`'d it against runtime attribute values, guarded only by a 200-character length cap. Length does not bound catastrophic backtracking, so a pattern like `(a+)+$` combined with an attacker-controlled attribute value could pin a CPU during flag evaluation. The pattern is now screened through b.guardRegex (strict) when the rules are validated, and a catastrophic-backtracking shape is refused with a clear error."
-        },
-        {
-          "title": "MCP tool input-schema patterns are screened for ReDoS before matching request input",
-          "body": "b.mcp.validateToolInput compiled a tool author's input-schema `pattern` and matched it against tool-call argument values; the 4096-character input cap does not bound backtracking (a `(a+)+$` pattern blows up at roughly forty input characters). The schema pattern is now screened through b.guardRegex (strict) before compilation, so a ReDoS-shaped pattern in a registered tool's schema fails input validation instead of letting hostile arguments hang the validator."
-        },
-        {
-          "title": "b.guardRegex now catches wrapped nested-quantifier patterns",
-          "body": "The nested-quantifier detector matched a quantified group whose body contained a quantifier, but its inner match was paren-blind, so wrapping the inner quantifier in an extra group — `((a)+)+`, `(([a-z]+)*)*`, `((a+))+` — slipped past it while remaining catastrophic. A structural scan now tracks group nesting and refuses an unbounded-quantified group whose body itself contains an unbounded quantifier at any depth, so the wrapped forms are rejected alongside the bare `(a+)+`. Bounded repeats (`{n}`, `{n,m}`) are unaffected. This strengthens every b.guardRegex caller, including the flag-targeting and MCP screening above."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.4.json

@@ -1,39 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.4",
-  "date": "2026-06-12",
-  "headline": "Telemetry attribute values are redacted before they leave the process, per-row data residency is enforced on every write and export path, DDL routes through the single-statement gate, the DPoP middleware requires its replay store, and session rotation re-keys the device binding",
-  "summary": "This release closes a set of egress, data-residency, and session-binding gaps. OTLP span, span-event, and resource attributes are now scrubbed through the telemetry redactor before serialization, on both the JSON and protobuf paths, matching the metric exporter - an attribute value holding a bearer token, password, or API key no longer reaches the collector verbatim. Per-row data residency, previously enforced only at the structured query builder, is now enforced on the three paths that bypassed it: raw SQL writes, read-replica fan-out, and backup export. Every CREATE TABLE / ALTER TABLE the schema reconciler and the DSR store emit now passes through the same single-statement gate the query builder uses. The DPoP middleware now requires its replay store at mount time instead of silently mounting a proof-of-possession gate that performed no replay check. And session rotation re-keys the device fingerprint to the new session id, so a rotated session stays bound to its device instead of falsely reporting drift on the next request.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "OTLP exporter redacts span, event, and resource attribute values before egress",
-          "body": "Span, span-event, and resource attributes were serialized to the OTLP collector verbatim on both the JSON and protobuf encodings - the metric exporter scrubbed its attributes through the telemetry redactor, but the span exporter did not. An attribute value carrying a secret or PII (a bearer token in `authorization`, a `password`, an `api_key`) was therefore shipped in clear to whatever collector the deployment points at (CWE-532). Every attribute-map encoder now runs each value through `b.observability.redactAttrs` (default composes `b.redact.redact`, dropping any attribute whose redactor throws) before the wire payload, so telemetry is redacted like the log and audit egress paths. The new `b.observability.redactAttrs(attrs)` is available for operators building custom exporters."
-        },
-        {
-          "title": "Per-row data residency is enforced on raw writes, read replicas, and backups",
-          "body": "Per-row residency was enforced only at the structured query builder. Three paths reached storage or left the deployment without it: raw SQL writes (`b.db.runSql` / `b.db.prepare().run()`, INSERT and UPDATE forms) bypassed the local residency check entirely, so a cross-border row could be written under a regulated posture with no refusal; read-replica fan-out dropped the row-residency tag, routing a regulated read with no row region identified to a residency-tagged, non-cross-border replica with no check; and `b.backup.create`'s residency check compared only the single deployment region to the destination, blind to a per-row-residency table that admits rows from several regions. Raw writes now parse the target table and residency value and apply the same gate the builder does; the replica read now fails closed when the row region is unidentified; and backup now emits a per-row cross-border advisory for any declared residency table whose admitted regions differ from the backup destination."
-        },
-        {
-          "title": "Schema and DSR DDL routes through the single-statement gate",
-          "body": "The CREATE TABLE / ALTER TABLE statements emitted by the schema reconciler and the DSR ticket store were assembled and run without the single-statement / NUL / unterminated-quote / unbalanced-paren gate that every query the builder emits already passes. That gate is now a shared check both the builder's catalog emitter and the schema/DSR DDL path call, so a terminator, comment marker, or unbalanced quote that reached a DDL fragment is refused at emit time on every backend."
-        },
-        {
-          "title": "DPoP middleware requires its replay store at mount time",
-          "body": "`b.middleware.dpop` documented `replayStore` as required, but the factory read it optionally and gated the jti-replay check behind its presence - omitting it mounted a proof-of-possession gate that performed no replay check, so a captured DPoP proof could be replayed indefinitely (RFC 9449 §11.1). The middleware now requires the store at config time: a missing store, or a store lacking `checkAndInsert`, throws when the middleware is created instead of failing open at request time. The low-level `b.auth.dpop.verify` primitive keeps `replayStore` optional for advanced callers that track jti themselves."
-        }
-      ]
-    },
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "Session rotation re-keys the device fingerprint to the new session id",
-          "body": "A session's optional device fingerprint is keyed to its session id, so that a stolen database cannot replay the binding. `b.session.rotate` moved the session id but left the stored fingerprint keyed to the old id, so the next `verify` recomputed the fingerprint against the new id and mismatched - reporting a false `fingerprintDrift` (which destroys the session under strict operators, logging the user out on every rotation) or silently breaking the binding. Rotation now re-keys the fingerprint to the new session id from the live request: pass the same `{ req, fingerprintFields }` to `rotate`. A fingerprint-bound session rotated without `req` now throws, because the binding cannot otherwise follow the new id; unbound sessions are unaffected."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.5.json

@@ -1,22 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.5",
-  "date": "2026-06-12",
-  "headline": "Legal-hold and subject-restriction PII is sealed at rest, and a guard's compliance-posture forensic and runtime caps are applied on its default gate",
-  "summary": "This release closes two data-protection gaps. The legal-hold registry and the subject-restriction flag stored their free-text fields - the legal basis, custodian, ticket citation, and restriction reason that link a data subject to a legal matter - in clear, because those local tables were written through a raw SQL path that bypassed the structured builder's at-rest sealing. Those columns are now sealed on write and unsealed on read, the same way the DSR ticket store already seals subject identifiers. Separately, a content guard built on the standard gate contract and gated with a compliance posture (for example b.guardCidr.gate({ compliancePosture: \"hipaa\" })) silently dropped that posture's forensic-snapshot cap and the profile's runtime cap, because the default gate passed the caller's raw options straight to the gate builder instead of resolving the profile and posture first - so a regulated-posture refusal carried no forensic evidence. The default gate now resolves the profile and posture before building the gate, matching the hand-written guard gates.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "Legal-hold and subject-restriction PII is sealed at rest",
-          "body": "`b.legalHold`'s `_blamejs_legal_hold` registry stored the hold reason, custodian, placed-by, and citation in clear, and `b.subject.restrict`'s `_blamejs_subject_restrictions` stored the restriction reason in clear - free text that ties a data subject to a litigation hold or an Art. 18 processing restriction. Those rows were written through a raw `sql.insert` + `prepare().run()` path that bypassed the structured builder's automatic field sealing (the subject-restrictions table even declared the field as sealed, but the raw write never applied it). Both now seal those columns on write and unseal on read through `cryptoField`, so the legal-basis and custodian text is encrypted at rest under the deployment's vault key. Pre-existing plaintext rows continue to read correctly (the unseal path passes through an already-plaintext value)."
-        },
-        {
-          "title": "A guard's default gate applies its compliance-posture forensic and runtime caps",
-          "body": "A guard built on `b.gateContract.defineGuard` with the standard gate (no bespoke gate) and gated with a compliance posture dropped that posture's `forensicSnippetBytes` cap and the profile's `maxRuntimeMs` cap: the default gate passed the caller's raw options straight to the gate builder, which reads those caps directly, but the values live on the resolved profile and posture, not the raw options. The effect was that a regulated-posture refusal captured no forensic snapshot (the cap defaulted to 0, i.e. disabled) and the check ran without the profile's runtime bound. The default gate now resolves the profile and posture before building the gate - matching the hand-written guard gates - so `gate({ compliancePosture: \"hipaa\" })` applies the posture's forensic cap and the profile's runtime cap as documented."
-        }
-      ]
-    }
-  ]
-}

package/lib/vendor/blamejs/release-notes/v0.15.6.json

@@ -1,59 +0,0 @@
-{
-  "$schema": "../scripts/release-notes-schema.json",
-  "version": "0.15.6",
-  "date": "2026-06-12",
-  "headline": "Closes SAML and OIDC assertion-replay windows, bounds SSE memory under a slow client, restores at-least-once delivery for a crashed outbox publisher, makes sealed-column membership queries work, ships JOSE-conformant SD-JWT signatures, and adds a URL canonicalizer for SSRF-safe comparison",
-  "summary": "A security and correctness release. On the identity surface: a SAML Response whose Bearer (or Holder-of-Key) SubjectConfirmation omits NotOnOrAfter is now rejected instead of accepted as fresh-forever, and the OIDC ID-token verifier no longer lets a caller disable expiry validation on a normal token - the exp bypass is restricted to back-channel-logout tokens and bounded by an issued-at freshness floor. SD-JWT-VC ES256/ES384 signatures are now emitted as JOSE raw r||s, so credentials this issuer signs verify in conformant wallets and verifiers. A new b.safeUrl.canonicalize (and b.ssrfGuard.canonicalizeHost) collapses obfuscated host and IP forms to one canonical string so allowlist and SSRF comparisons can't be bypassed by encoding tricks. On the reliability side: server-sent-event channels now cap their per-connection outbound buffer and evict a stalled client instead of growing the heap without bound; the outbox reclaims a job left in-flight by a publisher that crashed mid-delivery; the background worker pool no longer drops a task queued behind one that timed out; a retention preview no longer rewrites the whole database file; an equality / membership query on an encrypted column now hashes each candidate (membership queries previously failed outright); and the on-read re-hash of a legacy lookup digest now runs on Postgres and MySQL handles, not only SQLite.",
-  "sections": [
-    {
-      "heading": "Security",
-      "items": [
-        {
-          "title": "SAML SubjectConfirmation without NotOnOrAfter is rejected",
-          "body": "`b.auth.saml` SP response verification treated the `NotOnOrAfter` attribute on a Bearer SubjectConfirmationData as optional: a confirmation that omitted it was accepted with no upper bound on the assertion's freshness - a captured assertion replayable indefinitely. SAML 2.0 Web Browser SSO Profile §4.1.4.2 requires Bearer confirmations to carry NotOnOrAfter. `verifyResponse` now rejects a confirmation that is missing NotOnOrAfter, has an unparseable value, or is expired; the Holder-of-Key path (Profile §3.1) is hardened the same way, including the previously-accepted unparseable-value case."
-        },
-        {
-          "title": "ID-token expiry can no longer be disabled on a normal token",
-          "body": "`b.auth.oauth`'s `verifyIdToken` honored a `skipExpCheck` option with no constraint, so any caller could verify an expired - or replayed - ID token. That option exists only for OIDC Back-Channel Logout tokens, which carry no `exp`. It is now self-guarding: `verifyIdToken` rejects `skipExpCheck` (`auth-oauth/skip-exp-check-not-allowed`) on any token that lacks the back-channel-logout event claim, and even for a logout token it enforces an `iat` freshness floor (`auth-oauth/logout-token-stale`). The internal logout path is unaffected."
-        },
-        {
-          "title": "Server-sent-event channels bound their outbound buffer",
-          "body": "An SSE channel wrote to the response with no regard for backpressure and no cap on buffered bytes, so a single stalled client could make the server buffer events until the heap was exhausted (a memory-exhaustion denial of service). Each channel now tracks its unflushed-byte count and, past a per-channel cap (`maxBufferedBytes`, default 1 MiB), closes the connection and throws `sse/backpressure` - evicting the slow consumer instead of buffering without limit. A client that keeps up is never affected."
-        },
-        {
-          "title": "URL and host canonicalizer for SSRF-safe comparison",
-          "body": "New `b.safeUrl.canonicalize(url, opts?)` and `b.ssrfGuard.canonicalizeHost(host)` return the canonical, comparable form of a URL or host: scheme and host lowercased, IDN hosts emitted as their punycode A-label (a confusable / mixed-script host is rejected), every base of an IP literal (decimal, octal, hex, dotted, IPv4-mapped and zero-compressed IPv6) collapsed to one canonical address, default ports stripped, trailing-dot hosts normalized, and path percent-encoding normalized per RFC 3986. Use it to build host allowlists, deduplicate URLs, or compare a fetch target so an allowlist check can't be bypassed by encoding the same address a different way."
-        }
-      ]
-    },
-    {
-      "heading": "Fixed",
-      "items": [
-        {
-          "title": "SD-JWT-VC ES256 / ES384 signatures are JOSE-conformant",
-          "body": "`b.auth.sdJwtVc` signed and verified ES256 / ES384 credentials with node:crypto's default DER ECDSA encoding instead of the raw r||s (`ieee-p1363`) form JOSE and EUDI wallets require, so a credential this issuer signed was rejected by conformant verifiers and the library rejected conformant holders' key-binding JWTs. The issuer JWT and the holder KB-JWT now both sign and verify with `ieee-p1363`, matching the rest of the framework's JOSE signers."
-        },
-        {
-          "title": "Membership queries on an encrypted column now work",
-          "body": "Querying an encrypted (sealed) column with `IN` / `$in` - `b.db.from(table).whereIn(\"email\", [...])` or `b.db.collection(table).find({ email: { $in: [...] } })` - threw, because the sealed-field-to-derived-hash rewrite passed the whole candidate array to the hash lookup as a single value. Each candidate is now hashed individually and matched against both its active keyed digest and its legacy digest, so membership queries on an encrypted column return the right rows, including rows written before the lookup-hash default changed."
-        },
-        {
-          "title": "A timing-out background task no longer drops the task queued behind it",
-          "body": "When a `b.workerPool` task timed out or its worker errored, the slot was returned to the idle pool and drained one moment before it was marked for recycling, so a task queued behind it could be dispatched to the worker about to be terminated - and came back as `workerpool/worker-exit` (or hung) instead of running. The slot is now marked recycling before the queue is drained, so the queued task waits for the replacement worker."
-        },
-        {
-          "title": "The outbox recovers a job stranded by a crashed publisher",
-          "body": "`b.outbox` claims a row by flipping it to in-flight, but the claim scan only selected pending rows, so a publisher that crashed between claiming a row and recording delivery left that row in-flight forever - the event was silently dropped, breaking at-least-once delivery. The outbox now stamps each claim with a timestamp and, at the start of every poll, returns any in-flight row older than the claim lease (`claimReclaimMs`, default 5 minutes) to the pending pool so it is delivered. An existing outbox table gains the new column automatically."
-        },
-        {
-          "title": "A retention preview no longer rewrites the whole database",
-          "body": "Previewing a retention rule with `b.retention` (`run(name, { dryRun: true })` or the `retention preview` command) ran a full database VACUUM for every candidate row under a regulated posture (gdpr / hipaa / and similar), because the per-row erase - which schedules the vacuum - ran before the dry-run check. A preview now computes what it would erase without touching the database; the vacuum runs only on a real erase."
-        },
-        {
-          "title": "On-read lookup-digest upgrade runs on Postgres and MySQL",
-          "body": "When `b.cryptoField.unsealRow` re-hashed a legacy lookup digest to the current keyed form and persisted it, the UPDATE was always built for SQLite, so on a Postgres or MySQL handle the durable rewrite quoted identifiers for the wrong dialect and silently no-opped - the legacy digest stayed on disk and the migration never completed off SQLite. The rewrite now uses the handle's own dialect."
-        }
-      ]
-    }
-  ]
-}