@rangojs/router 0.0.0-experimental.debug-cache-2383ca26 → 0.0.0-experimental.df410dd5

package/skills/rango/SKILL.md

@@ -8,30 +8,241 @@ argument-hint:
 
 Django-inspired RSC router with composable URL patterns, type-safe href, and server components.
 
+This page is the mental model to read **before** the catalog. A flat list of
+skills gives nothing to slot details into, so a reader free-associates from local
+vocabulary — which is exactly how `revalidate()` gets misread as caching. Start
+with the shape, then pick a primitive.
+
+## The shape of rango (read first)
+
+- **Routes are expressed, not configured.** The `urls()` tree shows where every
+  route, layout, loader, and cache lives. No file-system convention, no hunting.
+- **Two freshness axes, orthogonal:**
+  - _stored-value freshness_ — `"use cache"`, `cache()`, loader `cache()`
+    (SWR is first-class where the store supports it; `"use cache"` ships a
+    default SWR window; see `/cache-guide`)
+  - _client-update selection_ — `revalidate()`
+- **Loaders are the live data layer** — fresh every request by default, even
+  inside a cached render. They run **in parallel** right after middleware and
+  **stream**, so data latency overlaps first paint instead of blocking it (a
+  cache hit streams UI instantly while loaders resolve fresh alongside). Opt into
+  caching explicitly. See `/loader` → "Parallel and streaming".
+- **One identity, one store** — loaders, handles, cached fns, and actions are all
+  `path#export`; all caches share one store. Entries expire by TTL/SWR; cache
+  entries accept an optional `tags` field, but built-in stores do not yet index
+  or invalidate by tag, so tag-based invalidation (`revalidateTag`) is a
+  forward-looking API requiring a custom store.
+- **Type-safe end to end** — route names, params, search schemas, loader return
+  types, context vars, and `href` / `reverse` are checked at compile time
+  (`/typesafety`).
+- **See where time goes** — turn on `debugPerformance` early (router option, or
+  `ctx.debugPerformance()` in middleware for per-request opt-in). It prints a
+  per-request waterfall + `Server-Timing` header; loaders should overlap the
+  render bar, not serialize after it. For production, wire `telemetry` to a
+  console, OpenTelemetry, or custom sink. See `/observability`.
+
+Most features are **just-in-time**: the core is `urls()`, `path()`, `layout()`,
+`include()`, and `reverse()`. Caching, parallel routes, intercepts, prerender,
+i18n, themes, and the rest are opt-in — reach for them when a requirement
+appears, not up front.
+
+## Composability: structure vs config
+
+- `path()` / `include()` are **structure** — they define URLs and must stay
+  visible in `urls()`. They cannot be hidden in a factory. `include()` composes
+  whole modules (separation of real concerns); `path()` places a leaf.
+- Everything else — `cache`, `loader`, `loading`, `middleware`, `revalidate`,
+  `parallel`, `intercept`, `errorBoundary`, … — is **config**. It attaches to a
+  node via its `use` callback, is importable, and extracts into factories that
+  return arrays (`withAuth()`, `withCaching()`), flattened automatically.
+
+To decide where something can live: **does it define a URL? structure, stays in
+`urls()`. Does it modify a node? config, compose freely.**
+
+## Pick a primitive
+
+| I need to…                            | Use                              | Skill                   |
+| ------------------------------------- | -------------------------------- | ----------------------- |
+| render data fresh every request       | `loader()` + `useLoader()`       | /loader                 |
+| cache a rendered subtree              | `cache()` on a segment           | /caching                |
+| cache one function/component's result | `"use cache"`                    | /use-cache              |
+| cache a loader's data                 | `loader(L, () => [cache()])`     | /loader, /caching       |
+| re-render a segment after an action   | `revalidate()`                   | /loader                 |
+| mutate                                | `"use server"` action            | /server-actions         |
+| debug a slow request                  | `debugPerformance` / telemetry   | /observability          |
+| share config across routes            | factory returning a helper array | /composability          |
+| compose a sub-app / module            | `include()`                      | /route                  |
+| modal / soft navigation               | `intercept()`                    | /intercept              |
+| pre-render a route at build time      | `Prerender(...)` wrapper         | /prerender              |
+| stream SSE / upgrade a WebSocket      | `path.stream()` / `path.any()`   | /streams-and-websockets |
+
+## Invariants
+
+- `path()`/`include()` are always visible in `urls()`; config helpers are extractable.
+- **Cache decides freshness; `revalidate()` decides client-update.** Orthogonal; compose.
+- Loaders resolve fresh every request (even inside `cache()`) and never run twice/request.
+- Inside `"use cache"`: `cookies()`/`headers()` and `ctx` side-effects
+  (`set`/`header`/`setTheme`/`onResponse`/`setLocationState`) throw; `ctx.use(Handle)`
+  is captured on miss and replayed on hit. (The non-cacheable read guard is a
+  separate `cache()`-boundary check — see the correctness bullet below.)
+- One identity `path#export` (`functionId`/`$$id`/`actionId`); one store. The
+  cross-cutting freshness mechanism today is TTL/SWR expiry; cache entries accept
+  an optional `tags` field, but built-in stores do not yet index or invalidate by
+  tag, so `revalidateTag` is forward-looking (requires a custom store).
+- `useLoader` / `useHandle` / `useFetchLoader` are client-only.
+- Caches are correctness-first: persistent store keys are version-segmented (no
+  cross-deploy drift), the forward/back cache is mutation-aware, and
+  `createVar({ cache: false })` throws on a **direct** read inside a `cache()`
+  boundary (a deliberately non-propagating guard). See `/cache-guide` →
+  "Correctness & invalidation".
+- Nested caches: the outer cache window bounds the inner — an inner shorter TTL
+  only applies when the enclosing cache recomputes; put a value in a loader if it
+  must be fresher. See `/cache-guide` → "Combining Both".
+
+## Don't confuse
+
+- `revalidate()` ≠ cache invalidation — partial-render selection vs value freshness.
+- host router `.lazy()` (lazy import of a handler/sub-app) vs `.map()` (inline Response).
+- `cache()` (segment, in the DSL) vs `"use cache"` (function/component directive).
+- `loader()` registration (server) vs `useLoader()` consumption (client).
+
+### Coming from another framework (false friends)
+
+Same words, different jobs — this is the most common source of the
+`revalidate()`-is-caching misread.
+
+| You may know                               | Maps to Rango axis | Watch out                                                                                                                                                                                                                       |
+| ------------------------------------------ | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Next.js `export const revalidate = N`      | **Axis 1** (cache) | Same word, opposite meaning. Next's `revalidate` is time-based cache expiry; Rango's `revalidate()` is **axis 2**. Use `cache({ ttl })` for the Next behavior.                                                                  |
+| Next.js `revalidatePath` / `revalidateTag` | **Axis 1** (cache) | Cache busting. No shipped equivalent: entries accept `tags`, but built-in stores don't yet index/invalidate by tag, so `revalidateTag` is forward-looking (custom store); today entries expire by TTL/SWR. No `revalidatePath`. |
+| React Router / Remix `shouldRevalidate`    | **Axis 2**         | This is the correct mental model for Rango's `revalidate()`.                                                                                                                                                                    |
+| HTTP `Cache-Control` / ISR                 | **Axis 1**         | Edge/document layer — see `/document-cache`. Separate from both `cache()` and `revalidate()`.                                                                                                                                   |
+| Remix/RR `loader`                          | live data          | Like Rango loaders, fresh per request — but Rango loaders run in parallel and stream (latency overlaps first paint), and can opt into caching on demand.                                                                        |
+
+See `/cache-guide` for the axis-1 decision guide, `/loader` and `/route` for
+`revalidate()` (axis 2), and `/document-cache` for the edge layer.
+
+## Canonical shape
+
+```ts
+export const urlpatterns = urls(({ path, layout, loader, loading, cache, revalidate }) => [
+  layout(<ShopLayout />, () => [                 // structure: wraps children
+    loader(CartLoader, () => [                   // config: live data
+      // partial-render axis: re-run on cart actions, defer otherwise.
+      // ctx.isAction() matches by reference (rename-safe), not by string.
+      revalidate((ctx) => ctx.isAction(CartActions) || undefined),
+    ]),
+    path("/shop/:slug", ProductPage, { name: "product" }, () => [  // structure: leaf
+      loader(ProductLoader, () => [cache({ ttl: 60 })]),  // config: cache loader DATA
+      loading(<ProductSkeleton />),              // config
+      withRecs(),                                // composed factory (config array)
+    ]),
+  ]),
+]);
+```
+
+One tree, both axes visible: structure (`layout`/`path`) vs config (everything
+else), freshness (`cache`) vs client-update (`revalidate`). Actions are matched
+by reference with `ctx.isAction(Action)` (rename-safe, where `CartActions` is an
+`import * as CartActions from "./actions/cart"`); see `/typesafety` → "Stable
+identity".
+
+The predicate arg carries the action's full context, not just its identity. Match
+_which_ action with `ctx.isAction(addToCart)` (rename-safe); branch on _what it
+returned_ with `ctx.actionResult` — the value your `"use server"` function
+returned, for outcome-conditional revalidation. The arg also exposes `actionId`
+(raw `path#export`), `actionUrl`, `formData`, `method`, and `stale` (cross-tab
+`_rsc_stale` signal). All are `undefined` on plain navigation (no action).
+
+```ts
+// re-render only when checkout actually succeeded; defer otherwise
+revalidate((ctx) => (ctx.isAction(checkout) && ctx.actionResult?.ok) || undefined),
+```
+
+**The source is the source of truth.** Structure, types, and update policy are
+visible and local in the tree — read top-down, no hidden global model to hold in
+your head. A snippet earns its place only if, from the code alone, you can answer:
+_what URLs exist and who owns them?_ (composition), _can I trust this reference
+without leaving the call site?_ (type-safety), _what re-renders after this
+action?_ (partial rendering). If any answer needs another file, it isn't legible
+yet.
+
+**Reading Rango's own source.** Rango is consumed as raw TypeScript — the
+`exports` map resolves `@rangojs/router` and its subpaths to `./src/*.ts` for
+both types and runtime, so a consuming app bundles Rango straight from source.
+Only the `./vite` plugin entry and the CLI `bin` load from `dist/`. To confirm
+any runtime or type detail against an installed copy, read the resolved source
+under `node_modules/@rangojs/router/src/`, not `dist/` — the runtime does not
+resolve `dist/` outside `./vite`, and it may lag `src/`.
+
 ## Skills
 
