Harness 驱动交付

交付过程为什么需要被约束

当一个项目缺少统一的推进框架时，常见的问题不是代码写不出来，而是没人能回答「现在做完了什么、还剩什么、怎么证明做完了」。典型失控包括：代码已写完 被当成完成标志，却没有验收证据；未提交的修改被意外覆盖；阻塞项被跳过或伪装成完成；README 描述的能力与代码实际行为脱节；临时补丁反复出现，却没有沉淀为规则或测试。这些摩擦不会让单次交付失败，却让每一次交付都重新踩一遍坑。

技能如何工作

Harness 驱动交付把项目推进视为可观测、可验证、可恢复的系统。它遵循几条硬性规则：优先复用项目已有结构与命令，只补缺失部分；一次只推进一个无阻塞工作项；不以「代码已写完」判定完成，必须逐条验收并记录证据；需求或架构变化先更新权威文档再继续实施；不默认执行提交、推送、部署等高风险操作。

推进闭环分九步：先发现事实，读取仓库中的 AGENTS.md、配置、测试与文档，识别已有改动；再建立权威顺序，按「已接受决策 > 批准的需求 > 架构文档 > 可执行计划 > README」排列事实来源；接着规范化计划，把任务映射为统一工作项，定义结果、范围、依赖与验收标准；然后用 node scripts/select-next-item.mjs 选择下一项可执行工作；实施前补齐最小 Harness，只补当前交付真正需要的能力——重复操作变成脚本，重复缺陷增加测试，危险动作增加审批；随后实施最小变更，只修改当前事项需要的文件；完成后按 quick → story → milestone 三层验证并收集证据；最后同步状态与文档，更新工作项、ADR、README 和文档索引。

技能提供多种模式适配不同场景：adopt 接管已有代码补齐轻量规则，plan 澄清需求并拆分工作项，advance 推进下一个可执行项，resume 从中断状态恢复，assess-harness 评估工具链可发现性与可恢复性，harden-harness 把重复摩擦升级为规则或脚本，audit 检查状态漂移，close 执行里程碑收尾。

适用边界

这个技能不是脚手架生成器。目标目录为空、尚未选择技术栈时，它不会初始化项目，应先使用 $bootstrap-project-harness 建立骨架后再回来推进工作项。它也不会静默扩大范围：发现范围外问题时记录为候选工作项，不顺手混入当前事项。遇到阻塞时如实报告事实、证据和解除条件，而不是把未完成的部分标记为通过。Harness 改进遵循渐进原则，只在问题重复出现或影响多个工作项时才升级为规则、脚本或测试，避免在交付前搭建过重的平台。