mo-convergence

诊断无法收敛的工作

只有当用户点名 mo-convergence 时才启动。仅仅提到工作进展缓慢、评审循环很长或尝试失败，都不会触发此技能，也没有其他技能会调用它。

完整阅读 Feature lifecycle 和 Обратная связь о методологии： 你遇到的阻碍应在回答中告知用户，此技能不会创建 Issue。

收集各方意见

通过生命周期已使用的界面，分别向负责工作的 Agent 以及所有仍处于活跃状态的评审者发送一条普通消息，询问他们：什么阻碍了收敛、他们自己对延误有何贡献，以及哪一项改动能解除阻碍。不要为了征求意见而开启新会话，也不要唤醒不活跃的槽位；参与者若已离开，应记录为不可用，而不是还原其意见。

这两个步骤都不需要判断。评审者槽位是否活跃，应针对每个槽位使用随附的 scripts/mo-review-resource.mjs hot 判断，其标志可通过 --help 查看。判断依据是自上次 worker_done 以来的时长，以及其屏幕所显示的上下文，具体见 Orca native mechanics，包括 --alive 的判定方式：只看该槽位自身记录的终端和屏幕，绝不能仅凭 Orca 的工作进程存活状态 unverifiable 作判断；未被判定为活跃的槽位就是不活跃的。只有经过验证的空白输入框才能向在线 Agent 发送内容：每条消息发送前，随附的 scripts/mo-harness-screen.mjs 都会读取该终端的当前屏幕，并且必须返回 action=inject。如果返回的是草稿、建议、信任对话框、Shell 提示符或任何其他内容，则不会发送任何消息；应记录该参与者不可用，并附上分类器给出的那一行。

然后，仅根据公开证据自行检查整个顺序：依次查看候选方案、每一轮的结论、attempt <n>/5 和 deep_reads <m>、被标记为已修复后又重新出现的问题，以及它们涉及的要求。以新形式反复出现的问题通常指向的是边界，而不是补丁。

提出建议

向用户给出一项建议，说明理由，并列出你排除的其他选项：

• continue — 剩余问题局部且正在减少；
• redesign — 同一边界反复出错，需要调整一个切片；
• narrow — 部分范围已有证据支持，可以先交付，其余部分暂缓；
• accept-limitation — 与继续进行更多轮相比，记录剩余风险成本更低；
• stop — 前提有误，或投入已不再值得。

当前范围内可逆的技术修正属于当前负责角色的职责，应将其交还该角色。更改产品边界、缩小范围、接受限制或停止，均由人来决定：你只提出建议，绝不替人做决定，也绝不自行更改规范、候选方案或评审结论。

此技能不会创建 Issue。在 Meta-O 文本中确认的阻碍应作为建议告知用户，是否提交由用户决定。

Meta-O 调用

• 无