opencastle 0.32.5 → 0.32.6

package/src/orchestrator/plugins/nextjs/SKILL.md

@@ -16,149 +16,93 @@ description: "Next.js framework best practices covering App Router, server/clien
 │   ├── loading.tsx          # Loading UI (Suspense boundary)
 │   ├── error.tsx            # Error boundary (Client Component)
 │   ├── not-found.tsx        # 404 page
-│   ├── global-error.tsx     # Root error boundary
 │   ├── (marketing)/         # Route group (no URL segment)
-│   │   ├── about/page.tsx   # → /about
-│   │   └── blog/page.tsx    # → /blog
+│   │   └── about/page.tsx   # → /about
 │   ├── dashboard/
 │   │   ├── layout.tsx       # Nested layout
-│   │   ├── page.tsx         # → /dashboard
 │   │   └── [id]/page.tsx    # → /dashboard/:id
 │   └── api/
 │       └── users/route.ts   # API route handler
 ├── components/              # Shared React components
 ├── lib/                     # Utilities, helpers, server logic
-├── public/                  # Static assets (served as-is)
+├── public/                  # Static assets
 ├── next.config.ts           # Next.js configuration
 ├── middleware.ts            # Edge middleware
 └── .env.local               # Environment variables (not committed)
 ```
 
-- **Route Groups** `(name)` — organize routes without affecting the URL.
-- **Private Folders** `_internal` — opt out of routing entirely.
-- **Parallel Routes** `@modal` — render multiple pages in the same layout.
-- **Intercepting Routes** `(.)photo` — intercept navigation to show modals.
+Route Groups `(name)` organize routes without affecting the URL. Private Folders `_internal` opt out of routing. Parallel Routes `@modal` render multiple pages in the same layout.
 
 ## Rendering Strategies
 
-Next.js supports multiple rendering strategies per route:
-
 | Strategy | When | How |
 |----------|------|-----|
 | **Static (SSG)** | Build time | Default for pages with no dynamic data |
-| **Incremental Static Regeneration (ISR)** | Build + revalidation | `fetch` with `next: { revalidate: N }` or route segment config |
-| **Server-Side Rendering (SSR)** | Every request | `export const dynamic = 'force-dynamic'` or dynamic functions (`cookies()`, `headers()`) |
-| **Client-Side Rendering (CSR)** | Browser | `'use client'` components with `useEffect`/SWR |
+| **ISR** | Build + revalidation | `fetch` with `next: { revalidate: N }` or route segment config |
+| **SSR** | Every request | `export const dynamic = 'force-dynamic'` or dynamic functions |
+| **CSR** | Browser | `'use client'` components with `useEffect`/SWR |
 | **Streaming** | Progressive | `<Suspense>` boundaries + `loading.tsx` |
-| **Partial Prerendering (PPR)** | Build + streaming | Static shell with dynamic holes via `<Suspense>` |
-
-### Route Segment Config
-
-Control per-route rendering behavior:
+| **PPR** | Build + streaming | Static shell with dynamic holes via `<Suspense>` |
 
-```tsx
-// app/dashboard/page.tsx
-export const dynamic = 'force-dynamic';        // SSR every request
-export const revalidate = 60;                   // ISR: revalidate every 60s
-export const fetchCache = 'default-cache';      // Cache fetch requests
-export const runtime = 'nodejs';                // 'nodejs' | 'edge'
-```
+Route segment config: `export const dynamic = 'force-dynamic'`, `export const revalidate = 60`, `export const runtime = 'edge'`.
 
 ## Server and Client Components
 
-**Default: Server Components** — data fetching, heavy logic, non-interactive UI.
-
+**Default: Server Components** — data fetching, heavy logic, non-interactive UI.  
 **Client Components** — add `'use client'` at top. Use for interactivity, state, browser APIs.
 
-### Decision Table
-
-| Need | Component Type | Why |
-|------|---------------|-----|
-| Fetch data at request time | Server | Direct DB/API access, no client waterfall |
-| Read cookies/headers | Server | Available only on the server |
-| Interactive UI (clicks, inputs) | Client | Requires event handlers |
-| Use `useState` / `useEffect` | Client | React hooks need client runtime |
-| Access browser APIs (localStorage, geolocation) | Client | Not available on server |
-| Render static/non-interactive content | Server | Smaller bundle, faster paint |
-| Show loading spinners for async children | Server (with `<Suspense>`) | Streams HTML progressively |
+| Need | Component Type |
+|------|---------------|
+| Fetch data / read cookies/headers | Server |
+| Interactive UI (clicks, inputs) | Client |
+| `useState` / `useEffect` / browser APIs | Client |
+| Static/non-interactive content | Server |
+| Async children with loading state | Server + `<Suspense>` |
 
 ### Critical Rule
 
-**Never use `next/dynamic` with `{ ssr: false }` inside a Server Component.** Move client-only logic into a dedicated `'use client'` component, then import it normally.
+**Never use `next/dynamic` with `{ ssr: false }` inside a Server Component.** Extract to a dedicated `'use client'` component and import it normally.
 
 ## Data Fetching
 
-### Server-Side Fetching
-
-Fetch directly in `async` Server Components. Next.js deduplicates identical `fetch` calls.
+### Server-Side
 
 ```tsx
 export default async function ProjectsPage() {
-  const projects = await fetch('https://api.example.com/projects', {
-    next: { revalidate: 60 },
-  }).then((res) => res.json());
-  return <ul>{projects.map((p: { id: string; name: string }) => <li key={p.id}>{p.name}</li>)}</ul>;
+  const data = await fetch('/api/projects', { next: { revalidate: 60 } }).then((r) => r.json());
+  return <ul>{data.map((p: { id: string; name: string }) => <li key={p.id}>{p.name}</li>)}</ul>;
 }
 ```
 
-### Server Actions (Mutations)
-
-Define with `'use server'`. Call from Client Components via `action` or `startTransition`.
+### Server Actions
 
 ```tsx
