@harness-engineering/cli 1.23.1 → 1.24.0

package/dist/agents/skills/claude-code/nestjs-testing-patterns/SKILL.md

@@ -0,0 +1,130 @@
+# NestJS Testing Patterns
+
+> Test NestJS apps with Test.createTestingModule, jest mocks, supertest e2e, and overrideProvider
+
+## When to Use
+
+- You are writing unit tests for a service and need to mock its dependencies
+- You are writing integration tests for a controller and need to spin up a partial NestJS app
+- You are writing e2e tests that exercise real HTTP requests against the running application
+- You need to verify that guards, interceptors, or pipes behave correctly in context
+
+## Instructions
+
+1. **Unit test a service** — mock all dependencies:
+
+```typescript
+describe('UsersService', () => {
+  let service: UsersService;
+  let prisma: DeepMockProxy<PrismaClient>;
+
+  beforeEach(async () => {
+    const module = await Test.createTestingModule({
+      providers: [UsersService, { provide: PrismaService, useValue: mockDeep<PrismaClient>() }],
+    }).compile();
+
+    service = module.get(UsersService);
+    prisma = module.get(PrismaService);
+  });
+
+  it('throws NotFoundException when user does not exist', async () => {
+    prisma.user.findUnique.mockResolvedValue(null);
+    await expect(service.findOne('missing-id')).rejects.toThrow(NotFoundException);
+  });
+});
+```
+
+2. **Integration test a controller** with overrideProvider:
+
+```typescript
+describe('UsersController (integration)', () => {
+  let app: INestApplication;
+  let usersService: jest.Mocked<UsersService>;
+
+  beforeAll(async () => {
+    const module = await Test.createTestingModule({
+      controllers: [UsersController],
+      providers: [UsersService],
+    })
+      .overrideProvider(UsersService)
+      .useValue({ findOne: jest.fn(), create: jest.fn() })
+      .compile();
+
+    app = module.createNestApplication();
+    app.useGlobalPipes(new ValidationPipe({ whitelist: true, transform: true }));
+    await app.init();
+    usersService = module.get(UsersService);
+  });
+
+  afterAll(() => app.close());
+
+  it('GET /users/:id returns 200', async () => {
+    usersService.findOne.mockResolvedValue({ id: '1', email: 'a@b.com' } as User);
+    return request(app.getHttpServer()).get('/users/1').expect(200);
+  });
+});
+```
+
+3. **E2e test** against the real application:
+
+```typescript
+// test/app.e2e-spec.ts
+describe('AppController (e2e)', () => {
+  let app: INestApplication;
+
+  beforeAll(async () => {
+    const module = await Test.createTestingModule({
+      imports: [AppModule],
+    }).compile();
+    app = module.createNestApplication();
+    await app.init();
+  });
+
+  it('POST /users returns 201', () => {
+    return request(app.getHttpServer())
+      .post('/users')
+      .send({ email: 'test@example.com', password: 'password123' })
+      .expect(201);
+  });
+});
+```
+
+4. **Mock a guard** in tests:
+
+```typescript
+.overrideGuard(JwtAuthGuard).useValue({ canActivate: () => true })
+```
+
+## Details
+
+NestJS testing is built on Jest, with `@nestjs/testing` providing `Test.createTestingModule()` which creates an isolated module context — no HTTP server, no port binding. Providers, guards, pipes, and interceptors can all be selectively replaced.
+
+**`overrideProvider` vs direct mock value:** `overrideProvider(Token).useValue(mock)` replaces the registered provider in the module without changing the module definition. This is cleaner than passing mock values in `providers` because it works even when the token is registered in an imported module.
+
+**`mockDeep` from jest-mock-extended:** Prisma's generated client is deeply nested. `mockDeep<PrismaClient>()` creates a deep mock where every method is a `jest.fn()`. Pair with `{ provide: PrismaService, useValue: mockDeep<PrismaClient>() }`.
+
+**Guard overrides:** `overrideGuard(MyGuard).useValue({ canActivate: () => true })` bypasses the guard entirely. To test the guard itself, instantiate it directly and call `canActivate()` with a mock `ExecutionContext`.
+
+**`app.init()` vs `app.listen()`:** For supertest, call `app.init()` — it sets up the application without starting a TCP server. `supertest(app.getHttpServer())` binds directly to the HTTP handler.
+
+**Test isolation:** Use `beforeEach` to recreate the module for unit tests (avoids state leakage between tests). Use `beforeAll` for e2e tests (app startup is expensive). Always call `app.close()` in `afterAll` to avoid open handle warnings.
+
+## Source
+
+https://docs.nestjs.com/fundamentals/testing
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/nestjs-testing-patterns/skill.yaml

