@rangojs/router 0.16.0 → 0.18.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rangojs/router",
-  "version": "0.16.0",
+  "version": "0.18.0",
   "description": "Django-inspired RSC router with composable URL patterns",
   "keywords": [
     "react",
@@ -197,7 +197,7 @@
     "@opentelemetry/api": "^1.9.0",
     "@opentelemetry/context-async-hooks": "^2.9.0",
     "@opentelemetry/sdk-trace-base": "^2.9.0",
-    "@playwright/test": "^1.49.1",
+    "@playwright/test": "^1.62.0",
     "@testing-library/dom": "^10.4.1",
     "@testing-library/react": "^16.3.2",
     "@types/node": "^24.10.1",

package/skills/api-client/SKILL.md

@@ -5,6 +5,10 @@ description: Build a typed client for consuming your own response-route JSON API
 
 # Typed API Client
 
+Use this skill when first-party TypeScript code (a client component, another
+worker, a script) calls your own `path.json()` endpoints and you want typed
+params and payloads without writing `fetch` + URL building by hand.
+
 Response routes (`path.json()`) already ship typed responses — `RouteResponse<typeof patterns, "name">` resolves to the **bare payload**, inferred from your handler with no codegen. This skill wraps that inference in a small **typed client** so first-party TypeScript code calls your endpoints like functions instead of hand-writing `fetch` + URL building per call site.
 
 This is a **recipe, not a framework feature** — copy the helper below into your app. It depends only on **type-only** imports from `@rangojs/router` (`RouteResponse`, `ExtractParams`, `ProblemDetails`), which are erased at build time, so it runs anywhere a `fetch` does — **browser, worker, or server**. Nothing new to install or version.
@@ -14,7 +18,9 @@ This is a **recipe, not a framework feature** — copy the helper below into you
 ## What you get
 
 ```ts
-const api = createApiClient(apiShopPatterns, routes, { baseUrl });
+const api = createApiClient<typeof apiShopPatterns, typeof routes>(routes, {
+  baseUrl,
+});
 
 await api.health.get(); // no params → callable bare
 await api.product.get({ params: { productId } }); // params typed + required
@@ -31,8 +37,8 @@ await api.cart.post({ body: { productId, qty: 2 } }); // body sent as JSON
 
 ## The two inputs
 
-1. **The `urls()` patterns value** — the type source. `typeof apiShopPatterns` carries the per-route response payloads (`_responses`) and patterns (`_routes`).
-2. **The generated route map** — the name → pattern source. `rango generate` emits a per-module `<name>.gen.ts` exporting `routes`:
+1. **The `urls()` patterns type** — the type source, passed as the first type argument. `typeof apiShopPatterns` carries the per-route response payloads and patterns. Only the type is needed, so import it with `import type` (see Notes).
+2. **The generated route map** — the name → pattern source, passed as the value argument (and its `typeof` as the second type argument). `rango generate` emits a per-module `<name>.gen.ts` exporting `routes`:
 
 ```ts
 // api-shop.gen.ts (generated — do not edit)
@@ -44,7 +50,9 @@ export const routes = {
 } as const;
 ```
 
-Routes that declare a **search schema** are generated as objects instead — `index: { path: "/", search: { q: "string" } }`. The helper accepts both the string and `{ path }` forms. If a `urls()` block is mounted under a name prefix, build a local-keyed map from your global `NamedRoutes` so the keys match the block's route names (e.g. `{ catalog: NamedRoutes["apiShop.catalog"], ... } as const`).
+Routes that declare a **search schema** are generated as objects instead — `index: { path: "/", search: { q: "string" } }`. The helper accepts both the string and `{ path }` forms.
+
+The per-module map's keys are the block's local route names (matching `RouteResponse`), but its patterns are **mount-relative**: `"/catalog"`, not `"/api/shop/catalog"`. When the block is mounted under a URL prefix, either put the prefix in `baseUrl` (`` `${origin}/api/shop` ``) or build a local-keyed map of absolute patterns from the global `NamedRoutes` in `router.named-routes.gen.ts` (e.g. `{ catalog: NamedRoutes["apiShop.catalog"], ... } as const`).
 
 ## The helper (copy into your app)
 
@@ -54,6 +62,7 @@ import type {
   RouteResponse,
   ExtractParams,
   ProblemDetails,
+  UrlPatterns,
 } from "@rangojs/router";
 
 type SearchParams = Record<string, string | number | boolean>;
@@ -121,11 +130,12 @@ function fillPath(pattern: string, params?: Record<string, string>): string {
     .replace(/\/{2,}/g, "/");
 }
 
+// Both type arguments are explicit: TPatterns has no value to infer from,
+// and TypeScript does not mix explicit and inferred type arguments.
 export function createApiClient<
-  TPatterns,
-  const TRouteMap extends Record<string, RouteMapEntry>,
+  TPatterns extends UrlPatterns<any, any, Record<string, unknown>>,
+  TRouteMap extends Record<string, RouteMapEntry>,
 >(
-  _patterns: TPatterns,
   routeMap: TRouteMap,
   opts: { baseUrl?: string; fetch?: typeof fetch } = {},
 ): ApiClient<TPatterns, TRouteMap> {
@@ -179,11 +189,11 @@ export function createApiClient<
 ## Using it
 
 ```ts
-import { apiShopPatterns } from "./urls/api-shop";
+import type { apiShopPatterns } from "./urls/api-shop";
 import { routes } from "./urls/api-shop.gen";
 import { createApiClient, ApiError } from "./lib/api-client";
 
-const api = createApiClient(apiShopPatterns, routes, {
+const api = createApiClient<typeof apiShopPatterns, typeof routes>(routes, {
   baseUrl: import.meta.env.VITE_API_URL ?? "",
 });
 
@@ -202,8 +212,10 @@ try {
 ## Notes
 
 - **Client-safe by construction.** The helper imports only **types** from `@rangojs/router` (erased at build) and builds URLs itself by substituting `:params` into the pattern — it does **not** use `createReverse`, which is a server/RSC-only export that throws in the browser. So `createApiClient` works in client components, workers, and on the server alike.
+- **Import the `urls()` module with `import type`.** `urls()` only runs on the server: in client code a value import throws when the module loads, and it would pull the route handlers into the client bundle. A type import is erased at build, so the same call works in client components, workers and server code. The generated `*.gen.ts` map has no imports and is safe to import anywhere.
+- **Always pass both type arguments.** If you leave them out, `TPatterns` falls back to its constraint and every response is typed `never`, so the first property access on a result is a compile error rather than a silent `any`.
 - **Params are route-typed; search and body are not.** Path params come from the route pattern (`ExtractParams`), so they are precise and required. `search` is generically typed (`Record<string, string | number | boolean>`), and `body` is `unknown` (serialized to JSON). Typed request **input** needs a declared schema layer, which is intentionally out of scope here — thread per-route schemas in yourself if you want typed search/body.
-- **Verb-agnostic wire.** Rango response routes do not dispatch on HTTP method — `.get`/`.post`/etc. set the request method but hit the same handler. Use whichever verb reads best for the operation.
+- **Verb-agnostic wire.** Rango response routes do not dispatch on HTTP method — `.get`/`.post`/etc. set the request method but hit the same handler (branch on `ctx.request.method` inside it if you need to). Use whichever verb reads best for the operation. Response-route `cache()` only serves and stores GET/HEAD.
 - **Path building.** `fillPath` handles standard `:param`, optional `:param?`, and constrained `:param(a|b)` forms. For exotic patterns or strict trailing-slash policies, swap in your own builder (or the router's `reverse` on the server).
 - **Want a return-based style instead of throwing?** Branch on `res.ok` yourself: the wire is the bare value on 2xx and `ProblemDetails` on non-2xx (see `/response-routes`). Wrapping the calls in a `{ ok, data } | { ok: false, error }` result type is a small variation on the same helper.
 - **Third parties.** The typed client is TypeScript-only and needs your route types. External consumers in any language use the plain wire as-is (bare JSON + problem+json); no client required.

package/skills/breadcrumbs/SKILL.md

@@ -7,9 +7,14 @@ argument-hint: "[setup]"
 # Breadcrumbs
 
 Built-in handle for accumulating breadcrumb items across route segments.
-Handlers and loader bodies push items via `ctx.use(Breadcrumbs)`, and they
-are collected in parent-to-child order with automatic deduplication by
-`href`.
+Route, layout, and parallel-slot handlers and loader bodies push items via
+`ctx.use(Breadcrumbs)`; client components read the collected trail with
+`useHandle(Breadcrumbs)`. Items are collected in parent-to-child order with
+automatic deduplication by `href`.
+
+`Breadcrumbs` is exported from both `@rangojs/router` (server, for pushing) and
+`@rangojs/router/client` (for `useHandle`). For page titles and meta tags, use
+the `Meta` handle the same way.
 
 ## BreadcrumbItem Type
 
@@ -59,6 +64,20 @@ export const urlpatterns = urls(({ path, layout }) => [
 
 On `/blog/my-post`, breadcrumbs accumulate: `Home > Blog > my-post`.
 
+The push function also accepts a `Promise` of an item, or an async function
+(called immediately) that returns one:
+
+```typescript
+const breadcrumb = ctx.use(Breadcrumbs);
+breadcrumb(async () => {
+  const post = await getPost(ctx.params.slug);
+  return { label: post.title, href: `/blog/${post.slug}` };
+});
+```
+
+Either way the item is resolved before any consumer reads it — `useHandle`
+never sees a pending crumb.
+
 ## Pushing from Loaders
 
 A data-derived crumb belongs where the data lives — the loader body pushes
@@ -66,6 +85,8 @@ with the same API (handler parity), so routes without handlers (`useLoader`
 consumption, `clientUrls()` groups) still build trails:
 
 ```typescript
+import { Breadcrumbs, createLoader } from "@rangojs/router";
+
 export const ProductLoader = createLoader(async (ctx) => {
   const product = await getProduct(ctx.params.slug);
 
@@ -82,7 +103,16 @@ Delivery follows the loader race model: a push that beats the handler barrier
 is in the SSR'd document; a push after a slow fetch streams and applies
 client-side (`useHandle` re-renders when it lands). To guarantee document
 delivery, register the loader as `loader(Def, { ssr: false })` —
-see `/loader` → "Writing Handles from Loaders".
+see `/loader` → "Writing Handles from Loaders". On a `ppr` route the race is
+decided at capture: a loader without `ssr: false` never runs there, so its
+crumb is not in the shell and applies client-side on every HIT; with
+`ssr: false` the crumb bakes into the shell (`/ppr` → "On a shell HIT").
+Under `cache()` loader crumbs are not stored with the cached segments; the
+loader re-pushes them on every hit, so they appear once even without an `href`.
+A loader with its own `cache()` keeps its crumbs on its own hits too: they are
+replayed from the loader's cache entry. A crumb from a loader it awaits appears
+once even when a sibling loader or the handler reads that loader too; that live
+run's crumb replaces the cached one in the trail.
 
 ## Async Content
 
@@ -107,6 +137,13 @@ path("/product/:id", async (ctx) => {
 Async content is a `Promise<ReactNode>`. Resolve it in your component
 with React's `use()` hook wrapped in `<Suspense>`.
 
+A crumb the HANDLER pushes is handler output. In a route `cache()` entry and
+in a `ppr` shell it is stored resolved: the cache write, or the shell capture
+(within `ppr.captureTimeout`), waits for a `content` promise and for a
+`.defer()` slot (below), and every HIT replays the crumb as it was resolved
+then, without running the handler. For per-request crumb content, push it
+from a loader without `ssr: false` (see "Pushing from Loaders").
+
 ### Deferred content (decide now, resolve from a deep component)
 
 When the handler should DECIDE to push a crumb early but the value is produced
@@ -219,9 +256,11 @@ const count = useHandle(Breadcrumbs, (data) => data.length);
 
 ## Deduplication
 
-The built-in collect function deduplicates by `href`. If multiple segments
-push the same `href`, the last one wins. This prevents duplicates when
-navigating between sibling routes that share a common breadcrumb.
+The built-in collect function deduplicates by `href`: each `href` appears once,
+at the position of its **first** push, with the value of its **last** push. A
+child that re-pushes a parent's `href` therefore updates that crumb's label in
+place without reordering the trail. Items without a string `href` are kept
+as-is and skip deduplication.
 
 ## Passing as Props
 
@@ -246,7 +285,9 @@ function DashboardNav({ handle }: { handle: typeof Breadcrumbs }) {
   return (
     <nav>
       {crumbs.map((c) => (
-        <a href={c.href}>{c.label}</a>
+        <a key={c.href} href={c.href}>
+          {c.label}
+        </a>
       ))}
     </nav>
   );
@@ -256,20 +297,31 @@ function DashboardNav({ handle }: { handle: typeof Breadcrumbs }) {
 ## Complete Example
 
 ```typescript
+// document.tsx — passed to createRouter({ document: Document, ... })
+"use client";
+import type { ReactNode } from "react";
+import { Html } from "@rangojs/router/client";
+
+export function Document({ children }: { children: ReactNode }) {
+  return (
+    <html lang="en">
+      <head><Html.Meta /></head>
+      <body>{children}</body>
+    </html>
+  );
+}
+
 // urls.tsx
 import { urls, Breadcrumbs, Meta } from "@rangojs/router";
-import { Outlet, MetaTags } from "@rangojs/router/client";
-import { BreadcrumbNav } from "./components/BreadcrumbNav";
+import { Outlet } from "@rangojs/router/client";
+import { BreadcrumbNav } from "./components/BreadcrumbNav"; // the client component above
 
 function RootLayout() {
   return (
-    <html lang="en">
-      <head><MetaTags /></head>
-      <body>
-        <BreadcrumbNav />
-        <main><Outlet /></main>
-      </body>
-    </html>
+    <>
+      <BreadcrumbNav />
+      <main><Outlet /></main>
+    </>
   );
 }
 
@@ -342,9 +394,9 @@ second argument to `createHandle()`:
 import { createHandle } from "@rangojs/router";
 
 // With a collect function (reducer): collect is first arg, tag is second
-export const Breadcrumbs = createHandle<BreadcrumbItem, BreadcrumbItem[]>(
-  collectBreadcrumbs,
-  "__my_package_breadcrumbs__",
+export const PackageCrumbs = createHandle<CrumbItem, CrumbItem[]>(
+  collectCrumbs,
+  "__my_package_crumbs__",
 );
 
 // Without a collect function: pass undefined, then the tag
@@ -354,5 +406,6 @@ export const Warnings = createHandle<string>(
 );
 ```
 
-The tag must be globally unique and stable across builds. Without it,
-`createHandle` throws in development mode.
+The tag must be globally unique and stable across builds. Without it (and
+without a plugin-injected id), `createHandle` throws — in dev and in production
+builds. Only test runners fall back to a synthetic id.

package/skills/bundle-analysis/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: bundle-analysis
-description: Audit a Rango app's production bundle for server-side code leaking into the client, dev/prod React duplication, oversized chunks, and inefficient client-reference grouping. Use when investigating bundle size growth, before a production deploy, or when the client/SSR/RSC output suddenly balloons.
+description: Audit a Rango app's production bundle for server-side code leaking into the client, dev/prod React duplication, oversized chunks, and poor client-chunk grouping. Use when investigating bundle size growth, before a production deploy, or when the client/SSR/RSC output suddenly balloons.
 argument-hint: "<app-dir>"
 ---
 
@@ -13,11 +13,11 @@ Use this when you want **proof** that your Rango app is shipping the bundles you
 Your app builds in three Vite environments — `client`, `ssr`, and `rsc` — and each ships its own bundle. The most common bundle bugs in a Rango app are:
 
 1. **Server code leaking into the client.** A file that imports `node:fs`, calls a database, or contains action logic ends up in the client bundle because a client component pulled it in transitively. Symptom: your client bundle is much larger than expected, sometimes with imports that fail at runtime.
-2. **Both dev and prod React in the SSR/RSC bundle.** When `process.env.NODE_ENV` isn't folded at build time, React's CJS files ship both `.development.js` _and_ `.production.js` variants — doubling React's footprint. The Cloudflare vite plugin folds NODE_ENV automatically; vanilla `vite build` does it for client but not always for SSR/RSC.
+2. **Both dev and prod React in the SSR/RSC bundle.** When `process.env.NODE_ENV` isn't folded at build time, React's CJS files ship both `.development.js` _and_ `.production.js` variants — doubling React's footprint. The Cloudflare Vite plugin and rango's `vercel` preset fold NODE_ENV automatically; on the default `node` preset, `vite build` does it for the client but not always for SSR/RSC, so add the `define` from Step 2.
 3. **An oversized routes-manifest in your RSC worker.** The `virtual:rsc-router/routes-manifest/<routerId>` chunk holds your route trie and precomputed entries — large only in proportion to your route count. If it's surprisingly big, you may have unintentionally generated routes (e.g., parametrized fixtures) that bloated the trie.
-4. **Inefficient client-reference grouping.** Each `"use client"` boundary becomes a chunk. Too many small client components = many tiny chunks; one giant client component = one giant chunk that defeats code-splitting.
+4. **Poor client-chunk grouping.** `rango({ clientChunks })` decides how `"use client"` modules are grouped into browser chunks. The default groups them by route directory (`routes/<id>/**` → `app-<id>`), with flat folders like `src/components/` in one shared chunk; `clientChunks: false` ships one client chunk per router. A route that pulls in unrelated routes' client code, or one oversized shared chunk, points at the grouping.
 
-Tree-shaking does _not_ catch (1) generated data inlined as string literals or (2) data-dependent conditionals like React's. You need a visualizer.
+Tree-shaking does _not_ catch generated data inlined as string literals, or data-dependent conditionals like React's `NODE_ENV` branches. You need a visualizer.
 
 ## Step 1: Install the visualizer
 
@@ -64,9 +64,9 @@ export default defineConfig(({ command }) => ({
     // your existing plugins...
     ...analyze(),
   ],
-  // For non-Cloudflare apps, fold NODE_ENV explicitly so React's CJS files
-  // emit only the .production.js variants in SSR/RSC. Skip if your build
-  // setup already does this (the Cloudflare vite plugin does).
+  // For node-preset apps, fold NODE_ENV explicitly so React's CJS files
+  // emit only the .production.js variants in SSR/RSC. Skip it on the
+  // cloudflare and vercel presets, which already do this.
   define:
     command === "build"
       ? { "process.env.NODE_ENV": JSON.stringify("production") }
@@ -104,12 +104,12 @@ The treemap shows nested boxes; box area = uncompressed size. Hover for gzip/bro
 **Look for:**
 
 - **Your server code.** Any of your own files that contain database queries, secret keys, server actions implementation (not the action _reference_), or `node:` imports. If they appear in the client treemap with non-zero bytes, they leaked. Common causes:
-  - A shared module that mixes client and server code without a `"use client"` or `"use server"` directive.
+  - A shared module that mixes client-safe helpers and server-only code, imported from a `"use client"` component.
   - A barrel file (`index.ts`) that re-exports both client and server symbols. Tree-shaking should help, but `JSON.parse('{...}')` data and side-effecting top-level statements survive.
   - Client component imports a server-only utility through an indirect path (e.g., shared types file that pulls server modules).
 - **Multiple copies of the same package.** Look for two boxes with the same package name but different version paths. Usually means a transitive dep pinned a different version.
-- **The `@rangojs/router` chunk** should be roughly **50 KB gzip** (74 files). If significantly larger, you might be importing client-incompatible APIs from the wrong subpath.
-- **Per-route client-reference chunks** (named like `chunk-<hash>.js`). Each `"use client"` boundary can become its own chunk. If you have hundreds of tiny chunks, you may have over-split (every leaf component as a client component); if you have one massive 200 KB chunk, you've under-split (a wide client tree behind one boundary).
+- **The router runtime chunk** (`router-<hash>.js`) is around **40–45 KB gzip**; the Rango repository's CI caps it at 44 KB on its reference app. If yours is much larger, check that client components import from `@rangojs/router/client`, not from a server path.
+- **Per-route client chunks** (groups named like `app-<route>`, plus `app-fallback` for error/not-found boundaries). A route's chunk should hold that route's client components. One massive shared chunk usually means client components live in a flat folder (or `clientChunks: false`); move route-specific ones under a route directory or pass a `clientChunks` function (see `/router-setup`).
 
 ### Now check `ssr.html`
 
@@ -123,23 +123,23 @@ The treemap shows nested boxes; box area = uncompressed size. Hover for gzip/bro
 
 **Look for:**
 
-- **`virtual:rsc-router/routes-manifest`** should be **tiny** (< 1 KB). If it's > 100 KB, you're on an old version of `@rangojs/router` that inlined the trie eagerly — upgrade to a release that includes commit `d10a2470`.
-- **`virtual:rsc-router/routes-manifest/<hash>`** is the lazy per-router chunk. Its size is proportional to your route count. For a typical app: 5–50 KB gzip. For a stress-test app with thousands of routes: hundreds of KB. If yours is unexpectedly huge, check whether you're generating routes you don't need.
+- **`virtual:rsc-router/routes-manifest`** (the eager module) should be **tiny**: well under 2 KB gzip even with tens of thousands of routes. If it is large, route data is being inlined eagerly; report it (see below).
+- **`virtual:rsc-router/routes-manifest/<routerId>`** is the lazy per-router chunk. Its size is proportional to your route count. For a typical app: 5–50 KB gzip. For a stress-test app with thousands of routes: hundreds of KB. If yours is unexpectedly huge, check whether you're generating routes you don't need.
 - **`<your-router>.named-routes.gen.ts`** — generated route map. Should match your route count.
 - **Your action and loader implementations** — these run server-side. Expected to be here, not in client.
 - **Worker-incompatible code** (Node-only imports like `node:fs` that Cloudflare doesn't support). The build will usually fail before the analyzer runs, but if you're seeing runtime errors at the edge, the RSC treemap shows what made it in.
 
 ## Step 5: Fix what you find
 
-| Finding                                                  | Fix                                                                                                                                                                         |
-| -------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| Your server code in `client.html` (non-zero bytes)       | Audit the import chain. Add `"use server"` to server-only files. Move shared data out of barrel files. Use the `@rangojs/router/server` subpath for explicitly server APIs. |
-| Your server code in `client.html` listed but 0 bytes     | Tree-shaking already eliminated it. Cosmetic. Leave it.                                                                                                                     |
-| `react-dom-server.edge.development-*.js` in SSR or RSC   | Add the `define` block from Step 2 to your vite config.                                                                                                                     |
-| Routes-manifest > 100 KB gzip in RSC eager chunk         | Update `@rangojs/router` to a release that includes the lazy-only manifest fix.                                                                                             |
-| Same package version present twice                       | Run `pnpm dedupe` (or `npm dedupe`). If the duplication persists, a transitive dep pins an incompatible version — open a PR upstream or pin the resolution.                 |
-| Client chunk > 500 KB gzip with a single dominant module | That module is your largest client component. Consider lazy-loading via dynamic `import()` or moving non-interactive parts to server components.                            |
-| Hundreds of tiny client chunks                           | You've sprinkled `"use client"` too liberally. Hoist directives to higher boundaries so React groups them.                                                                  |
+| Finding                                                  | Fix                                                                                                                                                                                                                                                                                                                                                            |
+| -------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Your server code in `client.html` (non-zero bytes)       | Audit the import chain from the `"use client"` file. Add `import "server-only"` to server-only modules so the client build fails on the import (`@vitejs/plugin-rsc` checks it; no package install needed). Move shared data out of barrel files. Do not add `"use server"` to a utility module: that turns every export into a client-callable server action. |
+| Your server code in `client.html` listed but 0 bytes     | Tree-shaking already eliminated it. Cosmetic. Leave it.                                                                                                                                                                                                                                                                                                        |
+| `react-dom-server.edge.development-*.js` in SSR or RSC   | Add the `define` block from Step 2 to your vite config.                                                                                                                                                                                                                                                                                                        |
+| Eager routes-manifest is large in RSC                    | Update `@rangojs/router`; if it persists, report it as a regression.                                                                                                                                                                                                                                                                                           |
+| Same package version present twice                       | Run `pnpm dedupe` (or `npm dedupe`). If the duplication persists, a transitive dep pins an incompatible version — open a PR upstream or pin the resolution.                                                                                                                                                                                                    |
+| Client chunk > 500 KB gzip with a single dominant module | That module is your largest client component. Consider lazy-loading via dynamic `import()` or moving non-interactive parts to server components.                                                                                                                                                                                                               |
+| One route downloads other routes' client code            | Move route-specific client components under a route directory (`routes/<id>/`), or group them yourself with a `clientChunks` function.                                                                                                                                                                                                                         |
 
 ## When to re-run
 
@@ -156,4 +156,4 @@ If a finding looks like a `@rangojs/router` regression (the framework is shippin
 - The `@rangojs/router` version (`pnpm why @rangojs/router`).
 - Your `vite.config.ts`.
 
-The framework maintainers run a similar audit internally — the methodology in this skill mirrors what they use to validate every release.
+The Rango repository runs the same analysis in CI (client leak checks, a router-chunk size cap, and an eager-manifest ceiling).