GeezerVison

…opment` (#231)

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #211

…opback (#232)

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #213

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #212

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #220

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #222

…#241)

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #215

…irst (#234)

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #219

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #223

…wrong (#236)

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #218

Co-authored-by: Claude <[email protected]>

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #216

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #210

Co-authored-by: Claude <[email protected]>

Co-authored-by: Claude Opus 5 <[email protected]>
Closes #229

Brings the eleven fixes that landed on release/1.17.0 during review, and
the release commit itself, back into dev. main and dev hold the same
work under different squash SHAs, so every conflict is resolved to
main's side; dev had nothing main lacked, and the result is tree-equal
to main.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Y2dPuUeGeK7mJvar9uLqKz

## Summary

- In **signed** mode (`csrf({ secret })`), if `session()` runs before
`csrf()`, the CSRF secret is now stored in the server-side session
instead of a cookie (synchronizer-token pattern).
- Tokens are bound to the session **and to its id**: `$regenerate()`
(call it on login) invalidates the token, so pages rendered after login
get a fresh one.
  - No CSRF cookie is set in this mode.
- The secret is written to the session only when `csrfToken(ctx)` is
called, so requests that never render a form do not create sessions.
- New option `bindToSession: false` restores the previous cookie-based
behaviour. Without a session, and in unsigned mode, nothing changes.

## Motivation

Until now, the signed token was `cookieSecret.HMAC(cookieSecret)`, and
verification only checked that the token matched the cookie. Nothing
tied that pair to a user. Anyone who can set a cookie for the victim can
therefore obtain a validly signed pair for themselves, plant its secret
as the victim's cookie, and forge requests. Setting a cookie for the
victim is possible from a sibling subdomain, or by a network attacker
for a cookie without the `__Host-` prefix.

The docs said signing defends against exactly this, which was wrong.
This is security-relevant, which is why it was reported privately rather
than as a public issue.

## Changes included

- `src/server/csrf.ts`:
- The session-bound path. The secret is stored as `{ secret, sid }`, and
a mismatch with `session.$id` counts as missing. This closes session
fixation: `$regenerate()` keeps the session payload, so an attacker who
planted a session cookie would otherwise already know the CSRF token of
the session the victim logs into.
  - A lazy token provider in `ctx.state`; `csrfToken()` resolves it.
  - The new `bindToSession` option with JSDoc.
  - Corrected module docs.
- `docs/guide/server.md`:
- Explains the cookie-injection limit, the session binding and the
rotation on login.
- Documents the per-visitor session cost and the race between two
concurrent first-visit requests.
  - Recommends `__Host-bq.csrf` for apps without sessions.
- `tests/server-stable.test.ts`:
  - no CSRF cookie in session mode;
- a token minted for another session is rejected, i.e. the injection
case;
  - no session is created without `csrfToken()`;
- the token rotates on `$regenerate()`: the pre-login token is rejected
and a freshly rendered one works;
  - a POST without a minted token is rejected;
  - the `bindToSession: false` opt-out.

## Validation

- [x] `bunx eslint .` + `bun run format:check`
- [x] `bun run test:types` + `bun run lint:types`
- [x] `bun run check`
- [x] `bun test`: 3524 pass, 0 fail

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- **Behaviour change (signed mode + `session()` only):**
  - No `bq.csrf` cookie is issued any more.
  - The token is a random value stored in the session.
- The token changes when the session id is regenerated, so apps must
render a new token after login.
  - Clients that read the cookie directly need `bindToSession: false`.
- **Merge together with #267:** pages that render a token create a
session per cookieless visitor. #267 caps the default `memoryStore()`
and sweeps expired entries; the docs here assume that bound.
- Known limitation (documented): two requests racing on the very first
visit each create a session and only the last cookie wins. Fixing that
needs merge-on-save in the session middleware, which is out of scope
here.
- Consider a GitHub Security Advisory for ≤ 1.17.0.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---------

Co-authored-by: Claude <[email protected]>

…the Node adapter (#270)

## Summary

- **Handler errors no longer crash the process.** `createNodeHandler()`
/ `createSSRHandler()` on Node now log the error and answer `500
Internal Server Error`. If the response had already started, the
connection is destroyed instead. Before, one throwing request surfaced
as an unhandled rejection, and Node terminates on those by default.
- **Client disconnects stop the response.** `request.signal` aborts and
the response body stream is cancelled. Before, the write loop waited
forever for a `drain` that a closed socket never emits, so streaming
renders and SSE iterators kept running and their resources leaked.
- **No more listener build-up.** Each backpressure wait now removes its
listeners. Before, every wait left one `error` listener on the response.

## Motivation

These are security-relevant robustness issues (a remote DoS and a
resource leak per disconnected client), so they were reported privately
rather than as public issues. Both reproduce under real Node 22 with a
plain `node:http` server; after the fix the same scripts return `500`
and keep the process alive, and the source's `cancel()` runs on
disconnect. `createServer().listen({ runtime: 'node' })` uses the same
adapter, so its streaming responses benefit too.

## Changes included

- `src/ssr/adapters.ts`:
- `NodeServerResponse` gains **optional** `headersSent`,
`writableFinished`, `destroy`, `removeListener` and the `close` event.
Existing structural implementations stay compatible.
- `trackNodeDisconnect()` returns an `AbortSignal` that aborts on
`close` before `writableFinished`. The signal is attached to the
`Request`.
- `writeResponseToNode()` cancels the reader on abort, releases the
drain wait, and cancels the source when the loop exits early.
  - `failNodeResponse()` is the last-resort error handler.
- `docs/guide/ssr.md`: documents the behaviour.
- `tests/ssr-runtime.test.ts`:
- A real `node:http` test: a throwing handler returns 500 twice, and the
server stays up.
- A mock-response disconnect test: cancellation, `request.signal`, and
no leftover listeners. It uses a mock because Bun's `node:http` shim
does not emit `close` for aborted clients.
  - Both tests fail on `dev`.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit` (`tsconfig.json` and `tsconfig.test.json`)
