devflow-kit 1.8.2 → 2.0.0

package/src/assets/skills/qa/references/scenario-templates.md

@@ -0,0 +1,102 @@
+# QA Skill — Scenario Templates
+
+Ready-to-adapt templates for common feature types.
+
+## Template 1: CLI Command
+
+```
+Feature: New CLI command `devflow foo --bar`
+
+S1 (happy):     Run `devflow foo --bar value` → expected output, exit 0
+S2 (happy):     Run `devflow foo` with defaults → sensible default behavior
+S3 (boundary):  Run `devflow foo --bar ""` → validation error, exit 1
+S4 (boundary):  Run `devflow foo --bar` (missing value) → usage help, exit 1
+S5 (negative):  Run `devflow foo --unknown` → "unknown flag" error, exit 1
+S6 (negative):  Run in directory without required config → helpful error message
+S7 (regression): Existing commands still work unchanged
+```
+
+## Template 2: API Endpoint
+
+```
+Feature: POST /api/widgets
+
+S1 (happy):      Valid body → 201, widget in response, persisted in DB
+S2 (happy):      Minimal valid body → 201, defaults applied
+S3 (boundary):   Body at max allowed size → 201 or 413
+S4 (boundary):   Empty required field → 400 with field-specific error
+S5 (negative):   No auth header → 401
+S6 (negative):   Invalid JSON body → 400
+S7 (negative):   Duplicate unique field → 409
+S8 (integration): Created widget appears in GET /api/widgets
+```
+
+## Template 3: Configuration Change
+
+```
+Feature: New config option `maxRetries` in config.json
+
+S1 (happy):     Set maxRetries=3 → system retries 3 times on failure
+S2 (boundary):  Set maxRetries=0 → no retries (immediate fail)
+S3 (boundary):  Set maxRetries=100 → accepted (or capped with warning)
+S4 (negative):  Set maxRetries=-1 → validation error on startup
+S5 (negative):  Omit maxRetries → sensible default applied
+S6 (negative):  Set maxRetries="abc" → type error on startup
+S7 (regression): Existing config options still work with new option added
+```
+
+## Template 4: File Processing
+
+```
+Feature: Import CSV data
+
+S1 (happy):      Valid CSV with 10 rows → 10 records imported
+S2 (happy):      CSV with headers → headers correctly mapped
+S3 (boundary):   Empty CSV (headers only) → 0 records, no error
+S4 (boundary):   Large CSV (10K rows) → all imported within timeout
+S5 (negative):   Malformed CSV (unmatched quotes) → error with line number
+S6 (negative):   Missing required column → error naming the column
+S7 (negative):   File not found → clear error message
+S8 (integration): Imported records queryable via existing API
+```
+
+## Template 5: Refactoring / Internal Change
+
+```
+Feature: Refactored auth middleware (no behavior change intended)
+
+S1 (regression): Login with valid credentials → same response as before
+S2 (regression): Login with invalid credentials → same error as before
+S3 (regression): Protected endpoint with valid token → accessible
+S4 (regression): Protected endpoint without token → 401
+S5 (regression): Token expiry behavior unchanged
+S6 (regression): Rate limiting behavior unchanged
+```
+
+## Template 6: Build System / Tooling Change
+
+```
+Feature: Added new build step
+
+S1 (happy):      Full build succeeds → all artifacts present
+S2 (happy):      Incremental build after change → only affected files rebuilt
+S3 (negative):   Build with missing dependency → clear error message
+S4 (regression): Existing build outputs unchanged
+S5 (regression): Build time not significantly degraded
+S6 (integration): Built artifacts installable/runnable
+```
+
+## Template 7: Web Component / Route
+
+```
+Feature: Login page
+
+S1 (happy):      Navigate to /login → form visible, all fields present
+S2 (happy):      Enter valid credentials → submit → redirect to /dashboard
+S3 (boundary):   Email with 255 chars → accepted or validation message shown
+S4 (negative):   Submit empty form → validation errors for required fields
+S5 (negative):   Wrong password → "Invalid credentials" message displayed
+S6 (integration): Successful login → user name visible on dashboard
+S7 (regression):  Existing pages still render correctly after changes
+S8 (negative):   Navigate to /login when already logged in → redirect to dashboard
+```

package/src/assets/skills/qa/references/sources.md

