6aspec 2.0.0-dev.10

package/.6aspec/rules/brown/brown_review_sop.md

@@ -0,0 +1,270 @@
+# 棕地需求 - Review SOP
+
+Phase 7: 实施后评估
+
+**输入**：`/6aspec:brown:review` 后可选需求名称。
+
+**注意**：此阶段通常在需求上线后 1 周或 1 个月执行，用于评估实施效果。
+
+**步骤**
+
+1. **选择需求并检查状态**
+
+   - 读取 `6aspecdoc/brown/<name>/status.json`
+   - 确认 `phases.verify` 为 "done"
+   - 如果未完成 Phase 6，提示先运行 `/6aspec:brown:verify`
+
+2. **读取历史文档**
+
+   读取以下文档：
+   - `6aspecdoc/brown/<name>/requirement.md` - 原始需求
+   - `6aspecdoc/brown/<name>/artifacts/02-impact-analysis.md` - 预期影响
+   - `6aspecdoc/brown/<name>/artifacts/03-technical-design.md` - 技术方案
+   - `6aspecdoc/brown/<name>/artifacts/ADR-<name>.md` - 架构决策（P0）
+
+3. **参考相关归档需求（可选）**
+
+   如果有相关的归档需求，可以参考其经验教训：
+
+   **如何参考**：
+   - 使用 `@` 手动加载归档需求的 `post-implementation-review.md`
+   - 例如：`@6aspecdoc/brown/.archived/2026-02-10-add-business-field/artifacts/06-post-implementation-review.md`
+
+   **应该参考的内容**：
+   - ✅ 经验教训：做得好的地方、需要改进的地方
+   - ✅ 最佳实践：可复用的方案和模式
+   - ✅ 关键成功因素：什么因素导致了成功或失败
+   - ✅ 改进建议：对未来类似需求的建议
+
+   **不应该参考的内容**：
+   - ❌ 技术方案：代码可能已经演进，历史方案可能已过时
+   - ❌ 影响面分析：当前代码状态可能已经不同
+   - ❌ 具体实现细节：应该基于当前代码，而不是历史文档
+
+   **为什么这样做**：
+   - 代码是唯一的事实来源，会随着需求演进而变化
+   - 归档文档是历史快照，不会更新
+   - 经验教训是跨时间有效的，但技术方案是时间敏感的
+
+4. **收集评估数据**
+
+   收集以下信息：
+
+   **技术指标**：
+   - 性能是否符合预期？
+   - 是否产生新的 bug？
+   - 技术债务是否可控？
+
+   **业务指标**：
+   - 是否解决了业务问题？
+   - 用户反馈如何？
+   - 是否需要调整？
+
+   **架构决策回顾**（P0 需求）：
+   - 当初的架构决策是否正确？
+   - 有哪些经验教训？
+   - 需要更新 ADR 吗？
+
+4. **生成评估报告**
+
+   创建 `6aspecdoc/brown/<name>/artifacts/06-post-implementation-review.md`：
+   ```markdown
+   # Phase 7: 实施后评估
+
+   > **需求**: <name>
+   > **阶段**: Phase 7 - 实施后评估
+   > **状态**: ✅ 已完成
+   > **评估时间**: <timestamp>
+   > **上线时间**: <timestamp>
+   > **评估周期**: 上线后 <X> 周/月
+
+   ## 评估概览
+
+   | 维度 | 评分 | 说明 |
+   |------|------|------|
+   | 技术指标 | ⭐⭐⭐⭐⭐ | <说明> |
+   | 业务指标 | ⭐⭐⭐⭐⭐ | <说明> |
+   | 用户满意度 | ⭐⭐⭐⭐⭐ | <说明> |
+   | 总体评价 | ⭐⭐⭐⭐⭐ | <说明> |
+
+   ## 1. 技术指标评估
+
+   ### 1.1 性能指标
+
+   | 指标 | 预期 | 实际 | 评估 |
+   |------|------|------|------|
+   | 响应时间 | <预期值> | <实际值> | ✅ 符合 / ⚠️ 偏差 / ❌ 不符合 |
+   | QPS | <预期值> | <实际值> | ✅ 符合 / ⚠️ 偏差 / ❌ 不符合 |
+   | 错误率 | <预期值> | <实际值> | ✅ 符合 / ⚠️ 偏差 / ❌ 不符合 |
+
+   ### 1.2 稳定性
+
+   - 是否产生新的 bug：✅ 否 / ⚠️ 少量 / ❌ 较多
+   - Bug 列表（如有）：
+     - BUG-001: <描述>
+     - BUG-002: <描述>
+
+   ### 1.3 技术债务
+
+   - 技术债务是否可控：✅ 是 / ⚠️ 部分 / ❌ 否
+   - 新增技术债务：
+     - DEBT-XXX: <描述>
+   - 已偿还技术债务：
+     - DEBT-XXX: <描述>
+
+   ## 2. 业务指标评估
+
+   ### 2.1 业务目标达成
+
+   | 业务目标 | 预期 | 实际 | 评估 |
+   |----------|------|------|------|
+   | <目标1> | <预期> | <实际> | ✅ 达成 / ⚠️ 部分达成 / ❌ 未达成 |
+   | <目标2> | <预期> | <实际> | ✅ 达成 / ⚠️ 部分达成 / ❌ 未达成 |
+
+   ### 2.2 用户反馈
+
+   - 正面反馈：
+     - <反馈1>
+     - <反馈2>
+
+   - 负面反馈：
+     - <反馈1>
+     - <反馈2>
+
+   - 改进建议：
+     - <建议1>
+     - <建议2>
+
+   ### 2.3 是否需要调整
+
+   - ✅ 不需要调整，符合预期
+   - ⚠️ 需要小幅调整
+   - ❌ 需要重大调整
+
+   调整计划（如需要）：
+   <调整计划>
+
+   ## 3. 架构决策回顾（P0 需求）
+
+   ### 3.1 决策回顾
+
+   回顾 ADR-<name>.md 中的架构决策：
+
+   | 决策 | 当时的理由 | 实际效果 | 评估 |
+   |------|-----------|----------|------|
+   | <决策1> | <理由> | <效果> | ✅ 正确 / ⚠️ 部分正确 / ❌ 错误 |
+
+   ### 3.2 经验教训
+
+   **做得好的地方**：
+   - <经验1>
+   - <经验2>
+
+   **需要改进的地方**：
+   - <教训1>
+   - <教训2>
+
+   ### 3.3 ADR 更新
+
+   - ✅ 需要更新 ADR
+   - ❌ 不需要更新
+
+   更新内容（如需要）：
+   <更新内容>
+
+   ## 4. 知识沉淀
+
+   ### 4.1 最佳实践
+
+   从本次需求实施中总结的最佳实践：
+   - <实践1>
+   - <实践2>
+
+   ### 4.2 可复用方案
+
+   可以在其他需求中复用的方案：
+   - <方案1>
+   - <方案2>
+
+   ### 4.3 文档更新
+
+   需要更新的文档：
+   - [ ] 架构文档
+   - [ ] 开发规范
+   - [ ] 最佳实践库
+
+   ### 4.4 知识分享
+
+   - [ ] 技术分享会
+   - [ ] 技术博客
+   - [ ] 团队培训
+
+   ## 5. 总结
+
+   ### 5.1 总体评价
+
+   <总体评价>
+
+   ### 5.2 关键成功因素
+
+   - <因素1>
+   - <因素2>
+
+   ### 5.3 改进建议
+
+   对未来类似需求的建议：
+   - <建议1>
+   - <建议2>
+
+   ## 6. 下一步
+
+   运行 `/6aspec:brown:archive` 归档此需求。
+   ```
+
+5. **更新状态**
+
+   更新 `status.json`：
+   ```json
+   {
+     "status": "completed",
+     "phases": {
+       ...
+       "review": "done"
+     },
+     "completedAt": "<timestamp>"
+   }
+   ```
+
+**输出**
+
+```
+## Phase 7 完成：实施后评估
+
+**需求**: <name>
+**进度**: 7/7 阶段完成 ✅
+
+### 评估结果
+- 技术指标：⭐⭐⭐⭐⭐
+- 业务指标：⭐⭐⭐⭐⭐
+- 用户满意度：⭐⭐⭐⭐⭐
+- 总体评价：⭐⭐⭐⭐⭐
+
+### 关键发现
+<列出关键发现>
+
+### 经验教训
+<列出经验教训>
+
+### 文档位置
+6aspecdoc/brown/<name>/artifacts/06-post-implementation-review.md
+
+### 下一步
+所有阶段已完成！运行 `/6aspec:brown:archive` 归档此需求。
+```
+
+**防护措施**
+- 必须先完成 Phase 6
+- 评估必须基于实际数据，不能主观臆断
+- 必须收集用户反馈
+- P0 需求必须回顾架构决策
+- 必须进行知识沉淀