@@ -0,0 +1,42 @@
+name: nestjs-testing-patterns
+version: "1.0.0"
+description: Test NestJS apps with Test.createTestingModule, jest mocks, supertest e2e, and overrideProvider
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "nest-cli.json"
+  - "**/*.spec.ts"
+  - "**/*.e2e-spec.ts"
+  - "test/**"
+related_skills:
+  - nestjs-service-pattern
+  - nestjs-controller-pattern
+  - nestjs-dependency-injection
+stack_signals:
+  - nestjs
+  - typescript
+  - nodejs
+keywords:
+  - testing
+  - jest
+  - supertest
+  - e2e
+  - unit-test
+  - createTestingModule
+  - overrideProvider
+metadata:
+  author: community
+  upstream: "docs.nestjs.com/fundamentals/testing"
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/next-app-router/SKILL.md

@@ -0,0 +1,77 @@
+# Next.js App Router
+
+> Structure Next.js 13+ applications using the App Router's file-system conventions for layouts, nested routes, and route segments
+
+## When to Use
+
+- Starting a new Next.js project with version 13 or later
+- Migrating from the Pages Router to the App Router
+- Adding nested layouts, route groups, or parallel routes
+- Designing URL structures that share UI across multiple routes
+- Working with `app/` directory conventions (`layout.tsx`, `page.tsx`, `loading.tsx`, `error.tsx`)
+
+## Instructions
+
+1. Place all routes under `app/`. Each folder becomes a route segment; `page.tsx` makes it publicly accessible.
+2. Use `layout.tsx` to wrap route segments in shared UI — layouts persist across navigations and do not re-render.
+3. Create route groups with `(groupName)/` to organize routes without affecting the URL path.
+4. Use `[slug]` for dynamic segments and `[...catchAll]` for catch-all segments. Access params via the `params` prop in `page.tsx` and `layout.tsx`.
+5. Co-locate `loading.tsx` alongside `page.tsx` to stream a Suspense fallback during data fetching.
+6. Co-locate `error.tsx` as a Client Component to catch runtime errors within the segment.
+7. Use `not-found.tsx` to render 404 UI and call `notFound()` from `next/navigation` to trigger it.
+8. Use `template.tsx` instead of `layout.tsx` when you need fresh state on every navigation (e.g., page-transition animations).
+9. Prefer route groups to share layouts across unrelated URL paths without creating a shared parent segment.
+10. Keep `layout.tsx` Server Components by default; only add `'use client'` if the layout needs interactivity.
+
+```typescript
+// app/dashboard/layout.tsx — shared layout for all /dashboard/* routes
+export default function DashboardLayout({ children }: { children: React.ReactNode }) {
+  return (
+    <div className="flex">
+      <DashboardNav />
+      <main className="flex-1">{children}</main>
+    </div>
+  );
+}
+
+// app/dashboard/[teamId]/page.tsx — dynamic route segment
+export default function TeamPage({ params }: { params: { teamId: string } }) {
+  return <h1>Team {params.teamId}</h1>;
+}
+```
+
+## Details
+
+The App Router replaces the Pages Router's `getServerSideProps` / `getStaticProps` model with React Server Components and async components. Every file in `app/` is a Server Component by default.
+
+**File conventions:** `page.tsx` (route UI), `layout.tsx` (shared wrapper), `loading.tsx` (Suspense fallback), `error.tsx` (error boundary), `not-found.tsx` (404), `route.ts` (API endpoint), `template.tsx` (per-navigation layout), `default.tsx` (parallel route fallback).
+
+**Route groups** `(groupName)/` exist only in the filesystem — they do not appear in the URL. Use them to co-locate files without coupling the URL structure.
+
+**Trade-offs:**
+
+- Layouts cannot read search params — use `searchParams` prop in `page.tsx` instead
+- `layout.tsx` is not re-mounted on navigation within its segment, so component state persists; use `template.tsx` if fresh state is needed
+- Deeply nested layouts increase the React component tree depth — profile rendering if performance degrades
+
+**Migration from Pages Router:** Pages under `pages/` continue to work alongside `app/` — the two routers coexist during migration. Remove a page from `pages/` only after its `app/` equivalent is tested.
+
+## Source
+
+https://nextjs.org/docs/app/building-your-application/routing
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/next-app-router/skill.yaml

