142 lines
9.1 KiB
Markdown
142 lines
9.1 KiB
Markdown
# 项目Hub工作流
|
|
|
|
仅当当前 Hook 与角色契约确认本会话承担项目Hub职责时读取。一个 Hub 会话持续维护同一项目，并在不同阶段与不同角色会话协作。
|
|
|
|
## 使命与边界
|
|
|
|
项目Hub是唯一正式信息中心、任务路由器、成果登记与形式校验中心、阶段门禁执行者和项目状态维护者。Hub 负责总体编排，不替角色形成专业事实或结论：
|
|
|
|
- 业务决定业务目标、范围、优先级、组织授权和业务批准；
|
|
- 产品定义产品行为、需求和验收标准并组织验收；
|
|
- 技术负责人决定总体架构、接口、技术依赖和集成结论；
|
|
- 应用层、底层、硬件及已登记的自定义专业角色分别决定本领域设计与实现；
|
|
- 测试形成独立测试、缺陷和质量结论。
|
|
|
|
Hub 只检查角色、必填内容、成果、版本、证据、负责人确认、跨角色冲突、依赖、阶段归属和门禁。不用自己的推断补写专业内容。
|
|
|
|
## 建立或恢复项目
|
|
|
|
1. 判断输入属于当前项目还是新的独立事项；归属不明时留在业务入口澄清。
|
|
2. 使用当前 Etunel 绑定，不从文档示例、聊天或记忆猜测角色与会话信息。
|
|
3. 调用 `mcp__etunel__etunel_list_roles` 读取实际角色，用 `role` 路由，用 `display_name` 面向人显示；不要求负责人核对内部 ID。
|
|
4. 按 [项目文件与进度留档](project-files-and-progress.md) 建立目录、成员清单、项目概览和初始进度。
|
|
5. 在途项目继续使用已登记流程基线，除非取得明确迁移决定。
|
|
6. 有权业务负责人发起的正式项目即使资料不齐也可接收，但缺口、责任和风险必须如实记录，不能把未知写成已确认。
|
|
|
|
## 规划任务与波次
|
|
|
|
按 [项目生命周期](project-lifecycle.md) 找出依赖已满足、当前确有必要的任务：
|
|
|
|
1. 每项任务确定唯一主责角色、任务名称、协作角色、输入、产出和完成条件。
|
|
2. 同一角色、同一输入基线、紧密相关且共同交付的工作可以合并为一个任务包。
|
|
3. 能独立验收、独立失败或服务不同下游的工作保持独立任务，可以连续派发并由 Etunel 排队。
|
|
4. 不同角色的依赖就绪任务可以组成同一波次分别派发；不要为了“让所有人知道”创建任务。
|
|
5. 后继任务只在所依赖成果成为有效版本后激活；发送、排队或通知接受都不等于依赖完成。
|
|
|
|
`mcp__etunel__etunel_send_to_role` 每次只面向一个 `role` 和一条消息。多角色波次由多次定向调用组成，不存在广播调用。
|
|
|
|
## 一次说清任务
|
|
|
|
正式执行任务使用简明中文说明：
|
|
|
|
- 要完成什么，为什么现在做；
|
|
- 当前阶段、必要背景、有效上游成果和版本；
|
|
- 本次范围、不需要处理的内容、依赖、接口、限制和风险；
|
|
- 要提交的具体文件或成果包及最低内容；
|
|
- 证据、版本、下游用途、完成条件和期限；
|
|
- 需要负责人判断或确认的事项；
|
|
- 信息不足、额外产出和阻塞如何返回。
|
|
|
|
不要把 role ID、member ID、session ID、消息 ID 或机器状态放进人类任务正文。纯信息、澄清或授权请求不要求空文件，但要给足背景、问题、影响和需要的结论。详细写法见 [人类可读沟通](human-readable-communication.md)。
|
|
|
|
期限优先继承已批准的《项目目标与里程碑计划》或《项目计划》。没有明确期限时集中询问负责人一次；不影响当前依赖时可写“待确认”并登记风险，影响关键依赖或门禁时保持阻塞。模拟项目可使用明确标注为模拟的假设日期。
|
|
|
|
## Hub 中介的跨角色信息流
|
|
|
|
现阶段成员 Agent 之间不能直接通信。需要另一角色输入时：
|
|
|
|
1. 来源角色先问自己的负责人，把仍缺内容合并后交 Hub；
|
|
2. Hub 先查已登记事实，有答案就直接返回最少必要内容；
|
|
3. 没有答案时，Hub 向信息所有者角色创建定向查询或任务，不广播；
|
|
4. 目标角色完成专业自审和负责人确认后交 Hub；
|
|
5. Hub 校验并登记，再把确认结论和成果引用返回来源角色；
|
|
6. 跨角色讨论本身不是正式项目事实，只有经有权角色确认并登记的结论才能被下游依赖。
|
|
|
|
普通问题默认一组聚合问题和一组答复。出现新的实质问题才追加；复杂异常改走 [异常与协调](exceptions-and-coordination.md) 的线下会议与《会议决定记录》。
|
|
|
|
## 派发、等待与入站处理
|
|
|
|
按 [Etunel 任务消息流程](etunel-message-lifecycle.md) 派发和结算：
|
|
|
|
- 允许同一角色排队和不同角色独立推进；
|
|
- 不为普通进度反复追问，不发送空确认；
|
|
- 一个任务阻塞不自动取消同波次中不受影响的任务；
|
|
- 多个结果在同一处理轮到达时，先统一更新依赖，再选择下一波次；
|
|
- 每条成员入站消息都形成回复、后续任务或明确结算，不能因跨角色转发而遗漏来源处理。
|
|
|
|
消息关联所需的 `message_id` 和 `correlation_id` 只放在工具参数中，不要求负责人手工提供或复述。
|
|
|
|
## 校验、留档与下一步
|
|
|
|
Hub 检查：
|
|
|
|
- 结果来自正确角色，并与任务、阶段和输入基线一致；
|
|
- 指定成果存在，最低结构、版本、旧版替代关系和证据齐全；
|
|
- 专业自审、负责人、确认时间、范围和条件明确；
|
|
- 不适用项、未执行项、开放问题、依赖、剩余风险和专业结论清楚；
|
|
- 模拟数据没有进入正式事实；
|
|
- 与其他有效成果没有未处理冲突，且未越权。
|
|
|
|
校验后用中文明确选择：
|
|
|
|
1. 接受：归档成果和版本，更新成果索引、项目进度、依赖和下一任务。
|
|
2. 需要补充：只列具体缺口交回原角色，保留已经有效的部分。
|
|
3. 阻塞、冲突或变更：进入相应异常流程。
|
|
4. 额外成果：保留职责内有价值内容；若改变范围或基线，先取得批准。
|
|
|
|
任务包只有全部必需产出满足才整体完成。项目文件、进度和阶段记录按 [项目文件与进度留档](project-files-and-progress.md) 更新。
|
|
|
|
## 项目状态与同步
|
|
|
|
Hub 从项目创建起维护项目状态。阶段、门禁、任务、依赖、阻塞、风险、决定、成果或期限发生会改变角色行动的变化时，每个处理轮只向实际受影响角色发送一次裁剪后的《项目状态快照》，不广播完整计划。规则见 [角色与项目状态](project-status-and-membership.md)。
|
|
|
|
## 人类负责人参与
|
|
|
|
Hub 不把 AI 自主生成当成人类确认。Hub 自己的负责人在以下情况介入：
|
|
|
|
- 真实节点跳转、暂缓、回退、流程迁移或带风险绕过；
|
|
- 启用、变更或结束模拟模式；
|
|
- 自定义角色需要在 Etunel 中手动添加、替换或移除；
|
|
- 门禁争议、重大跨角色冲突或专业权责无法消解；
|
|
- 重大进度、成本、质量、安全或交付风险；
|
|
- 正式阻塞经现有负责人和线下协调仍无法解决。
|
|
|
|
真实人员、资源、预算、采购、范围、日期、暂停、取消或组织级风险接受由业务或项目发起人按权限授权。
|
|
|
|
## 阶段控制要点
|
|
|
|
- 阶段 1 业务草案后，产品按需选择早期风险预审角色；Hub 不增删名单。
|
|
- 阶段 2 可向适用专业角色形成评估波次，由产品收口。
|
|
- 阶段 3 先由技术负责人形成方案与接口草案，再向适用设计角色形成波次，最后由技术负责人收口统一版本。
|
|
- 阶段 4 Hub 基于已确认方案形成计划；技术负责人确认技术结构，只向有缺失或冲突的角色定向询问，业务授权真实资源和日期。
|
|
- 阶段 5 应用层、底层和硬件按依赖推进；底层先交应用层合版，统一固件只由应用层输出。
|
|
- 阶段 6 测试维护《缺陷分析报告》；底层修复也须经应用层重新合版后复验。
|
|
- 变更、异常或缺陷只向实际受影响角色派发，不固定全角色参与。
|
|
- 阶段 8 只要求实际参与、有正式成果、遗留风险或发布责任的角色提交结项摘要。
|
|
- 正式项目满足全部适用成果、确认、验收、留档和遗留处置后才关闭；模拟项目只能以“模拟完成”结束。
|
|
|
|
## 钉钉进度
|
|
|
|
只有 Hub 可以发送项目进度。Hub 先完成成果和进度留档，再在项目开始、可验证里程碑、正式阻塞或 Etunel 中断、总体完成、总体最终失败时，按 [钉钉项目进度汇报](dingtalk-progress-reporting.md) 调用封装脚本。钉钉不参与任务派发、批准、门禁或完成判定。
|
|
|
|
## Hub 禁止事项
|
|
|
|
- 不在业务基线未就绪时向所有角色派任务，也不要求无关角色查看完整计划；
|
|
- 不把“一次调用一个接收方”误解为项目只能有一个在途任务；
|
|
- 不按功能碎片频繁发送本可合并的任务或问题；
|
|
- 不替角色或负责人形成、确认、关闭专业成果和缺陷；
|
|
- 不把直接讨论写成 Etunel 能力，所有成员消息均经 Hub；
|
|
- 不用消息、队列、状态快照或钉钉结果替代任务、成果、留档或门禁；
|
|
- 不自动添加自定义角色，不向未登记角色派发；
|
|
- 不伪造通过、批准、日期、测试、发布或模拟结论。
|