@rangojs/router 0.0.0-experimental.8bcfea43 → 0.0.0-experimental.8c0b0f1d

package/skills/i18n/SKILL.md

@@ -0,0 +1,276 @@
+---
+name: i18n
+description: Locale-aware routing with `include("/:locale?", ...)`, locale resolution chains, and react-intl integration
+argument-hint: "[topic]"
+---
+
+# Internationalization (i18n) and Locale Routing
+
+Rango doesn't ship an i18n module. The router gives you the URL primitives
+(optional include prefixes, constraints, typed reverse) and you compose
+them with whatever message library you use — `react-intl`, `lingui`,
+`@formatjs/intl`, or hand-rolled.
+
+This skill covers:
+
+- Mounting routes under an optional locale prefix (`/`, `/en`, `/gb`)
+- Constraining the prefix to a known locale set
+- Resolving the active locale (URL → cookie → `Accept-Language` → default)
+- Generating localized URLs via `reverse()` round-trip
+- Wiring `react-intl` into an RSC route tree
+
+## URL Shape: Optional Locale Prefix
+
+Mount your localized routes under an optional include prefix so the
+default locale lives at the bare URL and other locales get a prefix:
+
+```typescript
+// urls.tsx
+import { urls } from "@rangojs/router";
+import { menuRoutes } from "./menu";
+
+export const urlpatterns = urls(({ include }) => [
+  include("/:locale?", menuRoutes, { name: "menu" }),
+]);
+```
+
+URLs that match:
+
+| URL            | Matched route   | `ctx.params.locale` |
+| -------------- | --------------- | ------------------- |
+| `/`            | `menu.index`    | `undefined`         |
+| `/en`          | `menu.index`    | `"en"`              |
+| `/c/breads`    | `menu.category` | `undefined`         |
+| `/en/c/breads` | `menu.category` | `"en"`              |
+
+> **Constrain to known locales** when you want unknown locales to fall
+> through to other routes (or 404) instead of being treated as a slug:
+>
+> ```typescript
+> include("/:locale(en|gb|fr)?", menuRoutes, { name: "menu" });
+> ```
+>
+> `/de` now 404s (constraint rejects `de`), and `/c/breads` continues to
+> match `menu.category` with `locale: undefined`. Without the constraint,
+> `/de` would match `menu.index` with `locale: "de"`.
+
+## Reading the Locale in Handlers
+
+Absent optionals are `undefined` (not `""`), so `??` coalesces correctly:
+
+```typescript
+import { Handler } from "@rangojs/router";
+
+export const MenuIndex: Handler<"menu.index"> = (ctx) => {
+  // ctx.params.locale is `string | undefined`
+  const locale = resolveLocale(ctx);
+  return <Welcome locale={locale} />;
+};
+```
+
+The `resolveLocale` helper below implements a typical fallback chain.
+
+## Locale Resolution
+
+URL is the strongest signal but you usually want a fallback chain:
+
+1. **URL prefix** — if the user navigates to `/gb/...`, honor it
+2. **Cookie** — sticky preference set by a previous language switcher
+3. **`Accept-Language`** — browser hint
+4. **Default** — your app default
+
+Put it in a small helper that every locale-aware handler calls:
+
+```typescript
+// lib/locale.ts
+import { cookies, headers } from "@rangojs/router";
+
+export const SUPPORTED_LOCALES = ["en", "gb", "fr"] as const;
+export type Locale = (typeof SUPPORTED_LOCALES)[number];
+const DEFAULT_LOCALE: Locale = "en";
+
+const isSupported = (v: string): v is Locale =>
+  (SUPPORTED_LOCALES as readonly string[]).includes(v);
+
+export function resolveLocale(ctx: {
+  params: Record<string, string | undefined>;
+}): Locale {
+  const fromUrl = ctx.params.locale;
+  if (fromUrl && isSupported(fromUrl)) return fromUrl;
+
+  const fromCookie = cookies().get("locale")?.value;
+  if (fromCookie && isSupported(fromCookie)) return fromCookie;
+
+  const accept = headers().get("accept-language") ?? "";
+  for (const tag of accept.split(",")) {
+    const code = tag.split(";")[0].trim().split("-")[0];
+    if (isSupported(code)) return code as Locale;
+  }
+  return DEFAULT_LOCALE;
+}
+```
+
+If you want to redirect to the canonical URL when the resolved locale
+doesn't match the URL (e.g., user has `gb` cookie but visits `/`), do
+that in a global middleware so it covers actions too:
+
+```typescript
+import { redirect } from "@rangojs/router";
+
+router.use("/*", async (ctx, next) => {
+  const fromUrl = ctx.params.locale;
+  const resolved = resolveLocale(ctx);
+  if (resolved !== DEFAULT_LOCALE && !fromUrl) {
+    return redirect(`/${resolved}${ctx.url.pathname}`);
+  }
+  await next();
+});
+```
+
+## Generating Localized URLs
+
+`reverse()` treats `undefined` and `""` for an optional param as "absent"
+and collapses the segment cleanly. The round-trip is symmetric with the
+matcher:
+
+```typescript
+ctx.reverse("menu.index", { locale: "" }); // → "/"
+ctx.reverse("menu.index", { locale: undefined }); // → "/"
+ctx.reverse("menu.index", { locale: "en" }); // → "/en"
+ctx.reverse("menu.category", { locale: "en", slug: "breads" }); // → "/en/c/breads"
+ctx.reverse("menu.category", { slug: "breads" }); // → "/c/breads"
+```
+
+If the active locale is the app default and your URL strategy hides it
+(`"en"` → `/`, others → `/<locale>`), normalize before calling reverse:
+
+```typescript
+const normalized = locale === DEFAULT_LOCALE ? undefined : locale;
+const href = ctx.reverse("menu.category", { locale: normalized, slug });
+```
+
+## react-intl Integration
+
+`react-intl` needs a `<IntlProvider>` wrapping the tree, with `locale`
+and `messages` props. The cleanest split: load messages on the server
+(handler or layout), pass them through to a client provider component.
+
+### Messages loader
+
+Load message bundles per locale. Keep them server-side so they stream
+through the RSC payload and don't bloat the client bundle:
+
+```typescript
+// lib/messages.ts
+import type { Locale } from "./locale";
+
+const loaders: Record<Locale, () => Promise<Record<string, string>>> = {
+  en: () => import("../messages/en.json").then((m) => m.default),
+  gb: () => import("../messages/gb.json").then((m) => m.default),
+  fr: () => import("../messages/fr.json").then((m) => m.default),
+};
+
+export async function loadMessages(locale: Locale) {
+  return loaders[locale]();
+}
+```
+
+### Server layout: hand off to the client provider
+
+```tsx
+// layouts/intl-layout.tsx (server component)
+import type { ReactNode } from "react";
+import { resolveLocale } from "../lib/locale";
+import { loadMessages } from "../lib/messages";
+import { IntlClientProvider } from "../components/intl-client-provider";
+
+export async function IntlLayout({
+  ctx,
+  children,
+}: {
+  ctx: any;
+  children: ReactNode;
+}) {
+  const locale = resolveLocale(ctx);
+  const messages = await loadMessages(locale);
+  return (
+    <IntlClientProvider locale={locale} messages={messages}>
+      {children}
+    </IntlClientProvider>
+  );
+}
+```
+
+### Client provider
+
+```tsx
+// components/intl-client-provider.tsx
+"use client";
+
+import { IntlProvider } from "react-intl";
+import type { ReactNode } from "react";
+
+export function IntlClientProvider({
+  locale,
+  messages,
+  children,
+}: {
+  locale: string;
+  messages: Record<string, string>;
+  children: ReactNode;
+}) {
+  return (
+    <IntlProvider
+      locale={locale}
+      defaultLocale="en"
+      messages={messages}
+      onError={(err) => {
+        if (err.code === "MISSING_TRANSLATION") return; // common, log only
+        console.error(err);
+      }}
+    >
+      {children}
+    </IntlProvider>
+  );
+}
+```
+
+### Mounting
+
+Wrap your localized routes with the layout:
+
+```typescript
+import { urls } from "@rangojs/router";
+import { IntlLayout } from "./layouts/intl-layout";
+import { menuRoutes } from "./menu";
+
+export const urlpatterns = urls(({ layout, include }) => [
+  layout(IntlLayout, () => [
+    include("/:locale?", menuRoutes, { name: "menu" }),
+  ]),
+]);
+```
+
+`<FormattedMessage>`, `useIntl()`, etc. work in any client component
+under the layout. Server components can use `formatjs`'s `createIntl()`
+directly with the same `messages` map for static text.
+
+## Common Pitfalls
+
+| Pitfall                                                       | Fix                                                                                    |
+| ------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
+| `ctx.params.locale === ""` returns `false`                    | Absent optionals are `undefined`, not `""`. Use `=== undefined` or `??`.               |
+| `ctx.params.locale ?? "en"` returns `""`                      | Pre-fix behavior. After the include-prefix fix this works correctly.                   |
+| Bare `/` 404s when mounted via `include("/:locale?", routes)` | Requires the all-optional pattern fix in `compilePattern` (shipped).                   |
+| Unknown locale (e.g. `/de`) matches as `locale: "de"`         | Add a constraint: `:locale(en\|gb\|fr)?`. Unknown values now 404.                      |
+| Reverse produces `//c/breads` for absent locale               | `reverse()` collapses `undefined`/`""` segments — should not happen. File a bug.       |
+| Locale switcher loses search params                           | Read `ctx.url.search` and pass to `reverse(..., undefined, parsedSearch)`.             |
+| Action middleware can't read `ctx.params.locale`              | Route middleware doesn't wrap action execution. Use global `router.use()` for actions. |
+
+## Cross-references
+
+- `/route` — optional URL param syntax and runtime contract
+- `/typesafety` — `RouteParams<"name">` typing for optionals
+- `/middleware` — global vs route middleware scope (matters for actions)
+- `/server-actions` — actions and the global-vs-route middleware boundary
+- `/links` — `ctx.reverse()` and locale-aware URL generation

