feat: 优化

2026-04-04 20:42:15 +08:00
parent 682f5dc63b
commit 2850629e0d
2 changed files with 362 additions and 205 deletions
--- a/.agents/skills/monisuo-dev/README.md
+++ b/.agents/skills/monisuo-dev/README.md
@@ -4,138 +4,104 @@

 ### 1. 使用技能

-在 OpenClaw 中提及 "monisuo 开发" 即可触发此技能。
+在 Claude Code 中提及 "monisuo 开发" 即可触发此技能。

 ### 2. 开发流程

 ```
-需求分析 → 模块化开发 → 测试验证 → 构建部署
+分支隔离 → 需求探索 → 计划分解 → 子代理开发 → 双重审查 → 验证门控 → 构建 → 分支完成
 ```

-## 详细说明
+## 完整流程

-### Phase 1: 需求结构化定义
+### Phase 0: 分支隔离
+- 使用 git worktree 创建隔离工作区
+- 分支名: `feat/[feature-name]`

-**目标**: 将需求转化为结构化的 Feature Spec
+### Phase 1: 需求探索
+- 探索项目上下文
+- 逐步提问理解需求
+- 提出 2-3 个方案含权衡分析
+- 逐节确认设计
+- 写入 Feature Spec 并自审
+- 用户确认后才进入下一阶段

-**步骤**:
-1. 收集需求信息
-2. 创建 `docs/features/[功能名].md`
-3. 填写 Feature Spec 模板
-4. 评审并确认
+**Feature Spec 模板位置**: `docs/features/FEATURE_TEMPLATE.md`
+**Spec 输出**: `docs/features/[功能名].md`

-**模板位置**: `docs/features/FEATURE_TEMPLATE.md`
+### Phase 1.5: 计划分解
+- 探索现有代码库
+- 定义 API 契约和数据模型
+- 编写咬合级实施计划（每步 2-5 分钟）
+- TDD 红绿循环设计
+- 计划自审

-### Phase 2: 模块化开发
+**计划输出**: `docs/superpowers/plans/YYYY-MM-DD-[feature-name].md`

-**目标**: 按模块实现功能
+### Phase 2: 子代理驱动开发
+- 每个任务独立子代理执行
+- 双重审查: 规格合规 → 代码质量
+- 审查不通过循环修复直到通过

-**步骤**:
-1. 根据设计文档实现代码
-2. 遵循代码规范
-3. 使用设计系统（AppSpacing, AppRadius, AppColorScheme）
-4. 提交代码
+### Phase 3: 质量验证（铁律门控）
+- Agent A: 代码审查 + simplify + 测试
+- 验证铁律: 没有运行命令不得声称通过

-**Flutter 开发**:
-```bash
-cd flutter_monisuo
-flutter pub get
-flutter run -d chrome
-```
+### Phase 4: 功能验证
+- Agent B: 逐条验证 Spec 中的测试用例
+- 追踪代码路径确认逻辑正确

-**Admin 开发**:
-```bash
-cd monisuo-admin
-pnpm install
-pnpm dev
-```
+### Phase 5: 构建
+- Agent C: 后端 + Flutter 构建
+- 必须看到 exit 0 才算成功

-### Phase 3: 测试与重构
+### Phase 6: 分支完成
+- 合并到 main / 创建 PR / 保留分支

-**目标**: 确保代码质量和功能正确性
+## 融合的超级技能

