@zigrivers/scaffold 3.6.0 → 3.7.0

package/content/knowledge/web-app/web-app-security.md

@@ -0,0 +1,193 @@
+---
+name: web-app-security
+description: XSS prevention, Content Security Policy, CSRF tokens, clickjacking, Subresource Integrity, dependency auditing, and OWASP top 10 for web apps
+topics: [web-app, security, xss, csp, csrf, clickjacking, owasp, dependency-auditing]
+---
+
+Web application security failures are among the most costly and common causes of data breaches. The OWASP Top 10 has catalogued the same categories of vulnerabilities for decades — not because they are new, but because they recur in every generation of frameworks and technologies. Understanding the attack vectors and their mitigations is not optional for engineers building user-facing web applications. Security must be designed in, not bolted on.
+
+## Summary
+
+### XSS (Cross-Site Scripting) Prevention
+
+XSS occurs when attacker-controlled content is rendered as executable script in a victim's browser. It is the most prevalent web vulnerability class.
+
+**Three XSS types:**
+- **Stored XSS** — malicious script is stored in the database and rendered for all users (e.g., a comment containing `<script>`)
+- **Reflected XSS** — malicious script is in the URL and reflected back in the response (e.g., a search page rendering the query parameter unsanitized)
+- **DOM-based XSS** — malicious script is injected via client-side JavaScript manipulation of the DOM (e.g., `element.innerHTML = location.hash`)
+
+**Primary defense: output encoding.** Modern React, Vue, and Angular frameworks automatically escape string interpolation. The vulnerabilities arise when developers bypass the framework: `dangerouslySetInnerHTML`, `v-html`, `innerHTML`, `document.write`, `eval()`.
+
+**Content Security Policy (CSP):** A `Content-Security-Policy` response header instructs the browser to only execute scripts from trusted sources:
+
+```
+Content-Security-Policy:
+  default-src 'self';
+  script-src 'self' https://trusted-cdn.com;
+  style-src 'self' 'unsafe-inline';
+  img-src 'self' data: https:;
+  font-src 'self' https://fonts.gstatic.com;
+  connect-src 'self' https://api.example.com;
+  frame-ancestors 'none';
+  upgrade-insecure-requests;
+```
+
+`'unsafe-inline'` in `script-src` defeats the XSS protection benefit. Use nonces (`'nonce-{random}'`) or hashes instead for inline scripts.
+
+### Clickjacking Prevention
+
+Clickjacking loads your application in a hidden `<iframe>` on an attacker's page. Users believe they are clicking on the attacker's UI but are actually clicking your application's buttons.
+
+**Defense:** `Content-Security-Policy: frame-ancestors 'none'` (preferred) or the older `X-Frame-Options: DENY`. `frame-ancestors 'none'` prevents your app from being embedded in any frame. Use `frame-ancestors 'self'` if you need to allow same-origin framing.
+
+### CSRF Protection
+
+Cross-Site Request Forgery tricks an authenticated user into submitting a request to your application from an attacker's site. The browser automatically sends cookies, making the forged request appear legitimate.
+
+**Primary defense:** `SameSite=Strict` or `SameSite=Lax` cookies. With `SameSite=Strict`, the cookie is never sent on cross-site requests, making CSRF impossible.
+
+**Secondary defense for legacy or cross-site scenarios:** Synchronizer token pattern — include a CSRF token in every form/request and validate it on the server.
+
+### Subresource Integrity (SRI)
+
+When loading scripts or stylesheets from CDNs, SRI prevents a compromised CDN from serving malicious content:
+
+```html
+<script
+  src="https://cdn.example.com/library.min.js"
+  integrity="sha384-oqVuAfXRKap7fdgcCY5uykM6+R9GqQ8K/ux8P/C5b2E8x2U6sQ=="
+  crossorigin="anonymous"
+></script>
+```
+
+The browser verifies the hash of the loaded resource. If it does not match, the resource is blocked. Generate hashes with: `openssl dgst -sha384 -binary file.js | openssl base64 -A`.
+
+### Dependency Auditing
+
+Third-party dependencies are the most underestimated attack surface. The 2021 Log4Shell vulnerability and 2022 node-ipc supply chain attack demonstrated that a dependency in a dependency can cause a critical vulnerability.
+
+**Baseline practices:**
+- Run `npm audit` or `pnpm audit` in CI — fail the build on critical/high severities
+- Pin exact dependency versions in production builds (lockfile required)
+- Review dependency additions as carefully as code additions
+- Subscribe to security advisories for critical dependencies (GitHub Dependabot, Snyk)
+
+## Deep Guidance
+
+### Content Security Policy Implementation
+
+Deploying CSP in production requires a staged approach — a strict policy will break things:
+
+**Phase 1: Report-only mode.** Use `Content-Security-Policy-Report-Only` with a `report-uri` endpoint. This logs violations without blocking anything. Collect violations for 1–2 weeks.
+
+**Phase 2: Fix violations.** Address inline scripts (move to external files or use nonces), fix disallowed origins, and handle third-party widget requirements.
+
+**Phase 3: Enforce.** Switch to `Content-Security-Policy`. Monitor violation reports for regressions.
+
+```typescript
+// Next.js CSP with nonces (recommended over 'unsafe-inline')
+import { headers } from 'next/headers';
+import crypto from 'crypto';
+
+export default function RootLayout({ children }) {
+  const nonce = crypto.randomBytes(16).toString('base64');
+
+  const cspHeader = [
+    `default-src 'self'`,
+    `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'`,
+    `style-src 'self' 'nonce-${nonce}'`,
+    `img-src 'self' blob: data: https:`,
+    `font-src 'self'`,
+    `object-src 'none'`,
+    `base-uri 'self'`,
+    `form-action 'self'`,
+    `frame-ancestors 'none'`,
+    `upgrade-insecure-requests`,
+  ].join('; ');
+
+  return (
+    <html>
+      <head>
+        <meta httpEquiv="Content-Security-Policy" content={cspHeader} />
+      </head>
+      <body>{children}</body>
+    </html>
+  );
+}
+```
+
+### Security Headers Checklist
+
+Every production web app must serve these response headers:
+
+```
+# Prevent clickjacking
+Content-Security-Policy: frame-ancestors 'none'
+X-Frame-Options: DENY  # Legacy browsers
+
+# Prevent MIME sniffing
+X-Content-Type-Options: nosniff
+
+# Enable HSTS (HTTP Strict Transport Security)
+Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
+
+# Control referrer information
+Referrer-Policy: strict-origin-when-cross-origin
+
+# Control browser features
+Permissions-Policy: camera=(), microphone=(), geolocation=()
+
+# Prevent IE compatibility mode
+X-UA-Compatible: IE=edge
+```
+
+Configure these in your CDN (Cloudflare, Vercel, Fastly) or reverse proxy rather than application code — they should apply to all responses including static assets.
+
+### HTML Sanitization for User Content
+
+When you must render user-supplied HTML (rich text editors, markdown with HTML), use a server-side sanitization library:
+
+```typescript
+import DOMPurify from 'isomorphic-dompurify';
+
+// GOOD: Sanitize before storage and before rendering
+function sanitizeUserHTML(html: string): string {
+  return DOMPurify.sanitize(html, {
+    ALLOWED_TAGS: ['p', 'strong', 'em', 'ul', 'ol', 'li', 'a', 'br', 'blockquote'],
+    ALLOWED_ATTR: ['href', 'target', 'rel'],
+    FORBID_ATTR: ['style', 'class', 'id'],
+    ADD_ATTR: ['rel'],  // Ensure all links have rel="noopener noreferrer"
+    FORCE_BODY: true,
+  });
+}
+
+// BAD: Rendering user HTML without sanitization
+function UnsafeComponent({ userContent }) {
+  return <div dangerouslySetInnerHTML={{ __html: userContent }} />; // XSS risk
+}
+
+// GOOD: Sanitize before rendering
+function SafeComponent({ userContent }) {
+  return <div dangerouslySetInnerHTML={{ __html: sanitizeUserHTML(userContent) }} />;
+}
+```
+
+**Always add `rel="noopener noreferrer"` to user-supplied links.** Without `noopener`, the linked page can access `window.opener` and redirect the original tab.
+
+### OWASP Top 10 Mapping
+
+| OWASP 2021 | Web App Mitigation |
+|---|---|
+| A01 Broken Access Control | Server-side authz on every endpoint; never trust client-claimed identity |
+| A02 Cryptographic Failures | TLS everywhere; never store passwords in plaintext; use bcrypt/Argon2 |
+| A03 Injection | Parameterized queries; ORM; never concatenate user input into SQL/shell commands |
+| A04 Insecure Design | Threat model before building auth/payment flows |
+| A05 Security Misconfiguration | Headers checklist; disable debug endpoints in production; rotate default credentials |
+| A06 Vulnerable Components | `npm audit` in CI; Dependabot alerts; pin lockfile |
+| A07 Auth Failures | PKCE; rate limiting on login; MFA; session timeout |
+| A08 Software Integrity | SRI for CDN assets; verify npm package checksums; signed commits |
+| A09 Logging Failures | Log auth events; alert on anomalies; never log passwords or tokens |
+| A10 SSRF | Validate and restrict URLs in server-side fetch calls; block private IP ranges |
+
+Run a security review against this checklist before the first production deployment and after any major auth or data flow change.

package/content/knowledge/web-app/web-app-session-patterns.md

@@ -0,0 +1,214 @@
+---
+name: web-app-session-patterns
+description: Session management architecture, JWT vs cookie sessions, refresh token rotation, session storage, and hijacking prevention
+topics: [web-app, auth, sessions, jwt, cookies, security, redis]
+---
+
+Session management is the mechanism by which a web application recognizes a returning user between HTTP requests. Because HTTP is stateless, sessions are an application-level construct — and the design decisions here directly affect security, scalability, and user experience. The wrong session architecture causes token theft, session fixation attacks, memory exhaustion on the server, and logout failures that leave users permanently authenticated even after they believe they've signed out.
+
+## Summary
+
+### JWT vs Cookie Sessions
+
+The two primary session patterns have fundamentally different security models:
+
+**Cookie-based sessions (server-authoritative):**
+- Server stores session state (database or Redis); client holds an opaque session ID in a cookie
+- Immediate revocation: delete the session record and the user is logged out
+- Scales horizontally when session storage is centralized (Redis cluster)
+- HttpOnly + Secure + SameSite=Strict cookies resist XSS and CSRF simultaneously
+- Each request requires a session store lookup — adds latency (~1–5 ms for Redis)
+
+**JWT (stateless):**
+- Server stores no session state; the signed token is the complete session
+- No revocation without a token denylist (which re-introduces statefulness)
+- Zero session store lookups per request — appropriate for stateless microservices
+- Tokens can be stolen and reused until expiry — short expiry (15 minutes) is essential
+- Refresh tokens enable long sessions without long-lived access tokens
+
+**Rule of thumb:** Use cookie-based sessions for user-facing web apps where revocation matters. Use JWTs for service-to-service auth or APIs where clients are trusted and revocation is not required. Hybrid: short-lived JWTs + server-side refresh token rotation is the most common production pattern.
+
+### Refresh Token Rotation
+
+Refresh token rotation is the critical security mechanism for long-lived JWT sessions:
+
+1. Access token expires in 15 minutes
+2. Client uses refresh token to obtain a new access token + new refresh token
+3. The old refresh token is immediately invalidated
+4. If the old refresh token is ever presented again, all sessions for that user are terminated (token reuse detection indicates theft)
+
+This pattern detects token theft: if an attacker steals a refresh token and uses it, the legitimate user's next refresh attempt will fail and force re-authentication, alerting the user and invalidating the attacker's session.
+
+### Session Storage Backends
+
+| Backend | Best For | Limits |
+|---|---|---|
+| Redis (single node) | Fast sessions, moderate scale | Single point of failure |
+| Redis Cluster | High availability, large scale | Operational complexity |
+| Redis Sentinel | Automatic failover for single-node Redis | Less scale than Cluster |
+| Database (PostgreSQL) | Simpler stack, queryable sessions | Higher latency than Redis |
+| In-process memory | Development only | Lost on restart, no horizontal scale |
+
+For production, Redis is the standard choice: sub-millisecond lookups, TTL-based expiry is native, and session invalidation is an O(1) DEL command.
+
+### Token Expiry Strategy
+
+Define expiry per token type based on risk tolerance:
+
+- **Access token**: 15 minutes — short enough to limit exposure if stolen
+- **Refresh token**: 7–30 days — rotate on each use; invalidate on logout
+- **Remember-me token**: 90 days — separate from standard refresh, requires stronger audit
+- **Email verification token**: 24–48 hours — single-use, invalidate on consumption
+- **Password reset token**: 1 hour — single-use, invalidate on consumption, invalidate all sessions on use
+
+## Deep Guidance
+
+### Secure Cookie Configuration
+
+Every session cookie must be configured with all three security attributes:
+
+```typescript
+// Express.js session cookie configuration
+app.use(session({
+  name: '__Host-sessionId',  // __Host- prefix requires Secure + path=/ + no domain
+  secret: process.env.SESSION_SECRET,
+  resave: false,
+  saveUninitialized: false,
+  cookie: {
+    httpOnly: true,       // Inaccessible to JavaScript — prevents XSS token theft
+    secure: true,         // HTTPS only — prevents transmission over HTTP
+    sameSite: 'strict',   // Not sent on cross-site requests — prevents CSRF
+    maxAge: 7 * 24 * 60 * 60 * 1000,  // 7 days in milliseconds
+    path: '/',
+  },
+  store: new RedisStore({ client: redisClient }),
+}));
+```
+
+The `__Host-` cookie name prefix is a browser-enforced security policy that prevents subdomain hijacking — it requires `Secure`, `path=/`, and no `Domain` attribute. Use it for session cookies in production.
+
+### Refresh Token Rotation Implementation
+
+```typescript
+interface TokenPair {
+  accessToken: string;
+  refreshToken: string;
+  accessTokenExpiresAt: Date;
+}
+
+async function rotateRefreshToken(
+  incomingRefreshToken: string
+): Promise<TokenPair> {
+  // 1. Look up the incoming refresh token
+  const storedToken = await db.refreshToken.findUnique({
+    where: { token: incomingRefreshToken },
+    include: { user: true },
+  });
+
+  if (!storedToken) {
+    // Token not found — could be expired, already rotated, or forged
+    throw new AuthError('INVALID_REFRESH_TOKEN');
+  }
+
+  if (storedToken.usedAt !== null) {
+    // REUSE DETECTED: token was already rotated — potential theft
+    // Invalidate ALL refresh tokens for this user
+    await db.refreshToken.updateMany({
+      where: { userId: storedToken.userId },
+      data: { revokedAt: new Date() },
+    });
+    throw new AuthError('TOKEN_REUSE_DETECTED');
+  }
+
+  if (storedToken.revokedAt !== null || storedToken.expiresAt < new Date()) {
+    throw new AuthError('REFRESH_TOKEN_EXPIRED');
+  }
+
+  // 2. Mark old token as used (not deleted — needed for reuse detection)
+  await db.refreshToken.update({
+    where: { id: storedToken.id },
+    data: { usedAt: new Date() },
+  });
+
+  // 3. Issue new token pair
+  const newAccessToken = signAccessToken({ sub: storedToken.userId });
+  const newRefreshToken = await db.refreshToken.create({
+    data: {
+      userId: storedToken.userId,
+      token: generateSecureToken(),
+      expiresAt: addDays(new Date(), 30),
+      parentTokenId: storedToken.id,  // Track rotation chain
+    },
+  });
+
+  return {
+    accessToken: newAccessToken,
+    refreshToken: newRefreshToken.token,
+    accessTokenExpiresAt: addMinutes(new Date(), 15),
+  };
+}
+```
+
+### Session Hijacking Prevention
+
+Beyond secure cookies, defend against session hijacking at the application layer:
+
+**IP binding (optional, use carefully):**
+- Store the client IP at session creation and validate on each request
+- Breaks for legitimate users on mobile networks (IP changes per cell tower)
+- Use only for high-security flows (admin panels, bank-grade apps), not general user sessions
+
+**User-Agent fingerprint:**
+- Store a hash of the User-Agent string at session creation
+- Validate on each request; suspicious changes invalidate the session
+- Not a strong defense (UA is spoofable) but raises the cost of attack
+
+**Session fixation prevention:**
+- Always regenerate the session ID on successful authentication
+- Never allow the session ID to be set via URL parameters (cookie-only)
+- In Express: call `req.session.regenerate()` after successful login
+
+**Concurrent session limits:**
+- Track active session count per user in Redis
+- On new login, offer the user the choice to log out other sessions or enforce a maximum
+- Essential for compliance in regulated industries
+
+### Redis Session Store with TTL
+
+```typescript
+import Redis from 'ioredis';
+import RedisStore from 'connect-redis';
+
+const redisClient = new Redis({
+  host: process.env.REDIS_HOST,
+  port: 6379,
+  // Lazy connect — don't block startup if Redis is temporarily unavailable
+  lazyConnect: true,
+  // Retry strategy — exponential backoff
+  retryStrategy: (times: number) => Math.min(times * 50, 2000),
+});
+
+// Sessions expire automatically via Redis TTL — no cleanup job needed
+const sessionStore = new RedisStore({
+  client: redisClient,
+  prefix: 'sess:',
+  ttl: 7 * 24 * 60 * 60,  // 7 days in seconds
+});
+
+// Invalidate a specific session (logout)
+async function invalidateSession(sessionId: string): Promise<void> {
+  await redisClient.del(`sess:${sessionId}`);
+}
+
+// Invalidate all sessions for a user (force logout everywhere)
+async function invalidateAllUserSessions(userId: string): Promise<void> {
+  // Requires storing a user→sessions index in Redis
+  const sessionIds = await redisClient.smembers(`user:sessions:${userId}`);
+  if (sessionIds.length > 0) {
+    await redisClient.del(...sessionIds.map(id => `sess:${id}`));
+    await redisClient.del(`user:sessions:${userId}`);
+  }
+}
+```
+
+Maintain a `user:sessions:{userId}` Redis set to enable "logout everywhere" — essential for security incident response.

package/content/knowledge/web-app/web-app-testing.md

@@ -0,0 +1,249 @@
+---
+name: web-app-testing
+description: Component testing with Testing Library, SSR testing, E2E testing with Playwright, visual regression, accessibility testing with axe-core, and Lighthouse CI
+topics: [web-app, testing, playwright, testing-library, accessibility, visual-regression, lighthouse, e2e]
+---
+
+Web application testing requires covering multiple distinct layers: component behavior, server rendering correctness, end-to-end user flows, visual appearance, accessibility compliance, and performance budgets. Each layer catches different classes of bugs and has different cost/value characteristics. The correct strategy invests heavily in component and integration tests (fast feedback, high coverage), uses E2E tests for critical user journeys (slow but comprehensive), and enforces visual and performance budgets in CI (catches regressions before users do).
+
+## Summary
+
+### Testing Layers
+
+**Component tests (Testing Library):** Test components in isolation from the DOM's perspective — interactions, rendering, and state changes. These form the bulk of the test suite. Use `@testing-library/user-event` for realistic interactions, not `fireEvent`.
+
+**Integration tests:** Test pages or feature slices with real data flow but mocked network calls. Verify that components interact correctly. In Next.js: test pages as React components with a mocked router.
+
+**SSR tests (render-to-string):** Verify server-rendered HTML is correct and does not throw. Check that SSR and hydration produce consistent output (no hydration mismatches). Use `@testing-library/react`'s `renderToStaticMarkup` or framework-specific utilities.
+
+**E2E tests (Playwright):** Test complete user flows in a real browser against a running application. Reserve for high-value, business-critical flows: registration, login, checkout, core product value proposition. Keep the E2E suite small and fast (target under 10 minutes for the critical path).
+
+**Visual regression tests:** Screenshot comparison against committed baselines. Catch unintended UI changes from CSS refactors, component updates, or dependency upgrades. Run against a static Storybook deployment for fast, stable comparisons.
+
+**Accessibility tests (axe-core):** Automated WCAG compliance checking. Catches ~30–40% of accessibility issues automatically. Not a substitute for manual testing with a screen reader, but essential for catching regressions.
+
+**Performance tests (Lighthouse CI):** Enforce performance budgets in CI. Fail the build if LCP, CLS, or INP regressions are detected.
+
+### Testing Library Principles
+
+Testing Library is designed around the principle that tests should resemble how users interact with the application:
+
+- **Query by role first** — `getByRole('button', { name: 'Submit' })` over `getByTestId`
+- **Query by label text** — `getByLabelText('Email address')` for form inputs
+- **Never query by CSS class** — classes are implementation details, not behavior
+- **Use `userEvent` not `fireEvent`** — `userEvent.type()` simulates real keystrokes including focus, blur, and change events; `fireEvent` dispatches synthetic events that skip browser behaviors
+
+### Playwright for E2E
+
+Playwright supports Chromium, Firefox, and WebKit. Configure it to run against your staging environment in CI and your local dev server locally. Key features:
+- Auto-waiting: Playwright automatically waits for elements to be ready before interacting
+- Network mocking: intercept and mock API responses in tests
+- Trace viewer: visual debugging of test failures with full network and DOM timeline
+- Component testing: Playwright can also test components in isolation (alternative to Testing Library for teams that want one tool)
+
+## Deep Guidance
+
+### Component Testing Patterns
+
+```typescript
+// UserProfile.test.tsx — Testing Library patterns
+import { render, screen, waitFor } from '@testing-library/react';
+import userEvent from '@testing-library/user-event';
+import { UserProfile } from './UserProfile';
+import { server } from '@/mocks/server';  // MSW mock server
+import { http, HttpResponse } from 'msw';
+
+describe('UserProfile', () => {
+  it('displays user data after loading', async () => {
+    render(<UserProfile userId="user-123" />);
+
+    // Loading state
+    expect(screen.getByRole('status')).toBeInTheDocument();
+
+    // Data loads
+    await screen.findByText('Jane Smith');  // Awaits element appearance
+    expect(screen.getByText('jane@example.com')).toBeInTheDocument();
+    expect(screen.queryByRole('status')).not.toBeInTheDocument();
+  });
+
+  it('allows editing the display name', async () => {
+    const user = userEvent.setup();
+    render(<UserProfile userId="user-123" />);
+
+    await screen.findByText('Jane Smith');
+    await user.click(screen.getByRole('button', { name: 'Edit profile' }));
+
+    const nameInput = screen.getByLabelText('Display name');
+    await user.clear(nameInput);
+    await user.type(nameInput, 'Jane Doe');
+    await user.click(screen.getByRole('button', { name: 'Save changes' }));
+
+    await screen.findByText('Profile updated successfully');
+    expect(screen.getByText('Jane Doe')).toBeInTheDocument();
+  });
+
+  it('shows an error message when the save fails', async () => {
+    // Override the default MSW handler for this test
+    server.use(
+      http.patch('/api/users/:id', () =>
+        HttpResponse.json({ error: 'Server error' }, { status: 500 })
+      )
+    );
+
+    const user = userEvent.setup();
+    render(<UserProfile userId="user-123" />);
+
+    await screen.findByText('Jane Smith');
+    await user.click(screen.getByRole('button', { name: 'Edit profile' }));
+    await user.click(screen.getByRole('button', { name: 'Save changes' }));
+
+    await screen.findByRole('alert');
+    expect(screen.getByText(/something went wrong/i)).toBeInTheDocument();
+  });
+});
+```
+
+Use Mock Service Worker (MSW) for network mocking — it intercepts requests at the network level, making tests work identically in browser and Node environments.
+
+### Playwright E2E Tests
+
+```typescript
+// tests/e2e/auth.spec.ts — Playwright E2E for critical auth flow
+import { test, expect } from '@playwright/test';
+
+test.describe('Authentication', () => {
+  test('user can register and log in', async ({ page }) => {
+    const email = `test-${Date.now()}@example.com`;
+
+    // Registration
+    await page.goto('/register');
+    await page.getByLabel('Email address').fill(email);
+    await page.getByLabel('Password').fill('SecureP@ss123');
+    await page.getByLabel('Confirm password').fill('SecureP@ss123');
+    await page.getByRole('button', { name: 'Create account' }).click();
+
+    // Should redirect to onboarding
+    await expect(page).toHaveURL('/onboarding');
+    await expect(page.getByText('Welcome')).toBeVisible();
+
+    // Log out
+    await page.getByRole('button', { name: 'Account menu' }).click();
+    await page.getByRole('menuitem', { name: 'Sign out' }).click();
+    await expect(page).toHaveURL('/');
+
+    // Log in
+    await page.goto('/login');
+    await page.getByLabel('Email address').fill(email);
+    await page.getByLabel('Password').fill('SecureP@ss123');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+
+    await expect(page).toHaveURL('/dashboard');
+  });
+
+  test('shows error for invalid credentials', async ({ page }) => {
+    await page.goto('/login');
+    await page.getByLabel('Email address').fill('nonexistent@example.com');
+    await page.getByLabel('Password').fill('wrongpassword');
+    await page.getByRole('button', { name: 'Sign in' }).click();
+
+    await expect(page.getByRole('alert')).toContainText('Invalid email or password');
+    await expect(page).toHaveURL('/login');
+  });
+});
+```
+
+### Accessibility Testing with axe-core
+
+```typescript
+// Integrate axe-core into component tests
+import { render } from '@testing-library/react';
+import { axe, toHaveNoViolations } from 'jest-axe';
+
+expect.extend(toHaveNoViolations);
+
+describe('Accessibility', () => {
+  it('LoginForm has no accessibility violations', async () => {
+    const { container } = render(<LoginForm />);
+    const results = await axe(container);
+    expect(results).toHaveNoViolations();
+  });
+});
+
+// Playwright accessibility snapshot
+test('dashboard is accessible', async ({ page }) => {
+  await page.goto('/dashboard');
+  const accessibilityScanResults = await new AxeBuilder({ page })
+    .withTags(['wcag2a', 'wcag2aa'])
+    .analyze();
+  expect(accessibilityScanResults.violations).toEqual([]);
+});
+```
+
+Axe-core checks: missing alt text, insufficient color contrast, missing form labels, improper heading hierarchy, keyboard navigation issues, and ARIA attribute misuse. Run it against every page in CI.
+
+### Lighthouse CI Configuration
+
+```yaml
+# lighthouserc.yml
+ci:
+  collect:
+    url:
+      - 'http://localhost:3000/'
+      - 'http://localhost:3000/dashboard'
+    numberOfRuns: 3  # Average across multiple runs for stability
+    settings:
+      preset: 'desktop'
+      throttling:
+        rttMs: 40
+        throughputKbps: 10240
+        cpuSlowdownMultiplier: 1
+
+  assert:
+    preset: 'lighthouse:no-pwa'
+    assertions:
+      # Core Web Vitals
+      largest-contentful-paint:
+        - error
+        - maxNumericValue: 2500
+          aggregationMethod: optimistic  # Use best of N runs
+      cumulative-layout-shift:
+        - error
+        - maxNumericValue: 0.1
+      total-blocking-time:
+        - warn
+        - maxNumericValue: 300
+
+      # Performance budget
+      uses-optimized-images: ['warn', { minScore: 0.9 }]
+      uses-text-compression: ['error', { minScore: 1 }]
+      render-blocking-resources: ['warn', { minScore: 0.8 }]
+
+      # Accessibility
+      categories:accessibility: ['error', { minScore: 0.9 }]
+```
+
+Run Lighthouse CI in a separate CI step after deployment to your staging environment. Fail only on errors (hard regressions); warn on improvements.
+
+### SSR Hydration Testing
+
+```typescript
+// Verify SSR output and hydration consistency
+import { renderToString } from 'react-dom/server';
+import { render } from '@testing-library/react';
+
+test('ProductCard renders consistently in SSR and client', () => {
+  const props = { name: 'Widget', price: 29.99 };
+
+  // SSR render
+  const ssrHTML = renderToString(<ProductCard {...props} />);
+
+  // Client render
+  const { container } = render(<ProductCard {...props} />);
+
+  // Compare — normalize whitespace differences
+  const normalize = (html: string) => html.replace(/\s+/g, ' ').trim();
+  expect(normalize(container.innerHTML)).toBe(normalize(ssrHTML));
+});
+```
+
+Hydration mismatches produce React warnings in development and can cause visual flicker in production. Test SSR/client consistency for any component that uses `Date.now()`, `Math.random()`, browser APIs, or dynamic imports.