devflow-kit 3.11.0 → 3.12.0

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

@@ -21,136 +21,38 @@ activation:
 > Type-hint every function signature. Name every exception. Use dataclasses over raw
 > dicts. Python's flexibility is a strength only when boundaries are explicit.
 
-## When This Skill Activates
-
-Working with Python codebases, designing typed APIs, modeling data with dataclasses
-or Pydantic, implementing async code, structuring Python packages.
-
----
-
 ## Type Safety
 
-### Type Hint Everything [4][17][18]
-
-```python
-# BAD: def process(data, config): ...
-def process(data: list[dict[str, Any]], config: AppConfig) -> ProcessResult: ...
-```
-
-Dropbox's 4M-line mypy migration eliminated entire bug classes [18]. Use
-`from __future__ import annotations` for forward references [22].
-
-### Protocols for Structural Typing [5][1]
-
-```python
-from typing import Protocol
-
-class Repository(Protocol):
-    def find_by_id(self, id: str) -> User | None: ...
-    def save(self, entity: User) -> User: ...
-```
-
-PEP 544 formalizes duck typing as "static duck typing" — no `implements`
-required [5]. Any class with matching methods satisfies the Protocol [1].
-
-### Strict Optional Handling [4][23]
-
-PEP 604 `X | Y` syntax replaces verbose `Optional[X]` [23]:
-
-```python
-def get_name(user: User | None) -> str:
-    return "Anonymous" if user is None else user.name
-```
-
----
-
-## Error Handling [2][8][9]
-
-```python
-class AppError(Exception): ...
+- Annotate every parameter and the return: `def process(data: list[dict[str, Any]], config: AppConfig) -> ProcessResult`, not `def process(data, config)`.
+- Use `from __future__ import annotations` for forward references, not string annotations (`x: "MyClass"`).
+- Use `Protocol` for structural typing, over ABC: any class with matching methods satisfies it, with no `implements`.
+- Write optionals as `User | None` (PEP 604), not `Optional[User]`, and handle `None` explicitly.
 
-class NotFoundError(AppError):
-    def __init__(self, entity: str, id: str) -> None:
-        super().__init__(f"{entity} {id} not found")
-        self.entity, self.id = entity, id
+## Error Handling
 
-@contextmanager
-def database_transaction(conn: Connection):
-    try:
-        yield conn; conn.commit()
-    except Exception:
-        conn.rollback(); raise
-```
+- Define custom exception types: a base `AppError(Exception)` and subclasses (`NotFoundError`) that carry structured fields (`entity`, `id`).
+- Catch named exceptions, `except (ValueError, KeyError):`. Never a bare `except:`: it catches `SystemExit`.
+- Use context managers for resource cleanup and the unit of work: commit on success, roll back and re-raise on error.
 
-Google Style Guide prohibits bare `except:` — catches `SystemExit` [8].
-Cosmic Python wraps the unit-of-work in a context manager [9].
+## Data Modeling
 
----
-
-## Data Modeling [6][12][14]
-
-```python
-# Internal value objects — frozen enforces immutability [6][14]
-@dataclass(frozen=True)
-class User:
-    name: str
-    email: str
-    created_at: datetime = field(default_factory=lambda: datetime.now(timezone.utc))
+- Use `@dataclass(frozen=True)` for internal value objects, with `field(default_factory=...)` for computed defaults.
+- Use Pydantic models at API boundaries: they validate on instantiation (`EmailStr`, `Field(ge=0, le=150)`).
+- Use `@dataclass` for domain objects and Pydantic for API models — not interchangeably, and not raw dicts.
 
-# API boundary models — Pydantic validates on instantiation [12]
-class CreateUserRequest(BaseModel):
-    name: str
-    email: EmailStr
-    age: int = Field(ge=0, le=150)
-```
+## Pythonic Patterns
 