package/skills/intercept/SKILL.md

@@ -197,6 +197,31 @@ function ModalWrapper({ children }) {
 }
 ```
 
+## Interaction with View Transitions
+
+A layout that owns the `@modal` slot can also configure `transition()` for page
+fades — opening a modal does **not** fire the layout's view transition. Rango
+narrows the layout's `<ViewTransition>` wrap to the layout's default outlet
+content, so `<ParallelOutlet />` (the slot where the modal mounts) is a sibling
+of the wrap, not inside its subtree. Form actions submitted from inside an open
+modal also commit without firing the underlying layout's transition, and the
+modal subtree identity is preserved across revalidation (no remount,
+`useActionState` survives). Closing the modal restores the page without a
+stray transition.
+
+For a modal-only morph (e.g. when intercepted URLs change while the modal
+stays open), use an element-level React `<ViewTransition>` inside the modal
+component — `transition()` accepted on `intercept()` via the DSL is not
+applied to slot rendering today.
+
+Caveat: route-level `transition()` wraps the route component itself, so a
+`<ParallelOutlet />` rendered directly inside that route component would still
+be inside the route's VT subtree. Mount the slot in a layout instead when you
+combine intercept modals with route-level transitions.
+
+See [skills/view-transitions](../view-transitions/SKILL.md) for the full
+contract and direction-aware examples.
+
 ## Interaction with Prerender
 
 When the target route of an intercept uses `Prerender`, the intercept handler is

package/skills/layout/SKILL.md

@@ -118,6 +118,8 @@ function ShopLayout() {
 }
 ```
 
