flower-trellis 0.1.0

package/enhancements/old/.claude/commands/trellis/check-all.md

@@ -0,0 +1,124 @@
+# Check All — 全维度代码检查
+
+依次执行所有 check 命令，一次性完成全维度代码质量检查。
+
+> 顺序逻辑：**正确性 → 假设验证 → 完整性 → 规范性**
+> 先保证"做对了"，再保证"做全了"，最后保证"写好了"。
+
+---
+
+## 执行模式（重要）
+
+**默认在主对话中直接执行，不要委派给子 agent。**
+
+原因：
+- 各 Step 中存在"发现问题立即暂停询问用户"的交互点，子 agent 无法交互式暂停
+- 检查结果的具体细节（哪一行、哪个假设错了）对后续修复很关键，子 agent 的摘要式返回会丢失细节
+
+**仅当用户在调用时明确要求"用子 agent 执行"或"并行执行"时**，才使用 Agent 工具委派。否则一律在主对话中按步骤顺序执行。
+
+---
+
+## 包含的检查（按顺序执行）
+
+| 顺序 | 命令 | 检查什么 | 对照物 |
+|------|------|---------|--------|
+| 1 | `check-prd-impl` | 实现对不对 | PRD |
+| 2 | `check-impl` | 假设对不对 | 源码/真实数据 |
+| 3 | `check-cross-layer` | 改全了没 | git diff 影响范围 |
+| 4 | `check` | 写得规范吗 | spec 开发规范 |
+
+---
+
+## 执行步骤
+
+### Step 0: 确认变更范围
+
+```bash
+git diff --name-only
+```
+
+如果无变更，提示用户并终止。
+
+### Step 1: 对照 PRD 检查实现（check-prd-impl）
+
+按 `.claude/commands/trellis/check-prd-impl.md` 执行。
+
+**本轮重点**：PRD 中的每条需求和 AC 是否都正确实现了？有没有行为偏差、功能缺失、文案不一致？
+
+> 如果发现 ❌ 实现偏差或 🔴 未实现，**立即暂停**，展示问题并询问用户：
+> - 先修复再继续后续检查？
+> - 还是先跑完全部检查，最后统一修复？
+
+### Step 2: 实现假设验证（check-impl）
+
+按 `.claude/commands/trellis/check-impl.md` 执行。
+
+**本轮重点**：API 响应结构、组件生命周期、历史数据兼容性等假设是否正确？
+
+### Step 3: 跨层完整性检查（check-cross-layer）
+
+按 `.claude/commands/trellis/check-cross-layer.md` 执行。
+
+**本轮重点**：变更涉及的所有层、所有引用点是否都同步更新了？
+
+### Step 4: 代码规范检查（check）
+
+按 `.claude/commands/trellis/check.md` 执行。
+
+**本轮重点**：代码是否符合项目 spec 中的编码规范？lint 和 typecheck 是否通过？
+
+---
+
+## 输出：汇总报告
+
+所有检查完成后，输出一份汇总报告：
+
+```markdown
+## Check All 汇总报告
+
+### 任务: <任务名称>
+
+---
+
+### 各维度结果
+
+| 维度 | 状态 | 问题数 | 关键问题 |
+|------|------|--------|---------|
+| PRD 实现 | ✅/❌ | N | <最严重的问题摘要> |
+| 假设验证 | ✅/❌ | N | <最严重的问题摘要> |
+| 跨层完整 | ✅/❌ | N | <最严重的问题摘要> |
+| 代码规范 | ✅/❌ | N | <最严重的问题摘要> |
+
+### 待修复问题（按优先级排序）
+
+#### P0 — 功能性 BUG（来自 check-prd-impl / check-impl）
+1. ...
+
+#### P1 — 完整性遗漏（来自 check-cross-layer）
+1. ...
+
+#### P2 — 规范问题（来自 check）
+1. ...
+
+### 结论
+- <总体评价>
+- <建议修复顺序>
+```
+
+---
+
+## 使用时机
+
+- **开发完成后、提交前** — 作为 `/trellis:finish-work` 之前的全面检查
+- **Code Review 前** — 自查一遍再提交 MR
+- **不确定改动质量时** — 跑一遍全量检查心里有底
+
+---
+
+## 注意事项
+
+- 每个维度独立输出报告，最后汇总
+- 如果某个维度发现严重问题（❌ / 🔴），会暂停询问是否先修复
+- 如果当前任务没有 PRD，自动跳过 Step 1（check-prd-impl），从 Step 2 开始
+- 全量检查耗时较长，如果只想快速检查某个维度，直接使用单独的命令

