@umacloud/knowledge 1.0.1

package/experts/frontend-lead/methodology.md

@@ -0,0 +1,178 @@
+---
+id: methodology
+title: Frontend Lead — Development Methodology
+domain: experts
+category: frontend-lead
+difficulty: intermediate
+tags: [architecture, client, component, error, experts, handling, management, methodology]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# Frontend Lead — Development Methodology
+
+## 前端/客户端标准库速查（按需查阅，`<platform>/01-standards/<id>`）
+
+**先看架构文档声明的目标平台**，再查对应标准照着做：
+
+- Web 通用：frontend-architecture-and-layering（feature 分包/数据访问层/状态分治）· web-framework-best-practices（React/Next App Router/Vue 官方）· forms-and-validation · admin-dashboard-and-crud（后台/CRUD）· i18n-and-localization · accessibility-standard（无障碍）· seo-and-web-vitals
+- 移动：mobile/mobile-app-standard + 设计 mobile/{ios-design-hig, android-material-design}
+- 鸿蒙：harmony/{harmonyos-arkts-standard, harmonyos-design}
+- 小程序：miniprogram/{miniprogram-standard, miniprogram-design}
+- 桌面：desktop/{desktop-app-standard, desktop-design}
+- 跨平台：cross-platform/{platform-selection-and-architecture, cross-platform-frameworks}
+- **UI 务必遵循目标平台的官方设计规范**（iOS HIG / Android Material 3 / HarmonyOS Design / 微信 WeUI / macOS·Windows），不要套 web 范式。
+
+## 结构第一：按功能分包 + 关注点分层（动手前先定骨架）
+
+商业级前端的第一要务是结构。详见标准《前端架构与分层标准》(`frontend/01-standards/frontend-architecture-and-layering`)，硬性底线：
+
+- **按 feature 分包**（不按类型）：`features/<x>/{api,components,hooks,stores,types,index.ts}`；跨 feature 只经对方 `index.ts` 引用，禁止深层 import；`utils/` 不是垃圾场，feature 相关的 helper 留在 feature 内。
+- **分层**：展示组件(dumb，纯 props→UI) ↔ 容器组件(取数+编排) ↔ 数据访问层(typed API，唯一出口) ↔ 领域逻辑(纯函数/hook)。
+- **数据访问隔离**：组件内**禁止裸 fetch/axios**，统一走 typed API 层；路径集中常量、与后端契约一致；每个视图处理 loading/error/empty 三态。
+- **状态三类分治**：服务端数据用 React Query/SWR（别用 Redux 手动管），全局态用 Zustand/Redux/Pinia，UI 态用本地 useState/ref。
+- **业务逻辑下沉**到纯函数/hook，JSX/模板只做声明式渲染，副作用在 hook 里并清理。
+- **红线**：组件裸 fetch、业务逻辑写在 JSX、按类型分大筐、巨型组件、只画 happy path 不处理三态、emoji 当功能图标、硬编码颜色。
+
+## Component Architecture
+
+### Component Categories
+1. **Primitives** (atoms): Button, Input, Badge, Avatar, Icon
+   - No business logic, only presentation
+   - Accept variants via props (size, color, disabled)
+   - Fully accessible (keyboard, ARIA)
+
+2. **Composites** (molecules): SearchBar, FormField, Card, Modal
+   - Combine 2-3 primitives
+   - May have internal state (open/closed, input value)
+   - Still reusable across features
+
+3. **Features** (organisms): LoginForm, DashboardHeader, UserList
+   - Business logic lives here
+   - Connect to API / state management
+   - Specific to one feature
+
+4. **Pages** (templates): /dashboard, /settings, /auth/login
+   - Compose features into a full layout
+   - Handle routing, auth guards, data fetching
+
+### Component File Structure
+```
+components/
+  Button/
+    Button.tsx        # component
+    Button.test.tsx   # unit tests
+    Button.stories.tsx # storybook (if used)
+    index.ts          # re-export
+```
+
+### Props Design Rules
+- Use interface, not inline types
+- Required props first, optional last
+- Sensible defaults for optional props
+- Event handlers: `onX` naming (onClick, onChange, onSubmit)
+- Children for composition, not deep prop drilling
+- No more than 7 props (split into smaller components if needed)
+
+## State Management
+
+### Where State Lives
+| State type | Storage | Example |
+|---|---|---|
+| UI state (local) | useState / ref | modal open, input value, accordion expanded |
+| Form state | form library | field values, validation, dirty/touched |
+| Server state | query cache (React Query / SWR) | API data, loading/error states |
+| Global app state | context / store | auth user, theme, locale |
+| URL state | search params / path | current page, filters, sort order |
+
+### Rules
+- Default to local state. Only lift when two+ components need it.
+- Server state is NOT client state — use a cache library, not Redux/Zustand for API data.
+- URL state for anything the user might bookmark or share.
+- Never store derived values — compute them on render.
+
+## API Client Pattern
+
+### Centralized fetch wrapper
+```typescript
+// lib/api.ts
+const API_BASE = process.env.NEXT_PUBLIC_API_URL;
+
+export async function apiFetch<T>(path: string, options?: RequestInit): Promise<T> {
+  const res = await fetch(`${API_BASE}${path}`, {
+    headers: {
+      'Content-Type': 'application/json',
+      ...getAuthHeader(),
+      ...options?.headers,
+    },
+    ...options,
+  });
+  if (!res.ok) {
+    const error = await res.json().catch(() => ({ message: res.statusText }));
+    throw new ApiError(res.status, error.message, error.details);
+  }
+  return res.json();
+}
+```
+
+### Per-resource API functions
+```typescript
+// api/users.ts
+export const usersApi = {
+  list: (params?: ListParams) => apiFetch<User[]>('/users', { params }),
+  get: (id: string) => apiFetch<User>(`/users/${id}`),
+  create: (data: CreateUser) => apiFetch<User>('/users', { method: 'POST', body: JSON.stringify(data) }),
+  update: (id: string, data: Partial<User>) => apiFetch<User>(`/users/${id}`, { method: 'PATCH', body: JSON.stringify(data) }),
+  delete: (id: string) => apiFetch<void>(`/users/${id}`, { method: 'DELETE' }),
+};
+```
+
+## Error Handling
+
+### Error Boundary (global)
+Catches rendering errors, shows fallback UI, reports to error tracking.
+
+### API Error Handling (per-request)
+```typescript
+try {
+  const data = await usersApi.create(formData);
+  // success: redirect or show toast
+} catch (error) {
+  if (error instanceof ApiError) {
+    if (error.status === 422) {
+      // validation: show field-level errors
+      setFieldErrors(error.details);
+    } else if (error.status === 409) {
+      // conflict: "email already exists"
+      showToast('error', error.message);
+    } else {
+      // other API error
+      showToast('error', 'Something went wrong');
+    }
+  } else {
+    // network error
+    showToast('error', 'Unable to connect to server');
+  }
+}
+```
+
+### Loading States
+- Skeleton screens for initial load (not spinners)
+- Inline loading for mutations (button shows spinner, text changes to "Saving...")
+- Optimistic updates for fast-feeling UI (update UI first, then sync with server)
+
+### Empty States
+Every list/table/grid must have:
+- First-time empty: "No items yet. Create your first X."
+- Filtered empty: "No results match your filters."
+- Error empty: "Failed to load. [Retry button]"
+
+## Performance Checklist
+
+- [ ] Images: lazy loaded, responsive sizes, modern format (WebP/AVIF)
+- [ ] Fonts: preloaded, `font-display: swap`, subset if possible
+- [ ] JavaScript: code-split by route, tree-shaken, no unused dependencies
+- [ ] CSS: purged unused styles, critical CSS inlined
+- [ ] API calls: deduplicated (cache library), prefetched on hover
+- [ ] Lists: virtualized if > 100 items (react-virtual / tanstack-virtual)
+- [ ] Bundle size: < 200KB gzipped for initial load
+- [ ] Core Web Vitals: LCP < 2.5s, FID < 100ms, CLS < 0.1

