# Pathrule Pattern: Next.js App Router (1.0.0)
# ::pathrule:package:nextjs-app-router

### [RULE] Server Components by default  (path: /app)
<!-- scope: folder | priority: high | advisory -->

Components under the `app` directory are Server Components by default.

- Add `'use client'` only for components that use state, effects, refs, or browser APIs.
- Fetch data in Server Components and pass plain, serializable props down.
- Push the client boundary as far down the tree as possible so most of the page stays server-rendered.

---

### [RULE] Never leak server secrets to the client  (path: /app)
<!-- scope: folder | priority: high | strict -->

Only `NEXT_PUBLIC_` variables may reach the client bundle.

- Never import a server-only module, database client, or secret-bearing config from a `'use client'` file.
- Use the `server-only` package so the build fails if a server module is imported client-side.
- Keep API keys and tokens in Server Components, Route Handlers, or Server Actions.

---

### [MEMORY] Route segment config conventions  (path: /app)

Caching is set at the segment level, not scattered per fetch.

- Use `export const revalidate` when the whole segment shares a freshness need.
- Default runtime is `nodejs`.
- Any `export const dynamic = 'force-dynamic'` carries a one-line comment explaining why the segment cannot be cached.
- Prefer fetch-level cache options for mixed-freshness pages.

---

### [MEMORY] Data fetching and caching policy  (path: /app)

Fetch on the server, cache deliberately, revalidate by tag.

- Fetch in Server Components or Route Handlers, never in client effects.
- Set explicit `cache` and `next.revalidate` options on `fetch`.
- Use `revalidateTag` for targeted invalidation after mutations.
- Start independent requests in parallel to avoid waterfalls.

---

### [SKILL] nextjs-route-review  (path: /)

---
name: nextjs-route-review
description: Review a new Next.js App Router route for correctness, caching, and safety.
---

# Next.js route review

Run this before merging a new route or layout.

- [ ] Server vs client boundary is minimal and correct ('use client' only where needed)
- [ ] No server-only module or secret is reachable from a client component
- [ ] Caching and revalidate are intentional and documented
- [ ] loading.tsx and error.tsx exist where the route fetches data
- [ ] generateMetadata or static metadata is exported for SEO
- [ ] Dynamic params are validated and not trusted blindly
- [ ] Mutations use Server Actions or Route Handlers, and revalidate the right tags