Enterprise Iteration Agent

Enterprise Iteration Agent — 企业级全栈迭代工作流

理念: 一个迭代就是一个闭环。从需求理解到记忆沉淀，Agent 维护完整的状态机，确保每个阶段都有产出、每个决策都有记录、每段经验都能复用。

核心能力

1. 状态机驱动: 7阶段自动推进，支持前进/回退/跳过
2. 路径感知: 自动读取需求目录与代码目录，减少人工指定路径
3. 子Skill编排: 按需调用现有111个Skill中的相关能力
4. 上下文继承: 前一阶段的产出自动注入下一阶段
5. 并行加速: DEV阶段可拆分为前后端并行工作流

迭代状态机

INIT → REQ → DES → DEV → TST → REV → DEP → MEM → END
 │      │     │     │     │     │     │     │
 └──────┴─────┴─────┴─────┴─────┴─────┴─────┘
              ↑ 支持任意回退

路径感知配置（用户可自定义）

Agent 启动时会尝试读取以下路径（用户首次使用时确认或修正）：

路径仅作示例，首次触发时 Agent 会询问用户确认实际路径。

各阶段详细工作流

阶段一：INIT → 启动

触发语: "开始开发【xxx】需求" / "跑一个迭代" / "处理本次迭代"

动作:

1. 询问用户迭代名称与需求文件路径
2. 初始化迭代看板（Markdown 表格）
3. 读取需求文档，提取：
   • 需求背景与目标
   • 涉及的业务模块
   • 验收标准（如有Gherkin则直接提取）
   • 预计改动范围（前端页面/后端接口/数据库表）
4. 输出迭代计划书：
   • 阶段拆分建议
   • 风险评估（如涉及公共组件改造、接口兼容性）
   • 并行机会识别（前后端是否可解耦）

状态转换:

• 用户确认 → 推进到 REQ
• 用户要求补充信息 → 停留在 INIT

阶段二：REQ → 需求理解

核心目标: 把模糊的需求变成结构化的开发输入

动作:

1. 调用 openspec-sdd 能力：
   • 输出 OpenSpec 规范文档（6阶段）
   • 提取 Gherkin 验收场景
   • 生成开发任务分解表
2. 如需原型验证 → 调用 prd-to-demo 生成可交互 HTML 原型
3. 如需需求流转 → 调用 dev-toolkit-integrator 检查禅道/Jira 状态
4. 输出需求确认清单：
   • 功能列表（必须/应该/可以）
   • 边界条件与异常场景
   • 数据权限与按钮权限要求
   • 涉及的现有模块与接口

回退条件: 需求不清晰（无验收标准、无原型、无字段定义）→ 退回 INIT 要求补充

阶段三：DES → 架构设计

核心目标: 产出可执行的工程方案

动作:

1. 数据库设计（如需新建/改表）:
   • 调用 database-designer：ERD + MySQL DDL + Java Entity
   • 调用 erd-document：完整数据库设计文档（11章节）
   • 确保包含标准字段：remark, create_time, edit_time, delete_flag
2. API设计:
   • 调用 api-doc-generator：Swagger/OpenAPI 注解 + 字段说明
   • 明确接口前缀：/api/（前端）、/feign/（内部）、/open-api/（第三方）
3. UI设计（如需新页面）:
   • 调用 frontend-design 或 huashu-design 确定视觉方向
   • 调用 taste-skill 去除AI味，提升设计品质
   • 调用 diagram-design 输出页面信息架构图
4. 输出设计决策记录（ADR）:
   • 技术选型理由
   • 表结构设计依据
   • 接口边界划分
   • 潜在风险与回滚方案

状态转换:

• 设计通过 → DEV
• 设计有争议 → 停留在 DES，调用 brainstorming 辅助决策
• 发现需求遗漏 → 回退 REQ

阶段四：DEV → 编码开发

核心目标: 高质量代码产出，支持前后端并行

动作:

1. 环境确认:
   • 确认当前分支（基于 solo-parallel-dev 检查分支状态）
   • 确认 worktree 隔离（如使用 multi-agent-orchestration）
2. 前端开发（调用 enterprise-crm-fullstack）:
   • 配置式列表页：SearchListPage / ele-list-page
   • 详情页：表单 + 内联编辑表格 + 附件上传
   • 国际化：$i18n() 替换
   • 权限：v-btn-permission 指令
   • 路由：hash 模式，按模块懒加载
3. 后端开发（调用 backend-change-flow）:
   • 七阶段变更流：读代码 → 析需求 → 影响分析 → 三对齐 → 编码 → 循环Review → 一致性确认
   • Controller / Service / Mapper / Entity 四层架构
   • 符合 Java 开发规范（K&R括号、4空格、120字符、Javadoc）
