diff --git a/.agents/skills/monisuo-dev/README.md b/.agents/skills/monisuo-dev/README.md index 4601196..b644530 100644 --- 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 diff --git a/.agents/skills/monisuo-dev/SKILL.md b/.agents/skills/monisuo-dev/SKILL.md index 3a80e6f..88c7a7d 100644 --- 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 分支完成 + +### 严禁 +- 不准跳过根因分析直接修复 +- 不准用"应该修好了"代替验证 +- 不准在疲劳时降低验证标准