@@ -0,0 +1,30 @@
+# QA Skill — Sources
+
+Canonical references for scenario-based acceptance testing methodology.
+
+## Bibliography
+
+| # | Author(s) | Title | Year | Topics | Access |
+|---|-----------|-------|------|--------|--------|
+| 1 | Myers, Sandler, Badgett | The Art of Software Testing, 3rd ed. | 2011 | Boundary value analysis, equivalence partitioning, test case design | Wiley |
+| 2 | Kaner, Bach, Pettichord | Lessons Learned in Software Testing | 2001 | Scenario design, QA philosophy, exploratory testing foundations | Wiley |
+| 3 | Hendrickson, E. | Explore It! Reduce Risk and Increase Confidence with Exploratory Testing | 2013 | Exploratory testing charters, heuristics, risk-based exploration | Pragmatic |
+| 4 | Adzic, G. | Specification by Example | 2011 | Acceptance criteria → executable specifications, living documentation | Manning |
+| 5 | Crispin, Gregory | Agile Testing: A Practical Guide | 2009 | Testing quadrants (Q1-Q4), acceptance testing in agile, whole-team quality | Addison-Wesley |
+| 6 | Copeland, L. | A Practitioner's Guide to Software Test Design | 2004 | Equivalence classes, decision tables, state transition testing, pairwise | Artech House |
+| 7 | Beizer, B. | Software Testing Techniques, 2nd ed. | 1990 | Domain testing, cause-effect graphing, syntax testing, graph-based methods | Van Nostrand Reinhold |
+| 8 | Freeman, Pryce | Growing Object-Oriented Software, Guided by Tests (GOOS) | 2009 | Acceptance test-driven development, walking skeleton, outside-in TDD | Addison-Wesley |
+| 9 | Smart, J.F. | BDD in Action: Behavior-Driven Development for the Whole Software Lifecycle | 2014 | Given/When/Then scenarios, living documentation, specification workshops | Manning |
+| 10 | Ammann, Offutt | Introduction to Software Testing, 2nd ed. | 2016 | Input space partitioning, graph coverage, logic coverage criteria | Cambridge |
+| 11 | Whittaker, J. | Exploratory Software Testing | 2009 | Test tours (feature, complexity, claims, configuration), risk-based exploration | Addison-Wesley |
+| 12 | Google Testing Blog | Various: Acceptance Testing practices | 2007-2024 | Test pyramids, acceptance test patterns, flaky test reduction | testing.googleblog.com |
+
+## How Sources Map to SKILL.md Sections
+
+| Section | Primary Sources | Supporting Sources |
+|---------|----------------|-------------------|
+| Scenario Types | [1] Myers, [2] Kaner, [6] Copeland | [5] Crispin Q2/Q3 quadrants |
+| Scenario Design from Criteria | [4] Adzic, [8] Freeman, [9] Smart | [5] Crispin acceptance testing |
+| Equivalence Partitioning | [1] Myers, [6] Copeland, [7] Beizer | [10] Ammann ISP |
+| Exploratory Heuristics | [2] Kaner, [3] Hendrickson, [11] Whittaker | [5] Crispin session-based |
+| Evidence Collection | [8] Freeman (observable behavior), [12] Google | [4] Adzic (living docs) |

package/src/assets/skills/qa/references/violations.md