4. 代码质量:
   • 调用 stop-slop 去除代码中的AI生成痕迹
   • 调用 karpathy-skills 规避LLM编程常见陷阱
   • 调用 opinionated-engineer 确保工程化标准（类型安全、错误处理、无TODO）
5. 验证先于完成（借鉴 superpowers verification-before-completion）:
   • 宣称任何文件/接口/切片"完成"前，必须实际运行编译、lint 或测试命令并记录真实输出
   • 修复类任务必须先复现原始缺陷场景，再验证修复后场景，两轮证据都写入上下文
   • 禁止用"应该没问题""已自测"作为完成依据，无证据的完成声明不得计入产出清单
6. 输出开发产出清单:
   • 新增/修改的文件列表
   • 接口变更清单
   • 数据库变更脚本

并行模式（大需求时推荐）:

Orchestrator (你)
   ├── Agent-A: 前端开发 (worktree-A)
   └── Agent-B: 后端开发 (worktree-B)
        └── 每30分钟同步接口契约

阶段五：TST → 测试验证

核心目标: 不带着明显缺陷进入Review

动作:

1. 单元测试（调用 testing-patterns）:
   • Service层核心业务逻辑测试
   • 工具类/纯函数测试
   • 边界条件与异常分支覆盖
2. 集成/E2E测试（调用 webapp-testing）:
   • Playwright 侦察→行动：表单提交、列表查询、详情查看
   • 截图对比（UI回归）
3. 安全审计（调用 security-audit）:
   • SQL注入检查（参数化查询验证）
   • XSS检查（输入输出编码）
   • 越权访问检查（按钮权限、数据权限）
4. TDD回检（调用 test-driven-development）:
   • 红-绿-重构循环是否完成
   • 测试覆盖率是否达标（建议核心模块≥70%）
5. 输出测试报告:
   • 通过/失败用例统计
   • 发现的缺陷与修复建议
   • 安全扫描结果

阻断条件: 安全高危漏洞未修复 → 禁止推进到 REV

阶段六：REV → 质量审查

核心目标: 让Review成为质量提升而非形式主义

动作:

1. 提交前检查（调用 quality-gate）:
   • 五维检查：测试通过 / 安全无高危 / 规范符合 / 逻辑正确 / 性能可接受
   • 不通过则退回 DEV
2. PR生成（调用 create-pr）:
   • 分析 git diff，自动输出：
     • PR标题（Conventional Commits格式）
     • 摘要（What + Why）
     • 测试计划
     • 影响范围与回滚方案
     • 标签（feature/fix/refactor）
3. 两阶段代码审查（借鉴 superpowers two-phase review，两个阶段独立出具结论）:
   • 阶段一：规格符合性 — 对照 DES 阶段产出的 ERD / 接口契约 / ADR / 验收场景逐项核对实现；字段、动作、状态机、错误码、权限点是否兑现规范；验收场景（AC）逐条回放。critical 问题退回 DEV，不得用"代码质量好"为由绕过规格偏离
   • 阶段二：代码质量（调用 frontend-code-review）:
     • React/Vue组件检查（如适用）
     • 性能检查（不必要的渲染、大数据量处理）
     • 可维护性检查（圈复杂度、重复代码）
4. 置信度自检（调用 confidence-check）:
   • Agent 自我评估本次迭代的置信度（1-10）
   • 低置信度时标记风险点，建议人工复核
5. 输出审查报告:
   • PR链接/编号
   • 两阶段审查结论（规格符合性 / 代码质量，分别列出）
   • 发现的代码异味与建议
   • Agent置信度评分

阶段七：DEP → 部署交付

核心目标: 平稳合并，不影响主干

动作:

1. 提交规范（调用 git-commit）:
   • 检查提交信息是否符合 Conventional Commits
   • 多提交整理（rebase/squash建议）
2. 冲突预防（调用 solo-parallel-dev）:
   • 检查目标分支是否有新提交
   • 评估合并冲突风险
   • 提供冲突预演方案
3. 多Agent部署（调用 multi-agent-orchestration）:
   • 如需多服务同时发布，编排发布顺序
   • 数据库脚本先行 → 后端服务 → 前端页面
4. 输出部署记录:
   • 合并提交哈希
   • 发布版本号
   • 回滚指令

阶段八：MEM → 记忆沉淀

核心目标: 让经验成为资产，而非一次性消耗品

动作:

1. 项目记忆归档（调用 memory-hub）:
   • 归档本次迭代的 ADR 到 docs/adr/
   • 更新项目 INDEX（模块地图、关键决策、技术债务）
2. 经验模式提取（调用 hermes-experience）:
   • 提取可复用的代码片段（Snippet）
   • 记录踩坑记录与解决方案（Rule）
   • 总结本次迭代的最佳实践（Pattern）
