orchestrate-omp

在 OMP 上协调

在后台运行实质性工作时，继续为用户提供服务。根协调者负责计划、与用户互动、审批、范围、集成和最终验证。

1. 确定工作框架

1. 明确完成条件，以及最终产物或决策。
2. 仅将彼此独立的探索、专家审查或实现拆分出去，并明确责任归属。紧密耦合的工作应放在同一会话中完成。
3. 派发前明确划分主要责任，并指定共享约定。不要重复调查，也不要仅为避免可能的文件冲突而将有效的并行任务串行化。
4. 外部副作用和审批决策由根协调者负责。

2. 选择 Agent

使用实时 task 工具公开的准确名称；其清单是权威依据。当前 OMP 阵容如下：

工作	Agent	可选时的投入程度
范围狭窄、只读的代码库探索	scout	lo
常规、范围明确的实现	省略 agent，使用默认工作者	med
困难或含糊的实现	省略 agent，使用默认工作者	hi
机械式编辑或数据收集	sonic	lo
UI/UX 实现或审查	省略 agent，由任务说明提供设计专长	med 或 hi
代码质量评估	reviewer	med 或 hi
安全评估	security-reviewer	hi
外部库或 API 调研	librarian	lo 或 med

当实时任务架构公开 effort 时，应根据任务选择投入程度：范围狭窄的问题用 lo，常规工作用 med，存在歧义或影响重大时用 hi。否则应依赖所选 Agent 配置的模型角色，不要传递不可用字段。/skill:setup-pstack 可配置这些角色。

遵守实时清单中的只读和阻塞标记。绝不要显式传入默认工作者的名称。

3. 派发任务

1. 当实时架构公开 tasks[] 时，将彼此独立的参与者放入同一批次，让他们同时开始，并将共享的 context 按 Goal、Constraints 和 Contract 组织。否则，每次任务调用只启动一名参与者，且不要传入 context。
2. 为每个事项设置稳定的 CamelCase name，不超过 32 个字符；在适用时指定最具体的专家 agent；提供完整、独立的 task；并在 solutionSpace 中说明问题的开放程度，而非工作量。仅默认工作者可省略 agent。只有实时架构公开 effort 时才添加该字段。
3. 每项任务都按 Target、Change 和 Acceptance 组织。提供必要的仓库状态、决策、限制和依赖，因为子任务参与者看不到此前的对话记录。
4. 为每位写入者指定精确的可写范围。当实时架构公开 isolated 时，对需要独立工作区的并行写入者使用 isolated: true，之后检查返回的元数据，确认更改是已应用还是保留为产物。
5. 告知普通工作者：直接完成这项任务。不要调用 task 或创建子 Agent。 只有在任务明确指定某位工作者担任协调者时，才允许其继续委派；并牢记 task.maxRecursionDepth 默认值为 2，因此协调者的子任务参与者已是最后一层。
6. 告知工作者跳过项目范围的格式化、Lint 和测试套件。集成后由根协调者统一运行一次验证。

大量上下文应放在本地文件中，并通过 local://<path> 引用，而不要在多个任务中重复。

仅当协调者需要机器可读结果，且实时架构公开 outputSchema 时，才使用该字段。当无效输出必须导致失败而非仅返回警告时，设置 schemaMode: "strict"。

4. 协调

• 结果会自动交付。继续处理用户消息和独立的根任务，不要轮询。只有根任务确实受阻时才使用 wait。
• read proc:// 会列出正在运行的任务；read proc://<id> 会检查某项任务，但不会消费其交付结果。
• write agent://<id> 会发送有明确范围的修正、答复或下一阶段的协同任务，并唤醒暂停的会话。agent://all 会向所有人广播。在共享上下文中注明预期依赖，让同级消息有明确目的，而不是通过协商来发现依赖关系。
• write proc://<id>/kill 会取消过时或已被取代的任务。
• 从 agent://<id> 读取完整结果；如果报告不完整或可疑，则使用 history://<id>。
• 任务已完成表示子任务已成功交付，不代表其产物已被接受。

5. 交接

工作者的最终消息就是交接内容，也是唯一能将信息传递到树上层的内容。要求每位工作者使用相同格式：状态（PASS、ISSUES、BLOCKED）、分支或产物路径、完成的工作、备注和偏差、建议的后续工作。

• 保留工作者的原话。读取 agent://<id> 获取完整文本，不要把截断的预览改述到计划中。
• BLOCKED 表示一项任务陷入困境，不代表整棵树都受阻。通过后续消息重试、修复或澄清，并继续推进其他工作。
• 只有当继续工作会让所有分支都白费功夫时，才停止整棵树：例如基础损坏、约定错误或共享依赖故障。
• 子任务在没有报告的情况下终止，意味着存在缺口，而不是成功。明确记录并决定是否重新启动。
• 将备注部分视为信息最丰富的部分。每项偏差或顾虑都可能成为待办任务；对范围不明确的抱怨，说明任务简报过于单薄。

6. 集成

1. 收齐所有必需参与者的结果，或记录取消情况及缺口。
2. 检查每项声称完成的产物，并根据声明的所有权和约定解决冲突。
3. 在集成后的最新提交上，从根目录运行受影响的验证和真实用户流程。
4. 返回一条简洁的结果，列出 Agent 标识符、已接受的发现或更改、验证证据以及未解决的缺口。

只有当返回的元数据能够证明时，才声明模型或后端具有多样性。