write-tddlisted

## 定位 ``` write-prd → [write-tdd] → scaffold-project → 研发 → code-review → 测试 → deploy ``` TDD 的职责是把 PRD 的「做什么」翻��成「怎么做」：将功能需求转化为数据库表结构、 API 接口、模块划分和技术决策，让研发可以直接按文档开始实现。 ## 第一步：获取 PRD 上下文 优先从以下来源读取 PRD 信息（按优先级）： 1. 当前目录 `docs/` 下最新的 `prd-*.md` 文件 2. 用户在对话中提供的 PRD 内容 3. 用户口述的需求描述 从 PRD 中提取： - 产品名称和核心功能列表 - 目标用户和使用场景 - MVP 功能范围（重点） - 技术栈（前端、后端、数据库） 若以上均无，向用户询问以下信息（一次性列出，不要逐条追问）： - 产品名称和核心功能 - 技术栈（未指定则按默认规则推断：前端 React；后端/数据库按项目体量选择） ## 第二步：生成技术设计文档 按以下结构输出 TDD，所有技术均使用最新稳定版本，以官方文档最新版为准。 ``` # [产品/功能名称] 技术设计文档 > 关联 PRD：docs/prd-[功能名]-[日期].md ## 技术栈 | 层级 | 技术选型 | 版本要求 | |------|---------|---------| | 前端 | React | latest | | 后端 | Elysia.js | latest | | 数据库 | SQLite / PostgreSQL | latest | | 部署 | ... | ... | ## 系统架构 用简洁的文字描述整体架构，说明前后端交互方式（REST / WebSocket 等）、 数据流向和关键模块关系。如有必要，附 Mermaid 架构图： ```mermaid graph TD A[前端 React] -->|REST API| B[后端 Elysia.js] B --> C[(数据库)] ``` ## 数据库设计 针对每张核心表，给出字段定义、类型、约束和说明。 使用 MVP 功能范围决定哪些表优先实现。 ### 表：[表名] | 字段 | 类型 | 约束 | 说明 | |------|------|------|------| | id | INTEGER | PRIMARY KEY | 自增主键 | | ... | ... | ... | ... | | created_at | DATETIME | NOT NULL | 创建时间 | | updated_at | DATETIME | NOT NULL | 更新时间 | （ER 关系说明：如有表间关联，用文字或 Mermaid 描述） ## API 设计 遵循 RESTful 规范，按资源分组列出接口。 ### [资源名] | 方法 | 路径 | 说明 | |------|------|------| | GET | /api/[resource] | 获取列表 | | GET | /api/[resource]/:id | 获取单条 | | POST | /api/[resource] | 创建 | | PUT | /api/[resource]/:id | 更新 | | DELETE | /api/[resource]/:id | 删除 | 对关键接口补充请求/响应示例： **POST /api/[re