3. 代码库上下文更新（调用 beads-memory / claude-mem）:
   • 压缩本次变更的核心上下文
   • 更新跨会话记忆文件
   • 确保下次迭代能继承本次上下文
4. 输出迭代总结:
   • 时间线（各阶段耗时）
   • 关键决策与理由
   • 技术债务清单（待重构点）
   • 经验卡片（3个以内，方便下次复用）

用户控制指令

在迭代过程中，用户可以随时发出以下指令控制流程：

上下文维护机制

Agent 在迭代过程中维护以下上下文，确保跨阶段信息不丢失：

Iteration Context
├── meta/
│   ├── name: 迭代名称
│   ├── start_time: 开始时间
│   ├── current_stage: 当前阶段
│   └── status: running/paused/aborted/completed
├── req/
│   ├── prd_path: 需求文件路径
│   ├── scope: 功能范围
│   └── acceptance_criteria: 验收场景[]
├── des/
│   ├── erd: 表结构设计
│   ├── api_contract: 接口契约
│   └── adr: 架构决策记录[]
├── dev/
│   ├── frontend_files: 前端文件[]
│   ├── backend_files: 后端文件[]
│   └── db_migration: 数据库脚本
├── tst/
│   ├── test_report: 测试报告
│   └── security_scan: 安全扫描结果
├── rev/
│   ├── pr_info: PR信息
│   └── review_comments: Review意见[]
├── dep/
│   ├── commit_hash: 提交哈希
│   └── release_version: 发布版本
└── mem/
    ├── snippets: 代码片段[]
    ├── rules: 经验规则[]
    └── patterns: 设计模式[]

与其他Skill的关系

enterprise-iteration-agent (总控)
    ├── 编排: dev-flow (方法论参考)
    ├── 编排: multi-agent-orchestration (并行执行框架)
    ├── 编排: skill-orchestrator (Skill匹配导航)
    │
    ├── REQ阶段: openspec-sdd, prd-to-demo, brainstorming
    ├── DES阶段: database-designer, api-doc-generator, frontend-design, taste-skill
    ├── DEV阶段: enterprise-crm-fullstack, backend-change-flow, opinionated-engineer
    ├── TST阶段: testing-patterns, webapp-testing, security-audit
    ├── REV阶段: quality-gate, create-pr, frontend-code-review, confidence-check
    ├── DEP阶段: git-commit, solo-parallel-dev
    └── MEM阶段: memory-hub, hermes-experience, beads-memory

使用示例

示例一：标准单线迭代

用户: 开始开发【客户标签管理】需求，PRD在 D:\需求\客户\标签管理.md

Agent:
  [INIT] 已初始化迭代看板。读取 PRD 后识别到：
        - 新建表：customer_tag, customer_tag_rel
        - 前端页面：标签列表、标签分配弹窗
        - 后端接口：CRUD + 批量绑定
        - 预计阶段：REQ → DES → DEV → TST → REV → DEP → MEM

用户: 下一步

Agent: [REQ→DES] 进入架构设计...
  → 调用 database-designer 输出 ERD
  → 调用 api-doc-generator 输出接口契约
  → 产出 ADR-001: 标签表设计决策

用户: 下一步

Agent: [DES→DEV] 进入编码开发...
  → 前端：调用 enterprise-crm-fullstack 生成配置式列表页
  → 后端：调用 backend-change-flow 生成 Controller/Service/Mapper
  → 产出：新增6个文件，修改2个文件

...（持续推进至 END）

示例二：前后端并行迭代（大需求）

用户: 处理【沉默客户运营】大需求，前后端并行

Agent:
  [DEV] 启动并行模式：
        - Agent-A (worktree-frontend): 开发 Vue 2 页面
        - Agent-B (worktree-backend): 开发 Java 接口
        - Orchestrator: 每30分钟同步接口契约

  [30分钟后同步]
        - Agent-A 已完成列表页框架，等待接口字段确认
        - Agent-B 已定义 DTO，确认字段与前端一致
        - 继续并行...

示例三：回退与修正

用户: 当前状态

Agent: [DEV] 编码开发阶段，已完成前端页面，后端Service层编写中。
        发现风险：需求中"批量导入"功能未在设计阶段明确接口格式。

用户: 回退到DES

Agent: [DEV→DES] 回退到架构设计阶段。
        → 补充 api-doc-generator：批量导入接口（MultipartFile + 模板下载）
        → 更新 ADR-002：导入处理策略（异步+进度回调）

用户: 下一步

Agent: [DES→DEV] 重新进入开发，已继承更新后的接口契约...

风险熔断机制

当检测到以下情况时，Agent 自动暂停并请求人工确认：

"迭代不是代码的堆砌，而是认知的闭环。每一个结束都是下一次开始的前置条件。"