Generate Task

For each unit, identify:

• File path (exact, following codebase conventions)
• Action: create or modify
• Domain: database | api | shared | frontend | test | config | docs
• Dependencies: which other units must exist first

Standard dependency ordering (lower layers before higher):

1. Shared types, constants, i18n keys, env variables
2. Database migrations and schema updates
3. API routes, handlers, validation schemas
4. Shared hooks, utilities, helper functions
5. UI components (atoms → molecules → organisms)
6. Pages and routes composing components
7. Tests (unit, integration, E2E)
8. Config and infrastructure changes
9. Documentation updates

Orphan-free rule — every consumer of a resource must be in the same task as its producer OR in a later task that explicitly depends on the producer's task:

• New i18n key + every component using that key → same task (or key in TASK_N, component in TASK_M where M > N and TASK_M depends on TASK_N)
• New database column + migration that adds it → same task
• New shared type + every immediate consumer → same task
• New component + the page that renders it → same task (unless page is intentionally deferred to a later task)

Rule 1 — 30-file limit: a task may create or modify at most 30 files. If a natural group exceeds this, split on domain boundaries (data layer, API layer, UI layer, test layer).

Rule 2 — Production-ready delivery: every task, when merged in order, must leave the application in a runnable state — no broken imports, unresolved references, orphaned i18n keys, or missing migrations.

Rule 3 — Forward dependency only: if TASK_N requires output from TASK_M, then M < N. No task may depend on a later task.

Rule 4 — Mergeable without breaking: use feature flags, graceful degradation, or empty-state handling so earlier tasks don't expose incomplete UX to end users.

Rule 5 — Clear value delivery: each task must deliver a demonstrable increment — a working endpoint, a rendered component, a passing test suite. Avoid tasks with no visible or testable outcome.

Recommended grouping (adapt per feature):

1. Foundation — shared types, constants, i18n keys, env variables
2. Data layer — database schema, migrations, ORM models
3. API layer — routes, handlers, validation schemas, error codes
4. Core UI — reusable components, hooks, state management
5. Feature pages — pages and routes composing the core UI
6. Tests & polish — comprehensive test suites, accessibility audit, performance tuning
7. Documentation — CLAUDE.md updates, API docs, migration guides

Split tasks at domain boundaries when a group would exceed 30 files.

Success criteria — select PRD acceptance criteria that apply to this task's scope. Write them as testable assertions:

• "POST /api/resource returns 201 with the created resource payload" (not "API works")
• "Page renders the empty state at 1440px without console errors" (not "page looks right")
• "Migration runs cleanly on an empty database" (not "migration works")

Baseline checks — what to capture BEFORE making changes:

• Standard quality gates: tsc, lint, test, build (pass/fail and counts)
• Domain-specific: API endpoints (HTTP status + timing), pages (screenshot + LCP), schema state (table columns and types)

Post-change checks — what to verify AFTER changes, mapped 1:1 to each success criterion.

Performance benchmarks — from PRD NFRs or domain defaults:

• API endpoints: p95 response time target
• Frontend pages: LCP target, bundle size delta
• Database queries: execution time target

Non-functional requirements — scope PRD NFRs to this task's domain:

• Database task → data integrity, migration rollback safety, index strategy
• API task → input validation coverage, auth guard presence, rate limiting
• Frontend task → WCAG compliance level, responsive breakpoints, keyboard navigation

Before saving, validate each document:

• File count ≤ 30
• No file path appears in more than one task
• Every success criterion is testable (specific, measurable outcome)
• Every "create" file has its consumer in the same or a later task
• Task N's dependencies all have numbers < N
• Baseline checks include at minimum: tsc, lint, test, build

Fix any violation before saving.

After saving all tasks, print a summary table: