mission-orchestrator

任务编排器

概述

将整个 attune 开发生命周期（头脑风暴 → 规格说明 → 规划 → 执行）封装为单个任务，并自动检测状态、选择类型和路由阶段。遵循 spec-kit:speckit-orchestrator 中的“持续存在透镜”模式：完全通过 Skill() 调用委派给现有技能，绝不重新实现阶段逻辑。

适用场景

• 从零开始启动新项目（完整生命周期）
• 恢复中断的项目工作流
• 根据现有规格说明开展有针对性的战术实现
• 根据现有实施计划快速修复

不适用场景

• 直接运行单个阶段（使用 /attune:brainstorm、/attune:specify 等）
• 非项目工作（代码审查、调试、研究）
• 需要精细控制阶段转换时

任务生命周期

1. State Detection
   Scan for existing artifacts (project-brief.md, specification.md, etc.)
       |
2. Mission Type Selection
   Auto-detect type based on artifacts, or accept user override
       |
3. Phase Routing Loop
   For each phase in the mission type:
       a. Pre-phase validation (check prerequisites)
       b. Invoke Skill(attune:{phase-skill})
       c. Post-phase artifact check (verify output exists)
       d. Post-phase backlog triage (create GitHub issues
          for out-of-scope items after brainstorm/specify)
       e. Update mission state
       f. User checkpoint (skippable with --auto)
       g. Error handling via leyline:damage-control
       |
4. Completion
   All phases complete, final state saved

任务类型

类型	阶段	自动检测条件
full	头脑风暴 → 规格说明 → 规划 → 执行	不存在任何产物
standard	规格说明 → 规划 → 执行	存在 docs/project-brief.md
tactical	规划 → 执行	存在 docs/specification.md
quickfix	执行	存在 docs/implementation-plan.md
review	界定范围 → 调查 → 验证 → 报告	请求中提到要审计、试用或审查现有软件

review 是唯一根据请求意图而非产物来选择的类型，因为构建产物树看起来都一样，无论用户要求的是“交付这个”还是“审计这个”。它会首先运行检查。该类型会生成 reports/<topic>-<YYYY-MM-DD>.md，且绝不会进入战情室关卡；该关卡用于保护规划到执行的转换，而审查任务中没有这种转换。

完整的类型定义和自定义类型支持，请参阅 modules/mission-types.md。

阶段与技能的对应关系

阶段	调用的技能	生成的产物
brainstorm	Skill(attune:project-brainstorming)	docs/project-brief.md
specify	Skill(attune:project-specification)	docs/specification.md
plan	Skill(attune:project-planning)	docs/implementation-plan.md
execute	Skill(attune:project-execution)	已实现的代码和测试

审查任务会路由到现有审查技能，而非 attune 阶段技能：

阶段	调用的技能	生成的产物
scope	Skill(pensive:tiered-audit)	层级选择和限定范围
investigate	Skill(imbue:feature-review) 加上 pensive:* 领域透镜	原始发现
verify	Skill(imbue:proof-of-work)	每项发现对应的证据引用
report	Skill(imbue:structured-output)	reports/<topic>-<YYYY-MM-DD>.md

编排器绝不重新实现阶段逻辑。每个阶段都是一次完整的 Skill() 调用，由其处理自身的工作流。

任务期间的委派

任务默认会委派执行工作。 Skill(conjure:delegation-core) 负责此决策，其默认策略为开启：进入执行工作的阶段会将工作交给外部 CLI，无需等待用户要求。

阶段	是否委派	原因
brainstorm	否	推理；遵循 Keep Local 条款
specify	否	推理
plan	否	推理
execute	是，按任务委派	任务执行属于可委派部分
scope、investigate、verify、report	仅报告和验证	调查结果需要判断；批量提取则不需要

这种划分遵循 conjure 自己的原则：委派执行，保留推理。 完全属于判断工作的任务阶段会留在本地，且不会调用委派器。

以下两种情况需要处理，而不是仅作报告：

• fallback_reason 为 providers_exhausted：没有 CLI 响应。说明尝试过哪些 CLI，然后将任务交给使用当前会话模型的子 Agent。 Skill(attune:project-execution) 的 subagent-fallback.md 模块中包含相关规则：每个阶段使用哪个 Agent、如何保持模型和分支不变，以及何时允许内联处理。在未安装 CLI 的机器上，这是常规路径，不会导致阶段失败。 如果未安装 conjure，且无法加载其技能，也采用相同路径。
• fallback_reason 为 delegation_disabled：操作者选择不委派。 在本地完成任务，因为子 Agent 仍然属于委派；不要提议重新启用委派。

若要在不使用外部模型的情况下运行整个任务，请在调用前设置 CONJURE_DELEGATION=off。

会话恢复

任务会将状态持久化到 .attune/mission-state.json。恢复时：

1. 加载任务状态文件
2. 验证所引用的制品仍存在于磁盘上
3. 确定最后完成的阶段
4. 按顺序从下一阶段继续

有关状态架构和恢复协议，请参阅 modules/mission-state.md。

交互式计划审查

从计划阶段过渡到执行阶段时，会采用交互式审查循环，而不是简单的检查点。计划按章节逐一审查，根据反馈进行修订，并且必须通过强制性的战情室关卡才能执行。

主要功能：

• 按章节进行终端审查（先审查架构，再审查各阶段）
• 提供批准、修订或驳回的判定，并说明理由
• 跟踪计划版本并提供差异摘要
• 根据结构化反馈改进上下文
• 在用户审查前扫描增量偏差
• 最多进行 3 轮修订，之后强制作出决定
• 必须获得 Prosecution Counsel 的战情室批准

完整协议请参阅 modules/plan-review.md。

审查模块