@@ -0,0 +1,44 @@
+name: next-app-router
+version: '1.0.0'
+description: App Router architecture, layouts, nested routes, and route segments in Next.js 13+
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - 'next.config.*'
+  - '**/app/**/*.tsx'
+  - '**/app/**/*.ts'
+  - '**/pages/**/*.tsx'
+related_skills:
+  - next-server-components
+  - next-server-actions
+  - next-data-fetching
+  - react-hooks-pattern
+  - tanstack-prefetching
+  - next-error-boundaries
+stack_signals:
+  - next
+  - nextjs
+  - react
+keywords:
+  - app-router
+  - layouts
+  - nested-routes
+  - route-segments
+  - file-conventions
+  - app-directory
+metadata:
+  author: vercel
+  upstream: 'community/next.js-docs/app-router'
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/next-auth-patterns/SKILL.md

@@ -0,0 +1,94 @@
+# Next.js Authentication Patterns
+
+> Implement authentication with session handling, middleware guards, and Auth.js integration
+
+## When to Use
+
+- Protecting pages and API routes from unauthenticated access
+- Implementing login, logout, and session refresh flows
+- Reading the current user in Server Components and Route Handlers
+- Setting up role-based access control (RBAC) at the middleware level
+- Integrating OAuth providers (Google, GitHub) or credential-based auth
+
+## Instructions
+
+1. Use Auth.js (formerly NextAuth.js) v5 for a batteries-included auth layer — it handles OAuth, JWTs, sessions, and CSRF.
+2. Create `auth.ts` at the project root to configure providers, callbacks, and session strategy.
+3. Protect routes in `middleware.ts` using the Auth.js `auth` export — redirect unauthenticated users before the page renders.
+4. Access the session in Server Components with `auth()` — never trust client-supplied user data.
+5. Access the session in Client Components with `useSession()` from `next-auth/react` — wrap the app in `<SessionProvider>` in a Client Component layout wrapper.
+6. Use `signIn()` and `signOut()` from `next-auth/react` in Client Components, or call them from Server Actions for progressive enhancement.
+7. Validate authorization (role checks) in Route Handlers and Server Actions — middleware only covers page routes by default.
+8. Store sensitive user attributes (roles, permissions) in the JWT callback and expose them through the session callback — never rely solely on client state.
+
+```typescript
+// auth.ts — Auth.js v5 configuration
+import NextAuth from 'next-auth';
+import GitHub from 'next-auth/providers/github';
+
+export const { handlers, auth, signIn, signOut } = NextAuth({
+  providers: [GitHub],
+  callbacks: {
+    async jwt({ token, user }) {
+      if (user) token.role = user.role; // persist role in JWT
+      return token;
+    },
+    async session({ session, token }) {
+      session.user.role = token.role as string; // expose in session
+      return session;
+    },
+  },
+});
+
+// middleware.ts — route protection
+export { auth as middleware } from '@/auth';
+
+export const config = {
+  matcher: ['/dashboard/:path*', '/api/protected/:path*'],
+};
+
+// app/dashboard/page.tsx — server-side session access
+import { auth } from '@/auth';
+import { redirect } from 'next/navigation';
+
+export default async function DashboardPage() {
+  const session = await auth();
+  if (!session) redirect('/login');
+  if (session.user.role !== 'admin') redirect('/unauthorized');
+  return <Dashboard user={session.user} />;
+}
+```
+
+## Details
+
+Auth.js v5 is designed for the App Router and provides `auth()` as both a middleware function and a server-side session accessor. The same function works in middleware, Server Components, Route Handlers, and Server Actions.
+
+**Session strategies:** Auth.js supports JWT sessions (stateless, stored in cookies) and database sessions (stateful, stored in your database). JWT is simpler to deploy; database sessions allow true session revocation. Use database sessions when you need to invalidate sessions on logout or role changes.
+
+**Middleware guard scope:** The Auth.js middleware `auth` export only protects routes matched by `config.matcher`. API Route Handlers and Server Actions are not automatically protected — always call `auth()` and check the session inside them independently.
+
+**Role-based access:** Store roles in the JWT payload via the `jwt` callback. The JWT is signed and cannot be tampered with client-side. Read `session.user.role` in Server Components to make authorization decisions. Never read roles from URL parameters or request bodies for authorization.
+
+**OAuth callback URL:** OAuth providers require registering the callback URL: `https://yourdomain.com/api/auth/callback/github`. In development, use `http://localhost:3000/api/auth/callback/github`. Auth.js handles the callback route via the `handlers` export mounted at `app/api/auth/[...nextauth]/route.ts`.
+
+**PKCE and security:** Auth.js automatically uses PKCE for OAuth flows and includes CSRF protection for credential login. Do not re-implement these manually.
+
+## Source
+
+https://nextjs.org/docs/app/building-your-application/authentication
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/next-auth-patterns/skill.yaml