-PEP 557 gives `__init__`, `__repr__`, `__eq__` for free [6]. Use `@dataclass` for
-domain objects and Pydantic for API models — not interchangeably [9][12].
-
----
-
-## Pythonic Patterns [2][3]
-
-```python
-names = [u.name for u in users if u.active]  # comprehension over loop [2]
-for i, item in enumerate(items): ...          # enumerate, not range(len) [2]
-try:                                          # EAFP over LBYL [3]
-    value = mapping[key]
-except KeyError:
-    value = default
-```
-
----
-
-## Anti-Patterns [2][8][14][4]
-
-| Pattern | Violation | Fix |
-|---------|-----------|-----|
-| Bare except | `except:` | `except (ValueError, KeyError):` [8] |
-| Mutable default | `def fn(items=[])` | `def fn(items: list \| None = None)` [2] |
-| No type hints | `def process(data)` | Annotate params + return [4] |
-| Forward ref string | `x: "MyClass"` | `from __future__ import annotations` [22] |
-| God class | 50-method class | Compose smaller focused classes [9] |
-
----
+- Comprehensions over loops: `[u.name for u in users if u.active]`.
+- `enumerate(items)`, not `range(len(items))`.
+- EAFP over LBYL: `try: value = mapping[key]` with `except KeyError`.
+- No mutable default arguments: `def fn(items: list | None = None)`, not `def fn(items=[])`.
+- Compose smaller focused classes, not a 50-method god class.
+- Tests use pytest fixtures, no repeated setup.
 
 ## Extended References
 
-- `references/sources.md` — Full bibliography (25 sources)
-- `references/patterns.md` — Extended patterns: DI, decorators, fixtures [2][9][10][13]
+- `references/sources.md` — Full bibliography
+- `references/patterns.md` — Extended patterns: DI, decorators, fixtures
 - `references/violations.md` — Violation examples with citations
 - `references/detection.md` — Grep patterns for Python issues
-- `references/async.md` — Async patterns: gather, TaskGroup, generators [1][16]
-
----
-
-## Checklist
-
-- [ ] All functions annotated (params + return) [4]
-- [ ] Custom exception types, no bare `except:` [8]
-- [ ] Dataclasses or Pydantic for structured data [6][12]
-- [ ] No mutable default arguments [2]
-- [ ] Context managers for resource cleanup [10]
-- [ ] `from __future__ import annotations` for forward refs [22]
-- [ ] Protocols over ABC for structural typing [5]
-- [ ] Tests use pytest fixtures, no repeated setup [13]
+- `references/async.md` — Async patterns: gather, TaskGroup, generators

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

@@ -1,13 +1,13 @@
 ---
 name: qa
-description: This skill should be used when designing or running scenario-based acceptance tests.
+description: Use when designing or running scenario-based acceptance tests.
 user-invocable: false
 allowed-tools: Read, Grep, Glob, Bash
 ---
 
 # QA Patterns
 
-Scenario-based acceptance testing methodology. Ensures implementations satisfy user-observable requirements beyond what unit tests cover.
+Scenario-based acceptance testing: checks that an implementation satisfies user-observable requirements beyond what unit tests cover.
 
 ## Iron Law
 
@@ -17,11 +17,7 @@ Scenario-based acceptance testing methodology. Ensures implementations satisfy u
 > gets at least one scenario. Every scenario produces observable evidence. If you can't
 > demonstrate it works from the outside, it doesn't work. [3][8]
 
----
-
-## Scenario Types [1][2][6]
-
-Five categories ensure comprehensive coverage:
+## Scenario Types
 
 | Type | Purpose | Example |
 |------|---------|---------|
@@ -31,9 +27,9 @@ Five categories ensure comprehensive coverage:
 | **Integration** | Components work together correctly | "Add item → appears in search results" |
 | **Regression** | Existing behavior preserved after changes | "Old items still load after schema migration" |
 
-**Minimum coverage**: At least one scenario per acceptance criterion. At least one boundary and one negative scenario per feature. [1][6]
+**Minimum coverage**: At least one scenario per acceptance criterion. At least one boundary and one negative scenario per feature.
 
