flower-trellis 0.1.0

package/enhancements/old/.agents/skills/check-prd-impl/SKILL.md

@@ -0,0 +1,190 @@
+---
+name: check-prd-impl
+description: "对照 PRD 检查实现 — 逐条追踪代码是否正确完成 PRD 需求和 AC，找出需求级 BUG（实现偏差、未实现、文案不一致）"
+---
+# 对照 PRD 检查实现 — 找出需求级 BUG
+
+对照当前任务的 `prd.md`，逐条检查代码实现是否正确完成了 PRD 中的每一项需求和验收标准。重点不是代码风格，而是**行为是否符合需求**。
+
+> **定位**：与其他 check 命令互补。
+> - `check` — 代码规不规范（vs spec）
+> - `check-cross-layer` — 改全了没（vs git diff）
+> - `check-impl` — 假设对不对（vs 源码/真实数据）
+> - **`check-prd-impl`（本命令）** — **实现对不对（vs PRD）**
+
+---
+
+## 核心原则（不可违反）
+
+1. **PRD 是验收标准** — 每条 Requirement 和 AC 都必须在代码中找到对应实现，找不到即为缺失
+2. **逐条追踪，不跳不漏** — 不能只看 happy path，PRD 中提到的边界条件、异常处理、空值场景都要追踪
+3. **读代码，不猜代码** — 必须实际读到实现代码，不能因为"应该写了"就标记通过
+4. **文案逐字比对** — PRD 中的 UI 文案（按钮、提示语、Toast、弹窗、表头、placeholder）必须与代码中的字面值**完全一致**
+5. **只报事实，不加发挥** — 报告中只陈述 PRD 要求 vs 代码实现的差异，不要加入 PRD 之外的建议
+
+---
+
+## 执行步骤
+
+### Step 1: 获取 PRD 和变更范围
+
+```bash
+# 获取当前任务
+python3 ./.trellis/scripts/task.py list
+```
+
+读取任务目录下的 `prd.md`。如果不存在，提示用户先创建。
+
+同时获取本次实现的变更范围：
+
+```bash
+git diff --name-only
+git log --oneline -10
+```
+
+### Step 2: 分解 PRD 为可验证条目
+
+将 PRD 拆解为独立的、可验证的条目。每条必须是可以在代码中追踪的具体行为：
+
+**提取来源（按优先级）**：
+1. **Acceptance Criteria** — 最直接的验证条目
+2. **Requirements** — 每条需求对应的行为
+3. **业务规则** — PRD 中描述的条件判断、计算逻辑、状态流转
+4. **UI 文案** — PRD 中出现的所有用户可见文字
+5. **边界/异常场景** — PRD 中提到的空值处理、上限、错误提示等
+
+每条记录格式：
+```
+[条目ID] <PRD 原文摘要> — 来源：<PRD 中的位置>
+```
+
+### Step 3: 逐条追踪代码实现
+
+对每个条目，**在代码中找到对应实现**并验证：
+
+#### 3.1 定位实现代码
+
+根据条目类型确定搜索策略：
+
+| 条目类型 | 搜索方法 |
+|---------|---------|
+| API 接口行为 | 找 Controller → Service → DAO，追踪完整链路 |
+| 前端交互行为 | 找组件文件，检查事件处理、状态管理 |
+| 数据校验规则 | 前端 rules + 后端 validator/service 校验，两端都要查 |
+| UI 文案 | grep 关键字，在前端代码中精确匹配 |
+| 计算/转换逻辑 | 定位 service 层实现，读具体算法 |
+| 状态流转 | 追踪状态枚举定义 + 转换条件代码 |
+
+#### 3.2 验证实现正确性
+
+对每条标记状态：
+
+| 状态 | 含义 | 说明 |
+|------|------|------|
+| ✅ 已实现 | 代码正确实现了 PRD 要求 | 已读代码确认 |
+| ❌ 实现偏差 | 代码实现了，但行为与 PRD 描述不一致 | 标注 PRD 要求 vs 实际行为 |
+| 🔴 未实现 | 代码中找不到对应实现 | 标注缺失的功能点 |
+| ⚠️ 部分实现 | 核心逻辑有，但缺少边界/异常处理 | 标注缺失的场景 |
+| 🟡 文案不一致 | UI 文案与 PRD 不逐字一致 | 列出 PRD 文案 vs 代码文案 |
+
+#### 3.3 重点检查场景
+
+以下场景最容易出 BUG，**必须逐一检查**：
+
+- **条件判断** — PRD 说"当 X 时做 Y"，代码的 if 条件是否完整？是否漏了边界值？
+- **空值/零值** — PRD 提到的字段，代码在该字段为空时是否有处理？
+- **列表为空** — PRD 涉及列表展示，列表为空时是否有空状态/提示？
+- **并发/时序** — PRD 涉及多步操作，代码是否处理了中间状态？
+- **权限控制** — PRD 提到的按钮/操作，代码是否加了权限判断？
+- **前后端一致** — 同一条规则前后端是否都实现了？（如校验规则）
+
+### Step 4: 输出检查报告
+
+```markdown
+## PRD 实现检查报告
+
+### 任务: <任务名称>
+### PRD: <prd.md 路径>
+
+---
+
+### 一、总览
+
+- PRD 可验证条目数: N
+- ✅ 已实现: X 条
+- ❌ 实现偏差: X 条
+- 🔴 未实现: X 条
+- ⚠️ 部分实现: X 条
+- 🟡 文案不一致: X 条
+
+---
+
+### 二、问题清单（仅列出非 ✅ 的条目）
+
+#### ❌ 实现偏差
+
+##### [条目ID] <PRD 原文摘要>
+- **PRD 要求**: <原文>
+- **实际实现**: <代码行为描述>
+- **代码位置**: <文件路径:行号>
+- **偏差说明**: <具体差异>
+
+#### 🔴 未实现
+
+##### [条目ID] <PRD 原文摘要>
+- **PRD 要求**: <原文>
+- **预期实现位置**: <应该在哪个文件/模块>
+- **说明**: <为什么判断未实现>
+
+#### ⚠️ 部分实现
+
+##### [条目ID] <PRD 原文摘要>
+- **PRD 要求**: <原文>
+- **已实现部分**: <描述>
+- **缺失部分**: <描述>
+- **代码位置**: <文件路径:行号>
+
+#### 🟡 文案不一致
+
+| PRD 文案 | 代码文案 | 代码位置 |
+|---------|---------|---------|
+
+---
+
+### 三、结论
+- <总结评价：实现完成度>
+- <高风险问题（如有）>
+- <建议优先修复项>
+```
+
+### Step 5: 修复问题（需用户确认）
+
+如果发现问题，**先展示报告，获得用户确认后再修复**。
+
+修复时遵循：
+- **按严重程度排序**：❌ 实现偏差 > 🔴 未实现 > ⚠️ 部分实现 > 🟡 文案不一致
+- **每修一条，标注对应的 PRD 条目 ID**
+- **修复后重新验证该条目**
+
+---
+
+## 反模式（避免）
+
+- ❌ 不读代码，凭"应该实现了"就标记通过
+- ❌ 只检查 happy path，忽略 PRD 中提到的边界/异常场景
+- ❌ 文案只看"意思对"就通过（必须逐字一致）
+- ❌ 只查后端不查前端，或反之（PRD 涉及的层都要查）
+- ❌ 检查报告中加入 PRD 之外的改进建议（只对照 PRD，不发挥）
+- ❌ 发现问题直接改，不经用户确认
+
+---
+
+## 与其他命令的关系
+
+| 命令 | 校验什么 | 对照物 |
+|------|---------|--------|
+| `/trellis:check` | 代码规不规范 | spec 开发规范 |
+| `/trellis:check-cross-layer` | 改全了没 | git diff 影响范围 |
+| `/trellis:check-impl` | 假设对不对 | 源码/真实数据 |
+| `/trellis:check-prd` | PRD 对不对 | 原始需求文档 |
+| **`/trellis:check-prd-impl`**（本命令） | **实现对不对** | **PRD** |