+A layout's `transition()` config wraps the content that flows through `<Outlet />` — not the layout chrome itself, and not sibling `<ParallelOutlet />` slots. Stacking transitions across nested layouts collapses around the deepest default outlet content. See [skills/view-transitions](../view-transitions/SKILL.md) for the full wrap rules and intercept-modal interaction.
+
 ## Named Outlets
 
 For parallel routes, use named outlets:

package/skills/links/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: links
-description: URL generation with ctx.reverse (server default), href (client), useHref (mounted), useMount, and scopedReverse
-argument-hint: [ctx.reverse|href|useHref|useMount|scopedReverse]
+description: URL generation with ctx.reverse (server default), href (client), useHref (mounted), useMount, useReverse, and scopedReverse
+argument-hint: [ctx.reverse|href|useHref|useMount|useReverse|scopedReverse]
 ---
 
 # Links & URL Generation
@@ -10,7 +10,12 @@ argument-hint: [ctx.reverse|href|useHref|useMount|scopedReverse]
 
 **Default server API: `ctx.reverse()`.** Generate URLs from the handler context — it's typed, auto-fills mount params, and resolves local (`.name`) and absolute (`name.sub`) names.
 
-**`reverse()` is server-only.** It depends on the route manifest and handler context, neither of which are available in the browser. Client components receive URLs as props, loader data, or server-action return values — they never call `reverse` directly.
+**On the client, two patterns:**
+
+1. **Receive URLs as props / loader data / action return.** The default. The server has the full route manifest and handler context — generate URLs there and hand strings to client components.
+2. **`useReverse(routes)`.** Import a generated `routes` map from a `urls()` module's `.gen.ts` and call `reverse(".name", params?)`. Mount-aware via `useMount()`, auto-fills params from `useParams()`, fully typed from the imported map. Use this when a client component needs to generate URLs into a known module without round-tripping through the server.
+
+`ctx.reverse()` itself is **server-only** — it depends on the full route manifest and handler context. Client components never import or call it.
 
 ## Server: ctx.reverse()
 
