xuanbingbingo/claude-standard-dev-team/standard-team

输入：项目源码目录（用户指定，或默认当前工作目录）
重点检查（除常规项外，必须额外扫描）：
 
  Step 0 - 先侦察项目的部署方式：
    - 是否配置了子路径部署？（next.config basePath / vite.config base / nginx location 前缀）
    - 前端框架是什么？（Next.js / Vue / React / 其他）
    - 是否有服务端跳转逻辑？（middleware / proxy / 路由守卫 / 后端 redirect）
    → 根据侦察结果决定检查哪些文件和模式，不要假设文件名
 
  Step 1 - 若有子路径部署，检查所有跳转 / 重定向：
    - grep 关键词：redirect、router.push、router.replace、navigate、
      location.href、window.location、Response.redirect、NextResponse.redirect
    - 对每一处：目标路径是否正确携带了部署前缀？
      （框架路由方法通常自动补前缀；直接构造 URL 字符串时最容易丢失）
 
  Step 2 - 检查 API 请求路径是否硬编码：
    - grep：fetch('/api、axios.get('/api、axios.post('/api 等
    - 应使用环境变量前缀（VITE_API_BASE / NEXT_PUBLIC_BASE_PATH / 项目自定义变量）
 
  Step 3 - 常规 Blocker 项（安全、契约、错误处理等）
 
产出：docs/REVIEW_REPORT.md

输入：项目源码目录
产出：docs/SECURITY_REPORT.md

输入：需求描述 + 项目源码
额外验证：
  - 未登录访问受保护路由时，重定向 URL 前缀是否完整
  - 子路径部署下所有页面是否可正常访问
产出：READY / NEEDS WORK 判决 + 报告

🔍 Audit 完成：{项目名}
 
🔴 必须修复（Blocker）：[n] 项
  - [具体问题 + 文件:行号]
 
🟡 建议修复：[n] 项
🔒 安全问题：[高危 n / 中危 n / 低危 n]
✅ 未发现问题的检查项：[列出]

流程：
  1. 主会话在 docs/CHANGELOG.md 记一行（ITER-编号 + 快速通道 + 一句话描述）
  2. 派对应实现 agent（frontend-developer / backend-architect）直接改
     - 样式改动仍必须使用 DESIGN_SYSTEM 中已有的 CSS 变量，不得硬编码
  3. 派 testing-evidence-collector 对改动文件做任务级验证（同 Phase 5/6 STEP 2），追加写入 docs/QA_REPORT.md
  4. 用下方"Iteration 汇报格式"简报，标注【快速通道】

mkdir -p docs/iterations/ITER-{NNN}-{简短描述}

输入：
  - 用户的变更需求 / bug 描述（原话 + 复现步骤 / 报错日志，如有）
  - 读取 docs/PRD.md、docs/TECH_SPEC.md、docs/API_CONTRACT.md、docs/DB_SCHEMA.md、
    docs/DESIGN_SYSTEM.md、docs/DYNAMIC_CONTENT_MAP.md（存在的都读）
  - 读取 project-tasks/ 任务清单
  - 用 Grep / Glob 扫描源码，定位所有代码触点（调用方、引用方、types.ts、迁移文件）
 
产出：docs/iterations/ITER-{NNN}-{描述}/CHANGE_IMPACT.md，必须包含：
  1. 变更概述：类型（新功能 / 优化 / bug 修复 / 重构）+ 用户原始诉求
  2. 基线：commit hash + 各契约文件当前版本号
  3. 契约变更清单：| 文件 | 接口/表/章节 | 新增/修改/删除 | 旧 → 新 | 是否破坏性 |
     （契约不变时明确写"契约不变"，并说明为什么不需要改）
  4. 受影响模块 / 代码触点：| 文件:行 | 受影响原因 |
  5. 重跑 Phase 计划：Phase 0–11 逐行列出 | Phase | 重跑 / 跳过 | 范围（具体任务编号）| 理由 |
     （按下方 I-3 映射表判定；跳过的 Phase 也必须写理由）
  6. 风险与回滚：数据迁移风险、对存量数据 / 老客户端的兼容性、回滚方式
  7. 破坏性变更判定：是 / 否 + 依据
  8. 回归范围：本次改动点清单 + 必须回归的原有关键路径（PRD 中 P0 功能编号 + 对应接口）
 
完成标志：CHANGE_IMPACT.md 存在，8 个章节齐全，重跑计划覆盖 Phase 0–11 每一行

按 CHANGE_IMPACT.md 的契约变更清单，分派：
  - PRD 功能 / 验收标准有变化（新增 F 编号、修改验收标准）→ 调用 product-manager 增量修改 docs/PRD.md
      新功能沿用原编号体系往后排（F09、F10…），不得复用或改动已有编号
  - TECH_SPEC / API_CONTRACT / DB_SCHEMA / DYNAMIC_CONTENT_MAP 有变化 → 调用 software-architect（契约变更模式）
  - DESIGN_SYSTEM 需要新增 / 修改 token → 调用 ui-designer 增量修改 docs/DESIGN_SYSTEM.md + variables.css
 
版本号规则（每个被改动的契约文件）：
  - 非破坏性变更：次版本 +1（v1.2 → v1.3）
  - 破坏性变更：主版本 +1（v1.3 → v2.0），并在变更记录里写明迁移 / 兼容方案
  - 文件末尾"变更记录"追加一条，触发原因写 ITER-{NNN}（格式同 software-architect "被打回时的变更记录格式"）
 
要求：
  - 只改 CHANGE_IMPACT 列出的部分，不顺手重写无关章节
  - 改了 API_CONTRACT 字段名 / 类型 / envelope 时，照常执行"契约变更必扫前端 types.ts"硬规则
  - 契约变更中发现评估遗漏 → 回写 CHANGE_IMPACT.md 补全，再继续
 
完成标志：契约文件版本号已更新，变更记录已追加，与 CHANGE_IMPACT.md 一致

Phase 3 增量拆任务（主会话亲自执行）：
  - 新增任务：追加到原 backend-tasklist.md / frontend-tasklist.md 末尾，编号接着排，标注（ITER-{NNN}）
      ### [ ] TASK-B13：实现 GET /api/v1/orders/export（ITER-003）
  - 需要修改的已完成任务：把 [x] 改回 [ ]，并在任务下补一行"ITER-{NNN} 重开：原因"
  - 已完成且不受影响的任务保持 [x] 不动
  → 之后 Phase 5 / 6 的 Loop 照常只处理 [ ] 任务，天然只跑受影响部分
 
Phase 4 增量迁移（database-optimizer）：
  - 只新增迁移文件，禁止修改或删除已执行过的迁移文件
  - 新迁移必须有 down，涉及存量数据的要写数据迁移脚本并在 BACKEND_STATUS.md 说明
 
未受影响的 Phase：跳过，在 CHANGE_IMPACT.md 重跑计划里已写明理由；主会话最终汇报时列出。

输入：
  - docs/iterations/ITER-{NNN}-{描述}/CHANGE_IMPACT.md（回归范围）
  - 本次 git diff（基线 commit..HEAD 或工作区）
  - 更新后的契约文件 + 变更记录
 
验证内容（全部要可复核证据，不依赖浏览器 / 截图）：
  A. 改动点验证：契约变更清单逐条核对实现（路径 / 字段 / 类型 / 错误码 / 迁移）
  B. 原有关键路径回归：CHANGE_IMPACT 列出的 P0 功能接口逐个做契约测试，
     完整跑一遍类型检查 + 已有单元测试 / 接口测试，确认无新增失败
  C. 残留扫描：被删除 / 重命名的旧字段名、旧接口路径在前后端代码中 grep 结果为 0
  D. 契约一致性：未改动的接口抽查实现仍与契约一致；契约版本号与变更记录已更新
  E. bug 修复类：先给出修复前的复现证据（或日志 / 失败用例），再给出修复后的通过证据
 
产出：
  - PASS 或 FAIL + 可复核证据（返回主会话）
  - 追加写入 docs/QA_REPORT.md，章节标题"## ITER-{NNN} 回归验证"
 
决策：
  PASS → 进入 I-5
  FAIL（重试 < 3）→ 按问题归属打回对应 agent（实现问题 → 实现 agent；契约 / 评估遗漏 → software-architect）
  FAIL（重试 >= 3）→ 暂停，向用户报告卡点

输入：CHANGE_IMPACT.md + 契约变更记录 + 本次 git diff + QA_REPORT 的 ITER 章节
产出：
  - docs/CHANGELOG.md 追加一条（ITER 编号、日期、变更摘要、契约版本变化、是否破坏性、升级 / 迁移注意事项）
  - README.md 增量更新：仅当功能列表、环境变量、部署步骤、迁移说明有变化时改对应章节，不整篇重写
  - docs/API_DOC.md：API_CONTRACT 有变化时同步更新对应接口

🔁 迭代完成：ITER-{NNN} {简短描述}【完整流程 / 快速通道】
 
📝 变更类型：新功能 / 优化 / bug 修复
📜 契约变更：PRD v1.2→v1.3 / API_CONTRACT v1.4→v1.5 / DB_SCHEMA 不变
💥 破坏性变更：否（或：是，已于 I-1 后经用户确认，迁移方案见 CHANGELOG）
🔄 重跑 Phase：3、5（TASK-B13、B07 重开）、6（TASK-F09）、7、8
⏭️  跳过 Phase：4（DB 不变）、9（部署配置不变）、10（非破坏性且无新功能）
🧪 回归：改动点 [n] 项 + 原有关键路径 [n] 条，testing-evidence-collector PASS
📁 文档：CHANGELOG.md 已追加，README / API_DOC [已更新 / 无需更新]
 
⚠️  遗留项：[若有]

mkdir -p docs project-tasks

docs/
  PRD.md
  TECH_SPEC.md
  API_CONTRACT.md      ← 核心契约，前后端共同遵守
  DB_SCHEMA.md
  DESIGN_SYSTEM.md     ← UI 设计规范，frontend-developer 必须遵守
  DYNAMIC_CONTENT_MAP.md
  BACKEND_STATUS.md
  SECURITY_REPORT.md       ← Phase 7 安全审查报告
  REVIEW_REPORT.md         ← Phase 8 代码评审报告
  QA_REPORT.md             ← Phase 5/6 任务级 Dev-QA Loop 累计记录
  ACCEPTANCE_REPORT.md     ← Phase 10 最终验收报告
project-tasks/
  backend-tasklist.md
  frontend-tasklist.md

输入：用户原始需求
产出：docs/PRD.md
 
要求：
- 功能编号 F01/F02...（后续 agent 引用）
- 用户故事 Who/What/Why 格式
- 明确 MVP 范围（✅本期 / ❌不做）
- 非功能性需求（性能、安全、兼容性）
 
完成标志：docs/PRD.md 存在

输入：读取 docs/PRD.md
产出：
  - docs/TECH_SPEC.md      技术栈、目录结构、环境变量、编码规范
  - docs/API_CONTRACT.md   ← 所有接口的完整定义（路径/方法/字段/错误码）
  - docs/DB_SCHEMA.md      所有表结构、字段类型、索引、外键关系
 
关键要求：
- API_CONTRACT 中每个接口必须包含：
    完整 Request body（字段名+类型+是否必填）
    完整 Response 200（字段名+类型+结构）
    所有错误码（HTTP状态码+error字段+触发条件）
- DB_SCHEMA 中每个字段必须标注类型、约束、索引原因
- 不得出现"等字段"、"其他参数"等模糊表述
- TECH_SPEC.md 必须包含"部署路径规范"章节，明确：
    APP_PATH（URL 前缀），VITE_API_BASE 的生产值和本地值
    前端 API 调用层规范（禁止硬编码 /api/...）
    .env / .env.production 的配置模板
 
完成标志：三个文件存在且无模糊表述，且 TECH_SPEC 包含部署路径规范

输入：
  - 读取 docs/PRD.md（了解产品定位和目标用户）
  - 读取 docs/TECH_SPEC.md（获取前端技术栈和适配方案）
 
产出:
  - docs/DESIGN_SYSTEM.md     颜色/字体/间距/圆角/阴影/组件规范
  - src/styles/variables.css  可直接引入的 CSS 变量文件
 
要求：
  - 颜色体系：品牌色 + 功能色 + 中性色，变量命名统一
  - 字体体系：基于实际适配方案（vw/rem）的字号梯度，最小不低于 16px
  - 间距体系：基于 4px 基础单位，覆盖页面边距/卡片内距/列表项高度
  - 组件规范：针对 PRD 中的核心组件（如：待办卡片/表单/按钮/空状态）
  - 移动端必须包含：安全区适配、可点击区域最小 44px、暗色模式变量
 
完成标志：docs/DESIGN_SYSTEM.md 和 src/styles/variables.css 均存在

# 后端任务清单
> 基于 API_CONTRACT v1.0，每任务对应一个接口