sdd-full 4.2.0 → 4.3.0

package/skills/requirement-analysis/sdd/SKILL.md

@@ -0,0 +1,1044 @@
+【claude code调用标识：sdd】【trae调用标识：sdd+需求拆分】【流程场景：1.完整3阶段SDD流程、2.从零开始新项目、3.小型功能迭代】
+
+---
+name: sdd
+description: 用于将大型需求拆分为用户故事、UI设计、前后端架构边界、数据库/API契约与子代理可用的SDD功能规格，支持个人开发，适配Superpowers/Trae-CN全流程开发。
+---
+
+# SDD 需求拆分（个人开发版）
+
+## 概述
+
+本技能提供一套**"垂直切片+水平分层"双模式**需求拆分流程，兼顾敏捷快速交付与架构规范，专为个人开发者设计：
+
+**大需求 → 第0步：Epic拆分（超大需求适用）→ 第0.5步：拆用户故事 → 第1步：拆UI设计 → 第2步：拆前后端分离架构 → 第3步：拆数据库+接口 → 第4步：拆SDD**
+
+核心目的：
+- 既保证**快速交付用户价值**，又确保**技术架构规范**
+- 明确前后端**权责边界与协作契约**
+- 产出子代理可直接消费的**SDD功能规格**
+- 适配Superpowers/Trae-CN的**子代理驱动开发**与**测试驱动开发**工作流
+
+---
+
+## 何时使用
+
+- 你有一个**大型、模糊、跨模块**的需求/想法，需要结构化拆解
+- 项目采用**前后端分离架构**，需要明确技术边界
+- 在 **Superpowers / Trae-CN** 中进行**完整全流程开发**
+- 需要**敏捷迭代+架构规范**双保障，既快速交付又避免技术债务
+
+---
+
+## 核心流程
+
+```dot
+digraph requirement_splitting {
+    rankdir=TB;
+    node [shape=box, style=filled, fillcolor=lightblue];
+
+    "大需求":::start -> "第0步:Epic拆分(超大需求)":::epic;
+    "第0步:Epic拆分(超大需求)":::epic -> "第0.5步:拆用户故事":::agile;
+    "第0.5步:拆用户故事":::agile -> "第1步:拆UI设计":::step1;
+    "第1步:拆UI设计":::step1 -> "第2步:拆前后端架构":::step2;
+    "第2步:拆前后端架构":::step2 -> "第3步:拆数据库+接口":::step3;
+    "第3步:拆数据库+接口":::step3 -> "第4步:拆SDD":::step4;
+
+    {rank=same; "大需求"}
+    {rank=same; "第0步:Epic拆分(超大需求)"}
+    {rank=same; "第0.5步:拆用户故事"}
+    {rank=same; "第1步:拆UI设计"}
+    {rank=same; "第2步:拆前后端架构"}
+    {rank=same; "第3步:拆数据库+接口"}
+    {rank=same; "第4步:拆SDD"}
+
+    classDef start fillcolor=lightgreen;
+    classDef epic fillcolor=lightcoral;
+    classDef agile fillcolor=lightcoral;
+    classDef step1 fillcolor=lightcyan;
+    classDef step2 fillcolor=lightcyan;
+    classDef step3 fillcolor=lightcyan;
+    classDef step4 fillcolor=lightyellow;
+}
+```
+
+流程本质：**先垂直切片（用户价值维度），再水平分层（技术栈维度）**
+优势：**既保证独立交付价值，又确保技术架构规范**
+
+---
+
+## 个人敏捷工作流
+
+### 1. 双模式工作流
+
+```
+大需求 → Epic拆分（可选）→ 拆用户故事 → 按故事优先级分批 → 每批内执行水平拆分 → 子代理开发 → 测试验收 → 上线 → 下一批故事
+```
+
+### 2. 关键实践
+
+| 实践 | 具体做法 | 优势 |
+|------|----------|------|
+| 分批交付 | 按用户故事优先级分组，每批1–3个故事，分批完成水平拆分与开发 | 避免全量冻结，支持快速迭代，降低风险 |
+| 并行开发 | 前端按Mock数据开发，后端按契约开发，互不依赖 | 缩短迭代周期，提高开发效率 |
+| 契约版本化 | 每批故事对应一个契约版本，变更只影响当前批次 | 控制变更范围，减少返工成本 |
+| 子代理适配 | 每个SDD对应一个子代理任务，完成后自动审查 | 适配Superpowers/Trae-CN工作流，保证质量 |
+
+---
+
+## 第0步：Epic拆分（超大需求适用）
+
+### 目标
+
+将**跨越多个Sprint、涉及多模块**的超大需求（Epic）拆分为可管理的Feature和Story，确保价值渐进交付，降低风险。
+
+### Epic定义与识别标准
+
+什么是Epic？
+- **范围**：预计超过2周完成
+- **价值**：代表宏观用户价值或业务目标
+- **特点**：模糊性高，细节不明确，需要进一步拆解
+
+何时需要先拆Epic？
+✅ 需求描述中包含"完整""全部""全面"等词汇
+✅ 估算工作量>10人天
+✅ 涉及≥3个核心模块
+✅ 跨平台需求且各平台工作量不均衡
+
+### Epic三层拆分法（Epic→Feature→Story）
+
+```markdown
+# Epic拆分示例：电商购物流程
+
+## 1. Epic（顶级）
+- 名称：构建完整电商购物流程
+- 价值：用户可浏览商品→加入购物车→结算→支付→查看订单
+- 估算：6周
+
+## 2. Feature（中层，按业务流程拆分）
+- Feature 1：商品浏览与搜索（第1–2周）
+- Feature 2：购物车管理（第2–3周）
+- Feature 3：订单创建与管理（第3–4周）
+
+## 3. Story（底层，按用户价值拆分）
+### Feature 1：商品浏览与搜索
+- US-001：浏览商品列表
+- US-002：搜索商品
+- US-003：查看商品详情
+```
+
+### 6种Epic拆分模式（按场景选择）
+
+| 拆分模式 | 适用场景 | 示例 |
+|----------|----------|------|
+| **按用户旅程拆分** | 有明确用户操作流程的功能 | 购物流程：浏览→详情→加购→结算→订单 |
+| **按功能模块拆分** | 模块化强的系统 | 电商系统：用户→商品→订单→支付 |
+| **按平台适配拆分** | 跨平台开发 | 登录功能：Web→iOS→Android |
+| **按复杂度分层拆分** | 功能复杂度差异大的功能 | 搜索功能：基础搜索→高级筛选→智能推荐 |
+| **按时间阶段拆分** | 有明确时间节点的功能 | 会员系统：MVP版→高级版→尊享版 |
+
+---
+
+## 第0.5步：拆用户故事
+
+### 目标
+
+把大需求拆成**可独立交付、有用户价值**的用户故事，每个故事覆盖"页面+交互+业务+数据"完整链路，符合**INVEST原则**（独立、可协商、有价值、可估算、小、可测试）。
+
+### 产出
+
+`docs/stories/user_stories.md`
+
+### 故事模板
+
+```markdown
+# 用户故事清单
+
+## 格式
+
+作为[用户角色]，我想要[功能]，以便[价值]
+
+## Epic（可选，用于超大需求）
+
+### Epic：用户认证与授权
+
+包含用户注册、登录、权限管理等相关功能。
+
+## 核心故事（按优先级排序）
+
+### 故事1：用户登录系统
+- **优先级**：P0（最高）
+- **估算**：3天（或5故事点）
+- **内容**：作为未登录用户，我想要登录系统，以便访问个人中心和下单
+- **验收标准（BDD格式）**：
+  - Given 用户未登录，访问登录页
+  - When 输入正确用户名密码并点击登录
+  - Then 登录成功，跳转到首页
+  - And Token保存到本地存储
+- **验收标准（规则列表）**：
+  - ✅ 用户可以通过用户名/密码登录
+  - ✅ 登录成功后跳转到首页
+  - ✅ 登录失败显示友好提示
+  - ✅ 支持"记住我"功能（7天免登录）
+- **关联页面**：登录页
+- **前置依赖**：无
+- **非功能需求**：页面响应时间≤2秒
+
+### 故事2：浏览商品列表
+- **优先级**：P0
+- **估算**：2天
+- **内容**：作为登录用户，我想要浏览商品列表，以便选择商品
+- **验收标准**：
+  - Given 用户已登录，访问首页
+  - When 查看商品列表
+  - Then 显示商品按分类展示，支持分页
+- **关联页面**：首页、商品列表页
+- **前置依赖**：故事1
+
+### 故事3：查看商品详情
+- **优先级**：P1
+- **估算**：2天
+- **内容**：作为登录用户，我想要查看商品详情，以便了解商品信息
+- **验收标准**：显示商品完整信息（图片、描述、价格、库存）
+- **关联页面**：商品详情页
+- **前置依赖**：故事2
+```
+
+### 故事验收标准编写黄金法则
+
+1. **可测试性**：每个标准都能被验证，避免模糊表述（如"应该很快"→"响应时间≤2秒"）
+2. **无歧义**：使用精确术语，避免主观描述
+3. **完整性**：覆盖主流程、异常流程、边界条件
+4. **价值导向**：始终围绕用户价值，不包含技术实现细节
+
+### 三种验收标准格式
+
+#### 1. BDD场景格式（推荐）
+```markdown
+### 主场景
+Given [初始状态/前置条件]
+When [用户执行的关键动作]
+Then [系统预期结果]
+And [附加验证点1]
+```
+
+#### 2. 规则列表格式（适合简单功能）
+```markdown
+- ✅ 必须支持用户名/邮箱/手机号三种登录方式
+- ✅ 密码输入框必须隐藏明文显示
+- ✅ 登录按钮在表单未填写完整时禁用
+```
+
+#### 3. 多平台矩阵格式（适合复杂跨平台功能）
+| 场景 | 操作 | 预期结果（Web） | 预期结果（iOS） |
+|------|------|----------------|----------------|
+| 正常登录 | 输入正确账号密码 | 跳转首页 | 跳转首页 |
+
+### 敏捷故事拆分方法
+
+| 方法 | 适用场景 | 示例 |
+|------|----------|------|
+| 按用户旅程拆分 | 有明确用户操作流程的功能 | 购物流程：浏览→详情→加购→结算→订单 |
+| 按数据边界拆分 | 包含多数据实体的功能 | 简历功能：基本信息→工作经历→教育背景 |
+| 按操作路径拆分 | 有多种执行路径的功能 | 登录功能：正常登录→忘记密码→注册 |
+| 按优先级拆分 | 大型复杂功能 | 支付功能：基础支付→优惠券→积分抵扣 |
+
+### 故事拆分原则
+
+1. 每个故事必须**可独立交付**，能直接给用户带来价值
+2. 每个故事覆盖**UI+前端交互+后端业务+数据库**完整链路
+3. 故事粒度以**1–3天**可完成为宜
+4. 优先拆分**核心价值**故事，再拆分边缘功能
+5. 每个故事必须有明确的**验收标准**和**优先级**
+
+---
+
+## 第1步：拆UI设计
+
+### 目标
+
+把用户故事拆成**页面清单 + 页面范围说明**，只关心"用户看到什么、怎么操作"，**不涉及技术实现、接口、数据库**。
+
+### 产出
+
+`docs/ui/pages.md`
+
+### 模板
+
+```markdown
+# UI 页面清单
+
+## 1. 公共页面
+
+- 登录页（/login）：用户登录入口，关联故事1
+- 注册页（/register）：新用户注册入口
+- 404页：页面不存在时显示
+- 500页：服务器错误时显示
+
+## 2. 业务页面（按用户故事旅程拆分）
+
+- 首页（/home）：关联故事2，展示推荐商品和分类导航
+- 商品列表页（/goods/list）：关联故事2，展示商品列表和筛选
+- 商品详情页（/goods/detail/:id）：关联故事3，展示商品完整信息
+- 购物车页（/cart）：关联故事4，展示购物车商品和操作
+- 结算页（/checkout）：关联故事5，确认订单信息和支付
+- 订单列表页（/order/list）：展示用户历史订单
+- 订单详情页（/order/detail/:id）：关联故事5，展示订单详细信息
+- 个人中心（/profile）：用户信息管理
+
+## 3. 设计规范
+
+- 设计工具：Figma / 手绘稿
+- 主色：#165DFF
+- 字体：Inter，基础字号 14px
+- 响应式：桌面优先，兼容平板（1024px以上）
+- 组件库：使用Ant Design（或指定其他）
+```
+
+### 拆分原则
+
+- **一个独立页面 = 一条记录**，不合并
+- 只拆**页面路由、页面名称、核心用途**，关联对应的用户故事
+- **严禁**出现接口字段、表结构、技术选型
+- 覆盖**核心用户旅程**，边缘页面可后续补充
+
+---
+
+## 第2步：拆前后端分离架构
+
+### 目标
+
+明确**前端做什么、后端做什么、依赖关系**，一刀切开前后端边界，**互不越界、各司其职**，同时支持敏捷并行开发。
+
+### 产出
+
+`docs/architecture/frontend-backend.md`
+
+### 模板
+
+```markdown
+# 前后端分离架构
+
+## 1. 前端职责
+
+- 页面渲染（UI 见 docs/ui/pages.md）
+- 路由管理（/login、/goods/list…）
+- 客户端状态管理（用户信息、购物车）
+- 表单校验、交互反馈、异常提示
+- 调用后端 RESTful API（不写核心业务逻辑）
+- Mock数据并行开发，不依赖后端进度
+
+## 2. 后端职责
+
+- 提供 RESTful API（契约见 docs/api/contract.md）
+- 核心业务逻辑（下单、支付、库存扣减、权限校验）
+- 数据库读写（表结构见 docs/database/schema.md）
+- 数据校验、鉴权、限流、日志、事务
+- 无页面渲染、无交互逻辑
+- 按接口契约开发
+
+## 3. 分离边界
+
+- 前端：**无数据库、无核心业务逻辑** → 只发请求、渲染结果
+- 后端：**无页面、无交互** → 只处理数据、返回标准 JSON
+- 协作模式：前端 Mock 并行开发；后端按契约开发；联调前先对齐契约
+- 敏捷迭代：按用户故事优先级分批交付，每批完成后进行回归测试
+
+## 4. 技术选型（可选）
+
+- 前端框架：React / Vue / Angular
+- 状态管理：Redux / Vuex / MobX
+- UI组件库：Ant Design / Element Plus
+- 后端框架：Node.js / Java / Python / Go
+- 数据库：MySQL / PostgreSQL / MongoDB
+- 缓存：Redis
+```
+
+### 拆分原则
+
+- **单一职责**：前端=UI/交互；后端=业务/数据
+- **依赖单向**：前端依赖后端 API；后端不依赖前端
+- **边界刚性**：不允许前端写复杂业务、不允许后端渲染页面
+- **敏捷适配**：支持按用户故事分批交付，不要求全量完成后再上线
+
+---
+
+## 第3步：拆数据库+接口
+
+### 目标
+
+定义**数据库表结构 + RESTful API 契约**，作为前后端协作的**唯一事实来源**，支持敏捷迭代中的契约版本管理。
+
+### 产出
+
+- `docs/database/schema.md`（表结构）
+- `docs/api/contract.md`（接口契约）
+
+### 数据库模板
+
+```markdown
+# 数据库设计
+
+## 用户表（user）- 关联故事1
+
+- id（PK，自增，BIGINT）
+- username（唯一，VARCHAR(50)，用户名）
+- password（VARCHAR(255)，加密存储）
+- email（唯一，VARCHAR(100)）
+- avatar（VARCHAR(255)，头像URL，可选）
+- status（TINYINT，状态：0-禁用，1-正常）
+- create_time（DATETIME，创建时间）
+- update_time（DATETIME，更新时间）
+
+## 商品表（goods）- 关联故事2、3
+
+- id（PK，自增，BIGINT）
+- name（VARCHAR(200)，商品名称）
+- description（TEXT，商品描述）
+- price（DECIMAL(10,2)，价格）
+- original_price（DECIMAL(10,2)，原价）
+- stock（INT，库存）
+- status（TINYINT，状态：0-下架，1-上架）
+- category_id（FK，分类ID）
+- main_image（VARCHAR(255)，主图URL）
+- create_time（DATETIME，创建时间）
+- update_time（DATETIME，更新时间）
+
+## 购物车表（cart）- 关联故事4
+
+- id（PK，自增，BIGINT）
+- user_id（FK → user.id）
+- goods_id（FK → goods.id）
+- quantity（INT，数量）
+- create_time（DATETIME，创建时间）
+- update_time（DATETIME，更新时间）
+
+## 订单表（order）- 关联故事5
+
+- id（PK，自增，BIGINT）
+- order_no（VARCHAR(50)，订单号，唯一）
+- user_id（FK → user.id）
+- total_price（DECIMAL(10,2)，订单总价）
+- status（TINYINT，状态：0-待支付，1-已支付，2-已发货，3-已完成，4-已取消）
+- address（JSON，收货地址）
+- create_time（DATETIME，创建时间）
+- update_time（DATETIME，更新时间）
+
+## 订单项表（order_item）- 关联故事5
+
+- id（PK，自增，BIGINT）
+- order_id（FK → order.id）
+- goods_id（FK → goods.id）
+- goods_name（VARCHAR(200)，商品名称快照）
+- goods_price（DECIMAL(10,2)，商品价格快照）
+- quantity（INT，购买数量）
+- create_time（DATETIME，创建时间）
+
+## 索引设计
+
+- user表：username、email
+- goods表：category_id、status
+- cart表：user_id
+- order表：user_id、order_no
+- order_item表：order_id
+```
+
+### 接口契约模板
+
+```markdown
+# 接口契约（RESTful，JSON，版本 v1）
+
+## 通用规则
+
+- 基础路径：/api/v1
+- 请求/响应格式：JSON
+- 认证：JWT（请求头 Authorization: Bearer {token}）
+- 版本管理：每批用户故事交付后更新契约版本
+- 响应统一格式：
+
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {}
+}
+```
+
+## 用户模块（关联故事1）
+
+### POST /api/v1/auth/login - 用户登录
+
+请求：
+```json
+{
+  "username": "string",
+  "password": "string",
+  "remember": false
+}
+```
+
+响应成功（200）：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {
+    "token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
+    "user": {
+      "id": 1,
+      "username": "user1",
+      "email": "user1@example.com",
+      "avatar": "https://example.com/avatar.jpg"
+    }
+  }
+}
+```
+
+响应失败（401）：
+```json
+{
+  "code": 401,
+  "message": "用户名或密码错误",
+  "data": null
+}
+```
+
+### POST /api/v1/auth/register - 用户注册
+
+请求：
+```json
+{
+  "username": "string",
+  "password": "string",
+  "email": "string"
+}
+```
+
+### GET /api/v1/user/info - 获取当前用户信息
+
+需要认证。
+
+响应：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {
+    "id": 1,
+    "username": "user1",
+    "email": "user1@example.com",
+    "avatar": "https://example.com/avatar.jpg",
+    "createTime": "2024-01-01T00:00:00Z"
+  }
+}
+```
+
+## 商品模块（关联故事2、3）
+
+### GET /api/v1/goods/list - 商品列表（分页）
+
+请求参数（Query）：
+- page（INT，页码，默认1）
+- pageSize（INT，每页数量，默认20）
+- categoryId（INT，分类ID，可选）
+- keyword（STRING，搜索关键词，可选）
+
+响应：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {
+    "list": [
+      {
+        "id": 1,
+        "name": "商品名称",
+        "price": 99.99,
+        "originalPrice": 199.99,
+        "mainImage": "https://example.com/image.jpg",
+        "status": 1,
+        "stock": 100
+      }
+    ],
+    "total": 100,
+    "page": 1,
+    "pageSize": 20
+  }
+}
+```
+
+### GET /api/v1/goods/detail/:id - 商品详情
+
+响应：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {
+    "id": 1,
+    "name": "商品名称",
+    "description": "商品描述",
+    "price": 99.99,
+    "originalPrice": 199.99,
+    "mainImage": "https://example.com/image.jpg",
+    "images": ["url1", "url2"],
+    "status": 1,
+    "stock": 100,
+    "createTime": "2024-01-01T00:00:00Z"
+  }
+}
+```
+
+## 购物车模块（关联故事4）
+
+### POST /api/v1/cart/add - 添加商品到购物车
+
+需要认证。
+
+请求：
+```json
+{
+  "goodsId": 1,
+  "quantity": 2
+}
+```
+
+### GET /api/v1/cart/list - 获取购物车列表
+
+需要认证。
+
+响应：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": [
+    {
+      "id": 1,
+      "goodsId": 1,
+      "goodsName": "商品名称",
+      "goodsPrice": 99.99,
+      "mainImage": "https://example.com/image.jpg",
+      "quantity": 2,
+      "stock": 100
+    }
+  ]
+}
+```
+
+## 订单模块（关联故事5）
+
+### POST /api/v1/order/create - 创建订单
+
+需要认证。
+
+请求：
+```json
+{
+  "addressId": 1,
+  "paymentMethod": "alipay"
+}
+```
+
+响应：
+```json
+{
+  "code": 0,
+  "message": "success",
+  "data": {
+    "orderId": 1,
+    "orderNo": "ORD202401010001"
+  }
+}
+```
+
+### GET /api/v1/order/list - 订单列表
+
+需要认证。
+
+### GET /api/v1/order/detail/:id - 订单详情
+
+需要认证。
+```
+
+### 拆分原则
+
+- **先数据、后接口**：表结构稳定后再定义接口
+- **资源命名 RESTful**：名词复数、HTTP 方法语义化
+- **契约即法律**：开发前必须固化契约，变更需同步更新
+- **敏捷适配**：按用户故事分批定义契约，支持增量交付，不要求一次性定全量
+
+---
+
+## 第4步：拆SDD
+
+### 前提
+
+**用户故事 → UI → 架构 → 数据库/接口按批次固化后**，再拆对应批次的 SDD。
+
+SDD 是**给子代理的最小可执行单元**：一个 SDD = 一个用户故事/子故事 = 一个子代理任务，符合**垂直切片**原则。
+
+### 目标
+
+把"页面+接口+数据"按**用户故事维度垂直切分**，生成子代理可直接执行、测试、交付的规格文档，适配 Superpowers/Trae-CN 的**子代理驱动开发**与**测试驱动开发**工作流。
+
+### SDD 目录结构
+
+```
+specs/
+  story1-login/
+    login-frontend.md
+    login-backend.md
+  story2-goods/
+    goods-list-frontend.md
+    goods-list-backend.md
+    goods-detail-frontend.md
+    goods-detail-backend.md
+  story3-order/
+    ...
+```
+
+### 单个 SDD 模板
+
+```markdown
+# SDD：用户登录（关联用户故事1）
+
+## 1. 目标
+
+一句话清晰描述本功能要实现的业务价值（与用户故事一致）。
+
+让用户可以通过用户名和密码安全登录系统，获取访问权限。
+
+## 2. 依赖
+
+- 页面：登录页（引用 docs/ui/pages.md）
+- 接口：POST /api/v1/auth/login（引用 docs/api/contract.md）
+- 数据库：user表（引用 docs/database/schema.md）
+- 架构：前后端分离（引用 docs/architecture/frontend-backend.md）
+- 前置故事：无
+
+## 3. 验收标准（BDD风格）
+
+### 正常流程
+
+- Given 用户未登录，访问登录页
+- When 输入正确的用户名和密码，点击登录按钮
+- Then 登录成功，跳转到首页，显示用户信息
+- And Token保存到本地存储，支持自动登录
+
+### 异常流程
+
+- Given 用户未登录，访问登录页
+- When 输入错误的用户名或密码，点击登录按钮
+- Then 显示"用户名或密码错误"提示，停留在登录页
+
+- Given 用户未登录，访问登录页
+- When 用户名或密码为空，点击登录按钮
+- Then 显示字段验证提示
+
+- Given 用户已登录，访问登录页
+- When 页面加载
+- Then 自动跳转到首页
+
+## 4. 非功能需求
+
+- **性能**：页面响应时间≤2秒，API响应时间≤500ms
+- **安全**：密码加密传输，使用HTTPS
+- **兼容**：兼容主流浏览器
+
+## 5. 技术风险
+
+- **风险**：密码明文传输
+- **缓解措施**：使用HTTPS，密码加密传输
+- **风险**：暴力破解
+- **缓解措施**：添加登录失败次数限制，超过5次锁定15分钟
+
+## 6. 测试要点
+
+- 单元测试：登录表单验证、Token存储逻辑
+- 接口测试：正常登录、错误密码、空参数
+- E2E测试：完整登录流程
+- 安全测试：SQL注入、XSS防护
+
+## 7. 子代理执行说明
+
+- 角色：全栈 / 前端+后端
+- 产出：代码 + 单元测试 + 接口/页面联调通过
+- 实践：
+  1. 遵循 TDD 流程：先写测试 → 再写代码 → 重构
+  2. 完成后通过两阶段审查：spec合规性审查 → 代码质量审查
+  3. 审查通过后提交，进入下一个子任务
+```
+
+### 拆分原则
+
+- **垂直切片**：每个 SDD 覆盖UI+接口+数据完整链路，可独立交付价值
+- **故事驱动**：SDD 严格对应用户故事，不跨故事拆分
+- **依赖显式化**：所有依赖必须引用已固化的设计文档
+- **验收标准可测试**：采用 BDD 风格，输入输出明确，无模糊描述
+
+---
+
+## 非功能需求处理指南
+
+### 非功能需求分类与处理方式
+
+| 分类 | 示例 | 处理方式 | 优先级 |
+|------|------|----------|--------|
+| **性能** | 响应时间≤2秒，并发用户≥100 | 融入Story验收标准 | 高 |
+| **安全性** | 数据加密，权限控制，防SQL注入 | 融入DoD + 独立测试 | 最高 |
+| **可用性** | 系统可用性≥99.9% | 架构设计 | 高 |
+| **兼容性** | 适配iOS 14+，Android 10+ | 平台适配Story | 中 |
+| **可维护性** | 代码覆盖率≥80% | 融入DoD | 中 |
+
+### 个人DoD（完成的定义）
+
+```markdown
+# 个人DoD（包含非功能需求）
+
+1. 功能通过所有验收测试
+2. 代码通过静态分析，无高危漏洞
+3. 单元测试覆盖率≥80%
+4. 页面响应时间≤2秒
+5. 适配目标平台所有主流版本
+6. 符合安全规范（如OWASP Top 10防护）
+7. 文档更新完成
+```
+
+### 非功能需求融入验收标准示例
+
+```markdown
+## 故事ID: US-001（商品搜索）
+
+**验收标准**：
+1. 功能：支持关键词搜索、分类筛选、价格区间筛选
+2. 性能：搜索结果返回时间≤1秒（1000条数据）
+3. 可用性：无结果时显示友好提示，提供推荐商品
+4. 兼容性：在所有目标平台显示一致
+```
+
+---
+
+## 故事估算方法指南
+
+### 两种核心估算方法对比
+
+| 估算方法 | 定义 | 优点 | 缺点 | 适用场景 |
+|------|------|------|------|------|
+| **理想人天** | 无中断情况下完成任务的时间（人天） | 直观易懂，适合个人开发 | 受个人能力影响大 | 个人开发、小项目 |
+| **故事点** | 相对工作量单位，基于复杂度综合评估 | 不依赖个人能力，长期稳定 | 需要历史数据校准 | 长期项目 |
+
+### 理想人天估算方法（推荐个人开发使用）
+
+```markdown
+# 理想人天定义
+
+1. 理想人天 = 纯开发时间，不含会议、沟通、测试、中断
+2. 1理想人天 = 8小时专注开发时间
+3. 实际时间 ≈ 理想人天 × 1.5（考虑各种中断）
+
+# 任务分解估算示例
+
+## 故事ID: US-001（登录功能）
+
+### 任务分解：
+1. UI设计：0.5理想人天
+2. 前端开发：1理想人天
+3. 后端API开发：1理想人天
+4. 集成测试：0.5理想人天
+
+### 总估算：3理想人天
+### 实际计划：4.5天（考虑缓冲）
+```
+
+### 估算避坑指南
+
+#### ❌ 常见错误
+
+1. **过度乐观**：忽视边界条件和异常处理
+2. **技术镀金**：考虑超出需求的功能
+3. **依赖忽视**：未考虑外部系统依赖
+4. **估算疲劳**：连续估算太多Story，导致准确性下降
+
+#### ✅ 最佳实践
+
+1. **拆分先行**：先拆分为符合INVEST标准的Story，再估算
+2. **历史参考**：参考类似Story的历史估算和实际时间
+3. **缓冲预留**：计划时预留30-50%缓冲时间应对突发情况
+4. **回顾校准**：每个迭代后回顾估算准确性，调整方法
+
+---
+
+## 最终目录结构
+
+```
+项目根/
+├── brainstorm.md              # 原始大需求
+├── docs/
+│   ├── stories/
+│   │   └── user_stories.md    # 用户故事
+│   ├── ui/
+│   │   └── pages.md           # UI页面清单
+│   ├── architecture/
+│   │   └── frontend-backend.md # 前后端架构边界
+│   ├── database/
+│   │   └── schema.md          # 数据库表结构
+│   └── api/
+│       └── contract.md        # 接口契约
+└── specs/                     # SDD功能规格
+    ├── story1-login/
+    ├── story2-goods/
+    └── story3-order/
+```
+
+---
+
+## Superpowers / Trae-CN 操作指南
+
+1. 先完成 `docs/stories/user_stories.md`，确定**故事优先级**与**分批计划**
+2. 按批次完成 `docs/` 下设计文档（UI→架构→数据库→接口）
+3. 用 `/spec` 命令按故事生成 `specs/xxx/xxx.md` SDD 文件，每个 SDD 对应一个子代理任务
+4. 执行子代理驱动开发：`@specs/xxx/xxx.md`，每个子代理完成后自动进行**spec合规性审查**与**代码质量审查**
+5. 批次内所有 SDD 完成后，进行**集成测试**
+6. 验收通过后上线，进入下一批故事开发
+
+---
+
+## 常见错误与修复
+
+### 错误：水平拆分优先于垂直切片
+
+- **问题**：先做全量UI/架构/契约，再拆故事，导致迭代周期长、变更成本高
+- **修复**：**先拆用户故事，再按故事分批做水平拆分**
+
+### 错误：SDD 粒度过大，跨多个故事
+
+- **问题**：子代理无法独立完成，交付周期长，风险集中
+- **修复**：SDD 严格对应**单个用户故事/子故事**，粒度控制在**1–3天**可完成
+
+### 错误：契约未版本化，变更影响全量
+
+- **问题**：需求变更导致全量契约与代码返工
+- **修复**：**按批次版本化管理契约**，变更只影响当前批次
+
+### 错误：忽略非功能需求
+
+- **问题**：功能完成后发现性能、安全等问题
+- **修复**：**将非功能需求融入DoD或Story验收标准**
+
+---
+
+## 合理性、边界与适应场景
+
+### 合理性（适合场景）
+
+- **敏捷+架构规范双需求**的项目（互联网产品、中后台系统）
+- **大型复杂需求**，需要同时保证快速交付与技术可控
+- **Superpowers/Trae-CN 环境**，需要适配子代理驱动开发与测试驱动开发
+- **个人开发**，流程轻量但规范
+
+### 边界（固有约束）
+
+- **批次内强时序依赖**：每批内必须 1→2→3→4，前一步未固化无法进入下一步
+- **批次间并行有限**：批次按优先级顺序执行，无法完全并行
+
+### 不适应场景
+
+- **纯探索型项目**（需求完全不确定，每天都在变）
+- **非Web系统**（移动端原生、IoT、强实时系统）
+- **纯瀑布项目**（要求全量设计完成后再开发）
+
+---
+
+## 快速参考表
+
+| 步骤 | 产出文件 | 核心关注点 |
+|------|----------|------------|
+| 0 | docs/stories/user_stories.md | 用户价值、垂直切片 |
+| 1 | docs/ui/pages.md | 用户看到什么、操作什么 |
+| 2 | docs/architecture/frontend-backend.md | 前后端技术边界、权责划分 |
+| 3 | docs/database/schema.md + docs/api/contract.md | 数据结构、接口契约 |
+| 4 | specs/xxx/xxx.md | 独立功能规格、子代理任务 |
+
+---
+
+## 与 ui-sdd、sdd-add 的配置建议
+
+### 三层架构定位
+
+| 技能 | 核心定位 | 层级 | 产出 |
+|------|---------|------|------|
+| **sdd** | 需求层·业务拆分 | 顶层 | docs/stories/、docs/ui/pages.md、docs/architecture/、docs/database/、docs/api/、specs/ |
+| **ui-sdd** | 架构层·UI交互 | 中层 | spec/ui/ 下完整 SDD（100%覆盖） |
+| **sdd-add** | 迭代层·快速迭代 | 底层 | docs/temp-requirements/ 下临时迭代 |
+
+### 完整流程配置
+
+#### 项目从零启动（需求→UI→实现）
+
+1. **先用 sdd**：拆 Epic→Feature→Story，写验收标准、做估算
+2. **再用 ui-sdd**：对 Story 中的 UI/交互需求，按「App全域盘点清单」勾出所有页面/组件/规则，建完整 SDD
+3. **交付开发**（或用 sdd-add 做快速实现）
+
+#### 正常迭代开发（日常新功能）
+
+1. **先用 sdd**：把新功能拆成 Story，写验收标准
+2. **再用 ui-sdd**：回「盘点清单」补勾，补建/更新 spec/ui/ 下的 SDD
+3. **最后用 sdd-add**：做快速实现，需求文档中必须**引用 sdd 的 Story 和 ui-sdd 的 SDD**
+
+#### 临时需求/紧急修复
+
+1. **直接用 sdd-add**：快速澄清、优先级、实现
+2. **如果涉及 UI/新增页面**：必须同步回 ui-sdd：补勾、补建 SDD
+3. **如果涉及 Story 拆分**：必须同步回 sdd：补 Story
+
+### 文档关联引用规范
+
+#### sdd Story 中引用 ui-sdd
+
+在 sdd 产出的 Story 文档中加入：
+
+```markdown
+## 关联文档
+
+- 对应UI交互SDD：spec/ui/pages/xxx-page.sdd.md
+- 复用组件SDD：spec/ui/common/ui-yyy.sdd.md
+- 相关弹窗SDD：spec/ui/dialog/zzz-dialog.sdd.md
+```
+
+#### ui-sdd SDD 中引用 sdd Story
+
+在 ui-sdd 产出的页面/组件SDD中加入：
+
+```markdown
+## 关联用户故事
+
+- 主故事：US-001（在 docs/stories/user_stories.md）
+- 相关故事：US-002、US-003
+```
+
+#### sdd-add 临时需求中引用前两者
+
+在 sdd-add 产出的临时需求文档中加入：
+
+```markdown
+## 关联文档
+
+- 关联Story：docs/stories/user_stories.md 中的 US-xxx
+- 关联UI-SDD：spec/ui/pages/yyy-page.sdd.md
+```
+
+### 高频场景决策表
+
+| 场景 | 第1步用 | 第2步用 | 第3步用 |
+|------|---------|---------|---------|
+| 新项目从零开始 | sdd（需求拆分） | ui-sdd（UI设计） | 开发 |
+| 新增完整Story | sdd（Story拆分） | ui-sdd（补SDD） | 开发 |
+| 临时小功能 | sdd-add（快速处理） | ui-sdd（可选，需UI） | 开发 |
+| 新增复杂Epic | sdd（Epic拆分） | ui-sdd（批量建SDD） | 分批开发 |
+| 临时小bug修复 | sdd-add | 无需 | 快速修复 |
+| 优化现有交互 | sdd（更新Story） | ui-sdd（更新SDD） | sdd-add（实现） |
+
+### 一句话原则
+
+**「sdd 定方向（做什么），ui-sdd 定样子（怎么做），sdd-add 填细节（快速补）；从上往下拆，从下往上补，互相引用不遗漏」**