package/enhancements/old/.claude/commands/trellis/check-impl.md

@@ -0,0 +1,154 @@
+# Implementation Reality Check
+
+验证你写的代码是否基于真实的假设，而非"想当然"。大多数实现 bug 不是逻辑错误，而是前提假设错了。
+
+> **Note**: 这是 **post-implementation** 安全网，与 `/trellis:check-cross-layer` 互补。
+> cross-layer 检查结构完整性，本命令检查假设正确性。
+
+---
+
+## Execution Steps
+
+### 1. Identify Change Scope
+
+```bash
+git diff --name-only
+```
+
+### 2. Select Applicable Check Dimensions
+
+根据变更类型，执行对应的检查维度：
+
+---
+
+## Dimension A: API Contract（调用了已有 API 时）
+
+**Trigger**: 前端新增/修改了对后端 API 的调用
+
+**Checklist**:
+- [ ] 读过 Controller/Handler 源码，确认实际响应结构？
+- [ ] 找到项目中已有的同 API 调用代码作为参考？
+- [ ] 请求参数名、类型、默认值从源码确认（非凭记忆）？
+- [ ] 分页接口：确认了分页字段名和起始页码？
+
+**Anti-pattern**:
+
+| 错误假设 | 实际情况 |
+|---------|---------|
+| `res.data.data` 是数组 | 实际是 `{ items: [], total }` 分页结构 |
+| 参数名是 `page` | 实际是 `p`，且从 1 开始 |
+| 响应直接是业务数据 | 实际包了一层 `{ success, message, data }` |
+
+---
+
+## Dimension B: Component Context（在容器内使用组件时）
+
+**Trigger**: 在 Modal / Drawer / Tab / 条件渲染块内使用有状态组件
+
+**Checklist**:
+- [ ] 确认容器关闭/切换时是否销毁子组件？
+- [ ] 如需保持状态：是否用了 keepDOM / destroyOnClose={false} 等配置？
+- [ ] 受控组件的 value 与外部 state 是否正确绑定？
+- [ ] 找到项目中同容器内的组件用法作为参考？
+
+**Anti-pattern**:
+
+| 错误假设 | 实际情况 |
+|---------|---------|
+| Modal 关闭后表单状态保留 | 默认销毁子组件，再开状态丢失 |
+| value 传了就是受控 | 某些组件需 initValue + value 配合 |
+| 组件在任何地方行为一致 | 容器上下文会影响挂载/卸载行为 |
+
+---
+
+## Dimension C: Data History（修改了数据模型时）
+
+**Trigger**: 数据库表新增/修改了字段
+
+**Checklist**:
+- [ ] 历史记录的新字段值是什么（空/零值/null）？
+- [ ] 用新字段过滤时，历史数据能否被正确查到？
+- [ ] 是否需要降级查询路径（如从其他表补查历史数据）？
+- [ ] 写入链路中新字段的值从哪来？来源是否可靠？
+
+**Anti-pattern**:
+
+| 错误假设 | 实际情况 |
+|---------|---------|
+| 加了字段就有数据 | 旧记录新字段全是零值/空值 |
+| 只查聚合表就够了 | 聚合表缺维度，需从明细表降级查询 |
+| 字段值肯定有 | 某些调用链路中该值可能为空 |
+
+---
+
+## Dimension D: Data Flow Trace（跨层变更时）
+
+**Trigger**: 变更涉及 前端 ↔ API ↔ 数据库 的数据传递
+
+**Checklist**:
+- [ ] 模拟一条完整请求路径：前端发什么 → 后端收什么 → 查出什么 → 返回什么 → 前端解析什么？
+- [ ] 前端参数名 === 后端 Query/Body 参数名？
+- [ ] 后端返回结构 === 前端解析结构？
+- [ ] 空值/零值场景：不填该字段时，每一层的行为是否正确？
+
+**Anti-pattern**:
+
+| 错误假设 | 实际情况 |
+|---------|---------|
+| 代码看起来对就能跑 | 参数名差一个字母、嵌套差一层 |
+| 只检查非空路径 | 空值路径才是出 bug 最多的地方 |
+| 前后端分别看都没问题 | 放一起跑时数据对不上 |
+
+---
+
+## Dimension E: Verification Tests（验证关键假设的测试）
+
+**Trigger**: 任何涉及 Dimension A-D 的变更
+
+光靠肉眼审查不够，关键假设必须有可运行的验证手段。根据变更类型选择合适的验证方式：
+
+**API Contract 验证**:
+- [ ] 写一个请求测试，验证实际响应结构与代码解析逻辑匹配
+- [ ] 覆盖正常路径和空值/零值路径
+
+**数据模型验证**:
+- [ ] 写查询测试，用真实数据（含历史旧记录）验证过滤/聚合结果正确
+- [ ] 新字段为空时的查询行为是否符合预期
+
+**跨层数据流验证**:
+- [ ] 写端到端测试，从请求发起到响应解析，验证完整路径数据一致
+- [ ] 覆盖边界场景：空参数、特殊字符、零值
+
+**验证原则**:
+- 不要求高覆盖率，但每个 Dimension 中发现的关键假设至少有一个测试保护
+- 优先写能暴露"想当然"问题的测试，而非走过场的 happy path
+- 如果无法写自动化测试，记录手动验证步骤和预期结果
+
+**Anti-pattern**:
+
+| 错误做法 | 正确做法 |
+|---------|---------|
+| 只写 happy path 测试 | 优先覆盖假设最脆弱的路径 |
+| 测试写了但没跑 | 测试必须实际运行并通过 |
+| "这个太简单不用测" | 越简单的假设越容易错（参数名、嵌套层级） |
+
+---
+
+## Common Issues Quick Reference
+
+| Issue | Root Cause | Prevention |
+|-------|------------|------------|
+| API 调用返回 undefined | 响应结构假设错误 | 读 Controller 确认 |
+| 组件状态莫名丢失 | 容器销毁了子组件 | 检查容器生命周期 |
+| 筛选后数据为空 | 历史记录缺字段 | 验证旧数据查询路径 |
+| 参数传了但后端没收到 | 参数名不匹配 | 源码级确认参数名 |
+| 看着对但跑不通 | 只做了静态审查 | 模拟完整数据流 |
+
+---
+
+## Output
+
+Report:
+1. 本次变更涉及哪些维度
+2. 每个维度的检查结果
+3. 发现的问题及修复建议（直接修复）