@@ -0,0 +1,46 @@
+name: next-auth-patterns
+version: "1.0.0"
+description: Authentication patterns, session handling, and middleware auth guards in Next.js
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "next.config.*"
+  - "**/middleware.ts"
+  - "**/app/**/route.ts"
+  - "**/app/**/*.tsx"
+  - "**/auth.*"
+related_skills:
+  - next-middleware-pattern
+  - next-route-handlers
+  - next-server-actions
+  - trpc-middleware-pattern
+  - trpc-context-pattern
+stack_signals:
+  - nextjs
+  - react
+  - typescript
+keywords:
+  - authentication
+  - authorization
+  - session
+  - JWT
+  - NextAuth
+  - Auth.js
+  - middleware-guard
+  - cookies
+metadata:
+  author: community
+  upstream: https://nextjs.org/docs/app/building-your-application/authentication
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/next-caching-strategies/SKILL.md

@@ -0,0 +1,83 @@
+# Next.js Caching Strategies
+
+> Control Next.js's four cache layers to balance freshness, performance, and cost
+
+## When to Use
+
+- Deciding how long fetched data should remain valid before re-fetching
+- Implementing on-demand cache invalidation triggered by CMS or database mutations
+- Debugging stale data that persists despite server restarts or code changes
+- Optimizing expensive API calls with appropriate cache lifetimes
+- Understanding why a page is not updating after deploying new data
+
+## Instructions
+
+1. Use `fetch(url, { next: { revalidate: 60 } })` to cache a fetch result for 60 seconds (ISR-style).
+2. Use `fetch(url, { cache: 'no-store' })` to opt out of caching entirely — equivalent to always fetching fresh data.
+3. Use `fetch(url, { next: { tags: ['posts'] } })` to attach a cache tag — call `revalidateTag('posts')` later to purge it.
+4. Use `unstable_cache(fn, keyParts, { tags, revalidate })` to cache non-fetch data (database queries, third-party SDK calls).
+5. Set `export const revalidate = 60` at the page or layout level as a per-segment default that applies to all fetches in that segment.
+6. Set `export const dynamic = 'force-dynamic'` to opt the entire route out of all caching — equivalent to SSR.
+7. Call `revalidatePath('/posts')` from a Server Action or Route Handler to purge all cache entries for that path.
+8. Use `revalidateTag('tag')` for targeted invalidation without knowing specific paths — one tag can cover many routes.
+
+```typescript
+// lib/posts.ts — cached database query with tags
+import { unstable_cache } from 'next/cache';
+import { db } from '@/lib/db';
+
+export const getPosts = unstable_cache(
+  async () => db.post.findMany({ orderBy: { createdAt: 'desc' } }),
+  ['posts-list'],
+  { tags: ['posts'], revalidate: 3600 }
+);
+
+// app/api/revalidate/route.ts — webhook-triggered on-demand revalidation
+import { revalidateTag } from 'next/cache';
+import { NextRequest, NextResponse } from 'next/server';
+
+export async function POST(request: NextRequest) {
+  const secret = request.headers.get('x-revalidate-secret');
+  if (secret !== process.env.REVALIDATE_SECRET) {
+    return NextResponse.json({ error: 'Unauthorized' }, { status: 401 });
+  }
+  const { tag } = await request.json();
+  revalidateTag(tag);
+  return NextResponse.json({ revalidated: true });
+}
+```
+
+## Details
+
+Next.js App Router has four distinct caches that interact:
+
+1. **Request Memoization** — deduplicates identical `fetch()` calls within a single request lifecycle. Automatic, not configurable. Reset per request.
+2. **Data Cache** — persists `fetch()` results across requests and deployments. Controlled by `revalidate` and `cache` fetch options. The primary cache for server-side data.
+3. **Full Route Cache** — caches the rendered HTML and RSC payload of static routes. Populated at build time and on background revalidation. Invalidated by `revalidatePath()`.
+4. **Router Cache** — client-side cache of RSC payloads for previously visited routes. Reduces server requests during navigation. Automatically expires; call `router.refresh()` to purge.
+
+**`unstable_cache` vs fetch cache:** `fetch()` caching only applies to the native `fetch` function. Use `unstable_cache` to cache ORM queries (Prisma, Drizzle), Redis calls, or any async function. The API is identical in semantics — tags, revalidate, key parts.
+
+**Opt-out cascade:** Using `cookies()`, `headers()`, or `searchParams` in a Server Component automatically opts that route into dynamic rendering, bypassing the Full Route Cache. A single dynamic function in a layout propagates dynamism to all child routes.
+
+**Debugging stale cache:** Run `next build` and inspect the build output — routes marked `○` are static, `λ` are dynamic, `ƒ` are ISR. Use `NEXT_PRIVATE_DEBUG_CACHE=1` environment variable in development to log cache hits and misses.
+
+## Source
+
+https://nextjs.org/docs/app/building-your-application/caching
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.