-## Scenario Design from Acceptance Criteria [4][8][9]
+## Scenario Design from Acceptance Criteria
 
 Extract testable claims using Given/When/Then:
 
@@ -47,49 +43,28 @@ S4 (negative): Given no auth, When upload 5MB file, Then 401
 S5 (negative): Given auth user, When upload empty file, Then 400
 ```
 
-**Extracting criteria** [4]: If no explicit acceptance criteria, derive from the request:
+**Extracting criteria**: If no explicit acceptance criteria, derive from the request:
 1. What new behavior was requested? → happy path scenarios
-2. What inputs does it accept? → boundary scenarios [7][10]
+2. What inputs does it accept? → boundary scenarios
 3. What should it reject? → negative scenarios
 4. What existing behavior must survive? → regression scenarios
 
-## Equivalence Partitioning & Boundary Analysis [1][6][7]
-
-Reduce infinite inputs to representative cases:
-
-- **Valid partition**: One representative value from each valid class
-- **Invalid partition**: One representative from each invalid class
-- **Boundary values**: On, just below, just above each boundary [10]
-
-```
-Input: age (integer, 0-120 allowed)
-├── Valid: 25 (mid-range), 0 (minimum), 120 (maximum)
-├── Invalid: -1 (below min), 121 (above max), "abc" (wrong type)
-└── Boundary: 0, 1, 119, 120
-```
+**Partitions and boundaries**: Take one representative value from each valid and each invalid input class, plus the values on, just below and just above each boundary.
 
-## Exploratory Testing Heuristics [2][3][11]
+## Exploratory Testing Heuristics
 
 When acceptance criteria are vague, use structured exploration:
 
-- **CRUD tour** [11]: Create, Read, Update, Delete — does each operation work end-to-end?
-- **Configuration tour** [11]: Change every configurable value — does the system adapt?
-- **Error tour** [3]: Force every error path — are messages helpful, is state clean?
-- **Boundary tour** [3][11]: Push every input to its limits
+- **CRUD tour**: Create, Read, Update, Delete — does each operation work end-to-end?
+- **Configuration tour**: Change every configurable value — does the system adapt?
+- **Error tour**: Force every error path — are messages helpful, is state clean?
+- **Boundary tour**: Push every input to its limits
 
-## Evidence Collection
+## Evidence
 
-Every scenario must produce verifiable evidence:
+Every scenario produces verifiable evidence: the exit code and output of each command, plus the file state (`ls -la`, `diff`) for file changes, the HTTP status for an API endpoint, or the log lines for a background process.
 
-| Evidence Type | How to Capture | When to Use |
-|--------------|----------------|-------------|
-| Exit codes | `echo $?` after command | CLI tools, scripts |
-| Stdout/stderr | Redirect to capture | All command execution |
-| File state | `ls -la`, `diff`, `cat` | File creation/modification |
-| HTTP status | Response code from curl/fetch | API endpoints |
-| Log output | Grep logs after action | Background processes |
-
-## Browser-Based Scenarios [8][12]
+## Browser-Based Scenarios
 
 When implementation includes web-facing changes (.tsx, .jsx, .html, routes, pages):
 
@@ -101,19 +76,8 @@ When implementation includes web-facing changes (.tsx, .jsx, .html, routes, page
 | Console clean | Navigate → read console | No errors/warnings logged |
 | Navigation works | Click links → verify URL change | Correct page loaded |
 
-**Dev server lifecycle**: Check for running server first. If none, auto-start from package.json scripts, poll for readiness, kill after testing. Never kill pre-existing servers.
-**Testability assessment**: Before designing scenarios, assess what local infrastructure is available (DB, Redis, external APIs). Mark scenarios requiring unavailable infrastructure as SKIPPED.
 **Graceful degradation**: If browser tools or dev server unavailable, fall back to curl/API testing. Always report what was skipped and why alongside what was tested.
 
-## Severity Classification
-
-| Level | Meaning | Action |
-|-------|---------|--------|
-| **BLOCKING** | Acceptance criterion violated — feature does not work as requested | Report FAIL — Fix agent must fix |
-| **WARNING** | Edge case concern — feature works but edge behavior is unexpected | Report PASS with warnings — note for improvement |
-
----
-
 ## Extended References
 
 For additional scenario templates and anti-patterns:
@@ -122,8 +86,6 @@ For additional scenario templates and anti-patterns:
 - `references/violations.md` — QA anti-patterns to avoid
 - `references/scenario-templates.md` — Templates for common feature types
 
----
-
 ## Success Criteria
 
 - [ ] Every acceptance criterion has at least one scenario

package/src/assets/skills/qa/references/browser-testing.md

@@ -71,27 +71,3 @@ Requires: Chrome MCP tools available + dev server running.
    g. Record evidence from each step
 
 3. After all browser scenarios: close the tab created in step 1
-
----
-
-## Bash Execution Constraints
-
-When executing scenarios via Bash, these constraints are mandatory:
-
-**NEVER execute:**
-- Destructive filesystem commands: `rm -rf`, `rmdir`, `truncate`, `shred`
-- Privilege escalation: `sudo`, `su`, `chown`, `chmod` on system directories
-- Code injection vectors: `eval`, `exec`, shell substitution on untrusted input
-- Package management: `npm install -g`, `pip install`, `brew install`, `apt-get`
-- Network exfiltration: outbound curl/wget to external hosts not under test
-
-**ONLY run:**
-- Test runners: `npm test`, `pytest`, `go test`, `cargo test`, `jest`, `mocha`
-- Build commands: `npm run build`, `go build`, `cargo build`
-- Read-only file inspection: `cat`, `ls`, `diff`, `head`, `tail`, `grep`
-- Readiness checks: `curl` to `localhost` only, `lsof`, `pg_isready`, `redis-cli ping`
-- Process management for servers WE started: `kill $DEV_SERVER_PID`
-
-**Filesystem writes restricted to:**
-- Temporary files created via `mktemp` in `/tmp/devflow-tester-*`
-- Project test directories (e.g., `__tests__/fixtures/`, `test/data/`)

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

@@ -25,6 +25,6 @@ Canonical references for scenario-based acceptance testing methodology.
 |---------|----------------|-------------------|
 | 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 |
+| Partitions and boundaries | [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) |
+| Evidence | [8] Freeman (observable behavior), [12] Google | [4] Adzic (living docs) |

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

@@ -1,24 +1,20 @@
 ---
 name: quality-gates
-description: This skill should be used when evaluating implementation quality before submission.
+description: Use when evaluating implementation quality before submission.
 user-invocable: false
 allowed-tools: Read, Grep, Glob, Edit, Write, Bash
 ---
 
 # Self-Review Framework
 
-Systematic self-review for the Harden 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).
+Self-review for the Harden agent: evaluate the implementation against 9 pillars, and fix the issues you find.
 
 ## Iron Law
 
-> **FIX BEFORE RETURNING**
+> **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.
-
----
+> Self-review is a quality gate, not a report. If you find a P0 or P1 issue, fix it.
+> Return only when every critical issue is resolved, or a P0 issue is BLOCKED.
 
 ## The 9 Pillars
 
@@ -48,102 +44,19 @@ Errors handled explicitly? No swallowed exceptions, helpful messages, resources
 ### P1 - Tests
 New code tested? Covers happy path, errors, edges. Tests behavior, not implementation.
 
-### P2 - Naming and Consistency
-Owned by the Polish agent, which applies the project's naming and style standards. Report both as SKIP; do not judge or fix them here.
-
 ### 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 Documentation and fix it if straightforward. Naming and Consistency are the Polish agent's: SKIP.
-
-### Step 5: Generate Report
-Document status of each pillar, fixes applied, and overall readiness.
+## Process
 
----
-
-## 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: SKIP (Polish agent)
-- Consistency: SKIP (Polish agent)
-- Documentation: PASS/FIXED
-
-### Summary
-Issues Found: {n}, Fixed: {n}
-Status: PASS / FIXED / BLOCKED
-```
+Evaluate P0, then P1, then P2, and fix each issue when you find it. If a P0 issue cannot be fixed, stop and report the blocker.
 
