@blamejs/core 0.18.51 → 0.18.54

package/CHANGELOG.md

@@ -8,6 +8,191 @@ upgrading across more than a few patches at a time.
 
 ## v0.18.x
 
+- v0.18.54 (2026-08-24) — **Outbound mail could not be sent, and DANE refused exactly the peers that publish TLSA.** `b.mail.send.deliver` reached for a transport name nothing exports, so without an explicit `transportFactory` every recipient deferred 4.4.4 with no socket ever opened. The transport it should have reached discarded `message.raw` and rebuilt the body, so a message that did get through arrived empty. Under `policy.dane: "enforce"`, a peer that published TLSA records was refused while a peer that published none was delivered to, and the records that were fetched authenticated nothing. Alongside those: `b.mailStore` over `b.db` committed a write and then threw, POP3 and ManageSieve treated a SASL challenge as an authentication failure, `mx` gained the RCPT-time recipient check that made `550 5.1.1` reachable, and `b.mail.inbound.verify` now evaluates the ARC chain its own documentation had been promising.
+
+Three of these are worth upgrading for ahead of the rest. A pipelined SASL response was refused and the round already in flight was left running, so it could still authenticate the connection whose response had just been refused — on all four listeners. The SMTP client decided how to frame and whether to send a message from the capabilities advertised before STARTTLS, and never discarded them, so an extension line injected on the cleartext leg still steered decisions made under TLS. And DKIM and ARC signed a UTF-8 re-encoding of the message rather than its own octets, which for ordinary 8-bit mail meant a valid signature over bytes the sender never wrote, returned to the caller in place of the message. **Added:** *`b.codepointClass.hasPairWhere`* — The scan for a two-character construct — a path traversal opening on `..`, a regex inline-flag group on `(?`, a YAML merge key on `<<` — was written out by hand in each screen that needed one. The literals and the follow-on tests differ, the scan does not, and three copies of a scan are three places for an off-by-one to live.
+
+`hasPairWhere(text, first, second, accept)` calls `accept(i)` at every position where `first` is followed by `second`, and answers whether any of them counted. It reads the string one character at a time, which is what a guard needs: asking the question with a pattern would be a screen running the construct it screens over hostile text.
+
+`b.guardFilename`, `b.guardRegex` and `b.guardYaml` now route through it. · *`b.codepointClass.firstLineInjectionCharOffset`* — Returns the index of the first CR, LF or NUL in a string, or `-1`. These three end a line-oriented protocol record, so a value carrying one splits the record it is written into and the remainder is read as a second, attacker-chosen line. Four call sites had hand-rolled the same scan, which is how a fifth could go without it; they now share this one.
+
+Deliberately narrower than `firstControlCharOffset`, which refuses every C0 control and DEL: a caller adopting this does not silently start refusing values it used to accept. **Changed:** *Sample tokens and key placeholders no longer look like secrets to a default scanner* — A default-ruleset secret scan of `lib/` reported eleven findings, all inside comment blocks or documentation fixtures, none of them key material. The cost landed on anyone vendoring the tree: either a blanket allowlist over the whole library, which then hides a real finding, or a hand-triage repeated on every refresh.
+
+Sample JWTs are now built from their header and claims rather than pasted as literals, which also shows a reader what the token says instead of an opaque blob; the PEM placeholder is written without the `BEGIN` framing; and the two-key recipient shape is named in prose. CI now also scans `lib/` with the default ruleset and no configuration, which is the scan a consumer actually runs. **Fixed:** *`b.mail.send.deliver` can open a connection* — The default transport was read as `b.mail.smtpTransport`, a name nothing defines. The export is `b.mail.transports.smtp`. So the default was `undefined`, calling it threw, the throw was classified as a transient peer problem, and an operator who did not pass `transportFactory` got every recipient deferred `4.4.4` forever with no socket ever opened.
+
+The option is documented as an override, which means the default is the path most callers take. · *The SMTP transport sends the message it was given* — `send()` discarded `message.raw` and rebuilt the body from the structured fields. A message composed elsewhere and handed over as bytes therefore arrived as an empty `multipart/alternative`, and the peer answered `250`, so the sender had every reason to believe it had been delivered.
+
+Raw bytes now reach the wire verbatim, which took three things beyond keeping the buffer: the message is no longer decoded as UTF-8 on the way through (that replaced every invalid sequence, corrupting exactly the binary payloads this transport detects), the DATA terminator no longer appends a CRLF the message already ended with (which inserted a blank line and broke any signature over the body), and a body requiring BINARYMIME is refused rather than sent under DATA framing, which cannot carry one.
+
+BINARYMIME was in fact unreachable: the transport identifies a binary body by the NUL in it, and the outbound smuggling screen refused the message for containing a NUL. That screen now covers the header block for such a message, where the injection class actually lives.
+
+The wire-capability negotiation reads the raw bytes too: `SMTPUTF8` is decided from the raw header block, `8BITMIME` from the whole message, and `BINARYMIME` from a NUL anywhere in it, so a raw message still negotiates the extensions its content requires instead of being sent under the wrong ones. · *DANE authenticates the peer instead of refusing it* — Two defects on one path, and together they inverted what DANE is for.
+
+The TLSA lookup never passed the DNSSEC acknowledgement that `dane.tlsa` requires under RFC 7672 §1.3, and `deliver` exposed no option that could supply it. A peer publishing no records took an earlier return and was delivered to; a peer that published records reached the check and was refused. The operator who did the work of publishing TLSA was the one who stopped receiving mail.
+
+Separately, `dane.verifyChain` shipped and nothing called it, so on the path where the lookup did succeed the certificate the peer presented was never compared against the records just retrieved. `dane: "enforce"` meant "fail if the lookup did not go well", not "authenticate the peer".
+
+`policy.dnssecValidated: true` is now the operator's statement that their resolver validates, and `dane: "enforce"` requires it at `create()` rather than failing per-peer later: an un-asserted resolver is a property of the sender, not of any recipient. Under `"opportunistic"` without it the records are unusable, so none are fetched. The records that are fetched go to the transport, which matches the peer's certificate chain against them once the handshake completes and refuses the send on a mismatch, on both the implicit-TLS and STARTTLS paths.
+
+A DANE failure now defers instead of bouncing. It says the HOST could not be authenticated, and the ordinary cause is a certificate rollover part-way through DNS propagation, which resolves itself. Classified permanent it also skipped every remaining MX, so one host mid-rollover turned deliverable mail into a report. MTA-STS and REQUIRETLS refusals stay permanent.
+
+The lookup goes through the resolver the operator configured on `deliver`, because `dnssecValidated` is a statement about that resolver: fetching the records through the system resolver instead would let a non-validating path supply them under a validated banner. A configured resolver that cannot answer TLSA is refused rather than bypassed.
+
+Under DANE-EE and DANE-TA the TLSA record is the trust anchor and PKIX path validation is not performed (RFC 7672 §3.1.1), which is what lets a self-signed MX certificate work at all. Leaving the WebPKI check on rejected such a peer during the handshake, before its certificate could be compared against the records that authenticate it, so every DANE-only MX was deferred while matching its own records exactly. PKIX-TA and PKIX-EE record sets keep the WebPKI check.
+
+`b.mail.transports.smtp` takes the records directly as `dane: [tlsaRecord, ...]` for operators driving it themselves. · *`b.guardYaml` no longer reads a block scalar's contents as structure (#642)* — Two lines inside a block scalar that merely look like `key: value` were reported as a duplicate key. A `script: |` block holding JavaScript with `owner: ctx.owner` on two lines was refused, and there is no mapping inside a block scalar for those keys to collide in.
+
+0.18.53 introduced a lexer for exactly this and moved the tag, anchor and alias scans onto it. The duplicate-key screen was left reading the raw source, so the same root survived one release in a different screen.
+
+Sweeping that root found a second: the merge-key screen also read raw source, so `<<: *base` written in a comment, in a quoted value, inside a block scalar, or on a plain scalar's continuation line was reported as a merge key. Both screens now ask the lexer, which gained `lexLines` — the mask and the node-start offsets from one pass.
+
+The question it asks is "could a node begin here?", not "is this well-formed structure?", because `<<:*d` with no space after the colon is not a valid mapping entry and is still reported: that is the shape being smuggled past a parser variant that reads it as a merge. Asking it that way covers every region that is literal text at once. Enumerating those regions instead was tried first and left six of the eight open, which is why the lexer answers it rather than the screen. · *DKIM and ARC sign the octets they were given (#644)* — RFC 6376 §3.4 signs a canonicalized octet stream. `b.mail.dkim` took the message as a JavaScript string, canonicalized characters, and hashed the UTF-8 re-encoding of the result — so the octets it signed were `utf8(decode_utf8(original))`, equal to the original only when the original was already valid UTF-8. 128 of the 256 single-octet values do not survive that round trip.
+
+Signing was the worse half. `sign()` returns the message with the signature prepended, so a caller relaying the return value relayed corrupted bytes carrying a signature that verifies at the receiver: the corruption arrived authenticated, and the octets the sender wrote were gone from the relayed copy. On the receive side a legitimate 8-bit message verified as a DKIM fail, leaving DMARC to fall back to the SPF identity — and to nothing at all once the message had been forwarded.
+
+`sign()` and `verify()` now accept a `Buffer` and hash its octets, returning what they were given: a Buffer for a Buffer, a string for a string. A string argument keeps its present meaning, that the octets are its UTF-8 encoding, so existing signatures are unchanged. `b.mail.arc.sign` and the ARC verifier take the same treatment, since a seal covers a message the same way a signature does, and `b.mail.inbound.verify` passes a Buffer message through to both instead of decoding it. Both signers resolve the message through one shared function, which is what stops them answering "which bytes is this message" differently.
+
+§3.4 canonicalization touches only SP, HTAB, CR and LF, none of which can appear inside a multi-byte UTF-8 sequence, so this is byte-for-byte identical to the previous behaviour on every valid-UTF-8 message.
+
+The message is two views and they are not interchangeable, which is the part worth carrying to the next module that holds mail: a signature covers the bytes on the wire, and an address is characters. `b.mail.inbound.verify` reads the From header as text so an RFC 6531 local part still aligns against a DMARC record, and reads the same message as octets for DKIM and ARC. · *`b.mail.server.imap` returns a message's own octets (#645)* — Every FETCH response was assembled as a string and written with `socket.write`'s string overload, which encodes as UTF-8. RFC 9051 §4.3 makes a literal a counted sequence of octets and §6.4.5 makes `BODY[]` the message, so a message octet that is not valid UTF-8 could not survive: a `BODY[]` of a 69-octet message announced 71 and sent 71, none of them the stored bytes.
+
+The two numbers in one response disagreeing is what a client cannot work around — the literal count is what tells it where the response ends, so a count that does not match the payload leaves it reading the next response as part of this one. A `<start.count>` window was affected on ordinary UTF-8 mail too, since §6.4.5 puts no alignment condition on the window and a boundary falling inside a character took three octets to deliver two, none of them the ones requested.
+
+`fetchRange` may now return a row's `payload` as a Buffer, and should whenever the row carries message content; the response is framed and written as those octets. A string payload is unchanged and remains right for rows carrying only attributes. Response strings keep their UTF-8 encoding, which is what §5.1 asks for in the one place a response string is not ASCII: a mailbox name under UTF8=ACCEPT.
+
+A NOTIFY push carries message content too, and built its FETCH response from a second copy of the same code — so it corrupted identically. Both now go through one builder, which is what stops the two answers from diverging again.
+
+The same mailbox over POP3 already returned the message intact, so which protocol an account holder used decided whether they received their own mail. · *Raw 8-bit mail is refused when the peer does not offer 8BITMIME* — A body carrying octets with the high bit set needs 8BITMIME (RFC 6152 §3). When the peer did not advertise it, the framing choice fell through to `7BIT` and the transport wrote those octets anyway — declaring one thing and sending another. A receiver is then free to reject the transaction, or to strip the eighth bit and deliver a corrupted message, which for a signed message means a signature that no longer matches what arrived.
+
+The send is now refused with `mail/8bitmime-not-advertised` before DATA or BDAT opens, naming the two ways out: encode the body as quoted-printable or base64, or deliver through a peer that supports the extension. A peer that does advertise 8BITMIME is unaffected and still receives `BODY=8BITMIME`.
+
+The BINARYMIME sibling of this already refused. Marking a body as needing an extension and then shipping it without one is the same defect either way, and only one of the two was closed. · *`b.mail.arc.evaluate` agrees with `b.mail.arc.verify`* — `evaluate` answers `verify`'s question plus a trust decision, so the two must never disagree about whether a chain passes. They did, for any message containing a non-ASCII character: `evaluate` resolved the message to its wire form and then handed that form to `verify`, which resolved it again. The second pass read the wire representation as text and re-encoded it, so the octets checked were no longer the octets sealed — the chain passed `verify` and failed `evaluate`, and a trusted sealer went unrecognised.
+
+The conversion is idempotent on octets and not on text, so the internal hand-off now passes octets. That contract is written at the function both paths share, because the two views of a message are easy to mix up and the mistake is invisible on ASCII. · *A refused pipelined SASL response can no longer authenticate the connection* — A client can put several lines in one TCP segment, so two SASL responses can arrive together. The shared exchange refuses the second one, because a client that answers before it has been asked is not following the protocol — but it refused it and left the verifier already running for the first response alone.
+
+That verifier could then resolve `{ ok: true }` and authenticate the connection whose response had just been refused, so the refusal decided nothing. It could also emit a challenge after the listener had answered and cleared its state.
+
+The round in flight is now abandoned rather than merely reported: its completion, success or throw, reaches no callback. The exchange also stays dead afterwards, so a listener that does not tear the connection down cannot have it become authenticable again once the violation has scrolled past. IMAP, submission, POP3 and ManageSieve all drive their SASL exchange through this, so all four were exposed. · *SMTP capabilities are read only from the EHLO that follows STARTTLS* — `b.mail.smtpTransport` decided whether a message could be sent, and how it would be framed, from the capabilities advertised on the cleartext leg. The pre-upgrade extension list was also never discarded, so the set in force after the handshake was the union of both legs.
+
+RFC 3207 §4.2 requires the opposite: a client MUST discard every service extension learned before the upgrade, because the cleartext leg is exactly what a network attacker can rewrite. An injected extension line steered decisions made under TLS — a `SIZE` cap that refuses every message, a `CHUNKING` that selects a framing the real peer never offered.
+
+It read as an over-refusal too. Servers commonly advertise `CHUNKING` and `BINARYMIME` only once TLS is up, so a binary message was refused before `STARTTLS` was even sent, naming an extension the peer does advertise.
+
+Every capability-dependent decision now runs on the post-upgrade EHLO alone: the SMTPUTF8 and BINARYMIME requirement checks, the `SIZE` pre-check, and the BDAT-versus-DATA choice. Implicit-TLS transports are unaffected, since their first EHLO is already inside TLS. · *A deferred recipient names the receiver that refused (#643)* — `b.mail.send.deliver` returned deferred recipients with a reason and a retry budget and no `mxHost`, while delivered ones carried it. A queue view therefore read "deferred, retry in 15 minutes" with no peer attached, and a domain with several MX hosts gives an operator no way to tell which one refused — which is what decides whether to wait, to contact that receiver, or to look at their own transport security against that host.
+
+Deferred recipients now carry `mxHost`. It is `null`, rather than absent, when the deferral happened before any host was reached (an MX lookup that failed), so a consumer can tell "no peer was reached" from "the peer was not recorded". · *`b.guardFilename` honours `adsPolicy: "allow"` (#623, reopened)* — `sanitize`, `validate` and the gate accepted `adsPolicy: "allow"`, documented it as opting out of the NTFS alternate-data-stream check, and refused anyway. An operator who set every documented opt-out still could not store `12:30 notes.txt` — a timestamped note, not an attack.
+
+0.18.52 addressed the same report by making the refusal message explain why the option did not apply there. That reads as a considered boundary until you meet a filename like that one: the check is lexical, a colon is an ordinary filename character on Linux and macOS, and the shape of an attack is identical to the shape of a timestamp. Only the operator knows which filesystem the name will be written to, which is why the option exists.
+
+The option now opts out at every door that reads it, including strip mode and the validate finding. The default is unchanged and still refuses, in all three profiles — reaching the name requires setting `reservedCharPolicy: "allow"` as well, because a colon is also a Windows reserved character.
+
+This also corrects where the rule sits: an ADS suffix was treated as a floor no configuration could lower, alongside NUL bytes, `..` traversal and UNC prefixes. Those three are unsafe on every filesystem. A colon is not, and the rule belongs with `reservedCharPolicy` and `reservedNamePolicy`, the framework's other Windows-specific checks, all default-on with an opt-out.
+
+Note for anyone tracking versions: 0.18.52 was tagged but never published — its publish workflow failed and the tag is immutable, so npm goes 0.18.51 to 0.18.53. Nothing from it was lost; 0.18.53 carries it. · *`b.network.dns.resolver` queries the DoH endpoint you configured* — `b.network.dns.useDnsOverHttps({ url, ca })` sets where DNS goes, and `b.network.dns.resolver.create()` ignored it: its wire-format lookup addressed a public provider that was hardcoded in the source. A deployment that had pointed DoH at its own resolver — for split horizon, for privacy, or because that resolver validates DNSSEC — still had every `resolver.query()` leave for the public one.
+
+That also hollowed out the DANE assertion above: `policy.dnssecValidated: true` describes the operator's resolver, and the queries were not reaching it. The endpoint and its CA are now read per lookup, so a later `useDnsOverHttps` reaches the next query rather than a handle staying pinned to whatever was configured when it was built.
+
+The configured request method travels with it. RFC 8484 §4.1 allows GET and POST, an endpoint may accept only POST, and `useDnsOverHttps({ method: "POST" })` says so — honouring the URL while sending GET leaves that endpoint unusable. With no method configured the choice falls to URL length, using the same threshold the rest of the DNS module uses rather than a second copy of the number.
+
+`b.network.dns.activeDohEndpoint()` reports the endpoint in force, or `null` when the deployment is on DoT or the system resolver. · *`b.mail.send.deliver` reads MX records from the framework's own resolver* — The MX normalisation accepted `{ exchange, priority }` on each record, and `b.network.dns` decodes an MX RR into `{ ..., decoded: { preference, exchange } }`. Composed with the framework's own resolver — the one the DANE documentation points operators at — every MX host came out `undefined`, and the first thing to touch one failed the delivery.
+
+A comment above the normalisation asserted the flat shape, and every test agreed with it, because every test supplied a hand-written resolver returning exactly what the comment claimed. The disagreement is only visible against a real DNS response, which is what the new `mail-dane-authentication` integration test uses. · *`b.mailStore` over `b.db` no longer commits a write and then throws* — `appendMessage` and `hardExpunge` selected a transaction shape by testing `typeof backend.transaction === "function"`, which is true of both conventions and distinguishes neither. `b.db.transaction(fn)` runs `fn` and returns its result; better-sqlite3's returns a wrapper to call. Against `b.db` the callback ran, the write committed, and the framework then tried to call the returned value and threw. The caller saw a failure over a completed write.
+
+Both conventions are now honoured by observing what actually happened: if the callback ran, the result stands; if a function came back instead, it is called. A backend that does neither is refused rather than left to commit unatomically. · *`deliver` accepts the null reverse path a DSN requires* — RFC 5321 §4.5.5 requires a bounce to be sent from the null reverse path, `MAIL FROM:<>`, and the SMTP transport already turns `""` into exactly that. `deliver` refused `envelope.from: ""` as missing, so the one value a DSN must use was the one value it would not accept. Its own documented DSN example sent the report back with the original sender's address, which is the loop RFC 5321 §4.5.5 exists to prevent.
+
+`""` is now a value rather than an absence, and no DSN is generated for a message that already carries the null sender. · *POP3 and ManageSieve honour a SASL challenge* — An operator verifier may answer `{ pending: true, challenge }` to ask for another round trip, which IMAP and submission honoured. POP3 and ManageSieve called the verifier once, passed no `step`, and dropped a pending verdict into the branch that writes an authentication failure. That branch also spent the client's authentication-failure budget, so a normal protocol round trip consumed the defence that exists to slow down credential guessing.
+
+Both now run the exchange the way the other two listeners do, through one shared step runner rather than a fourth copy of the loop. The client's reply reaches the verifier instead of the command table, `*` cancels without costing budget, and a genuinely failed exchange still charges it.
+
+ManageSieve also accepts the literal form of a response. RFC 5804 §1.2 makes a string either quoted or a literal (`{N}` or `{N+}` followed by N bytes), and a SASL response is base64 and can be long, which is exactly when a client reaches for the literal. The initial response accepted both; the continuation accepted only the quoted form, so the literal marker itself was read as the response and its bytes as another one. · *`b.mail.server.mx` can refuse an unknown mailbox* — Recipients were decided from `localDomains` alone, so a local domain accepted every local part and the application first met the recipient at the agent handoff, after `354` and after the whole message body. From there the only answers were `250`, which tells the peer the message arrived and leaves the receiver owing a report, or `451`, which tells a peer holding a permanent condition to keep retrying. `550 5.1.1` was not expressible.
+
+`opts.recipientPolicy` runs at RCPT TO, in the same shape the submission listener already had: `{ ok: false, reason }` refuses `550 5.1.1` with the reason, and a throw defers `451 4.7.1`, because a directory that cannot be reached is not a verdict about the mailbox. Refusals charge the same per-IP recipient-failure budget as a relay refusal, since the difference between `250` and `550` is a mailbox-existence oracle. · *A recipient-refusal reason can no longer forge a second SMTP reply* — Both mail listeners wrote an operator policy's refusal reason straight into the `550` line. That reason is rarely the operator's own words: a directory wrapper answers "No such user: <address>", and the address came from the peer. A CR or LF in it ended the reply line early and everything after was read by the peer as a second server response, so a refusal could deliver a forged acceptance.
+
+The reason now goes through a check that returns it when it cannot split a line and a fixed fallback when it can, so the recipient is still refused and only the prose is replaced. This covers the submission listener's existing `recipientPolicy` as well as the MX listener's new one, and a detector keeps a third from appearing.
+
+The same class is closed on the SASL challenge that the IMAP, POP3, ManageSieve and submission listeners write during a multi-step exchange. There the exchange fails instead of substituting, because a challenge that cannot be sent verbatim cannot authenticate anyone. · *`b.mail.inbound.verify` evaluates ARC* — The module documented `b.mail.arc.verify` among the calls the receiver pipeline composes, and the pipeline never made it. A consumer wiring `b.mail.server.mx` as documented got SPF, DKIM and DMARC, no `arc` field in the result, no `arc=` method in the emitted `Authentication-Results`, and nothing at run time to say so.
+
+The chain is now evaluated and reported. It is treated as evidence rather than as a gate: a malformed chain is a `fail` verdict and the pipeline continues, because refusing mail over a defect in an intermediary's headers punishes the wrong party. "none" is reported like any other verdict, so a receiver reading the header can tell a chain that was checked and found absent from a receiver that does not check. · *`safeResolveTxt` reports absence as absence* — The guard listed the resolver's `ENOTFOUND` and `ENODATA` codes, and the DNS resolver reported every non-zero RCODE through one error code, so NXDOMAIN — the commonest form of "no record published" — arrived as a failure and threw.
+
+RCODE 3 now carries `resolver/nxdomain` and everything else stays `resolver/query-failed`. The distinction matters beyond this call: `b.mail.rbl` treated any lookup error as "not listed", so a SERVFAIL from a blocklist read as a clean verdict. It now accepts only genuine absence. · *`b.mail.helo` FCrDNS can pass* — The check calls `resolver.queryPtr`, which `b.network.dns.resolver.create()` did not expose. The call returned `undefined`, the resulting TypeError landed in a catch written for NXDOMAIN, and the check reported a clean "no reverse name" for every address it ever ran on. Every test passed throughout, because the only object with a `queryPtr` was the one in the test file.
+
+The resolver now provides `queryPtr`, and a resolver that does not is refused rather than read as a miss: "no reverse name" and "I could not ask" are different findings. · *`b.mail.agent.expunge` refuses a posture it cannot resolve* — The retention floor was resolved by indexing the floor table with a fallback to zero, so a misspelled posture, a capitalised one, or one the table does not carry all permitted an unbounded hard delete with no error. It also read through the prototype: posture `"constructor"` returned a function, which is truthy, so the fallback kept it and every age comparison against it was meaningless. A typo was refused where retention windows are computed and accepted at the one call that destroys mail permanently.
+
+It now resolves through `b.retention.complianceFloor`. No posture at all remains a legitimate zero-floor configuration; a posture that was supplied and is not understood is refused. · *`b.retention.complianceFloor` stops calling valid postures typos* — Absence from the retention-floor table was read as "not a posture", but that table holds only the subset of regimes carrying a regulator-mandated minimum. Most do not: GDPR Art. 5(1)(e) is storage limitation, the opposite of a floor. So 158 of the 169 postures `b.compliance.set` accepts were reported as misspellings, and an operator who set one could not compute a TTL at all.
+
+A posture the framework knows now resolves, to zero when it imposes no minimum. A name outside `b.compliance.KNOWN_POSTURES` still throws, and says which vocabulary it was measured against. · *`b.mail.server.imap` answers a literal with a real continuation* — RFC 9051 §7.5 defines a command continuation request as a line beginning with `+`. The listener wrote it as an untagged response, so the wire carried `* + Ready for literal data`. A conforming client waits for a `+` line, and `APPEND` never completed. The non-synchronizing route was closed too: the strict profile's guard refuses `LITERAL+` and `CAPABILITY` does not advertise it. · *`b.mail.server.jmap` can decline the WebSocket transport* — The RFC 8887 capability was advertised whether or not the consumer had wired the upgrade handler. The check that looked like an opt-out was not one: omit the key and the default added it, supply the key and the merge put it straight back. The only value that suppressed it was `undefined`, and only because `JSON.stringify` drops such keys.
+
+`webSocket: false` is now the answer, and it removes both the capability and the top-level `webSocketUrl` alias, so a client is not sent to an endpoint that cannot upgrade. · *`b.credentialHash.needsRehash` refuses an algorithm name it does not know* — `hash()` validated `opts.algo` against the algorithm table and threw on a name it did not recognise. `needsRehash()` read the same table with a fallback to the framework default, so a misspelling silently answered a different question than the caller asked: "is this row still the default?" rather than "is this row argon2id?", on a credential-rotation decision. It also read through the prototype, where `"constructor"` yielded a function that compares unequal to every real algorithm id. · *`b.ai.adverseDecision.wrap` refuses a legal basis it has no deadlines for* — `legalBasis` selects the statutory deadlines stamped on every adverse notice, and an unrecognised value fell back to `operator-defined`, whose deadlines are all null. One missing character in `gdpr-22` produced a notice asserting the subject has no right to an explanation, no right to human review and no right to appeal — the exact obligations Article 22 imposes, switched off silently, while the notice still recorded the misspelled basis as though it had been honoured.
+
+An operator whose regime the framework does not carry asks for `operator-defined` by name. · *`b.redact.classifyDefaults` refuses a prototype member as a classifier name* — The unknown-pattern check read `opts.extra[name]` through the prototype, so once a consumer supplied any extra pattern, `constructor` / `toString` / `valueOf` resolved to inherited functions and passed as known names. The scanner then met a function where a pattern spec belongs and threw an untyped error at scan time: a data-loss classifier failing at the moment it was asked to look, rather than refusing at boot. · *Two middleware counters no longer discard their own failures* — `b.middleware.bearerAuth` and `b.middleware.fetchMetadata` recorded their metrics through a call that throws on a misconfigured observability backend, inside the request path. Both now use the drop-silent emitter the rest of the framework's hot paths use, so a metrics problem cannot fail the request that triggered it.
+
+- v0.18.53 (2026-08-24) — **The YAML screens refused ordinary documents: a list of records, and an exclamation mark in a sentence.** `b.guardYaml.parse` refused any sequence whose items carry more than one key, which is the shape of nearly every list of records anyone writes. Separately, both `b.guardYaml` and `b.parsers.yaml` decided whether a `!`, `&` or `*` opened a tag, anchor or alias by looking at the character in front of it, so they reported one inside a quoted string, inside a block scalar's shell script, in the middle of a value, and inside a comment. `x: 1 # note !bang` was refused. Both screens now read the document's structure, through one scanner shared by the two modules. **Fixed:** *`b.guardYaml` no longer reports a duplicate key for a list of records* — Key uniqueness was tracked per indentation level, and a sequence-item line never reset that tracking. The second item's keys were therefore checked against the first item's, so every key except the one written inline with the dash was reported as a duplicate:
+
+```yaml
+steps:
+  - name: build
+    run: make
+  - name: test
+    run: make check
+```
+
+That document was refused with `duplicate key "run"`, and it has no duplicate key in it. Under `duplicateKeyPolicy: "reject"` — the strict profile's default — the parse threw.
+
+Each item of a sequence is now its own mapping, so a key may appear once per item. Two things that were already true stay true, and both are pinned by tests: a key repeated *within* one item is still a duplicate, and so is a key repeated in an ordinary mapping.
+
+The key written inline with the dash was being skipped entirely rather than tracked, so `- name: a` followed by `name: b` inside the same item went unreported. It is now tracked with the rest of its mapping. · *A tag, anchor or alias is recognised where it can actually appear* — `!`, `&` and `*` introduce a tag, an anchor and an alias only at a node start. Both YAML screens decided the question by looking at the preceding character — whitespace meant a sigil, anything else meant not — and that rule cannot tell a node start from the middle of a scalar. Every one of these was refused:
+
+```yaml
+x: "hello !world"      # a bang in a quoted string
+x: hello !world        # a bang in the middle of a value
+x: 1 # note !bang      # a bang in a comment
+x: |
+  echo !boom           # a bang in a shell script
+text: fish &chips      # an ampersand in prose
+```
+
+The two modules had separate implementations of the check and separate gaps. `b.parsers.yaml` masked quoted strings but copied comment text through verbatim and had no block-scalar handling, despite a note in it saying both were covered; `b.guardYaml` had none of the three. So a document refused by one was sometimes accepted by the other.
+
+Both now use one scanner that tracks where each character sits: inside a quoted scalar, a comment, a block-scalar body, a plain scalar, or in the structure. A sigil is reported only where it opens a node. Scalars that run across several lines are followed rather than read afresh, so neither the continuation of a quoted string nor of an unquoted value is mistaken for structure, and a `!` after the closing quote or the ending comma still is one.
+
+**What this changes for a document you already have:** a sigil inside a plain scalar is no longer reported. `text: this &notanchor` and `x: -&a` used to raise an anchor finding and no longer do. Neither declares an anchor — an anchor is a separate token — so nothing can reference it, and the amplification these findings exist to stop has no path through them. A merge key written without spaces, `<<:*d`, is still refused, by the merge-key screen rather than the alias one.
+
+`b.parsers.yaml` continues to refuse every real tag, anchor, alias and directive, and the strict profile of `b.guardYaml` continues to report them. · *The residency gate's raw-SQL timing check no longer depends on how busy the machine is* — The check that a padded raw `UPDATE` costs no extra parse time compared the padded call against an unpadded one and allowed 500ms between them. A difference of two timings carries the noise of both, and on a loaded runner the padded sample alone drifted past that allowance while the statement itself parses in a fraction of a millisecond.
+
+It now bounds the padded call on its own, and takes the fastest of fifteen samples rather than three. The defect it guards cost roughly seven seconds against 0.04ms once fixed, so the ceiling sits between the two behaviours with several orders of magnitude to spare rather than tracking the machine. The unpadded baseline is still measured and still printed, because a reader looking at a failure needs to know whether the box was slow or the parse was.
+
+- v0.18.52 (2026-08-23) — **A refusal that would not say why, and a currency gate that skipped the one pin able to move underneath it.** `b.guardFilename` refuses a filename carrying NTFS alternate-data-stream syntax whatever `adsPolicy` says, which is correct and was documented, but the refusal never mentioned the option — so a caller who set `"allow"` was left comparing their code against a message that said nothing about the setting they had changed. Separately, the pinned-actions currency gate could only see a `uses:` pinned to a commit SHA, so the one workflow reference pinned to a tag was absent from every run rather than reported, and its `--json` output had a human summary line after the document, so nothing could parse it. **Fixed:** *The NTFS-ADS refusal now says where `adsPolicy: "allow"` applies* — A filename carrying alternate-data-stream syntax (`report.txt:stream`) is refused by `b.guardFilename.sanitize`, `validate` and `gate` regardless of `adsPolicy`. That is deliberate: on Windows the write lands on a hidden stream of the base file rather than on a file anyone can see, so it is one of the shapes a filename guard always refuses. `adsPolicy` still takes `"allow"` because `verifyExtractionPath` honours it, for an operator deliberately extracting stream-suffixed entries into a root they chose.
+
+What was missing is that none of this was visible from the call site. The refusal said only that the name contained stream syntax, so setting `"allow"` and watching nothing change read as the option being broken rather than as it being scoped. The message now names the boundary, and the split is pinned by tests at all four entry points.
+
+One thing worth knowing if you go looking: a colon is also a Windows reserved character, so `reservedCharPolicy` refuses such a name before the ADS check is reached. Setting `adsPolicy` alone never changes the outcome for a name like `12:30 notes.txt` — `reservedCharPolicy` is the one governing it, and `"strip"` there yields `12_30 notes.txt`.
+
+This also records a change that shipped in 0.18.48 without being written down: before it, `sanitize` honoured `adsPolicy: "reject"` and so could be opted out of. It no longer can be, and there is no replacement value, because a stream-suffixed name has no safe repair. · *The pinned-actions currency gate could not see a tag-pinned workflow* — `check-actions-currency.js` matched a `uses:` line only when it was pinned to a 40-character commit SHA. A reference pinned to anything else matched nothing, was collected by nothing, and appeared in the run as neither current nor stale — absent, while the summary counted what it had looked at and read as a clean result.
+
+The pin that fell through is the one least able to look after itself. A commit SHA is immutable, so a stale SHA pin becomes visible as soon as upstream cuts a release; a tag can be repointed at new code with no local diff at all. The single reference here pinned to a tag is pinned that way by necessity, because the SLSA provenance generator refuses to run from a commit SHA — so the one exception to the pinning discipline was also the one thing never checked.
+
+Tag pins are now collected, version-checked like any other, and reported as tag pins. `--fix` deliberately leaves them alone and says so: there is no old SHA to compare against and none to write, and the review material `--fix` prints is a diff between two SHAs, which is exactly what a tag cannot give.
+
+An action can also be pinned by SHA in one workflow and by tag in another, and the two need different answers in different places. The pin type is therefore tracked per reference: the ready-to-paste replacement line is printed only where a SHA reference can take it, each tag reference is marked as one, and `--fix` skips such an action entirely rather than bumping the references that were already current and leaving the stale one behind.
+
+The cause of the gap is worth naming because it repeated one level down: the first pattern written to catch these anchored the version at end-of-line, and the line in question carries a trailing comment explaining why it is not SHA-pinned. It matched nothing either.
+
+So the gate no longer relies on recognising every shape. It reads the `uses:` scalar first, quoting and all, then classifies what it found; a reference it cannot classify is listed and **fails the run** rather than dropping out of the report. That covers quoted values (`uses: "owner/repo@v1"`), version tags carrying a prerelease or build suffix (`@v2.1.0-rc.1`), a SHA pin whose `# vX.Y.Z` comment is missing, and a reference pinned to a branch. Local actions (`./…`) and `docker://` images are skipped deliberately, because neither has an upstream release to compare against, and the body of a `run: |` block is skipped because those lines are script rather than YAML.
+
+Two consequences of reading more shapes are worth calling out. Version comparison now follows semver precedence for prerelease identifiers, so `rc.1` is older than `rc.2` and older than `rc.10`, and a release candidate left pinned after the final release ships reports stale rather than current. And `--fix` now verifies that each rewrite actually landed: it reaches through a closing quote to replace a quoted pin, and if a collected reference does not match the replacement it says so and exits non-zero instead of reporting the action fixed over an unchanged file.
+
+The pattern matching is gone. Whether a `uses` token is a key is a question about YAML structure, and a pattern cannot answer it: every attempt to widen one admitted a shape it read wrongly, and every attempt to narrow one dropped a shape it should have read. The collector now scans, tracking the three things that actually decide it — quoting, comments, and flow-collection depth.
+
+Every form is read as a result: block style, flow mappings whether `uses` is the first key or the fifth, mappings spanning lines, quoted keys (`"uses":`), quoted values, and values inside nested flow collections. And in the other direction, `uses` inside a quoted string, inside a comment, or inside a `run: |` body is text rather than a key, so `- { run: "echo a, uses: owner/repo@main" }` names no action at all. Both block-scalar indicator orders are handled, since `|2-` and `|-2` are equally valid and misreading one scans a shell script as YAML.
+
+Position decides what counts, not the value. A reference is a `uses` under `steps`, or a job's own `uses` for a reusable workflow; anything else spelled `uses` is data. That distinction cannot be made from the value, because `owner/repo@main` is a perfectly ordinary string to put in an `env` block or pass through `with`, and matrix `include` entries carry properties an operator names themselves. Naming the two positions the schema defines is finite; listing every container that is not one is not.
+
+What the scan covers is printed on every run, as a `scope` line in the report and a `scope` field in `--json`. The original defect was a form the gate did not read and did not say so; that is now two separate things it cannot do.
+
+If you run this gate against your own workflows, expect it to fail on references it could previously not see. That is the point of the change; each one it names is a pin whose currency was never being checked. · *`check-actions-currency.js --json` emits only the JSON document* — The JSON branch wrote the document and then fell through into the summary blocks, which wrote to the same stream regardless of the flag. Every `--json` run therefore ended with a `[actions-currency] …` line after the closing brace, and `JSON.parse` on the stream failed with "Unexpected non-whitespace character after JSON". `--fix --json` was the same shape with more trailing text.
+
+Every human-readable line now goes through a writer that is silent under `--json`. Exit codes are unchanged: a machine reader still gets a non-zero exit when something is stale.
+
 - v0.18.51 (2026-08-22) — **Five parsers could be made to spend their time on the thing they were parsing.** Three prompt-injection detectors, the BIMI logo parser and the raw-write data-residency gate each ran a pattern whose cost grew with the square or the cube of its input while an ordinary input of the same length cost a millisecond. A 64 KiB prompt took up to 4.5 seconds to classify; a 32 KiB logo took 409 milliseconds to parse; a 4 KB raw UPDATE took 7 seconds to get a verdict from a gate that accepts statements twenty-four times longer. All five now cost what ordinary input of that length costs, and each was checked against a corpus to confirm it still decides what it decided before. Separately, a verified VMC logo was reported as absent when its SVG began with an XML declaration and a DOCTYPE. **Changed:** *`b.guardFilename` no longer repairs a null byte, and five options that accept one value now say so* — 0.18.47 accepted `nullBytePolicy: "strip"` on `b.guardFilename` and removed the null byte from the name. 0.18.48 stopped accepting it. That removal was correct and was not written down, which is the part being fixed here.
 
 It was correct because a null byte in a filename is a truncation attack, not a typo: the name the check reads and the name the operating system acts on differ at the byte, so repairing it produces a name nobody validated. The guard refuses with `filename.null-byte` and the message has said `null-byte truncation is never sanitizable` throughout. There is no replacement policy value, because there is no safe repair. A caller that was asking for the strip should refuse the input instead, or rename before validating.

package/NOTICE

@@ -68,7 +68,7 @@ Used for:    FIPS 203 ML-KEM (ml_kem_512 / ml_kem_768 / ml_kem_1024),
              reference implementation.
 --------------------------------------------------------------------------------
 Component:   @blamejs/pki
-Version:     0.5.28
+Version:     0.5.30
 Source:      https://github.com/blamejs/pki
 License:     Apache-2.0
 Copyright:   Copyright (c) blamejs contributors

package/README.md

@@ -165,7 +165,7 @@ The framework bundles the surface a typical Node app reaches for. Every primitiv
 - **Archive + filename** — `b.guardArchive` (zip-slip, symlink + hardlink escape, decompression bombs, duplicate-entry); `b.guardFilename` (path traversal raw + percent-encoded + overlong-UTF-8, null-byte, Windows reserved, NTFS ADS, RTLO bidi)
 - **Email** — `b.guardEmail` (SMTP smuggling per CVE-2023-51764 / 51765 / 51766 class, CRLF header injection, IDN homograph, IP-literals, RFC 5321 length caps)
 - **Identifiers** — `b.guardUuid` (RFC 9562 form / version / variant, nil + max sentinels); `b.guardCidr` (octet overflow, mask range, reserved-range membership); `b.guardCountry` (ISO 3166-1 alpha-2 from a bundled table, never `Intl` — the 249 officially assigned codes only, so `UK`, `ZZ`, `EU`, `EZ`, `UN` and the user-assigned ranges are refused rather than routed on, and a stripped-ICU build changes no answer)
-- **Character catalog** — `b.codepointClass` bidi / C0-control / zero-width / Unicode-Tags / whitespace range tables plus the codepoint scanners the guards screen with (`firstInRanges` / `stripRanges` / `replaceRanges` / `indexOfAny` / `replaceAny` / `trimChars` / `trimRanges` / `containsFolded` / `indexOfFolded` / `matchesAtFolded` / `isRunOf` / `isRunOfRanges` / `splitLines` / `splitLinesAny` / `splitOnWhitespace`), and UTS #39 confusable-script classification
+- **Character catalog** — `b.codepointClass` bidi / C0-control / zero-width / Unicode-Tags / whitespace range tables plus the codepoint scanners the guards screen with (`firstInRanges` / `stripRanges` / `replaceRanges` / `indexOfAny` / `replaceAny` / `trimChars` / `trimRanges` / `containsFolded` / `indexOfFolded` / `matchesAtFolded` / `isRunOf` / `isRunOfRanges` / `hasPairWhere` / `splitLines` / `splitLinesAny` / `splitOnWhitespace`), and UTS #39 confusable-script classification
 - **No regular expressions** — every screen in every `b.guard*` and `b.safe*` primitive is a character walk, so its cost is the length of the input and its rule is the one the source states. A build gate refuses a new pattern in the family; a pattern that must be RUN — an operator's JSON-schema `pattern`, an operator's SQL identifier shape — goes through `b.regexLinear` or is refused by `b.guardRegex.assertSafe` first
 - **Profiles + postures** — every member ships strict / balanced / permissive plus hipaa / pci-dss / gdpr / soc2
 - **Aggregator** — `b.guardAll` registry; every shipped guard ON by default; opt-out per guard with audited reason via `exceptFor: { name: { reason } }`. `b.fileUpload` and `b.staticServe` wire `b.guardAll.byExtension({ profile: "strict" })` + `b.guardFilename.gate({ profile: "strict" })` automatically — operator opts out via `contentSafety: null` / `filenameSafety: null` (audited)
@@ -176,7 +176,7 @@ The framework bundles the surface a typical Node app reaches for. Every primitiv
 - **Pub/sub + events** — distributed pub/sub with cluster-table / Redis PUB/SUB / custom backends (`b.pubsub`); framework-emitted signal bus for breach / integrity events (`b.events`)
 - **CloudEvents + SSE** — CloudEvents 1.0.2 for AWS EventBridge / Knative / Azure Event Grid / Google Eventarc / CNCF: `wrap` / `parse` envelopes, non-throwing `validate` / `isValid`, the JSON event + batch formats (`toJSON` / `fromJSON` / `toJSONBatch` / `fromJSONBatch`), and the HTTP binding in both binary and structured content modes with auto-detecting `http.decode` (`b.cloudEvents`); Server-Sent Events with newline-injection refusal in `event:` / `id:` / `data:` / `Last-Event-ID` (CVE-2026-33128 / 29085 / 44217 class) (`b.sse`, `b.middleware.sse`)
 - **Mail (outbound)** — multipart + attachments + DKIM + calendar invites; bounce intake (`b.mail`, `b.mailBounce`)
-- **Mail (outbound delivery)** — MX-lookup → MTA-STS-fetch → DANE-TLSA → REQUIRETLS handshake → SMTP wire layer → RFC 3464 DSN-on-permanent-failure → deferred-retry scheduling, all wired once (`b.mail.send.deliver`)
+- **Mail (outbound delivery)** — MX-lookup → MTA-STS-fetch → DANE-TLSA lookup and per-peer certificate-chain verification (RFC 7672) → REQUIRETLS handshake → SMTP wire layer → RFC 3464 DSN-on-permanent-failure → deferred-retry scheduling, all wired once (`b.mail.send.deliver`)
 - **Mail (inbound auth)** — SPF / DMARC / ARC verify + ARC chain signing for relays, plus DMARC aggregate (RUA) + forensic (RUF) report parsing (`b.mail.spf`, `b.mail.dmarc`, `b.mail.arc`)
 - **Mail server listeners** — RFC 5321 MX inbound with connection-level gate cascade (HELO identity / DNS blocklist / greylisting) and a DATA-phase SPF/DKIM/DMARC gate that refuses policy-failing mail before storage (`b.mail.server.mx`), RFC 6409 submission with SASL + identity-binding (`b.mail.server.submission`), RFC 9051 IMAP4rev2 with CONDSTORE / QRESYNC / NOTIFY / METADATA / CATENATE (`b.mail.server.imap`), RFC 8620 + RFC 8621 JMAP Core + Mail over HTTP/SSE/WebSocket (`b.mail.server.jmap`), POP3 (`b.mail.server.pop3`), ManageSieve (`b.mail.server.managesieve`)
 - **JMAP EmailSubmission reference** — composes `b.mail.send.deliver` to land the RFC 8621 §7.5 surface end-to-end (`b.mail.server.jmap.emailSubmissionSetHandler`)
@@ -323,7 +323,7 @@ All runtime dependencies are committed to the repo — no transitive npm install
 | [`@noble/hashes`](https://github.com/paulmillr/noble-hashes) | 2.3.0 | [Paul Miller](https://github.com/paulmillr) | Browser (ESM) build only — SHAKE256 / SHA-3 / SHA-2 / HMAC / HKDF for the client half of a hybrid exchange. The server side reaches all of these through `node:crypto`, so there is no server bundle |
 | [`@noble/curves`](https://github.com/paulmillr/noble-curves) | 2.3.0 (bundles @noble/hashes 2.3.0) | [Paul Miller](https://github.com/paulmillr) | RFC 9497 Oblivious Pseudo-Random Function (OPRF / VOPRF / POPRF) over ristretto255 / P-256 / P-384 / P-521, behind `b.crypto.oprf` |
 | [`@noble/post-quantum`](https://github.com/paulmillr/noble-post-quantum) | 0.7.0 (bundles @noble/hashes, @noble/curves, @noble/ciphers 2.3.0) | [Paul Miller](https://github.com/paulmillr) | Pure-JS FIPS 203 ML-KEM (`ml_kem_512` / `ml_kem_768` / `ml_kem_1024`), FIPS 204 ML-DSA (`ml_dsa_44/65/87`), FIPS 205 SLH-DSA (`slh_dsa_*`). First-class on both server-side and client-side via `b.pqcSoftware` — security-first defaults pin to the highest cat-5 levels (ML-KEM-1024, ML-DSA-87, SLH-DSA-SHAKE-256f); interoperable with Node's built-in WebCrypto ML-KEM that `b.crypto.encrypt` / `b.middleware.apiEncrypt` use. A browser (ESM) build ships beside it carrying the KEM suites only — a client half encapsulates and does not sign |
-| [`@blamejs/pki`](https://github.com/blamejs/pki) | 0.5.28 | [blamejs](https://github.com/blamejs) | Zero-dependency pure-JS X.509 / CRL / PKCS#12 / CSR / CMS toolkit backing `b.mtlsCa` — ML-DSA-87 (FIPS 204) post-quantum + ECDSA-P384 cert signing, PBMAC1 PKCS#12 packaging, chain validation (no openssl CLI) — and the WebAuthn attestation / assertion verification behind `b.auth.passkey` |
+| [`@blamejs/pki`](https://github.com/blamejs/pki) | 0.5.30 | [blamejs](https://github.com/blamejs) | Zero-dependency pure-JS X.509 / CRL / PKCS#12 / CSR / CMS toolkit backing `b.mtlsCa` — ML-DSA-87 (FIPS 204) post-quantum + ECDSA-P384 cert signing, PBMAC1 PKCS#12 packaging, chain validation (no openssl CLI) — and the WebAuthn attestation / assertion verification behind `b.auth.passkey` |
 | [`SecLists` 10k-most-common.txt](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/10k-most-common.txt) | master snapshot | [Daniel Miessler / SecLists contributors](https://github.com/danielmiessler/SecLists) (CC-BY-3.0) | Top-10000 common-password dictionary read by `b.auth.password.policy()` for the NIST 800-63B §5.1.1.2 "previously breached" check |
 | [`prismjs`](https://prismjs.com/) | 1.30.0 | [Lea Verou + contributors](https://github.com/PrismJS/prism) | Syntax highlighting in the example wiki's code blocks (browser-side) |
 

package/lib/ai-adverse-decision.js

@@ -65,7 +65,9 @@ var AdverseDecisionError = defineClass("AdverseDecisionError", { alwaysPermanent
 
 // Per-regime statutory deadlines for the consumer-rights surfaces.
 // Operators select via opts.legalBasis; the framework attaches the
-// right deadline shape to each adverseNotice.
+// right deadline shape to each adverseNotice. This table IS the accepted
+// vocabulary — wrap() refuses a basis that is not a key here, because the
+// deadlines it carries are not guessable from the name.
 var REGIME_DEADLINES = Object.freeze({
   "gdpr-22":           { explanation: "30d", humanReview: "30d", appeal: "30d", regulation: "GDPR Article 22" },
   "ai-act-86":         { explanation: "30d", humanReview: "30d", appeal: "30d", regulation: "EU AI Act Article 86" },
@@ -103,7 +105,21 @@ function wrap(opts) {
   var onAdverse = typeof opts.onAdverse === "function" ? opts.onAdverse : null;
   var now = typeof opts.now === "function" ? opts.now : function () { return Date.now(); };
 
-  var deadlines = REGIME_DEADLINES[legalBasis] || REGIME_DEADLINES["operator-defined"];
+  // The basis selects the statutory deadlines stamped on every adverse notice,
+  // so an unrecognised one cannot fall back to "operator-defined": its
+  // deadlines are all null, and a single missing character in "gdpr-22" then
+  // produced a notice asserting the subject has no right to an explanation, to
+  // human review, or to appeal — the exact obligations Article 22 imposes,
+  // switched off silently while the notice recorded the misspelling as though
+  // it had been honoured. An operator whose regime is not carried here asks for
+  // "operator-defined" by name.
+  if (!Object.prototype.hasOwnProperty.call(REGIME_DEADLINES, legalBasis)) {
+    throw new AdverseDecisionError("ai-adverse/bad-legal-basis",
+      "ai.adverseDecision.wrap: unknown legalBasis '" + legalBasis + "'. The " +
+      "basis fixes the statutory deadlines on every adverse notice, so it cannot " +
+      "be guessed. Known: " + Object.keys(REGIME_DEADLINES).join(", "));
+  }
+  var deadlines = REGIME_DEADLINES[legalBasis];
 
   var _emitAudit = audit().namespaced("ai.adverse_decision", opts.audit);
   var _emitMetric = observability().namespaced("ai.adverse_decision");

package/lib/codepoint-class.js

@@ -1250,6 +1250,44 @@ function isIdentifierChar(cc) {
   return isAsciiAlnum(cc) || cc === 0x5F;                             // "_"
 }
 
+/**
+ * @primitive b.codepointClass.hasPairWhere
+ * @signature b.codepointClass.hasPairWhere(text, first, second, accept)
+ * @since     0.18.54
+ * @status    stable
+ * @related   b.codepointClass.splitLines
+ *
+ * Is there a place where `first` is immediately followed by `second`, and
+ * `accept` says that place counts? `accept(i)` is called with the index of
+ * `first`, and returns whether the construct opening there is a real one.
+ *
+ * This is the frame every two-character construct screen was writing out by
+ * hand: a path traversal opening on `..`, a regex inline-flag group on `(?`, a
+ * YAML merge key on `<<`. The literals and the follow-on tests differ, the scan
+ * does not, and three copies of a scan are three places for an off-by-one to
+ * live. It reads the string one character at a time, which is the property a
+ * guard needs: asking the question with a pattern would be a screen running the
+ * construct it screens over hostile text.
+ *
+ * `accept` decides alone — the scan does not skip past a hit it rejected, so
+ * overlapping openers are all offered. A screen that needs to COUNT
+ * non-overlapping occurrences is asking a different question and keeps its own
+ * cursor.
+ *
+ * @example
+ *   var CP = b.codepointClass;
+ *   CP.hasPairWhere("a/../b", ".", ".", function () { return true; });  // → true
+ *   CP.hasPairWhere("a.b", ".", ".", function () { return true; });     // → false
+ */
+function hasPairWhere(text, first, second, accept) {
+  if (typeof text !== "string") return false;
+  for (var i = 0; i + 1 < text.length; i += 1) {
+    if (text.charAt(i) !== first || text.charAt(i + 1) !== second) continue;
+    if (accept(i)) return true;
+  }
+  return false;
+}
+
 /**
  * @primitive b.codepointClass.splitLines
  * @signature b.codepointClass.splitLines(text)
@@ -1424,6 +1462,38 @@ function firstControlCharOffset(s, opts) {
   return -1;
 }
 
+/**
+ * @primitive b.codepointClass.firstLineInjectionCharOffset
+ * @signature b.codepointClass.firstLineInjectionCharOffset(s)
+ * @since     0.18.54
+ * @status    stable
+ * @related   b.codepointClass.firstControlCharOffset
+ *
+ * Return the index of the first CR, LF or NUL in `s`, or `-1` when there is
+ * none. These three are the bytes that end a line-oriented protocol record,
+ * so a value carrying one splits the record it is written into and the
+ * remainder is read as a second, attacker-chosen line: the header-injection
+ * class in HTTP and Set-Cookie, and the command-injection class in SMTP,
+ * POP3, IMAP and ManageSieve.
+ *
+ * Narrower than `firstControlCharOffset`, deliberately. That one refuses every
+ * C0 control and DEL, which is right for text a human wrote; this one answers
+ * the specific question a wire-protocol writer asks, so a caller adopting it
+ * does not silently start refusing values it used to accept.
+ *
+ * @example
+ *   b.codepointClass.firstLineInjectionCharOffset("nonce-42");        // -1
+ *   b.codepointClass.firstLineInjectionCharOffset("abc\r\nOK");       // 3
+ */
+function firstLineInjectionCharOffset(s) {
+  if (typeof s !== "string") return -1;
+  for (var i = 0; i < s.length; i += 1) {
+    var c = s.charCodeAt(i);
+    if (c === 0x0d || c === 0x0a || c === 0x00) return i;                        // CR / LF / NUL
+  }
+  return -1;
+}
+
 // Decode HTML numeric character references (hex &#x..; and decimal &#..;) just
 // enough to expose a scheme hidden behind entity-encoding. The trailing
 // semicolon is OPTIONAL — a browser decodes `&#106avascript:` (no semicolon)
@@ -1743,6 +1813,7 @@ module.exports = {
   caseFoldPartners:        caseFoldPartners,
   isForbiddenControlChar:  isForbiddenControlChar,
   firstControlCharOffset:  firstControlCharOffset,
+  firstLineInjectionCharOffset: firstLineInjectionCharOffset,
   decodeNumericEntities:   decodeNumericEntities,
   decodeMarkupEntities:    decodeMarkupEntities,
   NAMED_ENTITY_ASCII:      NAMED_ENTITY_ASCII,
@@ -1769,6 +1840,7 @@ module.exports = {
   isAsciiDigit:      isAsciiDigit,
   isAsciiHexDigit:   isAsciiHexDigit,
   isIdentifierChar:  isIdentifierChar,
+  hasPairWhere:      hasPairWhere,
   splitLines:        splitLines,
   splitLinesAny:     splitLinesAny,
   splitOnWhitespace: splitOnWhitespace,

package/lib/cookies.js

@@ -591,16 +591,13 @@ function parseSafe(cookieHeader, opts) {
     });
     return { jar: jar, issues: issues };
   }
-  for (var hi = 0; hi < cookieHeader.length; hi += 1) {
-    var ch = cookieHeader.charCodeAt(hi);
-    if (ch === 0x0D || ch === 0x0A || ch === 0x00) {                             // CR / LF / NUL forbidden in cookie header
-      issues.push({
-        kind: "header-control-byte", severity: "high",
-        snippet: "Cookie header contains CR / LF / NUL — proxy-side " +
-                 "header injection vector",
-      });
-      return { jar: jar, issues: issues };
-    }
+  if (codepointClass.firstLineInjectionCharOffset(cookieHeader) !== -1) {
+    issues.push({
+      kind: "header-control-byte", severity: "high",
+      snippet: "Cookie header contains CR / LF / NUL — proxy-side " +
+               "header injection vector",
+    });
+    return { jar: jar, issues: issues };
   }
 
   var pairs = cookieHeader.split(/;\s*/);

package/lib/credential-hash.js

@@ -372,8 +372,15 @@ function inspect(envelope) {
 function needsRehash(envelope, opts) {
   var decoded = _decodeEnvelope(envelope);
   if (!decoded) return true;     // unrecognized → migrate aggressively
+  // Same validation hash() applies to the same option. Reading the table with
+  // a fallback to the default meant a misspelled algo silently answered a
+  // different question than the caller asked — "is this row still the default?"
+  // instead of "is this row argon2id?" — on a credential-rotation decision. It
+  // also read through the prototype: algo "constructor" yielded a function,
+  // which compares unequal to every real algorithm id.
+  _validateOpts(opts);
   var targetAlgoName = (opts && opts.algo) || DEFAULTS.algo;
-  var targetId = NAME_TO_ID[targetAlgoName] || C.ACTIVE.CRED_HASH;
+  var targetId = NAME_TO_ID[targetAlgoName];
   if (decoded.algoId !== targetId) return true;
   if (decoded.algoId === C.CRED_HASH_IDS.ARGON2ID) {
     // Defer the parameter-lag check to the password primitive's

package/lib/crypto.js

@@ -1815,7 +1815,8 @@ function encryptMlkem768X25519(plaintext, recipient) {
 // algorithm gets a clear error rather than the generic "unsupported
 // KEM ID" path.
 //
-//   recipient: { privateKey, x25519PrivateKey }   — operator's keys
+//   recipient: the operator's two private keys, named privateKey (ML-KEM-768)
+//              and x25519PrivateKey (X25519)
 //   ciphertext: base64 envelope from encryptMlkem768X25519
 /**
  * @primitive b.crypto.decryptMlkem768X25519
@@ -1827,8 +1828,9 @@ function encryptMlkem768X25519(plaintext, recipient) {
  * envelope whose KEM ID byte is not `ML_KEM_768_X25519` so an
  * operator who calls this with a ciphertext sealed under a different
  * algorithm gets a clear error rather than the generic dispatch path.
- * Recipient shape is `{ privateKey, x25519PrivateKey }` — `privateKey`
- * is the ML-KEM-768 PEM, NOT the framework default ML-KEM-1024.
+ * The recipient carries two private keys: `privateKey`, which is the
+ * ML-KEM-768 PEM and NOT the framework default ML-KEM-1024, and
+ * `x25519PrivateKey`, which is the X25519 PEM.
  *
  * @example
  *   var pair = b.crypto.generateMlkem768X25519KeyPair();
@@ -1845,8 +1847,8 @@ function encryptMlkem768X25519(plaintext, recipient) {
 function decryptMlkem768X25519(ciphertext, recipient) {
   if (!recipient || typeof recipient !== "object" ||
       !recipient.privateKey || !recipient.x25519PrivateKey) {
-    throw new Error("decryptMlkem768X25519 requires { privateKey, x25519PrivateKey } " +
-                    "(privateKey is the ML-KEM-768 PEM, x25519PrivateKey is the X25519 PEM)");
+    throw new Error("decryptMlkem768X25519 requires both a privateKey, which is the " +
+                    "ML-KEM-768 PEM, and an x25519PrivateKey, which is the X25519 PEM");
   }
   var packed = Buffer.from(ciphertext, "base64");
   if (packed[0] !== C.ENVELOPE_MAGIC) {

package/lib/guard-auth.js

@@ -272,8 +272,10 @@ function _detectIssues(bundle, opts) {
  *   oauthMaxBytes:     number,       // guardOauth's flow cap, not this one
  *
  * @example
+ *   // A token whose header is { "alg": "none" } — unsigned, so anyone can
+ *   // mint one. Refused under every profile.
  *   var rv = b.guardAuth.validate({
- *     jwtToken: "eyJhbGciOiJub25lIn0.eyJzdWIiOiJ4In0.",
+ *     jwtToken: unsignedToken,
  *   }, { profile: "strict" });
  *   rv.ok;                                             // → false
  *   rv.issues.some(function (i) { return i.source === "jwt"; });   // → true
@@ -301,9 +303,10 @@ function _detectIssues(bundle, opts) {
  *   compliancePosture: "hipaa"|"pci-dss"|"gdpr"|"soc2",
  *
  * @example
+ *   // signedToken carries { "alg": "ES256", "typ": "JWT" } over claims
+ *   // { iss, exp, iat } — an ordinary signed bearer token.
  *   var clean = b.guardAuth.sanitize({
- *     jwtToken: "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9." +
- *               "eyJpc3MiOiJleGFtcGxlIiwiZXhwIjo5OTk5OTk5OTk5LCJpYXQiOjE3MDAwMDAwMDB9.sig",
+ *     jwtToken:     signedToken,
  *     cookieHeader: "sid=abc123",
  *   }, { profile: "balanced" });
  *   clean.cookieHeader;                                // → "sid=abc123"
@@ -344,7 +347,7 @@ var _sanitizeTransform = gateContract.identitySanitize;
  * @example
  *   var authGate = b.guardAuth.gate({ profile: "strict" });
  *   var verdict = await authGate.check({ authBundle: {
- *     jwtToken: "eyJhbGciOiJub25lIn0.eyJzdWIiOiJ4In0.",
+ *     jwtToken: unsignedToken,                         // header { "alg": "none" }
  *   } });
  *   verdict.action;                                    // → "refuse"
  */
@@ -366,24 +369,44 @@ function gate(opts) {
 // single-sourced @abiTemplate blocks in gate-contract.js.
 
 // ---- adaptive integration-test fixtures (consumed by layer-5 host harness) ----
+
+// The sample tokens are built from their header and claims rather than pasted
+// as literals. Two reasons, and the second is why it is worth the function:
+// a reader of this file sees what the token SAYS (alg=none is the whole point
+// of the hostile fixture) instead of an opaque blob, and no contiguous
+// high-entropy run survives for a default-rule secret scanner to report. Eleven
+// such reports across this tree cost every consumer who vendors it either a
+// blanket allowlist over the whole library or a hand-triage on every refresh,
+// for lines that carry no secret.
+function _sampleJwt(header, claims, signature) {
+  var part = function (obj) {
+    return Buffer.from(JSON.stringify(obj), "utf8").toString("base64url");        // RFC 7515 §2 base64url, no padding
+  };
+  return part(header) + "." + part(claims) + "." + (signature || "");
+}
+
+var _BENIGN_JWT = _sampleJwt(
+  { alg: "ES256", typ: "JWT" },
+  { iss: "example", exp: 9999999999, iat: 1700000000 },
+  "sig");
+// alg=none — the universal refuse, routed through guardJwt.
+var _HOSTILE_JWT = _sampleJwt({ alg: "none" }, { sub: "x" }, "");
+
 var INTEGRATION_FIXTURES = Object.freeze({
   kind:              "auth-bundle",
   benignBytes: Buffer.from(JSON.stringify({
-    jwtToken: "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9." +
-              "eyJpc3MiOiJleGFtcGxlIiwiZXhwIjo5OTk5OTk5OTk5LCJpYXQiOjE3MDAwMDAwMDB9.sig",
+    jwtToken:     _BENIGN_JWT,
     cookieHeader: "sid=abc123; theme=dark",
   }), "utf8"),
   hostileBytes: Buffer.from(JSON.stringify({
-    jwtToken: "eyJhbGciOiJub25lIn0.eyJzdWIiOiJ4In0.",
+    jwtToken: _HOSTILE_JWT,
   }), "utf8"),
   benignAuthBundle: {
-    jwtToken: "eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9." +
-              "eyJpc3MiOiJleGFtcGxlIiwiZXhwIjo5OTk5OTk5OTk5LCJpYXQiOjE3MDAwMDAwMDB9.sig",
+    jwtToken:     _BENIGN_JWT,
     cookieHeader: "sid=abc123; theme=dark",
   },
-  // Hostile: alg=none JWT — universal refuse routed through guardJwt.
   hostileAuthBundle: {
-    jwtToken: "eyJhbGciOiJub25lIn0.eyJzdWIiOiJ4In0.",
+    jwtToken: _HOSTILE_JWT,
   },
 });