@@ -0,0 +1,98 @@
+# QA Skill — Anti-Patterns
+
+Common QA anti-patterns that produce false confidence.
+
+## Violation 1: Happy-Path-Only Testing [1][2]
+
+```
+❌ Only testing the success case:
+   "User logs in with correct credentials → success"
+   No negative, boundary, or error scenarios
+
+✅ Complete coverage:
+   S1: Correct credentials → success (happy)
+   S2: Wrong password → error message (negative)
+   S3: Empty password → validation error (boundary)
+   S4: Locked account → account locked message (negative)
+   S5: SQL injection in username → sanitized, no breach (negative)
+```
+
+**Why**: Happy path tests verify ~20% of behavior. Most defects live in error handling and boundaries [1].
+
+## Violation 2: Testing Implementation, Not Behavior [2][8]
+
+```
+❌ Testing internals:
+   "Verify that addToCart() calls inventoryService.reserve()"
+   "Check that the Redux store has items array with length 1"
+
+✅ Testing user-observable behavior:
+   "Add item to cart → cart count shows 1"
+   "Add item to cart → item appears in checkout"
+```
+
+**Why**: Implementation tests break on refactoring. Behavior tests break when features break [8].
+
+## Violation 3: Missing Evidence [8][12]
+
+```
+❌ No evidence captured:
+   "Ran the command and it seemed to work"
+   PASS (based on what?)
+
+✅ Evidence captured:
+   $ some-command --flag
+   Exit code: 0
+   Output: "Success: 3 items processed"
+   File created: output.json (142 bytes)
+   PASS (evidence: exit code 0, expected output string present)
+```
+
+**Why**: Without evidence, failures are unreproducible and pass results are unverifiable [8].
+
+## Violation 4: Skipping Boundary Analysis [1][6][7]
+
+```
+❌ Testing one valid value:
+   "Input: age=25 → accepted"
+   (Ignores: age=0, age=-1, age=121, age=NaN)
+
+✅ Boundary triplets:
+   age=-1 → rejected (below minimum)
+   age=0  → accepted (minimum)
+   age=1  → accepted (above minimum)
+   age=119 → accepted (below maximum)
+   age=120 → accepted (maximum)
+   age=121 → rejected (above maximum)
+```
+
+**Why**: ~65% of input-related defects occur at boundaries [7]. Single-value testing misses them all.
+
+## Violation 5: Untraceable Scenarios [4][9]
+
+```
+❌ Vague scenarios:
+   "Test that search works"
+   "Make sure the form validates"
+
+✅ Structured Given/When/Then:
+   Given: Database contains users "alice", "bob", "charlie"
+   When: Search for "ali"
+   Then: Results contain "alice" only, displayed within 200ms
+```
+
+**Why**: Vague scenarios are non-reproducible. Structured scenarios are executable specifications [4][9].
+
+## Violation 6: Ignoring Non-Functional Acceptance [5][12]
+
+```
+❌ Only functional testing:
+   "Upload works" (but takes 30 seconds for a 1MB file)
+
+✅ Including observable quality:
+   S1: Upload 1MB file → completes within 2 seconds (performance)
+   S2: Upload shows progress indicator (usability)
+   S3: Upload failure shows retry option (error recovery)
+```
+
+**Why**: Users experience performance, usability, and error recovery — not just correct outputs [5].

package/src/assets/skills/quality-gates/SKILL.md

