qa-workflow-cc 1.0.0

package/skills/qa/templates/nielsen-heuristics.md

@@ -0,0 +1,274 @@
+# Nielsen's 10 Usability Heuristics — QA Evaluation Rubric
+
+Reference: nngroup.com/articles/ten-usability-heuristics/
+
+## Scoring Scale
+
+| Score | Level | Definition |
+|-------|-------|-----------|
+| 5 | Excellent | Exceeds expectations, delightful UX, no issues found |
+| 4 | Good | Meets standards with minor gaps, no usability barriers |
+| 3 | Acceptable | Functional but room for improvement, minor friction points |
+| 2 | Below Standard | Noticeable UX issues affecting task completion |
+| 1 | Poor | Significant usability problems preventing effective use |
+
+---
+
+## H1: Visibility of System Status
+
+**Principle:** The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
+
+### What to Check
+
+| Check | Expected Behavior |
+|-------|-------------------|
+| Loading states (skeleton/spinner) | All data fetches show loading indicators |
+| Progress indicators | Multi-step operations show progress (upload, save) |
+| Action feedback | Button presses, form submissions give immediate feedback |
+| Real-time updates | Live data shows connection status (online/offline) |
+| Error states | Failures show clear error with recovery option |
+| Empty states | Empty collections show helpful CTA messaging |
+| Network status | Offline detection with graceful degradation |
+
+### Scoring Guide
+- 5: All async operations show loading, all actions give immediate feedback, real-time status shown
+- 4: Most operations show status, minor gaps (e.g., no progress on batch uploads)
+- 3: Loading states exist but inconsistent, some actions lack feedback
+- 2: Major operations show no loading state, user unsure if action worked
+- 1: No loading indicators, no action feedback, user left guessing
+
+---
+
+## H2: Match Between System and Real World
+
+**Principle:** The system should speak the user's language, with words, phrases, and concepts familiar to the user, rather than system-oriented terms.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Terminology | Domain-specific language familiar to target users |
+| Workflow mapping | UI flow matches real-world process order |
+| Error messages | Human-readable, not technical codes |
+| Navigation labels | Plain language describing destinations |
+| Date formats | Relative or locale-appropriate formatting |
+| Currency/numbers | Properly formatted with locale conventions |
+| Status labels | Business-meaningful state names |
+
+### Scoring Guide
+- 5: All terminology matches target user vocabulary, natural workflow mapping
+- 4: Language mostly appropriate, occasional technical terms
+- 3: Mix of user-friendly and technical language
+- 2: Frequent use of developer jargon or database terms
+- 1: Interface feels like a database admin tool
+
+---
+
+## H3: User Control and Freedom
+
+**Principle:** Users often choose system functions by mistake and need a clearly marked "emergency exit" to leave the unwanted state without going through an extended dialogue.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Modal dismiss | All modals have X button AND backdrop/escape dismiss |
+| Back navigation | Back button works on all screens |
+| Undo actions | State changes can be reversed |
+| Cancel operations | All forms have Cancel option always available |
+| Destructive actions | Confirmation dialog before delete/archive |
+| Form preservation | Leaving partially filled form shows warning |
+| Filter/search reset | Clear all filters button when filters active |
+
+### Scoring Guide
+- 5: Every action is reversible, clear exits everywhere, form state preserved
+- 4: Most actions reversible, modals dismissible, minor gaps
+- 3: Some irreversible actions without warning, back nav mostly works
+- 2: Significant actions can't be undone, modal traps exist
+- 1: Users get stuck frequently, no undo/exit paths
+
+---
+
+## H4: Consistency and Standards
+
+**Principle:** Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Design system | Consistent use of component library across all screens |
+| Color palette | Consistent color usage per design tokens |
+| Typography | Consistent font sizes and weights |
+| Spacing | Consistent use of spacing tokens |
+| Visual style | Consistent border, shadow, and corner radius patterns |
+| Button hierarchy | Primary/Secondary/Tertiary consistent across screens |
+| Icon usage | Consistent icon library, same icon for same action |
+| Navigation patterns | Same navigation behavior across all sections |
+
+### Scoring Guide
+- 5: Perfect design system adherence, visually cohesive, no inconsistencies
+- 4: Mostly consistent, 1-2 minor deviations from the design system
+- 3: Noticeable inconsistencies (mixed button styles, varying spacing)
+- 2: Significant style mixing, feels like different apps
+- 1: No consistent design system applied
+
+---
+
+## H5: Error Prevention
+
+**Principle:** Even better than good error messages is a careful design which prevents a problem from occurring in the first place.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Form validation | Inline validation before submission |
+| Required fields | Clear marking of required vs optional |
+| Destructive confirmation | Confirmation dialog before delete/archive |
+| Input constraints | Format masks, character limits enforced |
+| Duplicate prevention | Warning when creating duplicate entries |
+| Data loss prevention | Unsaved changes warning on navigation |
+| Double-submit prevention | Disable buttons during submission |
+
+### Scoring Guide
+- 5: Comprehensive input validation, smart defaults, impossible to make critical errors
+- 4: Good validation, most destructive actions confirmed, minor gaps
+- 3: Basic validation exists, some destructive actions lack confirmation
+- 2: Missing validation on important fields, easy to make mistakes
+- 1: No input validation, destructive actions have no safeguards
+
+---
+
+## H6: Recognition Rather Than Recall
+
+**Principle:** Minimize the user's memory load by making objects, actions, and options visible.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Status visualization | Visual indicators show state without reading text |
+| Recent actions | Activity feed or history shows what happened |
+| Search | Global or contextual search for finding items |
+| Contextual actions | Action buttons visible on each item |
+| Active filters | Active filters shown as dismissible chips/tags |
+| Navigation state | Current location highlighted in nav |
+| Breadcrumbs | Deep hierarchies show navigation path |
+
+### Scoring Guide
+- 5: All information visible at a glance, zero memorization required
+- 4: Most information visible, occasional need to navigate for details
+- 3: Key info visible but some important details require navigation
+- 2: Users frequently need to remember IDs, names, or navigation paths
+- 1: Heavy reliance on user memory, hidden functionality
+
+---
+
+## H7: Flexibility and Efficiency of Use
+
+**Principle:** Accelerators — unseen by the novice user — may often speed up the interaction for the expert user.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Quick actions | Fast paths for common tasks |
+| Shortcuts | Keyboard shortcuts or gestures for power users |
+| Bulk operations | Select multiple items for batch actions |
+| Search/filter | Quick filtering to reduce cognitive load |
+| Customization | User-configurable views or preferences |
+| Recent items | Quick access to recently viewed/edited items |
+| Smart defaults | Pre-filled fields based on context |
+
+### Scoring Guide
+- 5: Multiple efficiency features, novice and expert workflows both smooth
+- 4: Good shortcuts exist, most common tasks have fast paths
+- 3: Basic efficiency features, some common tasks require too many steps
+- 2: No shortcuts, every task requires full navigation
+- 1: Excessive steps for common operations
+
+---
+
+## H8: Aesthetic and Minimalist Design
+
+**Principle:** Dialogues should not contain information which is irrelevant or rarely needed.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Information density | Items show key info only, details on interaction |
+| Visual hierarchy | Clear primary/secondary/tertiary content |
+| White space | Adequate breathing room between elements |
+| Progressive disclosure | Details hidden behind expand/tap |
+| No visual clutter | Clean backgrounds, focused content |
+| Meaningful visuals | Icons add meaning, not decoration |
+
+### Scoring Guide
+- 5: Clean, focused UI with perfect information hierarchy, nothing unnecessary
+- 4: Mostly clean, minor visual clutter or unnecessary elements
+- 3: Some screens cluttered, information hierarchy unclear in places
+- 2: Significant visual noise, hard to focus on key information
+- 1: Overwhelming amount of information, no clear hierarchy
+
+---
+
+## H9: Help Users Recognize, Diagnose, and Recover from Errors
+
+**Principle:** Error messages should be expressed in plain language, precisely indicate the problem, and constructively suggest a solution.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Error messages | Plain language, not technical codes |
+| Recovery actions | "Try again" button, "Go back" option |
+| Form errors | Inline under the specific field that failed |
+| Network errors | Friendly message with retry option |
+| Auth errors | Clear session expired message with re-login path |
+| Empty results | Suggest adjusting search/filter criteria |
+| Partial failures | Show what succeeded and offer retry for failures |
+
+### Scoring Guide
+- 5: All errors are user-friendly with clear recovery paths
+- 4: Most errors handled gracefully, minor cases show generic messages
+- 3: Error handling exists but messages sometimes unhelpful
+- 2: Raw error codes or generic "Something went wrong" frequently
+- 1: Errors cause blank screens, crashes, or incomprehensible messages
+
+---
+
+## H10: Help and Documentation
+
+**Principle:** Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation.
+
+### What to Check
+
+| Check | Expected |
+|-------|----------|
+| Help pages | FAQ or help section accessible from the app |
+| Onboarding | First-use guidance for new users |
+| Tooltips | Hover/tap hints on non-obvious features |
+| Contextual help | Explanation near complex features |
+| Contact support | Easy way to reach help (phone, email, chat) |
+| Empty state guidance | "Here's how to get started" messaging |
+
+### Scoring Guide
+- 5: Comprehensive help system, contextual guidance, self-serve documentation
+- 4: Good help content, most features have explanation, minor gaps
+- 3: Basic help exists (FAQ), some features lack explanation
+- 2: Minimal help content, users left to figure things out
+- 1: No help system, no guidance, users are on their own
+
+---
+
+## Aggregation
+
+Calculate the overall UX score as the average of all 10 heuristic scores per app.
+
+| App | H1 | H2 | H3 | H4 | H5 | H6 | H7 | H8 | H9 | H10 | **Avg** |
+|-----|----|----|----|----|----|----|----|----|----|----|---------|
+| {app_name} | /5 | /5 | /5 | /5 | /5 | /5 | /5 | /5 | /5 | /5 | **/5** |
+
+**Exit criteria target: >= 3.5 / 5.0 average across all apps.**