package/enhancements/old/.claude/commands/trellis/check-prd-impl.md

@@ -0,0 +1,186 @@
+# 对照 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/.claude/commands/trellis/check-prd.md

@@ -0,0 +1,215 @@
+# 校验 PRD — 对照原始需求文档
+
+对照用户提供的原始需求文档（需求规格说明、PRD 截图、文字描述等），逐条校验生成的 `prd.md` 是否准确还原了原始需求，标记所有偏差并修正。同时扫描原始需求文档中的**所有本次版本变更内容**，检查是否存在被 PRD 遗漏的变更点。
+
+---
+
+## 核心原则（不可违反）
+
+1. **原始需求文档是唯一权威** — PRD 内容必须忠实反映原始需求，不得自行"理解"、"推演"或"发挥"
+2. **逐条对照，不跳不漏** — 原始需求的每一个条目都必须在 PRD 中找到对应描述
+3. **标记偏差类型** — 区分"缺失"、"曲解"、"发挥过度"、"措辞不准"
+4. **文案必须逐字一致** — 原始需求中出现的用户可见文案（按钮文字、提示语、Toast、弹窗内容、表头、placeholder 等）必须与 PRD **逐字一致**；文案不一致直接标记为 ❌ 曲解（不是 ⚠️ 措辞偏差），因为前端会照搬 PRD 文案实现
+5. **只改偏差，不改结构** — 修正内容错误，不改变 PRD 整体格式框架
+5. **版本变更全覆盖** — 原始需求中属于本次版本的所有变更内容都必须被某个任务/PRD 覆盖，不得遗漏
+
+---
+
+## 使用方式
+
+```
+/trellis:check-prd
+```
+
+- 如果任务目录下已有 `prd.md`，自动使用
+- 如果有多个任务，列出让用户选择
+
+---
+
+## 执行步骤
+
+### Step 1: 定位文件
+
+```bash
+# 获取当前任务
+python3 ./.trellis/scripts/task.py list
+```
+
+读取任务目录下的 `prd.md`。如果不存在，提示用户先创建。
+
+### Step 2: 获取原始需求文档
+
+**必须主动获取原始需求文档来源**。按以下优先级查找：
+
+1. **任务目录下的附件** — 检查任务目录下是否有 `requirements.md`、`spec.md`、`需求.md`、`*.xlsx`、`*.pdf` 等文件
+2. **PRD 中的引用链接** — 检查 PRD 中是否引用了外部文档链接
+3. **用户提供** — 如果上述都没有，**明确询问用户**：
+
+```markdown
+当前任务目录下未找到原始需求文档。请提供需求来源：
+
+1. **粘贴需求文本** — 直接粘贴原始需求内容
+2. **指定文件路径** — 告诉我需求文档在哪里
+3. **口述要点** — 口头说明关键需求点
+```
+
+> **[!] 严禁在没有原始需求文档的情况下进行校验** — 没有参照物的校验没有意义。
+
+### Step 3: 逐条对照
+
+将原始需求文档分解为独立条目（逐个需求点/AC/功能点），然后逐条在 PRD 中查找对应描述。
+
+对每一条标记状态：
+
+| 状态 | 含义 | 示例 |
+|------|------|------|
+| ✅ 准确 | PRD 忠实还原了原始需求 | — |
+| ⚠️ 措辞偏差 | 意思基本对，但措辞可能引起歧义 | 原始："下一行" → PRD："下一条未完结任务" |
+| ❌ 曲解 | PRD 理解错了原始需求的意思 | 原始："按当前列表排序" → PRD："按 taskNo 正序" |
+| ❌ 文案不一致 | UI 可见文案与原始需求不逐字一致（按钮、提示语、Toast、弹窗、表头、placeholder 等） | 原始：提示"确认提交？" → PRD："确认保存？" |
+| 🔴 缺失 | 原始需求有，PRD 里完全没提 | — |
+| 🟡 自行发挥 | PRD 写了原始需求没有的内容 | — |
+
+### Step 3.5: 覆盖度扫描（反向检查）
+
+Step 3 是**正向检查**（PRD 里的内容 → 原始文档里是否有）。
+Step 3.5 是**反向检查**（原始文档里本次版本的变更 → PRD 里是否覆盖）。
+
+#### 3.5.1 识别本次版本的所有变更内容
+
+**不要假设需求文档有固定格式。** 根据文档的实际结构，使用以下策略组合来识别变更：
+
+| 策略 | 适用场景 | 方法 |
+|------|---------|------|
+| **标记扫描** | 文档用标记标注变更（如 `[v1.2.0变更]`、`[新增]`、`[变更]`） | grep 全文搜索所有标记，**包括段落中间嵌入的标记** |
+| **需求总表** | 文档有需求列表/变更日志表格 | 读取表格中「版本」「更新内容」列，提取本次版本的条目 |
+| **章节对比** | 文档无显式标记，但有版本说明章节 | 读取版本说明/变更日志章节，提取所有变更描述 |
+| **全文语义** | 文档无任何结构化标记 | 通读全文，识别「新增」「变更」「调整」「优化」等动作词所在段落 |
+
+> **[!] 关键：必须扫描全文，不能只看目录/总表/标题。**
+> 很多变更是**嵌入在大段描述中间的字段级变更**，只看结构性位置会遗漏。
+
+#### 3.5.2 定位每个变更所属的需求单元
+
+对每个识别到的变更内容，确定它属于哪个需求单元（REQ 编号、功能模块、页面等）。
+定位方式取决于文档结构：
+- 有编号体系的：向上查找最近的需求标题
+- 无编号体系的：按章节/功能模块归类
+
+#### 3.5.3 交叉比对
+
+将所有变更按需求单元归组后，与 PRD 中已覆盖的范围做差集：
+
+| 检查项 | 说明 |
+|--------|------|
+| **已覆盖** | 变更所属需求单元在 PRD 中有对应任务/测试项 |
+| **未覆盖** | 变更所属需求单元完全不在 PRD 范围内 |
+| **部分覆盖** | 需求单元在 PRD 中有对应，但该单元内的某些变更点未被提及 |
+
+> **特别注意散射型变更**：同一个功能点可能散布在多个需求单元中。
+> 即使主需求已覆盖，也要检查所有关联位置。
+
+#### 3.5.4 输出覆盖度清单
+
+对未覆盖和部分覆盖的变更，列出详情供 Step 4 报告使用。
+
+---
+
+### Step 4: 输出校验报告
+
+```markdown
+## PRD 校验报告
+
+### 任务: <任务名称>
+
+### 一、准确性校验
+
+#### 总览
+- 原始需求条目数: N
+- ✅ 准确: X 条
+- ⚠️ 措辞偏差: X 条
+- ❌ 曲解: X 条
+- 🔴 缺失: X 条
+- 🟡 自行发挥: X 条
+
+#### 逐条对照
+
+##### <需求点 1 标题>
+- **原始需求**: <原文摘抄>
+- **PRD 描述**: <PRD 中的对应内容>
+- **状态**: ✅ / ⚠️ / ❌ / 🔴 / 🟡
+- **问题**: <如果有偏差，说明具体问题>
+- **建议修正**: <如果需要修正，给出建议>
+
+##### <需求点 2 标题>
+...
+
+---
+
+### 二、覆盖度扫描
+
+#### 总览
+- 原始文档版本变更总数: N
+- ✅ 已覆盖: X 个
+- 🔴 未覆盖: X 个
+- ⚠️ 部分覆盖: X 个
+
+#### 未覆盖的变更点
+
+| 需求单元 | 位置 | 变更内容摘要 | 影响范围 |
+|---------|------|-------------|---------|
+
+#### 部分覆盖的变更点
+
+| 需求单元 | 位置 | 变更内容摘要 | PRD 中已有的覆盖 | 缺失的部分 |
+|---------|------|-------------|----------------|-----------|
+
+---
+
+### 三、结论
+- <总结性评价>
+- <准确性是否需要修正>
+- <覆盖度缺口是否需要补充任务>
+```
+
+### Step 5: 修正 PRD（需用户确认）
+
+如果发现偏差，**先列出所有修正项，获得用户确认后再修改 `prd.md`**。
+
+```markdown
+以下是建议的修正项：
+
+1. **<需求点>**: <原 PRD 内容> → <修正后内容>
+2. ...
+
+确认后我将更新 prd.md。
+```
+
+修正时遵循：
+- **只改内容偏差，不改 PRD 格式**
+- **优先使用原始需求文档的原文措辞**
+- **标注修正来源**：在 Technical Notes 中记录本次校验
+
+---
+
+## 反模式（避免）
+
+- ❌ 没有原始需求文档就凭感觉校验
+- ❌ 只看标题不看细节（AC 级别逐条对照）
+- ❌ 发现偏差不标记类型，笼统说"有出入"
+- ❌ 未经确认直接修改 PRD
+- ❌ 校验时加入自己的"理解"和"建议"（只对照，不发挥）
+- ❌ UI 文案不一致却只标记为 ⚠️ 措辞偏差（用户可见文案必须逐字一致，不一致直接标记 ❌）
+- ❌ 覆盖度扫描只看需求总表/目录，不扫描全文（嵌入式变更会遗漏）
+- ❌ 假设需求文档有固定的变更标记格式（每份文档结构可能不同）
+- ❌ 只追踪主需求单元，忽略同一功能点在其他页面/模块的散射变更
+
+---
+
+## 与其他命令的关系
+
+| 命令 | 职责 | 时机 |
+|------|------|------|
+| `/trellis:brainstorm` | 生成 PRD | 需求讨论阶段 |
+| `/trellis:check-prd` | 校验 PRD 准确性 + 覆盖度 | PRD 生成后、开发前 |
+| `/trellis:analyze-task` | 分析任务可行性和风险 | 开发前 |