- [ ] `bun run build` (not run)
- [x] `bun test`: 3519 pass, 0 fail
- [x] Manual repro under Node 22 before and after the fix: crash → 500
with the process alive; stream never cancelled → cancelled

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- The 500 body is a fixed string; error details are only logged via
`console.error`, never sent to the client. An `onError` option like
`createEdgeHandler`'s could be added later.
- Consider a GitHub Security Advisory for ≤ 1.17.0.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…decars (#269)

## Summary

- With `serveStatic({ precompressed: true })`, a `.br` or `.gz` sidecar
that resolves outside `root` (for example via a symlink) is now skipped.
The next acceptable encoding, or the identity file, is served instead.
- Hardening only: no API changes, and sidecars inside `root` behave as
before.

## Motivation

`serveStatic` documents that files outside `root` are never reachable,
and since 1.17.0 it re-checks the `realpath` of the identity file for
that reason. The sidecar picked afterwards is a different path, though,
and it was `stat()`ed and streamed without that check.

This is security-relevant, which is why it was reported privately rather
than as a public issue. Exploiting it requires a symlink inside the
served directory, for example in build output or an upload directory.

## Changes included

- `src/server/static.ts`: run `isInsideRoot()` on every sidecar
candidate and `continue` when it fails.
- `tests/server-static.test.ts`: fixture `linked-sidecar.js` with an
escaping `.br` symlink and a real `.gz` sidecar. The test covers both
`accept-encoding: br` (falls back to identity) and `br, gzip` (serves
the in-root gzip sidecar). It fails on `dev`.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3518 pass, 0 fail

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed (not needed; the documented guarantee now holds).
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- A rejected sidecar is skipped silently instead of producing a 403,
because the identity file itself is legitimately servable.
- This costs one extra `realpath` pair per request, and only when a
sidecar exists.
- Consider publishing a GitHub Security Advisory for 1.17.0 alongside
the release.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

Co-authored-by: Claude <[email protected]>

…rift (#268)

## Summary

- The supported-versions table in `SECURITY.md` now reads `1.17.x` ✅ /
`< 1.17.0` ❌. It previously still said 1.14.x.
- `bun run check:ai-guidance`, which is part of `bun run check`, now
fails whenever that table no longer matches the major.minor version in
`package.json`.

## Motivation

Fixes #258. `SECURITY.md` says fixes go to "the latest minor release
line", but the table was not updated for 1.15, 1.16 or 1.17.

## Changes included

- `SECURITY.md`: updated the table.
- `scripts/check-ai-guidance.mjs`: added a `SECURITY.md` entry that
derives the expected line from `package.json`. The script already checks
release metadata across files, so the new check does not need its own
script or CI wiring.

## Validation

- [x] `bunx eslint` + `bunx prettier --check`
- [x] `bun run check` passes
- [x] With the old `SECURITY.md`, `check:ai-guidance` fails and names
both missing rows.
- [ ] `bun run build` / `bun test` (not needed: no source changes)

## Checklist

- [x] I followed the contributing guidelines.
- [ ] I added or updated tests where behavior changed (not applicable;
the guard is itself the check).
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

At each minor release the table now has to be bumped together with
`AGENT.md` and `llms.txt`; the check enforces that.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…267)

## Summary

- `memoryStore()` now removes expired sessions while handling writes.
Before, an expired entry was removed only when the same id was read
again, so abandoned sessions stayed in memory forever.
- `maxEntries` eviction now removes expired entries first, then the
least recently **used** entry. `touch()` counts as use; before, the
order was plain insertion order.
- `session()`'s default store is capped at 10 000 entries, like the rate
limiter's default store.

## Motivation

Fixes #256. In a long-running single-instance deployment, which is the
case this store is documented for, memory grew with every distinct
visitor that ever received a session.

## Changes included

- `src/server/session.ts`:
- Expired entries are swept during `set()`, at most once every 30 s. The
sweep also runs before any `maxEntries` eviction.
  - `touch()` re-inserts the entry so it counts as recently used.
  - New default cap `DEFAULT_SESSION_MAX_ENTRIES = 10_000`.
  - Updated JSDoc.
- `docs/guide/server.md`: documents the cap and the sweeping.
- `tests/server-stable.test.ts`: three tests using `setSystemTime` for:
  - the sweep of never-read entries;
  - sweep before evicting a live entry;
  - least-recently-used eviction after `touch()`.

  All three fail on `dev`.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3520 pass, 0 fail

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- **Behaviour change:** the default store now evicts beyond 10 000 live
sessions. Apps that need more should pass `store: memoryStore({ ttlMs
})`, which stays unbounded, or a shared store. The cap trades memory
exhaustion for possible eviction of old sessions under a flood; this is
the same trade-off `rateLimit` makes.
- A sweep is O(n), but it runs at most every 30 s and only while writes
happen, so no background timer is needed and the process can still exit
normally.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…rusted Types (#266)

## Summary

- Under an enforced `require-trusted-types-for 'script'` CSP,
`component()` rendering and `createTemplate()` no longer throw
`TypeError: … requires 'TrustedHTML' assignment`.
- Component output is **not** sanitized a second time, so `<slot>`,
`part` and form attributes survive.

## Motivation

Fixes #253. `docs/concepts/security-model.md` promises that bQuery
defaults satisfy an enforced Trusted Types CSP. Both sinks, however,
assigned plain strings to `innerHTML`.

`trustedHtmlForSink()` would not have worked either: it re-sanitizes
with the default allow list, which strips exactly what the component
allow lists keep (`<slot>`, `part`), and for templates it would strip
the `bq-*` attributes.

## Changes included

- `src/security/trusted-types.ts`:
- New internal `trustedPreparedHtmlForSink(prepared)`. It wraps exactly
that string through the existing `bquery-sanitizer` policy without
re-sanitizing, so no new policy name has to be allowed in the CSP.
- The pass-through is module-private and armed only for that one
synchronous `createHTML` call. Any other input to the policy is
sanitized as before.
  - New `__resetTrustedTypesPolicy()` test hook, marked `@internal`.
- `src/component/component.ts`: render output goes through the new
helper.
- `src/view/mount.ts`: `createTemplate()` goes through the new helper.
- `docs/concepts/security-model.md`: documents the covered sinks and the
deliberate exceptions (`htmlUnsafe()`, unsanitized `bq-html`).
- `tests/trusted-types-sinks.test.ts`: emulates enforcement with a mock
policy plus `innerHTML` setters that reject plain strings. It covers
component render (slot and part preserved), `createTemplate()`, and a
check that the pass-through does not stay armed.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit` (`tsconfig.json` and `tsconfig.test.json`)
- [x] `bun run check`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3520 pass, 0 fail. With the component and view changes
reverted, the two sink tests fail.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions: component output is already sanitized, and templates are
author-trusted per the view threat model.

## Notes for reviewers

- **Trade-off:** under Trusted Types, `createTemplate()` with untrusted
input used to throw. It is now accepted, the same as without Trusted
Types. This matches the documented contract that templates are
author-controlled, but it is a policy decision worth a second look.
- The emulation cannot prove real browser enforcement; a real-browser
lane (#214) would.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

## Summary

- `email()` no longer backtracks quadratically. Input of the form `a@` +
50 000 dots + `@` took about 4.8 s on `dev`; it now returns in under 1
ms.
- Addresses longer than 254 characters are rejected before the regex
runs (the RFC 5321 forward-path limit).
- Empty domain labels are now rejected: `[email protected]`, `[email protected]`, `[email protected].`.

## Motivation

Fixes #252. In `/^[^\s@]+@[^\s@]+\.[^\s@]+$/`, the character classes on
both sides of `\.` can also match dots, so the engine tries every split
point. The validator blocks the thread while it runs, and this becomes
reachable from request bodies once forms validation runs server-side
(#221).

## Changes included

- `src/forms/validators.ts`: the pattern is now
`/^[^\s@]+@[^\s@.]+(?:\.[^\s@.]+)+$/`. Domain labels cannot contain a
dot, so each split is unambiguous. A `MAX_EMAIL_LENGTH = 254` guard runs
before the regex.
- `tests/forms.test.ts`: tests for empty labels, the length cap, and a
time-bounded adversarial case. That case takes about 4.9 s on `dev` and
fails its 100 ms bound; with the fix it takes well under a millisecond.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3520 pass, 0 fail. The three new tests fail on `dev`.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed (not needed).
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

The validator is now slightly stricter: it rejects empty domain labels
and addresses over 254 characters. Mail servers reject both kinds of
address anyway.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

Co-authored-by: Claude <[email protected]>

## Summary

- `http.get(url, { signal: alreadyAborted, timeout })` now rejects with
`ABORT` without sending the request. Before, it resolved normally.
- `abort('some reason')` with a non-`DOMException` reason is now
reported as `ABORT` instead of `NETWORK`.
- `app.listen({ signal: alreadyAborted })` rejects with the signal's
reason and does not bind.
- On Node, a signal that aborts while the socket is still binding now
shuts the server down instead of leaving it running.

## Motivation

Fixes #251. An aborted `AbortSignal` never dispatches `abort` again, so
code that only calls `addEventListener('abort', …)` misses it.
`useFetch` already handled this; `createHttp` and `listen()` did not.

## Changes included

- `src/reactive/http.ts`:
  - Check `signal.aborted` before composing with the timeout controller.
- In the catch block, use the merged signal's `aborted` state to
classify cancellations.
- `src/server/create-server.ts`:
  - `listen()` calls `signal.throwIfAborted()` up front.
- A new `onAbort()` helper tears down immediately when the signal is
already aborted; used on the Bun and Node paths. Deno receives the
signal natively.
- `src/server/types.ts`: documents the pre-aborted behaviour.
- Tests in `tests/http.test.ts` and `tests/server.test.ts`. All four
fail on `dev`.

## Validation

- [x] `bunx eslint` + `bunx prettier`
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3521 pass, 0 fail

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed (JSDoc on `ServerListenOptions.signal`).
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

`listen()` now **rejects** for a pre-aborted signal. The alternative was
to resolve a handle that is already stopped. Rejecting matches `fetch()`
and `AbortSignal` conventions.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…splay (#263)

## Summary

- `toggle()` now shows an element hidden via the `hidden` attribute.
Before, the first `toggle()` added `display: none` on top and the
element stayed hidden.
- `hide()` → `show()` restores the element's previous inline `display`,
e.g. `flex`, where it used to reset it to `''`. This holds for both
`$()` and `$$()`.
- `show('grid')` still forces an explicit value.

## Motivation

Fixes #250. `toggle()` and `show()` disagreed about what "hidden" means,
and `hide()` threw away state that jQuery users expect `show()` to
restore.

## Changes included

- `src/core/shared.ts`: `hideElement` / `showElement` /
`isElementHidden`. The pre-hide inline display is kept in a
`WeakMap<Element, string>`, so detached elements can be collected.
- `src/core/element.ts`, `src/core/collection.ts`: use them.
`show(display?: string)` no longer defaults to `''`. An explicit
argument still wins.
- `docs/guide/api-core.md`: describes the new semantics.
- `tests/core.test.ts`: tests for toggle on `[hidden]`, restoring
`flex`, repeated `hide()`, an explicit value, and the collection path.

## Validation

- [x] `bunx eslint` + `bunx prettier --check`
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3520 pass, 0 fail. The three new tests fail on `dev`.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- **Small behaviour change:** calling `show()` without arguments on an
element that is *not* inline-hidden no longer clears its inline
`display`. Before, `show()` on a `display: flex` element reset it to
`''`.
- An element hidden only by a stylesheet rule is still not detected.
Showing it would mean guessing a default display, which is out of scope
here.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…261)

## Summary

- `app.get('/über', …)`, `app.get('/a b/:id', …)` and emoji segments
used to always return 404. They now match.
- Lower-case percent-escapes sent by a client (`/%c3%bcber`) match too.

## Motivation

Fixes #248. `compileRoutePath` built the RegExp from the literal route
string, but matching runs against `ctx.url.pathname`, which the URL
parser always percent-encodes. Param decoding was already correct; only
static segments were affected. File routes are affected the same way,
since they compile through the same function.

## Changes included

- `src/server/create-server.ts`:
- `encodeStaticSegment()` encodes static segments with the URL path
percent-encode set before regex-escaping them.
- `normalizePercentEncoding()` upper-cases escapes in the request path
inside `matchRoute`. `ctx.path` itself is not changed.
- `tests/server.test.ts`: regression test for an umlaut, lower-case
escapes, a space segment combined with a decoded param, an emoji
segment, and a negative case.

## Validation

- [x] `bunx eslint` + `bunx prettier` on changed files
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3518 pass, 0 fail. The new test fails on `dev`.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed (not needed).
- [x] I confirmed the change does not introduce security-sensitive
regressions. `%` is not in the encode set, so a pre-encoded route like
`/a%20b` still matches literally.

## Notes for reviewers

The client-router counterpart is #260 (#247).

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

…260)

## Summary

- `route.params` values are now percent-decoded: `/user/J%C3%BCrgen%20M`
gives `{ name: 'Jürgen M' }`. Before this change they came back encoded.
- Routes whose static text contains non-ASCII or other URL-encoded
characters now match, e.g. `/über` and `/a b/:id`.
- `resolve()` → navigation → `route.params` round-trips.
- Param constraints are checked against the decoded value, the same
value `resolve()` validates.

## Motivation

Fixes #247. The router matched patterns against the raw, encoded
`location.pathname` and had no `decodeURIComponent` anywhere.
`resolve()` already encoded params, so named navigation with anything
non-ASCII produced encoded params.

## Changes included

- `src/router/match.ts`:
- Static route text is encoded the way the WHATWG URL parser encodes a
pathname (C0/space/`"#<>?\`{}`/DEL/non-ASCII). The result is cached per
pattern. Params, their constraints and `*` are left untouched.
- Percent-escapes in the incoming path are upper-cased, so `%c3%bc`
equals `%C3%BC`.
- Captured params are decoded before the constraint test. A malformed
escape is kept verbatim instead of failing navigation.
- `tests/router.test.ts`: three regression tests covering param
decoding, the `resolve()` round-trip with a constraint, and static
non-ASCII / space routes including lower-case escapes.

## Validation

- [x] `bunx eslint` + `bunx prettier --check` on changed files
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3520 pass, 0 fail. The three new tests fail on `dev`.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed (the docs never described encoded params, so nothing to change).
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- **Behaviour change:** an app that worked around this by calling
`decodeURIComponent(route.params.x)` itself will now decode twice. That
only matters for values containing a literal `%`. Worth a line in the
release notes.
- `route.path` stays the encoded URL path on purpose, since it is a URL.
- The server router has a similar static-segment issue; it has its own
PR for #248.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

#259)

## Summary

- `deepEqual` / `isEqual` (core) and the store-internal `deepEqual`
returned `true` for `{}` vs `[]`, `new Date(0)` vs `{}`, `new Map([[1,
2]])` vs `{}`, `new Set([1])` vs `[]`, `/a/` vs `{}`.
- They now return `false` whenever the two values are different built-in
kinds.

## Motivation

Fixes #246. The type-specific branches only ran when **both** sides were
the same kind. On a mismatch, comparison fell through to the own-key
check, and all these built-ins have zero own enumerable keys. As a
result, `watchStore({ deep: true })` could miss a field changing from
`{}` to a `Date`, `Map` or `[]`.

## Changes included

- `src/core/utils/object.ts`: compare `Array.isArray` and the
`Object.prototype.toString` tag before the kind-specific branches.
- `src/store/utils.ts`: same tag check.
- Tests: an all-pairs kind-matrix test in
`tests/utils-object-extras.test.ts` and mismatch cases in
`tests/store-utils.test.ts`. Null-prototype objects still compare equal
to plain objects, since both carry the tag `[object Object]`.

## Validation

- [x] `bunx eslint` + `bunx prettier --check` on the changed files
- [ ] `bun run build` (not run; no build-surface changes)
- [x] `bun test tests/utils-object-extras.test.ts
tests/store-utils.test.ts tests/store.test.ts`: 146 pass. The new tests
fail on `dev` (2 fail) and pass with the fix.

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [ ] I updated documentation when public behavior or developer workflow
changed (not needed; this is a bug fix to documented behaviour).
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

- Class instances still share the `[object Object]` tag, so they keep
today's own-key comparison. Tightening that with a prototype check would
change behaviour for null-prototype objects, which `serialize()`
returns.
- Two separate implementations still exist. Unifying them is a possible
follow-up.
- `CHANGELOG.md` has no Unreleased section, so this PR leaves it
untouched.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

## Summary

- `css({ fontSize: '18px' })`, `css('backgroundColor', 'blue')` and
`css('fontSize')` now work on both `$()` and `$$()`. Previously all
three were silently ignored or returned `''`.
- Custom properties (`--brandColor`) and kebab-case names behave as
before.

## Motivation

Fixes #249. The CSSOM `setProperty` / `getPropertyValue` calls only
accept hyphenated names. `docs/guide/migration.md` shows the camelCase
form, so jQuery users following the guide got no styles and no error.

## Changes included

- `src/core/shared.ts`: new internal `toCssPropertyName()`. It converts
camelCase to kebab-case, handles vendor prefixes (`WebkitX` →
`-webkit-x`, `msX` → `-ms-x`) and `cssFloat` → `float`, and passes
`--custom` names through unchanged.
- `src/core/element.ts`, `src/core/collection.ts`: every `css()` form
(single setter, object setter, getter) goes through it.
- `docs/guide/api-core.md`: one-line example.
- `tests/core.test.ts`: element and collection tests plus unit tests for
the helper.

## Validation

- [x] `bunx eslint` + `bunx prettier --check` on changed files
- [x] `bunx tsc --noEmit -p tsconfig.json`
- [ ] `bun run build` (not run)
- [x] `bun test`: 3521 pass, 0 fail

## Checklist

- [x] I followed the contributing guidelines.
- [x] I added or updated tests where behavior changed.
- [x] I updated documentation when public behavior or developer workflow
changed.
- [x] I confirmed the change does not introduce security-sensitive
regressions.

## Notes for reviewers

Per-call cost is one regex test for names without uppercase letters. The
object form maps the entries once per call, not once per element.

🤖 Generated with [Claude Code](https://claude.com/claude-code)

https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

---
_Generated by [Claude
Code](https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo)_

---------

Co-authored-by: Claude <[email protected]>

Security-and-correctness patch closing the 1.17.0 audit: serveStatic
sidecar containment, Node adapter error/disconnect handling, session-bound
signed CSRF tokens, plus ten bug fixes (#246-#253, #256, #258).

- bump package.json to 1.17.1 and sync AGENT.md, llms.txt and the AI
  guidance files (check:ai-guidance passes)
- CHANGELOG entry and docs/release-notes/1.17.1.md
- release-notes index and sidebar: add 1.17.1, link 1.17.0 (missing from
  the sidebar), and correct 1.17.0's date and CHANGELOG anchor to
  2026-09-25
- api-core guide: show()/hide()/toggle() and camelCase css() match the
  shipped behaviour; router guide documents decoded params

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

JosunLP left a comment

coderabbitai Bot left a comment

CSRF (session-bound mode):
- Requests without a stored session use the signed cookie instead of
  writing a secret into a new session. A flood of cookieless GETs that
  render csrfToken() can no longer fill the session store or evict real
  sessions from the capped default store. A session created during such
  a request adopts the cookie secret, so forms rendered earlier still
  verify.
- For a stored session the secret is bound before the handler runs, so
  a token read after next() resolved (streamed SSR, ctx.sse) is one the
  persisted session holds.

Core:
- isElementHidden() treats hidden="until-found" as hidden even with an
  inline display, since it hides through content-visibility; toggle()
  now shows such an element.
- api-core.md: the toggle(force?) entry names the inline-display
  exception.

Docs: server guide, CHANGELOG and 1.17.1 release notes describe the
anonymous cookie fallback and the late-read guarantee.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo

coderabbitai Bot left a comment

A visitor without a session who logs in creates the session through
$regenerate(). The post-handler binding then adopted the CSRF cookie
secret, so an attacker who had planted that cookie (cookie injection)
held a valid token for the authenticated session.

csrf() now observes $regenerate() and $destroy() on ctx.session: a
regenerated session binds a fresh random secret, and nothing is written
back to a destroyed session. Ordinary anonymous session creation still
adopts the cookie secret, so forms rendered before it keep working.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Claude-Session: https://claude.ai/code/session_01MdbZH1BQLrEGMoMD3gdBBo