任务与交接

任务（Task）是 MindMux 把已经达成共识的讨论转化为执行动作的方式。

任务的角色

MindMux 不想变成一个完整的项目管理系统。它的任务模型被刻意限制在更窄的职责范围内：

• 汇集正确的上下文
• 选择合适的执行路径
• 干净地派发工作
• 保留足够的状态，方便理解任务的来龙去脉

先讨论，再建任务

任务应该在工作已经清楚到可以交接之后再创建。它不是用来承载整场讨论的。

判断标准：这件事能不能由当前对话的 agent 直接完成？

• 能 → 不是任务，让 agent 在对话内通过 MCP 工具完成。
• 不能（需要独立 agent 长时间运行、worktree 或独立上下文）→ 才是任务。

创建流程

1. 在会话中把行动方向聚焦到一个明确的动作上。
2. agent 调用 create_task 生成任务草案。
3. 聊天中弹出 任务确认卡片，展示目标、项目大脑页面、执行渠道和隔离方式。
4. 用户确认后，任务立即派发，进入 dispatched 状态。

执行方式

当前所有任务都走 agent 模式：

• 启动一个独立的 sub-agent run。
• 与对话共享同一个 (runtime, profile) 绑定。
• 可选 worktree / tempdir 隔离，避免弄脏主工作区。
• 实时事件流回流到右侧任务面板。

隔离性

对于编码类工作，MindMux 默认采用隔离执行：

• worktree：独立的 git worktree，不影响当前分支。
• tempdir：临时目录，适合产出 out-of-tree 文件的任务。

具体隔离方式由 TaskType 决定，用户在确认卡片中可见。

任务之后怎么处理

MindMux 也刻意把任务后处理环节设计得更窄。任务完成后，你应该追问：

• 这次结果是否改变了项目事实？
• 是否应该更新某个页面或根文档？
• 是否产生了后续任务或修正动作？

小的后续修正可以通过对话中的 suggest_patch 引导式补丁解决，而不是把整段对话直接变成一个不受约束的编辑环境。

与 handoff skill 的关系

handoff skill 仍然保留，用于“手动把上下文贴给某个外部 agent”的场景。任务功能则是它的结构化升级版：

• 产出从“一段文本”升级为“结构化任务对象”
• 分发从“复制粘贴”升级为“一键路由 + 状态回流”

为什么这很重要

产品的价值不在于“有任务功能”。真正的价值在于，任务会继承正确的项目大脑和讨论上下文，让执行从更好的信息状态开始。