Front-End-Checklist Documentation

Click me

</After>
</CodeComparison>

Testing Examples Copy Section

Provide tests for multiple frameworks. Prioritize:

1. Jest/Vitest - Unit tests
2. Playwright - E2E tests
3. Cypress - E2E alternative
4. axe-core - Accessibility-specific

Writing Style Guide Copy Chapter

Voice & Tone Copy Section

• Active voice: "Add alt text" not "Alt text should be added"
• Direct address: "You should" or imperative "Add..."
• Confident but not arrogant: State best practices, acknowledge exceptions
• Concise: Every sentence should add value

Sentence Structure Copy Section

<!-- ✅ Good: Direct and actionable -->
All images must have appropriate alternative text.

<!-- ❌ Bad: Passive and wordy -->
It is recommended that alternative text be provided for images in order to ensure accessibility.

Technical Accuracy Copy Section

• Use precise technical terms
• Cite specifications when relevant (WCAG, HTML spec)
• Include version numbers for evolving standards

<!-- ✅ Good: Specific reference -->
This rule addresses WCAG 2.1 Success Criterion 1.1.1 (Non-text Content).

<!-- ❌ Bad: Vague reference -->
This helps with accessibility requirements.

Inclusive Language Copy Section

• Disability: Use person-first or identity-first based on community preference
• Users: Refer to specific user groups, not "normal users"
• Ability: Avoid ableist language ("see below", "blind to")

<!-- ✅ Good -->
Screen reader users will hear...
Users with low vision benefit from...
Keyboard users can navigate by...

<!-- ❌ Bad -->
Blind people need...
Normal users won't notice...
If you can see the screen...

Terminology Glossary Copy Chapter

Technical Terms Copy Section

Accessibility Terms Copy Section

Framework Terms Copy Section

Anti-Patterns Copy Chapter

Content Anti-Patterns Copy Section

Vague Guidance

<!-- ❌ Bad -->
Make sure your images are accessible.

<!-- ✅ Good -->
Add descriptive alt text to all `<img>` elements. Use empty `alt=""` for decorative images.

Tool Agnosticism When Opinion Helps

<!-- ❌ Bad -->
There are many tools available to test this.