package/.6aspec/rules/brown/brown_rollback_sop.md

@@ -0,0 +1,188 @@
+# 棕地需求 - Rollback SOP
+
+回退到上一个阶段，删除当前阶段生成的文件并更新状态。
+
+**输入**：`/6aspec:brown:rollback` 后可选需求名称。
+
+**适用场景**：
+- 发现前面阶段的分析有误或不完整
+- 需要修改前面阶段的产出
+- 希望重新执行某个阶段
+
+**限制**：
+- 只能一级一级往上退，不允许跨节点
+- 只能回退已完成的阶段（状态为 "done"）
+- 不能回退第一个阶段（proposal/understand）
+- 已归档的需求不能回退
+
+**步骤**
+
+1. **选择需求**
+
+   如果提供了名称，使用它。否则：
+   - 从对话上下文推断
+   - 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
+
+2. **检查当前状态**
+
+   读取 `6aspecdoc/brown/<name>/status.json`：
+   - 确认需求未归档
+   - 确认 `flowDepth`（流程深度）
+   - 找到当前已完成的最后一个阶段
+
+3. **确定回退目标**
+
+   根据流程深度和当前阶段，确定上一个阶段：
+
+   **轻量级流程（lightweight）**：
+   - design → proposal
+   - tasks → design
+   - implement → tasks
+
+   **标准级流程（standard）**：
+   - specs → understand
+   - impact → specs
+   - design → impact
+   - tasks → design
+   - implement → tasks
+
+   **完整级流程（complete）**：
+   - specs → understand
+   - impact → specs
+   - design → impact
+   - tasks → design
+   - implement → tasks
+   - verify → implement
+   - review → verify
+
+   **边界情况**：
+   - 如果当前在第一个阶段（proposal/understand），提示无法回退
+   - 如果所有阶段都是 pending，提示没有可回退的阶段
+
+4. **确认回退操作**
+
+   询问用户确认：
+   ```
+   问题："确认回退操作？"
+   说明：
+   - 当前阶段：<current-phase>
+   - 回退到：<previous-phase>
+   - 将删除的文件：<files-to-delete>
+
+   选项：
+   - 确认回退
+   - 取消
+   ```
+
+   如果用户选择"取消"，停止执行。
+
+5. **删除当前阶段生成的文件**
+
+   根据当前阶段删除对应的文件：
+
+   **proposal**：
+   - `artifacts/proposal.md`
+
+   **understand**：
+   - `artifacts/understanding.md`
+
+   **specs**：
+   - `artifacts/specs.md`
+
+   **impact**：
+   - `artifacts/impact-analysis.md`
+
+   **design**：
+   - `artifacts/design.md`
+   - `artifacts/ADR-*.md`（如果有）
+
+   **tasks**：
+   - `artifacts/tasks.md`
+   - `tasks/*.md`（所有任务文件）
+
+   **verify**：
+   - `artifacts/verification-report.md`
+
+   **review**：
+   - `artifacts/post-implementation-review.md`
+
+   使用 bash 命令删除文件：
+   ```bash
+   rm -f 6aspecdoc/brown/<name>/artifacts/<file>
+   ```
+
+6. **更新状态**
+
+   更新 `6aspecdoc/brown/<name>/status.json`：
+
+   a. 将当前阶段的状态从 "done" 改为 "pending"
+
+   b. 将上一个阶段的状态保持 "done"（不变）
+
+   c. 将当前阶段之后的所有阶段状态保持 "blocked"
+
+   d. 更新 status 字段为 "<current-phase>_pending"
+
+   e. 从 artifacts 数组中移除当前阶段的文件名
+
+   f. 更新 lastModified 时间戳
+
+   示例（从 tasks 回退，回到 design 完成的状态）：
+   ```json
+   {
+     "name": "example",
+     "flowDepth": "standard",
+     "status": "tasks_pending",
+     "createdAt": "2026-02-15T10:00:00Z",
+     "lastModified": "2026-02-15T10:30:00Z",
+     "phases": {
+       "understand": "done",
+       "specs": "done",
+       "impact": "done",
+       "design": "done",
+       "tasks": "pending",
+       "implement": "blocked"
+     },
+     "artifacts": ["understanding.md", "specs.md", "impact-analysis.md", "design.md"]
+   }
+   ```
+
+7. **显示回退结果**
+
+**输出**
+
+```
+## 回退成功：<name>
+
+**流程深度**: <flowDepth>
+**回退前阶段**: <current-phase>
+**回退后阶段**: <previous-phase>
+
+### 已删除的文件
+- <file1>
+- <file2>
+- ...
+
+### 当前状态
+- <previous-phase>: done（已完成）
+- <current-phase>: pending（待重新执行）
+
+### 下一步
+运行 `/6aspec:brown:<current-phase>` 重新执行该阶段，或运行 `/6aspec:brown:continue` 自动进入下一阶段。
+```
+
+**防护措施**
+- 必须确认需求未归档
+- 必须确认当前阶段已完成（状态为 "done"）
+- 不能回退第一个阶段
+- 必须用户确认后才能执行回退
+- 删除文件前检查文件是否存在
+- 更新状态时保持一致性
+
+**错误处理**
+
+- 如果需求不存在，提示创建新需求
+- 如果需求已归档，提示先取消归档
+- 如果当前在第一个阶段，提示无法回退
+- 如果所有阶段都是 pending，提示没有可回退的阶段
+- 如果文件删除失败，提示错误信息但继续更新状态

