name: vibecode-production-qa-validator description: "13-phase production QA for fullstack Next.js apps: build verification, SEO tags, OG images, favicon, route regression, API auth, page speed, lazy load, vulnerability scan, UI/UX cards, error boundaries, database, secure rendering, and cleanup." category: devops risk: critical source: self source_type: self date_added: "2026-05-31" author: Whoisabhishekadhikari tags: [qa, nextjs, production, deployment, seo, authentication, api, performance, favicon, cleanup, lighthouse, database, security, ui-ux] tools: [claude, cursor, gemini, claude-code, opencode] version: 2.0.0

Production QA Validator

Use the applicable phases in order and record evidence for each as passed, failed, incomplete or not applicable with a reason. Missing tooling, no tests, failed network calls and unperformed manual checks are incomplete, never success. Confirm project scripts, versions, approved URLs/methods, request limits, credentials and mutation boundaries before running. Builds/tests/lint/plugins can execute project code, write caches or reach services; they are not inherently read-only. Do not install hooks or overwrite existing config without authorization.

When to Use

• Use before shipping or promoting a fullstack Next.js app to production.
• Use after large UI, SEO, auth, API, database, or dependency changes need a concrete launch-readiness pass.
• Use when you need a compact command-driven checklist for build, route, metadata, performance, security, and cleanup checks.

export PROD_URL="https://yourdomain.com"
export QA_AUTH_HEADER=""       # optional: "Bearer eyJ..."
export PAGESPEED_API_KEY=""    # optional: for auto PageSpeed API

Evidence and a Bounded Route Check

The former consolidated qa:* runner returned successful exit codes after warnings, hid tool/network failures and inferred security from grep matches. It has been removed; a checklist is not an implemented automated gate. Use the project's actual checks and parse structured outputs. Keep raw logs private and redact secrets rather than echoing matched credential lines.

# Bash, approved staging target only; expect the exact documented status.
qa_route() {
  local route="$1" expected="$2" code
  code=$(curl --silent --show-error --max-time 15 --connect-timeout 5 \
    --output /dev/null --write-out '%{http_code}' "$PROD_URL$route") || return 1
  printf '%s %s\n' "$code" "$route"
  [ "$code" = "$expected" ]
}
qa_route / 200
qa_route /api/protected 401  # choose401/403 from the actual contract

Do not follow redirects carrying credentials to other origins. A status check proves only that response, not content, authorization, availability, SEO or a complete workflow. Auth probes need real configured endpoints and correct methods; never call logout/login mutations indiscriminately in production. Validate object/tenant isolation with owned synthetic accounts and explicit negative cases.

Phase 1: Code Integrity

• [ ] The project's pinned typecheck script
• [ ] The project's pinned lint script (flags differ by ESLint version)
• [ ] npm test # use the actual runner; zero discovered tests is incomplete

Phase 2: Build Verification

• [ ] npm run build succeeds
• [ ] Verify intended static/dynamic behavior; dynamic rendering is valid for many SEO pages
• [ ] Build log has no errors

Phase 3: API Session & Authentication

• [ ] Auth endpoints respond (login, session, logout)
• [ ] Protected routes return 401/403
• [ ] Session cookie: HttpOnly + Secure + SameSite
• [ ] Cookie not expired, Path/Domain correct
• [ ] No rate limiting bypass

Phase 4: Route Regression

• [ ] Core pages, sitemap, robots.txt all 200
• [ ] URLs use kebab-case, no duplicate slugs
• [ ] robots.txt allows indexing
• [ ] Sitemap XML valid, all URLs resolve 200

Phase 5: SEO — Tags, Images, Favicon, Slugs

• [ ] <title> 30–60 chars, unique per page
• [ ] <meta name="description"> in raw HTML
• [ ] og:title matches <title>, og:url matches canonical
• [ ] og:image uses the target platform's supported dimensions/format, absolute URL, loads 200
• [ ] twitter:card = summary_large_image
• [ ] Canonical self-referencing, no duplicates
• [ ] /favicon.ico 200, apple-touch-icon present
• [ ] hreflang tags if multilingual
• [ ] JSON-LD structured data present
• [ ] Slugs are stable/readable and preserve existing redirects; no arbitrary stop-word ban

Phase 6: API Route Behavior

• [ ] Correct status codes + Content-Type
• [ ] Errors return consistent JSON { error, message }
• [ ] Response latency meets the measured route-specific SLO
• [ ] CORS headers correct (if cross-origin)

Phase 7: Git Hygiene

• [ ] No secrets/credentials in diff
• [ ] No .next/node_modules staged
• [ ] Commit: type(scope): message

Phase 8: Post-Deployment Smoke Test

• [ ] Homepage 200, key pages 200
• [ ] OG image loads 200
• [ ] No console errors (manual)
• [ ] Auth flow works (manual)

Phase 9: Page Speed, Lazy Load & Bundles

