用途
Long Run Harness 用于编排复杂任务的多日执行。它把整体工作拆解为若干里程碑，每个里程碑都走一条固定流水线：plan-crafting → run-plan → review-work，并在里程碑之间设置检查点，以便在中断后恢复。
核心原则是：长时间执行必须可恢复、可审计、故障安全。每一次状态转换都要在下一个动作开始前持久化到磁盘。如果执行因任何原因停止——速率限制、崩溃、用户暂停、上下文丢失——都能从最后一个检查点恢复，而不重复已完成的工作。
主要能力
- 里程碑流水线：每个里程碑依次经过计划制定、执行（worker-validator 循环）、审查三个阶段。
- 硬性门禁：执行前必须已有里程碑；每个里程碑前后必须更新状态文件；每个里程碑必须走完整流水线，不得跳过审查；失败的里程碑会阻塞其依赖项；默认自主执行，里程碑之间不设审批门；已完成的里程碑不可修改；每个里程碑完成后写检查点。
- 状态持久化：所有状态写入磁盘，不依赖内存或对话记忆。
- 恢复协议：会话暂停或中断后，根据 state.md 中每个里程碑的最后状态决定恢复动作（pending 正常开始、planning 重启计划、executing 检查进度后恢复或重启、validating 重启审查、completed 跳过、failed 交由用户决定、skipped 跳过）。
- 并行里程碑执行：当多个里程碑依赖均已满足且无文件冲突时，可并行执行，各自在 worktree 中隔离运行，完成后合并。
- 跨里程碑集成检查：里程碑通过自身审查后、写检查点前，验证其输出与之前已完成里程碑的集成是否正确。
- 中途修正：若发现已完成里程碑的输出有误或需要新里程碑，暂停执行并交由用户决定（新增修正里程碑、从检查点重新规划、或中止）。
- 跳过规则：用户可跳过失败里程碑，但其依赖项默认仍被阻塞，除非用户明确解除阻塞。
- 时长守卫：对单个里程碑的活跃时间设软限制，对计划任务数设硬限制（单次计划超过 15 个任务时暂停并建议拆分）。
- 上下文窗口管理：设计上不依赖对话记忆，以应对长会话中的上下文压缩。
使用方式
输入为 Harness 状态目录路径，例如 docs/engineering-discipline/harness/<session-slug>/。该目录必须包含 state.md 和 milestones/*.md 文件。若不存在状态目录，则询问用户是否先运行 milestone-planning。
流程分为四个阶段：
- 加载并校验状态：读取 state.md 与所有里程碑文件，校验引用完整性、依赖 DAG 有效性、里程碑状态合法性，确定当前位置并向用户展示状态。
- 里程碑执行循环：按拓扑顺序对每个里程碑执行门禁检查、计划制定、执行、审查、跨里程碑集成检查、检查点写入。
- 并行里程碑执行：识别可并行组，先顺序完成所有并行里程碑的计划制定，再并发派发各自流水线，在 worktree 中隔离运行，通过审查后合并。
- 完成：所有里程碑完成后，运行最终端到端门禁与全量测试套件，生成完成摘要，并建议使用 simplify 做最终代码质量检查。
适用场景
- 已通过 milestone-planning 生成里程碑 DAG 之后。
- 用户说“long run”“start long run”“execute milestones”或“run all milestones”时。
- 恢复之前暂停的 long run 会话时。
限制
- 里程碑尚不存在时不适用（应先使用 milestone-planning）。
- 只有一个里程碑时不适用（应直接使用 plan-crafting + run-plan）。
- 不适用于不值得多阶段执行的快速任务。
- 已完成的里程碑不可修改；若后续里程碑需要改动先前工作，必须作为新里程碑处理。
- 跳过里程碑后不可取消跳过；若想稍后尝试，需创建同目标的新里程碑。
- 关于收费、价格、平台支持等具体信息，资料中暂未提供。