----
+Report each pillar as PASS, FIXED or BLOCKED, Naming and Consistency as SKIP, and the overall Status: PASS / FIXED / 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:
-- **Harden 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.
+Read one only when a pillar judgment needs more detail:
+- `references/patterns.md`: 9-pillar evaluation patterns and issue classification
+- `references/violations.md`: pillar-organized anti-patterns and P0/P1 red flags
+- `references/stub-detection.md`: stub and wiring-gap patterns
+- `references/report-template.md`: complete report templates and examples

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

@@ -15,7 +15,7 @@ activation:
 
 # React Patterns
 
-Reference for React-specific patterns with citations. Sources in `references/sources.md`.
+Sources in `references/sources.md`.
 
 ## Iron Law
 
@@ -26,118 +26,56 @@ Reference for React-specific patterns with citations. Sources in `references/sou
 > or composition. Props are for configuration, not data plumbing.
 > "Before You memo(), try solving it with composition." — Dan Abramov [4]
 
-## When This Skill Activates
+## Component Structure
 
-- Working with React codebases (.tsx, .jsx) — components, hooks, contexts, performance
+- Order a functional component: hooks → derived state → handlers → return.
+- Share structure through compound components and `children` (`Card` with `Card.Header`), not props.
+- Use context for shared state across distant components, at the level that needs it. Its hook throws outside the provider: `if (!ctx) throw new Error('useAuth must be used within AuthProvider')`.
+- Use stable unique IDs as list keys, not the index.
+- Put error boundaries around risky components, and handle loading and error states.
+- Accessibility: `aria-*`, `role`, labels on form inputs.
 
----
-
-## 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]
+## Hooks
 
-```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]
+Hooks must be called at the top level — never inside conditions, loops, or nested functions.
+Effects synchronize with external systems; they are not lifecycle methods.
+Every effect that subscribes must return a cleanup function. Deps must be complete — never omit to suppress warnings.
 
 See `references/hooks.md` for rules of hooks, custom hooks, useReducer, and effect anti-patterns.
 
