Link to PRD: PRD title
One paragraph on the technical challenge this design addresses. Don't restate the PRD — reference it. Focus on what makes this technically interesting or risky.
Carried from the PRD, restated in technical terms. Add any technical non-goals discovered during design.
Goals:
Non-Goals:
Architecture overview. Include a Mermaid diagram showing component relationships and data flow.
graph TD
A[Component A] --> B[Component B]
B --> C[Component C]
Subsections as needed for each significant component. Include:
Schema, storage, access patterns. Only if applicable.
Inputs, outputs, error handling for key boundaries.
One subsection per significant decision.
| Option | Pros | Cons | Verdict |
|---|---|---|---|
| Option A | Pro | Con | Chosen — reason |
| Option B | Pro | Con | Rejected — reason |
Files to create, modify, or delete, each with a one-line rationale.
| Action | File | Rationale |
|---|---|---|
| CREATE | path/to/new-file.ts |
Reason |
| MODIFY | path/to/existing.ts |
Reason |
| DELETE | path/to/old-file.ts |
Reason |
Dependency-ordered tasks. Each task is a single coherent change,
testable in isolation. Mark parallelizable tasks with [P].
path/to/file1.ts, path/to/file2.ts[P]path/to/file3.tsScope drifts during implementation. That's expected. Document divergences here as they happen so the design doc stays accurate without a full rewrite. Each entry should state what changed and why the original design was wrong or incomplete.
Unresolved items. State what blocks on each.
Technical risks and wrong assumptions.