Execution Coordination

此能力是 KS 的执行协调层，不替代当前 runtime 的子代理机制，也不替代 AFK/KFC 的阶段、门禁或 worker 编排。它只在用户明确提出协同且任务复杂时使用；默认仍是单会话执行。

适用判断

在建议或启动协同前，确认用户有明确协同意图，且至少存在一项复杂性：可独立并行的工作车道、必须隔离的独立验证、跨会话恢复需求，或单会话不能安全维持唯一主线与证据。

不满足时，说明保持单会话的判断，直接按原任务推进。不得因为出现 KS 入口、受管项目、多个文件或当前 runtime 支持子代理就自动拆分任务。不得自动读取长协作文档、扫描 ks-context/ 或创建聊天室。

KS CLI Runtime Contract

执行协调的状态查询和变更只通过已发布的 ks coordination ... 与 ks chat-room ... 命令进行。任何此类操作前，必须遵守KS CLI Runtime Contract：先检查 ks --version 与当前 plugin 所需版本，仅使用随包 tarball 修复 runtime，复检失败即停止。

不得直接读写或猜测 $KS_HOME、~/.ks、协调注册表、状态文件或计划文件。所有 KS 用户级状态只能由已发布的 ks CLI 接口查询或变更。

协同流程

1. 固定唯一主线：记录工作目标、冻结基线、Definition of Done、文件所有权和验证矩阵；不以子会话自行产生的计划替代主线。
2. 为每个确有必要的执行单元给出最小上下文、唯一职责、允许写入范围、禁止动作、停止条件、返回契约和证据要求。修复者与独立 verifier 必须职责隔离。
3. 使用当前 runtime 的自然语言子代理启动能力派发。只有取得派发句柄、可查询状态和职责范围内首个真实产出，才可记为“已启动”；缺少任一项都记录为未派发或失败。
4. 发生执行性动作后，按仪表盘格式输出状态投影；Execution State 是唯一状态真源，仪表盘不替代可审计状态和证据。
5. 恢复时优先复用原执行单元；职责、上下文或独立性不再成立时，建立可审计的替代关系，不改写历史。

原生子代理启动失败

启动失败时，记录该次原始错误和已尝试的修正。根据错误进行最小自检与策略修正后重试，整个启动过程最多三次。三次之后，只有仍缺少可审计成功证据时，才询问用户是否愿意手动创建子会话并使用聊天室协作。

人工子会话必须由用户创建；获得 runtime 权威回读及其首个职责范围内产出前，只能标为“待确认”，不得称为已派发或已启动。向用户只说明协同结果、阻塞和可选下一步，不暴露 runtime 底层参数、内部句柄或重试配置。

协作现场边界

遵守协作使用边界。聊天室是按需、可审计的人类协作投影，不是默认前置条件；不得自动创建，且不得侵入项目本体。协同不改变文件所有权，不得借此扩展用户授权或绕过项目既有的测试、审查、发布与人工确认门禁。

面向用户的表达

用自然语言说明是否建议协同、协同的必要性、可见进度、阻塞和下一步。不得将内部 skill 名、runtime 参数、派发句柄、状态存储路径或原始长日志作为常规用户可见内容；用户明确要求诊断时，仅提供完成诊断所需的最小证据。