-**步骤**:
-1. 应用 clean-code 技能优化代码
-2. 编写/更新 API 测试脚本
-3. 运行测试脚本
-4. 修复 Bug 直到全部通过
-
-**运行 API 测试**:
-```bash
-cd tests/api
-chmod +x test-template.sh
-./test-template.sh
-```
-
-**Flutter 单元测试**:
-```bash
-cd flutter_monisuo
-flutter test
-```
-
-### Phase 4: 构建与部署
-
-**目标**: 构建生产版本并提交
-
-**Flutter Web 构建**:
-```bash
-cd flutter_monisuo
-flutter build web --release --dart-define=ENV=prod
-```
-
-**Admin 构建**:
-```bash
-cd monisuo-admin
-pnpm build
-```
-
-**Git 提交**:
-```bash
-git add .
-git commit -m "feat(模块): 功能描述
-
- 详细说明 1
- 详细说明 2"
-git push origin main
-```
-
-## 目录结构
-
-```
-monisuo/
-├── .agents/skills/monisuo-dev/  # 本技能
-├── docs/
-│   └── features/               # Feature Spec 文档
-│       └── FEATURE_TEMPLATE.md # 模板
-├── flutter_monisuo/            # Flutter 前端
-├── monisuo-admin/              # Admin 后台
-└── tests/
-    ├── api/                    # API 测试脚本
-    │   └── test-template.sh    # 测试模板
-    └── e2e/                    # 端到端测试
-```
+| 超级技能 | 用途 | 阶段 |
+|----------|------|------|
+| using-git-worktrees | 分支隔离 | Phase 0 |
+| brainstorming | 需求探索、方案对比 | Phase 1 |
+| writing-plans | 咬合级计划分解 | Phase 1.5 |
+| subagent-driven-development | 子代理执行+双重审查 | Phase 2 |
+| verification-before-completion | 验证铁律 | Phase 3 |
+| systematic-debugging | 系统化 Bug 修复 | Bug 循环 |
+| finishing-a-development-branch | 分支完成 | Phase 6 |

 ## 常用命令

 ### Flutter
 ```bash
-flutter pub get                  # 安装依赖
-flutter run -d chrome            # 开发模式
-flutter analyze                  # 代码检查
-flutter test                     # 运行测试
-flutter build web --release --dart-define=ENV=prod  # 生产构建
+cd flutter_monisuo
+flutter pub get                                        # 安装依赖
+flutter run -d chrome                                  # 开发模式
+flutter analyze                                        # 代码检查
+flutter test                                           # 运行测试
+flutter build web --release --dart-define=ENV=prod     # 生产构建
+```
+
+### 后端
+```bash
+mvn spring-boot:run                    # 开发服务
+mvn compile                            # 编译
+mvn test                               # 测试
+mvn clean package -DskipTests          # 打包
 ```

 ### Admin
 ```bash
-pnpm install                     # 安装依赖
-pnpm dev                         # 开发模式
-pnpm build                       # 生产构建
+cd monisuo-admin
+pnpm install                           # 安装依赖
+pnpm dev                               # 开发模式
+pnpm build                             # 生产构建
+pnpm lint / pnpm lint:fix              # 代码检查
 ```

 ### 测试
 ```bash
-./tests/api/test-template.sh     # 运行 API 测试
+./tests/api/test-template.sh           # API 测试
 ```

 ## 环境配置
@@ -145,21 +111,31 @@ pnpm build                       # 生产构建
 | 开发 | dev | http://localhost:5010 |
 | 生产 | prod | http://8.155.172.147:5010 |

-## 最佳实践
+## 代码规范

-1. **需求阶段**: 充分理解业务，明确验收标准
-2. **开发阶段**: 小步迭代，频繁提交，遵循规范
-3. **测试阶段**: 自动化测试优先，覆盖完整
-4. **部署阶段**: 使用生产配置，灰度发布
+- **Flutter**: `flutter analyze` 无错，用 AppSpacing/AppRadius/AppColorScheme，禁止硬编码颜色
+- **Java**: Lombok 简化，资金变动方法加 `@Transactional(rollbackFor = Exception.class)`，RESTful 设计
+- **Admin**: TypeScript strict，TanStack Vue Query 做数据请求，shadcn-vue 组件不手动编辑
+- **Git**: Conventional Commits — `feat(module): 描述`、`fix(module): 描述`

-## 参考资源
+## 目录结构