package/dist/agents/skills/claude-code/next-caching-strategies/skill.yaml

@@ -0,0 +1,43 @@
+name: next-caching-strategies
+version: "1.0.0"
+description: fetch cache options, revalidate, cache tags, and unstable_cache patterns
+cognitive_mode: advisory-guide
+type: knowledge
+tier: 3
+triggers:
+  - manual
+platforms:
+  - claude-code
+  - gemini-cli
+  - cursor
+  - codex
+tools: []
+paths:
+  - "next.config.*"
+  - "**/app/**/*.tsx"
+  - "**/app/**/*.ts"
+related_skills:
+  - next-data-fetching
+  - next-static-generation
+  - next-server-components
+  - tanstack-query-invalidation
+  - tanstack-prefetching
+stack_signals:
+  - nextjs
+  - react
+  - typescript
+keywords:
+  - caching
+  - revalidate
+  - cache-tags
+  - unstable_cache
+  - data-cache
+  - full-route-cache
+  - router-cache
+metadata:
+  author: community
+  upstream: https://nextjs.org/docs/app/building-your-application/caching
+state:
+  persistent: false
+  files: []
+depends_on: []

package/dist/agents/skills/claude-code/next-data-fetching/SKILL.md

@@ -0,0 +1,97 @@
+# Next.js Data Fetching Patterns
+
+> Fetch server-side data efficiently without waterfalls using async Server Components
+
+## When to Use
+
+- Fetching data required to render a page in a Server Component
+- Optimizing multiple data dependencies to run in parallel instead of sequentially
+- Deciding whether to fetch at the layout, page, or component level
+- Passing fetched data to Client Components as props
+- Replacing `getServerSideProps` and `getStaticProps` from the Pages Router
+
+## Instructions
+
+1. Fetch data directly in Server Components using `async/await` — no `useEffect` or API abstraction layer needed.
+2. Initiate all independent data fetches before any `await` to enable parallel execution.
+3. Use `Promise.all()` when all fetches must resolve before rendering — one failure rejects all.
+4. Use individual `await`s with Suspense boundaries to stream each fetch result independently as it resolves.
+5. Fetch at the lowest component level that needs the data — avoid prop-drilling fetched data through multiple layers.
+6. Use `React.cache()` to memoize a fetch function — safe to call in multiple components that need the same data within a request.
+7. Avoid fetching in layouts when the data is only needed by a specific page — layouts block the segment render until resolved.
+8. Use `server-only` import to mark data access functions and prevent accidental client bundle inclusion.
+
+```typescript
+// lib/data.ts — cached data access functions
+import { cache } from 'react';
+import 'server-only';
+
+export const getUser = cache(async (id: string) => {
+  return db.user.findUnique({ where: { id } });
+});
+
+export const getPosts = cache(async (userId: string) => {
+  return db.post.findMany({ where: { authorId: userId } });
+});
+
+// app/users/[id]/page.tsx — parallel fetching
+export default async function UserPage({ params }: { params: { id: string } }) {
+  // Initiate in parallel — do NOT await immediately
+  const userPromise = getUser(params.id);
+  const postsPromise = getPosts(params.id);
+
+  // Await both — total time = max(userTime, postsTime), not sum
+  const [user, posts] = await Promise.all([userPromise, postsPromise]);
+
+  if (!user) notFound();
+  return <UserProfile user={user} posts={posts} />;
+}
+
+// app/users/[id]/page.tsx — streaming with Suspense (alternative)
+export default function UserPage({ params }: { params: { id: string } }) {
+  return (
+    <Suspense fallback={<UserSkeleton />}>
+      <UserContent userId={params.id} />
+    </Suspense>
+  );
+}
+
+async function UserContent({ userId }: { userId: string }) {
+  const user = await getUser(userId); // suspends this boundary only
+  return <UserProfile user={user} />;
+}
+```
+
+## Details
+
+In the App Router, data fetching is co-located with the components that need it — no centralized data loading layer required. Server Components can `await` database queries, fetch calls, and SDK methods directly in the component body.
+
+**Sequential vs parallel:** Two `await` statements in sequence create a waterfall — each waits for the previous. Initiating both promises before awaiting either enables parallelism. With `Promise.all`, both start simultaneously and the total time equals the slowest, not the sum.
+
+**`React.cache()` for deduplication:** Multiple Server Components requesting the same data within one render pass will each trigger a separate fetch unless the fetch function is wrapped with `React.cache()`. This is different from the Next.js Data Cache — `React.cache()` deduplicates within a single request only.
+
+**Fetch vs ORM:** `fetch()` in Server Components integrates with the Next.js Data Cache (caching, revalidation, tags). ORM calls (Prisma, Drizzle) do not — use `unstable_cache` from `next/cache` to cache them.
+
+**Layout vs page fetching:** Fetching in `layout.tsx` blocks the layout render, which blocks all child pages. Only fetch in layouts what every child route genuinely needs (e.g., current user session). Fetch page-specific data in `page.tsx` or in dedicated async components.
+
+**Request deduplication:** Next.js automatically deduplicates identical `fetch()` calls (same URL, same options) within a request lifecycle using Request Memoization. Multiple components fetching the same URL only trigger one network request.
+
+## Source
+
+https://nextjs.org/docs/app/building-your-application/data-fetching/fetching
+
+## Process
+
+1. Read the instructions and examples in this document.
+2. Apply the patterns to your implementation, adapting to your specific context.
+3. Verify your implementation against the details and edge cases listed above.
+
+## Harness Integration
+
+- **Type:** knowledge — this skill is a reference document, not a procedural workflow.
+- **No tools or state** — consumed as context by other skills and agents.
+
+## Success Criteria
+
+- The patterns described in this document are applied correctly in the implementation.
+- Edge cases and anti-patterns listed in this document are avoided.