-| Skill              | Description                                                                |
-| ------------------ | -------------------------------------------------------------------------- |
-| `/router-setup`    | Create and configure the RSC router                                        |
-| `/route`           | Define routes with `urls()` and `path()`                                   |
-| `/layout`          | Layouts that wrap child routes                                             |
-| `/loader`          | Data loaders with `createLoader()`                                         |
-| `/middleware`      | Request processing and authentication                                      |
-| `/intercept`       | Modal/slide-over patterns for soft navigation                              |
-| `/parallel`        | Multi-column layouts and sidebars                                          |
-| `/caching`         | Segment caching with memory or KV stores                                   |
-| `/use-cache`       | Function-level caching with `"use cache"` directive                        |
-| `/cache-guide`     | When to use `cache()` vs `"use cache"` — differences and decision guide    |
-| `/document-cache`  | Edge caching with Cache-Control headers                                    |
-| `/theme`           | Light/dark mode with FOUC prevention                                       |
-| `/links`           | URL generation: ctx.reverse, href, useHref, useMount, scopedReverse        |
-| `/hooks`           | Client-side React hooks                                                    |
-| `/typesafety`      | Type-safe routes, params, href, and environment                            |
-| `/host-router`     | Multi-app host routing with domain/subdomain patterns                      |
-| `/tailwind`        | Set up Tailwind CSS v4 with `?url` imports                                 |
-| `/response-routes` | JSON/text/HTML/XML/stream endpoints with `path.json()`, `path.text()`      |
-| `/mime-routes`     | Content negotiation — same URL, different response types via Accept header |
-| `/fonts`           | Load web fonts with preload hints                                          |
+Grouped by concern — read when you need to…
+
+**Structure & routing** — shape URLs, layouts, navigation, and request processing:
+
+| Skill                     | Description                                                                |
+| ------------------------- | -------------------------------------------------------------------------- |
+| `/router-setup`           | Create and configure the RSC router                                        |
+| `/route`                  | Define routes with `urls()`, `path()`, and `include()`                     |
+| `/layout`                 | Layouts that wrap child routes                                             |
+| `/parallel`               | Multi-column layouts and sidebars                                          |
+| `/intercept`              | Modal/slide-over patterns for soft navigation                              |
+| `/middleware`             | Request processing and authentication                                      |
+| `/host-router`            | Multi-app host routing with domain/subdomain patterns                      |
+| `/links`                  | URL generation: ctx.reverse, href, useHref, useMount, scopedReverse        |
+| `/response-routes`        | JSON/text/HTML/XML/stream endpoints with `path.json()`, `path.text()`      |
+| `/mime-routes`            | Content negotiation — same URL, different response types via Accept header |
+| `/streams-and-websockets` | SSE via `path.stream` and WebSocket upgrades via `path.any`                |
+| `/handler-use`            | Attach default loaders/middleware to a handler via `handler.use`           |
+| `/composability`          | Reusable route-helper factories (structure vs config)                      |
+
+**Data & caching** — fetch, mutate, and cache:
+
+| Skill             | Description                                                             |
+| ----------------- | ----------------------------------------------------------------------- |
+| `/loader`         | Data loaders with `createLoader()` and `revalidate()`                   |
+| `/server-actions` | Mutations with `"use server"`, useActionState, validation, revalidation |
+| `/caching`        | Segment caching with memory or KV stores                                |
+| `/use-cache`      | Function-level caching with `"use cache"` directive                     |
+| `/cache-guide`    | When to use `cache()` vs `"use cache"` — differences and decision guide |
+| `/document-cache` | Edge caching with Cache-Control headers                                 |
+| `/prerender`      | Pre-render route segments at build time (Passthrough live fallback)     |
+
+**Client & presentation** — build the client-side UX:
+
+| Skill               | Description                                                               |
+| ------------------- | ------------------------------------------------------------------------- |
+| `/hooks`            | Client-side React hooks                                                   |
+| `/theme`            | Light/dark mode with FOUC prevention                                      |
+| `/i18n`             | Locale routing with `:locale?`, resolution chains, react-intl integration |
+| `/fonts`            | Load web fonts with preload hints                                         |
+| `/tailwind`         | Set up Tailwind CSS v4 with `?url` imports                                |
+| `/view-transitions` | React View Transitions on layouts, routes, and parallel slots             |
+| `/breadcrumbs`      | Built-in Breadcrumbs handle for breadcrumb navigation                     |
+| `/react-compiler`   | Enable React Compiler (opt-in) the vite-rsc way; client-only scope        |
+
+**Observability & production health**:
+
+| Skill              | Description                                                              |
+| ------------------ | ------------------------------------------------------------------------ |
+| `/observability`   | `debugPerformance`, `Server-Timing`, structured telemetry, tracing       |
+| `/bundle-analysis` | Audit your app's production bundle for server leaks and oversized chunks |
+| `/debug-manifest`  | Inspect route manifest structure                                         |
+
+**Testing**:
+
+| Skill      | Description                                                                                                                     |
+| ---------- | ------------------------------------------------------------------------------------------------------------------------------- |
+| `/testing` | Unit (loaders/middleware/reverse/components), integration (dispatch/Flight), and e2e (dev+prod parity, progressive enhancement) |
+
+**Setup, types & migration**:
+
+| Skill                   | Description                                     |
+| ----------------------- | ----------------------------------------------- |
+| `/typesafety`           | Type-safe routes, params, href, and environment |
+| `/migrate-nextjs`       | Migrate a Next.js App Router project to Rango   |
+| `/migrate-react-router` | Migrate a React Router / Remix project to Rango |
 
 ## Quick Start
 