package/enhancements/old/.agents/skills/create-prd/SKILL.md

@@ -0,0 +1,154 @@
+---
+name: create-prd
+description: "Create PRD — 基于原始需求文档，有据可依（含 UI 文案原封不动约束）"
+---
+# Create PRD — 基于原始需求文档
+
+从原始需求文档中提取指定需求的完整内容，结构化为 `prd.md`。**所有内容必须有据可依，禁止自行发挥。**
+
+---
+
+## 核心原则
+
+1. **原文优先** — Requirements 和 AC 必须引用原始文档原文，不得改写语义
+2. **文案原封不动** — 原始文档中出现的用户可见文案（按钮文字、提示语、Toast、弹窗内容、表头、placeholder 等）必须**逐字引用**，禁止改写、缩略或意译。这些文案是用户直接看到的内容，一个字的差异都会导致前端实现偏差
+3. **标注出处** — 每条需求标注来源位置（文档行号、章节编号或页码）
+4. **禁止发挥** — 不得添加原始文档中没有的需求、验收标准或业务规则
+5. **完整提取** — 该需求单元下的所有内容全部提取，不跳不漏
+6. **散射追踪** — 检查同一功能点是否在文档其他位置也有提及，一并收录
+
+---
+
+## 输入
+
+用户需提供：
+- **需要提取的需求**（编号、名称或功能描述均可）
+- **原始需求文档路径**（如未指定，在 `doc/` 下查找）
+
+---
+
+## 执行步骤
+
+### Step 1: 理解文档结构
+
+读取原始需求文档，识别其组织方式：
+
+- 需求的划分单元是什么？（REQ 编号 / 章节 / 功能模块 / 用户故事卡片 / 其他）
+- 每个需求单元包含哪些子结构？（如：用户故事、业务规则、字段说明、验收标准）
+- 有无编号体系？（如 BR-01、AC-01，或无编号纯文本）
+
+> **不要假设文档有特定格式**，先读再判断。
+
+### Step 2: 定位并完整提取
+
+在文档中定位用户指定的需求，**完整读取**该需求下的所有内容，直到下一个同级需求开始。
+
+提取时注意：
+- 保留原始的编号、层级、表格结构
+- 不要跳过任何子节（即使看起来不重要）
+- 记录提取的起止位置（行号或章节号）
+
+### Step 3: 散射追踪
+
+提取目标需求中涉及的**关键实体**（字段名、功能点、业务概念），在全文中搜索这些关键词，检查是否在其他需求单元中也有相关内容：
+
+- 同一字段在不同页面/模块的展示、编辑、导出规则
+- 同一业务规则在不同入口的复用
+- 跨需求的依赖或约束
+
+将发现的关联记录到 PRD 的「关联需求」部分。
+
+### Step 4: 生成 PRD
+
+将提取的内容结构化为 `prd.md`，结构分两层：
+
+**第一层：来源原文（忠实摘录）**
+
+```markdown
+# <需求标识> <需求名称>
+
+> 来源：<文档名>，<位置范围>
+
+## Goal
+<直接引用原文中的目标/用户故事描述>
+
+## 来源需求原文
+<按原始文档的子结构组织，使用 blockquote 引用原文>
+<保留原始编号和层级>
+```
+
+**第二层：结构化提炼（每条标注来源）**
+
+```markdown
+## Requirements
+- <需求描述> — 来源：<原文位置>
+- ...
+
+## Acceptance Criteria
+- [ ] <原文中的验收标准> — 来源：<原文位置>
+- ...
+
+## 关联需求（散射追踪）
+| 需求单元 | 关联内容 | 位置 | 影响 |
+|---------|---------|------|------|
+
+## Out of Scope
+- <原始文档中明确排除的内容>
+
+## Technical Notes
+- 原始文档路径、提取范围、提取时间
+```
+
+> Requirements 中的每一条都必须指向原文中的具体位置。
+> 如果原始文档没有显式的验收标准，从业务规则中提炼，但必须标注「提炼自：<原文位置>」。
+
+### Step 5: 创建 task.json
+
+PRD 写入后，调用框架脚本创建 `task.json`，使任务目录完整可用：
+
+```bash
+python3 .trellis/scripts/task.py create "<PRD标题>" \
+  --slug "<任务目录名去掉日期前缀>" \
+  --priority P2 \
+  --description "<Goal 的一句话摘要>"
+```
+
+> **注意**：
+> - 如果任务目录已由用户手动创建（已有 `prd.md`），脚本会检测到目录已存在并在其中写入 `task.json`
+> - `--slug` 必须与任务目录名的 slug 部分一致，确保 `task.json` 落在正确目录
+> - 根据需求性质设置 `--priority`：紧急修复 P0/P1，常规需求 P2，小改动 P3
+> - 创建完成后，根据 PRD 中的分析补充 `task.json` 中的字段：
+>   - `dev_type`：`frontend` / `backend` / `fullstack`
+>   - `relatedFiles`：PRD Technical Notes 中识别的关键文件路径
+
+### Step 6: 自检
+
+| 检查项 | 方法 |
+|--------|------|
+| 原文完整性 | 原始文档中该需求的所有子节是否都出现在「来源需求原文」中 |
+| AC 可追溯 | 每条 AC 是否都标注了来源位置 |
+| 无自行发挥 | Requirements 中是否有任何一条找不到原文依据 |
+| 文案逐字一致 | PRD 中的 UI 文案（按钮、提示语、Toast、弹窗、表头、placeholder）是否与原始文档**完全一致**，无改写/缩略/意译 |
+| 散射完整 | 至少对 2-3 个关键实体做过全文搜索 |
+
+---
+
+## 反模式
+
+- ❌ 用自己的话改写需求（应引用原文）
+- ❌ 需求条目没有标注来源位置
+- ❌ 添加原始文档中不存在的业务规则或验收标准
+- ❌ 跳过某些子节不提取（即使觉得不重要）
+- ❌ 不做散射追踪
+- ❌ 假设文档有特定格式（每份文档先读结构再处理）
+
+---
+
+## 与其他命令的关系
+
+| 命令 | 职责 | 时机 |
+|------|------|------|
+| `/trellis:plan-version` | 版本级需求扫描 + 覆盖度确认 | 版本规划阶段 |
+| `/trellis:create-prd` | 单个需求的 PRD + task.json 生成（本命令） | 任务开发前 |
+| `/trellis:check-prd` | 校验已有 PRD 的准确性 + 覆盖度 | PRD 生成后 |
+| `/trellis:brainstorm` | 对话式需求发现（无原始文档时） | 需求模糊时 |

