用途：dev-team 用于以严谨流程实现一项变更——先构建、再独立验证、最后代码评审后才落地，而不是快速内联编辑。适合“用 dev→QA→review 循环实现此规格”“对这项任务启动 dev team”“用智能体构建并在提交前验证”等场景。不适合一行小改动、含多个子任务且各自需要 PR 的父工单（应使用 implement-full-spec），或需要同步结对编程的情况。
主要能力：启动一个小型智能体团队并运行有界循环。Dev 按逐字规格实现并保持改动未暂存；QA“什么都不信”，自己读代码、跑测试，逐条核对修复项，并用“心理回退”条款检查测试是否只是走过场；Reviewer 读取真实 diff 做代码评审并创建提交。失败时把具体反馈发回 Dev，最多 3 个循环，超限则升级。
必要用法：开始前需固定契约——工作区绝对路径与分支、逐字规格、每条修复项的 IN/OUT-of-scope 划分、期望通过的规范检查命令、提交终点。循环结束于分支上的一个提交，不推送、不开 PR，由调用方负责。若环境支持团队原语则建团队协调，否则退化为协调的子智能体序列。
限制与硬规则：提交不得使用 --no-verify，不得用 git add -A / git add .，默认不 amend，不得触碰操作者主检出，每个 Dev/QA/Reviewer 提示都要包含逐字规格与心理回退条款。团队须限定于一个工作单元并在提交后拆除。规格含糊、需要仓库外基础设施或超过循环上限时应停止并升级。
产出：分支上的一个提交（SHA 返回调用方），或附带 diff、失败输出与最后反馈的升级报告。推送、开 PR、更新工单由调用方负责。