# Etunel 任务消息流程

准备派发、补充、跨角色中继、返回、完成、阻塞或结算 Hub 入站消息时读取。当前 Hook 和 MCP schema 是工具名、参数与授权的最终依据；本文只约束职责和消息意图。

## 真实工具边界

Etunel 是严格的 Hub 星型拓扑：成员只能向 Hub 发送，只有 Hub 可以向角色发送。

| 意图 | 调用者 | 工具 |
|---|---|---|
| 读取实际角色 | Hub | `mcp__etunel__etunel_list_roles` |
| 向一个角色发送任务、回复或状态 | Hub | `mcp__etunel__etunel_send_to_role` |
| 结算无需回复的成员协调消息 | Hub | `mcp__etunel__etunel_complete_coordination` |
| 成员向 Hub 补充或提问 | 成员 | `mcp__etunel__etunel_send_to_hub` |
| 成员完成任务并交付成果 | 成员 | `mcp__etunel__etunel_complete_task` |
| 成员以具体阻塞结束任务 | 成员 | `mcp__etunel__etunel_report_blocked` |
| 读取必要附件或旧式消息 | 当前绑定会话 | `mcp__etunel__etunel_receive_message` |

工具未暴露、名称或参数改变时，以当前 schema 为准并报告能力缺口；不得猜参数或请求内部认证字段。

## 机器字段不进入人类正文

- Hub 用 `role` 路由，面向人使用 `display_name`。
- `message_id` 是 Etunel 消息标识；需要完成、阻塞或结算时从入站消息取值。
- `correlation_id` 只用于把回复或状态关联到来源消息。
- 这些字段只进入工具参数。任务正文、负责人对话、成果标题和钉钉消息不要求抄写或确认。
- Etunel schema 没有 member ID；Skill 不得创造 member、session 或任务 ID 字段。

## 任务波次如何发送

`mcp__etunel__etunel_send_to_role` 一次调用只发送一个接收角色和一条消息：

- 同一角色的多个独立任务可以连续发送，由 Etunel 队列处理；
- 同一角色紧密相关且共同交付的内容可以合并为任务包；
- 不同角色的依赖就绪任务分别发送、独立返回；
- 排队不代表业务并行完成，也不代表下游依赖已经满足。

Hub 不实现队列、确认包、锁、重试、去重或文件传输；这些由 Etunel 软件承担。

## Hub 发送任务

Hub 调用 `mcp__etunel__etunel_send_to_role` 时：

- `role` 使用 `etunel_list_roles` 返回的实际值；
- `kind` 按当前 schema 使用任务、回复或状态意图；
- `text` 使用简洁中文说明目标、背景、有效输入、范围、产出文件、证据、期限、完成条件和负责人确认要求；
- `attachment_paths` 只附当前任务实际需要的文件；
- 回复同一来源角色时，按 schema 使用 `correlation_id`，不把该值写入正文。

纯信息、澄清或授权消息写清问题、已确认事实、影响和所需答复，不要求空文件。不要转发无关聊天、全量计划或无法消化的资料堆。

## 成员请求补充

成员先问当前负责人并完成必要线下沟通。仍需 Hub 时，用一条 `mcp__etunel__etunel_send_to_hub` 写清：

- 已经完成什么、现有成果在哪里；
- 还缺什么信息或决定，为什么需要；
- 已经询问和协调的结果；
- 缺失对范围、期限、风险和下游的影响；
- 建议向哪个角色获取；
- 当前还能继续什么，希望 Hub 返回什么。

Hub 已有登记答案时一次补足；没有时才创建必要的跨角色查询或任务。

## 经 Hub 的跨角色中继

跨角色交流必须是：来源成员 → Hub → 目标成员 → Hub → 来源成员。

- Hub 忠实保留问题、适用范围和来源，不替任一角色作专业改写；
- 目标角色返回前完成专业自审和负责人确认；
- Hub 校验并登记确认结论后，才向来源角色返回最少必要内容；
- 给另一个角色的新任务是独立消息，不能拿来源消息标识充当跨角色结算；
- 对同一来源角色的回复或状态按当前 schema 关联，其他情况由 Hub 明确结算来源协调项。

普通问题默认一次聚合请求和一次答复；复杂异常使用《会议决定记录》，不把多轮聊天当成项目事实。

## 成员完成或阻塞

调用 `mcp__etunel__etunel_complete_task` 前，成员确认指定成果、证据、版本、期限状态、专业自审、负责人确认和明确结论都已包含，并通过 `attachment_paths` 发送实际文件。

调用 `mcp__etunel__etunel_report_blocked` 时，用简明中文说明：

- 当前阻塞；
- 已完成成果和已尝试的排查、负责人沟通及线下协调；
- 缺失输入或决定及建议责任角色；
- 对本任务和下游的影响；
- 恢复条件和建议下一步。

成员只能结束自己的任务。Hub 不能代成员完成或阻塞；成员不能结算 Hub 的协调消息。

## Hub 处理成员入站

Hub 对每条入站消息选择：

- 需要回复同一来源角色：发送关联回复或状态；
- 无需回复且已经处理：调用 `mcp__etunel__etunel_complete_coordination`；
- 需要其他角色：先正确处理来源协调项，再按依赖创建必要任务；
- 同一轮到达多个相关结果：先更新成果、留档、状态和依赖，再选择下一波次。

消息结算、排队和送达不代表任务、成果、阶段或项目完成。

成果已经按 [成果与完成判定](artifacts-and-evidence.md) 被 Hub 接受并归档后，后续任务记录异常不撤销成果，也不要求成员重复制作或提交；Hub 单独记录并说明运行时异常。尚未实际收到或校验成果时，不能用消息状态继续推进。本文件不为此设计额外重试、去重或队列逻辑。

## 附件

直接使用当前消息正文和内嵌内容。仅当消息明确列出附件且为当前任务必要输入时，调用 `mcp__etunel__etunel_receive_message` 获取所需附件。Hub 收到成果文件后按 [项目文件与进度留档](project-files-and-progress.md) 归档；不要为探测队列或重复确认而读取。