-// lib/actions.ts
 'use server';
 import { revalidatePath } from 'next/cache';
 export async function createItem(formData: FormData) {
-  const name = formData.get('name') as string;
-  await db.items.create({ data: { name } });
+  await db.items.create({ data: { name: formData.get('name') as string } });
   revalidatePath('/items');
 }
 ```
 
-```tsx
-// components/CreateItemForm.tsx
-'use client';
-import { createItem } from '@/lib/actions';
-export default function CreateItemForm() {
-  return <form action={createItem}><input name="name" required /><button type="submit">Add</button></form>;
-}
-```
+Use from a Client Component: `<form action={createItem}>...</form>`
 
-### Parallel Data Fetching
-
-Initiate independent fetches simultaneously — never `await` sequentially.
+### Parallel Fetching
 
 ```tsx
-export default async function DashboardPage() {
-  const [metrics, activity] = await Promise.all([getMetrics(), getRecentActivity()]);
-  return <><MetricsPanel data={metrics} /><ActivityFeed items={activity} /></>;
-}
+const [metrics, activity] = await Promise.all([getMetrics(), getRecentActivity()]);
 ```
 
-## Caching and Revalidation
+## Caching
 
 | Mechanism | Scope | How to Use |
 |-----------|-------|------------|
 | **Request Memoization** | Per-request | Automatic deduplication of identical `fetch` calls |
-| **Data Cache** | Cross-request | `fetch` results cached by default; opt out with `cache: 'no-store'` |
+| **Data Cache** | Cross-request | Cached by default; opt out with `cache: 'no-store'` |
 | **Full Route Cache** | Build time | Static routes cached as HTML + RSC payload |
 | **Router Cache** | Client-side | Prefetched and visited routes cached in browser |
 
-### Revalidation
-
-```tsx
-// Time-based — revalidate every 60 seconds
-fetch(url, { next: { revalidate: 60 } });
-
-// On-demand — revalidate by path or tag
-import { revalidatePath, revalidateTag } from 'next/cache';
-revalidatePath('/blog');
-revalidateTag('posts');
-
-// Tag a fetch for on-demand revalidation
-fetch(url, { next: { tags: ['posts'] } });
-```
+On-demand revalidation: `revalidatePath('/blog')` or `revalidateTag('posts')`. Tag a fetch: `fetch(url, { next: { tags: ['posts'] } })`.
 
 ## Routing
 
@@ -166,211 +110,61 @@ fetch(url, { next: { tags: ['posts'] } });
 
 | File | Purpose |
 |------|---------|
-| `page.tsx` | Route UI (makes segment publicly accessible) |
-| `layout.tsx` | Shared layout (wraps children, persists across navigation) |
+| `page.tsx` | Route UI |
+| `layout.tsx` | Shared layout (persists across navigation) |
 | `template.tsx` | Like layout but re-mounts on navigation |
 | `loading.tsx` | Loading UI (automatic Suspense boundary) |
-| `error.tsx` | Error UI (Client Component, automatic error boundary) |
+| `error.tsx` | Error UI (Client Component) |
 | `not-found.tsx` | 404 UI |
-| `route.ts` | API endpoint (no UI) |
+| `route.ts` | API endpoint |
 | `default.tsx` | Fallback for parallel routes |
 
 ### Dynamic Routes
 
-```
-app/blog/[slug]/page.tsx        → /blog/:slug
-app/shop/[...slug]/page.tsx     → /shop/:slug+ (catch-all)
-app/shop/[[...slug]]/page.tsx   → /shop or /shop/:slug+ (optional catch-all)
-```
-
-### Route Handlers (API Routes)
-
-```ts
-// app/api/users/route.ts
-import { NextRequest, NextResponse } from 'next/server';
-
-export async function GET(request: NextRequest) {
-  const { searchParams } = request.nextUrl;
-  const query = searchParams.get('q');
-  const users = await findUsers(query);
-  return NextResponse.json(users);
-}
-
-export async function POST(request: NextRequest) {
-  const body = await request.json();
-  const user = await createUser(body);
-  return NextResponse.json(user, { status: 201 });
-}
-```
-
-## Error Handling
-
-```tsx
-// app/dashboard/error.tsx — must be a Client Component
-'use client';
-export default function DashboardError({ error, reset }: { error: Error; reset: () => void }) {
-  return <div role="alert"><h2>Something went wrong</h2><button onClick={reset}>Try again</button></div>;
-}
-```
-
-```tsx
-// app/projects/[id]/page.tsx — trigger not-found boundary
-import { notFound } from 'next/navigation';
-export default async function ProjectPage({ params }: { params: { id: string } }) {
-  const project = await getProject(params.id);
-  if (!project) notFound();
-  return <h1>{project.name}</h1>;
-}
-```
+- `app/blog/[slug]/page.tsx` → `/blog/:slug`
+- `app/shop/[...slug]/page.tsx` → `/shop/:slug+` (catch-all)
+- `app/shop/[[...slug]]/page.tsx` → `/shop` or `/shop/:slug+` (optional)
 
 ## Middleware
 
-Runs at the Edge before every matched request. Use for auth, redirects, rewrites, headers.
+Runs at the Edge before every matched request. Use for auth, redirects, rewrites.
 
 ```ts
 import { NextResponse, type NextRequest } from 'next/server';