• [ ] Lighthouse ≥ 90 (Perf, A11y, SEO)
• [ ] Record lab/field conditions; assess field LCP≤2.5s, INP≤200ms and CLS≤0.1 at the75th percentile
• [ ] Below-fold images may lazy-load; prioritize the LCP/above-fold image
• [ ] Dynamic imports for heavy components
• [ ] Largest JS chunk < 200KB gzipped
• [ ] font-display: swap, no FOIT
• [ ] Total page weight < 1MB

Phase 10: Cleanup & Vulnerability Scan

• [ ] npm prune, depcheck — no unused deps
• [ ] No console.log/debugger in staged code
• [ ] npm audit — zero critical/high vulnerabilities
• [ ] No eval/new Function/document.write
• [ ] TODOs resolved

Phase 11: UI/UX — Cards, Animation, Error Boundaries

• [ ] Cards: equal height grid, no overlap, text ellipsis, responsive (1→2→3 col)
• [ ] No horizontal scroll at any viewport (320–1440px)
• [ ] Images: consistent aspect-ratio + object-fit: cover
• [ ] Touch targets ≥ 44×44px
• [ ] Animations use transform+opacity only (not layout props)
• [ ] prefers-reduced-motion respected
• [ ] Error boundaries at root + route level (app/error.tsx, app/global-error.tsx)
• [ ] app/not-found.tsx and app/loading.tsx exist
• [ ] All client fetches show loading + error + empty states
• [ ] Buttons: hover, focus-visible, active, disabled, loading states
• [ ] Forms prevent repeat submissions and server writes enforce atomic idempotency where needed

Phase 12: Database & Data Layer

• [ ] Connection pool configured (no starvation)
• [ ] Schema in sync with migrations
• [ ] Indexes and batching justified by actual query plans/workload; measure N+1
• [ ] No hardcoded DB credentials in source
• [ ] No raw SQL injection risk
• [ ] No sensitive data leaked in API responses
• [ ] Migrations are idempotent

Phase 13: Secure Data Rendering

• [ ] No secrets/tokens in client source or localStorage
• [ ] Use framework escaping or context-appropriate sanitization for untrusted HTML; sanitization is not a universal safe sink
• [ ] API errors don't leak stack traces
• [ ] Enforce object/tenant authorization regardless of identifier format; UUIDs are not access control
• [ ] User emails masked in UI
• [ ] NEXT_PUBLIC_ vars contain no secrets

Pre-Commit Hook

Use the project's existing hook manager and preserve installed hooks. Configure only after authorization; local hooks can be bypassed and do not replace CI.

CI/CD (GitHub Actions)

Template only: select pinned compatible tools/actions, the actual test runner and explicit permissions. Do not enable production probes or pass secrets to untrusted PR code.

name: QA
on: [push, pull_request]
jobs:
  qa:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: npm ci
      - run: npx tsc --noEmit
      - run: npm run lint
      - run: npm test # configure zero-test discovery to fail
      - run: npm run build

Best Practices

Common Pitfalls

Security Notes

• Project commands can mutate state or execute arbitrary lifecycle/tool code; inspect them and use an isolated approved environment.
• PROD_URL and QA_AUTH_HEADER only for environments you own
• Use a reviewed secret scanner with redacted output; missing matches do not prove absence. Validate dependencies from structured audit results and propagate command failures.
• Auth tests with real credentials against prod is destructive — use staging

Limitations

• Passing all phases reduces risk but doesn't eliminate production bugs
• Some checks depend on project-specific tooling (Prisma, NextAuth, etc.)
• Manual UX testing still required for critical user journeys
• SEO checks verify raw HTML only — not social preview rendering
• Route checks verify status codes, not content correctness

Master Checklist

Phase 1: Code

• [ ] tsc --noEmit, eslint, npm test pass

Phase 2: Build

• [ ] npm run build succeeds, no errors, pages static

Phase 3: Auth

• [ ] Endpoints respond, protected routes denied, secure cookies

Phase 4: Routes

• [ ] All core pages 200, sitemap valid, robots.txt correct

Phase 5: SEO

• [ ] title, description, og:*, twitter:card, canonical, favicon, slugs

Phase 6: API

• [ ] Status, Content-Type, consistent errors, timing

Phase 7: Git

• [ ] No secrets, no artifacts, conventional commit

Phase 8: Smoke

• [ ] Homepage + key pages 200, og:image loads

Phase 9: Speed

• [ ] Lighthouse ≥ 90, lazy images, dynamic imports, font-display: swap

Phase 10: Clean

• [ ] No vulns, no debug artifacts, unused deps pruned

Phase 11: UI/UX

• [ ] Cards responsive, error boundaries, button states, reduced-motion

Phase 12: Database

• [ ] Indexes, no N+1, no hardcoded URLs, no sensitive leaks

Phase 13: Secure Rendering

• [ ] No secrets in client, no XSS, no stack leaks, UUIDs