@rangojs/router 0.0.0-experimental.111 → 0.0.0-experimental.113

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@rangojs/router",
-  "version": "0.0.0-experimental.111",
+  "version": "0.0.0-experimental.113",
   "description": "Django-inspired RSC router with composable URL patterns",
   "keywords": [
     "react",
@@ -132,15 +132,6 @@
     "access": "public",
     "tag": "experimental"
   },
-  "scripts": {
-    "build": "pnpm dlx esbuild src/vite/index.ts --bundle --format=esm --outfile=dist/vite/index.js --platform=node --packages=external && mkdir -p dist/vite/plugins && cp src/vite/plugins/cloudflare-protocol-loader-hook.mjs dist/vite/plugins/cloudflare-protocol-loader-hook.mjs && pnpm dlx esbuild src/bin/rango.ts --bundle --format=esm --outfile=dist/bin/rango.js --platform=node --packages=external --banner:js='#!/usr/bin/env node' && chmod +x dist/bin/rango.js",
-    "prepublishOnly": "pnpm build",
-    "typecheck": "tsc --noEmit && tsc -p tsconfig.strict-check.json --noEmit && tsc -p tsconfig.augment-check.json --noEmit",
-    "test": "playwright test",
-    "test:ui": "playwright test --ui",
-    "test:unit": "vitest run",
-    "test:unit:watch": "vitest"
-  },
   "dependencies": {
     "@types/debug": "^4.1.12",
     "@vitejs/plugin-rsc": "^0.5.26",
@@ -152,15 +143,16 @@
   "devDependencies": {
     "@playwright/test": "^1.49.1",
     "@types/node": "^24.10.1",
-    "@types/react": "catalog:",
-    "@types/react-dom": "catalog:",
+    "@types/react": "^19.2.7",
+    "@types/react-dom": "^19.2.3",
     "esbuild": "^0.27.0",
     "jiti": "^2.6.1",
-    "react": "catalog:",
-    "react-dom": "catalog:",
+    "react": "^19.2.6",
+    "react-dom": "^19.2.6",
     "tinyexec": "^0.3.2",
     "typescript": "^5.3.0",
-    "vitest": "^4.0.0"
+    "vitest": "^4.0.0",
+    "@shared/e2e": "0.0.1"
   },
   "peerDependencies": {
     "@cloudflare/vite-plugin": "^1.38.0",
@@ -176,5 +168,14 @@
     "vite": {
       "optional": true
     }
+  },
+  "scripts": {
+    "build": "pnpm dlx esbuild src/vite/index.ts --bundle --format=esm --outfile=dist/vite/index.js --platform=node --packages=external && mkdir -p dist/vite/plugins && cp src/vite/plugins/cloudflare-protocol-loader-hook.mjs dist/vite/plugins/cloudflare-protocol-loader-hook.mjs && pnpm dlx esbuild src/bin/rango.ts --bundle --format=esm --outfile=dist/bin/rango.js --platform=node --packages=external --banner:js='#!/usr/bin/env node' && chmod +x dist/bin/rango.js",
+    "typecheck": "tsc --noEmit && tsc -p tsconfig.strict-check.json --noEmit && tsc -p tsconfig.augment-check.json --noEmit",
+    "test": "playwright test",
+    "test:ui": "playwright test --ui",
+    "test:hmr-local": "playwright test --project=dev-warmup --project=hmr-routes --project=hmr-basename --project=hmr-prerender --no-deps --workers=1",
+    "test:unit": "vitest run",
+    "test:unit:watch": "vitest"
   }
-}
+}

package/skills/cache-guide/SKILL.md

@@ -6,8 +6,9 @@ argument-hint:
 
 # cache() vs "use cache" — When to Use Which
 
-Both mechanisms share the same backing store, cache profiles, and tag-based
-invalidation. They differ in scope, cache key, execution model, and runtime control.
+Both mechanisms share the same backing store and cache profiles, and both accept
+an optional `tags` field (not yet honored by the built-in stores — see "Two axes"
+below). They differ in scope, cache key, execution model, and runtime control.
 
 ## Two axes — do not conflate
 
@@ -17,7 +18,10 @@ caching:
 
 1. **Stored-value freshness** — _is a cached value still good?_
    → `"use cache"` (fn/component), `cache()` (segment), loader `cache()` (loader data).