-
-export function middleware(request: NextRequest) {
-  const token = request.cookies.get('session')?.value;
-  if (!token && request.nextUrl.pathname.startsWith('/dashboard')) {
-    return NextResponse.redirect(new URL('/login', request.url));
-  }
-  // Add custom headers
-  const response = NextResponse.next();
-  response.headers.set('x-request-id', crypto.randomUUID());
-  return response;
+export function middleware(req: NextRequest) {
+  if (!req.cookies.get('session') && req.nextUrl.pathname.startsWith('/dashboard'))
+    return NextResponse.redirect(new URL('/login', req.url));
+  return NextResponse.next();
 }
-
-export const config = { matcher: ['/dashboard/:path*', '/settings/:path*'] };
+export const config = { matcher: ['/dashboard/:path*'] };
 ```
 
-## Configuration
-
-### `next.config.ts`
-
-```ts
-import type { NextConfig } from 'next';
-
-const nextConfig: NextConfig = {
-  reactStrictMode: true,
-  images: {
-    remotePatterns: [
-      { protocol: 'https', hostname: 'cdn.example.com' },
-    ],
-  },
-  experimental: {
-    ppr: true,                    // Partial Prerendering
-    typedRoutes: true,            // Type-safe <Link> hrefs
-  },
-  // Redirects, rewrites, headers
-  async redirects() {
-    return [{ source: '/old-path', destination: '/new-path', permanent: true }];
-  },
-};
-
-export default nextConfig;
-```
-
-### Environment Variables
+## Environment Variables
 
 | Prefix | Available in | Use Case |
 |--------|-------------|----------|
 | `NEXT_PUBLIC_` | Server + Client | Public values (API base URLs, feature flags) |
 | No prefix | Server only | Secrets (DB URLs, API keys, tokens) |
 
-Files loaded (in priority order): `.env.local`, `.env.development` / `.env.production`, `.env`.
-
-## Image and Font Optimization
-
-### Images
-
-```tsx
-import Image from 'next/image';
-import heroImg from '@/public/hero.jpg';
-
-// Local image — auto width/height from import
-<Image src={heroImg} alt="Hero" priority />
-
-// Remote image — must specify dimensions
-<Image src="https://cdn.example.com/photo.jpg" alt="Photo" width={800} height={600} />
-```
-
-### Fonts
-
-```tsx
-// app/layout.tsx
-import { Inter } from 'next/font/google';
-const inter = Inter({ subsets: ['latin'], display: 'swap' });
-
-export default function RootLayout({ children }: { children: React.ReactNode }) {
-  return <html lang="en" className={inter.className}><body>{children}</body></html>;
-}
-```
-
-## Metadata and SEO
-
-```tsx
-// app/layout.tsx — static metadata
-import type { Metadata } from 'next';
-
-export const metadata: Metadata = {
-  title: { default: 'My App', template: '%s | My App' },
-  description: 'App description',
-  openGraph: { title: 'My App', description: 'App description', type: 'website' },
-};
-```
-
-```tsx
-// app/blog/[slug]/page.tsx — dynamic metadata
-import type { Metadata } from 'next';
-
-export async function generateMetadata({ params }: { params: { slug: string } }): Promise<Metadata> {
-  const post = await getPost(params.slug);
-  return { title: post.title, description: post.excerpt };
-}
-```
-
-## Performance Patterns
-
-- **Default to Server Components** — smaller client bundles, faster paint.
-- **`<Suspense>` + `loading.tsx`** — stream content progressively; never block the whole page.
-- **`Promise.all()`** — parallel data fetching for independent data.
-- **Dynamic imports** — lazy-load heavy Client Components with `next/dynamic`.
-- **`<Image>`** — automatic lazy loading, responsive sizing, format conversion.
-- **`next/font`** — zero layout shift, self-hosted fonts.
-- **Route segment config** — fine-tune caching and rendering per route.
-
-## Deployment
-
-Next.js deploys to multiple targets:
-
-| Target | Config | Notes |
-|--------|--------|-------|
-| **Vercel** | Zero-config | Full feature support including Edge, ISR, Middleware |
-| **Node.js server** | `output: 'standalone'` | Minimal `standalone/` folder with server |
-| **Docker** | `output: 'standalone'` | Copy `.next/standalone` + `.next/static` + `public` |
-| **Static export** | `output: 'export'` | No server features (no SSR, API routes, middleware) |
+Files (priority order): `.env.local`, `.env.development` / `.env.production`, `.env`.
 
-## Component Practices & Naming
+## Image, Font, and Metadata
 
-- PascalCase for component files/exports. camelCase for hooks.
-- Shared components in `components/`. Route-specific components co-located in route folder.
-- TypeScript interfaces for props. Explicit types and defaults.
-- Co-locate tests with components.
-- Folders: `kebab-case`. Types/Interfaces: `PascalCase`. Constants: `UPPER_SNAKE_CASE`.
+- **Images**: Use `<Image>` from `next/image` — auto lazy loading, responsive sizing, format conversion. Configure `images.remotePatterns` in `next.config.ts` for remote URLs.
+- **Fonts**: Use `next/font/google` — zero layout shift, self-hosted, no external network request.
+- **Metadata**: Export `metadata` (static) or `generateMetadata` (dynamic) per page/layout for SEO and social previews.
 
 ## Anti-Patterns
 
 | Anti-Pattern | Why It's Wrong | Do This Instead |
 |-------------|---------------|-----------------|
-| `'use client'` on every component | Bloats JS bundle, defeats RSC benefits | Default to Server Components; add `'use client'` only when needed |
-| Sequential `await` for independent data | Creates a waterfall, slows page load | Use `Promise.all()` for parallel fetches |
-| `next/dynamic` with `ssr: false` in Server Components | Build/runtime crash | Extract to a Client Component, import normally |
-| Fetching in `useEffect` when server fetch works | Extra client roundtrip, loading flash | Fetch in the Server Component or use Server Actions |
-| Giant `layout.tsx` with all providers | Hard to test, couples unrelated concerns | Split providers into a `Providers` Client Component |
-| Catching errors without `error.tsx` | Unhandled errors crash the page | Add `error.tsx` per route segment |
-| Hardcoding secrets in source files | Security risk, leaks in version control | Use `.env.local` and `process.env` |
+| `'use client'` on every component | Bloats JS bundle, defeats RSC benefits | Default to Server Components |
+| Sequential `await` for independent data | Waterfall, slows page load | Use `Promise.all()` |
+| `next/dynamic` with `ssr: false` in Server Components | Build/runtime crash | Extract to Client Component |
+| Fetching in `useEffect` when server fetch works | Extra roundtrip, loading flash | Fetch in Server Component or Server Actions |
+| Giant `layout.tsx` with all providers | Hard to test, couples concerns | Split into a `Providers` Client Component |
+| No `error.tsx` per segment | Unhandled errors crash the page | Add `error.tsx` per route segment |
+| Hardcoding secrets in source | Security risk, version control leak | Use `.env.local` and `process.env` |
 | Skipping `loading.tsx` / `<Suspense>` | Blank screen while data loads | Add `loading.tsx` or wrap in `<Suspense>` |
-| Using `getServerSideProps` / `getStaticProps` | Legacy Pages Router patterns | Use App Router with `async` Server Components |
-| Ignoring `next.config.ts` for images | Remote images blocked by default | Configure `images.remotePatterns` |
+| `getServerSideProps` / `getStaticProps` | Legacy Pages Router | Use App Router with async Server Components |
 | Missing `metadata` exports | Poor SEO, no social previews | Export `metadata` or `generateMetadata` per page |

package/src/orchestrator/plugins/nx/SKILL.md

@@ -96,98 +96,46 @@ The NX MCP server provides tools for understanding and working with the workspac
 
 ## Code Generation Workflow
 
-Use this workflow whenever scaffolding new code (libraries, applications, features) or running automated code transformations. **Always prefer generators over manual file creation** when a generator exists for the task.
+Always prefer generators over manual file creation when a generator exists.
 
 ### Phase 1: Discover
 
-1. **List available generators** using `nx_generators` MCP tool
-   - This includes plugin generators (e.g., `@nx/react:library`) and local workspace generators
-2. **Match generator to request** — identify which generator(s) could fulfill the need
-3. **Prefer local generators** — when both local and plugin generators could work, **always prefer local** (they're customized for this repo's patterns)
-4. **If no generator fits** — check `nx_available_plugins` for installable plugins. Only fall back to manual creation after exhausting all generator options
+1. List available generators using `nx_generators` MCP tool (plugin + local workspace generators)
+2. Prefer local generators over plugin generators — they're customized for this repo
+3. If no generator fits, check `nx_available_plugins`; only fall back to manual creation after exhausting all generator options
 
 ### Phase 2: Understand
 
-Before running any generator, complete these steps:
-
-1. **Fetch generator schema** using `nx_generator_schema` MCP tool
-   - Identify required vs optional options
-   - Note default values that may need overriding
-   - Pay attention to options that affect file structure or naming
-
-2. **Read generator source code** (for unfamiliar generators)
-   - Find source: `node -e "console.log(require.resolve('@nx/<plugin>/generators.json'));"`
-   - If that fails: read from `node_modules/<plugin>/generators.json`
-   - Local generators: check `tools/generators/` or local plugin directories
-   - Understanding the source reveals side effects (config updates, dep installs) and files created/modified
-
-3. **Reevaluate generator choice** — after understanding what the generator does, confirm it's the right one. If not, go back to Phase 1 and select a different generator.
-
-4. **Examine repo context** — study existing similar artifacts in the codebase:
-   - Look at how similar projects are structured (naming, test runner, build tool, linter)
-   - Match conventions when configuring the generator
-   - Note directory structures, file patterns, and config styles
-
-5. **Validate required options** — map the user's request to generator options:
-   - Infer values from context where possible
-   - Ask for critical missing information if it cannot be inferred
+1. Fetch generator schema using `nx_generator_schema` — note required options, defaults, and file structure impacts
+2. Read generator source to understand side effects (config updates, dep installs, files created/modified)
+3. Examine existing similar artifacts for naming, structure, test runner, and config conventions; map user's request to generator options
 
 ### Phase 3: Execute
 
-1. **Consider dry-run first** (recommended for complex/unfamiliar generators):
-   ```bash
-   yarn nx generate <generator-name> <options> --dry-run --no-interactive
-   ```
-   - Shows files that would be created/deleted/modified (but not content)
-   - Some generators don't support dry-run (e.g., if they install packages) — skip and run for real
-   - For simple, well-understood generators, you may skip dry-run
+```bash
+yarn nx generate <generator-name> <options> --dry-run --no-interactive  # optional preview
+yarn nx generate <generator-name> <options> --no-interactive
+```
 
-2. **Run the generator**:
-   ```bash
-   yarn nx generate <generator-name> <options> --no-interactive
-   ```
-   **CRITICAL**: Always include `--no-interactive` to prevent prompts that hang execution.
+**CRITICAL**: Always include `--no-interactive` to prevent prompts that hang execution.
 
-   **CRITICAL**: Generators may behave differently based on the current working directory (e.g., library generators use cwd to determine placement). Verify cwd before running.
+**CRITICAL**: Verify cwd before running — generators may use it to determine file placement.
 
-3. **Handle failures** — if the generator fails:
-   - Read the error message carefully
-   - Common causes: missing required options, invalid values, conflicting files, missing dependencies
-   - Adjust options and retry
-   - Use the **self-improvement** skill to add a lesson if the fix was non-obvious
+On failure: read the error, adjust options, and retry. Use the **self-improvement** skill for non-obvious fixes.
 
 ### Phase 4: Post-Generation
 
-1. **Modify generated code** if needed — generators provide a starting point:
-   - Adjust functionality to match specific requirements
-   - Update imports, exports, configurations
-   - Integrate with existing code patterns
-
-2. **Format code**:
-   ```bash
-   yarn nx format --fix
-   ```
-
-3. **Run verification** on generated/affected projects:
-   ```bash
-   yarn nx run <new-project>:lint --fix
-   yarn nx run <new-project>:test
-   yarn nx run <new-project>:build
-   ```
-
-4. **Handle verification failures**:
-   - **Small scope** (few lint errors, minor type issues) — fix directly, re-verify
-   - **Large scope** (many errors, complex problems) — fix obvious issues first, escalate remaining with description of what was generated, what's failing, and what was attempted
+1. Modify generated code to match requirements (imports, exports, config, integrations)
+2. Format: `yarn nx format --fix`
+3. Verify lint, test, and build on generated/affected projects; fix small-scope issues directly, escalate large-scope failures
 
 ## Running Tasks Workflow
 
-When helping with build, test, lint, or serve tasks:
-
 1. Use `nx_current_running_tasks_details` to check for active/completed/failed tasks
-2. For a specific task, use `nx_current_running_task_output` to get its terminal output
+2. Use `nx_current_running_task_output` to get terminal output for a specific task
 3. Diagnose issues from the output and apply fixes
-4. To rerun a task, always use `yarn nx run <taskId>` to preserve the NX context
-5. **Continuous tasks** (like `serve`) are already running — don't offer to rerun, just check output
+4. To rerun, use `yarn nx run <taskId>` to preserve NX context
+5. **Continuous tasks** (like `serve`) are already running — don't rerun, just check output
 
 ## Project Names
 

package/src/orchestrator/plugins/playwright/SKILL.md

@@ -103,25 +103,12 @@ export class LoginPage {
 }
 ```
 
-### Custom Fixtures
+## API Mocking
 
 ```typescript
-// tests/fixtures/auth.fixture.ts
-import { test as base } from '@playwright/test';
-
-type AuthFixtures = {
-  authenticatedPage: Page;
-};
-
-export const test = base.extend<AuthFixtures>({
-  authenticatedPage: async ({ page }, use) => {
-    await page.goto('/login');
-    await page.getByTestId('email-input').fill('test@example.com');
-    await page.getByTestId('password-input').fill('password');
-    await page.getByTestId('login-button').click();
-    await page.waitForURL('**/dashboard');
-    await use(page);
-  },
+// Mock API responses for deterministic tests
+await page.route('/api/login', (route) => {
+  route.fulfill({ status: 200, body: JSON.stringify({ token: 'test' }) });
 });
 ```
 
@@ -189,3 +176,4 @@ The Playwright MCP server enables AI agents to interact with browsers directly:
 - Run tests in parallel (`fullyParallel: true`) for speed
 - Use `trace: 'on-first-retry'` to debug flaky tests
 - Use `codegen` to bootstrap tests, then refactor into page objects
+- Use `page.route()` to mock API responses — create isolated, deterministic tests without backend dependencies