package/experts/product-manager/industry/ecommerce.md

@@ -0,0 +1,43 @@
+---
+id: ecommerce
+title: E-Commerce Product — Industry-Specific Knowledge
+domain: experts
+category: product-manager
+difficulty: intermediate
+tags: [architecture, considerations, e-commerce, e-commerce-specific, ecommerce, experts, metrics, patterns]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# E-Commerce Product — Industry-Specific Knowledge
+
+## Key Metrics
+- **Conversion rate** — visitors → purchases, industry avg 2-3%
+- **AOV** (Average Order Value) — optimize with upsells, bundles, free shipping threshold
+- **Cart abandonment rate** — industry avg 70%, target < 55%
+- **Repeat purchase rate** — % of customers who buy again within 90 days
+- **ROAS** (Return on Ad Spend) — for paid acquisition channels
+
+## E-Commerce-Specific PRD Considerations
+- **Product catalog** — SKU management, variants (size/color), inventory tracking
+- **Cart** — persistent across sessions, merge anonymous → logged-in
+- **Checkout** — 1-page preferred, guest checkout required (don't force registration)
+- **Payment** — Stripe/PayPal minimum, support Apple Pay/Google Pay for mobile
+- **Shipping** — real-time rate calculation, multiple carriers, free shipping threshold
+- **Tax** — per-jurisdiction calculation (use Stripe Tax / TaxJar)
+- **Returns/refunds** — self-serve return requests, automated refund processing
+- **Order tracking** — real-time status updates, email/SMS notifications
+
+## E-Commerce Architecture Patterns
+- **Cart service** — separate from order service, handles anonymous + authenticated
+- **Inventory management** — optimistic locking to prevent overselling
+- **Search** — faceted search with filters (price range, color, size, rating)
+- **Image CDN** — responsive images, WebP/AVIF, lazy loading, zoom capability
+- **Recommendation engine** — "customers also bought", "frequently bought together"
+
+## E-Commerce UX Requirements
+- **Product page** — hero image gallery, variant selector, price + savings, trust signals (reviews, return policy)
+- **Add to cart** — no page navigation, drawer/modal confirmation, "continue shopping" option
+- **Cart** — edit quantity, remove items, promo code input, shipping estimate
+- **Checkout** — shipping → payment → review → confirm, progress indicator, save address for next time
+- **Order confirmation** — order number, expected delivery, items summary, email confirmation
+- **Mobile** — bottom sticky "Add to Cart" button, swipeable image gallery, one-tap payment

package/experts/product-manager/industry/saas.md

@@ -0,0 +1,40 @@
+---
+id: saas
+title: SaaS Product — Industry-Specific Knowledge
+domain: experts
+category: product-manager
+difficulty: intermediate
+tags: [appear, architecture, common, considerations, experts, metrics, must, patterns]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# SaaS Product — Industry-Specific Knowledge
+
+## Key Metrics (must appear in PRD success metrics)
+- **MRR** (Monthly Recurring Revenue) — the north star metric
+- **Churn rate** — monthly: acceptable < 5%, good < 3%
+- **CAC** (Customer Acquisition Cost) / **LTV** (Lifetime Value) — LTV/CAC > 3 is healthy
+- **Activation rate** — % of signups who complete onboarding and reach "aha moment"
+- **NPS** (Net Promoter Score) — measure after 30 days
+
+## SaaS-Specific PRD Considerations
+- **Multi-tenancy** — data isolation between customers is non-negotiable
+- **Billing integration** — Stripe/Paddle, plan limits, usage metering, proration
+- **Onboarding flow** — first-time user experience determines activation rate
+- **Team management** — invite members, roles (admin/member/viewer), SSO
+- **Self-serve vs sales-led** — affects pricing page, trial flow, upgrade prompts
+
+## Common SaaS Architecture Patterns
+- **Database per tenant** (expensive, max isolation) vs **shared DB with RLS** (efficient, careful isolation)
+- **Feature flags** — launch to % of users, A/B test features
+- **Webhook system** — customers need event notifications for integrations
+- **API rate limiting** — per-plan rate limits (free: 100/min, pro: 1000/min)
+- **Audit log** — enterprise customers require activity logging
+
+## SaaS Pricing Page Requirements
+- 2-4 tiers (free/starter/pro/enterprise)
+- Annual vs monthly toggle with savings badge
+- Feature comparison table below tier cards
+- "Most popular" highlight on recommended tier
+- Enterprise: "Contact sales" instead of price
+- FAQ section addressing billing questions

package/experts/product-manager/methodology.md

@@ -0,0 +1,97 @@
+---
+id: methodology
+title: Product Manager — Methodology
+domain: experts
+category: product-manager
+difficulty: intermediate
+tags: [experts, framework, methodology, writing]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# Product Manager — Methodology
+
+## PRD Writing Framework
+
+### 1. Problem Statement First
+
+Before any solution, define:
+- Who has this problem? (persona, not demographics)
+- How are they solving it today? (current workaround)
+- Why is the current solution inadequate? (pain intensity 1-10)
+- What evidence do we have? (user interviews, data, support tickets)
+
+### 2. Requirements Prioritization
+
+Use RICE scoring for feature prioritization:
+
+| Factor | Definition | Scale |
+|---|---|---|
+| **R**each | How many users per quarter? | actual number |
+| **I**mpact | How much does it move the needle? | 3=massive, 2=high, 1=medium, 0.5=low, 0.25=minimal |
+| **C**onfidence | How sure are we? | 100%=high, 80%=medium, 50%=low |
+| **E**ffort | Person-months to build | actual estimate |
+
+RICE Score = (Reach × Impact × Confidence) / Effort
+
+### 3. Acceptance Criteria Standard
+
+Every AC must be:
+- **Specific** — no ambiguous words ("fast", "nice", "easy")
+- **Measurable** — has a number or binary check
+- **Independent** — can be tested without other ACs
+- **Format** — Given [precondition], When [action], Then [observable result]
+
+Bad: "The page should load fast"
+Good: "Given a user on 3G connection, when they open /dashboard, then First Contentful Paint < 2s"
+
+Bad: "Login should be secure"
+Good: "Given 5 failed login attempts from same IP in 10 minutes, when the 6th attempt is made, then return 429 and lock for 15 minutes"
+
+### 4. Edge Cases Checklist
+
+Every feature must consider:
+- Empty state (no data yet)
+- Error state (API failure, validation failure)
+- Loading state (in-progress)
+- Boundary values (0, 1, max, negative)
+- Concurrent users (race conditions)
+- Offline/slow network
+- Permission denied
+- Already deleted / stale data
+
+### 5. Non-Functional Requirements Template
+
+| Category | Requirement | Target | How to Measure |
+|---|---|---|---|
+| Performance | Page load time | FCP < 1.5s | Lighthouse CI |
+| Performance | API response time | p95 < 200ms | Server metrics |
+| Performance | Concurrent users | 1000 simultaneous | Load test |
+| Security | Authentication | JWT with refresh | Manual audit |
+| Security | Data encryption | TLS 1.3 + at-rest AES-256 | Security scan |
+| Security | Input validation | All endpoints | Automated test |
+| Accessibility | WCAG level | 2.1 AA | axe-core audit |
+| Accessibility | Keyboard navigation | All interactive elements | Manual test |
+| Reliability | Uptime | 99.9% | Monitoring |
+| Reliability | Error rate | < 0.1% | Error tracking |
+
+### 6. Success Metrics Framework
+
+Use the HEART framework:
+- **H**appiness — user satisfaction (NPS, CSAT)
+- **E**ngagement — usage frequency, session duration
+- **A**doption — new users, feature adoption rate
+- **R**etention — day-1/7/30 retention
+- **T**ask success — completion rate, time-to-complete
+
+Each metric needs: baseline → target → measurement method → review cadence
+
+### 7. Common PRD Mistakes to Avoid
+
+1. **Solution before problem** — jumping to "we need a button" before defining the user need
+2. **Vague acceptance criteria** — "should be intuitive" is not testable
+3. **Missing edge cases** — happy path only, no error handling
+4. **No success metrics** — shipping without knowing if it worked
+5. **Scope creep built-in** — "and also it would be nice if..." without marking as out-of-scope
+6. **Missing non-functional** — no performance targets, no security requirements
+7. **No user flow** — feature list without showing how they connect
+8. **Assuming implementation** — "use React" in a PRD (that's architecture, not product)

package/experts/qa-lead/methodology.md

@@ -0,0 +1,123 @@
+---
+id: methodology
+title: QA Lead — Quality Assurance Methodology
+domain: experts
+category: qa-lead
+difficulty: intermediate
+tags: [categories, experts, framework, gates, methodology, process, quality, strategy]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# QA Lead — Quality Assurance Methodology
+
+## Test Strategy Framework
+
+### Test Pyramid
+```
+        ╱  E2E  ╲          ~5%  — critical user journeys only
+       ╱ Integr. ╲         ~15% — API contracts, DB, external services
+      ╱   Unit    ╲        ~80% — business logic, pure functions
+     ╱─────────────╲
+```
+- Unit tests: fast, isolated, test one behavior per test
+- Integration tests: verify real interactions (DB, cache, APIs)
+- E2E tests: cover the golden path + top 3 error scenarios per feature
+- Never mock what you don't own; use fakes/containers instead
+
+### Test Design Principles
+- Arrange-Act-Assert (AAA) pattern for every test
+- One assertion per test (logical assertion, not literally one `assert`)
+- Test behavior, not implementation — don't test private methods
+- Use descriptive test names: `should_reject_login_when_password_expired`
+- Tests must be deterministic: no date/time, no random, no network
+
+### Acceptance Criteria → Test Mapping
+| AC Pattern | Test Type | Example |
+|---|---|---|
+| "User can..." | E2E + Integration | Login flow → API → DB |
+| "System must..." | Integration + Unit | Rate limiting, validation |
+| "When X, then Y" | Unit | Business rule logic |
+| "Never/always..." | Unit + Property | Invariant tests |
+| "Within N ms" | Performance | Load test, benchmark |
+
+## Test Categories
+
+### Functional Testing
+- **Smoke tests**: top 5 critical paths pass? Deploy gate.
+- **Regression tests**: previously broken scenarios stay fixed
+- **Boundary tests**: min/max/empty/null/unicode/overflow
+- **Negative tests**: invalid input, unauthorized access, rate limits
+
+### Non-Functional Testing
+- **Performance**: response time P50/P95/P99 under expected load
+- **Load**: sustained traffic at 2x expected peak
+- **Security**: OWASP Top 10 checklist, dependency audit
+- **Accessibility**: WCAG 2.1 AA automated checks + manual screen reader
+
+### Test Data Management
+- Factory pattern for test data creation (not raw SQL inserts)
+- Each test creates its own data; no shared fixtures between tests
+- Use database transactions with rollback for test isolation
+- Sensitive test data: use faker/fabricator, never real PII
+
+## Quality Gates
+
+### Pre-Merge Gate
+- [ ] All unit tests pass
+- [ ] All integration tests pass
+- [ ] Code coverage ≥ 80% (new code ≥ 90%)
+- [ ] No new linting errors
+- [ ] Security scan clean (Snyk/Trivy/Dependabot)
+- [ ] Type check passes
+
+### Pre-Release Gate
+- [ ] Smoke tests pass against staging
+- [ ] E2E suite green (≤ 2% flaky tolerance)
+- [ ] Performance benchmarks within baseline ± 10%
+- [ ] Accessibility audit passes
+- [ ] Manual QA sign-off on new features
+- [ ] Rollback procedure verified
+
+### Post-Release Verification
+- [ ] Health checks green for 15 minutes
+- [ ] Error rate ≤ baseline + 0.1%
+- [ ] P95 latency ≤ baseline + 20%
+- [ ] Key business metrics trending normally
+- [ ] No new error patterns in log aggregation
+
+## Bug Triage Process
+
+### Severity Classification
+| Severity | Impact | Response Time | Example |
+|---|---|---|---|
+| P0 - Critical | Service down, data loss | Immediate | Auth broken, DB corruption |
+| P1 - High | Major feature broken | < 4 hours | Checkout fails for 20% users |
+| P2 - Medium | Feature degraded | < 24 hours | Search returns stale results |
+| P3 - Low | Minor issue | Next sprint | UI alignment off on Safari |
+
+### Root Cause Analysis
+1. Reproduce the bug with minimum steps
+2. Identify the root cause (not just the symptom)
+3. Write a failing test that catches the bug
+4. Fix the code
+5. Verify the test passes
+6. Check for similar patterns elsewhere in codebase
+
+## CI/CD Quality Integration
+
+### Pipeline Quality Checks
+```
+commit → lint → type-check → unit → integration → build → deploy(staging) → smoke → deploy(prod) → verify
+```
+
+### Flaky Test Management
+- Quarantine flaky tests (don't delete, don't block pipeline)
+- Maximum 2% flaky rate; above this → halt new features until fixed
+- Track flaky tests with retry count; >3 retries = quarantine
+- Root-cause every flaky test: timing, ordering, shared state, network
+
+### Test Coverage Policy
+- Coverage is a floor, not a ceiling — high coverage ≠ good tests
+- Focus coverage on: business logic, error handling, state transitions
+- Exempt from coverage: generated code, configuration, type definitions
+- Use mutation testing quarterly to verify test quality

package/experts/qa-lead/test-strategy.md

@@ -0,0 +1,128 @@
+---
+id: test-strategy
+title: QA Lead — Test Strategy
+domain: experts
+category: qa-lead
+difficulty: intermediate
+tags: [acceptance, cases, criteria, experts, from, integration, pyramid, standards]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# QA Lead — Test Strategy
+
+## 测试分层底线（按架构分层去测）
+
+详见标准《测试策略与分层规范》(`testing/01-standards/test-strategy-and-layering`)。硬性底线：
+
+- **金字塔**：大量单元（领域逻辑/纯函数，无 IO）+ 适量集成（服务+仓储+真 DB）+ 少量 E2E（关键业务流）。倒金字塔（一堆 e2e、几乎无单测）不合格。
+- **各层测各层**：领域层测不变量/状态机；服务层 mock 依赖测用例编排与错误路径；repository 用真 DB 集成测；接口层测状态码/校验/错误信封/鉴权；关键流走 E2E。
+- **写法**：AAA、一测一行为、覆盖正常+边界+错误、测行为不测私有实现、测试独立可并行无 flaky、外部依赖用替身。
+- **CI**：每次 PR 跑 lint+单元+集成，失败阻断合并；关键路径覆盖达阈值；flaky 必修。
+
+## Test Pyramid
+
+```
+        ╱ E2E Tests ╲           (few, slow, expensive)
+       ╱─────────────╲
+      ╱ Integration   ╲        (moderate count)
+     ╱─────────────────╲
+    ╱   Unit Tests      ╲      (many, fast, cheap)
+   ╱─────────────────────╲
+```
+
+Target ratios: 70% unit / 20% integration / 10% E2E
+
+## From Acceptance Criteria to Test Cases
+
+Each PRD acceptance criteria generates multiple test cases:
+
+**AC**: Given a user on the login page, when they enter valid credentials, then they are redirected to /dashboard
+
+**Test Cases**:
+1. ✓ Valid email + correct password → redirect to /dashboard
+2. ✓ Valid email + wrong password → show error "Invalid credentials"
+3. ✓ Non-existent email → show same generic error (no user enumeration)
+4. ✓ Empty email field → show validation "Email is required"
+5. ✓ Invalid email format → show validation "Enter a valid email"
+6. ✓ Empty password → show validation "Password is required"
+7. ✓ 5 failed attempts → show "Account locked, try again in 15 minutes"
+8. ✓ SQL injection in email field → sanitized, returns validation error
+9. ✓ XSS in email field → sanitized, no script execution
+10. ✓ Redirect to originally requested page after login (not always /dashboard)
+
+## Unit Test Standards
+
+### Naming Convention
+```
+test_[unit]_[scenario]_[expected_result]
+
+test_login_valid_credentials_returns_jwt
+test_login_wrong_password_returns_401
+test_login_locked_account_returns_429
+```
+
+### Test Structure (Arrange-Act-Assert)
+```
+// Arrange: set up test data and dependencies
+let user = create_test_user("test@example.com", "password123");
+let req = LoginRequest { email: "test@example.com", password: "password123" };
+
+// Act: call the function under test
+let result = auth_service.login(req).await;
+
+// Assert: verify the outcome
+assert!(result.is_ok());
+assert!(!result.unwrap().token.is_empty());
+```
+
+### What to Test
+- Happy path (normal operation)
+- Boundary values (0, 1, max, max+1)
+- Error paths (invalid input, missing data, network failure)
+- Edge cases (empty collections, null/None, concurrent access)
+
+### What NOT to Test
+- Third-party library internals
+- Private methods directly (test through public API)
+- Configuration / constants
+- Framework boilerplate
+
+## Integration Test Standards
+
+### API endpoint tests must verify:
+1. Correct status code
+2. Response body structure (schema validation)
+3. Database state after mutation
+4. Authentication/authorization enforcement
+5. Error responses for invalid input
+
+### Database test isolation:
+- Each test uses a transaction that rolls back after
+- OR each test uses a fresh test database
+- Never share state between tests
+
+## E2E Test Standards
+
+### What to cover:
+- Complete user flows (signup → onboard → core action → logout)
+- Cross-page navigation
+- Form submissions with validation
+- Real API calls (not mocked)
+
+### What NOT to E2E test:
+- Every field validation (unit test those)
+- Error edge cases (integration test those)
+- Visual appearance (use visual regression tools separately)
+
+## Pre-Release Checklist
+
+- [ ] All unit tests pass
+- [ ] All integration tests pass
+- [ ] E2E smoke tests pass
+- [ ] No console errors in browser
+- [ ] Performance budget met (Lighthouse ≥ 90)
+- [ ] Accessibility audit passes (axe-core, 0 violations)
+- [ ] Security headers present
+- [ ] Error tracking connected and receiving events
+- [ ] Monitoring dashboards show expected metrics
+- [ ] Rollback procedure documented and tested