dev-workflow

用途\n\ndev-workflow 用于执行或恢复 keel 开发任务，覆盖单项任务、批量任务和明确授权的无人值守运行三种场景。它的视角是资深开发者：务实优先、不过度设计、测试先行、提交原子化。任务拆分请使用 /dev-tasks，非 keel 开发使用 dev-flow，修 Bug 使用 /bugfix。支持中英文提问，统一中文回复。\n\n## 运行模式\n\n支持多种指定符：单任务（如 T-03）、范围（如 T-01~T-05）、枚举（如 T-01,T-03,T-07）、功能点（如 F-001，通过关联需求字段反查所有关联任务）、用户故事（如 US-001）。也支持轻量入口：直接描述任务与验收标准，即使没有 04 文档也可按 inline-entry.md 物化 stub 后转单任务路径。没有 M-XXX 里程碑指定符，里程碑不是执行单元。\n\n## 模式选择\n\n- 轻量模式：Bug fix、小改动、配置变更，走 /bugfix。\n- 标准模式：新功能、需求变更，走完整 Requirements→Design→Tests→Tasks→Dev。\n- 探索模式：原型、技术调研，可跳过文档强制与对抗式验证，但不得跳过 S6 绿验（skipped/todo=0）和至少 1 条目标行为证据，须写入任务台账 exploration_mode: true。无证据将阻止提交。\n\n## 工作流程\n\n标准流程为 S1 到 S11：S1 读取任务定义；S1.5 Sprint Contract 生成可执行验收契约；S2-S3 生成接口骨架与测试骨架；S4-S7 红绿重构；S8 完成检查；S9 前置验证与对抗审查；S10 自描述；S11 Commit 1。S12 文档同步属于 Commit 2 后置流程。步骤状态用于断点恢复。\n\n## 双 Agent 与信息屏障\n\n所有执行通过 Task tool 启动子 Agent。Test Agent 写骨架与测试，编排器做红色验证，Impl Agent 写实现与重构。存在严格的信息屏障：Test Agent 不得看到实现代码，Impl Agent 不得看到 03-test-*.md。测试不可变：Impl Agent 严禁修改测试代码，疑似缺陷须经用户确认后回退 Test Agent 修复。主 Agent 禁止直接执行 TDD。\n\n## 审查档位与质量地板\n\nreview_profile 分 fast、guarded、audit 三档，只决定独立对抗审查（Phase 1~3 与 Phase 4）的时机。质量地板五条在所有档位恒定 inline：绿验 skipped/todo=0、测试冻结、声称与实际 diff 一致、行为型 AC 至少 1 条独立证据、受影响测试后置。\n\n## 无人值守与自动提交\n\n无人值守和自动提交不是默认行为，须用户明说。无人值守要求工作区洁净、依赖不得处于进行中状态，且绝不推送远程。自动提交在测试通过且无 Blocker 时自动提交，出现 Blocker 或测试失败时暂停询问。\n\n## 提交规范\n\nCommit 1 为代码提交，Commit 2 为文档提交，二者分离且保持原子。提交信息中不写任何 keel 编号与流程状态，格式为 type(scope): 描述可观察结果，辅以 Why 与 Tests 字段。真正的流程状态（如 review_state、ext_review_state、commits）迁到 04-dev-tasks.md 的任务台账。\n\n## 适用场景与限制\n\n适用于采用 keel 工作流、已有任务文档或可物化 stub 的开发项目。前置条件为任务文档已定义并包含关联需求、验收标准、测试方法，或直接给出任务定义与验收标准。限制包括：测试通过判定排除 skipped/todo；失效任务卡会立即阻断；审计档位须审过才提交。