@@ -87,6 +298,15 @@ Each file is classified by its contents:
 Directories are scanned recursively for `.ts`/`.tsx` files, skipping `node_modules`,
 dotfiles, and existing `.gen.` files.
 
+> The two generated files are **not interchangeable surfaces**.
+> `router.named-routes.gen.ts` augments the global `GeneratedRouteMap` for
+> named-route typing (`Handler<"name">`, `ctx.reverse("name")`, prerender).
+> Per-module `*.gen.ts` exports a local `routes` map for `useReverse(routes)`
+> and explicit local handler typing (`Handler<".name", routes>`). Neither
+> carries response payloads — response/MIME payload inference comes from
+> `typeof router.routeMap` via `RegisteredRoutes`, not `*.named-routes.gen.ts`.
+> See `/typesafety` for the full surface breakdown.
+
 ### Recursive includes
 
 The generator follows `include()` calls across files, resolving imports to build

package/skills/react-compiler/SKILL.md

@@ -0,0 +1,168 @@
+---
+name: react-compiler
+description: Enable the React Compiler in a Rango app the @vitejs/plugin-rsc way — a separate @rolldown/plugin-babel running reactCompilerPreset(), ordered after react() and before the plugin that supplies @vitejs/plugin-rsc. Use when a consumer wants to turn React Compiler on, hits the dead plugin-react v6 `react({ babel })` path, or is unsure why server components aren't being compiled.
+argument-hint:
+---
+
+# React Compiler
+
+React Compiler is **opt-in** in Rango. The plugin pipeline is fully compatible —
+you just add one more plugin. The catch on a current Rango stack (Vite 8 +
+`@vitejs/plugin-react` v6) is that **v6 dropped its internal Babel for oxc**, so
+the way the React docs and most blog posts show it — `react({ babel: { plugins:
+[...] } })` — silently does nothing. The compiler has to be its own top-level
+plugin.
+
+## The shape (read first)
+
+- The compiler is a **Babel** plugin, run via
+  [`@rolldown/plugin-babel`](https://www.npmjs.com/package/@rolldown/plugin-babel)
+  with `reactCompilerPreset()` from `@vitejs/plugin-react`.
+- **Ordering is load-bearing:** put `babel(...)` **after `react()`** and
+  **before the plugin that supplies `@vitejs/plugin-rsc`**. In a default Rango
+  app that plugin is `rango()` itself; in a Cloudflare app it is
+  `@cloudflare/vite-plugin`.
+- **It is client-only.** `reactCompilerPreset()` gates itself to the client
+  environment. Server/RSC components are not compiled, and that is the upstream
+  example's behavior — not a Rango limitation. See
+  [What gets compiled](#what-gets-compiled-client-only).
+- **Rango's build-time prerender is unaffected.** You do not need to do anything
+  special. See [Prerender](#interaction-with-build-time-prerender).
+
+## Step 1: Install
+
+```bash
+pnpm add -D @rolldown/plugin-babel @babel/core babel-plugin-react-compiler
+# TypeScript users also want the Babel core types:
+pnpm add -D @types/babel__core
+```
+
+React 19 ships `react/compiler-runtime` in-tree, so there is **no** extra runtime
+to install and **no** `target` option to set. Only pass `target: '17' | '18'` to
+`reactCompilerPreset()` if you are on an older React.
+
+## Step 2: Wire it in
+
+### Default (non-Cloudflare) app
+
+```ts
+// vite.config.ts
+import { defineConfig } from "vite";
+import react, { reactCompilerPreset } from "@vitejs/plugin-react";
+import babel from "@rolldown/plugin-babel";
+import { rango } from "@rangojs/router/vite";
+
+export default defineConfig({
+  plugins: [
+    react(),
+    babel({ presets: [reactCompilerPreset()] }),
+    rango(), // supplies @vitejs/plugin-rsc
+  ],
+});
+```
+
+### Cloudflare app
+
+```ts
+// vite.config.ts
+import { cloudflare } from "@cloudflare/vite-plugin";
+import react, { reactCompilerPreset } from "@vitejs/plugin-react";
+import babel from "@rolldown/plugin-babel";
+import { defineConfig } from "vite";
+import { rango } from "@rangojs/router/vite";
+
+export default defineConfig({
+  plugins: [
+    react(),
+    babel({ presets: [reactCompilerPreset()] }),
+    rango({ preset: "cloudflare" }),
+    cloudflare({
+      /* ... */
+    }), // supplies @vitejs/plugin-rsc
+  ],
+});
+```
+
+## What gets compiled (client-only)
+
+`reactCompilerPreset()` carries
+`rolldown.applyToEnvironmentHook: (env) => env.config.consumer === "client"`, so
+even though the babel plugin is top-level, the transform runs **only in the
+`client` environment**:
+
+| Environment | `consumer` | Compiled? |
+| ----------- | ---------- | --------- |
+| client      | `client`   | Yes       |
+| ssr         | `server`   | No        |
+| rsc         | `server`   | No        |
+
+This matches the upstream `@vitejs/plugin-rsc` example. If you genuinely need to
+compile **server** components, you would have to invoke
+`babel-plugin-react-compiler` yourself without the preset's
+`applyToEnvironmentHook` — that is outside what the example does and is not
+covered here.
+
+## Options
+
+`reactCompilerPreset()` forwards to `babel-plugin-react-compiler`:
+
+| Option                          | Effect                                                                                 |
+| ------------------------------- | -------------------------------------------------------------------------------------- |
+| `compilationMode: 'annotation'` | Compile only components marked with the `"use memo"` directive, not every eligible one |
+| `target: '17' \| '18'`          | Emit `react-compiler-runtime` calls for React < 19. Omit on React 19+.                 |
+
+## Interaction with build-time prerender
+
+Nothing to configure. Rango's discovery/prerender step runs a throwaway temp Vite
+server (`createTempRscServer`) that forwards only your **resolution** plugins
+(`resolveId` / `load`). A pure transform plugin like `@rolldown/plugin-babel` is
+intentionally **not** forwarded — and that is correct: the temp runner only
+produces **data** (serialized Flight payloads + the route manifest), not shipped
+code, and React Compiler is a memoization-only transform that does not change
+rendered output. Your shipped client bundle still gets compiled, because the
+babel plugin lives in your app's top-level plugin array alongside `react()`.
+
+## Step 3: Verify the compiler actually ran
+
+A compiled module imports the cache allocator from `react/compiler-runtime` and
+calls `_c(n)`. Those two appear in **every** compiled module, so they are the
+reliable per-module signal in dev:
+
+```bash
+pnpm dev
+# fetch any client component module straight from Vite and look for the markers:
+curl -s "http://localhost:5173/src/components/SomeClientComponent.tsx" \
+  | grep -E "compiler-runtime|_c\("
+```
+
+For a production build, grep the built client bundle for the compiler's
+input-independent cache check, which has a **zero baseline** without the compiler:
+
+```bash
+pnpm build
+grep -r "Symbol.for(\"react.memo_cache_sentinel\")" dist/client/assets/ | head
+```
+
+Note the **comparison** form `$[i] === Symbol.for("react.memo_cache_sentinel")`
+is only emitted for components with input-independent JSX, so it is reliable over
+the **whole** client bundle, not necessarily in one chosen module. (React core
+also defines that symbol once with a single `=` assignment, so count comparisons,
+not the bare string.) Run the same grep over `dist/rsc` / `dist/ssr` and you
+should find **none** — that is the client-only contract.
+
+## Troubleshooting
+
+| Symptom                                                               | Cause / fix                                                                                                                                 |
+| --------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- |
+| Nothing is compiled; no `compiler-runtime` import anywhere            | You used `react({ babel: { plugins: [...] } })`. plugin-react v6 has no internal Babel — add `@rolldown/plugin-babel` as its own plugin.    |
+| Client compiled, but server/RSC components are not                    | Expected. `reactCompilerPreset()` is client-only (see the table). Not a bug.                                                                |
+| `Cannot find module 'babel-plugin-react-compiler'` (or `@babel/core`) | Install the peer deps from Step 1; they are not bundled by `reactCompilerPreset()`.                                                         |
+| Build pulls in `react-compiler-runtime`                               | You set `target: '17'`/`'18'` on React 19. Drop `target` — React 19 ships `react/compiler-runtime` in-tree.                                 |
+| Output looks compiled but a component misbehaves                      | The component likely breaks the Rules of React. Fix the component, or scope the compiler with `compilationMode: 'annotation'` while you do. |
+
+## Reference
+
+A worked, tested wiring (dev + production e2e markers, incl. the client-only
+contract) lives in the `@rangojs/router` repo: `docs/react-compiler.md` and the
+`react-compiler.test.ts` files under `e2e/e2e-basic`, `tests/cloudflare-basic`,
+and `tests/vite-rsc-demo`.

package/skills/response-routes/SKILL.md

@@ -236,22 +236,69 @@ type ProductsData = RouteResponse<typeof apiPatterns, "products">;
 // = ResponseEnvelope<{ id: string; name: string; price: number }[]>
 ```
 
-### PathResponse (global lookup by URL pattern)
+### Rango.PathResponse (global lookup by URL pattern or concrete path)
 
-Look up response type from the merged route map by URL pattern:
+`Rango.PathResponse` is ambient (no import) and reads from `RegisteredRoutes`,
+which carries response payload metadata. That surface is **not** auto-wired —
+without the augmentation below, `Rango.PathResponse` falls back to the generated
+path/search map, or to a permissive map when nothing is generated. Either way, it
+has no response payload metadata, so response routes resolve to
+`ResponseEnvelope<never>`:
 
 ```typescript
-import type { PathResponse } from "@rangojs/router/client";
+// router.tsx
+export const router = createRouter({ document: Document }).routes(urlpatterns);
 
+declare global {
+  namespace Rango {
+    interface RegisteredRoutes extends typeof router.routeMap {}
+  }
+}
+```
+
+With that in place, look up the response type by URL pattern (ambient, no import):
+
+```typescript
 // After include("/api", apiPatterns) in main urls
-type Health = PathResponse<"/api/health">;
+type Health = Rango.PathResponse<"/api/health">;
 // = ResponseEnvelope<{ status: string; timestamp: number }>
 
 // RSC routes return ResponseEnvelope<never>
-type Home = PathResponse<"/">;
+type Home = Rango.PathResponse<"/">;
 // = ResponseEnvelope<never>
 ```
 
+`Rango.PathResponse` also accepts a **concrete path**, so it types a `fetch`
+wrapper whose response is inferred from the path you pass:
+
+```typescript
+import { href } from "@rangojs/router/client";
+
+async function get<T extends Rango.Path>(
+  path: T,
+): Promise<Rango.PathResponse<T>> {
+  return fetch(href(path)).then((r) => r.json());
+}
+
+const product = await get("/api/products/42"); // ResponseEnvelope<Product>
+```
+
+Pattern keys (`/:id`) match exactly; a concrete path under a _nested_ dynamic
+route can match several patterns and union their responses.
+
+`Rango.PathResponse` reports the JSON **wire** shape, not the handler's raw
+return: `path.json()` serializes with `JSON.stringify`, so a handler returning
+`{ createdAt: Date }` resolves to `ResponseEnvelope<{ createdAt: string }>`. This
+runs through the ambient `Rango.JsonSerialize<T>` transform (`Date -> string`,
+honors `toJSON()`, drops functions/`undefined`, `bigint -> never`). The
+`RouteResponse` surface below applies the same `Rango.JsonSerialize` transform, so
+both response lookups report the identical wire shape.
+
+For local/scoped response typing without global augmentation, prefer
+`RouteResponse<typeof patterns, "routeName">` (see the section above) — it reads
+the response payload straight from the `urls()` patterns and needs no
+`RegisteredRoutes` wiring.
+
 ### ParamsFor with Response Routes
 
 ```typescript
@@ -361,14 +408,16 @@ export const urlpatterns = urls(({ path, include }) => [
 
 ```typescript
 import type { RouteResponse } from "@rangojs/router";
-import type { PathResponse, ParamsFor } from "@rangojs/router/client";
+import type { ParamsFor } from "@rangojs/router/client";
 
-// Scoped (before mount) -- use the module directly
+// Scoped (before mount) -- use the module directly, no global wiring needed
 type Stats = RouteResponse<typeof blogApiPatterns, "stats">;
 // = ResponseEnvelope<{ views: number; visitors: number }>
 
-// After mounting -- names get prefixed
-type BlogStats = PathResponse<"/blog/api/stats">;
+// After mounting -- names get prefixed.
+// Rango.PathResponse needs `RegisteredRoutes extends typeof router.routeMap` (see above),
+// otherwise it resolves to ResponseEnvelope<never>.
+type BlogStats = Rango.PathResponse<"/blog/api/stats">;
 // = ResponseEnvelope<{ views: number; visitors: number }>
 
 // Params work through nested includes
@@ -400,6 +449,14 @@ path(
 Multiple response types can share the same URL pattern. See `/mime-routes` for the
 full content negotiation API (Accept header matching, Vary: Accept, multi-variant routes).
 
+## Long-Lived Responses (SSE / WebSocket)
+
+For Server-Sent Events (`path.stream`) and WebSocket upgrades (`path.any`
+returning a 101 / `webSocket` Response), see `/streams-and-websockets`.
+Upgrade responses flow through without reconstruction; `Vary` and
+`Server-Timing` are skipped, and stub headers are applied in place on a
+best-effort basis.
+
 ## How It Works
 
 1. `path.json()` tags the route at the trie level with a MIME type