@@ -0,0 +1,152 @@
+---
+name: quality-gates
+description: This skill should be used when evaluating implementation quality before submission, checking correctness, security, and simplicity.
+user-invocable: false
+allowed-tools: Read, Grep, Glob, Edit, Write, Bash
+---
+
+# Self-Review Framework
+
+Systematic self-review for the Scrutinize agent. Evaluate implementation against 9 pillars. **Fix issues, don't just report them.**
+
+Based on [Google Engineering Practices](https://google.github.io/eng-practices/review/reviewer/looking-for.html).
+
+## Iron Law
+
+> **FIX BEFORE RETURNING**
+>
+> Self-review is not a report generator. It's a quality gate. If you find a P0 or P1 issue,
+> you fix it. You only return when all critical issues are resolved. Pride in craftsmanship.
+
+---
+
+## The 9 Pillars
+
+| Priority | Action | Pillars |
+|----------|--------|---------|
+| **P0** | MUST fix | Design, Functionality, Security |
+| **P1** | SHOULD fix | Complexity, Error Handling, Tests |
+| **P2** | FIX if time | Naming, Consistency, Documentation |
+
+### P0 - Design
+Does the implementation fit the architecture? Follows existing patterns, respects layer boundaries, dependencies injected.
+
+If `FEATURE_KNOWLEDGE` is provided, verify implementation respects the feature area's documented architecture and anti-patterns. Flag deviations as P0-Design issues when the documented pattern is clearly intentional.
+
+### P0 - Functionality
+Does the code work? Happy path, edge cases (null, empty, boundary), no race conditions.
+
+### P0 - Security
+Any vulnerabilities? No injection, input validated, no hardcoded secrets, auth checked.
+
+### P1 - Complexity
+Understandable in 5 minutes? Functions < 50 lines, nesting < 4 levels, no magic numbers.
+
+### P1 - Error Handling
+Errors handled explicitly? No swallowed exceptions, helpful messages, resources cleaned up.
+
+### P1 - Tests
+New code tested? Covers happy path, errors, edges. Tests behavior, not implementation.
+
+### P2 - Naming
+Names clear and descriptive? No cryptic abbreviations, consistent style.
+
+### P2 - Consistency
+Matches existing patterns? Same style, same conventions, no unnecessary divergence.
+
+### P2 - Documentation
+Will others understand? Complex logic commented, public APIs documented, no outdated comments.
+
+---
+
+## Quick Examples
+
+### Design Red Flag
+```typescript
+// BAD: Direct DB in controller (violates layers)
+class UserController {
+  async getUser(req, res) {
+    const user = await db.query('SELECT * FROM users WHERE id = ?', [req.params.id]);
+  }
+}
+```
+
+### Security Red Flag
+```typescript
+// BAD: SQL injection
+const query = `SELECT * FROM users WHERE email = '${email}'`;
+
+// BAD: Missing auth
+app.delete('/api/users/:id', async (req, res) => {
+  await deleteUser(req.params.id);  // No auth check!
+});
+```
+
+---
+
+## Self-Review Process
+
+### Step 1: Gather Changes
+```bash
+git diff --name-only HEAD~1
+git diff HEAD~1
+```
+
+### Step 2: Evaluate P0 Pillars
+Check Design, Functionality, Security. If issues found and fixable, fix immediately. If unfixable, STOP and report blocker.
+
+### Step 3: Evaluate P1 Pillars
+Check Complexity, Error Handling, Tests. Fix issues found.
+
+### Step 4: Evaluate P2 Pillars
+Check Naming, Consistency, Documentation. Fix if time permits.
+
+### Step 5: Generate Report
+Document status of each pillar, fixes applied, and overall readiness.
+
+---
+
+## Output Format
+
+```markdown
+## Self-Review Report
+
+### P0 Pillars
+- Design: PASS/FIXED
+- Functionality: PASS/FIXED
+- Security: PASS/FIXED
+
+### P1 Pillars
+- Complexity: PASS/FIXED
+- Error Handling: PASS/FIXED
+- Tests: PASS/FIXED
+
+### P2 Pillars
+- Naming: PASS/FIXED/SKIP
+- Consistency: PASS/FIXED/SKIP
+- Documentation: PASS/FIXED/SKIP
+
+### Summary
+Issues Found: {n}, Fixed: {n}
+Status: READY / BLOCKED
+```
+
+---
+
+## Extended References
+
+For detailed checklists, examples, and red flags for each pillar:
+- See `references/patterns.md` (9-pillar evaluation patterns and issue classification)
+- See `references/violations.md` (pillar-organized anti-patterns and P0/P1 red flags)
+
+For complete report templates and examples:
+- See `references/report-template.md`
+
+---
+
+## Integration
+
+Used by:
+- **Scrutinize agent**: Dedicated self-review in fresh context after the Code agent completes
+
+The self-review ensures implementations meet quality standards before external review, catching issues early.

package/src/assets/skills/quality-gates/references/stub-detection.md

@@ -0,0 +1,135 @@
+# Stub Detection Patterns
+
+Placeholder implementations that compile but don't deliver real functionality. Flag as **P0-Functionality** issues.
+
+Cross-reference: `software-design/references/code-smell-violations.md` covers hardcoded data and fake functionality labeling. This file focuses on structural stub patterns.
+
+---
+
+## 1. Component Stubs
+
+Render nothing meaningful or return placeholder markup.
+
+```tsx
+// STUB — returns static text, no real rendering
+function UserProfile({ userId }: Props) {
+  return <div>Name</div>;
+}
+
+// REAL — fetches and renders actual data
+function UserProfile({ userId }: Props) {
+  const user = useUser(userId);
+  if (!user) return <Skeleton />;
+  return <div><h2>{user.name}</h2><p>{user.email}</p></div>;
+}
+```
+
+**Patterns to flag:**
+- `return null` / `return <></>` in components that should render content
+- Empty function bodies (`{}`) for handlers or lifecycle methods
+- Components returning only hardcoded strings with no data binding
+
+---
+
+## 2. API / Service Stubs
+
+Functions that exist in signature but throw, return hardcoded values, or do nothing.
+
+```typescript
+// STUB — throws instead of implementing
+async function createOrder(items: CartItem[]): Promise<Order> {
+  throw new Error("TODO: implement");
+}
+
+// STUB — hardcoded return, no real logic
+async function getUser(id: string): Promise<User> {
+  return { id, name: "Test User", email: "test@test.com" };
+}
+
+// REAL — actual implementation
+async function createOrder(items: CartItem[]): Promise<Result<Order, OrderError>> {
+  const validated = validateItems(items);
+  if (!validated.ok) return validated;
+  const order = await db.orders.create({ items: validated.value });
+  await queue.publish("order.created", order);
+  return { ok: true, value: order };
+}
+```
+
+**Patterns to flag:**
+- `throw new Error("TODO")` / `throw new Error("Not implemented")`
+- Functions returning hardcoded objects (no DB/API/computation)
+- `"Not implemented"` strings in response bodies
+- Empty async functions (`async function foo() {}`)
+
+---
+
+## 3. Hook / Effect Stubs
+
+State and effects declared but not wired to behavior.
+
+```typescript
+// STUB — effect does nothing
+useEffect(() => {}, [userId]);
+
+// STUB — state declared, setter never called
+const [items, setItems] = useState<Item[]>([]);
+// ... setItems never appears in the component
+
+// STUB — custom hook returns static value
+function usePermissions(): Permissions {
+  return { canEdit: true, canDelete: false };
+}
+
+// REAL — custom hook with actual logic
+function usePermissions(): Permissions {
+  const { user } = useAuth();
+  const { data } = useQuery(["permissions", user.role], fetchPermissions);
+  return data ?? DEFAULT_PERMISSIONS;
+}
+```
+
+**Patterns to flag:**
+- `useEffect(() => {}, [...])` — empty effect body
+- `useState` where the setter is never called in the component
+- Custom hooks returning static/hardcoded values
+- `useMemo`/`useCallback` wrapping static values
+
+---
+
+## 4. Wiring Gaps
+
+Individual pieces exist but aren't connected to the running application. **Highest-value detection** — these pass compilation and individual tests but the feature doesn't work end-to-end.
+
+```typescript
+// GAP — fetch without await (result discarded)
+function loadDashboard() {
+  fetchMetrics(); // Promise floats, never awaited
+  return <Dashboard />;
+}
+
+// GAP — state declared but never rendered
+const [error, setError] = useState<string | null>(null);
+// ... error never appears in JSX
+
+// GAP — handler defined but not bound
+function handleSubmit(data: FormData) { /* real logic */ }
+// ... <form onSubmit={handleSubmit}> never appears
+
+// GAP — route defined with no-op handler
+app.post("/api/orders", (_req, res) => {
+  res.status(200).json({ ok: true });
+});
+
+// GAP — env var read but unused
+const API_KEY = process.env.STRIPE_API_KEY;
+// ... API_KEY never passed to any client or fetch call
+```
+
+**Patterns to flag:**
+- `fetch`/`axios`/API call without `await` or `.then` (result discarded)
+- State variable (`useState`, `useRef`) never rendered or read in output
+- Event handler defined but not bound to any element/listener
+- Route/endpoint registered with empty or no-op handler
+- Environment variable or config read but never used downstream
+- Import used only in type position but imported as value (in non-type-only import)

package/src/assets/skills/react/SKILL.md

@@ -0,0 +1,143 @@
+---
+name: react
+description: This skill should be used when the user works with React components (.tsx/.jsx), asks about "hooks", "state management", "context providers", "memo optimization", "useEffect", or discusses component composition and rendering performance. Provides patterns for hooks, state, effects, memoization, and React-specific architecture.
+user-invocable: false
+allowed-tools: Read, Grep, Glob
+activation:
+  file-patterns:
+    - "**/*.tsx"
+    - "**/*.jsx"
+  exclude:
+    - "node_modules/**"
+    - "**/*.test.*"
+    - "**/*.spec.*"
+---
+
+# React Patterns
+
+Reference for React-specific patterns with citations. Sources in `references/sources.md`.
+
+## Iron Law
+
+> **COMPOSITION OVER PROPS** [2][4][12]
+>
+> Use children and compound components, not prop drilling. If a component has >5 props,
+> it's doing too much. Split it. If you're passing data through 3+ levels, use context
+> or composition. Props are for configuration, not data plumbing.
+> "Before You memo(), try solving it with composition." — Dan Abramov [4]
+
+## When This Skill Activates
+
+- Working with React codebases (.tsx, .jsx) — components, hooks, contexts, performance
+
+---
+
+## Component Structure [1][2]
+
+**Functional component order**: hooks → derived state → handlers → return. [1]
+
+**Compound components** share structure through children, not props: [2][4]
+
+```tsx
+function Card({ children }: { children: React.ReactNode }) {
+  return <div className="card">{children}</div>;
+}
+Card.Header = ({ children }: { children: React.ReactNode }) =>
+  <div className="card-header">{children}</div>;
+```
+
+**Context** for shared state across distant components — eliminates prop drilling: [1][2]
+
+```tsx
+const AuthContext = createContext<AuthContextValue | null>(null);
+export function useAuth() {
+  const ctx = useContext(AuthContext);
+  if (!ctx) throw new Error('useAuth must be used within AuthProvider');
+  return ctx;
+}
+```
+
+---
+
+## Hooks [3][16][24]
+
+Hooks must be called at the **top level** — never inside conditions, loops, or nested functions. [16][24]
+Effects synchronize with external systems; they are not lifecycle methods. [3]
+Every effect that subscribes must return a cleanup function. Deps must be complete — never omit to suppress warnings. [3]
+
+See `references/hooks.md` for rules of hooks, custom hooks, useReducer, and effect anti-patterns.
+
+---
+
+## Performance [3][4][5][17]
+
+The React Compiler (2024) handles many memoizations automatically [17]. For manual
+optimization, follow this priority: [4]
+
+1. **Composition first** — "before you memo(), try passing children down" [4]
+2. **Extract primitives** for `useEffect` deps — avoid object/array literals [3]
+3. **`useMemo`** for expensive computations; **`useCallback`** for stable handlers [3]
+4. **`React.memo`** only when parent has stable, memoized callbacks [4]
+5. **Virtualize** long lists (react-window) [5]; **lazy-load** heavy components [5]
+
+```tsx
+const [user, orders] = await Promise.all([fetchUser(id), fetchOrders(id)]); // parallel [1]
+const filtered = useMemo(() => users.filter(u => u.name.includes(q)), [users, q]); // derived [13]
+const selectedSet = useMemo(() => new Set(selected), [selected]); // O(1) lookup [5]
+```
+
+---
+
+## State Architecture [1][14]
+
+| Pattern | When to Use | Source |
+|---------|-------------|--------|
+| `useState` | Simple, independent values | [1] |
+| `useReducer` | Complex state with multiple transitions | [14] |
+| Context | Shared state across distant components | [1][2] |
+| Server Components | Server-only data; zero bundle impact | [6][7] |
+
+Server Components render on the server and stream to the client — no `useEffect`
+or API route required for data fetching. [6][7]
+
+---
+
+## Key Anti-Patterns [3][13]
+
+| Anti-Pattern | Correct Approach | Source |
+|-------------|-----------------|--------|
+| Derived state in `useState` + `useEffect` | Compute with `useMemo` during render | [13] |
+| Object/array literal in `useEffect` deps | Extract to primitives | [3] |
+| Missing cleanup in `useEffect` | Always return cleanup function | [3] |
+| Prop drilling (3+ levels) | Context or composition | [2][4] |
+| Barrel imports | Direct named imports (tree-shakable) | [5] |
+| `Array.find`/`includes` in render loops | `Map`/`Set` via `useMemo` | [5] |
+| Index as list key | Use stable unique IDs | [1] |
+
+---
+
+## Extended References
+
+- `references/sources.md` — Full bibliography (24 sources)
+- `references/patterns.md` — Extended correct patterns with citations
+- `references/violations.md` — Extended violation examples with citations
+- `references/hooks.md` — Hook rules, custom hooks, useEffect deep-dive, utilities
+- `references/forms.md` — Controlled/uncontrolled, validation, Server Actions
+- `references/error-handling.md` — Error boundaries, Suspense, async error states
+
+---
+
+## Checklist
+
+- [ ] Hooks at top level — no conditions or loops [16][24]
+- [ ] All `useEffect` deps included; cleanup returned [3]
+- [ ] `useCallback` for handlers to memoized children; `useMemo` for expensive values [4]
+- [ ] Context at appropriate level — no prop drilling [2]
+- [ ] Error boundaries around risky components [1]
+- [ ] Unique stable keys on list items — not index [1]
+- [ ] Loading and error states handled [13]
+- [ ] Accessibility: `aria-*`, `role`, labels on form inputs [21][22]
+- [ ] Independent fetches parallelized with `Promise.all` [1]
+- [ ] Direct imports — no barrel imports; lazy-load heavy components [5]
+- [ ] `Set`/`Map` for O(1) lookups instead of `Array.includes`/`find` [5]
+- [ ] Images have explicit dimensions, lazy loading, and aspect-ratio [23]