@@ -127,9 +132,7 @@ path("/product/:slug", (ctx) => {
 
 ## Client components: receive URLs as props
 
-`reverse()` is not available inside `"use client"` modules — there is no handler context and no route manifest in the browser bundle. Generate the URL on the server and hand it to the client component.
-
-Three patterns, in order of preference:
+`ctx.reverse()` is not available inside `"use client"` modules — there is no handler context in the browser bundle. For in-module names, prefer `useReverse(routes)` (see below) and import the relevant `urls/*.gen.js`. For cross-module URLs or one-off names, generate the URL on the server and hand it to the client component using one of these three patterns:
 
 1. Pass as a prop from a server component:
 
@@ -187,6 +190,8 @@ export async function getProductUrl(slug: string) {
 }
 ```
 
+See `/server-actions` for the full action surface (`getRequestContext()` is the same context middleware and handlers use).
+
 For static path strings (not named routes), client components can use `href()` — see below.
 
 ## Client: href()
@@ -254,18 +259,159 @@ function MountInfo() {
 
 `useMount()` reads from `MountContext`, which is automatically set by `include()` in the segment tree.
 
-## When to use what
+## Client: useReverse(routes)
+
+Hook that returns a typed local reverse function for a `routes` map imported from a generated `.gen.ts` next to a `urls()` module. The route map is the **exposure boundary** — `useReverse` only knows about names in that map, never the full app manifest.
+
+```tsx
+"use client";
+import { Link, useReverse } from "@rangojs/router/client";
+import { routes as blogRoutes } from "../urls/blog.gen.js";
+
+export function BlogNav() {
+  const reverse = useReverse(blogRoutes);
+
+  return (
+    <nav>
+      <Link to={reverse(".index")}>Blog</Link>
+      <Link to={reverse(".post", { postId: "hello" })}>Post</Link>
+    </nav>
+  );
+}
+```
+
+### How it resolves
 
-| Context          | API                                                | Resolves                        | Use for                                                          |
-| ---------------- | -------------------------------------------------- | ------------------------------- | ---------------------------------------------------------------- |
-| Server handler   | `ctx.reverse("name")`                              | Named routes (local + absolute) | **Default** server-side URL generation                           |
-| Server handler   | `scopedReverse<T>(ctx.reverse)`                    | Same, with type safety          | Type-safe server URLs                                            |
-| Client component | (URL passed as prop / loader data / action return) | Named routes                    | Any URL derived from a named route — generate on server, pass in |
-| Client component | `href("/path")`                                    | Absolute paths (static strings) | Static navigation where no named-route lookup is needed          |
-| Client component | `useHref()`                                        | Mount-prefixed paths            | Local navigation inside `include()`                              |
-| Client component | `useMount()`                                       | Raw mount path                  | Custom mount-aware logic                                         |
+1. Strips the leading `.` and looks up the name in the imported `routes` map.
+2. Joins the local pattern with the surrounding `useMount()` value — the include's URL pattern.
+3. Substitutes params: explicit params from the call, then auto-filled from `useParams()` for anything still unresolved (mount params like `:tenantId` flow in this way).
+4. Appends a query string if a search object is passed and the route has a `search` schema.
+
+### Mount-relativity
+
+Patterns in the generated `routes` map are **mount-relative** — they're the patterns as defined inside the `urls()` module, _not_ the full app paths. Mount-joining happens at runtime via `useMount()`, so the same component works under any include:
+
+```typescript
+// urls/blog.tsx
+export const blogPatterns = urls(({ path }) => [
+  path("/", BlogIndex, { name: "index" }),
+  path("/:postId", BlogPost, { name: "post" }),
+]);
+
+// Generated urls/blog.gen.ts
+// export const routes = { index: "/", post: "/:postId" } as const;
+
+// urls.tsx — same module mounted twice
+include("/news", blogPatterns, { name: "news" }),    // <BlogNav> renders /news, /news/hello
+include("/journal", blogPatterns, { name: "diary" }), // <BlogNav> renders /journal, /journal/hello
+```
+
+The `/` pattern under a non-root mount collapses cleanly: under `/news`, `reverse(".index")` returns `/news` (no trailing slash), matching `ctx.reverse(".index")` on the server.
+
+### Auto-filled params (mount params)
+
+When the include itself carries `:params`, those are auto-filled from `useParams()` so the caller doesn't have to thread them through:
+
+```typescript
+// urls.tsx
+include("/tenant/:tenantId", clientReversePatterns, { name: "tenant" });
+```
+
+```tsx
+// At /tenant/acme/posts/p1, useParams() = { tenantId: "acme", postId: "p1" }
+const reverse = useReverse(clientReverseRoutes);
+
+reverse(".index"); // "/tenant/acme"
+reverse(".post", { postId: "p2" }); // "/tenant/acme/posts/p2"   (tenantId auto-filled)
+reverse(".post", { tenantId: "other", postId: "p2" }); // "/tenant/other/posts/p2" (explicit override)
+```
+
+Auto-fill follows soft navigation — when the matched route changes, `useReverse` re-renders with the new params.
+
+### Search schemas
+
+Routes declared with a `search` schema accept a typed search object as the third argument:
+
+```typescript
+// urls/blog.tsx
+path("/search", SearchPage, {
+  name: "search",
+  search: { q: "string", page: "number?" },
+}),
+
+// Generated as: search: { path: "/search", search: { q: "string", page: "number?" } }
+```
+
+```tsx
+const reverse = useReverse(blogRoutes);
+reverse(".search", {}, { q: "hello world", page: 2 });
+// "/news/search?q=hello%20world&page=2"
+```
+
+### Errors
+
+- Unknown name: throws `Unknown local route: ".not-a-route"`.
+- Missing required param: throws `Missing param "postId" for route ".detail"`.
+
+Both happen synchronously during `reverse()` — wrap calls in try/catch (or an ErrorBoundary if the throw happens during render) when you need to surface them as UI.
+
+### Names are dot-only on the client
+
+`useReverse` accepts only `.name` (and dotted variants like `.nested.index`). There is no global namespace on the client — the import IS the scope. To link into a different module, import that module's `routes`:
+
+```tsx
+import { routes as blogRoutes } from "../urls/blog.gen.js";
+import { routes as shopRoutes } from "../urls/shop.gen.js";
+
+function CrossNav() {
+  const blog = useReverse(blogRoutes);
+  const shop = useReverse(shopRoutes);
+  return (
+    <nav>
+      <Link to={blog(".index")}>Blog</Link>
+      <Link to={shop(".cart")}>Cart</Link>
+    </nav>
+  );
+}
+```
+
+### Codegen
+
+Each `urls()` module gets a sibling `.gen.ts` with the local route names and patterns, produced by `rango generate`:
+
+```bash
+pnpm exec rango generate src/urls/blog.tsx
+# or generate everything under a directory:
+pnpm exec rango generate src/urls --static
+```
+
+Don't edit the file by hand — re-run codegen when patterns change.
+
+**Today the Vite plugin only regenerates the router-level `*.named-routes.gen.ts`.** Per-module `urls/*.gen.ts` files are emitted only by the CLI (or `writePerModuleRouteTypesForFile` programmatically). Commit the generated files and re-run `rango generate` whenever a `urls()` module's `path()`/`include()` shape changes. A common workflow is to wire it into a `predev` script:
+
+```jsonc
+// package.json
+{
+  "scripts": {
+    "predev": "rango generate src",
+    "dev": "vite",
+  },
+}
+```
+
+## When to use what
 
-> `reverse()` is server-only. Client components never import or call it — they receive the already-resolved string.
+| Context          | API                                                | Resolves                                  | Use for                                                          |
+| ---------------- | -------------------------------------------------- | ----------------------------------------- | ---------------------------------------------------------------- |
+| Server handler   | `ctx.reverse("name")`                              | Named routes (local + absolute)           | **Default** server-side URL generation                           |
+| Server handler   | `scopedReverse<T>(ctx.reverse)`                    | Same, with type safety                    | Type-safe server URLs                                            |
+| Client component | `useReverse(routes)`                               | Local names from an imported `routes` map | Typed in-module URL generation without round-tripping the server |
+| Client component | (URL passed as prop / loader data / action return) | Named routes                              | Cross-module URLs or one-off names you don't want to import      |
+| Client component | `href("/path")`                                    | Absolute paths (static strings)           | Static navigation where no named-route lookup is needed          |
+| Client component | `useHref()`                                        | Mount-prefixed paths                      | Local navigation inside `include()`                              |
+| Client component | `useMount()`                                       | Raw mount path                            | Custom mount-aware logic                                         |
+
+> `ctx.reverse()` is server-only. On the client, either generate URLs on the server and pass them in, or import the `routes` map and use `useReverse(routes)` for in-module names.
 
 ## Complete example: mounted module
 

package/skills/loader/SKILL.md

@@ -6,7 +6,10 @@ argument-hint: [loader]
 
 # Data Loaders with loader()
 
-Loaders fetch data on the server and stream it to the client.
+Loaders fetch data on the server and stream it to the client. For mutations
+(writes triggered by forms or buttons), use server actions instead — see
+`/server-actions`. Loaders re-resolve after an action runs, so the typical
+flow is _action mutates → loader re-reads → UI updates_.
 
 ## Creating a Loader
 
@@ -248,6 +251,37 @@ path("/product/:slug", ProductPage, { name: "product" }, () => [
 ]);
 ```
 
+### `revalidate()` return shapes
+
+A `revalidate(fn)` callback can return one of four shapes. The chain
+processes revalidators in order; each call's return controls how the
+chain continues:
+
+```typescript
+// 1) Hard decision — short-circuits the chain, used as the final answer.
+revalidate(() => true);
+revalidate(({ actionId }) => actionId?.includes("Cart") ?? false);
+
+// 2) Soft decision — updates the running suggestion for downstream
+//    revalidators on the same segment, chain continues.
+revalidate(({ defaultShouldRevalidate }) => ({
+  defaultShouldRevalidate: !defaultShouldRevalidate,
+}));
+
+// 3) Defer (no opinion) — leaves the running suggestion unchanged and
+//    continues to the next revalidator. Implicit return / null /
+//    undefined are all equivalent and consumer-friendly.
+revalidate(({ actionId }) => {
+  if (actionId?.includes("Cart")) return true; // hard for this branch only
+  // implicit return — let downstream revalidators or the segment default decide
+});
+revalidate(() => undefined); // explicit defer
+revalidate(() => null); // explicit defer
+```
+
+If every revalidator on a segment defers, the segment-type default
+(e.g. params-changed for routes, `false` for parallels) is used.
+
 ### Revalidation Contracts for Loader Dependencies
 
 If a loader reads `ctx.get()` data produced by an outer handler/layout, share

package/skills/middleware/SKILL.md

@@ -32,6 +32,8 @@ When the router has a `basename`, pattern-scoped `.use()` patterns are automatic
 
 Registered inside `urls()` callback. Wraps **rendering only** -- it does NOT wrap server action execution. Actions run before route middleware, so when route middleware executes during post-action revalidation, it can observe state that the action set (cookies, context variables, headers).
 
+> **Implication for auth:** route middleware cannot guard server actions. Use `router.use("/admin/*", requireAuth)` (global, scoped) for action protection, or check inside the action body. See `/server-actions` for action-side auth patterns.
+
 ```
 Request flow (with action):
   global mw -> action executes -> route mw -> layout -> handler -> loaders

package/skills/migrate-nextjs/SKILL.md

@@ -225,7 +225,7 @@ Loaders are Rango's live data layer. Use them when you need:
 
 - **Client-side data refresh** — `useLoader()` in client components for reactive data
 - **Per-loader caching** — opt in with `loader(MyLoader, () => [cache({ ttl: 60 })])`; loaders stay live by default
-- **Revalidation control** — `revalidate()` targets specific loaders after actions
+- **Revalidation control** — `revalidate()` targets specific segments and loaders after actions
 - **Loading skeletons** — `loading()` shows a Suspense fallback while loaders resolve
 
 ```typescript
@@ -463,6 +463,8 @@ Server actions work the same way — `"use server"` directive, `useActionState`,
 
 Key difference: in Rango, route middleware does NOT wrap action execution. Actions only see global middleware context. Use `getRequestContext()` in actions to access `ctx.set()`/`ctx.get()`.
 
+Next.js's `revalidatePath()` / `revalidateTag()` have no direct equivalent — Rango partially re-renders matched route segments (path/layout/parallel/intercept) and re-resolves their loaders, and you scope re-runs by attaching a `revalidate(({ actionId }) => ...)` rule to any segment or loader registration. See `/server-actions` for the full pattern (validation, error handling, file uploads) and `/loader` for revalidation rule semantics.
+
 ## 8. Metadata / Head
 
 Rango uses the `Meta` handle + `<MetaTags />` client component:

package/skills/migrate-react-router/SKILL.md

@@ -483,6 +483,10 @@ Since Rango uses RSC server actions, all React action patterns work:
 `useActionState`, `useOptimistic`, `useTransition`, `startTransition`,
 and plain `<form action={serverAction}>`. No framework-specific hook needed.
 
+For the full guide — defining actions, validation with Zod, error handling,
+revalidation rules, file uploads, and progressive enhancement — see
+`/server-actions`.
+
 ### clientLoader / clientAction (framework mode)
 
 RR7 framework mode's `clientLoader` and `clientAction` run in the browser.

package/skills/parallel/SKILL.md

@@ -237,6 +237,8 @@ A slot's `loading()` (whether from `handler.use` or explicit) makes that slot an
 
 The `parallel` mount site has the narrowest allow-list for `handler.use` items — slots cannot bring their own middleware or layout, only `revalidate`, `loader`, `loading`, `errorBoundary`, `notFoundBoundary`, and `transition`. See [skills/handler-use](../handler-use/SKILL.md) for the full table and merge rules.
 
+`transition` is allowed in the slot allow-list, but slot-level rendering does **not** currently apply a `<ViewTransition>` wrapper — only the layout/route wraps take effect at render time. For a modal-only morph today, use an element-level React `<ViewTransition>` inside the slot's component. The reverse direction is the useful guarantee: a layout-level `transition()` fires when the layout's default outlet content changes but **not** when a `<ParallelOutlet />` mounts new content (modal opens are not subtree updates of the layout VT). See [skills/view-transitions](../view-transitions/SKILL.md) for the wrap rules and the intercept caveat.
+
 ### Two scopes for explicit `use`: shared (broadcast) and slot-local
 
 `parallel({...slots}, () => [...use])` runs the shared `use()` callback **once per slot** ([dsl-helpers.ts](../../src/route-definition/dsl-helpers.ts)) — items in that callback land on every slot's entry. That's the right behavior for the items the parallel allow-list permits and that accumulate (`loader`, `revalidate`, `errorBoundary`, `notFoundBoundary`, `transition`). (Slots cannot bring `middleware` or `layout` — see the allowed-types note above.)
@@ -347,6 +349,13 @@ Revalidating only the parallel does not re-run outer handlers/layouts.
 If the slot reads `ctx.get()` data established above it, opt the outer
 segment into revalidation as well.
 
+A `revalidate()` callback may return a hard `boolean`, a soft
+`{ defaultShouldRevalidate }` object, or nothing (`void` / `null` /
+`undefined`) to defer to the next revalidator. See
+[loader/SKILL.md#revalidate-return-shapes](../loader/SKILL.md#revalidate-return-shapes)
+for the full contract — it's the same across `loader()`, `path()`,
+`layout()`, `parallel()`, and `intercept()`.
+
 ### Revalidation Contracts for Parallel Dependencies
 
 Prefer named revalidation contracts shared by both the upstream producer and

package/skills/rango/SKILL.md

@@ -16,6 +16,8 @@ Django-inspired RSC router with composable URL patterns, type-safe href, and ser
 | `/route`                | Define routes with `urls()` and `path()`                                   |
 | `/layout`               | Layouts that wrap child routes                                             |
 | `/loader`               | Data loaders with `createLoader()`                                         |
+| `/server-actions`       | Mutations with `"use server"`, useActionState, validation, revalidation    |
+| `/i18n`                 | Locale routing with `:locale?`, resolution chains, react-intl integration  |
 | `/middleware`           | Request processing and authentication                                      |
 | `/intercept`            | Modal/slide-over patterns for soft navigation                              |
 | `/parallel`             | Multi-column layouts and sidebars                                          |