----
+## Performance
 
-## Performance [3][4][5][17]
+The React Compiler handles many memoizations automatically. For manual optimization, follow this priority:
 
-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"
+2. Extract primitives for `useEffect` deps — avoid object/array literals
+3. `useMemo` for expensive computations; `useCallback` for stable handlers to memoized children
+4. `React.memo` only when parent has stable, memoized callbacks
+5. Virtualize long lists (react-window); lazy-load heavy components
 
-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]
+- Compute derived state during render with `useMemo`, not with `useState` + `useEffect`.
+- Parallelize independent fetches: `await Promise.all([fetchUser(id), fetchOrders(id)])`.
+- Use a `Set` or `Map` from `useMemo` for O(1) lookups, not `Array.find`/`includes` in render loops.
+- Use direct named imports (tree-shakable), not barrel imports.
+- Give images explicit dimensions, lazy loading, and aspect-ratio.
 
-```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
 
----
-
-## 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] |
+| Pattern | When to Use |
+|---------|-------------|
+| `useState` | Simple, independent values |
+| `useReducer` | Complex state with multiple transitions |
+| Context | Shared state across distant components |
+| Server Components | Server-only data; zero bundle impact |
 
 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] |
-
----
+or API route required for data fetching.
 
 ## Extended References
 
-- `references/sources.md` — Full bibliography (24 sources)
+- `references/sources.md` — Full bibliography
 - `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]