package/skills/qa/templates/performance-benchmarks-base.md

@@ -0,0 +1,321 @@
+# Performance Benchmarks (Generic Template)
+
+Category B template for QA bootstrapping. Contains universal performance standards (Core Web Vitals, Lighthouse) with `{{variable}}` placeholders for project-specific targets.
+
+## Variables
+
+| Variable | Description | Example |
+|----------|-------------|---------|
+| `{{appTargets}}` | Per-app Lighthouse score targets table | Web App >= 90, Mobile PWA >= 80 |
+| `{{apiEndpoints}}` | Project-specific API endpoint benchmarks | user.list < 150ms, order.create < 300ms |
+| `{{bundleBudgets}}` | Per-app and per-page bundle size budgets | Web App < 400KB gzip first load |
+| `{{criticalPaths}}` | Critical user journey page-level budgets | Login page < 50KB JS, Dashboard < 80KB JS |
+| `{{projectName}}` | Name of the project | TruLine, Acme CRM |
+
+---
+
+## Core Web Vitals Targets (Universal)
+
+These targets apply to ALL web projects. They are based on Google's Core Web Vitals thresholds (web.dev/vitals) and represent the standard for "Good" user experience.
+
+| Metric | Good | Needs Improvement | Poor | Our Target |
+|--------|------|-------------------|------|-----------|
+| **LCP** (Largest Contentful Paint) | < 2.5s | 2.5s - 4.0s | > 4.0s | < 2.5s |
+| **INP** (Interaction to Next Paint) | < 200ms | 200ms - 500ms | > 500ms | < 200ms |
+| **CLS** (Cumulative Layout Shift) | < 0.1 | 0.1 - 0.25 | > 0.25 | < 0.1 |
+| **FCP** (First Contentful Paint) | < 1.8s | 1.8s - 3.0s | > 3.0s | < 2.0s |
+| **TTFB** (Time to First Byte) | < 800ms | 800ms - 1800ms | > 1800ms | < 800ms |
+
+### How to Measure
+
+| Method | Tool | When to Use |
+|--------|------|-------------|
+| Lab data | Lighthouse CLI | During QA testing, CI/CD |
+| Lab data | Chrome DevTools Performance tab | During development |
+| Field data | Chrome UX Report (CrUX) | Post-launch monitoring |
+| Field data | web.dev/measure | Quick spot checks |
+| Synthetic monitoring | WebPageTest | Detailed waterfall analysis |
+
+---
+
+## Lighthouse Score Targets (Universal)
+
+These minimum thresholds are universal. Projects may set higher targets but should never go below these floors.
+
+| Category | Floor (Minimum) | Good Target | Stretch Goal |
+|----------|----------------|-------------|-------------|
+| Performance | 80 | 90+ | 95+ |
+| Accessibility | 85 | 95+ | 100 |
+| Best Practices | 80 | 90+ | 95+ |
+| SEO | 80 | 90+ | 95+ |
+
+### Per-App Targets
+
+{{appTargets}}
+
+<!-- BOOTSTRAP INSTRUCTIONS:
+     Replace {{appTargets}} with a table of per-app Lighthouse targets.
+     Adjust targets based on app type (marketing sites should score higher on SEO,
+     PWAs higher on performance, admin panels can be slightly lower).
+
+     Example:
+
+| App | Performance | Accessibility | Best Practices | SEO |
+|-----|------------|---------------|----------------|-----|
+| Web Dashboard (app.example.com) | >= 80 | >= 85 | >= 80 | N/A |
+| Client Portal (portal.example.com) | >= 80 | >= 90 | >= 85 | >= 80 |
+| Marketing Site (example.com) | >= 85 | >= 90 | >= 85 | >= 90 |
+| Mobile PWA (m.example.com) | >= 75 | >= 85 | >= 80 | N/A |
+
+     Notes on target selection:
+     - Marketing/public sites: Higher performance and SEO targets
+     - Authenticated apps: Can relax SEO, focus on performance and a11y
+     - Mobile/PWA: May have slightly lower performance floor due to constraints
+     - Admin/internal tools: Can relax all targets slightly
+-->
+
+---
+
+## API Response Time Budgets (Universal Tiers)
+
+These tiers apply to most backend APIs regardless of framework (REST, GraphQL, tRPC, gRPC).
+
+| Endpoint Category | p50 | p95 | p99 | Timeout |
+|-------------------|-----|-----|-----|---------|
+| **Simple reads** (get by ID, list with pagination) | < 100ms | < 300ms | < 500ms | 5s |
+| **Write operations** (create, update, delete) | < 200ms | < 500ms | < 1s | 10s |
+| **Complex queries** (aggregations, joins, analytics) | < 500ms | < 1.5s | < 3s | 15s |
+| **AI/ML operations** (generation, classification, embedding) | < 3s | < 8s | < 15s | 30s |
+| **File operations** (upload signature, download URL) | < 200ms | < 500ms | < 1s | 10s |
+| **Webhook processing** (inbound webhook handlers) | < 1s | < 3s | < 5s | 30s |
+| **Authentication** (token validation, session check) | < 50ms | < 150ms | < 300ms | 5s |
+| **Search** (full-text, fuzzy, vector similarity) | < 200ms | < 800ms | < 2s | 10s |
+
+### Project-Specific Endpoint Benchmarks
+
+{{apiEndpoints}}
+
+<!-- BOOTSTRAP INSTRUCTIONS:
+     Replace {{apiEndpoints}} with a table of your project's specific API endpoints
+     and their budgets. Map each endpoint to the appropriate tier above, then
+     set specific budgets based on expected query complexity.
+
+     Example:
+
+| Endpoint | Operation | Category | Budget (p95) |
+|----------|-----------|----------|-------------|
+| user.list | Paginated list (20 items) | Simple read | < 150ms |
+| user.create | Create user + send welcome email | Write | < 300ms |
+| user.get | Single user with relations | Simple read | < 100ms |
+| order.list | Orders with line items | Complex query | < 500ms |
+| search.query | Full-text product search | Search | < 800ms |
+| report.generate | Monthly analytics report | Complex query | < 1.5s |
+| ai.summarize | AI-generated summary | AI/ML | < 8s |
+| upload.getSignature | Cloud storage signature | File operation | < 100ms |
+
+     Tips:
+     - Start with the tier defaults, then adjust per endpoint
+     - Endpoints with JOINs across 3+ tables: use "Complex query" tier
+     - Endpoints that trigger async work: measure only the sync portion
+     - AI endpoints: budget is for the synchronous response, not background processing
+-->
+
+---
+
+## Bundle Size Budgets
+
+### Per-App Budgets
+
+{{bundleBudgets}}
+
+<!-- BOOTSTRAP INSTRUCTIONS:
+     Replace {{bundleBudgets}} with your project's per-app bundle size budgets.
+
+     Example:
+
+| App | Total JS (gzip) | First Load JS (gzip) | Max Single Chunk (gzip) |
+|-----|-----------------|---------------------|------------------------|
+| Web Dashboard | < 500KB | < 200KB | < 100KB |
+| Client Portal | < 400KB | < 150KB | < 80KB |
+| Marketing Site | < 300KB | < 100KB | < 60KB |
+| Mobile App (OTA bundle) | < 5MB | N/A | < 500KB |
+
+     Guidelines for setting budgets:
+     - Total JS: Sum of all JS chunks loaded for the heaviest page
+     - First Load JS: Shared chunks + page-specific chunk for initial route
+     - Max Single Chunk: Largest individual chunk (prevents code-split failures)
+     - Mobile OTA: Over-the-air update size (Expo/React Native)
+-->
+
+### Critical Path Page Budgets
+
+{{criticalPaths}}
+
+<!-- BOOTSTRAP INSTRUCTIONS:
+     Replace {{criticalPaths}} with per-page budgets for your most important user journeys.
+
+     Example:
+
+| Page | JS Budget (gzip) | CSS Budget (gzip) | Notes |
+|------|------------------|--------------------|-------|
+| Login/Auth | < 40KB | < 10KB | Must load fast on slow connections |
+| Main Dashboard | < 80KB | < 20KB | First screen after login |
+| List View (primary) | < 80KB | < 20KB | Most visited page |
+| Detail View | < 60KB | < 15KB | Accessed from list |
+| Settings | < 50KB | < 10KB | Low-traffic, can be lazy loaded |
+| Marketing Home | < 50KB | < 15KB | Must score high on Lighthouse |
+
+     Tips:
+     - Identify the 5-8 most important pages by traffic/business value
+     - Auth pages and landing pages need the tightest budgets
+     - Pages behind auth can be slightly larger (cached after first load)
+     - Use route-based code splitting to keep individual page bundles small
+-->
+
+---
+
+## Database Performance (Universal)
+
+These query performance budgets apply to relational databases (PostgreSQL, MySQL, etc.).
+
+| Query Pattern | Budget | Alert If Exceeds |
+|--------------|--------|-----------------|
+| Simple SELECT by primary key | < 5ms | > 50ms |
+| SELECT with WHERE + LIMIT (indexed) | < 20ms | > 200ms |
+| JOIN across 2 tables | < 50ms | > 500ms |
+| JOIN across 3+ tables | < 100ms | > 1s |
+| Aggregation (COUNT, SUM, AVG) | < 100ms | > 1s |
+| Full-text search (tsvector/GIN) | < 200ms | > 2s |
+| Vector similarity search (pgvector/HNSW) | < 300ms | > 3s |
+| Bulk INSERT (100 rows) | < 200ms | > 2s |
+| Bulk UPDATE (100 rows) | < 200ms | > 2s |
+| Transaction (2-3 operations) | < 100ms | > 1s |
+
+### Database Health Indicators
+
+| Metric | Healthy | Warning | Critical |
+|--------|---------|---------|----------|
+| Connection pool utilization | < 50% | 50-80% | > 80% |
+| Slow query count (> 1s) per minute | 0 | 1-5 | > 5 |
+| Active connections | < 50% of max | 50-80% | > 80% |
+| Cache hit ratio | > 99% | 95-99% | < 95% |
+| Index usage ratio | > 95% | 80-95% | < 80% |
+| Deadlock count per hour | 0 | 1-2 | > 2 |
+
+---
+
+## Real-Time Performance
+
+{{realtimeTargets}}
+
+<!-- BOOTSTRAP INSTRUCTIONS:
+     Replace {{realtimeTargets}} with your project's real-time communication targets,
+     or remove this section entirely if your project has no real-time features.
+
+     For WebSocket-based systems (Socket.IO, ws, Pusher, etc.):
+
+| Metric | Target |
+|--------|--------|
+| Connection establishment | < 500ms |
+| Message delivery latency (client-to-client) | < 100ms |
+| Typing indicator latency | < 50ms |
+| Reconnection time after disconnect | < 2s |
+| Max concurrent connections per instance | 1000 |
+| Message throughput per second | > 500 |
+
+     For Server-Sent Events (SSE):
+
+| Metric | Target |
+|--------|--------|
+| Connection establishment | < 300ms |
+| Event delivery latency | < 200ms |
+| Reconnection time | < 3s |
+
+     For polling-based systems:
+
+| Metric | Target |
+|--------|--------|
+| Poll interval | 5-30s depending on data freshness needs |
+| Poll response time | < 200ms |
+| Data staleness tolerance | < 60s |
+
+     If your project has no real-time features, delete this entire section.
+-->
+
+---
+
+## Image and Media Performance (Universal)
+
+| Metric | Target | Notes |
+|--------|--------|-------|
+| Thumbnail load (< 50KB source) | < 500ms | Use CDN with transforms |
+| Full-size image load (< 5MB source) | < 2s | Lazy load below fold |
+| Image upload (5MB file) | < 5s | Show progress indicator |
+| Batch upload (10 files) | < 30s | Parallel uploads with progress |
+| Video thumbnail generation | < 2s | Server-side or CDN |
+| CDN cache hit ratio | > 90% | Monitor via CDN dashboard |
+
+### Image Optimization Checklist
+
+| Practice | Required |
+|----------|----------|
+| Serve WebP/AVIF with fallback | Yes |
+| Responsive srcset for viewport sizes | Yes |
+| Lazy loading for below-fold images | Yes |
+| Width/height attributes to prevent CLS | Yes |
+| CDN for asset delivery | Yes |
+| Compression (quality 75-85 for photos) | Yes |
+| Maximum upload file size enforced | Yes |
+
+---
+
+## Test Performance Criteria
+
+For QA testing, map test IDs to measurement methods:
+
+| Test ID Prefix | What to Measure | How to Measure |
+|---------------|-----------------|----------------|
+| PERF-CWV-* | Core Web Vitals | Lighthouse CLI or web.dev/measure |
+| PERF-LH-* | Lighthouse category scores | `lighthouse` CLI with JSON output |
+| PERF-API-* | API response times | HTTP client timing (p50/p95/p99) |
+| PERF-BUNDLE-* | Bundle sizes | Build output analysis (next build, webpack stats) |
+| PERF-DB-* | Database query times | Query EXPLAIN ANALYZE or ORM query logging |
+| PERF-RT-* | Real-time latency | Round-trip timestamp comparison |
+| PERF-IMG-* | Image/media load times | Resource timing API or Lighthouse |
+| PERF-SEARCH-* | Search response times | API timing with representative queries |
+
+### Measurement Best Practices
+
+| Practice | Why |
+|----------|-----|
+| Measure p95 and p99, not just average | Averages hide tail latency |
+| Test with realistic data volumes | Empty databases are always fast |
+| Test on throttled connections (3G/4G) | Users are not always on broadband |
+| Measure cold start separately | First request after deploy is slower |
+| Run measurements 3+ times, take median | Reduces noise from outliers |
+| Test during simulated load | Single-user perf != concurrent perf |
+| Record baseline before changes | Need a comparison point for regressions |
+
+---
+
+## Performance Regression Prevention
+
+### CI/CD Integration Points
+
+| Gate | When | Blocks Deploy? |
+|------|------|---------------|
+| Bundle size check | Every PR | Yes, if > 10% increase |
+| Lighthouse CI | Every PR to main | Yes, if below floor |
+| API response time test | Pre-deploy | Yes, if p95 > budget |
+| Database migration timing | Schema changes | No, but flag if > 30s |
+
+### Monitoring Recommendations
+
+| What to Monitor | Tool Options | Alert Threshold |
+|----------------|-------------|-----------------|
+| Core Web Vitals (field) | CrUX, Vercel Analytics, Sentry | Any metric crosses "Needs Improvement" |
+| API latency (p95) | APM (Datadog, New Relic, Sentry) | > 2x budget for any endpoint |
+| Error rate | APM, Sentry | > 1% of requests |
+| Database slow queries | pg_stat_statements, query logging | Any query > 1s |
+| Memory usage | Infrastructure monitoring | > 80% of limit |
+| CPU usage | Infrastructure monitoring | Sustained > 70% |