@rsc-kit/mcp 0.15.0 → 0.16.0

package/guides/coming-from-next.md

@@ -0,0 +1,151 @@
+# Coming from Next.js
+
+> What carries over unchanged, what to rename, and what is different on purpose.
+
+Most of a Next.js app directory moves over as it is. This page is the rest,
+in the order a port meets it.
+
+## What is the same
+
+The `app/` conventions are the same conventions: `layout.tsx`, `page.tsx`,
+`loading.tsx`, `error.tsx`, `not-found.tsx`, `route.ts`, `[slug]`,
+`[...path]`, `(group)`, `@slot` and `(.)intercept`. `"use client"` and
+`"use server"` mean what they mean in React. `cookies()` and `headers()` are
+async and have the same names. `redirect()`, `notFound()`,
+`generateStaticParams()` and `export const metadata` all exist. Streaming
+through `<Suspense>` works the same way, because it is React doing it.
+
+Copy `src/app` across first and fix imports second. Most files need only the
+imports.
+
+## Imports
+
+| Next.js | here |
+| --- | --- |
+| `next/link` | `@rsc-kit/core/Link` — `href` is typed to your routes, and `search` to the page's schema |
+| `useRouter().push(url)` | `visit(url)` from `@rsc-kit/core/router`; `replace: true` for `.replace()` |
+| `useRouter().refresh()` | `refresh()` from `@rsc-kit/core/router` — or better, `revalidate()` from the action |
+| `usePathname()` | `@rsc-kit/core/usePathname` |
+| `useSearchParams()` | `@rsc-kit/core/useSearchParams`, or [nuqs](/guides/routing#search-params-as-state) with our adapter |
+| `useParams()` | the page's `params` prop, passed down |
+| `cookies()`, `headers()` from `next/headers` | the same names from `@rsc-kit/core/request` |
+| `redirect()` from `next/navigation` | `@rsc-kit/core/redirect` |
+| `notFound()` | `@rsc-kit/core/not-found` |
+| `revalidatePath()`, `revalidateTag()` | `revalidate('tag')` from `@rsc-kit/core/revalidate` — see below, it is narrower |
+| `Metadata` from `next` | `@rsc-kit/core/metadata` — `metadataBase`, `openGraph`, `twitter`, `icons` as you had them |
+| `next/font` | [Fontsource](/guides/fonts): install the font, import its CSS |
+| `next/image` | [unpic](/guides/images) for a CDN, `vite-imagetools` for files in the repo |
+| `next/script` | [a `<script>` tag](/guides/third-party-scripts): React 19 hoists and dedupes `async` scripts itself |
+| `NEXT_PUBLIC_*` | `VITE_*`, read through `import.meta.env`; everything else stays `process.env` on the server |
+| `next.config.js` | `vite.config.ts` — Tailwind, aliases and plugins are Vite's |
+| `next-safe-action` | `createActionClient()` — same shape, [below](#actions) |
+
+## Different on purpose
+
+### Nothing is dynamic by declaration
+
+There is no `export const dynamic = 'force-dynamic'` and no `revalidate = 60`.
+A page is frozen at build time unless it **reads the request** — `cookies()`,
+`headers()`, `searchParams`, `await connection()` — and then it renders per
+request, or as a shell with the reading part streamed in. The build prints
+which, and why:
+
+```
+  ○  /about               no js
+  ◐  /orders              85 kB
+     dynamic — called cookies()
+```
+
+`await connection()` is the one explicit mark, for a page that must render per
+visitor and does not happen to read anything. Time-based ISR does not exist:
+a frozen page changes when you build, a dynamic one on every request, and
+[edge caching](/guides/edge-caching) covers the middle.
+
+### Middleware is per directory, not one file at the edge
+
+Next has one `middleware.ts` that runs on a matcher, on the edge runtime, with
+a restricted API. Here a `middleware.ts` sits in the directory it protects,
+runs on the server with the full API, and covers everything below it:
+
+```ts title="src/app/admin/middleware.ts"
+export default async function middleware() {
+  if (!(await currentUser())?.isAdmin) redirect('/login');
+}
+```
+
+It does not run for actions — an action renders no route — which is why the
+check for an action belongs in the action. See [Authorization](/guides/authorization).
+
+### Actions
+
+`next-safe-action` users will find the same shape under a different name.
+`createActionClient()` chains middleware, validates with any Standard Schema,
+and **returns** failures as `{ validationErrors }` or `{ serverError }` rather
+than throwing them across the wire:
+
+```ts
+export const client = createActionClient().use(async ({ next }) => {
+  const user = await currentUser();
+  if (!user) throw new ServerAuthenticationError();
+  return next({ ctx: { user } });
+});
+
+export const createPost = client.input(schema).handler(async ({ input, ctx, fieldErrors }) => {
+  if (await slugTaken(input.slug)) return fieldErrors({ slug: 'Already taken' });
+  return save(input, ctx.user);
+});
+```
+
+`returnValidationErrors(schema, { email: { _errors: [...] } })` becomes
+`return fieldErrors({ email: 'Account not found' })`. `useAction` from
+next-safe-action is `useActionState`, or a `<Form action={createPost}>` that
+reads the returned errors on its own. The build lists any action not built
+from a client, because nothing checks who calls those.
+
+### Revalidation is targeted
+
+`revalidatePath('/orders')` re-renders the page. `revalidate('orders')`
+re-renders the [section](/guides/sections) registered under that name and
+sends it back **with the action's own response** — one request, the rest of
+the page untouched, a half-typed input elsewhere on it still typed. Wrap the
+region in `section('orders', Orders)` and name it from the action.
+
+### Forms
+
+`<Form>` from `@rsc-kit/core/form` submits to an action, shows pending state,
+places field errors, and works before hydration. It is uncontrolled by
+default like React Hook Form's `register`, with `field()` for a controlled
+binding and `useField()` for a value read anywhere. shadcn's `Field`
+components fit as they are. See [Forms](/guides/forms).
+
+### Query strings are typed
+
+Export a schema beside the page and the values arrive parsed; the same schema
+types every `<Link search={…}>` to it. `Number(searchParams.get('page'))` is
+not a thing you write here. See [URL validation](/guides/url-validation).
+
+### There is no image optimizer, and no `opengraph-image.tsx`
+
+Both are processes Next runs for you at request time. Put `opengraph-image.png`
+in `src/app` and it is picked up; generate one at build time if it has to be
+generated. Images: [unpic or imagetools](/guides/images).
+
+### Testing does not need a browser
+
+`createTestApp()` hands back the deployed `Request → Response` handler.
+Actions, queries and api routes are plain functions. There is no equivalent
+in Next; see [Testing](/guides/testing).
+
+## The porting order that worked
+
+1. `bun create rsc-kit@latest` and copy `src/app` over the scaffold's.
+2. Fix imports from the table. `bun run typecheck` finds the rest.
+3. `bun run build` and **read the output**: every route that is not `○` says
+   why. Most surprises are a `cookies()` in a layout making everything
+   dynamic — the build says so under the summary.
+4. Actions not built from a client are listed. Decide for each.
+5. `bun run check`. Then a browser, for the parts that are a browser's.
+
+An agent doing the port has all of this: the `.mcp.json` in the scaffold
+answers `how_to({ topic })` and `read_guide({ slug })` from the installed
+version, and the build report is what it reads instead of guessing.

package/guides/getting-started.md

@@ -0,0 +1,132 @@
+# Getting started
+
+> Serve React Server Components from any JavaScript backend.
+
+A host is a `Request` in and a `Response` out. You do not normally write the
+server that calls it: [Nitro](https://nitro.build) builds one around your route
+tree, and where it runs is a preset in `vite.config.ts`.
+
+## Building
+
+Three steps, and only the first is required:
+
+```bash
+npm run dev         # vite — serves from source, no build step
+npm run build       # bundles, renders every route once, then Nitro assembles .output/
+npm run start       # runs .output/server/index.mjs
+```
+
+`dev` is Vite's own dev server, and edits reach the browser without a reload:
+
+| you edit | what happens |
+| --- | --- |
+| a client component | Fast Refresh — the code updates and its state survives |
+| a page or layout | the payload is re-fetched and the tree re-rendered |
+| adding or deleting a page | the server restarts to pick up the new route table |
+
+The browser never holds a server component, so Vite cannot hot-swap it. Instead
+the client re-fetches the page — which remounts any client component below, so
+their state resets.
+
+Edit a client component directly and its state does survive; that is Fast
+Refresh.
+
+The restart on a new page is because the route tree is read when the server
+starts: a page that appears later would otherwise 404 while sitting right there
+on disk.
+
+`build` ends by rendering every route once and storing what it can, which is
+what turns a route into a file on disk instead of a render per request.
+
+It is part of `build` rather than a separate command because forgetting it costs
+you everything and looks like nothing — every page still works, each one just
+renders again for every visitor.
+
+Turn it off with `rscKit({ prerender: false })` when the build machine
+cannot do what the pages need. See [Static
+generation](/guides/static-generation).
+
+<Aside type="note" title="There is no NODE_ENV to set">
+  React picks its build from it, and getting it wrong gives you a page that
+  renders perfectly and never hydrates. The build stamps the mode it ran in
+  into the server bundles, so a server is production because it was built that
+  way — `npm run start` needs no environment at all.
+</Aside>
+
+## Compiling to a single binary
+
+With the Bun preset the whole application ends up in one file:
+
+```bash
+npm run compile   # builds, then bun build --compile
+./dist/app
+```
+
+That works because the generated config sets `serveStatic: 'inline'`. Without
+it the binary compiles, starts, serves pages, and 404s every asset — the static
+path resolves into Bun's virtual filesystem, where the files on disk are not.
+
+### What it costs
+
+Measured on the example — eleven routes, 240 KB of assets, 164 KB of stored
+pages:
+
+| | compiled | run from `.output/` |
+| --- | --- | --- |
+| Cold start | 45 ms | 56–65 ms |
+| Resident, idle | 18 MB | 19 MB |
+| Resident, after 300 requests | 27 MB | 32 MB |
+| On disk | 62 MB | 240 KB + a runtime |
+
+Memory is flat between the two: the binary holds its assets as `Response`
+objects built at boot, which for 240 KB is nothing, and both settle in the high
+twenties once React has warmed up. A live render is what moves it — 40 MB after
+200 of them — and that is the renderer, not the packaging.
+
+<Aside type="note" title="What compiling is actually for">
+  Deployment shape, not speed. One file, no `node_modules`, no runtime to
+  install. Throughput between the two is inside the noise of any benchmark I
+  could run on one machine — the only differences I can defend are the ~15 ms
+  of cold start and the shape of what you ship.
+</Aside>
+
+<Aside type="caution" title="What embedding costs">
+  Every asset goes in whole. Three files is nothing; a media-heavy app is
+  hundreds of megabytes of executable, with no CDN in front and no streaming
+  from disk. Keep large or rarely-read files outside the binary and serve them
+  from wherever they already live.
+
+  Frozen pages are not embedded either. The build writes them to
+  `.output/server/rsc-static` and the server reads them from beside itself; a
+  binary has no filesystem to read, so it renders those pages live. Everything
+  still answers — what you lose is the stored render, not the page.
+</Aside>
+
+## If you work with an AI agent
+
+The scaffold writes an `AGENTS.md` beside your `README.md`. Claude Code, Cursor
+and the rest read it, and it covers the things an agent otherwise gets wrong
+from React or Next habits — `"use client"` versus `"use server"`, where an
+authorisation check belongs, which props are async, and that the build output is
+worth reading rather than ignoring.
+
+Beside it is `.mcp.json`, which connects the [MCP server](/guides/mcp): Claude
+Code asks you to approve it on first use, and from then on an agent can read
+what your last build actually did instead of guessing.
+
+And there is a test to extend, `tests/app.test.ts`, which goes through the
+real build: `bun run check` runs typecheck, lint and tests together, and is
+the one command an agent — or you — runs before calling something done.
+
+Edit it as your project grows. It is yours; nothing regenerates it.
+
+There is also an MCP server, which answers from your actual build rather than
+from memory:
+
+```sh
+claude mcp add rsc-kit -- npx -y @rsc-kit/mcp
+```
+
+It can say why a particular page is not static, what each route ships to the
+browser, and how to build a form or an api route the way this framework
+expects. See [Working with an AI agent](/guides/mcp/).

package/guides/index.json

@@ -14,6 +14,11 @@
     "title": "Asking once per request",
     "description": "cache() — one lookup, however many places need it."
   },
+  {
+    "slug": "coming-from-next",
+    "title": "Coming from Next.js",
+    "description": "What carries over unchanged, what to rename, and what is different on purpose."
+  },
   {
     "slug": "connection",
     "title": "Rendering per request",
@@ -44,11 +49,26 @@
     "title": "Forms",
     "description": "Progressive forms, pending state and validation errors."
   },
+  {
+    "slug": "getting-started",
+    "title": "Getting started",
+    "description": "Serve React Server Components from any JavaScript backend."
+  },
   {
     "slug": "images",
     "title": "Images",
     "description": "Responsive images with no optimizer to run — unpic for a CDN, imagetools for files in the repo."
   },
+  {
+    "slug": "installation",
+    "title": "Installation",
+    "description": "From an empty directory to a streaming RSC app."
+  },
+  {
+    "slug": "introduction",
+    "title": "Introduction",
+    "description": "React Server Components as a Vite plugin, deployed wherever you like."
+  },
   {
     "slug": "mcp",
     "title": "Working with an AI agent",
@@ -89,6 +109,11 @@
     "title": "Queries",
     "description": "Reading from the server over GET, and letting TanStack Query or SWR own everything above it."
   },
+  {
+    "slug": "quick-start",
+    "title": "Quick start",
+    "description": "A running app in one command, or added to a project you already have."
+  },
   {
     "slug": "react-compiler",
     "title": "React Compiler",

package/guides/installation.md

@@ -0,0 +1,338 @@
+# Installation
+
+> From an empty directory to a streaming RSC app.
+
+There is no scaffolding command. An app is a Vite project with one plugin and
+one request handler, so this is the whole of it.
+
+## Create an app
+
+One command, and it asks the rest:
+
+```sh
+bun create rsc-kit@latest my-app
+```
+
+It asks where it will run (Bun, Node or Cloudflare Workers), whether you want the
+React Compiler and which implementation, and whether to include Tailwind. Every
+answer has a flag, so it also runs unattended:
+
+```sh
+bun create rsc-kit@latest my-app --host=bun --compiler=oxc --tailwind
+```
+
+What comes out builds, prerenders, typechecks and serves before you edit it.
+
+The rest of this page is for adding rsc-kit to an app you already have.
+
+## Install
+
+<PackageManagers pkg="@rsc-kit/core react react-dom" />
+
+<PackageManagers pkg="vite @vitejs/plugin-rsc @vitejs/plugin-react @types/react @types/react-dom" dev />
+
+`@rsc-kit/core` brings the Vite plugin, the render engine and the client
+runtime. React 19 and Vite 8 are peer dependencies — the versions the RSC build
+needs, not ones this package pins for you.
+
+<Aside type="note" title="What @vitejs/plugin-react is for">
+  Fast Refresh: edit a client component and React keeps its state, instead of
+  the page reloading and losing it. Put it *after* `rscKit()`.
+</Aside>
+
+## Configure Vite
+
+```ts title="vite.config.ts"
+import { defineConfig } from 'vite'
+import react from '@vitejs/plugin-react'
+import { nitro } from 'nitro/vite'
+import { rscKit } from '@rsc-kit/core/vite'
+
+/**
+ * The full route tree, built the way every scaffolded app is built.
+ *
+ * Nitro owns the server and the entry is generated — there is no server file
+ * in this directory, which is the point.
+ */
+export default defineConfig({
+  plugins: [
+    nitro({ preset: 'bun', serveStatic: 'inline' }),
+    rscKit({
+      sourceDir: 'src',
+      outDir: 'build',
+      viewTransitions: true,
+      offline: true,
+    }),
+    react(),
+  ],
+})
+```
+
+`sourceDir` is where your route tree lives. The defaults are plain Vite ones —
+`src/app` in, `dist/client` and `.rsc` out — so a project that adopts them can
+call `rscKit()` with nothing at all.
+
+<Aside type="note" title="Add your own plugins after it">
+  `rscKit()` includes `@vitejs/plugin-rsc`, which has to see modules before
+  any React layer transforms them. Tailwind, the React Compiler and anything
+  else go after it in the array.
+</Aside>
+
+## Write a root layout
+
+The root layout renders the **whole document** — there is no separate HTML
+template, and the build injects the bootstrap script and stylesheet links into
+what you return here.
+
+```tsx title="src/app/layout.tsx"
+import './styles.css'
+// Preloaded so the browser finds it before the stylesheet does. ?url is Vite's
+// and hands back the hashed path the build serves.
+import frauncesLatin from '@fontsource-variable/fraunces/files/fraunces-latin-full-normal.woff2?url'
+import type { ReactNode } from 'react'
+import { Nav } from '../components/Nav'
+import type { Metadata } from '@rsc-kit/core/metadata'
+
+export const metadata: Metadata = {
+  title: { template: '%s · rsc-kit', default: 'rsc-kit' },
+  description: 'React Server Components as a Vite plugin',
+  // Once, here. A share-card scraper needs an absolute image url, and this is
+  // what turns the opengraph-image.png in app/ into one.
+  metadataBase: new URL('https://example.rsc-kit.dev'),
+  openGraph: {
+    siteName: 'rsc-kit example',
+    type: 'website',
+  },
+  twitter: {
+    card: 'summary_large_image',
+    site: '@rsckit',
+  },
+}
+
+// `modal` is a parallel slot: the @modal directory beside this file fills it.
+// It renders alongside children, not instead of them.
+export default function RootLayout({ children, modal }: { children: ReactNode; modal?: ReactNode }) {
+  return (
+    <html lang="en">
+      <head>
+        <meta charSet="utf-8" />
+        <meta name="viewport" content="width=device-width, initial-scale=1" />
+        <link rel="preload" href={frauncesLatin} as="font" type="font/woff2" crossOrigin="anonymous" />
+      </head>
+      <body>
+        <Nav />
+        <main>{children}</main>
+        {modal}
+      </body>
+    </html>
+  )
+}
+```
+
+## Write a page
+
+```tsx title="src/app/page.tsx"
+export default function HomePage() {
+  return <h1>Hello</h1>;
+}
+```
+
+`app/page.tsx` serves `GET /`, wrapped in `app/layout.tsx`. Nothing registers
+it — the plugin reads the directory at build time. See
+[Routing](/guides/routing) for the rest of the conventions.
+
+## Serve it
+
+There is no server file to write. Nitro builds one around the route tree, and
+`npm run build` leaves it in `.output/`:
+
+```sh
+npm run build
+npm run start
+```
+
+Where it runs is the preset in `vite.config.ts` — see [Where it
+runs](/hosts/where-it-runs).
+
+## Scripts
+
+```json title="package.json"
+{
+  "type": "module",
+  "scripts": {
+    "dev": "vite",
+    "build": "vite build",
+    "start": "bun .output/server/index.mjs",
+    "compile": "bun build --compile .output/server/index.mjs --outfile my-app"
+  }
+}
+```
+
+`build` freezes every page it can, so there is no separate prerender step and
+no command for one — freezing runs the app, which needs the bundle the build
+just wrote, and only the build knows where that is. Turn it off with
+`rscKit({ prerender: false })`.
+
+`start` runs what the build wrote. There is no server file in a scaffolded app —
+Nitro builds the server around the route tree, and where it runs is a preset in
+`vite.config.ts`. See [Where it runs](/hosts/where-it-runs).
+
+`compile` produces a standalone binary containing the engine, the route tree,
+the frozen pages **and** the assets. That last part is `serveStatic: 'inline'`
+in the vite config; without it the binary serves pages and 404s every asset.
+
+<Aside type="note" title="Do not set NODE_ENV">
+  The build stamps its mode into the bundle, so `npm run start` is
+  production because it was *built* that way. Setting `NODE_ENV` yourself adds a
+  second source of truth that can disagree — and when it disagrees, every page
+  renders and none of them become interactive.
+
+  For a development build with React's real error messages, use
+  `vite build --mode development`.
+</Aside>
+
+Then:
+
+```bash
+npm run build   # bundles, and freezes every page it can
+npm run start
+```
+
+Worth adding a `typecheck` script beside them (`tsc --noEmit`) and running it
+in CI. Server components are ordinary functions and pages are ordinary
+modules, so the typechecker sees the whole route tree — a page whose props do
+not match its `[param]` segment is a compile error rather than a blank page.
+
+## TypeScript
+
+```json title="tsconfig.json"
+{
+  "compilerOptions": {
+    "target": "ESNext",
+    "module": "ESNext",
+    "moduleResolution": "bundler",
+    "jsx": "react-jsx",
+    "strict": true,
+    "noEmit": true,
+    "skipLibCheck": true,
+    "resolveJsonModule": true,
+    "types": [
+      "@types/bun",
+      "vite/client"
+    ]
+  },
+  "include": ["src/**/*", "server/**/*", ".rsc-kit/**/*", "vite.config.ts"]
+}
+```
+
+`vite/client` is doing real work in that list: without it a side-effect import
+of a stylesheet (`import './styles.css'` in the root layout) is an error, and
+`import.meta.env` is untyped.
+
+### Environment variables
+
+There is nothing to install and nothing this package adds — Vite already owns
+this. Two rules and one declaration.
+
+Anything named `VITE_*` is **inlined into the client bundle** and ships to the
+browser, whether or not a browser file reads it. Everything else stays on the
+server, read through `process.env`.
+
+The prefix is the whole boundary, so never put a secret behind it.
+`VITE_STRIPE_KEY` is a published key.
+
+Declare the ones you use, and Vite types them:
+
+```ts title="src/env.d.ts"
+interface ViteTypeOptions {
+  // Turns an unknown import.meta.env key into an error instead of `any`.
+  strictImportMetaEnv: unknown;
+}
+
+interface ImportMetaEnv {
+  readonly VITE_API_URL: string;
+}
+```
+
+<Aside type="caution" title="On Bun, a misspelled variable still compiles">
+  `@types/bun` declares its own `ImportMetaEnv`, which cancels out the strictness
+  Vite's option adds. You still get autocomplete and `string` instead of
+  `string | undefined` — but a typo is `any`, not an error.
+</Aside>
+
+#### When they are read
+
+`import.meta.env.VITE_*` is a literal in the bundle: changing one means a
+rebuild. `process.env.*` is a live read, so the deploy's environment wins —
+with one exception the build makes for you. A route that reads an environment
+variable and nothing request-bound is frozen at build time, value included,
+because nothing marked it as needing a request. That is the right answer for
+`PUBLIC_SITE_NAME` and the wrong one for a feature flag flipped per deploy. For
+the second kind, read it after `await connection()`, which keeps the route on
+the server. See [Static generation](/guides/static-generation).
+
+#### Validating them
+
+Vite checks the prefix and nothing else: a missing `DATABASE_URL` is
+`undefined` until the first query fails. There is nothing native for this
+because nothing native is needed — [t3-env](https://env.t3.gg/docs/core) works
+unchanged, with any Standard Schema validator:
+
+```ts title="src/env.ts"
+import { createEnv } from '@t3-oss/env-core';
+import { z } from 'zod';
+
+export const env = createEnv({
+  server: { DATABASE_URL: z.string().url() },
+  clientPrefix: 'VITE_',
+  client: { VITE_API_URL: z.string().url() },
+  runtimeEnv: typeof process === 'undefined' ? import.meta.env : { ...import.meta.env, ...process.env },
+  emptyStringAsUndefined: true,
+});
+```
+
+Read `env.DATABASE_URL` instead of `process.env.DATABASE_URL` and three things
+follow. It is a `string`, not `string | undefined`. A server variable touched
+from a client component throws by name rather than being silently `undefined`.
+And because the module validates when it is first imported, a missing variable
+fails the **build** — the prerender imports it — instead of the first request
+in production.
+
+The build writes its declaration files into `.rsc-kit/` at the project root,
+not among your own source. Three of them:
+
+- `rsc-routes.d.ts` — the routes it found, which is what makes `Link` and
+  `redirect()` [typed](/guides/routing#typed-links)
+- `rsc-env.d.ts` — the host global
+- `rsc-engine.d.ts` — the generated bundle
+
+Only what has to be generated is. Anything you can import, you import —
+[`Metadata`](/guides/metadata/) comes from the package and works before you have
+built anything.
+
+These are ambient, which needs only that they are inside the project and that
+the typechecker is told the directory exists:
+
+```json title="tsconfig.json"
+{ "include": ["src/**/*", ".rsc-kit/**/*"] }
+```
+
+A scaffolded app has that line, and `rsc-kit init` adds it. Leave it out and
+the build says so — otherwise typed routes fall back to plain `string` and
+nothing else would tell you.
+
+Add `.rsc-kit/` to `.gitignore`.
+
+## Where next
+
+<CardGrid>
+  <Card title="Routing" icon="ph:tree-structure">
+    [Pages, layouts, slots and navigation →](/guides/routing)
+  </Card>
+  <Card title="Server actions" icon="ph:lightning">
+    [Calling the server from a client component →](/guides/server-actions)
+  </Card>
+  <Card title="Static generation" icon="ph:snowflake">
+    [Rendering ahead of time, and exporting →](/guides/static-generation)
+  </Card>
+</CardGrid>