<!-- ✅ Good -->
Use [axe DevTools](https://www.deque.com/axe/) for automated detection.
For manual testing, use NVDA (Windows) or VoiceOver (Mac).

Excessive Framework Coverage

<!-- ❌ Bad: Every framework for a simple HTML rule -->
## Framework Examples
[React, Vue, Angular, Svelte, Solid, Qwik, Astro, Remix, Next, Nuxt...]

<!-- ✅ Good: Only when frameworks handle it differently -->
## Framework Examples
[Show only if framework has specific API or gotcha]

Missing Context for Code

<!-- ❌ Bad: Code without explanation -->
```html

For images below the fold, add lazy loading to improve initial page load:

### Structure Anti-Patterns

#### Heading Hierarchy Violations

```mdx
<!-- ❌ Bad: Skipping levels -->
## Implementation
#### Specific Detail  <!-- Skipped h3 -->

<!-- ✅ Good: Sequential hierarchy -->
## Implementation
### Basic Usage
#### Edge Case

Callout Overload

<!-- ❌ Bad: Wall of callouts -->
<Tip>...</Tip>
<Warning>...</Warning>
<Tip>...</Tip>
<Warning>...</Warning>

<!-- ✅ Good: Strategic placement -->
[Content explaining concept]
<Tip>Key insight</Tip>
[More content]
<Warning>Important gotcha</Warning>

Testing Without Context

<!-- ❌ Bad: Test code dump -->
```javascript
test('images have alt', () => { ... })

Verify all images have appropriate alt attributes. Decorative images should have empty alt:

test('informative images have descriptive alt', () => { ... })
test('decorative images have empty alt', () => { ... })

---

## Page Rendering

### Layout Structure

┌─────────────────────────────────────────────────────────┐
│ Breadcrumb: Home > Rules > Category > Rule Title │
├─────────────────────────────────────────────────────────┤
│ ┌─────────────────────────────────┐ ┌─────────────────┐ │
│ │ Main Content │ │ Sidebar │ │
│ │ │ │ │ │
│ │ Title [Done] │ │ Table of │ │
│ │ Description │ │ Contents │ │
│ │ [Priority] [Difficulty] [Time] │ │ │ │
│ │ [Categories...] │ │ - Section 1 │ │
│ │ │ │ - Section 2 │ │
│ │ ┌─────────────────────────────┐ │ │ - Section 3 │ │
│ │ │ TL;DR │ │ │ │ │
│ │ │ • Point 1 │ │ │ ─────────────── │ │
│ │ │ • Point 2 │ │ │ │ │
│ │ │ Why: Single sentence │ │ │ Related Rules │ │
│ │ └─────────────────────────────┘ │ │ │ │
│ │ │ │ • Related 1 │ │
│ │ [MDX Content...] │ │ • Related 2 │ │
│ │ │ │ • Related 3 │ │
│ │ ─────────────────────────────── │ │ │ │
│ │ │ └─────────────────┘ │
│ │ AI Prompts │ │
│ │ [Check] [Fix] [Explain] │ │
│ │ │ │
│ │ ─────────────────────────────── │ │
│ │ │ │
│ │ Tools & Resources │ │
│ │ • Tool 1 ↗ │ │
│ │ • Tool 2 ↗ │ │
│ └─────────────────────────────────┘ │
├─────────────────────────────────────────────────────────┤
│ [AI Prompts FAB] │
└─────────────────────────────────────────────────────────┘

### UI Components Behavior

#### Priority Indicator
Colored badge with dot: Critical (red), High (orange), Medium (yellow), Low (green)

#### AI Prompts FAB (Floating Action Button)
- Fixed position bottom-right
- Shows all 3 prompts on click (Check, Fix, Explain)
- One-click copy to clipboard
- Doesn't obscure content

#### Table of Contents
- Sticky sidebar on desktop
- Highlights current section
- Depth: h2 and h3 only

#### Related Rules
- Smart suggestions based on content similarity
- Max 5 rules shown
- Falls back to same-category if no similar content

#### Last Updated
- Shown in header area
- Format: "Updated Jan 2025"
- Derived from git history or frontmatter

---

## Appendix

### Minimum Viable Rule

The absolute minimum for a valid rule:

```mdx
---
title: Use the HTML5 doctype
description: The Doctype is HTML5 and is at the top of all your HTML pages.
categories: ['html']
priority: 'critical'
prompts:
  check: "Verify this HTML document has <!DOCTYPE html> at the top."
  fix: "Add <!DOCTYPE html> as the first line of the HTML document."
  explain: "Explain why HTML5 doctype is required for standards mode rendering."
---

The HTML5 doctype must be declared at the very top of every HTML page.

## Basic Implementation

```html
<!DOCTYPE html>
<html lang="en">
  <head>...</head>
  ...
</html>

### Complete Rule Examples

See these comprehensive examples demonstrating all sections and components:

- `/packages/content/rules/en/html/alt-text.mdx` - Demonstrates accessibility rule patterns, testing approaches, and semantic HTML guidance
- `/packages/content/rules/en/images/image-optimization.mdx` - Demonstrates CodeTabs with framework examples (React, Next.js, Vue.js), build tool integration, and performance optimization patterns

---

*Last updated: January 2025*

---

## File: tsconfig.base.json

{
  "extends": "./configs/config-typescript/base.json",
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@repo/design-system": ["./packages/design-system/src/design-system"],
      "@repo/*": ["./packages/*/src", "./configs/*"]
    }
  }
}

---

## File: turbo.json

{
  "$schema": "https://turbo.build/schema.json",
  "globalDependencies": ["**/.env.*local"],
  "tasks": {
    "build": {
      "dependsOn": ["^build"],
      "inputs": ["$TURBO_DEFAULT$", ".env*"],
      "env": [
        "DATABASE_URL",
        "BETTER_AUTH_SECRET",
        "BETTER_AUTH_URL",
        "ENABLE_REMOTE_DATA_FETCH",
        "GITHUB_CLIENT_ID",
        "GITHUB_CLIENT_SECRET",
        "GITHUB_SPONSORS_LOGIN",
        "GITHUB_TOKEN",
        "MCP_TELEMETRY_ENABLED",
        "NEXT_PUBLIC_OPENPANEL_CLIENT_ID",
        "NEXT_PUBLIC_MCP_URL",
        "NEXT_PUBLIC_SITE_URL",
        "OPENPANEL_API_URL",
        "OPENPANEL_CLIENT_SECRET",
        "OPENPANEL_SECRET_ID",
        "OPENAI_APPS_CHALLENGE_TOKEN",
        "PUBLIC_SUPPORT_EMAIL",
        "RESEND_API_KEY",
        "RESEND_AUDIENCE_ID",
        "RESEND_TOPIC_ID",
        "NEXT_PUBLIC_SENTRY_DSN",
        "SENTRY_DSN",
        "SENTRY_AUTH_TOKEN",
        "SENTRY_OTLP_TRACES_URL",
        "SENTRY_ORG",
        "SENTRY_PROJECT",
        "SENTRY_PUBLIC_KEY",
        "SENTRY_VERCEL_LOG_DRAIN_URL",
        "SUBSCRIBE_SECRET",
        "KV_REST_API_TOKEN",
        "KV_REST_API_READ_ONLY_TOKEN",
        "KV_REST_API_URL",
        "KV_URL",
        "REDIS_URL",
        "UPSTASH_REDIS_REST_TOKEN",
        "UPSTASH_REDIS_REST_URL"
      ],
      "outputs": [".next/**", "!.next/cache/**", "dist/**", "build/**"]
    },
    "@repo/auth#build": {
      "cache": false,
      "env": ["DATABASE_URL"]
    },
    "dev": {
      "cache": false,
      "persistent": true
    },
    "lint": {
      "dependsOn": ["^lint"]
    },
    "test": {
      "dependsOn": ["^build"],
      "inputs": ["src/**/*.tsx", "src/**/*.ts", "test/**/*.ts", "test/**/*.tsx"],
      "outputs": ["coverage/**"]
    },
    "test:ci": {
      "dependsOn": ["^build"],
      "inputs": ["src/**/*.tsx", "src/**/*.ts", "test/**/*.ts", "test/**/*.tsx"],
      "outputs": ["coverage/**"],
      "cache": false
    },
    "test:coverage": {
      "dependsOn": ["^build"],
      "inputs": ["src/**/*.tsx", "src/**/*.ts", "test/**/*.ts", "test/**/*.tsx"],
      "outputs": ["coverage/**"],
      "cache": false
    },
    "test:coverage:check": {
      "dependsOn": ["^build"],
      "inputs": ["src/**/*.tsx", "src/**/*.ts", "test/**/*.ts", "test/**/*.tsx"],
      "outputs": ["coverage/**"],
      "cache": false
    },
    "typecheck": {
      "dependsOn": ["^build"],
      "inputs": ["src/**/*.tsx", "src/**/*.ts", "**/*.json"],
      "cache": true
    },
    "e2e": {
      "dependsOn": ["build"],
      "inputs": ["e2e/**/*.ts", "e2e/**/*.tsx", "playwright.config.ts"],
      "outputs": ["playwright-report/**", "test-results/**"],
      "cache": false
    },
    "e2e:headed": {
      "dependsOn": ["build"],
      "cache": false
    },
    "e2e:ui": {
      "dependsOn": ["build"],
      "cache": false
    },
    "clean": {
      "cache": false
    }
  }
}

---

## File: .mcp.json

{
  "mcpServers": {
    "frontend-checklist": {
      "command": "npx",
      "args": ["tsx", "packages/mcp/src/cli.ts"],
      "cwd": "/Users/thedaviddias/Projects/frontendchecklist.io"
    },
    "qmd": {
      "command": "qmd",
      "args": ["mcp"],
      "cwd": "/Users/thedaviddias/Projects/frontendchecklist.io"
    }
  }
}

---

## File: apps/e2e/README.md

# E2E Testing with Playwright

## Overview

This directory contains end-to-end tests for the web application using Playwright with a Page Object Model (POM) architecture for maintainability and scalability.

## Architecture

e2e/
├── config/ # Centralized test configuration
│ └── test.config.ts
├── fixtures/ # Custom test fixtures and helpers
│ ├── test.fixture.ts
│ └── test-helpers.ts
├── pages/ # Page Object Models
│ ├── base.page.ts
│ ├── home.page.ts
│ └── counter.page.ts
├── tests/ # Test specifications
│ ├── homepage.spec.ts
│ ├── counter.spec.ts
│ ├── accessibility.spec.ts
│ └── performance.spec.ts
└── utils/ # Utility functions
├── test.utils.ts
├── performance.utils.ts
└── accessibility.utils.ts

## Running Tests

### Local Development

```bash
# Install Playwright browsers (first time only)
pnpm run e2e:install

# Run all tests
pnpm run e2e

# Run tests in headed mode (see browser)
pnpm run e2e:headed

# Run tests in UI mode (interactive)
pnpm run e2e:ui

# Run specific test file
pnpm run e2e tests/homepage.spec.ts

# Run tests with specific tag
pnpm run e2e --grep="@smoke"

# Run tests on specific browser
pnpm run e2e --project=chromium
pnpm run e2e --project=firefox
pnpm run e2e --project=webkit

# Debug tests
pnpm run e2e:debug

CI/CD Copy Section

Tests run automatically in CI on:

• Pull requests (smoke tests only)
• Pushes to main/develop branches (full suite)
• Deployment workflows

# Run tests as they run in CI
CI=true pnpm run e2e

# Run with sharding (for parallel execution)
pnpm run e2e --shard=1/3
pnpm run e2e --shard=2/3
pnpm run e2e --shard=3/3

Writing Tests Copy Chapter

Using Page Objects Copy Section

import { test, expect } from '../fixtures/test.fixture'

test('example test', async ({ homePage, counterPage }) => {
  // Navigate using page object
  await homePage.goto()
  
  // Verify using page object methods
  await homePage.verifyPageLoaded()
  
  // Interact with components
  await counterPage.increment()
  await counterPage.verifyCounterValue(1)
})

Using Utilities Copy Section

test('performance test', async ({ performanceUtils }) => {
  const metrics = await performanceUtils.measureCoreWebVitals()
  expect(metrics.lcp).toBeLessThan(2500)
})

test('accessibility test', async ({ accessibilityUtils }) => {
  const result = await accessibilityUtils.checkAccessibilityViolations()
  expect(result.hasViolations).toBe(false)
})

Test Tags Copy Section

Use tags to categorize tests:

test('critical user flow @smoke @critical', async ({ page }) => {
  // Test implementation
})

Common tags:

• @smoke - Quick smoke tests for PR checks
• @critical - Critical user flows
• @visual - Visual regression tests
• @slow - Long-running tests

Configuration Copy Chapter

Test Config (e2e/config/test.config.ts) Copy Section

Central location for all test constants:

• URLs and routes
• Timeouts
• Viewport sizes
• Test data
• Performance thresholds
• Selectors

Playwright Config (playwright.config.ts) Copy Section

Playwright-specific settings:

• Browser configurations
• Test directory
• Reporter settings
• Web server settings

Best Practices Copy Chapter

1. Use Data-TestIds: Add data-testid attributes to elements for stable selectors
2. Page Object Model: Encapsulate page logic in page objects
3. Centralized Config: Keep all constants in test.config.ts
4. Reusable Utilities: Create utility functions for common operations
5. Parallel Execution: Tests run in parallel by default
6. Retry Logic: Configure retries for flaky tests
7. Screenshots: Automatically captured on failure
8. Assertions: Use Playwright's built-in assertions for auto-retry

Debugging Copy Chapter

VS Code Integration Copy Section

1. Install Playwright Test for VS Code extension
2. Click the play button next to tests to run/debug

Command Line Copy Section

# Debug mode with inspector
pnpm run e2e:debug

# Show browser (headed mode)
pnpm run e2e:headed

# Slow down execution
SLOWMO=1000 pnpm run e2e

Trace Viewer Copy Section

# Run with trace
pnpm run e2e --trace on

# View trace
pnpm exec playwright show-trace trace.zip

Reports Copy Chapter

HTML Report Copy Section

# Generate and open report
pnpm run e2e:report

GitHub Actions Copy Section

• Test results appear in PR comments
• Artifacts uploaded for failed tests
• HTML reports available as workflow artifacts

Troubleshooting Copy Chapter

Common Issues Copy Section

1. Browser not installed

   bash Copy

   pnpm run e2e:install

2. Port already in use

   • Check if dev server is running on port 3080
   • Kill existing process or use different port

3. Timeout errors

   • Increase timeout in test.config.ts
   • Check network conditions
   • Verify selectors are correct

4. Flaky tests

   • Add explicit waits
   • Use Playwright's auto-retry assertions
   • Check for race conditions

CI/CD Integration Copy Chapter

GitHub Actions Workflows Copy Section

1. e2e.yml: Dedicated E2E test workflow
2. ci.yml: Comprehensive CI including E2E
3. pr.yml: Quick checks for pull requests

Environment Variables Copy Section

Required for CI:

• CI=true
• BASE_URL (optional, defaults to localhost:3080)

Performance Testing Copy Chapter

The suite includes performance tests that check:

• Core Web Vitals (LCP, FCP, CLS)
• JavaScript bundle size
• Memory leaks
• Page load times

Run performance tests:

pnpm run e2e --grep="Performance"

Accessibility Testing Copy Chapter

Automated accessibility checks include:

• WCAG compliance
• ARIA attributes
• Keyboard navigation
• Color contrast
• Heading hierarchy

Run accessibility tests:

pnpm run e2e --grep="Accessibility"

Contributing Copy Chapter

1. Follow the existing patterns
2. Add data-testid attributes when adding new UI elements
3. Update page objects when UI changes
4. Keep tests independent and idempotent
5. Use descriptive test names
6. Add appropriate tags to new tests

File: apps/web/components.json Copy Chapter

{
"$schema": "https://ui.shadcn.com/schema.json",
"style": "new-york",
"rsc": true,
"tsx": true,
"tailwind": {
"config": "",
"css": "app/globals.css",
"baseColor": "zinc",
"cssVariables": true
},
"aliases": {
"components": "@/components",
"utils": "@repo/utils",
"ui": "@repo/design-system",
"lib": "@/lib",
"hooks": "@/hooks"
},
"iconLibrary": "lucide"
}

File: apps/web/package.json Copy Chapter

{
"name": "web",
"version": "1.0.0",
"private": true,
"type": "module",
"scripts": {
"build": "bash ../../scripts/ci/migrate-on-vercel-production.sh && pnpm --filter @repo/auth build && next build",
"build:content": "content-collections build",
"dev": "concurrently "content-collections watch" "portless run next dev"",
"e2e": "playwright test",
"e2e:debug": "playwright test --debug",
"e2e:headed": "playwright test --headed",
"e2e:install": "playwright install --with-deps",
"e2e:report": "playwright show-report",
"e2e:ui": "playwright test --ui",
"enrich-mentions": "tsx scripts/enrich-mentions.ts",
"lint": "biome check .",
"start": "next start",
"test": "jest --watchman=false --passWithNoTests",
"test:ci": "jest --watchman=false --ci --maxWorkers=1 --passWithNoTests",
"test:coverage": "jest --watchman=false --coverage --passWithNoTests",
"test:coverage:check": "jest --watchman=false --coverage --coverageReporters=text-summary --coverageReporters=json-summary --passWithNoTests",
"test:related": "jest --watchman=false --findRelatedTests --passWithNoTests",
"typecheck": "tsc --noEmit"
},
"dependencies": {
"@content-collections/core": "^0.15.3",
"@content-collections/mdx": "^0.2.2",
"@content-collections/next": "^0.2.11",
"@icons-pack/react-simple-icons": "catalog:",
"@next/third-parties": "^16.3.8",
"@openpanel/nextjs": "^1.5.1",
"@prisma/client": "catalog:",
"@radix-ui/react-accordion": "^1.2.20",
"@radix-ui/react-checkbox": "catalog:",
"@radix-ui/react-dialog": "catalog:",
"@radix-ui/react-dropdown-menu": "catalog:",
"@radix-ui/react-progress": "catalog:",
"@radix-ui/react-radio-group": "^1.4.7",
"@radix-ui/react-select": "catalog:",
"@radix-ui/react-slot": "catalog:",
"@radix-ui/react-switch": "catalog:",
"@radix-ui/react-tabs": "catalog:",
"@radix-ui/react-tooltip": "catalog:",
"@repo/auth": "workspace:",
"@repo/config": "workspace:",
"@repo/data-layer": "workspace:",
"@repo/design-system": "workspace:",
"@repo/emails": "workspace:",
"@repo/i18n": "workspace:",
"@repo/mcp": "workspace:",
"@repo/rule-feedback": "workspace:",
"@repo/schemas": "workspace:",
"@repo/search": "workspace:",
"@repo/seo": "workspace:",
"@repo/state": "workspace:",
"@repo/storage": "workspace:",
"@repo/types": "workspace:",
"@repo/utils": "workspace:",
"@repo/virtualization": "workspace:",
"@sentry/nextjs": "^11.4.0",
"@tanstack/react-form": "^1.33.5",
"@tanstack/react-query": "catalog:",
"@tanstack/react-query-devtools": "^5.104.1",
"@thedaviddias/analytics": "workspace:*",
"@upstash/ratelimit": "^2.2.0",
"@upstash/redis": "^1.39.0",
"better-auth": "^1.7.7",
"botid": "^1.5.11",
"class-variance-authority": "catalog:",
"cmdk": "^1.1.1",
"focus-trap-react": "^12.0.3",
"framer-motion": "catalog:",
"fuse.js": "^7.5.0",
"lru-cache": "^11.5.3",
"next": "catalog:",
"next-safe-action": "^8.7.3",
"next-themes": "^0.4.6",
"nuqs": "^2.10.1",
"open-graph-scraper": "^6.12.0",
"react": "catalog:",
"react-dom": "catalog:",
"rehype-autolink-headings": "^7.1.0",
"rehype-pretty-code": "^0.14.5",
"rehype-slug": "^6.0.0",
"remark-gfm": "^4.0.1",
"shiki": "^4.5.0",
"tailwind-merge": "catalog:",
"zod": "catalog:"
},
"devDependencies": {
"@axe-core/react": "^4.13.0",
"@content-collections/cli": "^0.1.9",
"@playwright/test": "^1.63.0",
"@repo/config-typescript": "workspace:^",
"@tailwindcss/postcss": "^4.3.3",
"@testing-library/jest-dom": "^7.0.1",
"@testing-library/react": "catalog:",
"@testing-library/user-event": "^14.6.7",
"@types/jest": "catalog:",
"@types/node": "catalog:",
"@types/react": "catalog:",
"@types/react-dom": "catalog:",
"concurrently": "^10.0.5",
"eslint-plugin-jsx-a11y": "^6.10.2",
"jest": "catalog:",
"jest-environment-jsdom": "^30.5.2",
"tailwindcss": "^4.3.3",
"typescript": "catalog:"
}
}

File: apps/web/TESTING-STRATEGY.md Copy Chapter

Testing Strategy & Coverage Guidelines

Coverage Thresholds Copy Chapter

Based on industry best practices from Google, Microsoft, and other leading tech companies, we enforce the following coverage thresholds:

Global Coverage Requirements Copy Section

• Statements: 80% (Industry standard)
• Lines: 80% (Industry standard)
• Functions: 80% (Industry standard)
• Branches: 70% (Pragmatic target for conditional logic)

Tiered Coverage by Code Type Copy Section

Critical Utilities (`/utils/`)

• Target: 90% all metrics
• Rationale: Utility functions are reused across the application and should be thoroughly tested

UI Components (`/components/`)

• Target: 80% statements/lines/functions, 70% branches
• Rationale: Standard coverage for UI components, acknowledging that some edge cases may be less critical

Application Pages (`/app/`)

• Target: 80% overall
• Rationale: Focus on user journeys and integration rather than 100% unit coverage

Best Practices Copy Chapter

1. Focus on Critical Paths Copy Section

• Prioritize testing business-critical functionality
• Ensure error handling paths are covered
• Test data validation and security boundaries

2. Quality Over Quantity Copy Section

• Write meaningful tests that validate behavior, not just increase coverage
• One good integration test can be worth multiple unit tests
• Focus on what's NOT covered rather than the percentage

3. Progressive Coverage Goals Copy Section

Different testing levels should have different targets:

• Unit Tests: 80-90% coverage
• Integration Tests: 70-80% coverage
• E2E Tests: Focus on critical user journeys (50-60%)

4. When to Exclude Files from Coverage Copy Section

Acceptable exclusions:

• Generated files
• Configuration files
• Type definitions (.d.ts)
• Test utilities and mocks
• Boilerplate code with no logic

5. Incremental Improvement Copy Section

For existing code with low coverage:

• Set realistic incremental goals
• Use tools to prevent coverage regression
• Focus on new code having proper coverage

Running Tests Copy Chapter

# Development (watch mode)
pnpm test

# Run with coverage report
pnpm test:coverage

# CI mode (no watch, with coverage)
pnpm test:ci

# Run specific test file
pnpm test Counter.test.tsx

Coverage Reports Copy Chapter

Coverage reports are generated in multiple formats:

• Terminal: Immediate feedback during development
• HTML: Detailed browseable report in coverage/lcov-report/index.html
• LCOV: For CI/CD integration

Enforcement Copy Chapter

Coverage thresholds are enforced at multiple levels:

1. Local Development: Jest fails if coverage drops below thresholds
2. Pre-commit Hook: Checks coverage on staged files
3. Pre-push Hook: Runs full test suite with coverage
4. CI/CD Pipeline: Blocks merge if coverage requirements not met

Why These Thresholds? Copy Chapter

Based on empirical studies and industry experience:

• 80% coverage provides good confidence in code correctness
• 70% branch coverage is pragmatic for complex conditionals
• Coverage above 80-90% has diminishing returns
• Time spent going from 80% to 100% is better invested in integration/E2E tests

Red Flags Copy Chapter

Be concerned if you see:

• Coverage below 60% on any metric
• Critical business logic with low coverage
• Error handling paths not tested
• No tests for data validation
• Security-related code without tests

Resources Copy Chapter

• Google Testing Blog - Code Coverage Best Practices
• Jest Documentation - Coverage Configuration
• Testing Library Best Practices

Remember Copy Chapter

"The goal is not 100% coverage. The goal is confidence in your code's correctness and maintainability."

Coverage is a tool, not a goal. Use it wisely to build reliable, maintainable software.

File: apps/web/tsconfig.json Copy Chapter

{
"extends": "@repo/config-typescript/nextjs.json",
"compilerOptions": {
"incremental": true,
"baseUrl": ".",
"paths": {
"@/": ["./"],
"@/components/": ["./components/"],
"@/app/": ["./app/"],
"@/utils/": ["./utils/"],
"@/test-utils": ["./test-utils/index.tsx"],
"@/e2e/": ["./e2e/"],
"content-collections": ["./.content-collections/generated"],
"@repo/": ["../../packages//src"],
"@repo/auth": ["../../packages/auth/src/auth.ts"],
"@repo/auth/": ["../../packages/auth/src/"],
"@repo/emails": ["../../packages/emails/src/index.ts"],
"@repo/emails/server": ["../../packages/emails/src/server.ts"]
}
},
"include": [
"next-env.d.ts",
"/*.ts",
"/.tsx",
".next/types/**/.ts",
".content-collections/generated//*.ts"
],
"exclude": [
"node_modules",
"test-utils",
"/.test.ts",
"**/.test.tsx",
"/*.spec.ts",
"/*.spec.tsx"
]
}

File: apps/web/vercel.json Copy Chapter

{
"$schema": "https://openapi.vercel.sh/vercel.json",
"git": { "deploymentEnabled": false },
"crons": [
{
"path": "/api/cron/supabase-keepalive",
"schedule": "0 6 * * "
}
],
"rewrites": [
{
"source": "/:path",
"has": [
{
"type": "host",
"value": "mcp.frontendchecklist.io"
}
],
"destination": "/api/mcp"
}
]
}

File: apps/web/.lighthouserc.json Copy Chapter

{
"ci": {
"collect": {
"url": ["http://localhost:3080/"],
"startServerCommand": "pnpm --filter web exec next start --port 3080",
"startServerReadyPattern": "Ready",
"numberOfRuns": 3,
"settings": {
"preset": "desktop",
"throttling": {
"cpuSlowdownMultiplier": 1
}
}
},
"assert": {
"preset": "lighthouse:recommended",
"assertions": {
"categories:performance": ["error", { "minScore": 0.9 }],
"categories:accessibility": ["error", { "minScore": 0.9 }],
"categories:best-practices": ["error", { "minScore": 0.9 }],
"categories:seo": ["error", { "minScore": 0.9 }],
"first-contentful-paint": ["error", { "maxNumericValue": 1800 }],
"largest-contentful-paint": ["error", { "maxNumericValue": 2500 }],
"cumulative-layout-shift": ["error", { "maxNumericValue": 0.1 }],
"total-blocking-time": ["error", { "maxNumericValue": 300 }],
"speed-index": ["error", { "maxNumericValue": 3000 }],
"interactive": ["error", { "maxNumericValue": 3500 }],
"max-potential-fid": ["error", { "maxNumericValue": 130 }],
"uses-responsive-images": "warn",
"uses-optimized-images": "warn",
"uses-webp-images": "warn",
"uses-text-compression": "warn",
"uses-rel-preconnect": "warn",
"unused-javascript": "warn"
}
},
"upload": {
"target": "temporary-public-storage"
}
}
}

File: apps/web/data/mentions-input.json Copy Chapter

{
"mentions": [
{
"type": "article",
"url": "https://css-tricks.com/front-end-checklist-just-tool-everything-depends/",
"featured": true
},
{
"type": "article",
"url": "https://www.noupe.com/magazine/design/perfect-for-web-developers-the-front-end-checklist-ensures-code-quality.html",
"featured": true
},
{
"type": "article",
"url": "https://css-tricks.com/front-end-performance-checklist/",
"featured": true
},
{
"type": "article",
"url": "https://codeburst.io/the-front-end-checklist-app-a1faa882cad6"
},
{
"type": "tweet",
"url": "https://x.com/madzadev/status/1873297404390408372?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/guillaume_rygn/status/1862044944036135221?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/Manz/status/1678348970438041600?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/guillaume_rygn/status/1630132469264424960?s=20"
},
{
"type": "tweet",
"url": "https://x.com/donwolfonline/status/1626912814391607298?s=20"
},
{
"type": "tweet",
"url": "https://x.com/mrdavediamond/status/1549207668652638210?s=20"
},
{
"type": "tweet",
"url": "https://x.com/Sumukhmg/status/1526434885283418112?s=20"
},
{
"type": "tweet",
"url": "https://x.com/ishrratumar/status/1520752430245240832?s=20"
},
{
"type": "tweet",
"url": "https://x.com/code_rams/status/1515253474165932034?s=20"
},
{
"type": "tweet",
"url": "https://x.com/devatTheCave/status/1441398475824893952?s=20"
},
{
"type": "tweet",
"url": "https://x.com/grandemayta/status/1196432555408576513?s=20"
},
{
"type": "tweet",
"url": "https://x.com/_DZGND/status/1186687665351073792?s=20"
},
{
"type": "tweet",
"url": "https://x.com/codepo8/status/1046844559781715968?s=20"
},
{
"type": "tweet",
"url": "https://x.com/codepo8/status/997740512806408192?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/hdjirdeh/status/1162450424244236288?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/1030437747104854017?s=20"
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/1022166928444612608?s=20"
},
{
"type": "article",
"url": "https://levelup.gitconnected.com/3-essential-front-end-checklists-for-web-developers-d873b226b1f0",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/Astro_Deja/status/981549240626417665?s=20"
},
{
"type": "tweet",
"url": "https://x.com/1stwebdesigner/status/979085960146227201?s=20"
},
{
"type": "tweet",
"url": "https://x.com/forwebdev/status/976777682548649986?s=20"
},
{
"type": "tweet",
"url": "https://x.com/speckyboy/status/975824505204609025?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/SoyJuanMacias/status/974736513266339840?s=20"
},
{
"type": "tweet",
"url": "https://x.com/qudusdev/status/949679725689167872?s=20"
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/943023612549726208?s=20"
},
{
"type": "tweet",
"url": "https://x.com/440UrPp/status/937815946089107456?s=20"
},
{
"type": "tweet",
"url": "https://x.com/disco_lu/status/934247068146679808?s=20"
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/932653865140232192?s=20"
},
{
"type": "tweet",
"url": "https://x.com/KrasimirTsonev/status/925581418541002752?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/923918497918287873?s=20"
},
{
"type": "tweet",
"url": "https://x.com/housecor/status/923754949556785153?s=20",
"featured": true
},
{
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/923603765768347648?s=20"
},
{
"type": "article",
"url": "https://www.sitepoint.com/web-development-checklists/"
}
]
}

File: apps/web/data/mentions.json Copy Chapter

{
"_generated": "DO NOT EDIT - Generated from mentions-input.json via 'pnpm enrich-mentions'",
"mentions": [
{
"id": "645b5836",
"type": "article",
"url": "https://codeburst.io/the-front-end-checklist-app-a1faa882cad6",
"date": "2026-05-29",
"featured": false,
"title": "",
"source": "codeburst.io"
},
{
"id": "da6e6d73",
"type": "article",
"url": "https://www.sitepoint.com/web-development-checklists/",
"date": "2026-05-29",
"featured": false,
"title": "",
"source": "sitepoint.com"
},
{
"id": "80a12b14",
"type": "tweet",
"url": "https://x.com/madzadev/status/1873297404390408372?s=20",
"date": "2024-12-29",
"featured": true,
"tweetId": "1873297404390408372",
"author": "Madza 👨‍💻⚡",
"authorUrl": "https://x.com/madzadev",
"avatarUrl": "https://pbs.twimg.com/profile_images/1526471322762715136/w25QtNnl_normal.jpg",
"handle": "madzadev",
"content": "Here are some good tips not only for performance but also for good practices in general: https://t.co/2FHleW7sHE",
"likes": 1
},
{
"id": "820785d6",
"type": "tweet",
"url": "https://x.com/guillaume_rygn/status/1862044944036135221?s=20",
"date": "2024-11-28",
"featured": true,
"tweetId": "1862044944036135221",
"author": "code w/Guillaume 💻",
"authorUrl": "https://x.com/guillaume_rygn",
"avatarUrl": "https://pbs.twimg.com/profile_images/1483519295288233991/9igtPNRr_normal.jpg",
"handle": "guillaume_rygn",
"content": "J'ai trouvé un site qui recense toutes les bonnes pratiques à avoir sur son site sous forme de Checklist✅\n\nÇa s'appelle https://t.co/wGx6qHxyDd ! c'est pratique pour ne rien oublier (performances, SEO, images etc)\nJe fais toujours un check de cette liste avant de lancer un… pic.twitter.com/hL35ziltTL",
"mediaUrl": "https://pbs.twimg.com/media/GddP_cdXYAA0DK9.jpg",
"likes": 223
},
{
"id": "0cd85b83",
"type": "tweet",
"url": "https://x.com/Manz/status/1678348970438041600?s=20",
"date": "2023-07-10",
"featured": true,
"tweetId": "1678348970438041600",
"author": "Manz 🇮🇨⚡👾",
"authorUrl": "https://x.com/Manz",
"avatarUrl": "https://pbs.twimg.com/profile_images/1386378668717613060/Ghr2DQuO_normal.jpg",
"handle": "Manz",
"content": "⚡Mis otras redes: https://t.co/YGtxSUGe4S\n➡ Frontend Checklist: https://t.co/T4L9iAKZkv\n🎬 Buenas prácticas (1): https://t.co/IzhOvwoOJQ",
"likes": 2
},
{
"id": "df52a663",
"type": "tweet",
"url": "https://x.com/guillaume_rygn/status/1630132469264424960?s=20",
"date": "2023-02-27",
"featured": false,
"tweetId": "1630132469264424960",
"author": "code w/Guillaume 💻",
"authorUrl": "https://x.com/guillaume_rygn",
"avatarUrl": "https://pbs.twimg.com/profile_images/1483519295288233991/9igtPNRr_normal.jpg",
"handle": "guillaume_rygn",
"content": "J'ai trouvé un site qui recense toutes les bonnes pratiques à avoir sur son site sous forme de Checklist✅\n\nÇa s'appelle https://t.co/wGx6qHxyDd! c'est pratique pour ne rien oublier (performances, SEO, images etc)\nJe fais toujours un check de cette liste avant de lancer un site👀 pic.twitter.com/RUmLjGz9Qe",
"mediaUrl": "https://pbs.twimg.com/media/Fp9k16PXsAQx_PD.jpg",
"likes": 468
},
{
"id": "5b17b97a",
"type": "tweet",
"url": "https://x.com/donwolfonline/status/1626912814391607298?s=20",
"date": "2023-02-18",
"featured": false,
"tweetId": "1626912814391607298",
"author": "Frederick Dineen",
"authorUrl": "https://x.com/donwolfonline",
"avatarUrl": "https://pbs.twimg.com/profile_images/1966594105674174464/Ejnic0CW_normal.jpg",
"handle": "donwolfonline",
"content": "📌 A very awesome website for Front-End developers 👌😍\nIt gives you a list of the things you need to adjust when making a new design with HTML / CSS / JAVASCRIPT and even SEO ✅\nTasks are divided according to importancehttps://t.co/JzjzWZIk5d",
"likes": 0
},
{
"id": "a2cc909d",
"type": "tweet",
"url": "https://x.com/mrdavediamond/status/1549207668652638210?s=20",
"date": "2022-07-19",
"featured": false,
"tweetId": "1549207668652638210",
"author": "Dave Diamond",
"authorUrl": "https://x.com/mrdavediamond",
"avatarUrl": "https://pbs.twimg.com/profile_images/1628243766841868288/V5gFatf4_normal.jpg",
"handle": "mrdavediamond",
"content": "Killer 📑 #checklist from @TheDavidDias!\n\nSuper helpful if you're web designer, #startup founder, and compulsory if you're a #FrontEndDeveloper.\n\nCheck this >> https://t.co/5pOsUuL8wk 👀\n\n #SeoTools #Web3 #design",
"likes": 1
},
{
"id": "4f5d3320",
"type": "tweet",
"url": "https://x.com/Sumukhmg/status/1526434885283418112?s=20",
"date": "2022-05-17",
"featured": false,
"tweetId": "1526434885283418112",
"author": "Sumukh",
"authorUrl": "https://x.com/Sumukhmg",
"avatarUrl": "https://pbs.twimg.com/profile_images/1832443952600887296/HEDtuy9C_normal.jpg",
"handle": "Sumukhmg",
"content": "⑤ Frontend checklist: The Front-End Checklist is an exhaustive list of all elements you need to have / to test before launching your website / HTML page to production.\n🔗 https://t.co/DmmGMvrWyF pic.twitter.com/vv5yMt5htG",
"mediaUrl": "https://pbs.twimg.com/media/FS78b7MUsAAinfw.jpg",
"likes": 3
},
{
"id": "4e1d634e",
"type": "tweet",
"url": "https://x.com/ishrratumar/status/1520752430245240832?s=20",
"date": "2022-05-01",
"featured": false,
"tweetId": "1520752430245240832",
"author": "Ishrat",
"authorUrl": "https://x.com/ishrratumar",
"avatarUrl": "https://pbs.twimg.com/profile_images/1503799335292743687/zUfzmZA8_normal.jpg",
"handle": "ishrratumar",
"content": "3. Front-End Checklist\n\n✍️ The Front-End Checklist is a detailed list of all you need to test before publishing your site.https://t.co/iJIESy92b3 pic.twitter.com/nK6vxDVKUI",
"mediaUrl": "https://pbs.twimg.com/media/FRrMRgKUYAAgT3l.jpg",
"likes": 10
},
{
"id": "df75080f",
"type": "tweet",
"url": "https://x.com/code_rams/status/1515253474165932034?s=20",
"date": "2022-04-16",
"featured": false,
"tweetId": "1515253474165932034",
"author": "Ramya Chinnadurai 🚀",
"authorUrl": "https://x.com/code_rams",
"avatarUrl": "https://pbs.twimg.com/profile_images/1491644590583345152/0_qYmn9E_normal.jpg",
"handle": "code_rams",
"content": "8. The front-end checklist\n\nThe Complete checklist for particularly perfect for modern websites and meticulous developers!https://t.co/gmQ7GkcxzN pic.twitter.com/BW6FWaWjLT",
"mediaUrl": "https://pbs.twimg.com/ext_tw_video_thumb/1515251863729459203/pu/img/1hyWWe0HVAgzae3W.jpg",
"likes": 49
},
{
"id": "65b7feb8",
"type": "tweet",
"url": "https://x.com/devatTheCave/status/1441398475824893952?s=20",
"date": "2021-09-24",
"featured": false,
"tweetId": "1441398475824893952",
"author": "Mahmood Tareq",
"authorUrl": "https://x.com/devatTheCave",
"avatarUrl": "https://pbs.twimg.com/profile_images/1784715641515130880/d7-QYWLz_normal.jpg",
"handle": "devatTheCave",
"content": "3- The front-end checklist\n\nThis is the website was the reason I made this list\n\nIt allows you to learn and follow the rules when it comes to front-end web development\n\nIt tells you the best practices you should use for building a websitehttps://t.co/pfB2W8QbY3 pic.twitter.com/ohClvvoYDE",
"mediaUrl": "https://pbs.twimg.com/media/FADgFTMX0AA-3q7.jpg",
"likes": 63
},
{
"id": "4ea365bb",
"type": "tweet",
"url": "https://x.com/grandemayta/status/1196432555408576513?s=20",
"date": "2019-11-18",
"featured": false,
"tweetId": "1196432555408576513",
"author": "Gabriel Mayta",
"authorUrl": "https://x.com/grandemayta",
"avatarUrl": "https://pbs.twimg.com/profile_images/1422842448267653122/RyKFEelV_normal.jpg",
"handle": "grandemayta",
"content": "Are you new in the Frontend world?\nHere you can find three useful links about:\n\n🗂Guidelines -> https://t.co/v1pku1sOhL\n💎Design -> https://t.co/IEnEDmqE8p\n🎮Performance -> https://t.co/WeJq77EdYY\nBonus:\n👍Live Checklist -> https://t.co/P2kjUo1L0G#frontend #webdevelopment",
"likes": 1
},
{
"id": "ee3f6e51",
"type": "tweet",
"url": "https://x.com/_DZGND/status/1186687665351073792?s=20",
"date": "2019-10-22",
"featured": false,
"tweetId": "1186687665351073792",
"author": "Dareth NHANG",
"authorUrl": "https://x.com/_DZGND",
"avatarUrl": "https://pbs.twimg.com/profile_images/1879907154808778752/P-36bbNT_normal.jpg",
"handle": "_DZGND",
"content": "Pour nous, les #dev (#front)… Mais aussi pour #LesClients ou les personnes qui pensent que développer un site internet, c'est juste quelques clics… https://t.co/WTElZfEotP\n\nEt je ne vous parle pas du #back, de la #sécurité, de la gestion des serveurs, etc. !!! pic.twitter.com/LqpWtpNjoa",
"mediaUrl": "https://pbs.twimg.com/media/EHf2JIiXUAETqMS.jpg",
"likes": 2
},
{
"id": "b5105424",
"type": "tweet",
"url": "https://x.com/hdjirdeh/status/1162450424244236288?s=20",
"date": "2019-08-16",
"featured": true,
"tweetId": "1162450424244236288",
"author": "Houssein Djirdeh",
"authorUrl": "https://x.com/hdjirdeh",
"avatarUrl": "https://pbs.twimg.com/profile_images/1460651862340915201/w8Zva6LO_normal.jpg",
"handle": "hdjirdeh",
"content": "David is super passionate about everything he works on and was solely responsible for building https://t.co/8UEvCMDb3A\n\nFor any Toronto folks who follow me looking to hire, reach out to him! https://t.co/TRaDm0FTYl",
"likes": 9
},
{
"id": "14eaba8b",
"type": "tweet",
"url": "https://x.com/codepo8/status/1046844559781715968?s=20",
"date": "2018-10-01",
"featured": false,
"tweetId": "1046844559781715968",
"author": "Chris Heilmann codepo8.bsky.social",
"authorUrl": "https://x.com/codepo8",
"avatarUrl": "https://pbs.twimg.com/profile_images/1969442465976336384/jeDfC3x9_normal.jpg",
"handle": "codepo8",
"content": "Fun to meet @thedaviddias of frontend checklist fame. #WEBU18 https://t.co/Ggh5mSsFgM give him thanks when you meet him. Curating something like this looks easy but is a hell of a job",
"likes": 25
},
{
"id": "52898468",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/1030437747104854017?s=20",
"date": "2018-08-17",
"featured": false,
"tweetId": "1030437747104854017",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "Thanks @ResWebDes for mentioning the Front-End Performance Checklist in your last newsletter #322! #FrontEndChecklist #FrontEndFriday #FrontEnd #Checklist #thank you pic.twitter.com/gbVrx6B1Fk",
"mediaUrl": "https://pbs.twimg.com/media/DkzZev7UYAUgvNF.jpg",
"likes": 3
},
{
"id": "06e9283f",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/1022166928444612608?s=20",
"date": "2018-07-25",
"featured": false,
"tweetId": "1022166928444612608",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "The Front-End Performance Checklist is listed on JavaScript Weekly Newsletter! 😱 😍 😇 https://t.co/eJspXW1iMC #javascript #FrontEndChecklist #newsletter #trending pic.twitter.com/qYmcp51KyH",
"mediaUrl": "https://pbs.twimg.com/media/Di93ZtYWwAE5MPj.jpg",
"likes": 3
},
{
"id": "5ab4e4b1",
"type": "article",
"url": "https://levelup.gitconnected.com/3-essential-front-end-checklists-for-web-developers-d873b226b1f0",
"date": "2018-07-24",
"featured": true,
"title": "3 Essential Front-End Checklists for Web Developers",
"source": "Medium",
"author": "David Dias",
"excerpt": "Ensure your web applications are air tight and high quality with these open source checklists covering engineering, design, and performance",
"ogImage": "https://miro.medium.com/v2/resize:fit:1200/1*wAs_2vEPznyXz49izdZNwg.jpeg",
"favicon": "https://levelup.gitconnected.com/favicon.ico"
},
{
"id": "ef2849b4",
"type": "tweet",
"url": "https://x.com/codepo8/status/997740512806408192?s=20",
"date": "2018-05-19",
"featured": true,
"tweetId": "997740512806408192",
"author": "Chris Heilmann codepo8.bsky.social",
"authorUrl": "https://x.com/codepo8",
"avatarUrl": "https://pbs.twimg.com/profile_images/1969442465976336384/jeDfC3x9_normal.jpg",
"handle": "codepo8",
"content": "Check the 🔥 Front-End Checklist Application 🔥 for modern websites and meticulous developers! With more than 20 000 🌟 on #Github, now you can use it on your daily workflow and generate reports 📑! https://t.co/IV6fcMePix #FrontEndChecklist #FrontEnd #Tool #Web via @thedaviddias",
"mediaUrl": "https://pbs.twimg.com/card_img/2060282638141632517/vwydf3bQ?format=jpg&name=800x419",
"likes": 403
},
{
"id": "a19e9d4c",
"type": "tweet",
"url": "https://x.com/Astro_Deja/status/981549240626417665?s=20",
"date": "2018-04-04",
"featured": false,
"tweetId": "981549240626417665",
"author": ";",
"authorUrl": "https://x.com/Astro_Deja",
"avatarUrl": "https://pbs.twimg.com/profile_images/1210275549568028682/TGXaoqd-_normal.jpg",
"handle": "Astro_Deja",
"content": "#100DaysOfCode #CodeNewbie\n\nLook what I found on @github 🙌🏿😵🙌🏿 Will be using the #FrontEndChecklist from now on!!! The only checklist you will ever need as a #FrontEnd #WebDev\n\nThanks, @thedaviddias !!!https://t.co/TlzbcM8syG",
"likes": 17
},
{
"id": "78602c2c",
"type": "tweet",
"url": "https://x.com/1stwebdesigner/status/979085960146227201?s=20",
"date": "2018-03-28",
"featured": false,
"tweetId": "979085960146227201",
"author": "1stWebDesigner",
"authorUrl": "https://x.com/1stwebdesigner",
"avatarUrl": "https://pbs.twimg.com/profile_images/1220368801113440256/z9ZkPaGb_normal.jpg",
"handle": "1stwebdesigner",
"content": "The Front-End Checklist https://t.co/J8mEgg4zwe pic.twitter.com/5Pj5YLbx8i",
"mediaUrl": "https://pbs.twimg.com/media/DZZpfcSUMAEcjyZ.jpg",
"likes": 38
},
{
"id": "8e08643c",
"type": "tweet",
"url": "https://x.com/forwebdev/status/976777682548649986?s=20",
"date": "2018-03-22",
"featured": false,
"tweetId": "976777682548649986",
"author": "For Web 🇺🇦",
"authorUrl": "https://x.com/forwebdev",
"avatarUrl": "https://pbs.twimg.com/profile_images/1643693635475521536/tp_nbsHs_normal.jpg",
"handle": "forwebdev",
"content": "The Front-End Checklist\n\nОбъёмный чеклист и рекомендации для проверки всех аспектов фронтенда сайта, от разметки и доступности до производительности.\n\nТеперь и в виде удобного сайта с возможностью печати → https://t.co/vKaYAr2AJP pic.twitter.com/8CYUztjemR",
"mediaUrl": "https://pbs.twimg.com/media/DY42H7EWsAA7kMf.jpg",
"likes": 50
},
{
"id": "c952930a",
"type": "tweet",
"url": "https://x.com/speckyboy/status/975824505204609025?s=20",
"date": "2018-03-19",
"featured": true,
"tweetId": "975824505204609025",
"author": "Speckyboy",
"authorUrl": "https://x.com/speckyboy",
"avatarUrl": "https://pbs.twimg.com/profile_images/1833187020996333568/WrW1WadX_normal.png",
"handle": "speckyboy",
"content": "The Front-End Checklist https://t.co/EKgCry8eLk pic.twitter.com/dfnUDrclwI",
"mediaUrl": "https://pbs.twimg.com/media/DYrTNyWXUAE6U9f.jpg",
"likes": 92
},
{
"id": "569ad69f",
"type": "tweet",
"url": "https://x.com/SoyJuanMacias/status/974736513266339840?s=20",
"date": "2018-03-16",
"featured": false,
"tweetId": "974736513266339840",
"author": "Juan Macias",
"authorUrl": "https://x.com/SoyJuanMacias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1612607291366297600/ugafEXtT_normal.jpg",
"handle": "SoyJuanMacias",
"content": "@thedaviddias Teaching us how to start an Open-Source project and his awesome tool https://t.co/g1QWcoqobr. One of the best meetup I’ve been! Thanks @thedaviddias for all and @IronhackMAD for give us your space! pic.twitter.com/Hyd4UD8aqL",
"mediaUrl": "https://pbs.twimg.com/media/DYb1rxDWAAAf3XP.jpg",
"likes": 1
},
{
"id": "d666f531",
"type": "tweet",
"url": "https://x.com/qudusdev/status/949679725689167872?s=20",
"date": "2018-01-06",
"featured": false,
"tweetId": "949679725689167872",
"author": "Qudus",
"authorUrl": "https://x.com/qudusdev",
"avatarUrl": "https://pbs.twimg.com/profile_images/793780072561934336/IuuT2K9U_normal.jpg",
"handle": "qudusdev",
"content": "Wowhttps://t.co/qROdcFwWHa",
"likes": 0
},
{
"id": "24980364",
"type": "article",
"url": "https://css-tricks.com/front-end-performance-checklist/",
"date": "2018-01-04",
"featured": true,
"title": "Front-End Performance Checklist | CSS-Tricks",
"source": "CSS-Tricks",
"excerpt": "Vitaly Friedman swings wide with a massive list of performance considerations. It's a well-considered mix of old tactics (cutting the mustard, progressive",
"ogImage": "https://i0.wp.com/css-tricks.com/wp-content/uploads/2021/12/default-social-css-tricks.png",
"favicon": "https://css-tricks.com/favicon.ico"
},
{
"id": "6209f678",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/943023612549726208?s=20",
"date": "2017-12-19",
"featured": false,
"tweetId": "943023612549726208",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "Hey @twilio, thanks for sharing the #FrontEndChecklist in your last Twilio developer digest! As you can see, I always read your newsletter 😅😂 #opensource #frontend #twilio pic.twitter.com/3T0dTdGNaV",
"mediaUrl": "https://pbs.twimg.com/media/DRZK9-hXUAATykw.jpg",
"likes": 10
},
{
"id": "15054d52",
"type": "article",
"url": "https://www.noupe.com/magazine/design/perfect-for-web-developers-the-front-end-checklist-ensures-code-quality.html",
"date": "2017-12-13",
"featured": true,
"title": "Perfect for Web Developers: The Front-End Checklist Ensures Code Quality | NOUPE",
"source": "noupe",
"author": "Noupe Editorial Team",
"excerpt": "Following checklists is proven to help improve the quality of what the checklist was designed for. This front-end checklist is dedicated to web development",
"ogImage": "https://www.noupe.com/wp-content/uploads/2017/12/checklist-2589418_1280.jpg",
"favicon": "https://www.noupe.com/favicon.ico"
},
{
"id": "b33f554a",
"type": "tweet",
"url": "https://x.com/440UrPp/status/937815946089107456?s=20",
"date": "2017-12-04",
"featured": false,
"tweetId": "937815946089107456",
"author": "[email protected]",
"authorUrl": "https://x.com/440UrPp",
"avatarUrl": "https://pbs.twimg.com/profile_images/1978138753722937344/bU8MtkM2_normal.jpg",
"handle": "440UrPp",
"content": "I went through my first front end check list test on https://t.co/rm5BvM3eAB and I have to say my web dev sucks! So many points were lost to very straight forward things. I got an E for the site I'm currently on.\n\nNow imma need to go update all the websites I've ever worked on. pic.twitter.com/J5u4pBLEyI",
"mediaUrl": "https://pbs.twimg.com/tweet_video_thumb/DQPKeWKXcAEoDuN.jpg",
"likes": 0
},
{
"id": "07d534f1",
"type": "article",
"url": "https://css-tricks.com/front-end-checklist-just-tool-everything-depends/",
"date": "2017-11-30",
"featured": true,
"title": "The Front-End Checklist is just a tool... everything depends on you. | CSS-Tricks",
"source": "CSS-Tricks",
"excerpt": "One month ago, I launched the Front-End Checklist on GitHub. In less than 2 weeks, more than 10,000 people around the world starred the repository. That was",
"ogImage": "https://i0.wp.com/css-tricks.com/wp-content/uploads/2017/11/image2.jpg",
"favicon": "https://css-tricks.com/favicon.ico"
},
{
"id": "80c929ce",
"type": "tweet",
"url": "https://x.com/disco_lu/status/934247068146679808?s=20",
"date": "2017-11-25",
"featured": false,
"tweetId": "934247068146679808",
"author": "luis.",
"authorUrl": "https://x.com/disco_lu",
"avatarUrl": "https://pbs.twimg.com/profile_images/2046287739038138368/VDIwR0e2_normal.jpg",
"handle": "disco_lu",
"content": "This frontend checklist from @thedaviddias looks special. https://t.co/WsQVmlZK1M pic.twitter.com/BRKsbM8DrO",
"mediaUrl": "https://pbs.twimg.com/media/DPccwSuUQAA1OAu.jpg",
"likes": 1
},
{
"id": "0cca0ae1",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/932653865140232192?s=20",
"date": "2017-11-20",
"featured": false,
"tweetId": "932653865140232192",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "A 🙌 HUGE thanks to @KeyCDN who sponsored the #FrontEndChecklist! #thankyou #youarethebest #cdn pic.twitter.com/Qi2QmwYAP3",
"mediaUrl": "https://pbs.twimg.com/tweet_video_thumb/DPFzkesXcAEWK1C.jpg",
"likes": 4
},
{
"id": "8a95d3ff",
"type": "tweet",
"url": "https://x.com/KrasimirTsonev/status/925581418541002752?s=20",
"date": "2017-11-01",
"featured": true,
"tweetId": "925581418541002752",
"author": "Krasimir",
"authorUrl": "https://x.com/KrasimirTsonev",
"avatarUrl": "https://pbs.twimg.com/profile_images/1324953787275091974/EW2-Fv9f_normal.jpg",
"handle": "KrasimirTsonev",
"content": "If you are a front-end developer make sure that you check this page https://t.co/oDJF7PYrsA Front-End Checklist #fe #javascript",
"likes": 15
},
{
"id": "fdacbb8f",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/923918497918287873?s=20",
"date": "2017-10-27",
"featured": false,
"tweetId": "923918497918287873",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "🔥The #frontendchecklist is above 10 000 stars in less 2 weeks! 😱😱😲 @github #FridayFeeling #sucess #github #frontend #cantbelieve pic.twitter.com/qqZtGGDfZL",
"mediaUrl": "https://pbs.twimg.com/media/DNJq95pW0AAKtTK.jpg",
"likes": 7
},
{
"id": "882d0af4",
"type": "tweet",
"url": "https://x.com/housecor/status/923754949556785153?s=20",
"date": "2017-10-27",
"featured": true,
"tweetId": "923754949556785153",
"author": "Cory House",
"authorUrl": "https://x.com/housecor",
"avatarUrl": "https://pbs.twimg.com/profile_images/1963593369306750976/7gPWqEa8_normal.jpg",
"handle": "housecor",
"content": "Hey David, that list is epic! I have a tweet scheduled for tomorrow on it. Thanks for the feedback, and thank for sharing the list!",
"likes": 1
},
{
"id": "17b75250",
"type": "tweet",
"url": "https://x.com/TheDavidDias/status/923603765768347648?s=20",
"date": "2017-10-26",
"featured": false,
"tweetId": "923603765768347648",
"author": "David Dias",
"authorUrl": "https://x.com/TheDavidDias",
"avatarUrl": "https://pbs.twimg.com/profile_images/1948133704238260225/xRTA829j_normal.jpg",
"handle": "TheDavidDias",
"content": "The #frontendchecklist is trending on @TrendingGithub @github this week till today! Don't know how to thank the community for such support! pic.twitter.com/BNB6ai3XNE",
"mediaUrl": "https://pbs.twimg.com/media/DNFMrcPW0AQ-99F.jpg",
"likes": 3
}
]
}

File: apps/web/data/sponsors-fallback.json Copy Chapter

{
"_comment": "Optional fallback when GitHub/Open Collective APIs return no sponsors. Add entries to show sponsors in dev or when APIs are unavailable.",
"sponsors": []
}

File: configs/config-next/package.json Copy Chapter

{
"name": "@repo/config-next",
"version": "1.0.0",
"private": true,
"main": "./index.ts",
"types": "./index.ts",
"scripts": {
"clean": "rm -rf .turbo node_modules",
"lint": "biome check .",
"typecheck": "tsc --noEmit --emitDeclarationOnly false"
},
"dependencies": {
"@next/bundle-analyzer": "^16.3.8",
"@t3-oss/env-core": "^0.13.11",
"@t3-oss/env-nextjs": "^0.13.11",
"zod": "catalog:"
},
"devDependencies": {
"@repo/config-typescript": "workspace:*",
"@types/node": "catalog:",
"next": "catalog:",
"typescript": "catalog:"
}
}

File: configs/config-next/tsconfig.json Copy Chapter

{
"extends": "@repo/config-typescript/nextjs.json",
"compilerOptions": {
"baseUrl": "."
},
"include": ["/*.ts", "/*.tsx"],
"exclude": ["node_modules"]
}

File: configs/config-typescript/README.md Copy Chapter

[Empty file]

File: configs/config-typescript/base.json Copy Chapter

{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "Default",
"compilerOptions": {
"declaration": true,
"declarationMap": true,
"esModuleInterop": true,
"forceConsistentCasingInFileNames": true,
"ignoreDeprecations": "6.0",
"incremental": false,
"isolatedModules": true,
"lib": ["es2022", "DOM", "DOM.Iterable"],
"module": "NodeNext",
"moduleDetection": "force",
"moduleResolution": "NodeNext",
"rootDir": "../..",
"resolveJsonModule": true,
"skipLibCheck": true,
"strict": true,
"types": ["node"],
"target": "ES2022",
"strictNullChecks": true,
"downlevelIteration": true,
"baseUrl": ".",
"paths": {
"@repo/": ["../../packages//src", "../../configs/"],
"@frontendchecklist/rules": ["../../packages/rules/src/index.ts"],
"@frontendchecklist/rules/": ["../../packages/rules/src/*"]
}
}
}

File: configs/config-typescript/nextjs.json Copy Chapter

{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "Next.js",
"extends": "./base.json",
"compilerOptions": {
"plugins": [{ "name": "next" }],
"module": "ESNext",
"moduleResolution": "Bundler",
"allowJs": true,
"jsx": "preserve",
"noEmit": true,
"paths": {
"@/": ["./"],
"@repo/": ["../../packages/"]
}
},
"exclude": ["node_modules"]
}

File: configs/config-typescript/node.json Copy Chapter

{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "Node (extensionless imports)",
"extends": "./base.json",
"compilerOptions": {
"module": "ESNext",
"moduleResolution": "node",
"types": ["node"]
}
}

File: configs/config-typescript/package.json Copy Chapter

{
"name": "@repo/config-typescript",
"version": "1.0.0",
"private": true,
"main": "base.json",
"files": [
"*.json",
"README.md"
],
"scripts": {
"clean": "rm -rf .turbo node_modules"
}
}

File: configs/config-typescript/react-library.json Copy Chapter

{
"$schema": "https://json.schemastore.org/tsconfig",
"display": "React Library",
"extends": "./base.json",
"compilerOptions": {
"jsx": "react-jsx"
}
}

File: docs/card-links.md Copy Chapter

Card link pattern (stretched link)

Card-style navigation in the web app uses a stretched link pattern so that:

1. The link's accessible name is the card title (good for screen readers and SEO).
2. The whole card is clickable (good for touch and UX).
3. The link lives in the DOM where it semantically belongs — wrapping the title.

Pattern Copy Chapter

• Container: A div or article with position: relative and the card's visual styles (border, padding, hover). Add group for Tailwind group-hover effects.

• Title link: The <a> or <Link> wraps only the title text inside the <h3> (or equivalent heading). It uses ::after to expand its hit area to fill the card:

  tsx Copy

  <h3 className="...">
    <Link
      href="/destination"
      className={cn(
        'after:absolute after:inset-0 after:content-[""]',
        'focus-visible:outline-none focus-visible:after:ring-2 focus-visible:after:ring-ring focus-visible:after:rounded-xl'
      )}
    >
      {title}
    </Link>
  </h3>

  Because the link is position: static (the default), its ::after pseudo-element with position: absolute is positioned relative to the nearest positioned ancestor — the card container.

• Content: All other visible content (description, pills, icons) lives as normal siblings. No z-index is needed for non-interactive content.

• Secondary actions: Buttons or links (e.g. "GitHub") need position: relative; z-index: 10 to stay clickable above the stretched ::after.

Do not use a separate overlay <a> with absolute inset-0 as a sibling. The link should wrap the title and stretch from there.

External links Copy Chapter

For external links, use <a> instead of <Link>:

<a
  href={url}
  target="_blank"
  rel="noopener noreferrer"
  className={cn(
    'after:absolute after:inset-0 after:content-[""]',
    'focus-visible:outline-none focus-visible:after:ring-2 focus-visible:after:ring-ring focus-visible:after:rounded-xl'
  )}
>
  {title}
</a>

Reference components Copy Chapter

• apps/web/app/[lang]/rules/[category]/[slug]/related-rules-section.tsx — related rule cards
• apps/web/app/[lang]/rules/[category]/[slug]/_components/resource-card.tsx — ResourceCard, ToolCard
• apps/web/app/[lang]/checklists/_components/checklist-card.tsx — ChecklistCard
• apps/web/app/[lang]/_components/homepage/category-card.tsx — CategoryCard
• apps/web/app/[lang]/about/_components/creator-projects.tsx — ProjectCard
• apps/web/components/mentions/embeds/mention-embeds.tsx — ArticleEmbed
• apps/web/components/mentions/embeds/mention-embeds-compact.tsx — YouTubeEmbedCompact, ArticleEmbedCompact

Checklist rule Copy Chapter

This pattern is recommended in the Provide sufficient touch target size rule (packages/content/rules/en/accessibility/touch-targets.mdx) under "Card and list item links."

File: docs/global-skill-benchmark.md Copy Chapter

Global Skill Benchmark

Goal Copy Chapter

Benchmark one aggregate Front-End Checklist skill against popular skills.sh audit and review skills using real findings, not just prompt quality.

Source Of Truth Copy Chapter

The rule corpus is the product. The global skill is a generated aggregate over those rules.

When the benchmark exposes weak output, the default order of operations is:

1. improve the relevant rules
2. regenerate the global skill
3. rerun the affected fixtures
4. compare again

Only use pure prompt tuning when the rule corpus is already decision-complete and the loss is clearly aggregation behavior rather than missing knowledge.

Aggregate Skill Copy Chapter

The aggregate skill is generated at:

• skills/frontend-checklist-global/SKILL.md

It is intentionally a router, not a 374-rule prompt dump. It points agents to the Front-End Checklist MCP tools:

• review_code for file or snippet review
• audit_url for public-page audits
• search_rules, get_rule, fix_rule, explain_rule for targeted remediation
• get_workflow, get_checklist_rules, get_quick_reference for broader guidance

That design keeps the skill current as rules change and avoids duplicating the rule corpus into a static skill file.

How To Test Copy Chapter

1. Regenerate skills:

pnpm generate:skills

2. Run the local benchmark on the main codebase:

pnpm benchmark:global-skill

3. If you want a narrower run, pass directories:

pnpm tsx scripts/benchmark-global-skill.ts apps/web
pnpm tsx scripts/benchmark-global-skill.ts packages/design-system

Benchmark Criteria Copy Chapter

Use the same criteria for every competing skill:

1. Zero-setup execution in a default agent environment
2. Real findings on a local repo, with exact file references
3. Breadth across frontend concerns, not just one slice like performance
4. Rule-grounded remediation instead of generic advice
5. Repeatability across runs
6. Honest scope boundaries

Comparison Set Copy Chapter

These are strong comparison targets because they are either popular or close to the same problem space:

• squirrelscan/skills:audit-website
• addyosmani/web-quality-skills:web-quality-audit
• cloudflare/skills:web-perf
• coderabbitai/skills:code-review

Expected Positioning Copy Chapter

Front-End Checklist should win on:

• Local repo audits with no extra vendor login
• Rule-grounded remediation tied to a named corpus
• Breadth across accessibility, performance, SEO, security, images, and general frontend quality

Front-End Checklist should not claim to beat specialized tools at everything:

• web-perf should remain better for runtime trace-based performance analysis on a live page
• audit-website should remain stronger for multi-page live-site crawling
• code-review may remain better for PR-diff workflows tightly coupled to its own review service

If the aggregate skill starts underperforming on local repo findings, that is a signal to improve review_code heuristics rather than expand the skill prompt.

Current Conclusion Copy Chapter

The benchmark work established a few durable conclusions:

• A single global Front-End Checklist skill is viable, but only when it is strongly derived from the rule corpus.
• Pairwise judging is more useful than coarse heuristic scoring for ranking competing skills.
• Safe-pattern fixtures are essential because many competing skills over-report decorative images, fragment-only components, and framework-managed metadata.
• Repo-derived compound fixtures are the best discriminator for frontend breadth, prioritization, and remediation quality.

This benchmark should remain part of the ongoing maintenance loop for the rule corpus and the generated global skill.

Current Caveat Copy Chapter

The current local benchmark is useful for recall, but some component-level findings still need manual verification.
The recent review_code precision pass reduced React heading-fragment noise substantially.
The main remaining noise in this repo is:

• form-label checks on reusable input primitives or test fixtures
• empty-alt handling where decorative images may be valid but the heuristic treats them as suspicious
• page-component metadata checks on files that rely on framework metadata APIs instead of literal head tags

File: docs/guide-template.mdx Copy Chapter

title: "Guide title"
slug: "guide-slug"
type: "how-to"
category: "performance"
tags:

• "core web vitals"
  publishedAt: "2026-03-13"
  updatedAt: "2026-03-13"
  coverImage: "/guides/cover-example.svg"
  featured: false
  relatedRules:
• "performance/largest-contentful-paint"
  relatedChecklists:
• "core-web-vitals"
  relatedGuides:
• "another-guide"

Write a short intro paragraph before the first H2. It should explain the outcome, who the guide is for, and why it matters now.

TL;DR Copy Chapter

• Add 3-4 concise takeaways.

Before You Start Copy Chapter

Explain prerequisites, scope, and when to use this workflow.

Steps Copy Chapter

1. First step Copy Section

Describe the action clearly.

Examples Copy Chapter

Add realistic examples, screenshots, or code samples.

Common Mistakes Copy Chapter

• Call out common failures and tradeoffs.

Verification Copy Chapter

Describe how the reader confirms the guide worked.

Related Checklist Copy Chapter

Link back to the most relevant checklist and related rules in natural language.

File: docs/guides-authoring.md Copy Chapter

Guides Authoring

Guides live in packages/content/guides/en/ and are a first-class content type separate from the /guide help page.

Supported types Copy Chapter

• how-to
• insight

Required frontmatter Copy Chapter

• title
• description
• slug
• type
• category
• tags
• publishedAt
• updatedAt
• coverImage
• featured
• relatedRules
• relatedChecklists
• relatedGuides

If author is omitted, the site falls back to the default David Dias profile.

Required section order Copy Chapter

How-to Copy Section

1. Intro paragraph before the first H2
2. ## TL;DR
3. ## Before You Start
4. ## Steps
5. ## Examples
6. ## Common Mistakes
7. ## Verification
8. ## Related Checklist

Insight Copy Section

1. Intro paragraph before the first H2
2. ## Context
3. ## Argument
4. ## Examples
5. ## Practical Takeaway
6. ## Related Checklist

Publish checks Copy Chapter

Run these from the repo root:

pnpm validate:guide-structure
pnpm validate:guides

The publish validator currently enforces:

• required frontmatter completeness
• required cover image existence in apps/web/public
• at least 2 internal links in the body
• at least 1 external authoritative link in the body
• at least 180 words of substantive content
• estimated reading grade no higher than 14

Use docs/guide-template.mdx as the starting point for new how-to guides.

File: docs/launch-readiness-checklist.md Copy Chapter

Launch Readiness Checklist

Repo-grounded checklist for launching frontendchecklist.io as both a public product and an open-source project.

This is not a generic startup checklist. It is based on the current repository shape, workflows, env wiring, and public-facing features present on March 26, 2026.

Current repo-specific gaps to resolve first Copy Chapter

• Verify that all contributors, deployment targets, and hosted environments can actually run the pinned baseline of Node 24.14.1 and pnpm 10.33.0.
• Fix E2E path drift. Playwright currently lives under apps/e2e/, but several workflows still reference apps/web/e2e, apps/web/playwright.config.ts, and apps/web/test-results.
• Decide whether waitlist and "coming soon" surfaces stay public at launch. The site currently exposes a Pro waitlist and an MCP CLI notify form.
• Add production error monitoring. Analytics exists via OpenPanel, but there is no real production exception pipeline such as Sentry, Datadog, or Bugsnag wired into the app.
• Decide whether the current env documentation is sufficient for external contributors or whether it should move to a root-level setup guide with service-by-service notes.
• Add missing open-source governance docs. There is no tracked LICENSE, CONTRIBUTING, CODE_OF_CONDUCT, or SECURITY document in the repo root.

Product and site launch Copy Chapter

• Freeze the public IA for launch: home, rules, categories, guides, checklists, MCP docs, account flows, and any waitlist-only surfaces.
• Decide which features are launch scope versus explicitly post-launch. The current repo already hints at future work through waitlists and Pro teasing.
• Review all public CTAs to make sure they land on real, supported flows rather than placeholders or "notify me later" paths.
• Confirm every public page has production-quality metadata, canonical URLs, OG images, and schema where relevant.
• Run a full broken-link pass across README, rules, guides, checklists, nav, footer, and API docs.
• Verify robots and sitemap behavior against the final set of public routes, especially new guide pages.
• Confirm favicon, manifest, Apple touch icon, and social preview assets are complete and render correctly on real devices.
• Review the homepage and rule pages for any copy that still sounds provisional, internal, or pre-launch.
• Decide whether the MCP CLI notify form should remain a waitlist or be replaced with real install/docs guidance before launch.
• Confirm auth UX is ready for public traffic: sign-in, sign-out, error states, profile flows, and social login copy.
• Validate all list/checklist share flows from a cold browser session and on mobile.
• Review 404, not-found, and empty states so they help users recover instead of dead-ending.

Content and corpus readiness Copy Chapter

• Run the full content pipeline before launch: pnpm validate:rule-structure, pnpm validate:guide-structure, pnpm validate:guides, pnpm validate:evidence, pnpm validate:sources, pnpm score:rules, pnpm generate:skills, and pnpm generate:readme.
• Rebuild the README and confirm the published counts and category totals match the live corpus.
• Audit the newest or recently edited rules for consistency in frontmatter, examples, sources, and verification sections.
• Review the guide section for launch credibility. There are currently only a small number of guide documents, so decide whether that is enough for launch or whether more editorial depth is needed.
• Confirm every checklist page feels intentional and complete, not like a thin wrapper around rule lists.
• Validate that llms.txt and MCP-discoverable content reflect the current corpus and route structure.
• Spot-check generated skills against the most important rules and workflows so agents do not get stale guidance.
• Review all content for naming consistency, especially "X" branding, category labels, and route vocabulary.

Ops, infra, and environment readiness Copy Chapter

• Create a single source of truth for required production env vars across web, auth, analytics, email, and rate limiting.
• Add missing launch env vars to .env.example or split them into a more complete root-level env reference.
• Verify production values for:
  • DATABASE_URL
  • BETTER_AUTH_SECRET
  • BETTER_AUTH_URL
  • NEXT_PUBLIC_SITE_URL
  • GITHUB_CLIENT_ID
  • GITHUB_CLIENT_SECRET
  • RESEND_API_KEY
  • RESEND_TOPIC_ID
  • RESEND_AUDIENCE_ID if legacy segment assignment is still needed
  • SUBSCRIBE_SECRET
  • NEXT_PUBLIC_OPENPANEL_CLIENT_ID
  • OPENPANEL_CLIENT_SECRET
  • OPENPANEL_API_URL (self-hosted: https://stats.daviddias.digital/api)
  • UPSTASH_REDIS_REST_URL
  • UPSTASH_REDIS_REST_TOKEN
• Confirm allowedHosts, trustedOrigins, auth callback URLs, and cookie domain behavior match the final production domains and subdomains.
• Verify Vercel project settings for both frontendchecklist.io and mcp.frontendchecklist.io.
• Make sure rate limiting is truly enabled in production. Right now the app degrades to "allow all" when Upstash credentials are missing.
• Confirm the MCP subdomain rewrite and CORS setup still matches the intended browser and agent access patterns.
• Decide whether deploys should remain push-to-main only or require a stricter promotion path through preview/staging first.

Monitoring, analytics, and support Copy Chapter

• Add production error monitoring for the Next.js app and API routes.
• Add alerting for failed auth, failed waitlist submissions, MCP abuse spikes, and unexpected 5xx rates.
• Define a minimum observability dashboard: traffic, conversion, waitlist submissions, MCP usage, API errors, and latency.
• Confirm OpenPanel events are reviewed for privacy and do not capture raw PII unintentionally.
• Decide how to monitor the MCP endpoint separately from the main site.
• Add uptime monitoring for the website and the MCP hostname.
• Decide where user support and bug reports should go on launch day: GitHub Issues, discussions, email, or all three.

Security and abuse prevention Copy Chapter

• Run a focused pre-launch security pass on auth, checklist mutation routes, shared/public list routes, waitlist submission, and MCP.
• Confirm BotID coverage matches the public mutation endpoints you actually want to protect.
• Review public API endpoints for input validation, rate limits, auth requirements, and abuse handling.
• Confirm secrets are not committed anywhere and that secret scanning runs locally and in CI.
• Review CSP, security headers, cookie settings, and OAuth callback configuration in the deployed environment.
• Decide whether the MCP endpoint needs stricter origin allowlists, quotas, or telemetry retention limits before launch traffic arrives.
• Verify privacy-policy and consent flows reflect the real analytics and email behavior in production.

QA, release engineering, and automation Copy Chapter

• Make CI, PR checks, and deploy workflows agree on the same runtime versions, paths, and validation commands.
• Fix the current E2E workflow assumptions so Playwright artifacts and test directories point to the real apps/e2e layout.
• Add guide validation to the default CI path, not just local scripts.
• Confirm pnpm ci:check and the actual GitHub workflows enforce the same launch gate.
• Decide which checks are required on pre-push versus CI-only to keep local workflows fast but reliable.
• Run a final end-to-end launch rehearsal from a clean clone on a fresh machine.
• Validate production deploy behavior after merge: build, rewrite rules, auth, analytics proxy, waitlist, and MCP endpoint.
• Verify deploy reporting and post-deploy notifications behave correctly on push-based production releases.
• Decide whether Lighthouse should block deploys or remain advisory.
• Add a rollback playbook for bad deploys, broken content pushes, and MCP outages.

Open-source launch readiness Copy Chapter

• Add a license file and make the license explicit in the README and package metadata where needed.
• Add a contributor guide covering setup, validation commands, content authoring, and review expectations.
• Add a code of conduct.
• Add a security policy with a disclosure path.
• Add issue templates for bug reports and feature requests.
• Add a PR template that points contributors at pnpm commands and repo conventions.
• Decide how releases are communicated: changelog, GitHub Releases, newsletter, social posts, or all of them.
• Document supported Node and pnpm versions clearly in contributor-facing docs.
• Decide whether GitHub Discussions should be enabled for questions and community support.
• Review README onboarding from the perspective of a first-time contributor and a first-time user of the MCP server.

Nice-to-have before or right after launch Copy Chapter

• Add a staging checklist that mirrors launch-day smoke tests.
• Add a simple launch dashboard or internal scorecard for traffic, signups, errors, and MCP usage.
• Add automated secret scanning in CI if you want a second line of defense after local hooks.
• Add dependency and dead-code audits such as pnpm audit and knip when the repo is stable enough to enforce them.
• Add issue labels, milestones, and a short public roadmap so incoming feedback is easier to triage.

File: docs/mcp-analytics.md Copy Chapter

MCP usage analytics

OpenPanel project: frontend-checklist. Collection is enabled only with
MCP_TELEMETRY_ENABLED=true and production OpenPanel credentials. Delivery runs
inside Next.js after() so the Vercel function awaits it after responding.

Event meanings Copy Chapter

• mcp_tool_called: one completed registered tool execution, including semantic
  failures. Properties include toolName, outcome, durationMs, and
  returnedRuleCount. This duration excludes network delivery. Invalid protocol
  requests, input validation rejections and rate limits are outside this metric.
• mcp_rule_requested: a canonical rule requested through get_rule,
  check_rule, fix_rule or explain_rule.
• mcp_rule_returned: each distinct canonical rule returned by a search, review,
  audit, workflow, checklist or quick-reference call. This does not indicate that
  somebody applied a fix.

Use total event counts. Anonymous server events have no reliable user identity.
Existing events are not backfilled when new dimensions are introduced.

Client source Copy Chapter

All three events include these bounded dimensions:

These are self-reported analytics hints, not authenticated identities or proof
of which model ran. Modern MCP client information takes precedence when its name
matches the explicit product allowlist. OpenAI's optional openai/userAgent
metadata yields an OpenAI vendor hint, without inferring ChatGPT versus Codex.
Explicit HTTP user-agent product tokens are a fallback. Conflicting vendor
signals yield unknown; generic browser/SDK user agents do not identify a vendor.
An unrecognized client name yields other, without retaining that name.

Legacy stateless calls cannot inherit client information from an earlier
initialize request. No session, IP, account or fingerprint matching is used to
guess that relationship. Clients that send neither supported metadata nor an
explicit product user agent remain unknown. The client SDK integration test
checks that classifications do not leak between callers.

The MCP per-request metadata specification
defines optional client information and its self-reported nature.
OpenAI's reference
documents the optional analytics hint and warns against treating it as a stable
host-surface identifier.

No raw client name, version, user agent, prompt, code, query, audited URL, user
location, user/conversation/organization identifier or account data is forwarded
to OpenPanel. Its geography for these server events represents the Vercel
function, not the caller.

Dashboards Copy Chapter

• MCP Usage & Reliability
• Rule Demand
• Website Engagement

The OpenPanel gateway MCP can verify saved report configurations and execute
reports. Dashboard/report creation currently uses the authenticated browser UI.
Verify production receipts separately from local classifier tests. Synthetic
source verification calls do not prove that a real directory client emits those
signals.

File: docs/mcp-quality.md Copy Chapter

MCP quality pipeline

This doc describes how we run the Front-End Checklist MCP server through third-party and in-repo tools to improve quality, security, and compatibility.

Server

• URL: https://mcp.frontendchecklist.io
• Code: packages/mcp (handler), apps/web/app/api/mcp/route.ts (HTTP wrapper)

One-command audit (recommended) Copy Chapter

From the repo root:

pnpm mcp:audit

This runs:

1. Unit tests for @repo/mcp (Jest).
2. Security scan of packages/mcp/src with mcp-security-auditor (fails only on critical; medium/high often false positives).

Exit code is non-zero if tests fail or the security scan reports critical issues. Safe to use in CI.

Quality evaluation Copy Chapter

Run the golden MCP quality evaluation from the repo root:

pnpm mcp:evaluate

This runs packages/mcp/tests/quality/mcp-quality.test.ts against the real rule corpus and prints a compact quality report. It currently measures:

1. Retrieval quality with golden discovery queries using Recall@5 and mean reciprocal rank.
2. review_code accuracy with labeled true-positive and true-negative fixtures, reported as precision, recall, and false-positive rate.
3. Improvement impact with before/after code scenarios that check whether review_code identifies known defects, provides guidance, and verifies those defects are gone after a corrected version.
4. Tool contract quality across the full 11-tool surface, including naming, schemas, read-only annotations, and agent-facing descriptions.

The command fails when quality drops below the current thresholds:

• Retrieval Recall@5 >= 80%
• Retrieval MRR >= 0.50
• review_code precision >= 90%
• review_code recall >= 85%
• review_code false-positive rate <= 10%
• Improvement-impact defect detection rate >= 90%
• Improvement-impact verification-clear rate >= 95%
• Improvement-impact guidance rate >= 90%
• All 11 expected tools remain exposed when checklist data exists

Use this when changing search scoring, rule metadata, detector heuristics, tool definitions, or checklist-backed MCP behavior.

This is still a deterministic proxy, not a full agent A/B test. It answers whether the MCP can point an agent at the right fixes and verify those fixes locally. To prove an LLM writes better patches with the MCP, run the same benchmark tasks twice with the same model: once without MCP access and once with MCP access, then score the resulting diffs for expected fixes, regressions, tests, token cost, and time.

Impact benchmark Copy Chapter

Run the A/B benchmark harness when you want to measure whether MCP access improves actual agent patches:

pnpm mcp:impact -- --init .mcp-impact/run-001

This creates two identical workspaces:

• .mcp-impact/run-001/without-mcp
• .mcp-impact/run-001/with-mcp

Run the same model twice with the same prompt, time budget, and temperature. Disable the Front-End Checklist MCP in without-mcp; enable it in with-mcp. Then score the outputs:

pnpm mcp:impact -- --score .mcp-impact/run-001

The scorer checks fixed frontend defects across image accessibility/layout stability, icon-button accessible names, new-tab link hardening, unsafe dynamic code execution, and viewport zoom accessibility. It reports expected fixes completed in each condition plus the MCP delta.

Verify the harness itself with:

pnpm mcp:impact -- --self-test

Ecosystem quality radar Copy Chapter

Run the broader skills, rules, and MCP contract radar from the repo root:

pnpm skills:audit

This turns current ecosystem research into local, repeatable checks:

• Skills as reusable workflows: OpenAI and GitHub both describe skills as SKILL.md workflows with clear descriptions, optional resources/scripts, required outputs, and final checks. The audit measures grounding URLs, references, workflow language, output contracts, progressive disclosure, validation checklists, and assessment questions.
• Skill registry safety: skills.sh and GitHub's gh skill docs both emphasize reviewing third-party skill contents before installation. The audit now tracks safety-boundary language so generated skills do not only say what to do, but also when to avoid risky behavior.
• MCP contract quality: the official MCP docs and schema reference emphasize unique names, input/output schemas, tool annotations, and inspectable server behavior. The audit verifies all 11 public tools have valid names, input schemas, output schemas, read-only/non-destructive/idempotent annotations, and a narrow open-world boundary.
• Modern frontend gap radar: public web platform docs from MDN, web.dev, Chrome Developers, W3C/WICG, and Privacy Sandbox feed a candidate list for emerging or under-covered frontend rules.

Research references used for these criteria:

• OpenAI: Using skills
• GitHub Docs: Adding agent skills for GitHub Copilot
• skills.sh docs
• google/skills
• MCP Inspector
• MCP Registry
• MCP Tool Annotations
• MCP Security Best Practices
• MCP Schema Reference

Security-only (no tests):

pnpm mcp:audit:security

Tools we use Copy Chapter

1. MCP Inspector (manual) Copy Section

What: Official MCP testing/debugging UI. Good for ad‑hoc tool calls and protocol behavior.

How:

• Ensure the server is reachable (e.g. pnpm dev and use production URL, or deploy).
• Run: pnpm dlx @modelcontextprotocol/inspector
• Add server via HTTP with URL: https://mcp.frontendchecklist.io (or your local URL).

Use this to manually verify tools, try prompts, and debug responses.

2. MCP Doctor (optional, Python) Copy Section

What: Health and security checks (auth, credentials, agent-friendliness). Rule-based, no LLM.

How: Python 3.10+. See destilabs/mcp-doctor.

• Install and run against the running server URL (HTTP). Useful for periodic audits against the live endpoint.

3. mcp-security-auditor (automated) Copy Section

What: Scans MCP server source code for secrets, injection risks, unsafe patterns, and dependency issues.

How:

pnpm dlx mcp-security-auditor scan packages/mcp/src

Optional: fail CI on critical only: --fail-on critical. Medium/high findings (e.g. relative imports flagged as path traversal, or request handlers as SSRF) are often false positives; review and ignore as needed.

4. In-repo tests Copy Section

What: Jest tests in packages/mcp/tests/ that call the MCP handler directly (no HTTP).

How:

pnpm --filter @repo/mcp test
# or
pnpm test --filter=@repo/mcp

Coverage: tools/list, get_rule, search_rules, check_rule, fix_rule, explain_rule, list_categories, review_code, get_workflow, get_quick_reference, telemetry, error handling.

5. Golden quality evals Copy Section

What: Labeled quality checks in packages/mcp/tests/quality/ that answer “is the MCP useful to agents and likely to improve code?” rather than only “does it execute?”

How:

pnpm mcp:evaluate

Add a retrieval case whenever a real agent query should reliably find a rule. Add a review fixture whenever review_code gains a new heuristic or previously noisy behavior is fixed.

6. Tool performance benchmarks Copy Section

What: In-process latency benchmarks for the main tools; asserts p95 stays within budget and that review_code scales sub-linearly as the rule set grows.

How:

pnpm --filter @repo/mcp test -- tool-performance.test --verbose

Budgets (p95, in ms): review_code 100, search_rules 50, list_categories 50, get_rule 5, get_checklist_rules 10. These run as part of the full MCP test suite and in pnpm mcp:audit. They do not cover the HTTP layer (Next.js route, JSON serialization) or audit_url (which does a live fetch).

7. Protocol conformance (official suite) Copy Section

What: Runs @modelcontextprotocol/conformance (pinned in packages/mcp/scripts/conformance.ts) against a standalone copy of the server. Most scenarios target the reference "everything" server's fixture tools (test_simple_text, test://static-text, …), so packages/mcp/conformance-baseline.yml lists them as expected failures with the reason. Everything this server advertises must pass: initialize, ping, tools/list, resources/list, prompts/list, and DNS-rebinding protection.

How:

pnpm mcp:conformance                                  # spawns scripts/serve.ts on a free port
pnpm mcp:conformance -- --url http://localhost:3000/api/mcp   # any running server

Fails on any failure outside the baseline and on baseline entries that start passing (stale baseline).

8. Load testing and profiling Copy Section

What: packages/mcp/scripts/load-test.ts drives a weighted mix of real operations (connect, tools/list, search_rules, get_rule, review_code, resources/read, prompts/get, skills/list) at stepped concurrency, half with the official v2 client on protocol 2026-07-28 and half with 2025-era JSON-RPC. Per operation it reports throughput, p50/p95/p99/max latency and errors; per stage it reports server CPU ms per request and RSS.

By default it spawns the standalone server (scripts/serve.ts, same handleMcpHttpRequest pipeline as the Vercel route, minus Next.js, CORS and rate limiting) in its own process, so client and server do not share an event loop.

How:

pnpm mcp:load                                         # 1, 8, 32 workers × 10 s, mixed eras
pnpm mcp:load -- --concurrency 1,16,64 --duration 20
pnpm mcp:load -- --era modern                         # 2026-07-28 clients only
pnpm mcp:load -- --profile                            # V8 CPU profile + top self-time functions
pnpm mcp:load -- --compare .mcp-load/baseline.json    # deltas vs a previous run
pnpm mcp:serve -- --port 3100                         # just the standalone server

Reports (and .cpuprofile files, loadable in Chrome DevTools → Performance) go to .mcp-load/ (gitignored). The run exits non-zero when any stage's error rate exceeds 1%.

Reading results: wall-clock throughput depends on what else the machine is doing; the harness records the load average and warns when the machine is busy. Prefer server CPU ms per request for before/after comparisons: it is kernel-accounted CPU time, so it stays valid under contention. Do not point the load test at production: it is rate limited (30 requests/min per IP), so you would only measure the limiter.

Finding improvements: run with --profile, read the "Server CPU hot spots" table, fix the top entry, then re-run with --compare against the previous report.

History:

9. Tool-description lint (CI) Copy Section

What: packages/mcp/tests/quality/tool-descriptions.test.ts. Agents choose tools from the name, description and input schema alone, so these are the server's real prompt. The lint fails when a description:

• is outside 150–650 characters, or the combined budget exceeds 5,500;
• doesn't say when to use the tool ("Use it when…");
• uses emphatic all-caps or bold wording, which makes newer models over-trigger a tool;
• names a tool that doesn't exist;
• leaves a parameter documented in fewer than 25 characters, a numeric input without bounds, or an optional enum/boolean/number without its default;
• reads too much like a sibling tool's description (word-overlap Jaccard above 0.35).

It runs with the normal test suite (pnpm --filter @repo/mcp test).

10. Tool-choice eval (Anthropic API, on demand) Copy Section

What: packages/mcp/scripts/eval-tool-choice.ts sends single-turn prompts to Claude with the server's tool definitions and a neutral client system prompt, then records which tool the model calls first, or whether it answers directly. The cases live in scripts/tool-choice/cases.ts:

• clear: one obviously right tool.
• confusable: sibling tools the descriptions must disambiguate, such as fix_rule vs get_rule vs explain_rule, review_code vs audit_url, and get_quick_reference vs search_rules.
• no-tool: general coding or chit-chat, where calling a tool is an over-trigger.

Each case runs k times. The report gives:

• accuracy;
• pass@k, the share of cases the model gets right at least once;
• pass^k, the share it gets right every time, which is what users of an agent feel;
• over- and under-trigger rates;
• an expected -> chosen confusion list;
• token usage.

How (needs ANTHROPIC_API_KEY or an ant auth login profile; every non-dry run spends API credits):

pnpm mcp:eval-tools -- --dry-run                                   # validate cases, print request count
pnpm mcp:eval-tools                                                # claude-opus-5-5, k=3 (93 requests)
pnpm mcp:eval-tools -- --models claude-opus-5-5,claude-sonnet-5-5,claude-haiku-4-5
pnpm mcp:eval-tools -- --only confusable --trials 5
pnpm mcp:eval-tools -- --min-pass-hat-k 0.9                        # exit 1 below the threshold

Reports go to .mcp-evals/ (gitignored). The runner records rate limits, server errors and connection failures as failed trials and aborts on anything systemic, such as missing credentials or an unknown model. Refusals are counted on their own. Server-side refusal fallbacks are deliberately off, because a fallback would score a different model than the one under test.

Improving tools with it: when a case misses, fix the description or schema rather than the case. Then re-run --only <group> and compare pass^k. Every case's expected tools are unit-tested against the live tool list, so renaming a tool breaks the build instead of silently invalidating the eval.

Suggested workflow Copy Chapter

• Before PRs: Run pnpm mcp:audit (tests + security scan) and pnpm mcp:conformance.
• After changing a tool name, description or schema: Run pnpm mcp:eval-tools -- --only confusable and compare pass^k with the previous report.
• Before performance-sensitive changes: Save a pnpm mcp:load -- --out .mcp-load/before.json report, then compare with --compare .mcp-load/before.json.
• Periodically: Run MCP Inspector against https://mcp.frontendchecklist.io and, if you use Python, MCP Doctor against the same URL.
• CI: Add pnpm mcp:audit to your pipeline (e.g. ci:check or a dedicated MCP job).

Adding more tools Copy Chapter

If you adopt MCPSpec, MCP Eval, or other CLIs, add them to scripts/audit/mcp-audit.ts (or new scripts) and document the exact commands and exit-code behavior here.

Token / response size Copy Chapter

Tool responses are capped so the MCP doesn’t blow LLM token budgets:

• Default: Each tool response is limited to ~32k characters (~8k tokens). If the JSON would exceed that, it’s truncated at a newline and a short [... response truncated to stay within token budget ...] note is appended.
• Configure: Set MCP_MAX_RESPONSE_CHARS (number) in the app env to override the limit. handleMcpHttpRequest(request, getRules, getChecklists, { maxResponseChars }) and createMcpServer(getRules, getChecklists, { maxResponseChars }) accept it programmatically.
• Pagination: Use search_rules with limit and cursor to fetch in smaller chunks; get_rule returns one rule (still subject to the cap).

Telemetry Copy Chapter

What exists

• In-memory usage counters in packages/mcp: every tools/call increments a per-tool counter when telemetry is enabled. Exposed via getTelemetryStats() and in GET /api/mcp as the optional usage object (e.g. usage: { get_rule: 42, search_rules: 10 }). Anonymous only; no IPs or identifiers. Counts reset on each deploy/restart.
• Database persistence: Each tools/call is stored in the McpToolCall table (anonymous: toolName, createdAt). The API route writes after a successful request; DB errors are ignored so telemetry never breaks MCP responses. Apply migrations with pnpm --filter @repo/auth db:migrate.

Enabling telemetry

• Telemetry is disabled by default for the public hosted endpoint to avoid database writes and analytics work for routine agent traffic.
• Set MCP_TELEMETRY_ENABLED=true (or MCP_TELEMETRY_ENABLED=1) in the app environment to opt in. When enabled: in-memory counters are updated, GET /api/mcp includes usage, and successful tools/call requests write anonymous rows to McpToolCall. handleMcpHttpRequest and createMcpServer also accept { telemetryEnabled: true } when used programmatically (e.g. in tests).

How to see it

• Live counts: GET https://mcp.frontendchecklist.io (or local /api/mcp) returns usage with per-tool counts for the current process.
• Historical data: Query the database, e.g. SELECT "toolName", COUNT(*), DATE("createdAt") FROM "McpToolCall" GROUP BY "toolName", DATE("createdAt"); or use Prisma Studio / your analytics stack.

Extending

• External analytics: In the API route, after prisma.mcpToolCall.createMany, send an event to your provider (Vercel Analytics, PostHog, etc.) with no PII.
• Structured logs: Log each tool call as JSON to stdout and rely on your host’s log aggregation.

File: docs/production-launch-readiness.md Copy Chapter

Production Launch Readiness

Last updated: 2026-05-29

Executive Summary Copy Chapter

The v2 frontend is launchable from the local readiness sweep. The production build, unit CI, typecheck, lint, rule quality gates, source validation, MCP audit, generated skills, and Playwright smoke suite are passing locally.

The main launch blocker is Vercel project configuration. A preview build rehearsal on 2026-05-29 pulled project settings for david-dias-digital/frontendchecklist.io and found the project configured as root directory . with framework Other. Vercel successfully ran the monorepo build, but failed packaging because it expected a static public output directory instead of the Next.js app in apps/web.

Before production deploy, update the Vercel project settings to:

• Root Directory: apps/web
• Framework Preset: Next.js
• Build Command: auto-detected, or pnpm --filter web build
• Install Command: auto-detected pnpm install
• Output Directory: auto-detected

After updating settings, rerun vercel pull --yes --environment preview --scope david-dias-digital, vercel build --yes, and preview smoke tests.

Verified Gates Copy Chapter

• pnpm score:rules: 385/385 rules pass, average score 95%.
• pnpm validate:rule-structure: 385 rules checked, 0 errors.
• pnpm validate:evidence: 385 rules checked, 0 issues.
• pnpm validate:sources: 385 rules checked, 0 broken URLs.
• pnpm validate:packages: passes; no npmPackages metadata currently present.
• pnpm generate:skills: generated 385 skills.
• pnpm lint: passes.
• pnpm typecheck: 21/21 tasks pass.
• pnpm test:ci: 16/16 tasks pass.
• pnpm exec turbo build --force: production build passes.
• pnpm test:e2e:ci: 9/9 Playwright smoke tests pass across Chromium, Firefox, and WebKit.
• pnpm mcp:audit: passes with no critical findings.
• vercel build --yes: blocked by Vercel project settings, not app compilation. Vercel ran the Next build successfully, then failed with No Output Directory named "public" found because the project is configured as Other at repository root.

Fixed During Sweep Copy Chapter

• Restored production build compatibility for @frontendchecklist/rules by keeping ESM source imports and adding runtime JS shims for Turbopack resolution.
• Wrapped request-bound account layout auth checks in Suspense, fixing the Next.js Cache Components prerender blocker on /profile.
• Hardened pnpm validate:sources with lower concurrency, longer timeout, HEAD-to-GET fallback, and a retry for transient source-host failures.
• Replaced brittle rule citations with more specific stable sources for breadcrumb, geo meta, meta refresh, Open Graph, RFC URL syntax, and related SEO rules.
• Fixed MCP audit path resolution and switched MCP security-audit invocation to pnpm dlx.
• Raised MCP performance budgets to match current corpus size while keeping latency checks active.
• Fixed PR workflow e2e artifact/path filters for the current apps/web/e2e layout.
• Removed unnecessary header hydration suppressions and footer decorative blobs.

Browser QA Copy Chapter

Manual local production smoke passed on:

• Desktop homepage, rule detail, checklist detail, and MCP page.
• Mobile homepage and mobile menu.
• Signed-out /profile redirects back to the public home page.
• Local /api/mcp metadata endpoint returns 200 with 11 tools, prompts, resource templates, and security headers.

Residual Risks Copy Chapter

• mcp-security-auditor still reports two high SSRF-looking findings for new Request(request.url, ...) in the MCP request adapter. These appear to be static-analysis false positives because no outbound fetch is made, but they should be triaged before calling the security report clean.
• MCP heuristic coverage is 128/135 rules (94.8%). Missing heuristic coverage is a post-launch quality backlog, not a current failing gate.
• React Doctor reports warning-only cleanup: Tailwind size-* shorthands, mention embeds using ``, and multi-component mention embed files. Score is 99/100 after fixing the header error.
• Vercel preview verification is blocked until the project uses apps/web as root with the Next.js framework preset.
• Production-only checks still need Sentry/OpenPanel env sanity, live mcp.frontendchecklist.io behavior, and remote migration readiness review.

File: docs/rule-structure.md Copy Chapter

Rule Structure Guide

Front-End Checklist rules now use one machine-detectable core body contract:

1. Intro paragraph before any H2
2. ## Code Example or ## Code Examples
3. ## Why It Matters
4. Optional implementation or guidance sections
5. ## Verification

Rule Contract V2 adds lightweight, conditional guidance:

• ## Exceptions for nuanced or false-positive-prone rules
• ### Automated Checks and ### Manual Checks inside ## Verification when both apply
• ## Browser Support, ## Support Notes, or ## Standards when compatibility or compliance materially affects implementation

Browser support notes should come from the repo browser policy in .browserslistrc plus package-backed compatibility data.

Inline link contract Copy Chapter

Body prose may include natural inline links when they directly support a sentence-level claim, comparison, or implementation recommendation.

• Keep sources as the authoritative evidence registry.
• Keep resources for further reading, tools, and optional secondary references.
• Keep relatedRules as the discovery graph for dedicated related-rule UI.
• Do not add standalone metadata paragraphs such as See also ... or Reference: ....
• Aim for light-touch density: usually 2-5 inline links per rule, with 0-1 in the intro, 1-3 across the main guidance sections, and 0-1 internal rule link unless the rule is unusually interconnected.
• Prefer newer inline secondary articles only when they add practical or current context that the evergreen primary sources do not already cover well.
• When you mention a specific tool for the first meaningful time in the prose, link that first mention if the tool is genuinely useful to the reader and already appears in resources or tools.
• Keep secondary article links curated. Good defaults are well-established practitioner sources such as CSS-Tricks, Smashing Magazine, NN/g, WebAIM, Screaming Frog, Sitebulb, Moz, or Yoast.
• Use descriptive anchor text that names the concept or claim being supported.

Required rules Copy Chapter

• ## Code Example(s) must appear before ## Why It Matters
• ## Why It Matters must appear before ## Verification
• ## Verification must be the final H2
• Optional H2 sections belong between ## Why It Matters and ## Verification

Preferred optional headings Copy Chapter

• ## Best Practices
• ## Common Mistakes
• ## Framework Examples
• ## Tools & Validation
• ## Thresholds
• ## Exceptions
• ## Browser Support
• ## Support Notes
• ## Standards
• ## Implementation Notes

The validator reports headings outside this taxonomy so new one-off section names do not spread silently.

Conditional V2 sections Copy Chapter

Use ## Exceptions when the rule needs caveats, false-positive guidance, or valid exceptions.

Use ## Browser Support or ## Support Notes when a rule depends on feature support, environment differences, or fallback strategy.

Use ## Standards when a visible WCAG, spec, Google, or policy mapping changes implementation decisions.

Inside ## Verification, prefer:

## Verification

### Automated Checks

- CI, lint, crawler, Lighthouse, axe, or script-based validation

### Manual Checks

- Browser, assistive tech, visual, or judgment-based validation

Keep a compact flat verification list only when the rule is too simple to justify the split.

Before Copy Chapter

Short intro paragraph.

## Basic Implementation

...

## Testing

...

## Accessibility Considerations

...

After Copy Chapter

Short intro paragraph.

## Code Example

...

## Why It Matters

...

## Accessibility Considerations

...

## Verification

...

Commands Copy Chapter

pnpm validate:rule-structure
pnpm validate:rule-structure --report
pnpm report:v2-gaps
pnpm report:rule-links
pnpm generate:exceptions-hints
pnpm generate:support-notes
pnpm generate:verification-split
pnpm normalize:rule-structure --report
pnpm normalize:rule-structure --write

File: docs/rule-template.mdx Copy Chapter

title: "Rule title" categories: ['html'] priority: 'high' difficulty: 'beginner' estimatedTime: 15 prompts: check: "Describe exactly what to audit" fix: "Describe exactly how to remediate the issue" explain: "Describe why this matters and how to verify it" Copy Chapter

Write a short intro paragraph that explains the rule in plain language before any H2 headings.

Code Example Copy Chapter

<!-- Prefer paired passing and failing examples -->

Why It Matters Copy Chapter

Explain the user, business, accessibility, performance, or maintenance impact.

Best Practices Copy Chapter

• Add optional guidance sections only when they materially help implementation.

Exceptions Copy Chapter

• Add this only when the rule has valid exceptions, caveats, or common false positives.

Browser Support Copy Chapter

• Add this only when compatibility or fallback strategy materially affects implementation.

Verification Copy Chapter

Automated Checks Copy Section

• Describe CI, lint, crawler, Lighthouse, axe, or script-based checks when they exist.

Manual Checks Copy Section

• Describe browser, assistive tech, visual, or judgment-based checks when they are needed.

File: docs/v2-positioning-memo.md Copy Chapter

Front-End Checklist V2 Positioning Memo

Summary Copy Chapter

Front-End Checklist V2 should be positioned as a trusted front-end quality system for humans and AI agents, not as a generic library of tips.

That means the primary story is:

• a high-quality rule corpus
• executable workflows for launch, review, and audits
• MCP and skills as distribution for AI-assisted work
• guides and checklists as onboarding paths for humans

The project is strongest when it feels like shared infrastructure for front-end quality, not like a content site with many articles.

Core Positioning Copy Chapter

Positioning statement Copy Section

Front-End Checklist is the open-source front-end quality system for teams that want trusted review standards for both humans and AI agents.

One-sentence homepage version Copy Section

Trusted front-end quality rules for humans and AI agents.

Expanded product version Copy Section

Browse the rules on the web, run curated workflows, or connect the same corpus to MCP-capable tools for structured AI reviews.

Who It Is For Copy Chapter

Primary audiences Copy Section

• Senior engineers and tech leads who want consistent review standards
• AI-heavy developers who want better retrieval than generic LLM knowledge
• Agencies and consultancies that need repeatable audit workflows
• Developer educators who want examples, verification steps, and structured guidance

Secondary audiences Copy Section

• Junior developers learning what “good” looks like in production
• Product teams preparing launches or audits
• Open-source maintainers who want a shared quality checklist

Audience fit by role Copy Section

• Juniors need guided entry points, not the raw corpus first
• Seniors want search, prioritization, MCP, and review workflows
• AI users want structured tools, prompts, and proof that the corpus is opinionated and maintained

Why It Matters In The AI Era Copy Chapter

The differentiator is not “frontend best practices.” That is crowded.

The differentiator is:

• the rules are structured enough for retrieval and automation
• the corpus has evidence, scoring, and validation
• MCP lets the same rules drive real agent workflows
• skills make the content reusable in agentic tooling

This makes Front-End Checklist more than documentation. It becomes an execution layer for front-end quality.

Message Architecture Copy Chapter

What to emphasize Copy Section

• Trusted and maintained corpus
• Shared standards for teams and agents
• Actionable workflows, not just reference material
• Verification and remediation guidance
• Open source plus AI-native distribution

What to de-emphasize Copy Section

• “Huge list of best practices”
• generic “learn web development” framing
• counts as the primary value story
• broadness without guidance on where to start

Product proof points Copy Section

• hundreds of production-oriented rules
• hosted MCP server
• curated checklists for concrete workflows
• rule scoring, structure validation, and source validation
• guides tied back to rules and checklists

Homepage Recommendations Copy Chapter

Recommended hero direction Copy Section

Lead with trust, execution, and AI relevance in one sentence.

Suggested supporting copy:

• Browse the rule corpus on the web
• Start with curated workflows for launch and audits
• Connect the same corpus to AI tools through MCP

Headline options Copy Section

1. Trusted front-end quality rules for humans and AI agents
2. The open-source front-end quality system for modern teams
3. Front-end review standards your team and AI tools can actually use
4. A shared front-end quality layer for code reviews, audits, and launches
5. Production-ready front-end standards, executable by humans and AI

Subhead options Copy Section

1. Browse 385 rules across 11 categories, run curated workflows, or connect the corpus to MCP-capable tools for structured AI reviews.
2. Use the same rule corpus for launch checklists, code reviews, and AI-assisted audits.
3. Turn front-end best practices into repeatable workflows, trusted references, and AI-native review tools.

Audience Entry Points Copy Chapter

The homepage and docs should create clear entry routes instead of dropping everyone into the same giant corpus.

Recommended entry points:

• Start here as a junior developer
• Use this for senior code review
• Run a launch-readiness workflow
• Audit with AI using MCP
• Browse accessibility and performance first

These can be delivered through curated checklists, guide cards, and homepage sections before adding more complex product UI.

What To Build Next Copy Chapter

Short-term Copy Section

• Unify public counts and category metadata everywhere
• Make privacy and internationalization feel first-class in category UX
• Tighten homepage and MCP copy around the “quality system” story
• Add stronger “who this is for” entry points

Medium-term Copy Section

• Show real MCP demo flows with before/after review examples
• Add framework-specific workflows for React, Next.js, Astro, and static sites
• Package launch, accessibility, and performance as the canonical starting workflows

30-Day Buzz Plan Copy Chapter

Week 1 Copy Section

• Publish a launch post framing Front-End Checklist as a front-end quality system for humans and AI agents
• Tighten homepage, README, and MCP page messaging
• Make one canonical demo video or GIF of MCP finding real issues

Week 2 Copy Section

• Publish two example audits:
  • “Generic AI review vs Front-End Checklist MCP review”
  • “Launch-readiness audit of a real page”
• Share focused clips and screenshots on X and developer communities

Week 3 Copy Section

• Ship one or two framework-targeted guides:
  • using Front-End Checklist with Next.js
  • using Front-End Checklist for accessibility reviews
• Ask early users to share real workflows and repo integrations

Week 4 Copy Section

• Package the strongest demos into a single landing-page proof section
• Promote one opinionated thesis:
  • AI reviews are only as good as the rule corpus behind them

Risks Copy Chapter

• If counts drift across README, site, and metadata, the project feels less trustworthy
• If the homepage keeps framing the product as a giant checklist, the AI-native story gets buried
• If juniors do not get guided entry points, the corpus feels overwhelming
• If there are no public examples of the MCP server doing useful work, the AI story feels hypothetical

Recommendation Copy Chapter

Lean harder into the second identity: Front-End Checklist as trusted front-end quality infrastructure.

That is the version with the most relevance, the most differentiation, and the highest chance of earning attention beyond the usual “best practices” audience.

File: docs/audit-comparison/README.md Copy Chapter

Comparative Audit: Front-End Checklist vs squirrelscan

This folder holds results and instructions for comparing our audit_url tool against squirrelscan (and other audit tools) on the same set of URLs. The goal is to document gaps: where our 377-rule corpus finds issues that others miss, and vice versa.

Test URLs (10 sites) Copy Chapter

1. Run our audit (Front-End Checklist) Copy Chapter

Prerequisites: Dev server running (pnpm dev from repo root).

# From repo root; uses http://localhost:3000 by default
pnpm tsx scripts/compare-audit.ts

Optional: run against the deployed MCP server:

BASE_URL=https://mcp.frontendchecklist.io pnpm tsx scripts/compare-audit.ts

Output: docs/audit-comparison/our-results.json — one audit result per URL (summary + issues).

2. Run squirrelscan on the same URLs Copy Chapter

Install squirrelscan (see docs):

curl -fsSL https://squirrelscan.com/install | bash

Run a single-page audit for each URL (no crawl) for a fair comparison with our single-page audit_url:

# Example: one URL, JSON output
squirrel audit https://example.com -f json -o docs/audit-comparison/squirrel-example-com.json

To batch all 10 URLs (bash):

mkdir -p docs/audit-comparison/squirrel
for url in https://example.com https://web.dev https://developer.mozilla.org https://frontendchecklist.io https://www.w3.org https://nextjs.org https://react.dev https://vercel.com https://github.com https://stackoverflow.com; do
  name=$(echo "$url" | sed 's|https\?://||;s|\.|_|g;s|/|_|g')
  squirrel audit "$url" -C quick -f json -o "docs/audit-comparison/squirrel/${name}.json"
done

Note: squirrelscan crawls by default; use -C quick or -m 1 to approximate single-page checks. Our tool only audits the given URL’s HTML.

3. Document gaps Copy Chapter

After both runs, fill in the table below (and add rows per URL if useful).

Where we find issues they don’t (our rule depth) Copy Section

Where they find issues we don’t Copy Section

Summary (edit after runs) Copy Section

• Our strengths: e.g. fix prompts per rule, MCP-native, 377 open-source rules, categories (a11y, SEO, performance, security, etc.).
• Their strengths: e.g. multi-page crawl, incremental caching, E-E-A-T, adblock/legal/analytics categories.
• Use this for: marketing (“we find X that others miss”), product (prioritize rules or crawler work), and partnership (complementary tools).

Files in this folder Copy Chapter

File: docs/audit-comparison/our-results.json Copy Chapter

{
"runAt": "2026-03-11T00:18:31.542Z",
"results": [
{
"url": "https://example.com",
"fetchedAt": "2026-03-11T00:18:31.492Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://web.dev",
"fetchedAt": "2026-03-11T00:18:31.498Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://developer.mozilla.org",
"fetchedAt": "2026-03-11T00:18:31.502Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://frontendchecklist.io",
"fetchedAt": "2026-03-11T00:18:31.506Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://www.w3.org",
"fetchedAt": "2026-03-11T00:18:31.513Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://nextjs.org",
"fetchedAt": "2026-03-11T00:18:31.518Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://react.dev",
"fetchedAt": "2026-03-11T00:18:31.523Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://vercel.com",
"fetchedAt": "2026-03-11T00:18:31.527Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://github.com",
"fetchedAt": "2026-03-11T00:18:31.538Z",
"success": false,
"error": "fetch failed"
},
{
"url": "https://stackoverflow.com",
"fetchedAt": "2026-03-11T00:18:31.542Z",
"success": false,
"error": "fetch failed"
}
]
}

File: docs/audits/2026-10-04-mcp-validation/boundaries-final.txt Copy Chapter

PASS app/api/mcp/tests/route.test.ts (14.5 s)
PASS app/api/mcp/tests/request-body.test.ts
PASS lib/tests/mcp-cache.test.ts
Test Suites: 3 passed, 3 total
Tests: 20 passed, 20 total
Time: 19.47 s

File: docs/audits/2026-10-04-mcp-validation/core-postfix.txt Copy Chapter

PASS tests/unit/review-code-detection.test.ts
PASS tests/quality/mcp-quality.test.ts (8.787 s)
PASS tests/unit/false-positive-audit.test.ts
PASS tests/unit/heuristic-coverage.test.ts
PASS tests/integration/mcp-server.test.ts
PASS tests/unit/tool-performance.test.ts
PASS tests/integration/skills.test.ts (26.598 s)
PASS tests/quality/tool-descriptions.test.ts
PASS tests/unit/tool-choice-eval.test.ts
PASS tests/unit/audit-url-ssrf.test.ts
PASS tests/integration/http-server.test.ts (9.317 s)
PASS tests/integration/plugin.test.ts
PASS tests/unit/eval-detection.test.ts
PASS tests/unit/jsx-list-structure.test.ts
PASS tests/unit/get-rule.test.ts
PASS tests/unit/response-cap.test.ts
Test Suites: 16 passed, 16 total
Tests: 296 passed, 296 total
Snapshots: 0 total
Time: 70.632 s
Ran all test suites.

File: docs/audits/2026-10-04-mcp-validation/eval-performance.json Copy Chapter

{
"node": "v24.19.0",
"results": [
{
"bytes": 1022,
"scenario": "ordinary",
"p50Ms": 0.001,
"p95Ms": 0.001
},
{
"bytes": 1012,
"scenario": "comment",
"p50Ms": 2.11,
"p95Ms": 6.909
},
{
"bytes": 1023,
"scenario": "call",
"p50Ms": 0.714,
"p95Ms": 7.63
},
{
"bytes": 10234,
"scenario": "ordinary",
"p50Ms": 0.001,
"p95Ms": 0.001
},
{
"bytes": 10238,
"scenario": "comment",
"p50Ms": 8.879,
"p95Ms": 24.379
},
{
"bytes": 10235,
"scenario": "call",
"p50Ms": 2.62,
"p95Ms": 12.877
},
{
"bytes": 102396,
"scenario": "ordinary",
"p50Ms": 0.005,
"p95Ms": 0.006
},
{
"bytes": 102400,
"scenario": "comment",
"p50Ms": 83.86,
"p95Ms": 148.74
},
{
"bytes": 102397,
"scenario": "call",
"p50Ms": 38.172,
"p95Ms": 45.416
}
],
"rssMB": 189.9
}

File: docs/audits/2026-10-04-mcp-validation/hydration-before.txt Copy Chapter

FAIL before-tests/content/code/tests/code-tabs-hydration.test.cjs (13.545 s)
FAIL before-tests/rules/detail/tests/table-of-contents-hydration.test.cjs (7.798 s)
Test Suites: 2 failed, 2 total
Tests: 4 failed, 4 total
Snapshots: 0 total
Time: 35.725 s
Ran all test suites.

File: docs/audits/2026-10-04-mcp-validation/hydration-postfix.txt Copy Chapter

PASS validation-tests/content/code/tests/code-tabs.test.cjs (6.534 s)
PASS validation-tests/content/code/tests/code-tabs-hydration.test.cjs
PASS validation-tests/rules/detail/tests/table-of-contents-hydration.test.cjs (5.415 s)
Test Suites: 3 passed, 3 total
Tests: 8 passed, 8 total
Snapshots: 0 total
Time: 22.629 s
Ran all test suites.

File: docs/audits/2026-10-04-mcp-validation/performance.json Copy Chapter

{
"comparison": "MCP SDK 2.2.0 vs 2.3.0; identical current source and corpus",
"order": ["before-1", "after-1", "after-2", "before-2"],
"runs": {
"before-1": {
"node": "v24.19.0",
"modernClientSmoke": true,
"stages": [
{
"concurrency": 1,
"requests": 491,
"errors": 0,
"rps": 97.4,
"p50": 7.34,
"p95": 27.06,
"p99": 53.89,
"cpuMsPerRequest": 10.92,
"rssMB": 229.3
},
{
"concurrency": 8,
"requests": 944,
"errors": 0,
"rps": 187.8,
"p50": 35.76,
"p95": 93.67,
"p99": 121.79,
"cpuMsPerRequest": 6.394,
"rssMB": 248.3
},
{
"concurrency": 32,
"requests": 921,
"errors": 0,
"rps": 179,
"p50": 143.64,
"p95": 381.71,
"p99": 515.76,
"cpuMsPerRequest": 6.466,
"rssMB": 253.7
}
],
"holdout": [
{
"name": "eval in executable code",
"code": "const value = eval(userInput)",
"expected": true,
"actual": true
},
{
"name": "eval in comment",
"code": "// eval(userInput) is unsafe\nconst value = Number(userInput)",
"expected": false,
"actual": true
},
{
"name": "eval in string literal",
"code": "const example = "eval(userInput)"",
"expected": false,
"actual": true
},
{
"name": "indirect eval",
"code": "const value = (0, eval)(userInput)",
"expected": true,
"actual": false
}
]
},
"after-1": {
"node": "v24.19.0",
"modernClientSmoke": true,
"stages": [
{
"concurrency": 1,
"requests": 593,
"errors": 0,
"rps": 118.5,
"p50": 6.14,
"p95": 22.48,
"p99": 40.21,
"cpuMsPerRequest": 9.054,
"rssMB": 217.3
},
{
"concurrency": 8,
"requests": 893,
"errors": 0,
"rps": 177.3,
"p50": 33.07,
"p95": 111.82,
"p99": 215.23,
"cpuMsPerRequest": 6.662,
"rssMB": 245.4
},
{
"concurrency": 32,
"requests": 1218,
"errors": 0,
"rps": 239.1,
"p50": 111.78,
"p95": 275.41,
"p99": 432.26,
"cpuMsPerRequest": 4.854,
"rssMB": 247.6
}
],
"holdout": [
{
"name": "eval in executable code",
"code": "const value = eval(userInput)",
"expected": true,
"actual": true
},
{
"name": "eval in comment",
"code": "// eval(userInput) is unsafe\nconst value = Number(userInput)",
"expected": false,
"actual": true
},
{
"name": "eval in string literal",
"code": "const example = "eval(userInput)"",
"expected": false,
"actual": true
},
{
"name": "indirect eval",
"code": "const value = (0, eval)(userInput)",
"expected": true,
"actual": false
}
]
},
"after-2": {
"node": "v24.19.0",
"modernClientSmoke": true,
"stages": [
{
"concurrency": 1,
"requests": 484,
"errors": 0,
"rps": 96.1,
"p50": 7.6,
"p95": 27.68,
"p99": 53.88,
"cpuMsPerRequest": 10.803,
"rssMB": 203.4
},
{
"concurrency": 8,
"requests": 676,
"errors": 0,
"rps": 133.6,
"p50": 51.45,
"p95": 133.11,
"p99": 204.92,
"cpuMsPerRequest": 9.699,
"rssMB": 247.1
},
{
"concurrency": 32,
"requests": 854,
"errors": 0,
"rps": 155,
"p50": 156.99,
"p95": 376.29,
"p99": 1189.1,
"cpuMsPerRequest": 7.457,
"rssMB": 256.6
}
],
"holdout": [
{
"name": "eval in executable code",
"code": "const value = eval(userInput)",
"expected": true,
"actual": true
},
{
"name": "eval in comment",
"code": "// eval(userInput) is unsafe\nconst value = Number(userInput)",
"expected": false,
"actual": true
},
{
"name": "eval in string literal",
"code": "const example = "eval(userInput)"",
"expected": false,
"actual": true
},
{
"name": "indirect eval",
"code": "const value = (0, eval)(userInput)",
"expected": true,
"actual": false
}
]
},
"before-2": {
"node": "v24.19.0",
"modernClientSmoke": true,
"stages": [
{
"concurrency": 1,
"requests": 346,
"errors": 0,
"rps": 68.8,
"p50": 10.37,
"p95": 39.44,
"p99": 73.51,
"cpuMsPerRequest": 15.493,
"rssMB": 205.1
},
{
"concurrency": 8,
"requests": 449,
"errors": 0,
"rps": 89.1,
"p50": 75.39,
"p95": 209.79,
"p99": 285.12,
"cpuMsPerRequest": 13.621,
"rssMB": 238.6
},
{
"concurrency": 32,
"requests": 826,
"errors": 0,
"rps": 158.3,
"p50": 165.46,
"p95": 427.25,
"p99": 570.96,
"cpuMsPerRequest": 7.513,
"rssMB": 247
}
],
"holdout": [
{
"name": "eval in executable code",
"code": "const value = eval(userInput)",
"expected": true,
"actual": true
},
{
"name": "eval in comment",
"code": "// eval(userInput) is unsafe\nconst value = Number(userInput)",
"expected": false,
"actual": true
},
{
"name": "eval in string literal",
"code": "const example = "eval(userInput)"",
"expected": false,
"actual": true
},
{
"name": "indirect eval",
"code": "const value = (0, eval)(userInput)",
"expected": true,
"actual": false
}
]
}
}
}

File: docs/audits/2026-10-04-mcp-validation/public-modern.json Copy Chapter

{
"protocol": "2026-07-28",
"server": {
"name": "frontend-checklist-mcp",
"title": "Front-End Checklist",
"icons": [
{
"src": "https://frontendchecklist.io/favicon.svg",
"mimeType": "image/svg+xml",
"sizes": ["any"]
}
],
"version": "2.0.0",
"websiteUrl": "https://frontendchecklist.io/en/mcp"
},
"toolCount": 11,
"searchError": false,
"search": [
{
"type": "text",
"text": "{\n "rules": [\n {\n "slug": "avoid-eval",\n "title": "Never use eval() or unsafe dynamic code execution",\n "priority": "critical",\n "categories": [\n "javascript"\n ],\n "primaryCategory": "javascript"\n },\n {\n "slug": "color-contrast",\n "title": "Meet minimum color contrast ratios",\n "priority": "high",\n "categories": [\n "accessibility"\n ],\n "primaryCategory": "accessibility"\n },\n {\n "slug": "picture-element",\n "title": "Use with an fallback",\n "priority": "high",\n "categories": [\n "images"\n ],\n "primaryCategory": "images"\n }\n ],\n "nextCursor": "eyJvZmZzZXQiOjN9",\n "totalCount": 66\n}"
}
]
}

File: docs/audits/2026-10-04-mcp-validation/report.md Copy Chapter

MCP maintenance validation — 4 October 2026

Tracked in DAV-614, following dependency maintenance DAV-598. This report records local validation before publication. Commit/push verification is tracked in DAV-645. Production smoke checks exercise the deployed service, not these fixes.

Findings and fixes Copy Chapter

1. The POST request limit trusted Content-Length. A chunked request or inaccurate header could bypass the 100 KiB limit. apps/web/app/api/mcp/request-body.ts now counts bytes while reading, cancels oversized streams, and parses only bounded input. The route returns 413 for oversized input and 400 for malformed JSON. Tests cover absent/inaccurate lengths, multibyte UTF-8, chunk cancellation, malformed input and the exact limit.
2. Response caching could return the wrong envelope or skip transport validation. The old 32-bit hash collides for otherwise identical tools/list requests with IDs 1r and 30. SHA-256 now hashes the complete cache input. That input includes transport headers, so a successful request cannot prime a response subsequently returned to a request with invalid Accept or different protocol context. A route regression primes the cache, then verifies that Accept: text/plain is still rejected with 406.
3. The review detector had quality gaps, now fixed locally. The independent four-case challenge detects executable eval(userInput), incorrectly flags the same text in a comment and string, and misses (0, eval)(userInput). This existed with both SDK versions. DAV-619 records the parser-based remediation. Comments and strings no longer trigger this check, and common indirect, optional, global and bound eval calls are detected. This is a source fix beyond the dependency upgrade.
4. Production rule pages emit React error 418. Two browser contexts reproduced the hydration error on /rules/images/alt-text, including a fresh context before any progress interaction. Local SSR regression tests establish a DOM-dependent table of contents as a hydration mismatch: the server renders no navigation, while the first client render adds navigation. Code-tab selection also read browser storage/hash/context during the initial render. Both now use deterministic initial state and apply browser state in effects; the sidebar remounts on rule navigation. These local fixes have not been deployed. DAV-621 holds this separate application investigation. See browser error evidence and page capture.