package/enhancements/old/.agents/skills/draw-uml/SKILL.md

@@ -0,0 +1,148 @@
+---
+name: draw-uml
+description: "以资深 PM / 业务架构师身份，用 UML 活动图厘清业务逻辑（先反问再画图，禁止臆测；每次自动渲染 PNG 并读图展示）"
+---
+# PM 活动图梳理
+
+以**资深互联网产品经理 + 业务架构师**的身份，协助我用 **UML 活动图**厘清业务逻辑；信息不充分时**主动反问**，不得臆测。每次产出图后**必须渲染 PNG 并读图展示**，不要只扔代码。
+
+## 角色设定
+
+- **身份**：资深互联网产品经理 & 业务架构师
+- **职责**：把用户零散的想法 / 口头描述，结构化为清晰的业务流程
+- **工具**：UML 活动图（Activity Diagram），必要时辅以泳道、判定节点、并行分支
+- **原则**：需求不清先问，再画；**严禁虚构角色、系统或分支**
+
+## 交互步骤
+
+### 1. 接收输入
+读取用户提供的需求 / 场景描述（可能是一句话、一段聊天记录或一份粗略文档）。
+
+### 2. 澄清式反问（必要时）
+当下列任一要素缺失时，**先提问再动笔**：
+- **主体角色**：谁发起？谁审批？谁执行？（用户 / 系统 / 第三方）
+- **触发条件**：什么场景 / 事件进入此流程？
+- **判定分支**：条件是什么？各分支的后续动作？
+- **异常路径**：失败 / 超时 / 拒绝 如何处理？
+- **终止状态**：流程成功 / 失败 各以什么状态结束？
+
+一次最多提 3～5 个最关键的问题，避免"问题轰炸"。
+
+### 3. 输出活动图（Mermaid 代码）
+
+使用 **Mermaid `flowchart` / `stateDiagram` 语法**（或 PlantUML `@startuml` 活动图语法），直接可渲染。
+
+**Mermaid 示例**：
+````markdown
+```mermaid
+flowchart TD
+    Start([开始]) --> A[用户提交申请]
+    A --> B{金额 > 1万?}
+    B -- 是 --> C[主管审批]
+    B -- 否 --> D[自动通过]
+    C --> E{审批通过?}
+    E -- 是 --> D
+    E -- 否 --> F[通知驳回]
+    D --> End([结束])
+    F --> End
+```
+````
+
+### 4. 渲染为 PNG（每次必做）
+
+Mermaid 代码必须落盘并渲染为图片，否则用户可能看不到图。
+
+**4.1 确定产物路径**
+
+- 从流程名派生 `slug`（英文小写 + 连字符），例：`附件打包下载` → `attachment-zip-flow`
+  - 无法自动派生时，向用户确认 slug
+- 输出目录：当前工作目录下 `doc/uml/`（不存在则 `mkdir -p`）
+- 产物：`doc/uml/<slug>.mmd`（源码）+ `doc/uml/<slug>.png`（图）
+- 同名已存在：直接覆盖（Mermaid 源码是真源，无需保留历史版本）
+
+**4.2 写源码 + 在线渲染**
+
+用 `mermaid.ink` 渲染（零依赖、无需 key），标准 python3 即可：
+
+```bash
+SLUG="<slug>"
+mkdir -p doc/uml
+cat > "doc/uml/${SLUG}.mmd" <<'EOF'
+<把 Mermaid 源码粘到这里，结束行是独立的 EOF>
+EOF
+
+python3 - "$SLUG" <<'PY'
+import base64, json, pathlib, sys, urllib.request
+slug = sys.argv[1]
+src = pathlib.Path(f'doc/uml/{slug}.mmd').read_text()
+payload = {'code': src, 'mermaid': {'theme': 'default'}}
+b64 = base64.urlsafe_b64encode(json.dumps(payload).encode('utf-8')).decode('ascii').rstrip('=')
+url = f'https://mermaid.ink/img/{b64}?type=png&bgColor=FFFFFF'
+req = urllib.request.Request(url, headers={'User-Agent': 'curl/8'})
+with urllib.request.urlopen(req, timeout=30) as resp:
+    data = resp.read()
+out = pathlib.Path(f'doc/uml/{slug}.png')
+out.write_bytes(data)
+print(f'saved: {out} ({len(data)} bytes)')
+PY
+```
+
+**4.3 读图展示**
+
+用 Read 工具读取 `doc/uml/<slug>.png`，让图片直接出现在对话里（Claude Code 多模态支持）。
+
+**4.4 渲染失败降级**
+
+网络不通 / `mermaid.ink` 503 / Mermaid 语法报错时：
+- 保留 `.mmd` 源码文件（已落盘）
+- 明确告诉用户失败原因（HTTP 码或异常）
+- 给两条本地兜底：
+  1. `npx -p @mermaid-js/mermaid-cli mmdc -i doc/uml/<slug>.mmd -o doc/uml/<slug>.png`
+  2. 贴到 <https://mermaid.live> 手动导出
+- **不要假装成功**，也不要跳过这一步直接进入 Step 5
+
+### 5. 附随说明
+
+图下方补充：
+- **产物路径**：`doc/uml/<slug>.png` + `doc/uml/<slug>.mmd`
+- **角色清单**：列出图中涉及的所有角色 / 系统
+- **关键判定**：每个菱形分支的业务含义
+- **待确认项**：还存在哪些尚未澄清的点（如果有）
+
+### 6. 迭代优化
+
+用户反馈后，**只改动被指出的部分**，保持其余节点不变；大改前先口头确认修改范围。改完后**重新走 Step 4**（覆写 `.mmd` → 重新渲染 → 重新读图），保证图和代码同步。
+
+## 输出模板
+
+```markdown
+## 业务流程：<流程名>
+
+### 角色
+- <角色 A>
+- <系统 B>
+
+### 活动图
+<Mermaid 代码块>
+
+（此处应紧跟 Read 工具读出的 PNG 图像）
+
+### 产物
+- 图：`doc/uml/<slug>.png`
+- 源码：`doc/uml/<slug>.mmd`
+
+### 关键判定
+- **<判定节点>**：<业务规则说明>
+
+### 待确认
+- [ ] <悬而未决的问题>
+```
+
+## 禁止事项
+
+- [X] 跳过澄清直接画图（除非需求已极其明确）
+- [X] 虚构角色 / 系统 / 字段
+- [X] 一次性把所有分支画出来却不标注业务含义
+- [X] 用纯文字描述替代活动图（用户要的是"图"）
+- [X] 只贴 Mermaid 代码不渲染 PNG（除非 Step 4 明确失败并告知用户）
+- [X] 渲染失败静默跳过，不告知用户

