Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@library/src/regex.ts`:
- Line 120: The current JWT_REGEX allows '=' padding and disallows unsecured
JWTs with an empty signature; update the JWT_REGEX constant so it matches the
standard compact JWT form: exactly three dot-separated Base64URL segments where
the first two segments require one or more Base64URL chars ([A-Za-z0-9_-]+) and
the third (signature) may be empty ([A-Za-z0-9_-]*), and do not permit '='
padding; replace the existing /^[-\w]+={0,2}\.[-\w]+={0,2}\.[-\w]+={0,2}$/u with
a regex that enforces those token characters for JWT_REGEX so jwt() (used at
jwt.ts:92-97) correctly classifies tokens.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@library/src/actions/jwt/jwt.test.ts`:
- Around line 67-76: The test 'for valid JWTs' currently includes real-looking
JWT strings that trigger secret scanners; change the fixtures used in
expectNoActionIssue to synthetic base64url-safe segments instead (e.g., generate
header, payload, signature strings that match JWT_REGEX but are not real
secrets) so coverage of jwt() / JWT_REGEX remains the same; update the array
passed to expectNoActionIssue in the test (and any other similar arrays in this
file) to use these synthetic base64url-safe segment placeholders rather than raw
JWT literals.

---

Nitpick comments:
In `@library/src/actions/jwt/jwt.test.ts`:
- Around line 125-130: The test 'for invalid characters' is using an escaped
backslash sequence "\\u00a9" instead of an actual Unicode character; update the
third test string passed to expectActionIssue (inside the test named 'for
invalid characters') to include a real non-ASCII character (e.g., "©" or the
literal "\u00a9" without an extra backslash) so the case exercises Unicode
rejection rather than just backslash escaping; keep the other two inputs and
variables (action, baseIssue) unchanged.

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@library/src/actions/jwsCompact/jwsCompact.ts`:
- Around line 99-103: The JWS_COMPACT_REGEX used by jwsCompact (referenced via
the requirement property in the '~run' method) currently rejects compact
serializations with an empty payload; update the regex definition named
JWS_COMPACT_REGEX in library/src/regex.ts to allow an empty middle (payload)
segment (change the base64url quantifier from one-or-more to zero-or-more) so
the dataset.check in '~run' accepts empty payloads, and add a regression test
exercising jwsCompact() with a valid compact serialization whose payload encodes
to the empty string to prevent regressions; ensure the behavior in '~run' and
_addIssue remains unchanged aside from accepting the empty payload case.

In `@website/src/routes/api/`(actions)/jwsCompact/index.mdx:
- Around line 3-37: Reword the doc for the jwsCompact action to keep the public
contract purely structural: replace references to "JWT strings" and implications
of signature/semantics with language that describes only the three-part JWS
compact shape (un-padded Base64URL segments) and that an empty/absent third
segment is valid syntax; update the description, summary lines that read like
JWT semantics (mentions of "signed" or 'alg: "none"') to clarify you are not
decoding or verifying headers/ signatures and that acceptance of an empty third
segment is purely a structural allowance, not an inference about decoded header
or algorithm.

In `@website/src/routes/api/`(types)/JwsCompactAction/index.mdx:
- Around line 3-15: Update the documentation text in the JwsCompactAction MDX to
remove the broader "JWT" wording and explicitly describe structural JWS compact
validation: change lines referencing "JWT validation" and "JWT strings" to
phrases like "JWS compact validation" and "JWS compact serialized strings" so
the description matches the narrower jwsCompact contract; apply the same exact
wording changes in the JwsCompactIssue MDX so both docs consistently reference
JWS compact validation and the jwsCompact function by name.

---

Nitpick comments:
In `@library/src/actions/jwsCompact/jwsCompact.test.ts`:
- Around line 73-79: Replace the hard-coded JWT strings in the
jwsCompact.test.ts fixtures with synthetic, non-sensitive base64url-like strings
(e.g., construct header.payload.signature patterns programmatically) so the
jwsCompact() tests still exercise structure parsing without containing real or
high-signal JWT samples; locate the array of fixtures used by the jwsCompact
tests (the entries currently containing 'eyJ...' strings including the one
ending with a trailing dot) and substitute them with generated placeholders that
mirror "header.payload.signature" shape (keeping variations such as empty
signature or different alg fields) to preserve coverage while avoiding
secret-scanning hits.