-   Entries are coupled across the one store by **tags** (`revalidateTag`).
+   Entries expire by **TTL/SWR**. They accept an optional `tags` field, but the
+   built-in stores (`MemorySegmentCacheStore`, `CFCacheStore`) do not yet index or
+   invalidate by tag, so tag-based invalidation (`revalidateTag`) is a
+   forward-looking API requiring a custom store with secondary indices.
 2. **Client-update selection** — _should this segment re-run and stream to the
    client on this navigation/action?_
    → `revalidate()`. Covered in `/loader` and `/route`, **not here**.
@@ -58,12 +62,16 @@ There are two guard models to keep separate. Both block response side effects
 else they allow:
 
 - **`cache()` boundary guard** (route-level) — fires while the handler runs on a
-  miss. `ctx.get(nonCacheableVar)` throws (a tainted value would be baked into the
-  cached segment) and response side effects (`ctx.header()`, `ctx.setCookie()`,
+  miss. `cookies()` and `headers()` throw (request-scoped data would be baked into
+  the shared cached shell), `ctx.get(nonCacheableVar)` throws (a tainted value
+  would be baked in), and response side effects (`ctx.header()`, `ctx.setCookie()`,
   `ctx.setStatus()`, `ctx.onResponse()`) throw. `ctx.set()` of a cacheable var is
-  **allowed** — children are cached too and can read it.
-- **`"use cache"` exec-guard** (function-level) — stricter: inside the cached
-  function `cookies()`, `headers()`, `ctx.set()`, and `ctx.header()` all throw.
+  **allowed** — children are cached too and can read it. **Loaders are exempt**
+  (they always run fresh) — read request data inside a loader.
+- **`"use cache"` exec-guard** (function-level) — the same request-scoped APIs
+  throw inside the cached function (`cookies()`, `headers()`, `ctx.set()`,
+  `ctx.header()`); additionally, tainted `ctx`/`env`/`req` args are excluded from
+  the cache key.
 
 ### Cross-deploy safety: version-segmented store keys
 
@@ -331,18 +339,21 @@ specifies `cache: false`, the value is non-cacheable.
 
 **Behavior inside a `cache()` boundary:**
 
-| Operation                         | Inside a `cache()` boundary                        |
-| --------------------------------- | -------------------------------------------------- |
-| `ctx.get(cacheableVar)`           | Allowed                                            |
-| `ctx.get(nonCacheableVar)`        | Throws (would be baked in)                         |
-| `ctx.set(var, value)` (cacheable) | Allowed                                            |
-| `ctx.header()` / cookie writes    | Throws (response side effect would be lost on hit) |
-
-(Inside a `"use cache"` function the scoping differs: `ctx.set`, `ctx.header()`,
-`cookies()`, and `headers()` **throw** via the cache-exec guard. Inside
-`cache()`, response side effects throw via the cache-boundary guard, while the
-`ctx.get(nonCacheableVar)` taint check above is tied to the `cache()` boundary —
-see "Headers and Cookies" and the precise guarantee below.)
+| Operation                                 | Inside a `cache()` boundary                            |
+| ----------------------------------------- | ------------------------------------------------------ |
+| `cookies()` / `headers()` (read or write) | Throws (request-scoped, would poison the shared entry) |
+| `ctx.get(cacheableVar)`                   | Allowed                                                |
+| `ctx.get(nonCacheableVar)`                | Throws (would be baked in)                             |
+| `ctx.set(var, value)` (cacheable)         | Allowed                                                |
+| `ctx.header()` / cookie writes            | Throws (response side effect would be lost on hit)     |
+| Any of the above **inside a loader**      | Allowed (loaders always run fresh)                     |
+
+(Both scopes block the same request-scoped APIs — `cookies()`, `headers()`,
+response side effects, and non-cacheable `ctx.get()` — because each would leak
+per-request data into a shared cache entry. The `cache()` boundary tracks the
+scope via `isInsideCacheScope()`; `"use cache"` uses the exec guard and also
+excludes tainted `ctx`/`env`/`req` args from the cache key. Loaders are exempt in
+both — see "Headers and Cookies" and the precise guarantee below.)
 
 Write is dumb — `ctx.set()` stores the cache metadata but does not enforce.
 Enforcement happens at read time (`ctx.get()`), where ALS detects the cache
@@ -379,10 +390,10 @@ layout((ctx) => {
 So do **not** read this as "you can't cache user data" — that overstates it and
 breeds the false confidence that makes the derived leak _more_ likely. The guard
 is deliberately non-propagating (propagation would cost a wrapper per derivation
-on the hot path), and it is scoped to the `cache()` segment boundary — `"use
-cache"` functions guard request data differently (tainted `ctx`/`env`/`req` args
-are excluded from the cache key, and `cookies()` / `headers()` throw inside them;
-see "Headers and Cookies"). The pattern that stays safe is also the natural one:
+on the hot path), and it is scoped to the `cache()` segment boundary. `"use
+cache"` functions block the same request-scoped reads (`cookies()` / `headers()`
+throw inside them) and additionally exclude tainted `ctx`/`env`/`req` args from
+the cache key. The pattern that stays safe is also the natural one:
 **read tainted context at the point of use, in the path that needs it (a loader or
 live segment) — never extract user data into a plain value and cache that.**
 Loaders are exempt because they run outside the cache scope and resolve fresh

package/skills/caching/SKILL.md

@@ -8,6 +8,46 @@ argument-hint: [setup]
 
 @rangojs/router supports segment-level caching with stale-while-revalidate (SWR) for optimal performance.
 
+> SWR support is store-specific. `CFCacheStore` revalidates segment, response,
+> and `"use cache"` entries in the background. `MemorySegmentCacheStore`
+> supports SWR for response and `"use cache"` item entries, but its
+> route-segment entries expire at TTL with no background revalidation — use
+> `CFCacheStore` for real segment SWR. See `/cache-guide`.
+
+## cache() is Partial Prerendering (PPR)
+
+`cache()` caches **everything except loaders**. On a cache hit, the cached
+segments (layouts, route components, parallels — including any resolved
+Suspense) are served from the store, and **loaders re-run fresh on every
+request**, streaming their results into the same response. Loaders are the
+dynamic "holes" of an otherwise-cached tree.
+
+This means a `cache()` boundary at the document root **is** whole-document
+Partial Prerendering: the static shell is cached and served instantly while
+per-request/per-user data stays live — in one streamed response, no extra round
+trip. The browser cannot tell the shell came from cache.
+
+```typescript
+cache({ ttl: 60, swr: 300 }, () => [
+  layout(<RootLayout />), // cached shell
+  path("/dashboard", Dashboard, { name: "dashboard" }, () => [
+    loader(StatsLoader), // DYNAMIC HOLE — re-runs every request
+  ]),
+]);
+```
+
+The consumer rule: **want it cached? render it inline. want it dynamic? put it
+in a loader and read it with `useLoader()` in a client component.** Anything
+read with `cookies()`, `headers()`, or a non-cacheable variable belongs in a
+loader (loaders always run fresh). Reading it directly in a cached handler
+throws; awaiting it with `ctx.use()` and rendering the result in a cached
+handler silently bakes per-request data into the shared shell (see "Cache purity
+& tainted objects" below).
+
+Pre-rendering (`/prerender`) is the build-time twin: it caches the same shell at
+build time instead of on first request. Both feed the segment system
+identically, and loaders always run fresh at request time.
+
 ## Route-Level Caching with cache()
 
 Use the `cache()` DSL function to cache routes:
@@ -116,7 +156,6 @@ import { MemorySegmentCacheStore } from "@rangojs/router/cache";
 
 const store = new MemorySegmentCacheStore({
   defaults: { ttl: 60, swr: 300 },
-  maxSize: 1000, // Max entries
 });
 ```
 
@@ -173,13 +212,82 @@ const router = createRouter<AppBindings>({
 KV entries require `expirationTtl >= 60s`. Short-lived entries (< 60s total TTL)
 are only cached in L1.
 
-## Context Variables Inside Cache Boundaries
+## Cache purity & tainted objects
+
+A `cache()` boundary caches everything except loaders, so anything read inside a
+cached handler is **frozen into the shared cache entry** and served to every
+subsequent visitor. To stop one user's request-scoped data from leaking to
+another, request-scoped APIs are guarded inside a cache scope:
+
+| Inside a `cache()` boundary                                     | Behavior                                            |
+| --------------------------------------------------------------- | --------------------------------------------------- |
+| `cookies()` / `headers()` (read or write)                       | **throws** — request-scoped, would poison the entry |
+| `ctx.header()` / `setCookie()` / `setStatus()` / `onResponse()` | **throws** — response side effects lost on a hit    |
+| `ctx.get(var)` where the var is `{ cache: false }`              | **throws** on read                                  |
+| `ctx.set(var, value)` for a cacheable var                       | allowed (children are cached too)                   |
+| Any of the above **inside a loader**                            | **allowed** — loaders always run fresh              |
+
+**Tainted objects.** Request-scoped objects (`ctx`, `env`, `request`) carry an
+internal taint symbol so they are excluded from `"use cache"` cache keys, and
+the cache scope is tracked via async-local state. Two flags back the guards:
+`INSIDE_CACHE_EXEC` (set while a `"use cache"` function runs) and the `cache()`
+DSL scope (`isInsideCacheScope()`). `isInsideCacheScope()` deliberately returns
+`false` inside loaders — which is exactly why loaders are the dynamic holes:
+they may read `cookies()`/`headers()` and re-run on every request.
+
+The fix for "I need request data in a cached route": register a `loader()` and
+**consume it with `useLoader()` in a client component**. The loader is the
+dynamic hole — its data rides the fresh (never-cached) loader segment and is
+rendered in the client component, so it never lands in the cached shell.
+
+This is NOT the same as awaiting the loader in the handler. A cached handler
+that does `await ctx.use(Loader)` and renders the result bakes that per-request
+data straight into the shared cached segment — the loader running "fresh" does
+not help, because its output was inlined into the cached parent, and `ctx.use()`
+is **not** guarded. `ctx.use()` is a server-side escape hatch for non-rendered
+uses (set a ctx var, make a routing decision); never render its result inside a
+cached handler.
+
+```typescript
+// WRONG — throws: cookies() read directly in a cached handler
+cache({ ttl: 60 }, () => [
+  path("/me", () => <Profile id={cookies().get("uid")?.value} />),
+]);
+
+// ALSO WRONG (unguarded, but leaks) — the awaited loader data is rendered into
+// the cached handler, so the user's data is frozen into the shared shell.
+cache({ ttl: 60 }, () => [
+  path(
+    "/me",
+    async (ctx) => {
+      const { user } = await ctx.use(MeLoader); // runs fresh…
+      return <Profile user={user} />; // …but inlined into the CACHED segment → leak
+    },
+    { name: "me" },
+    () => [loader(MeLoader)],
+  ),
+]);
+
+// RIGHT — consume the loader in a CLIENT component via useLoader(). The cached
+// route segment holds only the <Profile/> reference; the user data rides the
+// fresh loader segment and renders client-side.
+
+// profile.tsx (client component)
+"use client";
+import { useLoader } from "@rangojs/router/client";
+
+export function Profile() {
+  const { user } = useLoader(MeLoader); // fresh per request; never cached
+  return <span>{user.name}</span>;
+}
+
+// urls — register the loader; MeLoader reads cookies() inside the loader (allowed)
+cache({ ttl: 60 }, () => [
+  path("/me", () => <Profile />, { name: "me" }, () => [loader(MeLoader)]),
+]);
+```
 
-Context variables (`createVar`) are cacheable by default and can be read and
-written inside `cache()` scopes. Variables marked with `{ cache: false }` (at
-the var level or write level) throw when read inside a cache scope. Response
-side effects (`ctx.header()`, `ctx.cookie()`) always throw inside cache
-boundaries. See `/cache-guide` for the full cache safety table.
+See `/cache-guide` for the full decision guide and the `cache()` vs `"use cache"` comparison.
 
 ## Nested Cache Boundaries
 

package/skills/document-cache/SKILL.md

@@ -10,73 +10,82 @@ Caches complete HTTP responses (HTML/RSC) at the edge based on Cache-Control hea
 
 ## Setup
 
-Configure document cache in router:
+Document caching is a middleware. Add `createDocumentCacheMiddleware()` to the
+router with `.use()`. The cache store it reads from is the app-level store you
+configure on `createRouter({ cache })` (available on the request context as
+`requestCtx._cacheStore`), not a store passed to the middleware.
 
 ```typescript
 import { createRouter } from "@rangojs/router";
-import { CFCacheStore } from "@rangojs/router/cache";
+import {
+  createDocumentCacheMiddleware,
+  CFCacheStore,
+} from "@rangojs/router/cache";
 import { urlpatterns } from "./urls";
 
 const router = createRouter<AppBindings>({
   document: Document,
   urls: urlpatterns,
-  documentCache: (_env, ctx) => ({
-    store: new CFCacheStore({ ctx: ctx! }),
+  // App-level cache store. The document cache middleware uses this store's
+  // getResponse/putResponse methods.
+  cache: (_env, ctx) => new CFCacheStore({ ctx: ctx! }),
+});
+
+router.use(
+  createDocumentCacheMiddleware({
     skipPaths: ["/api", "/admin"],
     debug: process.env.NODE_ENV === "development",
   }),
-});
+);
 
 export default router;
 ```
 
-## Route Opt-In with cache()
+## Route Opt-In with Cache-Control
 
-Routes opt-in to document caching using the `cache()` DSL with `documentCache` option:
+Routes opt-in to document caching by setting a `Cache-Control` response header
+with `s-maxage`. The middleware caches responses whose `Cache-Control` includes
+`s-maxage`; `stale-while-revalidate` enables background revalidation (SWR).
 
 ```typescript
-import { urls } from "@rangojs/router";
-
-export const urlpatterns = urls(({ path, cache }) => [
-  // Cache full page for 5 min, serve stale for 1 hour
-  cache({ documentCache: { sMaxAge: 300, swr: 3600 } }, () => [
-    path("/blog", BlogIndex, { name: "blog" }),
-  ]),
-
-  // Long cache for individual posts
-  cache({ documentCache: { sMaxAge: 3600, swr: 86400 } }, () => [
-    path("/blog/:slug", BlogPost, { name: "blogPost" }),
-  ]),
-
-  // No cache for dashboard (no documentCache option)
-  path("/dashboard", Dashboard, { name: "dashboard" }),
-]);
+// Cache full page for 5 min, serve stale for 1 hour
+function BlogIndexHandler(ctx) {
+  ctx.headers.set("Cache-Control", "s-maxage=300, stale-while-revalidate=3600");
+  return <BlogIndex />;
+}
+
+// Long cache for individual posts
+function BlogPostHandler(ctx) {
+  ctx.headers.set("Cache-Control", "s-maxage=3600, stale-while-revalidate=86400");
+  return <BlogPost />;
+}
+
+// Dashboard sets no Cache-Control header, so it is never document-cached.
 ```
 
 ## Document Cache Options
 
-```typescript
-createRouter({
-  // ...
-  documentCache: (_env, ctx) => ({
-    // Cache store (required)
-    store: new CFCacheStore({ ctx: ctx! }),
+`createDocumentCacheMiddleware(options?)` accepts:
 
-    // Skip specific paths
-    skipPaths: ["/api", "/admin"],
+```typescript
+createDocumentCacheMiddleware({
+  // Skip specific paths (matched by pathname prefix)
+  skipPaths: ["/api", "/admin"],
 
-    // Custom cache key
-    keyGenerator: (url) => url.pathname,
+  // Custom cache key generator
+  keyGenerator: (url) => url.pathname,
 
-    // Conditional caching
-    isEnabled: (ctx) => !ctx.request.headers.has("x-preview"),
+  // Conditional caching, evaluated per request
+  isEnabled: (ctx) => !ctx.request.headers.has("x-preview"),
 
-    // Debug logging
-    debug: true,
-  }),
+  // Debug logging (HIT, MISS, STALE, REVALIDATED)
+  debug: true,
 });
 ```
 
+The cache store is not a middleware option — it comes from the app-level
+`createRouter({ cache })` store.
+
 ## How It Works
 
 ```
@@ -89,7 +98,7 @@ Request → Check Cache
     ↓             ↓
   Fresh?      Run handler
     │             │
-   Yes → Return   Has documentCache?
+   Yes → Return   Has s-maxage?
     │             │
    No (stale)    Yes → Cache + Return
     │             │
@@ -120,13 +129,14 @@ Segment hash ensures different cached responses for navigations from different s
 
 - Full HTML responses (document requests)
 - RSC payloads (client navigation)
-- Only 200 OK responses with documentCache enabled
+- Only 200 OK responses whose `Cache-Control` includes `s-maxage`
 
 ## What's NOT Cached
 
 - Server actions (`_rsc_action`)
 - Loader requests (`_rsc_loader`)
-- Routes without `documentCache` option
+- Non-GET requests
+- Responses without an `s-maxage` `Cache-Control` directive
 - Non-200 responses
 
 ## Complete Example
@@ -134,40 +144,53 @@ Segment hash ensures different cached responses for navigations from different s
 ```typescript
 // router.tsx
 import { createRouter } from "@rangojs/router";
-import { CFCacheStore } from "@rangojs/router/cache";
+import { createDocumentCacheMiddleware, CFCacheStore } from "@rangojs/router/cache";
 import { urlpatterns } from "./urls";
 
 const router = createRouter<AppBindings>({
   document: Document,
   urls: urlpatterns,
-  documentCache: (_env, ctx) => ({
-    store: new CFCacheStore({ ctx: ctx! }),
+  cache: (_env, ctx) => new CFCacheStore({ ctx: ctx! }),
+});
+
+router.use(
+  createDocumentCacheMiddleware({
     skipPaths: ["/api"],
     debug: process.env.NODE_ENV === "development",
   }),
-});
+);
 
 export default router;
 
 // urls.tsx
 import { urls } from "@rangojs/router";
 
-export const urlpatterns = urls(({ path, layout, cache, loader }) => [
-  // Blog with document caching
-  cache({ documentCache: { sMaxAge: 300, swr: 3600 } }, () => [
-    layout(<BlogLayout />, () => [
-      path("/blog", BlogIndex, { name: "blog" }),
-      path("/blog/:slug", BlogPost, { name: "blogPost" }, () => [
-        loader(BlogPostLoader),
-      ]),
+export const urlpatterns = urls(({ path, layout, loader }) => [
+  // Blog pages opt into document caching via Cache-Control headers set in
+  // their handlers (see BlogIndex / BlogPost below).
+  layout(<BlogLayout />, () => [
+    path("/blog", BlogIndex, { name: "blog" }),
+    path("/blog/:slug", BlogPost, { name: "blogPost" }, () => [
+      loader(BlogPostLoader),
     ]),
   ]),
 
-  // Dashboard - no document cache (dynamic content)
+  // Dashboard sets no Cache-Control header, so it is never document-cached.
   layout(<DashboardLayout />, () => [
     path("/dashboard", Dashboard, { name: "dashboard" }),
   ]),
 ]);
+
+// Blog handlers set s-maxage to opt into the document cache.
+function BlogIndex(ctx) {
+  ctx.headers.set("Cache-Control", "s-maxage=300, stale-while-revalidate=3600");
+  return <BlogIndexPage />;
+}
+
+function BlogPost(ctx) {
+  ctx.headers.set("Cache-Control", "s-maxage=300, stale-while-revalidate=3600");
+  return <BlogPostPage />;
+}
 ```
 
 ## Document Cache vs Segment Cache
@@ -175,7 +198,7 @@ export const urlpatterns = urls(({ path, layout, cache, loader }) => [
 | Feature      | Document Cache             | Segment Cache         |
 | ------------ | -------------------------- | --------------------- |
 | Granularity  | Full response              | Individual segments   |
-| Opt-in       | `documentCache` in cache() | `cache({ ttl, swr })` |
+| Opt-in       | `Cache-Control` `s-maxage` | `cache({ ttl, swr })` |
 | Use case     | Static pages               | Dynamic compositions  |
 | Key includes | URL + segment hash         | Route params          |
 

package/skills/hooks/SKILL.md

@@ -268,7 +268,11 @@ reads (keyed or not) reset on navigation from fresh route data, as before.
 **Refreshing multiple loaders together (`refreshGroup` + `useRefreshLoaders`)**:
 
 `key` groups readers of one loader. To refresh **different** loaders together,
-tag them with the same `refreshGroup` and trigger them with `useRefreshLoaders`:
+tag them with a shared `refreshGroup` name and trigger them with
+`useRefreshLoaders()`. The hook takes no argument; you pass the group(s) to the
+function it returns, so one `useRefreshLoaders()` can refresh different groups
+depending on context. A read may carry **several** tags — pass an array — and is
+refreshed when **any** of its groups is refreshed:
 
 ```tsx
 function Profile() {
@@ -279,33 +283,47 @@ function Profile() {
   return <span>{data.name}</span>;
 }
 function Orders() {
+  // Tagged into two groups: refreshed by "account" (the whole set) or the
+  // finer "orders" tag.
   const { data } = useLoader(OrdersLoader, {
     key: userId,
-    refreshGroup: "account",
+    refreshGroup: ["account", "orders"],
   });
   return <span>{data.count} orders</span>;
 }
-function RefreshButton() {
-  const refreshAccount = useRefreshLoaders("account");
-  return <button onClick={() => refreshAccount()}>Refresh</button>;
+function RefreshButtons() {
+  const refresh = useRefreshLoaders();
+  return (
+    <>
+      <button onClick={() => refresh("account")}>Refresh account</button>
+      <button onClick={() => refresh("orders")}>Refresh orders only</button>
+      <button onClick={() => refresh(["account", "orders"])}>
+        Refresh both
+      </button>
+    </>
+  );
 }
 ```
 
-`refreshAccount()` re-runs every currently-mounted member with a **plain GET**
-against the current route URL — no params, no body, no mutation methods, because
-a group spans loaders with different shapes. It returns a promise that resolves
+`refresh(groups)` accepts one name or an array and re-runs every currently-mounted
+member tagged with **any** of them, with a **plain GET** against the current route
+URL — no params, no body, no mutation methods, because a group spans loaders with
+different shapes. A member that sits in two of the requested groups is fetched
+once (members are unioned and deduped by read). It returns a promise that resolves
 when all members settle and **rejects with an `AggregateError`** if any fail;
 group refresh never render-throws, so handle failures at the await site
-(`await refreshAccount().catch(...)`). Each failing member also exposes its error
-via its own read's `error`.
-
-Sharing within a group is opt-in via `key`: members that share a `key` share one
-value (and one fetch); a grouped reader **without** a `key` gets its own private
-bucket, so a group refresh updates only that read and never leaks into unrelated
-unkeyed reads of the same loader. A bucket may belong to several groups at once
-(different reads can tag the same keyed bucket with different group names).
-Keep parameterized loaders on the single-loader `key` — a plain-GET group refresh
-sends no params.
+(`await refresh("account").catch(...)`). Each failing member also exposes its
+error via its own read's `error`.
+
+Multiple tags give you granular vs. whole-set refresh from one place: a coarse
+tag (`"account"`) covers everything, while a finer tag (`"orders"`) targets a
+subset. Sharing within a group is opt-in via `key`: members that share a `key`
+share one value (and one fetch); a grouped reader **without** a `key` gets its own
+private bucket, so a group refresh updates only that read and never leaks into
+unrelated unkeyed reads of the same loader. A bucket may belong to several groups
+at once (one read tagged with multiple names, or different reads tagging the same
+keyed bucket with different names). Keep parameterized loaders on the single-loader
+`key` — a plain-GET group refresh sends no params.
 
 **Load options**:
 
@@ -888,7 +906,7 @@ See `/links` for the full URL generation guide. `ctx.reverse()` is server-only;
 | `useLinkStatus()`     | Link pending state                | { pending }                                                        |
 | `useLoader()`         | Loader data (strict)              | data, isLoading, error                                             |
 | `useFetchLoader()`    | Loader with on-demand fetch       | data, load, isLoading                                              |
-| `useRefreshLoaders()` | Refresh a cross-loader group      | `(group) => () => Promise<void>`                                   |
+| `useRefreshLoaders()` | Refresh cross-loader group(s)     | `() => (groups: string \| string[]) => Promise<void>`              |
 | `useHandle()`         | Accumulated handle data           | T (handle type)                                                    |
 | `useAction()`         | Server action state               | state, error, result                                               |
 | `useLocationState()`  | History state (persists or flash) | T \| undefined                                                     |

package/skills/loader/SKILL.md

@@ -98,9 +98,9 @@ path("/product/:slug", ProductPage, { name: "product" }, () => [
 >   **client** refresh identity. It groups which mounted reads of one loader
 >   refresh together when one calls `load()`. It never touches the server
 >   request. For refreshing **different** loaders together, tag them with
->   `{ refreshGroup }` and call `useRefreshLoaders(name)()` (plain GET only).
->   See the hooks skill ("Scoping refetch with a `key`" and "Refreshing multiple
->   loaders together").
+>   `{ refreshGroup }` (one name or several) and call `useRefreshLoaders()(name)`
+>   (plain GET only). See the hooks skill ("Scoping refetch with a `key`" and
+>   "Refreshing multiple loaders together").
 > - `cache({ key })` — a **server** cache identity (storage hit/miss/ttl/swr).
 > - `revalidate()` — which **server** segments/loaders recompute during
 >   navigation and action refreshes.