package/enhancements/old/.agents/skills/plan-version/SKILL.md

@@ -0,0 +1,140 @@
+---
+name: plan-version
+description: "版本开发计划 — 从需求文档到任务拆分"
+---
+# 版本开发计划 — 从需求文档到任务拆分
+
+从原始需求文档出发，生成版本开发计划（需求清单 + 工时评估 + 人员分工），内置覆盖度校验确保不遗漏需求。
+
+---
+
+## 核心原则
+
+1. **需求文档是唯一真相** — 需求清单必须从文档全文提取，不能只看目录/总表
+2. **先扫后拆** — 先完成覆盖度扫描，确认无遗漏后再做工时评估和分工
+3. **可追溯** — 每个任务可追溯到原始文档的具体位置（行号/章节）
+
+---
+
+## 输入
+
+用户需提供：
+- **原始需求文档路径**
+- **版本号或迭代标识**
+- **开发团队信息**（人数、角色分工模式）
+
+---
+
+## 执行步骤
+
+### Step 1: 理解文档结构 + 全文扫描
+
+#### 1.0 先读后扫
+
+读取文档，识别其组织方式：
+- 需求的划分单元是什么？（编号体系 / 章节 / 功能模块 / 用户故事）
+- 有无需求总表或变更日志？
+- 版本变更如何标记？（显式标记 / 总表版本列 / 变更日志章节 / 无标记）
+
+> **不要假设文档有特定格式**，先读再判断。
+
+#### 1.1 多策略识别本版本变更
+
+根据文档实际结构，组合使用以下策略：
+
+| 策略 | 方法 |
+|------|------|
+| **标记扫描** | grep 搜索版本相关标记，**包括段落中间嵌入的** |
+| **需求总表** | 读取需求列表中版本相关列，提取本版本的条目 |
+| **全文通读** | 逐章扫描「新增」「变更」「调整」等动作词 |
+
+#### 1.2 归组到需求单元
+
+每个变更点定位到所属的需求单元，记录：
+- 需求单元标识（编号、名称或章节）
+- 变更内容摘要
+- 在文档中的位置
+- 变更类型：整体新增 / 局部变更 / 字段级嵌入
+
+> **[!] 关键：必须识别出「字段级嵌入变更」。**
+> 有些需求单元整体是旧版本的，但内部某个字段/段落属于新版本变更。
+> 仅看需求单元标题会遗漏这类变更。
+
+#### 1.3 识别散射型变更
+
+检查是否有同一功能点散布在多个需求单元中：
+- 同一字段在不同页面的展示/编辑/导出
+- 同一业务规则在不同入口的复用
+- 标记每组散射变更，确保后续分工时归同一人
+
+### Step 2: 输出需求清单 — 覆盖度确认
+
+输出完整的需求清单，请用户确认无遗漏：
+
+```markdown
+## <版本> 需求清单
+
+### 扫描统计
+- 需求总表中本版本条目: X 个
+- 全文扫描发现的变更: Y 个
+- 去重后独立需求单元: Z 个
+
+### 需求列表
+
+| # | 需求单元 | 功能点 | 变更类型 | 变更摘要 | 文档位置 |
+|---|---------|--------|---------|---------|---------|
+
+### 散射型变更（同一功能点跨多个需求单元）
+
+| 功能点 | 涉及的需求单元 | 建议处理 |
+|--------|--------------|---------|
+
+### 需求总表 vs 全文扫描差异
+
+| 来源 | 仅在总表 | 仅在全文 | 两者都有 |
+|------|---------|---------|---------|
+
+> 仅在全文中的变更 = 总表未收录的嵌入式变更，最易遗漏。
+```
+
+**等待用户确认后再继续。**
+
+### Step 3: 工时评估
+
+基于确认后的需求清单，评估每个需求的工时。
+
+输出表格的列结构**根据项目实际的角色分工来定**（如前端/后端/全栈/测试等），不要预设。
+
+评估原则：
+- 如有 AI 编程辅助，标注基准（AI 辅助 vs 纯人工）
+- 复用关系明确标注
+- 优先级以需求文档为准
+
+### Step 4: 人员分工
+
+按模块边界分工，遵循：
+- 复用链归同一人
+- 散射型变更归同一人
+- 尽量无交集
+
+输出分工表和排期建议。
+
+### Step 5: 生成产物文件
+
+在 `doc/` 目录下生成：
+
+```
+doc/
+├── <版本>-需求清单.md            # Step 2 的完整输出（含覆盖度校验）
+├── <版本>-开发计划-工时评估.md    # Step 3 + Step 4
+```
+
+---
+
+## 反模式
+
+- ❌ 只从需求总表提取需求（会漏掉嵌入式变更）
+- ❌ 跳过覆盖度确认直接做工时评估
+- ❌ 散射型变更分给不同的人
+- ❌ 假设文档有特定格式或特定的角色分工模式
+- ❌ 当多个来源的优先级冲突时不明确说明以哪个为准