- [Flutter 文档](https://flutter.dev/docs)
- [Spring Boot 文档](https://spring.io/projects/spring-boot)
- [Conventional Commits](https://www.conventionalcommits.org/)
- [Clean Code 技能](~/.agents/skills/clean-code/SKILL.md)
+```
+monisuo/
+├── .agents/skills/monisuo-dev/  # 本技能
+├── docs/
+│   ├── features/               # Feature Spec 文档
+│   │   └── FEATURE_TEMPLATE.md # 模板
+│   └── superpowers/plans/      # 实施计划
+├── flutter_monisuo/            # Flutter 前端
+├── monisuo-admin/              # Admin 后台
+├── src/main/java/              # Java 后端
+└── tests/
+    ├── api/                    # API 测试脚本
+    └── e2e/                    # 端到端测试
+```

 ---
-
-**版本**: v1.0.0  
-**创建日期**: 2026-03-23
+**版本**: v2.0.0
+**更新日期**: 2026-04-04
+**变更**: 融合超级技能体系，新增 brainstorming、writing-plans、subagent-driven-development、verification 铁律、systematic-debugging
--- a/.agents/skills/monisuo-dev/SKILL.md
+++ b/.agents/skills/monisuo-dev/SKILL.md
@@ -1,124 +1,257 @@
 ---
 name: monisuo-dev
-description: Monisuo 项目结构化开发流程。需求分析 → 架构设计 → 模块化开发 → 精简测试 → 功能验证 → 构建。
+description: Monisuo 项目结构化开发流程。融合超级技能体系：需求探索 → 计划分解 → 子代理开发 → 双重审查 → 验证门控 → 构建。
 ---

 # Monisuo 开发工作流

+融合超级技能（Superpowers）的完整开发流程。每个阶段引用对应的超级技能，确保高质量交付。
+
 ## 流程概览

 ```
-Phase 1: 需求定义 → Phase 1.5: 架构设计 → Phase 2: 模块化开发（子任务逐步推进）
-     ↑                                              │
-     │                                              ↓
-     │                                    主对话：同步更新 Spec
-     │                                              │
-     │                                              ↓
-     │                                   [Agent A] Phase 3: 精简 + 测试 → 输出审查报告
-     │                                              │
-     │                                              ↓ (通过)
-     │                                   [Agent B] Phase 4: 功能验证（接收审查报告）
-     │                                              │
-     │                                              ↓ (通过)
-     │                                   [Agent C] Phase 5: 构建
-     │                                              │
-     └──────────────── Bug 修复 ←──────────────────┘
+Phase 0: 分支隔离 → using-git-worktrees
+    ↓
+Phase 1: 需求探索 → 融合 brainstorming（提问→方案→评审）
+    ↓
+Phase 1.5: 计划分解 → 融合 writing-plans（咬合级任务+TDD）
+    ↓
+Phase 2: 开发执行 → 融合 subagent-driven-development（子代理+双重审查）
+    ↓
+Phase 3: 质量验证 → verification-before-completion 铁律门控
+    │                                      ↓ (通过)
+    │                          [Agent A] 精简 + 测试 → 输出审查报告
+    │                                      ↓ (通过)
+    │                          [Agent B] Phase 4: 功能验证
+    │                                      ↓ (通过)
+    │                          [Agent C] Phase 5: 构建
+    ↓
+Phase 6: 分支完成 → finishing-a-development-branch
+    ↑
+Bug 修复循环 → systematic-debugging（根因分析优先）
 ```

-**Phase 1/1.5/2 在主对话完成，Phase 3/4/5 分别启动独立 Agent。**
-**所有 Agent prompt 中的 `[feature-name]` 由主对话替换为实际值后再传入。**
+**Phase 0/1/1.5 在主对话完成**（需与用户交互，子代理无法代替）。但其中的**代码库探索**环节可并行派发 Explore 子代理加速。
+**Phase 2 用子代理驱动，Phase 3/4/5 分别启动独立 Agent。**

 ---

-## Phase 1: 需求定义
+## Phase 0: 分支隔离

-将用户需求结构化为 Feature Spec，输出到 `docs/features/[feature-name].md`。
+**引用技能:** `superpowers:using-git-worktrees`

-### Feature Spec 结构
-
-```markdown
-# [功能名称]
-
-## 概述
-功能名称 / 优先级(P0-P2) / 业务背景(痛点→方案→收益)
-
-## 用户故事
-作为 [角色]，我希望 [行为]，以便 [目的]
-
-## 功能列表
- [ ] 功能点1
- [ ] 功能点2
-
-## 技术方案（Phase 1.5 填充）
-### API 设计
-### 数据模型
-### 技术决策
-
-## 测试用例
- [ ] 正常 / 异常 / 边界
-
-## 验收标准
-```
+开发前创建隔离工作区，避免在 main 分支直接修改。

 ### 执行步骤
-1. 与用户确认需求，识别关键场景和约束
-2. 创建 `docs/features/[feature-name].md`，填充概述、用户故事、功能列表、测试用例
-3. 与用户评审确认
+1. 确认当前在 main 分支且工作区干净
+2. 使用 `EnterWorktree` 创建隔离工作树，分支名 `feat/[feature-name]`
+3. 后续所有开发在 worktree 中进行
+
+### 例外
+- 紧急热修复可跳过 worktree，直接在 main 分支操作
+- 用户明确要求跳过时可以跳过

 ---

-## Phase 1.5: 架构设计
+## Phase 1: 需求探索

-编码前确定技术方案。**必须先探索代码库再设计。**
+**引用技能:** `superpowers:brainstorming`
+
+将用户需求通过协作对话转化为结构化设计。不再直接写 Spec，而是先充分探索。
+
+### 执行步骤
+
+1. **探索项目上下文** — 检查相关文件、文档、最近提交，理解现有架构
+   - **可用 Explore 子代理并行加速**：涉及多个独立模块时（如后端+Flutter+Admin），派发多个 Explore 子代理并行扫描，结果汇总到主对话
+   - 单模块时直接在主对话 Glob/Grep/Read 即可，无需子代理
+
+2. **逐步提问** — 一次一个问题，理解目的、约束、成功标准（必须主对话）
+   - 优先使用选择题，也可开放式
+   - 评估范围：如果涉及多个独立子系统，先分解再逐个设计
+
+3. **提出 2-3 个方案** — 含权衡分析和推荐理由
+   - 领先展示推荐方案及原因
+   - 每个方案列出优劣
+
+4. **逐节呈现设计** — 按复杂度控制篇幅
+   - 每节确认是否正确
+   - 覆盖：架构、组件、数据流、错误处理、测试
+
+5. **写入 Feature Spec** — 保存到 `docs/features/[feature-name].md`
+
+   ```markdown
+   # [功能名称]
+
+   ## 概述
+   功能名称 / 优先级(P0-P2) / 业务背景(痛点→方案→收益)
+
+   ## 用户故事
+   作为 [角色]，我希望 [行为]，以便 [目的]
+
+   ## 功能列表
+   - [ ] 功能点1
+   - [ ] 功能点2
+
+   ## 技术方案（Phase 1.5 填充）
+   ### API 设计
+   ### 数据模型
+   ### 技术决策
+
+   ## 测试用例
+   - [ ] 正常 / 异常 / 边界
+
+   ## 验收标准
+   ```
+
+6. **Spec 自审** — 快速内联检查
+   - 占位符扫描：有无 TBD、TODO、未完成章节？修复。
+   - 内部一致性：各章节是否矛盾？
+   - 范围检查：是否聚焦到单个实施计划？
+   - 歧义检查：需求是否有两种解读？选定一种明确写出。
+
+7. **用户确认** — 让用户审阅 Spec 文件，确认后才进入下一阶段
+
+### 硬门控
+**用户未确认 Spec 之前，不得进入 Phase 1.5。**
+
+---
+
+## Phase 1.5: 计划分解
+
+**引用技能:** `superpowers:writing-plans`
+
+将 Spec 转化为咬合级实施计划，每步 2-5 分钟。必须先探索代码库再设计。

 ### 执行步骤

 1. **探索现有代码库**
-   - Glob/Grep/Read 扫描相关模块，理解现有模式和架构
+   - **可用 Explore 子代理并行加速**：涉及多个独立模块时（如后端现有 API、Flutter 现有页面、Admin 现有路由），派发多个 Explore 子代理并行扫描
+   - 单模块时直接在主对话 Glob/Grep/Read 即可
   - 识别可复用的组件、Service、工具类
   - 确认集成点

-2. **定义 API 契约** — 方法、路径、请求/响应体，写入 Spec 的「API 设计」
+2. **更新 Spec 技术方案**
+   - 定义 API 契约 — 方法、路径、请求/响应体
+   - 设计数据模型 — 表结构、Entity/DTO/VO 映射
+   - 记录技术决策 — 选型理由、模块职责、关键约束

-3. **设计数据模型** — 表结构、Entity/DTO/VO 映射，写入 Spec 的「数据模型」
+3. **映射文件结构** — 列出所有需要创建/修改的文件及职责

-4. **记录技术决策** — 选型理由、模块职责、关键约束，写入 Spec 的「技术决策」
+4. **编写实施计划** — 保存到 `docs/superpowers/plans/YYYY-MM-DD-[feature-name].md`
+
+   计划头部：
+   ```markdown
+   # [功能名称] Implementation Plan
+
+   > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development to implement this plan task-by-task.
+
+   **Goal:** [一句话描述]
+
+   **Architecture:** [2-3 句方案描述]
+
+   **Tech Stack:** [关键技术]
+
+   ---
+   ```
+
+5. **任务分解原则**
+   - 每步一个动作（2-5 分钟）
+   - TDD 红绿循环：写失败测试 → 验证失败 → 最小实现 → 验证通过 → 提交
+   - 按模块自底向上：数据层 → 后端 API → Flutter 前端 → Admin 前端
+   - 不允许占位符：每步必须包含实际代码和命令
+
+   ```markdown
+   ### Task N: [组件名称]
+
+   **Files:**
+   - Create: `exact/path/to/file`
+   - Modify: `exact/path/to/existing.java:123-145`
+   - Test: `tests/exact/path/test`
+
+   - [ ] **Step 1: 写失败测试**
+   - [ ] **Step 2: 运行验证失败**
+   - [ ] **Step 3: 最小实现**
+   - [ ] **Step 4: 运行验证通过**
+   - [ ] **Step 5: 提交**
+   ```
+
+6. **计划自审** — 对照 Spec 逐条检查
+   - 覆盖性：Spec 每条需求都有对应任务？
+   - 占位符扫描：无 TBD/TODO
+   - 类型一致性：前后任务的类型、方法签名一致
+
+7. **用户提供执行选择**
+   - 推荐子代理驱动开发（Phase 2 默认方式）
+   - 用户选择内联执行时，按 `superpowers:executing-plans` 执行

 ### 完成标准
 - 已扫描现有代码，无重复造轮子
 - API 契约完整，前后端可并行开发
 - 数据模型与现有表结构兼容
+- 每个任务有完整代码和验证命令

 ---

-## Phase 2: 模块化开发
+## Phase 2: 开发执行

-依据 Spec 中的 API 契约和数据模型，**按子模块逐步推进**，自底向上开发：
+**引用技能:** `superpowers:subagent-driven-development`
+
+每个子任务独立子代理执行，完成后双重审查（规格合规 + 代码质量）。
+
+### 核心原则
+- 每个任务启动**新的子代理**，不继承主对话上下文
+- 主对话负责提取任务文本、构造上下文、传递给子代理
+- 子代理完成后，先做规格合规审查，再做代码质量审查
+
+### 执行流程
+
+对计划中的每个任务：

 ```
-2a. 数据层 → 2b. 后端 API → 2c. Flutter 前端 → 2d. Admin 前端（如有）
-    DDL/Entity   Controller/Service  Model/Provider/UI   Vue Pages
+1. 提取任务全文和上下文
+2. 启动实现子代理（implementer）
+3. 子代理提问？→ 回答后重新派发
+4. 子代理实现、测试、提交、自审
+5. 启动规格审查子代理 → 不通过？→ 实现子代理修复 → 重新审查
+6. 启动质量审查子代理 → 不通过？→ 实现子代理修复 → 重新审查
+7. 标记任务完成
 ```

-### 子模块执行方式
- 每个子模块独立完成，不与其他子模块混在一起
- 每完成一个子模块，确认无编译错误再进入下一个
- 后端子模块完成后可先验证 API，前端再对接
+### 模型选择策略
+- **机械任务**（1-2 文件，Spec 完整）→ 快速模型
+- **集成任务**（多文件，模式匹配）→ 标准模型
+- **架构/审查任务** → 最强模型

-### 代码规范
+### 子代理行为准则
 - Flutter: `flutter analyze` 无错，用 AppSpacing/AppRadius/AppColorScheme，禁止硬编码颜色
 - Java: Lombok 简化，资金变动方法加 `@Transactional(rollbackFor = Exception.class)`，RESTful 设计
+- Admin: TypeScript strict，TanStack Vue Query 做数据请求，shadcn-vue 组件不手动编辑
+
+### 禁止事项
+- 不要在 main/master 分支直接实现
+- 不要跳过任何审查（规格或质量）
+- 不要在审查有未修复问题时进入下一任务
+- 不要并行派发多个实现子代理（会冲突）
+- 不要让子代理自行读取计划文件（主对话提供全文）

 ### Spec 同步
-Phase 2 全部完成后、启动 Agent 前，**主对话必须更新 Spec**：
+Phase 2 全部完成后、启动 Agent A 之前，**主对话必须更新 Spec**：
 - 实际实现与设计有差异时，以实现为准更新 Spec
 - 确保 Phase 3/4 的 Agent 读到的是最新状态

 ---

-## Phase 3: 精简 + 测试（Agent A）
+## Phase 3: 质量验证（铁律门控）

-Phase 2 完成且 Spec 已同步后，启动独立 Agent 执行代码精简和自动化测试。
+**引用技能:** `superpowers:verification-before-completion`
+
+### 验证铁律
+
+```
+没有新鲜验证证据，不得声明任何状态。
+```
+
+Phase 2 完成后，启动独立 Agent 执行代码精简和自动化测试。

 ### 启动 Agent A

@@ -128,6 +261,10 @@ Agent(
  prompt: |
    你是 Monisuo 项目质量 Agent，独立完成以下任务，不要询问用户。

+    ## 铁律
+    没有运行验证命令，不得声称"通过"或"完成"。
+    使用"应该通过" = 没有验证。
+
    ## 1. 读取 Spec
    - 路径: docs/features/[feature-name].md
    - 理解验收标准
@@ -141,9 +278,9 @@ Agent(
    - 对变更代码执行 /simplify：审查复用性、质量和效率，修复发现的问题
    - 精简完成后重新运行 git diff 确认变更合理

-    ## 4. 测试
-    - 后端: mvn test
-    - Flutter: cd flutter_monisuo && flutter test
+    ## 4. 测试（必须运行并读取完整输出）
+    - 后端: mvn test（读取输出，确认 0 failures）
+    - Flutter: cd flutter_monisuo && flutter test（读取输出，确认 0 failures）
    - API: ./tests/api/test-[feature].sh（如存在）

    ## 5. 输出审查报告（供 Agent B 使用）
@@ -153,22 +290,25 @@ Agent(
    - 精简改动摘要（改了什么、为什么改）

    ### 测试结果
-    | 项目 | 状态 | 备注 |
-    |------|------|------|
+    | 项目 | 状态 | 证据（命令输出摘要） |
+    |------|------|----------------------|
    | 代码审查 | ✅/❌ | |
    | 代码精简 | ✅/❌ | 改动摘要 |
-    | 后端测试 | ✅/❌ | |
-    | Flutter 测试 | ✅/❌ | |
+    | 后端测试 | ✅/❌ | X/Y 通过 |
+    | Flutter 测试 | ✅/❌ | X/Y 通过 |

    如有 Bug，列出：文件、原因、修复建议。返回主对话修复后重新验证。
 )
 ```

+### 门控
+Agent A 报告中任何一项 ❌ → 主对话修复 → 重新启动 Agent A。
+
 ---

 ## Phase 4: 功能验证（Agent B）

-**Agent A 全部通过后**，启动独立 Agent。Agent B 接收 Agent A 的审查报告，避免重复读代码。
+**Agent A 全部通过后**，启动独立 Agent。

 ### 启动 Agent B

@@ -178,6 +318,9 @@ Agent(
  prompt: |
    你是 Monisuo 项目功能验证 Agent。基于 Feature Spec 中的测试用例，验证功能实现是否正确。不要询问用户。

+    ## 铁律
+    没有运行验证命令，不得声称"通过"。逐条代码追踪，不是靠印象。
+
    ## 1. 读取 Spec
    - 路径: docs/features/[feature-name].md
    - 提取「测试用例」和「验收标准」
@@ -189,21 +332,15 @@ Agent(

    ## 3. 逐条验证测试用例
    对 Spec 中的每条测试用例：
-    - **正常流程**：追踪代码路径，确认主流程逻辑正确（参数传递、返回值、状态变更）
+    - **正常流程**：追踪代码路径 Controller → Service → Mapper，确认参数传递、返回值、状态变更
    - **异常流程**：确认错误处理覆盖（参数校验、权限检查、边界条件）
    - **边界条件**：空值、零值、溢出、并发等极端场景是否有防护

-    ### 验证方法
-    - **后端 API**：阅读 Controller → Service → Mapper 代码路径，确认请求参数、业务逻辑、数据库操作与 Spec 一致
-    - **前端页面**：阅读 UI → Provider/State → Service 代码路径，确认交互流程、状态管理、错误展示正确
-    - **数据一致性**：确认资金变动相关的操作有事务注解、余额校验、流水记录
-
    ## 4. 输出验证报告
-    | 用例编号 | 用例描述 | 验证结果 | 备注 |
+    | 用例编号 | 用例描述 | 验证结果 | 证据 |
    |----------|----------|----------|------|
-    | TC-01 | 正常：xxx | ✅ 通过 / ❌ 失败 | 具体原因 |
-    | TC-02 | 异常：xxx | ✅ 通过 / ❌ 失败 | 具体原因 |
-    | ... | ... | ... | ... |
+    | TC-01 | 正常：xxx | ✅/❌ | 追踪的具体代码路径 |
+    | TC-02 | 异常：xxx | ✅/❌ | 具体原因 |

    ### 总结
    - 通过率：X/Y
@@ -214,11 +351,14 @@ Agent(
 )
 ```

+### 门控
+Agent B 报告中有 ❌ → 主对话修复 → 重新启动 Agent B。
+
 ---

 ## Phase 5: 构建（Agent C）

-**Agent A 和 Agent B 全部通过后**，启动独立 Agent 执行构建。
+**Agent A 和 Agent B 全部通过后**，启动独立 Agent。

 ### 启动 Agent C

@@ -228,13 +368,16 @@ Agent(
  prompt: |
    你是 Monisuo 项目构建 Agent，独立完成构建任务，不要询问用户。

-    ## 1. 构建
+    ## 铁律
+    没有运行构建命令并看到 exit 0，不得声称"构建成功"。
+
+    ## 1. 构建（必须运行并读取完整输出）
    - 后端: mvn clean package -DskipTests → target/monisuo-*.jar
    - Flutter: cd flutter_monisuo && flutter build web --release --dart-define=ENV=prod → build/web/

    ## 2. 输出报告
-    | 项目 | 状态 | 备注 |
-    |------|------|------|
+    | 项目 | 状态 | 证据（命令输出摘要） |
+    |------|------|----------------------|
    | 后端构建 | ✅/❌ | 产物路径 |
    | Flutter 构建 | ✅/❌ | 产物路径 |

@@ -242,11 +385,49 @@ Agent(
 )
 ```

+### 门控
+Agent C 报告中有 ❌ → 主对话修复 → 重新启动 Agent C。
+
+---
+
+## Phase 6: 分支完成
+
+**引用技能:** `superpowers:finishing-a-development-branch`
+
+所有 Phase 通过后，完成开发分支。
+
+### 执行步骤
+1. 确认所有测试通过（Phase 3 证据）
+2. 确认功能验证通过（Phase 4 证据）
+3. 确认构建成功（Phase 5 证据）
+4. 向用户展示选项：
+   - 合并到 main
+   - 创建 PR
+   - 保留分支待后续处理
+5. 执行用户选择
+6. 退出 worktree
+
 ---

 ## Bug 修复循环

- **Agent A 失败**（测试不通过）→ 主对话修复 Bug → 重新启动 Agent A
- **Agent B 失败**（功能验证不通过）→ 主对话修复逻辑 → 重新启动 Agent B
+**引用技能:** `superpowers:systematic-debugging`
+
+遇到 Bug 时，严禁猜测式修复。
+
+### 四阶段流程
+1. **根因调查** — 重现问题 → 缩小范围 → 找到根因（未完成此阶段不得提出修复）
+2. **修复方案** — 针对根因设计最小修复
+3. **实施修复** → 回到 Phase 3 重新验证
+4. **回归验证** — 确认修复未引入新问题
+
+### 错误修复路由
+- **Agent A 失败**（测试不通过）→ 主对话用 systematic-debugging 修复 → 重新启动 Agent A
+- **Agent B 失败**（功能验证不通过）→ 主对话用 systematic-debugging 修复 → 重新启动 Agent B
 - **Agent C 失败**（构建不通过）→ 主对话修复构建问题 → 重新启动 Agent C
- **全部通过** → 开发完成
+- **全部通过** → Phase 6 分支完成
+
+### 严禁
+- 不准跳过根因分析直接修复
+- 不准用"应该修好了"代替验证
+- 不准在疲劳时降低验证标准