• plan-review.md：审查循环的主协调器
• plan-versioner.md：版本跟踪和差异生成
• feedback-collector.md：判定捕获和 JSON 输出
• context-injector.md：修订提示词构建
• iteration-governor.md：轮次跟踪和升级

用户指令覆盖

协调器会在任务开始时解析用户命令参数和自由文本，识别自然语言中的信任信号。例如“忽略范围保护”、“深入思考”、“别再一直问”和“自主处理”等短语，会被识别为指令覆盖，从而调整约束配置，无需显式设置 --constraints= 标志。

指令覆盖优先于任务类型默认设置，但绝不会绕过安全底线（提交前钩子、工作证明、破坏性操作确认、对外操作）。检测到指令后，协调器会在任务开始时确认一次，并停止询问对应检查点。指令覆盖后仍反复请求批准，本身就是工作流错误。

有关解析表，请参阅 modules/adaptive-constraints.md 的“用户指令覆盖”部分。

使命章程

使用 references/mission-charter.md 中的结构化模板来定义使命边界。使命章程明确规定：

• 预期成果：成功是什么样的
• 成功指标：可衡量的完成标准
• 截止时间：时间边界（会话、日期或时长）
• 约束：令牌／时间预算、禁止的操作
• 范围：范围内和范围外的领域
• 停止标准：使命停止的条件

完整模板和示例请参阅 references/mission-charter.md。

进度报告

使用 references/progress-report.md 中的结构化检查点来跟踪进度。在以下情况下生成报告：

• 阶段边界（在头脑风暴→明确规范→计划→执行之间）
• 识别出阻碍因素
• 风险升级
• 达到预算阈值（50%、75%、90%）

模板和检查点节奏指南请参阅 references/progress-report.md。

模块参考

核心模块（始终加载）

• mission-types.md：类型定义、自动检测逻辑、自定义类型
• state-detection.md：产物存在性检查、质量验证、过时状态
• phase-routing.md：阶段执行协议、转换钩子、错误处理
• mission-state.md：状态架构、持久化、恢复协议

计划审查模块（运行计划阶段时加载）

• plan-review.md：按部分交互式审查，并扫描偏见
• plan-versioner.md：版本跟踪和差异摘要
• feedback-collector.md：评审结论记录和反馈文件
• context-injector.md：根据反馈构建修订提示词
• iteration-governor.md：轮次跟踪、上限执行、升级处理

条件模块（仅在触发时加载）

• reflexion-buffer.md：跨会话学习缓冲区；迭代次数 > 1 或修订轮次失败后加载。
• trust-tier.md：约束配置分类器；在使命开始时检测到用户指令覆盖时加载。
• adaptive-constraints.md：约束调整规则；指令覆盖生效时与 trust-tier.md 一同加载。

按使命类型加载模块

此技能声明 progressive_loading: true。为尽可能降低编排器的常驻令牌开销，只加载各使命类型实际需要的模块子集。使命开始时，编排器本身只加载四个核心模块；其余模块会在相应阶段运行时按需加载。

使命类型	核心	计划审查	反思	信任与自适应
quickfix（仅执行）	是	--	--	如果有指令
tactical（计划 -> 执行）	是	是	如果正在修订	如果有指令
standard（明确规范 -> 计划 -> 执行）	是	是	如果正在修订	如果有指令
full（头脑风暴 -> 明确规范 -> 计划 -> 执行）	是	是	是	如果有指令
review（确定范围 -> 调查 -> 验证 -> 报告）	是	--	如果正在修订	如果有指令

令牌开销（根据 hub 和已加载模块的 wc -w 结果计算，再按每个词约 1.3 个令牌换算）：

使命类型	已加载模块	约计令牌数
quickfix	hub 和核心模块（4）	~4,100
tactical	hub、核心模块和计划审查（9）	~6,900
standard	与 tactical 相同（9）	~6,900
full	hub、核心模块、计划审查和反思（10）	~7,900

此前的全部加载模式会为每个使命加载约 10,100 个令牌，包括只需要执行阶段的 quickfix 运行。采用按类型加载后，quickfix 的开销减少约 60%，standard／tactical／full 路径则减少 22-32%。

触发指令覆盖时，trust-tier 与 adaptive-constraints 这一对模块会在使命类型的基准开销上增加约 2,200 个令牌。

参考模块

• mission-charter.md：结构化的使命定义 模板（仅在定义使命章程时加载）
• progress-report.md：检查点状态报告模板 （仅在生成进度报告时加载）

相关技能

• Skill(attune:project-brainstorming) - 头脑风暴阶段
• Skill(attune:project-specification) - 规格定义阶段
• Skill(attune:project-planning) - 规划阶段
• Skill(attune:project-execution) - 执行阶段
• Skill(attune:war-room-checkpoint) - 对 RED/CRITICAL 任务进行风险评估
• Skill(leyline:risk-classification) - 任务风险分类
• Skill(leyline:damage-control) - 阶段执行期间的错误恢复
• Skill(conjure:delegation-core) - 默认启用的执行工作委派

相关命令

• /attune:mission - 调用此技能
• /attune:mission --resume - 从保存的状态恢复
• /attune:mission --type tactical - 覆盖使命类型

退出条件

• 使命类型中的所有阶段均已成功完成
• 每个已完成阶段都有对应产物
• 使命状态已保存到 .attune/mission-state.json
• 已生成风险摘要（统计所有任务的风险等级数量）
• 执行阶段的工作要么已委派，要么依据明确命名的 Keep Local 条款暂缓处理，绝不能因未决定是否委派而跳过
• 任何 providers_exhausted 结果均由 session-model 子 Agent 完成；若运行环境没有子 Agent 工具，则在当前流程中完成，并报告尝试过的提供方
• 没有尚未解决的错误或阻碍