package/.6aspec/rules/brown/brown_specs_sop.md

@@ -0,0 +1,228 @@
+# 棕地需求 - Specs SOP
+
+Phase 1.5: 需求规格定义
+
+**输入**：`/6aspec:brown:specs` 后可选需求名称。
+
+**适用流程**：标准级、完整级
+
+**步骤**
+
+1. **选择需求并检查状态**
+
+   - 读取 `6aspecdoc/brown/<name>/status.json`
+   - 确认 `phases.understand` 为 "done"
+   - 如果未完成 Phase 1，提示先运行 `/6aspec:brown:understand`
+   - 确认流程深度为 "standard" 或 "complete"
+   - 如果是 "lightweight"，提示应该使用 `/6aspec:brown:proposal`
+
+2. **读取前置文档**
+
+   - `6aspecdoc/brown/<name>/requirement.md`
+   - `6aspecdoc/brown/<name>/artifacts/01-understanding.md`
+
+3. **读取问题答案**
+
+   从 understanding.md 中读取"待明确问题清单"及用户的答案：
+
+   - 检查问题清单中哪些问题已经有答案（标记为具体值而非"[待确认]"）
+   - 如果有未回答的问题，提示用户这些问题需要明确，但不阻塞 specs 阶段
+   - 基于已有的答案和现状分析，开始定义需求规格
+
+   注意：specs 阶段不再提出新问题，所有需求问题应该在 understand 阶段提出并收集。
+
+4. **定义功能需求**
+
+   基于需求理解和问题答案，明确定义系统应该具备的能力：
+
+   **功能需求格式**：
+   - FR-001: <功能描述>
+     - 输入：<输入内容>
+     - 输出：<输出内容>
+     - 业务规则：<业务规则>
+     - 验收标准：<验收标准>
+
+   **拆解原则**：
+   - 每个功能需求应该是独立的、可验证的
+   - 功能需求应该从用户视角描述（做什么，而不是怎么做）
+   - 避免技术实现细节（技术细节放在 design 阶段）
+
+5. **定义非功能需求**
+
+   明确系统应该满足的质量标准：
+
+   - NFR-001: 性能需求（响应时间、并发量等）
+   - NFR-002: 安全需求（权限控制、数据加密等）
+   - NFR-003: 可用性需求（易用性、可维护性等）
+   - NFR-004: 兼容性需求（浏览器、数据库等）
+
+6. **定义范围和约束**
+
+   明确做什么、不做什么：
+
+   **范围定义**：
+   - 包含：<明确包含的功能>
+   - 不包含：<明确不包含的功能>
+
+   **约束条件**：
+   - 技术约束：<技术上的限制>
+   - 业务约束：<业务上的限制>
+   - 时间约束：<时间上的限制>
+
+7. **定义验收标准**
+
+   明确如何验证需求已经实现：
+
+   - AC-001: <功能验收标准>
+   - AC-002: <非功能验收标准>
+   - AC-003: <数据验收标准>
+
+8. **创建需求规格文档**
+
+   创建 `6aspecdoc/brown/<name>/artifacts/01.5-specs.md`：
+   ```markdown
+   # Phase 1.5: 需求规格定义
+
+   > **需求**: <name>
+   > **阶段**: Phase 1.5 - 需求规格
+   > **状态**: ✅ 已完成
+   > **完成时间**: <timestamp>
+
+   ## 1. 需求概述
+
+   ### 1.1 业务目标
+   <为什么需要这个功能>
+
+   ### 1.2 使用场景
+   <谁用、什么时候用、怎么用>
+
+   ### 1.3 范围定义
+   **包含**：
+   - <明确包含的功能>
+
+   **不包含**：
+   - <明确不包含的功能>
+
+   ## 2. 功能需求
+
+   ### FR-001: <功能名称>
+   **描述**：<功能描述>
+
+   **输入**：
+   - <输入内容>
+
+   **输出**：
+   - <输出内容>
+
+   **业务规则**：
+   - <业务规则1>
+   - <业务规则2>
+
+   **验收标准**：
+   - <验收标准1>
+   - <验收标准2>
+
+   ### FR-002: <功能名称>
+   ...
+
+   ## 3. 非功能需求
+
+   ### 3.1 性能需求
+   - NFR-001: <性能要求>
+
+   ### 3.2 安全需求
+   - NFR-002: <安全要求>
+
+   ### 3.3 可用性需求
+   - NFR-003: <可用性要求>
+
+   ### 3.4 兼容性需求
+   - NFR-004: <兼容性要求>
+
+   ## 4. 约束条件
+
+   ### 4.1 技术约束
+   - <技术上的限制>
+
+   ### 4.2 业务约束
+   - <业务上的限制>
+
+   ### 4.3 时间约束
+   - <时间上的限制>
+
+   ## 5. 验收标准
+
+   ### 5.1 功能验收
+   - AC-001: <功能验收标准>
+   - AC-002: <功能验收标准>
+
+   ### 5.2 非功能验收
+   - AC-003: <非功能验收标准>
+   - AC-004: <非功能验收标准>
+
+   ### 5.3 数据验收
+   - AC-005: <数据验收标准>
+
+   ## 6. 下一步
+
+   运行 `/6aspec:brown:impact` 进行影响面分析。
+   ```
+
+9. **更新状态**
+
+   更新 `6aspecdoc/brown/<name>/status.json`：
+   ```json
+   {
+     "status": "impact_pending",
+     "phases": {
+       "understand": "done",
+       "specs": "done",
+       "impact": "pending",
+       ...
+     },
+     "artifacts": ["01-understanding.md", "01.5-specs.md"]
+   }
+   ```
+
+**输出**
+
+```
+## Phase 1.5 完成：需求规格定义
+
+**需求**: <name>
+**进度**: 2/8 阶段完成（标准级）或 2/9 阶段完成（完整级）
+
+### 需求概要
+- 功能需求：<数量> 个
+- 非功能需求：<数量> 个
+- 验收标准：<数量> 个
+
+### 核心功能
+<列出 2-3 个核心功能需求>
+
+### 关键约束
+<列出 1-2 个关键约束>
+
+### 文档位置
+6aspecdoc/brown/<name>/artifacts/01.5-specs.md
+
+### 下一步
+- 直接回复补充或修正需求规格 → 我会更新本阶段文档（01.5-specs.md）
+- 运行 `/6aspec:brown:impact` → 进入影响面分析阶段
+- 运行 `/6aspec:brown:continue` → 自动进入下一阶段
+```
+
+**用户补充信息时的处理**
+
+当用户补充需求细节、修正功能需求时（未使用阶段命令）：
+1. 将用户的补充整合到 `01.5-specs.md` 的对应章节（功能需求、非功能需求、验收标准等）
+2. 展示变更摘要
+3. 再次提示：可以继续补充，或通过命令进入下一阶段
+4. **禁止**：不得自动进入下一阶段
+
+**防护措施**
+- 必须先完成 Phase 1（understand）
+- 只适用于标准级和完整级流程
+- 功能需求必须从用户视角描述，避免技术实现细节
+- 验收标准必须具体、可验证
+- 需求问题的答案应该体现在功能需求定义中，而不是单独列出