thread-orchestration

Thread Orchestration — 多 Thread 并行编排

核心理念：thread 承载工作现场，猫按本次任务承担角色。指挥、执行、验收不绑定猫名、家族或模型档位；责任归属与通讯路径分别明确。

组织三种现场、跨执行现场依赖或小团队排班时，先读 星系协作契约。这是本 skill 的角色与通讯约定；发送、授权核验、审查与处置仍走对应 skill，不新增球权账本。

何时触发

发现跨 scope 的问题/信息？
  → 先 list_threads keyword=<关键词> 查有没有已有 thread
  → 有已有 thread → 不要新建！用 cross_post_message 投递（cross-thread-sync skill）
  → 没有已有 thread + 需要独立追踪 → 本 skill：propose_thread

任务可以拆成多个独立子任务？
  → 有依赖？ → 独立部分并行；共享写入面单写，消费点等确切接口产物
  → 子任务独立？ → 本 skill：开 thread 并行推进
只有一个任务？ → 不需要本 skill，直接做

F128/F193 环（KD-E4）：propose_thread（新建）和 cross_post_message（投递）是一个环。 默认走投递（cross_post_message），只有确认没有已有 thread 时才走新建（propose_thread）。 新建 thread 的阈值高于投递——新建会增加operator的认知负担。

五步流程

Step 1: 拆解 — 识别独立可交付单元

判定标准：各自有可判断的交付物，且能划清写入面与消费依赖；能在不同 worktree 编辑不是充分条件。有共享接线时只串行该写入面，其余独立部分可并行。

拆解时明确每个子任务的：

• Scope: 改哪些文件/模块
• 交付物: 代码 + 测试 + 文档（具体到文件）
• 验收条件: 用户实得与证据；区分代码交付、已加载运行版本和真实旅程通过
• 角色与依赖: 当前执行责任猫、共享写入面、直接依赖方、可先做的部分、必须停下的消费点
• 完成边界: 整项委派何时结束、结果回哪里；分片 PR 合入不自动结束整项责任

Step 2: 提议 Thread — 每个子任务一个提议（用户审批后才创建）

重要：cat 不直接创建 thread。 调用 cat_cafe_propose_thread 创建一个提议卡片，等用户在 source thread 里点"批准"，后端才真正创建 thread。

→ cat_cafe_propose_thread(
    title: "简洁描述任务目标",
    reason: "为什么这个子任务值得自己一个 thread（必填）",
    preferredCats: ["<实际起跑猫 catId>"], // 多猫可能形成接龙；review 候选不当作必跑名单
    projectPath: "/abs/path/to/repo",  // 子 thread 的工作区/真相源归属；不是外部目标仓
    reportingMode: "final-only"  // 可选回报契约: none/final-only(默认)/state-transitions/blocking-ack，见下表
  )

返回值：{ proposalId, status: "pending" } —— 不是 threadId。Thread 还未存在，不要尝试 cross_post 到一个尚未批准的 proposal。

社区 PR / issue 分发： title / reason / initialMessage 中出现外部 PR/issue 时， 服务端不再自动注入 opensource-ops maintainer 五问、猜测作者角色或写入 PR metadata。 子 thread 的第一项工作是主动加载 opensource-ops skill，在 child workspace 内完成 provider object 与 author grounding，再执行 maintainer 五问与 custody 判断。本地猫替外部作者修代码需要 显式 Strategy B 授权 provenance，不能默认派给 preferredCats 里的猫。