first commit

etunel-role-collaboration/SKILL.md

@@ -0,0 +1,76 @@
+---
+name: etunel-role-collaboration
+description: 在 Etunel 多 Agent 项目中识别项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或已登记的自定义角色，并按 Hub 唯一跨角色中介、依赖就绪任务波次、正式成果、人类负责人确认、成员与状态基线和 Etunel 消息流程推进项目。用于进入 Etunel 项目任务、确认职责边界、派发或完成任务、处理阻塞返工变更、阶段交接以及 Hub 钉钉进度汇报；不用于设计 Etunel 队列、投递、重试或去重机制。
+---
+
+# Etunel 多角色项目协作
+
+一个 WORK_ID 使用一个持续的项目Hub会话贯穿生命周期。默认角色为项目Hub、业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试；已完成契约并由 Hub 真人负责人在 Etunel 中手动添加的自定义角色也可参与。
+
+## 先确认身份与任务
+
+从当前 Hook、Etunel 角色契约和入站任务确认：
+
+- semantic role、实际 role ID、role member ID、session ID 和 human owner；
+- WORK_ID、SUBTASK_ID、项目模式、流程基线、阶段、任务波次和本任务范围；
+- 唯一主责角色与主责成员、协作角色、上游依赖和要求完成时间；
+- 要求产出的文件或连贯成果包、最低内容、证据、完成条件和下游用途。
+
+不要根据文件夹名、历史消息或记忆猜身份。成员、会话、职责或任务归属不清时，先报告边界问题，不自行换角色。
+
+## 共享硬约束
+
+1. 项目Hub是成员 Agent 之间唯一的跨角色中介。现阶段 Etunel 不支持成员间直接通信；成员只交 Hub，Hub 再定向路由，且不替角色改写或作出专业结论。
+2. 正常阶段顺序为：业务需求、产品定义、方案设计、项目规划、软硬件实现、测试验证、业务验收、发布结项。阶段按有效流程基线和依赖推进。
+3. 同一阶段中，依赖已满足的任务可组成任务波次；一个工具调用只有一个接收方，同一角色的多项工作可以内聚成任务包或连续派发多个 SUBTASK_ID。
+4. 每个 SUBTASK_ID 只有一个主责角色、一个主责成员和一个可独立判定的结果。协作角色不等于共同主责。
+5. Hub 给足当前任务需要的已登记信息，但不默认广播完整计划、全部资料或私有对话。缺口应聚合后经 Hub 定向补齐。
+6. 正式执行任务必须要求具体产出文件或连贯成果包，且派发要求与预期产出一致。纯信息查询、确认或决定请求不虚构文件。
+7. 角色 AI 收到任务后先与本角色 human owner 对齐，形成成果后完成专业自审并取得负责人确认，才可正式返回。
+8. Hub 只校验身份、结构、版本、证据、确认状态、跨角色冲突、依赖和门禁，不替专业角色判断内容是否充分。
+9. 项目模式、任务结果、成果生命周期、成果适用性、阶段门禁、测试结论、业务验收和消息通知是不同状态层；不适用项统一只写 NA，也不混用状态。
+10. 正式项目只在已有成果覆盖且取得必要确认时受控跳转。明确的流程模拟可记录 BYPASSED_WITH_RISK 和 SIMULATION_ONLY，并只能以 SIMULATION_COMPLETED 结束。
+11. Etunel 运行时负责队列、投递、重试、去重、会话授权和文件传输；本 Skill 不另造这些软件机制。
+12. 当前 Hook、工具 schema、项目角色契约、成员登记和已确认流程基线高于本 Skill 的通用说明；不存在的工具、角色或参数不得伪造。
+
+## 渐进式路由
+
+只读取当前工作需要的引用：
+
+- Hub：先读 [Hub 工作流](references/hub-workflow.md)。
+- 创建项目、选择成员、配置自定义角色、成员交接、维护状态或发送状态快照：读 [成员与项目状态](references/project-status-and-membership.md)。
+- 选择阶段、正式成果、任务波次或交接：读 [项目生命周期](references/project-lifecycle.md)。
+- 成员：先读 [成员通用工作流](references/member-workflow.md)，再只读当前角色文件：
+  - [业务](references/roles/business.md)
+  - [产品](references/roles/product.md)
+  - [技术负责人](references/roles/technical-lead.md)
+  - [嵌入式应用层](references/roles/embedded-application.md)
+  - [嵌入式底层](references/roles/embedded-lowlevel.md)
+  - [硬件](references/roles/hardware.md)
+  - [测试](references/roles/testing.md)
+- 准备派发、回复、跨角色中继、完成或报告阻塞：读 [Etunel 任务消息流程](references/etunel-message-lifecycle.md)。
+- 定义或校验成果、状态、版本、证据、额外产出或豁免：读 [成果与完成判定](references/artifacts-and-evidence.md)。
+- 缺信息、错投、阻塞、会议决定、返工、变更、流程跳转或模拟：读 [异常与协调](references/exceptions-and-coordination.md)。
+- 仅当当前会话是 Hub 且发生钉钉汇报事件：读 [钉钉项目进度汇报](references/dingtalk-progress-reporting.md)。
+- 测试角色仅在任务类型匹配时，按 [测试职责](references/roles/testing.md) 中的二级链接读取更深细则。
+
+不要为“全面了解”一次加载全部引用或全部角色文件。Etunel Hook 源文件独立配置，不属于本 Skill 的渐进式发现树。
+
+## 每项任务的控制循环
+
+1. 确认身份、成员映射、有效流程与成果基线、任务目标、主责边界和 human owner。
+2. 向负责人复述任务；一次核对输入、输出、证据、版本、期限、完成条件和下游用途。
+3. 信息足够后执行本角色工作；缺少跨角色输入时，先走负责人路径，再向 Hub 提交聚合请求。
+4. 形成产出文件或成果包，完成专业自审并取得负责人确认。
+5. 通过当前 Hook 和 Etunel schema 对应的工具返回结果、补充请求或正式阻塞。
+6. Hub 校验并登记；合格则更新成果、状态、依赖和下一波次，不合格则精确补齐或按异常流程路由。
+
+## 提交前检查
+
+- 身份、成员、会话、WORK_ID、SUBTASK_ID 和流程基线是否来自运行时？
+- 是否只有一个主责角色和主责成员，且未越过其他角色专业或批准边界？
+- 输入是否足够，输出文件、证据、期限和完成条件是否与任务要求一致？
+- 自审、版本、负责人确认、开放项和风险是否明确？
+- 状态层是否正确，NA、DEFERRED、WAIVED 和模拟状态是否被混用？
+- 是否把并行任务波次误当成无依赖广播，或把消息排队、通知接受误当成业务完成？
+- 是否只使用当前 schema 中与本次意图匹配的 Etunel 工具？

etunel-role-collaboration/agents/openai.yaml

@@ -0,0 +1,4 @@
+interface:
+  display_name: "Etunel 多角色协作"
+  short_description: "约束 Hub 中介、成员状态、依赖任务波次、正式成果与消息流程"
+  default_prompt: "Use $etunel-role-collaboration to identify my Etunel role and member mapping, load only the relevant workflow and role rules, and complete the current project task through the Hub-mediated Etunel process."

etunel-role-collaboration/references/artifacts-and-evidence.md

@@ -0,0 +1,118 @@
+# 成果与完成判定
+
+Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读取。具体职责和上下游见 [项目生命周期](project-lifecycle.md) 与当前角色契约。
+
+## 正式成果集合
+
+正式门禁成果只使用以下名称：
+
+| 阶段 | 正式成果 |
+|---|---|
+| 1 业务需求 | Project Background Brief；Project Milestone Plan |
+| 2 产品定义 | Project Initiation Package；Test & Acceptance Criteria；Milestone Requirements |
+| 3 方案设计 | Solution Architecture；Software/Hardware Interface Contract；Hardware Design Package；Architecture Decision Record；Test Plan |
+| 4 项目规划 | Project Plan；Risk Register；Role Assignment；Product Documentation Package；Project Status Record |
+| 5 软硬件实现 | Hardware Implementation Package；Low-Level Implementation Package；Application Firmware Package |
+| 6 测试验证 | Functional Test Report；Reliability Test Report；Specialized Test Report；Test Evidence Package；Defect Analysis Report |
+| 7 业务验收 | Platform Test Approval Report；Customer Acceptance Approval Report；Conditional Acceptance Items |
+| 8 发布结项 | Closure Documentation Archive；Change Log；Closure Report；Process Closure Summary |
+
+角色自定义文件可作为 supporting、internal 或 ADDITIONAL 材料，但不能替代适用正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、Test Evidence Package 或 Defect Analysis Report，不另立正式成果类别。
+
+## 先定义产出契约
+
+正式执行任务派发时明确：
+
+1. 正式成果或内聚成果包名称及主责角色、主责成员；
+2. 每项最低内容、适用子项和协作边界；
+3. 输入基线、版本、supersedes 和可追踪引用；
+4. 所需证据及未执行验证的表达方式；
+5. 下游用途、期限和可检查完成条件；
+6. 本角色必须给出的专业结论；
+7. 专业自审和 human owner 确认要求。
+
+任务要求和实际产出应一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需可追踪、经有权角色确认且结论明确。
+
+## 任务结果最低结构
+
+不强制统一复杂 JSON，但正式结果必须让 Hub 找到：
+
+- WORK_ID、SUBTASK_ID、模式、流程基线、阶段、波次；
+- semantic role、实际 role ID、主责成员、session、human owner 和输入基线；
+- 实际完成内容和要求完成时间状态；
+- 成果名称、位置或传输引用、版本及 supersedes；
+- 每项完成条件对应的证据；
+- NA、未执行项、开放问题、依赖和剩余风险；
+- 本角色明确结论：满足、部分满足或无法满足；
+- self_check_result；
+- internal_approved，以及确认人、时间、范围和条件。
+
+一句“已完成”“没问题”或“测试通过”不能关闭任务。
+
+## 状态分层
+
+以下层级彼此独立：
+
+1. 项目运行模式；
+2. 任务执行结果；
+3. 成果生命周期；
+4. 成果适用性；
+5. 阶段与门禁；
+6. 测试结论；
+7. 业务验收结论；
+8. Etunel 消息或钉钉通知状态。
+
+按当前运行时或角色规则记录状态属于哪一层。任务成功不等于成果已基线；成果存在不等于门禁满足；测试 PASS 不等于业务验收；消息 Consumed 或通知 ACCEPTED 不等于项目完成。
+
+internal_approved=true 是本次消息／提交的人工确认字段；INTERNALLY_APPROVED 是成果生命周期语义。前者不能自动替代后者，成果状态仍需按其版本、证据和流程明确更新。
+
+## 内聚任务包与多任务
+
+- 同一角色、同一基线、紧密相关且共同交付的成果可组成一个任务包；全部必需产出满足才成功。
+- 能独立验收、失败或服务不同依赖的工作使用独立 SUBTASK_ID，即使同批发送。
+- 包内有效成果保留，未完成部分可拆为关联新任务；一个子项失败不能被其他成功掩盖。
+
+## 专业自审和人类确认
+
+self_check_result 说明角色如何按任务契约检查产出，可为 PASS、PARTIAL 或 FAIL，并列出依据与例外。
+
+internal_approved 表示本角色 human owner 实际查看本次结果并确认可作为角色正式提交。至少记录确认人、时间、文件／版本／范围和附带条件。AI 不得自行设为 true；模拟项目只确认模拟使用和流程推进，不证明模拟值真实。
+
+## 适用性、NA 与豁免
+
+- 适用内容必须形成；不适用统一标记 NA，并说明条件和依据。
+- NA 只表示不适用，不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
+- DEFERRED 是延后；WAIVED 是完成正式豁免；二者都不等于 NA。
+- 适用内容缺失不能用 NA 掩盖；固定成果不能靠空文件或虚假 PASS 通过。
+
+Artifact Waiver 由成果主责角色提出，提供成果标识、阶段、NA 原因、替代证据、下游影响、风险和内部确认。Hub 识别受影响角色与门禁：
+
+1. 受影响角色负责人确认不会产生需求、接口、实现、测试、发布或审计缺口；
+2. 低影响、无专业争议时，Hub AI 可完成形式审查、批准和登记；
+3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或存在争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
+4. 只有状态为 WAIVED、批准记录完整才满足对应门禁；
+5. 条件变化使成果重新适用时撤销豁免并恢复 REQUIRED。
+
+## 额外产出
+
+角色可提交职责内有价值的额外文件，标记 ADDITIONAL 并说明与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
+
+Hub 可将其纳入成果索引。若改变范围、接口、成员责任、基线、排期、正式成果或验收，先走 Change Request，不静默生效。
+
+## 事实、判断和证据
+
+结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标、正式承诺、REAL 与 SIMULATED 数据。
+
+研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。
+
+## 版本与可追踪性
+
+代码、固件、硬件、配置、设计、计划或报告给出足以唯一识别对象的版本／引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口／板卡／BOM／ECO／构建／环境的匹配关系和下游约束。
+
+新结果不能静默覆盖旧基线。正式变更保留旧版本、新版本、生效范围和 supersedes 关系。
+
+## Hub 校验边界
+
+Hub 检查文件存在、最低结构、身份、版本、证据引用、自审、负责人确认、冲突、依赖、状态层和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
+
+向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。

etunel-role-collaboration/references/dingtalk-progress-reporting.md

@@ -0,0 +1,78 @@
+# Hub 钉钉项目进度汇报
+
+仅当当前会话是 Hub 且发生本文件定义的汇报事件时读取。钉钉是面向项目群组的单向辅助可见性与异常提醒，不是任务派发、跨角色沟通、审批、门禁、人类确认或项目记录的事实源。
+
+## 权限与唯一入口
+
+- 只有 Hub／主 Agent 可以发送；成员 Agent 只把成果、状态或阻塞交给 Hub。
+- 项目配置为启用时视为持续发送授权，不需每条消息再次询问。
+- 只能调用项目封装入口：
+
+  `./scripts/dingtalk-progress <start|milestone|blocked|complete|failed> "<简短、人类可读的摘要和下一步>"`
+
+- Agent 不得直接调用底层 OpenAPI、`dws api` 或其他消息入口绕过封装脚本。
+- Agent 不读取、修改、输出或请求 Client Secret、DING_SEC、App Token、Client ID、robotCode、openConversationId 等凭据和内部标识。
+- Skill 与消息正文不得硬编码项目 Client ID、robotCode、openConversationId、Client Secret 或群名；项目差异只由 `.dingtalk/config.env` 和封装脚本处理。
+
+## 汇报单位
+
+汇报以整个 WORK_ID 生命周期为单位。Hub 聚合阶段、任务波次和 SUBTASK_ID 的结果，不为每条队列消息、普通回复、单个小步骤或短小只读问答发送通知。
+
+## 事件判定
+
+### start
+
+每个 WORK_ID 最多一次。在第一个真实可执行任务或任务波次已经通过 Etunel 实际派发后发送。仅建立计划、等待输入或讨论想法时不发送。
+
+### milestone
+
+在可验证、会改变下一步的实质进展发生时发送，例如：
+
+- 关键基线／成果包经校验成为有效版本；
+- 一个有意义的任务波次完成并触发角色或阶段交接；
+- 门禁、受控跳转、回退或豁免完成真实记录和必要确认；
+- 正式阻塞解除，项目恢复到明确下一动作；
+- 统一固件、版本矩阵、测试结论、验收或发布组合形成。
+
+同一处理轮或同一波次的相关结果合并成一条，不逐个 SUBTASK_ID 刷屏。没有固定时间间隔；依靠事件语义和去重控制频率。
+
+### blocked
+
+出现下列实际阻塞时立即发送：
+
+- 角色已完成负责人询问和必要线下协调，仍需用户、Hub 负责人或外部条件才能继续；
+- 关键路径等待有权决定；
+- Etunel 的任务投递、成员返回、会话或消息链路实际中断。
+
+普通排队、正常等待、角色仍可自行推进或尚未完成产出不算 blocked。阻塞解除后用 milestone 汇报恢复，不修改历史消息。
+
+### complete
+
+整个 WORK_ID 或用户明确指定的整体目标最终完成时发送一次。模拟项目必须写 `SIMULATION_COMPLETED`，不得表达真实发布、客户验收或生产就绪。
+
+### failed
+
+整个 WORK_ID／整体目标已最终终止、无法恢复或明确失败时发送。可返工的测试 FAIL、单个 SUBTASK_ID 失败或临时脚本异常不使用 failed。
+
+## 消息写法
+
+写成一段短摘要，或 2–4 条简洁要点，像项目负责人向团队说明进展，不像日志转储。优先包含：
+
+- 可公开的项目名或 WORK_ID、正式／模拟模式；
+- 当前阶段或任务波次；
+- 已验证进展、关键成果或版本；
+- 下一步和主责角色；
+- blocked 时补充原因、影响和需要谁采取什么动作。
+
+只写已验证结论。不得包含密钥、Token、个人数据、客户敏感信息、大段日志、完整内部对话或未经验证的根因推断。
+
+## 调用与结果
+
+1. Hub 判断事件并合并摘要。
+2. 调用封装脚本一次；脚本自行处理配置检查、发送和有限重试。
+3. 只有真实发送响应含非空 `processQueryKey`，才记为 `ACCEPTED`，含义仅是钉钉服务端接受，不证明群成员已读。
+4. 缺少或未启用配置记为 `SKIPPED`；dry-run 记为 `DRY_RUN`；没有有效 key 或最终发送错误记为 `FAILED_OR_UNKNOWN`。
+5. `SKIPPED`、`DRY_RUN` 和发送前配置／依赖校验错误不重试。真实发送失败或响应无有效 key 时，由脚本最多总计尝试 3 次，尝试间隔 10 秒；首次成功立即停止。未知响应重试可能造成极少量重复通知，按当前项目策略接受。
+6. 三次仍失败只终止本次钉钉发送，Etunel 主任务继续。Hub 在本地最终结果中向负责人说明一次，不再递归发送 blocked／failed，不自动补发历史事件。
+
+脚本输出和退出码用于判断通知调用，不得把钉钉结果升级成项目门禁。Agent 不自行在脚本外追加重试循环。

etunel-role-collaboration/references/etunel-message-lifecycle.md

@@ -0,0 +1,115 @@
+# Etunel 任务消息流程
+
+准备派发、补充、跨角色中继、返回、完成、阻塞或结算 Hub 入站消息时读取。当前 Hook 和 MCP schema 是工具名、参数与授权的最终依据；本文只约束职责和消息意图。
+
+## 标识与身份
+
+| 标识 | 含义 |
+|---|---|
+| WORK_ID | 贯穿项目生命周期的工作容器 |
+| 流程基线／阶段 | 当前 WORK_ID 已登记的流程版本与位置 |
+| 任务波次 | 同一有效基线下依赖已满足、可连续派发的一组任务 |
+| SUBTASK_ID | 一个主责角色和主责成员可独立判定的一项任务 |
+| role/member/session | 语义角色、实际角色实例、主责成员和绑定会话 |
+| message_id | 一条 Etunel 消息的单跳关联或结算标识 |
+
+正文已有有效标识时复用。已终态 SUBTASK_ID 不重新作为活动任务；运行时字段命名不同则按实际 schema 映射。
+
+## 工具职责
+
+| 意图 | 调用者 | Etunel 工具 |
+|---|---|---|
+| 向一个角色派发一条任务消息 | Hub | etunel_send_to_role，kind=task |
+| 向同一来源角色返回信息或终态状态 | Hub | etunel_send_to_role，kind=reply 或 kind=status，并按 schema 关联来源 message_id |
+| Hub 已处理入站且无需回复 | Hub | etunel_complete_coordination |
+| 成员向 Hub 补充、聚合询问或报告非终态状态 | 成员 | etunel_send_to_hub |
+| 成员成功结束自己的任务 | 主责成员 | etunel_complete_task |
+| 成员以具体阻塞结束自己的任务 | 主责成员 | etunel_report_blocked |
+| 读取当前消息列出的必要附件 | 当前绑定会话 | etunel_receive_message |
+
+工具未暴露、名称或参数不同，以当前 Hook 和 schema 为准并报告能力缺口；不得猜参数或请求内部授权字段。
+
+## 任务波次如何发送
+
+etunel_send_to_role 一次调用只发送一个接收角色和一条消息：
+
+- 同一角色多个独立 SUBTASK_ID 可连续发送，由 Etunel 队列处理；
+- 同一角色紧密相关且共同交付的内容可合并为内聚任务包；
+- 不同角色的依赖就绪任务分别发送、独立返回；
+- 排队不代表角色业务并行完成，也不代表下游依赖已经满足。
+
+Hub 不实现队列、ACK、锁、重试、去重或文件传输；这些由 Etunel 软件承担。
+
+## Hub 发送任务
+
+每条正式任务消息应包含：
+
+- WORK_ID、SUBTASK_ID、模式、流程基线、阶段和波次；
+- semantic role、实际 role ID、主责成员、session、human owner 和协作角色；
+- 目标、背景、上游成果、输入版本和成果引用；
+- IN_SCOPE、OUT_OF_SCOPE、依赖、接口、限制和风险；
+- 指定成果及最低内容、证据、版本、下游用途；
+- 要求完成时间、完成条件和职责内结论；
+- 专业自审和 human owner 确认要求；
+- 信息不足、额外产出和阻塞的处理边界。
+
+纯信息、澄清或授权消息写清问题、已确认事实、影响、选项和所需答复，不要求空文件。不要转发无关聊天、全量计划或无法消化的资料堆。
+
+## 成员请求补充
+
+成员先询问自己的负责人并完成必要线下沟通。仍需 Hub 时，用一条 etunel_send_to_hub 写清：
+
+- SUBTASK_ID、已完成工作和现有成果；
+- 聚合后的缺失信息／决定及用途；
+- 已向负责人询问和线下协调的结果；
+- 对结论、范围、期限、风险和下游的影响；
+- 建议的信息所有者角色；
+- 当前仍可继续的范围与希望 Hub 返回的具体内容。
+
+Hub 已有登记答案时一次补足；没有时才产生必要的跨角色查询或任务。
+
+## 经 Hub 的跨角色中继
+
+当前 Etunel 没有成员间直连工具。跨角色交流必须是：来源成员 → Hub → 目标成员 → Hub → 来源成员。
+
+- Hub 忠实保留问题、适用范围和来源，不替任一角色作专业改写；
+- 目标角色返回前完成专业自审和负责人确认；
+- Hub 校验并登记确认结论后，才向来源角色返回最小必要内容；
+- 给另一个角色的新 task 是独立消息，不能拿来源角色的 message_id 充当跨角色结算；
+- 只有按当前 schema 返回同一来源角色的关联 reply/status 才结算该来源协调项；
+- 一个跨角色 task 的发送不能替代对原入站消息的正确处理。
+
+默认一次聚合请求和一次答复；复杂异常使用 Meeting Decision Record，不把多轮聊天当成项目事实。
+
+## Project Status Snapshot
+
+状态快照只由 Hub 向受影响角色发送，是裁剪后的状态同步，不是新专业任务、成果或门禁。写明变化、有效版本、对接收方影响、下一步、责任方和期限；同一处理轮聚合一次。若需要角色执行动作，应另有明确 task 或按当前 schema 明确消息意图。
+
+## 成员完成或阻塞
+
+调用 etunel_complete_task 前，确认指定成果、证据、版本、期限状态、专业自审、负责人确认和明确结论均已包含。
+
+调用 etunel_report_blocked 时至少说明：
+
+- 阻塞条件；
+- 已完成成果和已尝试排查／负责人／线下协调；
+- 缺失输入或决定及建议责任人；
+- 对本任务和下游的影响；
+- 恢复条件和建议下一步。
+
+成员只能结束自己的任务。Hub 不能代成员完成或阻塞；成员不能结算 Hub 的协调消息。
+
+## Hub 处理成员入站
+
+Hub 对每条入站消息选择：
+
+- 需要向同一来源角色回复：按 schema 发送关联 reply/status；
+- 无需回复且已处理：调用 etunel_complete_coordination；
+- 需要其他角色：正确处理来源协调项，并按依赖创建一个或多个必要任务；
+- 同一轮到达多个相关结果：先更新成果、状态和依赖，再统一选择下一波次。
+
+消息结算、排队和送达不代表 SUBTASK_ID、成果、阶段或 WORK_ID 完成。
+
+## 附件
+
+直接使用当前消息正文和内嵌内容。仅当消息明确列出附件且为当前任务必要输入时，调用 etunel_receive_message 获取所需附件。不要为探测队列或重复确认而读取。

etunel-role-collaboration/references/exceptions-and-coordination.md

@@ -0,0 +1,124 @@
+# 异常与协调
+
+出现缺失信息、错投、职责冲突、阻塞、复杂线下会议、缺陷、返工、变更、流程跳转、成果豁免或模拟流程时读取。所有成员 Agent 跨角色通信都经 Hub；现阶段没有成员直连。
+
+## 缺失信息
+
+成员按以下顺序处理：
+
+1. 检查任务和本会话已有的已确认资料；
+2. 一次向本角色负责人列清缺什么、用途、影响和建议来源；
+3. 负责人能回答时记录来源、时间、范围和条件后继续；
+4. 负责人不能回答时，提醒其线下寻找能解决问题的人；
+5. 线下结果回到本角色会话，经本角色负责人确认；
+6. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题或正式阻塞。
+
+Hub 有登记答案时直接补足；没有时只向实际信息所有者角色创建必要查询或任务。取得确认结果后返回原任务，不广播无关角色。
+
+## 结果不完整
+
+- 原任务目标不变；Hub 只列缺失成果、字段、证据、版本、自审或确认。
+- 已终态任务使用关联的新 SUBTASK_ID 补齐；有效部分保留，不要求无关重做。
+- 补齐后按原契约重新校验。
+- Hub 不用推测补专业结论，也不为一个格式字段增加虚假评审层。
+
+## 错投与职责冲突
+
+成员保留本角色已完成部分，向 Hub 说明错误身份／成员、越界内容、影响和建议责任方。Hub 按决定权路由：
+
+- 目标、业务范围、优先级、资源、组织授权和最终业务风险接受：业务；
+- 产品行为、需求含义、用例与验收标准：产品；
+- 总体架构、跨层接口、技术取舍、依赖与集成：技术负责人；
+- 应用逻辑、状态机、应用协议和应用服务：嵌入式应用层；
+- BSP、Bootloader、驱动、RTOS、系统服务和 HAL：嵌入式底层；
+- 电路、PCB、器件、BOM、电源、信号、热和板卡：硬件；
+- Test Plan、环境、用例、证据、缺陷复验与质量结论：测试；
+- 已登记自定义领域：按其角色契约，不隐式夺取默认角色权责。
+
+跨多个领域时，技术负责人界定接口和依赖；每项后续任务仍只有一个主责角色和成员。
+
+## 阻塞与异常提醒
+
+正式阻塞说明原因、已完成成果、负责人沟通、线下协调、影响、需要谁采取什么动作以及恢复条件。
+
+- Hub 评估关键路径；不受影响的任务继续。
+- Hub 主动提醒当前主责和实际关联角色，提供问题、证据、冲突点、影响、原流程位置、所需回应和期限；不机械通知全体角色。
+- 能由一个角色解决时只派该角色；多个独立问题可形成波次。
+- 没有现成责任人时提醒当前负责人线下找能解决问题的人。
+- 需要用户、业务、项目发起人或重大争议决定时，Hub 负责人介入。
+- 阻塞解除后，终态任务使用关联的新 SUBTASK_ID。
+
+Etunel 投递、成员返回、会话或消息链路实际中断是流程阻塞；正常排队和等待不是阻塞。
+
+## 复杂线下会议与 Meeting Decision Record
+
+普通线下补充不强制会议记录。跨角色冲突复杂、证据矛盾或在线任务已阻塞时：
+
+1. Hub 准备问题包和结论模板，不主持专业裁决；
+2. 当前主责角色的真人负责人组织线下会议；
+3. 参与者把各自专业结论带回对应角色会话，完成角色负责人确认；
+4. 当前主责角色汇总一份 Meeting Decision Record，至少包含参与角色、问题、证据、各专业确认、统一结论、适用范围、版本、不同意见、风险、行动项、责任人和期限；
+5. 当前主责角色向 Hub 提交该记录及参与方确认引用，其他角色不重复提交整份记录；
+6. Hub 只校验身份、确认、版本、证据、冲突和可执行性，登记后从原阻塞点恢复；
+7. 结论改变正式基线时转入 Change Request。
+
+会议记录不能让主责角色代替参与角色作出专业批准；缺少有权确认时仍保持阻塞。
+
+## 缺陷与返工
+
+1. 测试创建并持续维护 Defect Analysis Report，记录被测组合、环境、复现、期望／实际、证据、风险、建议责任边界、复验和状态。
+2. 根因边界不清时由技术负责人确认系统边界、版本关系或架构影响；Hub 不自行归因。
+3. Hub 向实际责任角色派发修复任务；相关缺陷可形成修复包，独立角色可形成修复波次。
+4. 实现角色提交 Root Cause Analysis、Fix Plan、修复成果和版本、角色自测、影响与建议回归范围。
+5. 底层修复先交应用层重新合版；硬件 ECO 同步评估底层兼容、应用固件有效性和版本关系。
+6. 技术负责人确认新版本组合后，测试在目标组合独立复验。
+7. 只有测试可把 Defect Analysis Report 更新为 VERIFIED／CLOSED；实现角色和 Hub 无权替换或关闭。
+
+产品负责需求含义，业务负责业务风险接受；这些决定不修改测试原始观察和质量结论。
+
+## Change Request
+
+任何改变已确认范围、方案、任务、正式成果、成员职责、接口、版本、排期或门禁的事项都走正式变更：
+
+1. Hub 冻结受影响任务，登记来源、原因、目标、当前基线、影响对象和紧急性；
+2. 产品、技术负责人、实际受影响实现／自定义角色和测试分别评估；
+3. Hub 汇总范围、技术、实现、测试、资源、成本、质量、风险、完成工作和里程碑影响；
+4. 需要组织授权的变更由业务批准、拒绝或延期；
+5. 批准后创建新基线，保留旧版本和 supersedes，重开受影响阶段、成果、任务和门禁；
+6. 未批准不得边评估边实施，也不得用状态纠正规避变更。
+
+只联系真正受影响角色，不固定全角色参与。
+
+## 成果豁免
+
+固定正式成果不适用时，按 [成果与完成判定](artifacts-and-evidence.md) 发起 Artifact Waiver。NA、DEFERRED、SKIPPED、口头同意或空文件都不能替代 WAIVED。
+
+## 正式项目的受控跳转、暂缓与回退
+
+正式项目只有在已有正式成果实际覆盖目标阶段并取得必要角色确认时才能受控跳转：
+
+- 记录发起人、原因、时间、现阶段、目标位置、复用成果及版本、未满足项、影响、风险、批准和恢复点；
+- 使用当前运行时支持的真实受控跳转、回退或 DEFERRED 状态；任何正式要求未被既有成果覆盖时都不能通过门禁，也不得用 BYPASSED_WITH_RISK 代替；
+- Hub 负责人确认；影响范围、日期、资源、成本、质量、验收或专业结论时取得业务和相关角色确认；
+- 下游明确知道缺失基线和风险；固定成果确实无需补做时另走 WAIVED。
+
+跳转是流程状态，不是专业批准，也不保证可发布。
+
+## 模拟／流程验证项目
+
+只有用户明确对整个 WORK_ID 启用模拟后可使用：
+
+- 可使用真实已知数据和为流程验证构造的数据；关键值标记 REAL 或 SIMULATED；
+- 模拟值影响结论时，相关成果整体标记 SIMULATION_ONLY；
+- 可按明确指令临时跳过或进入后续节点，并记录 BYPASSED_WITH_RISK、假设、风险和恢复项，不让门禁卡死流程验证；
+- human owner 确认的是模拟使用和流程推进，不是数据真实性；
+- 不静默切回正式模式，不让模拟结论进入客户承诺、真实测试或生产发布；
+- 结束状态只能是 SIMULATION_COMPLETED，不能写 CLOSED、RELEASED、CUSTOMER_ACCEPTED 或 PRODUCTION_READY。
+
+## 真实授权事项
+
+真实人员、资源、预算、采购、业务范围、正式日期、项目暂停或取消需要授权时，Hub 提供事实、选项、建议、影响和最晚决定点，向有权业务负责人／项目发起人请求决定。未决定前保持真实等待或阻塞，不解释为默认批准。
+
+## 信息披露
+
+Hub 只向实际需要者传递已确认结论、成果版本、证据引用和行动要求；不群发完整聊天。外部客户信息由业务或产品真人负责人按授权取得并回到对应角色会话；客户未作为已契约且已绑定角色时，Hub 不直接派发 Etunel 任务。

etunel-role-collaboration/references/hub-workflow.md

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

etunel-role-collaboration/references/member-workflow.md

@@ -0,0 +1,91 @@
+# 成员角色通用工作流
+
+适用于业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试及已登记自定义角色会话。读取后，只加载当前角色对应职责；自定义角色只使用其实际角色契约。
+
+## 身份与通信边界
+
+成员会话只代表当前绑定的 semantic role、实际 role ID 和 role member ID，负责本角色任务的沟通、专业工作、成果、证据与结论，不负责项目总体调度。
+
+- 正式任务从 Hub 接收，正式结果只交 Hub。
+- 现阶段 Etunel 不支持成员间直接通信；不得直接向其他成员 Agent 派任务、索取结论或建立私下依赖。
+- 跨角色问题先聚合交 Hub，由 Hub 定向中继并返回已确认结论。
+- 人类负责人可以线下找相关人员；讨论结果必须回到负责该专业结论的角色会话，经负责人确认后再交 Hub。
+- 不向钉钉发送项目进度；需要可见性时把成果、状态或阻塞交给 Hub。
+
+## 接收任务后先对齐
+
+先确认入站任务确实指向本角色、本成员和当前会话；主责成员不明、指向其他成员或交接不完整时先报告，不抢占任务。
+
+角色 AI 不得收到 Hub 任务后自顾自完成。先向 human owner 用人类可读语言复述：
+
+- WORK_ID、SUBTASK_ID、项目模式、流程基线、阶段、波次和主责身份；
+- 任务目标、IN_SCOPE、OUT_OF_SCOPE 和协作边界；
+- 已确认输入、版本、依赖、接口、限制与风险；
+- 指定文件或成果包、最低内容、证据、下游用途和完成条件；
+- 要求完成时间及是否为正式承诺、目标或待确认；
+- 需要负责人提供、判断或确认的事项。
+
+一次列出当前可预见缺口。负责人确认理解、补足输入或明确可以开始后再执行。同一消息含多个 SUBTASK_ID 时分别保持状态和结论；内聚任务包按全部必需产出整体判定。
+
+## 执行本角色任务
+
+1. 只使用 Hub 给出的当前有效基线，且只处理本角色范围。
+2. 形成任务指定的实际文件或连贯成果包；纯信息或决定请求直接给出所需结论。
+3. 记录实际方法、环境、版本、构建、板卡、配置或其他可复查证据。
+4. 分开写明事实、证据、专业判断、假设、批准决定、开放问题、依赖和剩余风险。
+5. 未执行验证说明原因和影响，不虚构构建、测试、设备结果或人类意见。
+6. 发现范围、接口、版本、成员责任、日期或验收变化时不静默修改基线，提交 Hub 走 Change Request。
+7. 产出完成前不发送频繁进度；只有必要补充、正式阻塞或 Hub 明确要求的关键状态才发送非终态消息。
+
+## 信息不足与跨角色输入
+
+按以下顺序处理：
+
+1. 检查任务和本会话已有的已确认输入。
+2. 一次向本角色负责人列出缺什么、用途、影响和建议来源。
+3. 负责人能提供则记录来源、范围、时间和条件后继续。
+4. 负责人无法提供时，提醒其线下联系能解决问题的人；讨论结果回到本会话。
+5. 仍无法解决，或必须取得另一角色正式成果时，向 Hub 发送一组聚合问题，写明需要的专业所有者和当前可继续范围。
+6. Hub 返回后核对来源角色、确认状态、成果版本、适用范围和风险，再继续任务。
+
+不要逐句追问或绕过 Hub。默认一问一答；只有新的实质阻塞才追加。复杂异常按 Meeting Decision Record 流程处理。
+
+## 专业自审与负责人确认
+
+正式结果至少包含：
+
+- WORK_ID、SUBTASK_ID、主责身份和输入基线；
+- 实际完成内容、成果文件及版本；
+- 每项完成条件对应证据；
+- NA、未执行项、开放问题、依赖和剩余风险；
+- 本角色明确专业结论；
+- self_check_result；
+- internal_approved，以及负责人、时间、确认范围和附带条件。
+
+internal_approved=true 只能在负责人实际确认后填写；它是提交字段，不等于成果生命周期已经是 INTERNALLY_APPROVED。模拟模式的确认只代表同意使用标明的模拟材料推进，不证明数据真实。
+
+## 返回与终态
+
+- 任务仍可继续且只需 Hub 补充：用 etunel_send_to_hub 一次提交聚合请求，任务保持非终态。
+- 全部必需产出完成、专业自审完成且负责人确认：当前主责成员调用 etunel_complete_task。
+- 任务无法继续，且原因、已尝试协调、影响、所需决定和恢复条件明确：当前主责成员调用 etunel_report_blocked。
+
+已终态 SUBTASK_ID 不复用。补充、返工或阻塞解除后，由 Hub 创建关联的新 SUBTASK_ID。工具细则见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
+
+## 错投、越界或成员替换
+
+1. 保留已经完成的本角色范围工作；
+2. 指出错误身份、越界内容、影响和建议责任角色／成员；
+3. 把本角色可确认事实交 Hub；
+4. 等待 Hub 重新路由或完成交接，不替另一角色补写专业结论；
+5. 新成员不自动继承旧成员的人类批准，需重新确认适用成果。
+
+## 成员禁止事项
+
+- 不自行切换角色、成员或任务主责；
+- 不直接向其他成员 Agent 通信；
+- 不自行改变业务范围、产品行为、总体架构、硬件规格、接口、验收标准或正式日期；
+- 不用角色自测替代测试结论，不用 AI 生成替代负责人确认；
+- 不在成果完成前用大量状态消息制造往返；
+- 不传播完整私有对话、无关项目资料、个人数据或明文凭据；
+- 不把 Etunel 投递状态、Project Status Snapshot 或钉钉通知当作业务完成。

etunel-role-collaboration/references/project-lifecycle.md

@@ -0,0 +1,202 @@
+# Etunel 项目生命周期
+
+Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成员只在当前任务需要理解上下游时读取相关阶段。
+
+## 通用推进原则
+
+- 正常顺序是：业务需求 → 产品定义 → 方案设计 → 项目规划 → 软硬件实现 → 测试验证 → 业务验收 → 发布结项。
+- 每项任务只有一个主责角色、一个主责成员、一个 SUBTASK_ID 和可独立判定结果。
+- 主责草案、专业角色评估／设计和主责收口的依赖不可颠倒；同一基线上的独立任务可形成波次。
+- 正式结果必须有指定成果、版本、证据、专业自审和 human owner 确认。
+- 正式成果名以本文件清单为准；过程记录、支持材料和 ADDITIONAL 文件不得冒充正式成果。
+- 不适用统一写 NA；成果豁免写 WAIVED；延期写 DEFERRED。BYPASSED_WITH_RISK 仅用于明确的模拟／流程验证，不得满足正式门禁。
+- 正式项目遵循门禁。仅明确的模拟／流程验证 WORK_ID 可按异常规则灵活跳转并标记 SIMULATION_ONLY。
+
+## 阶段 1：业务需求
+
+### 正常任务链
+
+1. 业务形成 REVIEW_READY 业务草案，澄清背景、客户目标、价值、IN_SCOPE、OUT_OF_SCOPE、优先级、合作边界、成功指标和目标里程碑。
+2. 产品判断是否需要早期专业风险预审，并精确选择一个或多个角色、问题和必要输入。
+3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
+4. 产品整理预审影响，业务负责人确认阶段 1 基线。
+
+### 正式成果
+
+- Project Background Brief
+- Project Milestone Plan
+
+早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。
+
+### 门禁
+
+有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。
+
+## 阶段 2：产品定义
+
+### 正常任务链
+
+1. 产品基于阶段 1 基线形成产品定义草案、详细客户输入和可测试验收标准。
+2. Hub 以同一草案版本向技术负责人、嵌入式应用层、嵌入式底层、硬件和测试中的适用角色派发专业评估；依赖独立时可并行。
+3. 各角色只返回本领域可行性、约束、缺口、风险和建议，不代产品改需求。
+4. 产品处置反馈、解决需求冲突并收口产品基线。
+5. 业务批准客户范围、验收边界和需要组织授权的结论。
+
+### 正式成果
+
+- Project Initiation Package
+- Test & Acceptance Criteria
+- Milestone Requirements
+
+Customer Input Matrix、平台 SDK、串号、对接资料、功能清单、器件和板框资料可作为包内内容或支持输入，不另立旧版开发资料包。
+
+### 门禁
+
+产品行为、范围、异常边界、接口期望和客观验收标准明确；关键专业约束已处置；产品负责人确认，业务完成范围批准。
+
+## 阶段 3：方案设计
+
+### 正常任务链
+
+1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的 Project Plan。
+2. Hub 以同一方案／接口版本向适用角色形成设计波次：
+   - 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
+   - 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
+   - 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
+   - 测试：Test Plan、环境、策略、覆盖、可测试性和通过标准；
+   - 产品：确认方案没有需求漂移。
+3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
+4. 受影响角色分别确认本领域约束与统一版本一致。
+
+### 正式成果
+
+- Solution Architecture
+- Software/Hardware Interface Contract
+- Hardware Design Package
+- Architecture Decision Record
+- Test Plan
+
+技术负责人主责总体方案、接口契约和 ADR；硬件主责 Hardware Design Package；测试主责 Test Plan。
+
+### 门禁
+
+方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。
+
+## 阶段 4：项目规划
+
+### 正常任务链
+
+1. Hub 基于已确认方案形成 Project Plan、Risk Register、Role Assignment、Product Documentation Package 和正式 Project Status Record 草案。
+2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
+3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
+4. Hub 收口计划和状态记录；业务授权真实成员、资源、采购、成本和正式日期。
+5. Hub 向相关主责成员下发依赖就绪任务切片。
+
+### 正式成果
+
+- Project Plan
+- Risk Register
+- Role Assignment
+- Product Documentation Package
+- Project Status Record
+
+项目创建时的成员映射和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或 READY。
+
+### 门禁
+
+每项计划任务有主责角色、主责成员、输入、输出、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可执行。
+
+## 阶段 5：软硬件实现
+
+### 正常任务链
+
+1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
+2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
+3. 底层向 Hub 提交可消费底层版本和集成说明；Hub 交应用层合版。
+4. 应用层解决集成问题并作为唯一出口形成 Application Firmware Package。
+5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
+6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。
+
+### 正式成果
+
+- Hardware Implementation Package
+- Low-Level Implementation Package
+- Application Firmware Package
+
+版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。
+
+### 门禁
+
+适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。
+
+## 阶段 6：测试验证
+
+### 正常任务链
+
+1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
+2. 测试依据 Test Plan 和 Test & Acceptance Criteria 执行功能、可靠性、专项和回归验证。
+3. 测试创建并维护 Defect Analysis Report；缺陷由 Hub 向实际责任角色形成修复波次。
+4. 实现角色提交 Root Cause Analysis、Fix Plan、修复成果、版本、自测和影响；不能替测试关闭缺陷报告。
+5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
+6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。
+
+### 正式成果
+
+- Functional Test Report
+- Reliability Test Report
+- Specialized Test Report
+- Test Evidence Package
+- Defect Analysis Report
+
+质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。
+
+### 门禁
+
+测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试给出 PASS、FAIL 或 BLOCKED。测试通过不替代业务验收。
+
+## 阶段 7：业务验收
+
+### 正常任务链
+
+1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示／试用和差异处置。
+2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品真人负责人按联络边界取得，并返回对应角色会话。只有已契约化、由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
+3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
+4. 产品形成验收报告和附条件事项；业务批准验收结论、上线／交付条件和业务风险接受。
+
+### 正式成果
+
+- Platform Test Approval Report
+- Customer Acceptance Approval Report
+- Conditional Acceptance Items
+
+不适用的平台或客户验收成果按 NA／Artifact Waiver 规则处理，不能用内部测试自动替代。
+
+### 门禁
+
+平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。
+
+## 阶段 8：发布结项
+
+### 正常任务链
+
+1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布／结项任务：
+   - 应用层输出唯一最终发布固件和发布说明；
+   - 底层归档实际被集成的版本和接口信息；
+   - 硬件归档板卡、BOM、生产资料和适用 ECO；
+   - 技术负责人确认最终版本组合与发布技术前提；
+   - 测试对最终组合执行适用发布验证；
+   - 产品确认发布范围与批准产品和验收一致；
+   - 业务确认交付、合同、License、客户沟通和遗留责任。
+2. 实际参与角色提交成果索引、未决事项和本角色 Process Closure Summary 输入；未参与角色登记 NA 原因，不创建虚假任务。
+3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。
+
+### 正式成果
+
+- Closure Documentation Archive
+- Change Log
+- Closure Report
+- Process Closure Summary
+
+### 门禁
+
+正式项目只有在适用交付、验证、批准、归档和遗留承接完成后才可关闭。模拟项目只记录 SIMULATION_COMPLETED，不得宣称真实发布、客户验收或生产就绪。

etunel-role-collaboration/references/project-status-and-membership.md

@@ -0,0 +1,69 @@
+# 成员与项目状态
+
+创建 WORK_ID、建立成员映射、添加或替换角色、维护 Project Status Record、纠正状态或向角色同步状态时读取。
+
+## 默认角色与自定义角色
+
+默认语义角色为：业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试。默认角色不是封闭集合，但尚未在当前项目登记的角色不能接收任务。
+
+自定义角色启用前必须有角色契约，至少说明：
+
+- 目标、存在理由、职责和 non-goals；
+- 参与阶段、触发条件、上游输入和下游消费者；
+- 正式成果、专业决定权、确认权和不拥有的门禁权；
+- semantic role、实际 role ID、role member ID、session ID 和 human owner；
+- 加入、退出、替换、交接和未完成事项承接规则。
+
+由 Hub 负责人或项目发起人提出，受影响角色负责人确认边界。若改变阶段、正式成果、信息流、门禁或既有基线，先走 Change Request 并取得业务批准。
+
+角色契约确认后，必须由 Hub 真人负责人在 Etunel 中手动添加并完成实际绑定。Hub AI 只能准备契约、检查信息和等待运行时登记，不得宣称已自动创建角色，不为不存在的角色或会话派发任务，也不生成虚假的通用自定义角色 Hook。
+
+## 身份与成员映射
+
+- semantic role 表示业务、产品、测试等职责语义；实际 role ID 表示当前项目中的角色实例。
+- role member ID 或 member ID 表示实际成员；session ID 表示绑定会话；human owner 表示该会话的真人负责人。
+- 同一 Codex 账户在同一项目原则上只承担一个 semantic role。
+- 同一角色可以有多个账户或会话，但每个 SUBTASK_ID 必须明确唯一主责角色和主责成员。
+- Hub 只向主责成员及确有必要的协作成员提供任务切片，不向同角色所有会话广播。
+
+创建 WORK_ID 时立即建立过程成员登记和会话映射。阶段 4 再把实际成员、职责、任务主责、协作和交接关系正式化为 Role Assignment。
+
+## 加入、退出与替换
+
+新成员接收任务前，先确认身份与角色，并交接：
+
+- 当前流程基线、阶段和门禁；
+- 未决任务、依赖、期限和阻塞；
+- 适用成果、当前版本、supersedes 关系和风险；
+- 允许决定的范围、human owner 和协作路径。
+
+成员退出或替换时保留历史角色、任务、成果和确认记录。新成员不得自动继承旧成员的人类批准；需要继续使用时，由新负责人明确重新确认适用文件、版本、范围和条件。
+
+## Project Status Record
+
+Hub 从项目创建起维护内部状态。阶段 1 至阶段 3 属于过程记录；阶段 4 将其正式化为 Project Status Record，此后版本化维护。至少覆盖：
+
+- 项目模式、流程基线、当前阶段和门禁；
+- 任务、主责成员、协作角色、依赖、期限和下一步；
+- 成员与会话映射、加入退出和交接状态；
+- 风险、阻塞、决定、变更和豁免；
+- 正式成果、生命周期、适用性、版本、证据和 supersedes；
+- 下一可执行任务及其恢复条件。
+
+Project Status Record 记录流程事实，不替代各阶段正式专业成果。
+
+## 裁剪状态快照
+
+阶段／门禁、任务分派、依赖、阻塞、风险、决定、成果基线或期限发生会改变行动的关键变化时，Hub 向实际受影响的角色发送 Project Status Snapshot：
+
+- 每个处理轮或波次聚合一次，不为每个细小字段变化刷屏；
+- 只包含接收方需要采取行动或判断依赖的状态切片；
+- 写明当前有效版本、发生了什么、对本角色的影响、下一步、责任方和期限；
+- 不广播完整计划、无关角色状态、私有对话或空 ACK；
+- 快照是同步视图，不替代任务、成果、批准或门禁。
+
+## 状态纠正与基线变更
+
+发现过程状态登记错误时，保留旧值、新值、原因、证据、纠正人和生效时间。单纯纠正事实可更新记录；若改变已确认范围、方案、任务、成员职责、接口、版本、排期、正式成果或门禁，必须转入 Change Request，不能用“状态纠正”规避变更。
+
+新 WORK_ID 默认使用当前流程基线。在途 WORK_ID 继续使用其已登记基线；只有明确决定迁移时，才记录阶段和成果映射、缺失项、风险、必要确认及 supersedes，并按影响决定是否建立 Change Request。

etunel-role-collaboration/references/roles/business.md

@@ -0,0 +1,89 @@
+# 业务角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担 business 语义职责时读取。
+
+## 核心使命
+
+作为面向客户和组织授权的业务窗口，负责正式项目发起、客户关系、商业价值、业务范围、优先级、合作与交付边界、真实资源与对外承诺，以及报价到回款、续约或终止的业务闭环。
+
+业务定义为什么做、商业价值、高层成功标准和哪些决定获得组织授权；产品把这些目标转化为详细产品行为、输入清单和可执行验收条件。
+
+## 流程节点
+
+- 阶段 1：主责 Project Background Brief 和 Project Milestone Plan；确认早期预审影响后的业务需求基线。
+- 阶段 2：批准客户范围、验收边界和需要业务授权的产品结论。
+- 阶段 4：授权真实人员、资源、采购、成本和正式日期承诺，不在方案形成前虚构计划承诺。
+- 阶段 7：在产品组织验收后批准业务验收、上线／交付条件和风险接受。
+- 阶段 8：确认交付、合同、付款、License、客户沟通和遗留责任。
+- Change Request：在实际受影响角色评估后批准、拒绝或延期需要组织授权的变更。
+- 业务事件：处理报价、合同、License、付款、重大投诉、暂停、缩减、续约、扩容或终止。
+
+## 正式项目发起
+
+有权业务负责人明确要求发起的项目视为正式项目。资料不完整时：
+
+- 不重新做商机资格审查，也不把项目降级为模拟；
+- 已知信息如实提交，未知、冲突、假设和风险列为开放项；
+- 不猜测详细产品或技术事实，也不因缺少它们拒绝发起；
+- 只向 Hub 提交项目发起成果，不直接向产品、研发、硬件或测试派任务。
+
+从现有材料整理客户与项目、问题、目标、场景、价值、产品方向、合作模式、交付边界、客户期望日期、材料引用和已知风险。“起草、评估、优化”只形成草案；只有负责人明确授权提交时才通过 Etunel 正式交 Hub。
+
+## 主责范围
+
+- 市场机会、客户主体、客户关系和决策关系；
+- 商业价值、业务目标、优先级和高层成功指标；
+- 报价、合同、付款、回款和 License 条款；
+- 客户范围、定制范围、合作模式、交付边界和责任划分；
+- 客户期望、目标里程碑和经批准的对外口径；
+- 重大范围变化、业务例外、客户关系与商业风险；
+- 售后、续约、扩容、合作终止和业务收尾；
+- 基于正式产品与测试证据的最终业务验收与风险接受。
+
+业务按事件介入，不参加每个研发和测试事项，也不承担日常技术项目经理职责。
+
+## 与产品和客户的边界
+
+阶段 1 后，产品主责详细需求、Customer Input Matrix、平台 SDK／协议资料、测试环境与账号状态、样机输入、产品流程和验收条件。业务移交已知客户背景、联络权限、约定和材料引用，不替产品维护详细输入矩阵或判断技术资料适用性。
+
+外部客户不是默认 Etunel 角色。客户信息由业务或产品真人负责人按联络边界取得并返回各自会话，再经 Hub 流转；Hub 不直接向未契约、未绑定的客户发送任务。
+
+产品日常细化无需业务逐项批准。价格、合同、License、客户范围、责任、对外承诺、验收条件、重大客户风险、暂停或终止发生变化时，再由 Hub 定向交业务决定。
+
+## 授权、状态和日期
+
+以下事项需要有权业务负责人明确确认：
+
+- 报价、合同、付款和 License；
+- 客户范围、定制范围和交付边界；
+- 真实人员、资源、预算、采购和正式日期；
+- 重大范围变化、暂停、缩减或终止；
+- 附条件交付、业务风险接受；
+- ACCEPTED、CONDITIONALLY_ACCEPTED 或 REJECTED 等业务验收语义。
+
+沉默、超时、普通协调状态或“客户可能同意”不算批准。批准不自动等于已经对外承诺。日期至少区分 CUSTOMER_EXPECTED_DATE、INTERNAL_TARGET_DATE 和 COMMITTED_DATE。
+
+## 期望输入
+
+- 客户原始材料、联络边界和业务事实；
+- 产品收口成果、验收标准和验收组织结果；
+- Hub 整理的范围、版本、计划影响、风险和明确决定请求；
+- 测试结论、平台／客户验收证据、缺陷和剩余风险；
+- 报价、合同、付款、License 与交付材料的受控引用。
+
+## 正式输出
+
+- Project Background Brief；
+- Project Milestone Plan；
+- 业务目标、范围、优先级、高层成功指标和交付边界；
+- 报价／合同／付款／License 决定和对外承诺记录；
+- 产品范围批准、Change Request 决定和组织授权；
+- 业务验收批准、Conditional Acceptance Items 的业务处置或拒绝原因；
+- 结项阶段的交付、回款、续约、终止和遗留业务事项；
+- 决定人、授权状态、证据引用和剩余业务风险。
+
+业务不输出详细产品需求、总体方案、硬件／固件实现或测试结论。
+
+## 信息保护
+
+完整报价、合同、付款、License 和客户材料使用受控引用；只向下游传递当前任务必需的业务边界和批准结论。密码、Token、私钥、证书密钥、个人数据及无关客户资料不得进入普通消息或成果。

etunel-role-collaboration/references/roles/embedded-application.md

@@ -0,0 +1,52 @@
+# 嵌入式应用层角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担嵌入式应用层职责时读取。
+
+## 核心使命
+
+在已确认产品行为、总体架构和底层接口之上，实现设备业务逻辑、功能流程、应用模块与服务，并交付可集成、可提测、可发布的应用层固件和证据。
+
+## 流程节点
+
+- 阶段 2：评估产品需求中的应用实现约束；
+- 阶段 3：基于统一方案／接口版本形成应用层设计、接口和资源需求，并确认技术负责人收口版本；
+- 阶段 5：按已确认依赖完成应用层实现，消费底层版本并形成唯一统一固件；
+- 阶段 6：承担证据指向应用层的缺陷修复；
+- 阶段 8：作为唯一最终固件出口形成正式发布固件与发布说明；
+- 需求变更：仅在技术负责人判定实际受影响时评估应用影响。
+
+## 主责
+
+- 设备业务逻辑、功能流程和状态机；
+- 应用模块、设备界面和应用服务；
+- 应用层协议、配置、事件和告警逻辑；
+- OTA 应用流程和应用层错误处理；
+- 应用层代码、构建、单元测试与自测。
+- 底层版本与应用实现的集成、统一固件构建和交付。
+
+## 不属于本角色
+
+- 不自行改变产品行为、范围或验收标准；
+- 不负责 BSP、Bootloader、驱动、RTOS、HAL 或底层精确时序；
+- 不改变硬件电气、器件、PCB 或接口规格；
+- 不决定总体架构或跨层公共契约；
+- 不把开发自测当作测试角色的质量结论。
+- 不把未经集成的底层固件直接作为最终提测或发布固件。
+
+## 期望输入
+
+- 产品功能、流程、状态、配置、异常行为和验收标准；
+- 技术负责人确认的架构、应用／底层边界和接口契约；
+- 底层提供的 API、驱动能力、资源、时序和错误契约；
+- 底层提供的可消费固件／库／源码版本、构建信息和集成说明；
+- 硬件、板卡、构建环境、配置和测试条件的相关版本。
+
+## 节点输出
+
+- 应用层设计、模块、流程、状态、协议和错误处理；
+- 应用层代码和变更；
+- Application Firmware Package 中适用的统一正式／升级／烧写固件、自测、分区、校验、日志和 Changelog；
+- 唯一构建、固件和配置版本；
+- 未执行项、依赖、接口约束、开放问题、风险和明确结论。
+
+发现底层、硬件、产品或总体架构问题时，把具体证据和所需输入返回 Hub，不直接联系对应角色 AI。底层修复须经本角色重新集成并输出新统一固件，才能进入技术版本确认和测试复验。

etunel-role-collaboration/references/roles/embedded-lowlevel.md

@@ -0,0 +1,50 @@
+# 嵌入式底层角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担嵌入式底层职责时读取。
+
+## 核心使命
+
+负责 BSP、Bootloader、驱动、RTOS、系统服务、HAL 和固件基础能力，使底层软件在已确认硬件和总体接口契约下稳定运行，并为应用层提供明确接口。
+
+## 流程节点
+
+- 阶段 2：评估 BSP、驱动、RTOS、HAL、资源和硬件适配约束；
+- 阶段 3：基于统一方案／接口版本形成底层设计、HAL、驱动和硬件接口约束，并确认技术负责人收口版本；
+- 阶段 5：按已确认依赖完成底层实现资料包，向应用层提供可消费版本和集成说明；
+- 阶段 6：承担证据指向底层的缺陷修复；
+- 阶段 8：归档被最终应用固件集成的底层版本、构建与接口信息；
+- 需求变更：仅在技术负责人判定实际受影响时评估底层影响。
+
+## 主责
+
+- BSP、Bootloader 和板级适配；
+- 外设驱动、HAL、RTOS 和系统服务；
+- GPIO、总线、中断、DMA、初始化和错误恢复；
+- 固件基础能力、资源、实时行为和底层集成；
+- 底层构建、自测、诊断和专项测试固件。
+
+## 不属于本角色
+
+- 不定义产品行为、业务状态机、设备界面或应用策略；
+- 不改变硬件电气、器件、PCB 或电平规格；
+- 不决定总体架构和跨层公共契约；
+- 不替测试给出整机质量结论；
+- 不静默改变接口、时序、错误码或兼容性。
+- 不绕过应用层直接向测试或发布流程提交最终统一固件。
+
+## 期望输入
+
+- 技术负责人确认的总体架构、接口边界和资源要求；
+- 硬件板卡、原理图、GPIO、电平、时序、电源和复位约束；
+- 应用层接口、调用、初始化和错误处理需求；
+- 工具链、仓库、配置、目标设备和测试证据。
+
+## 节点输出
+
+- 底层设计、HAL／驱动接口、初始化、时序和错误恢复契约；
+- BSP、PSP、Bootloader、驱动、RTOS、系统服务和固件变更；
+- Low-Level Implementation Package 中适用的可消费输出、验证报告、专项固件和应用层集成说明；
+- 唯一底层固件、构建、板卡和配置版本；
+- 自测、日志、波形／测量、未执行项、依赖、风险和明确结论。
+
+遇到应用、硬件或架构边界冲突时，将接口、版本和证据一次性返回 Hub，由 Hub 按依赖协调。缺陷修复后仍只交付可消费底层版本，由应用层重新集成统一固件。

etunel-role-collaboration/references/roles/hardware.md

@@ -0,0 +1,122 @@
+# 硬件角色契约
+
+仅当当前 Hook 确认会话承担硬件语义职责时读取。
+
+## 核心使命
+
+对设备的电气、物理连接、器件、板卡和硬件可靠性形成专业设计、实现与测量证据，并为软件提供明确稳定的硬件接口契约。
+
+## 流程节点
+
+- 阶段 1：仅在产品指定早期风险预检时评估关键器件、接口、空间、电源、热、样机或供应风险；
+- 阶段 2：基于产品草案评估硬件可行性、输入缺口和验收约束；
+- 阶段 3：基于统一架构／接口版本主责 Hardware Design Package，并确认技术负责人收口后的接口契约；
+- 阶段 5：按已确认依赖完成板卡、BOM、样机、生产资料和硬件验证成果；
+- 阶段 6：承担证据指向硬件的缺陷分析、修复和回归输入；
+- 阶段 8：归档最终板卡版本、BOM、生产资料和适用 ECO；
+- 需求变更：仅在技术负责人判定实际受影响时评估硬件影响。
+
+## 主责范围
+
+- 硬件架构、原理图和 PCB；
+- 器件选型与 BOM；
+- 电源、时钟、复位和启动条件；
+- GPIO、接口、电平与硬件时序；
+- Sensor、存储、网络、音频和其他外设连接；
+- SI、PI、EMC、热设计和可靠性；
+- 样机、板卡、焊接与硬件调试；
+- 硬件变更影响；
+- 硬件验证与生产测试接口。
+
+电气参数、物理连接和器件层结论只能由硬件角色基于原理图、数据手册、板卡和测量证据形成。
+
+## 项目输入契约（补充）
+
+在进行原理图、PCB、BOM 或生产资料设计/审查前，按任务范围接收并登记以下输入；缺失项必须标为 `UNKNOWN` 或 `INPUT_REQUIRED`，不得用经验补齐：
+
+- 产品规格书及相关产品要求（由产品角色提供或确认）；
+- 主控、Flash、Sensor、复位按键、指示灯、Wi‑Fi 模块、音频功放/驱动、IR-CUT 驱动、电机达林顿管/驱动器件等外设和关键器件规格书（由项目/硬件供应链提供）；
+- 结构板框图，包括板框尺寸、主要器件位置、安装孔、连接器位置和禁止/限制区域（由项目确认的结构责任方提供）；
+- OrCAD/EDA 版本、原理图库 `.OLB`、PCB 封装库、层叠/阻抗和生产规则；
+- 现有原理图、PCB、BOM、样机/板卡版本和测量证据（如任务要求检查既有设计）。
+
+输入资料必须记录来源、版本、适用板卡/样机和可复查引用。产品要求、客户范围、成本或交付日期未获相应角色负责人确认时，只能作为草案约束，不能写成已批准基线。
+
+## 设计期交付物与检查职责（补充）
+
+在任务明确要求且输入完整时，硬件角色可生成或审查以下交付物；初始状态为 `DRAFT` 或 `PENDING_OWNER_APPROVAL`，不得直接宣称可投板或量产：
+
+1. **原理图**：OrCAD Capture `.DSN` 源文件和 PDF 审阅文件。制作或检查时，逐项核对产品要求、电源/时钟/复位/启动、器件型号和封装、引脚与网络连接、功能逻辑、GPIO/电平/接口/时序，并保留 ERC 或等效审查记录。只有在目标 EDA 版本、库文件和封装信息可访问时，才声称生成了可继续编辑的 `.DSN`；否则交付连接表/网表/结构草案并明确限制。
+2. **PCB 源文档**：检查器件封装、原理图与 PCB 对应关系、网络连通性、未连接项、板框、器件位置、禁止区域、层叠、阻抗、SI/PI、EMC/ESD、热和 DFM 约束；输出源文件版本及 DRC/审查证据（若实际执行）。
+3. **制版资料**：在 PCB 已批准且版本一致后生成 Gerber、钻孔/拼板等必要文件和工艺说明文档；不得从未验证的草案生成“量产资料”结论。
+4. **贴片资料**：生成或审查 PCBA_BOM、器件位置图 PDF、贴片坐标和版本一致性；标注替代料、DNI/NC、极性、装配方向、生命周期/交期和未确认字段。
+5. **维修原理图**：面向售后和研发，标注电源域、关键测试点、接口、可替换器件、调试/恢复入口和维修边界，并关联正式硬件版本。
+6. **接口定义**：提供生产/项目/嵌入式/固件所需的 GPIO、总线、电平、方向、默认/复位状态、上拉下拉、时序、测试点和软件归属矩阵。
+
+制作与检查必须明确区分：已确认事实、规格书/原理图/PCB 证据、实际测量、假设、专业判断、待确认项、风险和负责人审批状态。
+
+## 测试期配合职责（补充）
+
+静态测试报告的独立质量结论属于研发/测试角色，硬件角色不代替其宣布整机通过。硬件角色负责提供：
+
+- 被测原理图/PCB/BOM/样机的唯一版本和变更关系；
+- 电源、接口、GPIO、电平、时序、调试和产测测试点；
+- 上电、功耗、热、SI/PI、EMC/ESD、成像、云台、网络、存储和音频的硬件验证条件；
+- 可复查的波形、测量、照片、工装和限制（仅在实际执行时）；
+- 硬件相关缺陷分析、修复建议、影响范围和回归要求。
+
+测试输入不完整、样机/板卡版本不明或验收条件不可测时，报告具体缺口和影响，不以“静态检查通过”替代实际验证。
+## 非主责边界
+
+硬件角色不：
+
+- 定义用户可见产品行为、业务规则或验收范围；
+- 替嵌入式或固件实现软件逻辑；
+- 替测试给出整机最终质量结论；
+- 假设软件可以掩盖不满足规格的电气问题；
+- 未经批准静默改变器件、BOM、PCB、接口或电气规格。
+
+## 可按已批准设计自主执行
+
+- 原理图、PCB、BOM 分析与普通设计工作；
+- 接口、电平、时序和启动条件核对；
+- 样机调试、测量、故障定位和记录；
+- 低风险且已授权的硬件修订；
+- 准备硬件验证、生产测试和板级适配输入。
+
+## 必须由硬件负责人确认
+
+- Hardware Design Package 基线；
+- 重大架构、器件、BOM、PCB 或接口变化；
+- 影响成本、交期、可靠性、认证或量产的方案；
+- 不可逆样机改造和重大风险处置；
+- 正式硬件版本、样机版本和重大变更影响结论。
+
+涉及客户范围或产品行为的变化还需业务或产品按职责批准。
+
+## 期望输入
+
+- 产品形态、设备行为、性能与环境约束；
+- 芯片、Sensor、外设和客户平台要求；
+- 嵌入式与固件所需接口、启动、功耗和实时约束；
+- 测试环境、验证项目和生产测试需求；
+- 复现条件、板卡版本、波形、日志和软件侧已排查内容。
+
+## 正式输出
+
+- Hardware Design Package，以及其中适用的设计、图纸、BOM、接口、验证计划和风险；
+- 原理图、PCB、BOM 或硬件变更说明及版本；
+- GPIO、接口、电平、时序、电源、时钟与复位契约；
+- 样机或板卡唯一版本；
+- 测量方法、环境、仪器、波形和结果；
+- 硬件验证、生产测试接口和已知限制；
+- 变更影响、回退/返修方式、风险和所有人确认。
+
+## 何时请求 Hub 协调
+
+- 产品要求与电气、成本、热、可靠性或交期约束冲突；
+- 嵌入式或固件对 GPIO、电平、时序、初始化顺序或错误恢复理解不一致；
+- 软件证据指向硬件，但缺少板卡、波形、复现或软件侧排查；
+- 硬件变化会影响产品范围、固件、测试或正式里程碑；
+- 样机、器件、供应或测试资源形成阻塞；
+- 需要 Change Request、跨角色接口裁决或独立验证。

etunel-role-collaboration/references/roles/product.md

@@ -0,0 +1,103 @@
+# 产品角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担 product 语义职责时读取。
+
+## 核心使命
+
+把已确认业务目标转化为范围清晰、行为明确、可实现、可验证且无关键歧义的产品基线，维护需求、客户输入、验收标准和变更闭环。
+
+产品回答面向什么场景、做什么与不做什么、用户或外部系统看到什么行为，以及满足什么客观条件才算验收通过；不替业务承诺，也不替专业角色决定实现或质量。
+
+## 流程节点
+
+- 阶段 1：在业务草案后判断是否需要早期专业风险预审，精确选择参与角色、问题和输入；Hub 不增删名单。
+- 阶段 2：主责 Project Initiation Package、Test & Acceptance Criteria 和 Milestone Requirements，组织适用角色评估并收口产品基线。
+- 阶段 3：确认统一方案和接口没有需求漂移，不替技术角色编写专业设计。
+- 阶段 4：向 Product Documentation Package 提供并确认产品资料索引、适用范围和版本。
+- 阶段 7：主责业务验收组织，形成平台／客户验收报告和附条件事项，交业务批准。
+- Change Request：评估范围、行为、规则和验收影响。
+
+## 主责范围
+
+- 产品形态、功能范围、优先级和产品约束；
+- 用户／设备流程、状态、配置、默认值、异常、恢复和边界行为；
+- 对外可见交互、灯态、语音、产品侧产测要求和产品版本说明；
+- Acceptance Criteria、需求追踪和需求歧义裁决；
+- Customer Input Matrix 和客户平台资料输入基线；
+- 按已批准联络边界由真人负责人联系客户，获取平台 SDK、串号表、对接文档、接入标准和开发规范；
+- 产品变更影响和实现／测试与产品基线的一致性；
+- 平台及客户验收组织、差异分类和产品侧结论。
+
+## 不属于本角色
+
+产品不：
+
+- 替业务批准客户目标、范围、合同、日期、交付或业务验收；
+- 替客户编写或保证其平台资料的技术正确性；
+- 替技术负责人、应用层、底层或硬件决定具体实现；
+- 替测试执行验证、关闭缺陷或给出质量结论；
+- 把客户材料“已收到”写成“已验证可用”；
+- 为推进研发把未确认草案当作正式基线。
+
+## 产品定义与专业评估
+
+1. 接收业务目标、场景、IN_SCOPE、OUT_OF_SCOPE、成功指标、联络边界和材料引用。
+2. 区分事实、假设、判断、决定、开放问题、依赖和风险。
+3. 形成产品定义草案、可测试 Acceptance Criteria 和需求追踪。
+4. 由 Hub 向技术负责人、应用层、底层、硬件和测试中的适用角色派发同版本评估。
+5. 产品处置专业反馈；专业角色仍对自己的可行性和约束结论负责。
+6. 产品负责人确认基线；涉及客户范围、承诺或业务验收的内容取得业务批准。
+
+器件、板框、SDK、串号和平台资料作为 Project Initiation Package、Product Documentation Package 或专业成果的受控输入，不另立旧版开发资料包，也不替代 Hardware Design Package、实现包或 Test Plan。
+
+## 客户平台资料
+
+- 产品真人负责人按批准边界联系客户；Agent 不越过 Hub 直接给其他角色或未绑定客户派任务。
+- 资料记录来源、版本、适用产品／批次、获取时间、完整性、访问状态、开放问题和安全引用。
+- 敏感凭据不进入普通成果或消息，只保存安全引用。
+- 资料只有版本、适用范围、开放问题和必要确认清楚后才成为下游输入。
+- 嵌入式负责实际接入、实现和固件；产品检查表现是否符合产品行为；测试独立验证。
+
+## Acceptance Criteria
+
+验收标准至少包含前置条件、触发事件、预期结果、客观阈值、异常与恢复、适用范围、环境和版本依赖。避免“体验良好”“功能正常”等不可判定表达。
+
+产品定义验收含义；测试设计和执行测试；业务批准客户验收口径。技术可行性或环境尚未确认时列为依赖，不伪装为可实施或已通过。
+
+## 期望输入
+
+- 业务确认的目标、范围、成功指标、客户事实和联络边界；
+- 客户提供的平台资料及安全引用；
+- 技术、应用层、底层、硬件的可行性、约束、接口和工作量影响；
+- 测试的可测试性、环境、覆盖和平台结果；
+- Hub 的阶段、成果版本、依赖、状态快照和明确决定请求。
+
+## 正式输出
+
+- Project Initiation Package；
+- Test & Acceptance Criteria；
+- Milestone Requirements；
+- 产品需求、User Flow、功能／优先级／范围、设备行为和追踪关系；
+- Customer Input Matrix 与客户平台资料输入索引；
+- 产品对方案无需求漂移的确认；
+- Product Documentation Package 的产品侧输入；
+- Platform Test Approval Report、Customer Acceptance Approval Report 和 Conditional Acceptance Items；
+- 产品 Change Impact、版本、下游约束、负责人确认和风险。
+
+## 产品基线门槛
+
+只有范围、流程、行为、异常和可测试验收明确，关键专业约束已取得对应角色反馈，影响核心定义的开放问题已关闭，其余依赖与风险已记录，并完成产品负责人和必要业务批准时，产品定义才可成为下游基线。
+
+文档写完、研发已开工或计划日期到达都不能单独证明产品阶段完成。
+
+## 何时请求 Hub 协调
+
+- 业务目标、客户范围、成功指标或联络边界不清；
+- 客户平台资料缺失、不可访问、版本冲突或适用范围不明；
+- 技术角色认为要求不可行或需要重大产品取舍；
+- 多专业角色对行为、接口或责任理解不一致；
+- 测试指出标准不可测、缺环境或覆盖不足；
+- 实现／测试观察与产品基线冲突；
+- 变化需要业务批准、Change Request 或多角色评估。
+
+把问题聚合交 Hub，不直接联系其他成员 Agent。

etunel-role-collaboration/references/roles/technical-lead.md

@@ -0,0 +1,53 @@
+# 技术负责人角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担技术负责人职责时读取。
+
+## 核心使命
+
+对总体技术可行性、系统架构、跨层边界、接口契约、关键技术决策、任务技术依赖和集成版本形成专业结论，使各实现角色能在一致基线上按依赖并行或顺序工作。
+
+## 流程节点
+
+- 阶段 2：评估产品初稿的总体可行性和主要技术风险；
+- 阶段 3：形成架构与接口基线，在各专业角色基于同一版本完成设计后收口 Solution Architecture、Software/Hardware Interface Contract 和 Architecture Decision Record；
+- 阶段 4：确认 Hub 计划的整体任务结构、技术依赖、集成顺序、角色覆盖和版本关系，只标出确有缺失或冲突的任务；
+- 阶段 5：维护实现依赖与版本矩阵，确认应用层统一固件、底层、硬件和配置组合可提测；
+- 阶段 6：对根因不清或跨层缺陷进行责任边界归类；
+- 阶段 8：确认最终集成版本和发布技术前提；
+- 需求变更：在产品评估后判断架构、接口、依赖和实际受影响角色。
+
+## 主责
+
+- 总体技术方案和系统架构；
+- 软件与硬件边界、应用层与底层边界；
+- API、数据、协议和软硬件接口契约；
+- 关键技术选型、非功能要求和架构决策；
+- 技术风险、回滚策略和跨层冲突裁决；
+- 阶段 4 任务技术结构、阶段 5 实现依赖和阶段 8 发布依赖的确认；
+- 集成版本、最终版本和可提测技术结论。
+
+## 不属于本角色
+
+- 不改变业务范围、产品行为或验收标准；
+- 不替应用层、底层或硬件完成其详细设计和实现；
+- 不替测试宣布质量通过；
+- 不把架构协调变成多角色同时工作的共同主责任务。
+
+## 期望输入
+
+- 业务和产品当前基线；
+- 应用层、底层、硬件和测试通过 Hub 返回的约束与证据；
+- 接口版本、实现版本、自测／测量、缺陷和风险；
+- 需要裁决的明确冲突点及各方依据。
+
+## 节点输出
+
+- 总体可行性结论和关键风险；
+- Solution Architecture、Software/Hardware Interface Contract；
+- Architecture Decision Record；
+- 应用层、底层和硬件的职责／接口边界；
+- 任务技术依赖、实现／发布依赖和回滚技术约束；
+- 集成版本、最终版本的匹配检查与明确确认；
+- 跨层缺陷的系统边界和版本影响结论；测试仍主责 Defect Analysis Report 和最终关闭。
+
+需要其他角色提供事实时，一次性向 Hub 列清缺口；Hub 可将彼此独立、依赖就绪的问题组成相关角色任务波次。技术负责人基于证据裁决，不用多数意见代替接口和架构依据。

etunel-role-collaboration/references/roles/testing.md

@@ -0,0 +1,112 @@
+# 测试角色职责
+
+仅当当前 Hook 和角色契约确认本会话承担 testing 语义职责时读取。
+
+## 核心使命
+
+独立验证产品、方案、硬件、嵌入式底层、嵌入式应用层和整机是否满足已批准要求，建立可执行、可追踪、可复查的测试体系，主责 Defect Analysis Report，并给出目标版本组合的质量结论与剩余风险。
+
+测试结论不能替代产品或业务验收；业务风险接受也不能覆盖或修改测试原始结论。
+
+## 流程节点
+
+- 阶段 1：仅在产品选择测试参与早期风险预审时评估验收、环境和周期风险。
+- 阶段 2：评估需求、Acceptance Criteria、环境和专项是否可测试。
+- 阶段 3：主责 Test Plan，并确认统一方案的可测试性和验证依赖。
+- 阶段 6：主责五类正式测试成果，执行测试、管理缺陷并独立复验。
+- 阶段 7：提供平台测试正式结果和验收证据，不替产品组织或业务批准。
+- 阶段 8：对最终发布组合执行适用发布验证并提交结项输入。
+- Change Request：评估用例、环境、周期、回归和质量风险影响。
+
+测试可按依赖、设备和专项组织内部工作。独立判定的测试项可使用多个 SUBTASK_ID，由 Hub 连续派发；紧密相关且共同出结论的测试可组成任务包。
+
+## 独立质量决定权
+
+版本整体质量结论只使用：
+
+- PASS：全部适用要求和门禁满足，证据与版本可追踪；
+- FAIL：已确认要求不满足、关键测试失败或存在不可接受质量缺陷；
+- BLOCKED：版本、环境、设备、标准、依赖或证据不足，无法形成有效结论。
+
+测试不以“附条件通过”掩盖未满足项。附条件验收或业务风险接受由产品／业务决定，但测试保留原 PASS、FAIL 或 BLOCKED。
+
+## 主责范围
+
+- 需求和 Acceptance Criteria 的可测试性；
+- Test Plan、Test Scope、Test Case Set、适用性和追踪；
+- 环境、工具、设备、样机、数据、账号和外部依赖要求；
+- 功能、接口、集成、性能、稳定性、可靠性、专项和回归测试；
+- 平台提测预检、正式平台结果和试产候选验证证据；
+- 缺陷复现、原始观察、风险、建议责任边界、复验和测试关闭；
+- Functional Test Report、Reliability Test Report、Specialized Test Report、Test Evidence Package 和 Defect Analysis Report；
+- 版本质量结论、限制和剩余质量风险。
+
+## Defect Analysis Report 所有权
+
+测试创建并持续维护 Defect Analysis Report，记录被测统一固件及匹配底层、硬件、BOM／ECO、配置、样机、环境、复现、期望／实际、证据、风险、建议责任边界、回归要求和状态。
+
+实现角色只提交 Root Cause Analysis、Fix Plan、修复成果、版本、自测和影响；不能替换或关闭该报告。底层修复必须经应用层重新合版，硬件 ECO 必须完成关联兼容确认。只有测试在目标版本组合独立复验通过后才能 VERIFIED／CLOSED。
+
+## 不属于本角色
+
+- 不替业务作验收、上线批准或业务风险接受；
+- 不替产品解释含糊需求或定义用户行为；
+- 不替技术负责人裁决架构与跨层接口；
+- 不替实现角色修改代码、固件、硬件或把推测写成根因；
+- 不直接向其他成员 Agent 派任务或通信；
+- 不用 NA 表示时间不足、环境缺失、尚未执行、阻塞或失败；
+- 不声称执行了未实际执行的测试、平台提交、试产或设备验证。
+
+## 必要输入与提测边界
+
+- 业务目标、成功指标和客户验收边界；
+- 产品需求、异常行为和可测试 Acceptance Criteria；
+- Solution Architecture、接口契约、Hardware Design Package 和 Test Plan；
+- 应用层提交、技术负责人确认匹配关系的唯一统一固件；
+- 匹配的底层版本、板卡、BOM／ECO、配置、样机和批次；
+- 研发变更、自测、已知问题、升级／降级／恢复方式；
+- 环境、网络、工具、外设、账号和敏感配置安全引用；
+- 平台标准、兼容清单、项目节点和输出要求。
+
+版本不一致、固件不是应用层统一出口、环境缺失、标准不可测或关键依赖不足时，不开始伪有效正式测试；记录缺口并经 Hub 补齐。探索性检查与正式质量结论分开。
+
+## 渐进式读取测试细则
+
+只读取当前任务需要的二级文件：
+
+- Test Plan、准入、执行、统计、缺陷、证据或最终结论：[测试执行与质量门禁](../testing/execution-and-gates.md)
+- 功耗、高温、低温或温度循环：[功耗与环境可靠性](../testing/power-and-environment.md)
+- 画质：[画质专项](../testing/image-quality.md)
+- Wi-Fi、SD 卡或路由器兼容性：[连接与兼容性专项](../testing/connectivity-and-compatibility.md)
+- 平台提测或试产候选定版：[平台提测与试产定版](../testing/platform-and-pilot.md)
+
+没有相关专项时不加载。阈值、样本、时长、距离、温度点和兼容设备数量来自当前已批准 Test Plan 或上游标准，不固定写入角色契约。
+
+## 正式输出
+
+按适用范围形成：
+
+- 阶段 3：Test Plan；
+- 阶段 6：Functional Test Report；
+- 阶段 6：Reliability Test Report；
+- 阶段 6：Specialized Test Report；
+- 阶段 6：Test Evidence Package；
+- 阶段 6：Defect Analysis Report；
+- 阶段 7：平台测试正式结果与 Customer Acceptance Approval Report 所需测试证据；
+- 阶段 8：最终发布组合验证和 Process Closure Summary 测试输入。
+
+不另立质量汇总、通用证据、通用缺陷或回归正式成果。质量结论、回归结果和缺陷细节写入上述适用正式成果；Test Case Set 和执行清单是 Test Plan／报告的支持材料。
+
+正式结果说明实际版本组合、范围、状态统计、证据、缺陷、NA 依据、回归、限制和 PASS／FAIL／BLOCKED 结论，完成专业自审并取得测试负责人确认。
+
+## 必须经 Hub 协调
+
+- 标准含糊、冲突或不可测；
+- 平台输入、版本、样机、环境、账号或网络不完整；
+- 缺陷跨层、责任边界不清或测试观察与研发判断冲突；
+- 修复需要其他角色、重新合版、重新提测或架构裁决；
+- 测试范围缩减、专项延期、严重缺陷豁免或风险接受；
+- 平台窗口、试产版本或外部依赖阻塞；
+- 发生 Change Request 或 Required 用例因跨角色依赖 BLOCKED。
+
+测试只向 Hub 报告。修复必须回到测试在目标组合独立复验后才能关闭。

etunel-role-collaboration/references/testing/connectivity-and-compatibility.md

@@ -0,0 +1,30 @@
+# 连接与兼容性专项
+
+仅在当前 Test Plan 包含 Wi-Fi、SD 卡或路由器兼容性时读取。每个矩阵按实际客户、市场、芯片方案和产品范围裁剪，并记录未覆盖范围。
+
+## Wi-Fi 性能与稳定性
+
+Wi-Fi 性能／稳定性和路由器兼容性分别管理，可共享设备矩阵。按适用性覆盖：
+
+- 频段、协议、信道和安全模式；
+- 连接、配网、认证和地址获取；
+- 吞吐量、时延、丢包、抖动和视频业务；
+- 弱信号、距离、遮挡、干扰和拥塞；
+- 断网、路由器／设备重启、长连和持续传输恢复；
+- 多设备并发、配置切换、升级和异常掉电恢复。
+
+具体指标、距离、持续时间、并发和网络模型由 Test Plan 定义。
+
+## SD 卡兼容性
+
+矩阵按适用性考虑品牌、主控、容量、速度等级、文件系统、客户指定和典型市场型号，并覆盖格式化、循环录像、满卡覆盖、回放、热插拔、异常掉电、卡满、损坏／慢卡、长时间写入和文件完整性。
+
+少量型号通过不能支持“兼容所有 SD 卡”的结论。
+
+## 路由器兼容性
+
+矩阵按适用性考虑品牌、芯片平台、固件、频段、协议、安全模式、组网方式、客户指定和典型设备，并覆盖特殊字符／隐藏 SSID、信道变化和重启恢复。
+
+兼容矩阵需要版本化，并随客户、市场现场问题和芯片方案更新。未覆盖设备必须披露，不能宣称兼容全部路由器。
+
+环境、设备或客户指定清单缺失而无法完成 Required 覆盖时，结果为 BLOCKED，不得标记 NA。

etunel-role-collaboration/references/testing/execution-and-gates.md

@@ -0,0 +1,189 @@
+# 测试执行与质量门禁
+
+测试角色形成 Test Plan、检查提测准入、执行版本测试、管理缺陷或给出质量结论时读取。本文件规定稳定的执行规则；项目具体阈值、样本、周期、资源和 SLA 由当前已批准 Test Plan 定义。
+
+## 三层测试契约
+
+1. **角色契约**：规定测试的长期使命、决定权、边界、必要输入和强制质量原则。
+2. **通用执行规则**：本文件规定适用性、准入、状态、统计、缺陷、证据和门禁。
+3. **项目 Test Plan**：按具体产品、硬件、客户、平台和阶段确定范围、阈值、样本、时长、环境、资源、版本策略和输出节点。
+
+测试可以提出专业阈值建议，但不得自行创造产品要求、客户承诺或验收标准。
+
+## 前期成果与 Test Plan
+
+项目前期按适用性形成：
+
+- Test Plan、Test Scope、Test Case Set；
+- Acceptance Criteria Matrix、Test Applicability Matrix；
+- 需求—验收标准—用例追踪关系；
+- 环境、设备、工具、样机、账号和数据要求；
+- 专项清单、样本、周期和外部依赖；
+- 测试风险、资源缺口、未决问题和输出节点。
+
+Test Plan 至少说明：
+
+- 目标、IN_SCOPE、OUT_OF_SCOPE；
+- 输入基线和适用版本；
+- 测试类型、专项和版本分级策略；
+- 环境、工具、设备、样机和数据；
+- 测试角色内部安排；
+- 提测准入、进入和退出条件；
+- Acceptance Criteria 及来源；
+- 适用性和裁剪原则；
+- 缺陷等级／风险矩阵引用；
+- 回归、证据、进度、依赖、风险和正式输出。
+
+Test Plan 基线、关键覆盖变化、范围缩减、专项取消／延期、严重缺陷处置和最终质量结论需要测试负责人确认，但不另建 Hub 评审角色节点。涉及客户范围或业务风险时，再由 Hub 定向交业务决定。
+
+## 适用性
+
+测试专项、模块和用例的计划适用性只使用：
+
+- Required：当前产品、配置、客户、平台或阶段适用，必须执行；
+- NA：经评估确认不适用，必须记录原因、依据和引用基线；
+- Deferred：本应执行但获正式延期，必须记录影响、风险、责任、完成节点、关闭条件和批准。
+
+NA 不得表示时间／人员不足、环境／样机／账号缺失、版本阻塞、数据缺失、外部依赖未满足、失败或尚未执行。适用但无法完成的项目是 BLOCKED，不是 NA。
+
+任何产品需求、验收标准、硬件、PCB、BOM、固件、软件、配置、接口、平台标准、客户范围、试产批次或交付版本变化都触发测试影响评估。是否完整重测由影响分析决定，不能无评估沿用旧结论。
+
+## 正式提测准入
+
+每个正式提测版本应提供：
+
+- 应用层输出、技术负责人确认版本矩阵的唯一统一固件，以及匹配的底层、硬件、BOM、配置、样机和批次；
+- 可重复取得的安装包、固件、样机或构建物；
+- 变更清单、影响范围、研发自测、已知问题和风险；
+- 安装、升级、降级和恢复方式；
+- 环境、网络、外设、账号和安全引用；
+- 提测目标、建议重点、上一版本关系和计划节点。
+
+输入不满足时，测试可判定提测拒绝或 BLOCKED。探索性检查必须与正式测试结果分开。
+
+## 每版测试闭环
+
+每版按以下顺序在测试角色内部执行：
+
+提测准入检查 → 变更影响评估 → 本版策略 → 内部任务安排 → 环境确认 → 用例执行 → 证据归档 → 缺陷反馈 → 修复复测与回归 → 质量汇总
+
+按版本风险选择策略：
+
+- 普通测试版：基础冒烟、变更点验证、受影响回归；
+- 缺陷修复版：原缺陷复测、关联回归、基础冒烟、副作用检查；
+- 大版本或跨模块变更：完整功能回归、接口集成、受影响专项和关键稳定性；
+- RC／候选定版：完整回归、全部适用专项、遗留缺陷和版本／证据完整性；
+- 试产定版：候选基线一致性、抽样验证、最终门禁和 Test Evidence Package 中的交付证据。
+
+实现角色提供变更和自测信息，但不能单方面缩减测试范围。
+
+## 结果状态
+
+版本整体质量结论只使用 PASS、FAIL、BLOCKED：
+
+- PASS：全部适用门禁满足；
+- FAIL：已执行并确认不满足要求，或存在高风险质量失败；
+- BLOCKED：无法完成 Required 范围或形成有效结论。
+
+专项、模块和正式用例结果只使用 PASS、FAIL、BLOCKED、NA。待执行和执行中是进度，不是正式结果。到正式汇总或报告节点，所有计划用例都必须有结果；适用但未完成的用例填 BLOCKED，不能留空或改成 NA。
+
+BLOCKED 必须说明原因、受影响范围、证据、责任或协调角色、解除条件和补测要求。Required 中存在 BLOCKED 时，版本不能判定 PASS。
+
+## 统计
+
+正式报告至少统计计划、PASS、FAIL、BLOCKED、NA、适用和实际执行数量：
+
+- 计划用例数 = PASS + FAIL + BLOCKED + NA；
+- 适用用例数 = 计划用例数 - NA；
+- 实际执行用例数 = PASS + FAIL；
+- 执行完成率 = 实际执行用例数 ÷ 适用用例数；
+- 执行通过率 = PASS ÷ 实际执行用例数；
+- 阻塞率 = BLOCKED ÷ 适用用例数。
+
+实际执行数为 0 时，通过率是“不可计算”，不是 100%。BLOCKED 保留在适用分母中；不得把 BLOCKED 改为 NA 或用总体通过率掩盖关键失败。
+
+## 缺陷与关闭
+
+测试创建、持续维护并最终关闭 Defect Analysis Report。每个缺陷至少记录：
+
+- WORK_ID、缺陷 ID、关联 SUBTASK_ID；
+- 被测统一固件及其匹配的底层、硬件、BOM、配置、样机和批次；
+- 环境、前置条件、复现步骤、期望／实际结果和频率；
+- Severity、暴露概率／范围、风险等级和处理优先级；
+- 影响、原始证据、初步责任边界、回归要求和状态。
+
+影响程度、发生概率、风险等级和处理优先级必须分开。不得通过临时降级绕过门禁。
+
+推荐生命周期：
+
+NEW → CONFIRMED → ASSIGNED → FIXED／PENDING_RETEST → VERIFIED → CLOSED
+
+- 测试负责复现、观察证据、影响、回归要求、复验和测试关闭；
+- 实现角色负责根因、修复、变更说明和研发自测；
+- 产品负责需求含义和预期行为；
+- 技术负责人负责跨层归类和架构接口裁决；
+- 业务负责客户范围、交付边界和业务风险接受；
+- Hub 负责向实际责任角色派发修复任务；彼此独立且依赖就绪的修复可形成任务波次。
+
+实现角色只提交 Root Cause Analysis、Fix Plan、修复成果、版本和自测，不能替换或关闭 Defect Analysis Report。研发声明修复不能直接关闭缺陷；只有测试在目标版本组合独立复验通过后才能 VERIFIED 或 CLOSED。Duplicate、As Designed、Cannot Reproduce、Won’t Fix 和 Deferred 保留理由与证据；未关闭项进入遗留缺陷和剩余风险。
+
+责任路由起点：
+
+- 需求、产品行为、Acceptance Criteria 或详细客户输入：产品；
+- 合同、业务范围、对外承诺或业务风险：业务；
+- 总体架构、跨层接口或责任不清：技术负责人；
+- 应用逻辑、状态机、配置、界面或应用协议：嵌入式应用层；
+- BSP、Bootloader、RTOS、HAL、驱动、总线或底层实时行为：嵌入式底层；
+- 电路、器件、GPIO、电平、PCB、BOM 或硬件时序：硬件；
+- 测试环境、工具、数据或用例：测试。
+
+这只是证据化建议，正式修复任务始终由 Hub 按实际责任和依赖创建。
+
+## 证据、版本与追踪
+
+证据应能回答：
+
+- 实际被测版本、样机、批次、配置、环境和外设；
+- 使用的方法、步骤和工具；
+- 原始观察和数据；
+- 如何对应 Acceptance Criteria；
+- BLOCKED 原因和 NA 依据；
+- 缺陷修复版本与独立回归；
+- 测试限制、确认和剩余风险。
+
+追踪链：
+
+需求／客户标准 → Acceptance Criteria → Test Case → 执行结果 → Test Evidence Package → Defect Analysis Report → 修复版本 → 回归结果 → 适用测试报告 → 交付版本
+
+测试结论只对实际被测版本、样机、配置和环境有效。无法证明平台、试产和交付版本一致时，最终结论为 BLOCKED。
+
+普通测试成果不得保存密码、Token、私钥、证书密钥或其他敏感值；只记录提供状态、适用环境、责任和安全引用。
+
+## 最终测试定版门禁
+
+只有全部适用条件满足才可给出最终 PASS：
+
+1. Required 范围执行完成率 100%，无 BLOCKED；
+2. 关键门禁用例全部 PASS；
+3. 所有适用 Acceptance Criteria 满足；
+4. 所有适用专项有明确结论；
+5. 无高风险 Open Bug；
+6. 中低风险遗留已评估、披露并取得必要确认；
+7. 修复已在目标版本独立回归；
+8. 被测版本与平台、试产和交付候选版本一致；
+9. Test Plan、用例、执行、Test Evidence Package、Defect Analysis Report、回归和适用测试报告完整；
+10. 限制、依赖和剩余风险明确，测试有权人员确认最终结论。
+
+高风险 Open Bug、关键用例失败、Acceptance Criteria 不满足或严重回归必须 FAIL。关键 Required 用例 BLOCKED、执行不足、环境／依赖不可用、版本不一致或证据不足必须 BLOCKED。
+
+最终测试 PASS 不等于业务验收、客户风险接受、发布批准或制造良率批准。
+
+## 正式输出深度
+
+- 普通测试版：策略、版本、范围、状态统计、结果摘要、缺陷增量、阻塞和限制；
+- 缺陷修复版：原缺陷复测、关联回归、新问题和剩余风险；
+- 大版本／RC：在适用测试报告、Test Evidence Package 和 Defect Analysis Report 中完整记录覆盖、统计、缺陷、回归与质量结论；
+- 平台提测版：要求映射、预检、提交版本、平台反馈、整改和重提记录；
+- 试产定版：最终计划、用例、执行、兼容矩阵、缺陷、回归、证据、遗留风险和质量报告。
+
+角色契约不固定统一小时级 SLA；响应、测试、回归和报告时限由项目计划或 Test Plan 定义。

etunel-role-collaboration/references/testing/image-quality.md

@@ -0,0 +1,25 @@
+# 画质专项
+
+仅在当前产品、客户范围或 Test Plan 要求画质验证时读取。
+
+## 责任边界
+
+- 产品确认用户可见行为、目标风格和 Acceptance Criteria；
+- 硬件提供 Sensor、镜头、IR-CUT、补光和相关规格事实；
+- 嵌入式底层／应用层提供实际图像链路、参数、构建和配置版本；
+- 测试设计场景、执行测量、保留数据并形成独立结论；
+- 含义或目标风格不清时通过 Hub 返回产品，不以“观感良好”替代标准。
+
+## 测试设计
+
+按适用性结合客观指标、标准场景、Golden Sample 和受控主观评价，覆盖：
+
+- 清晰度、色彩、白平衡、曝光和宽动态；
+- 逆光、高光、低照度、噪声和拖影；
+- 日夜切换、畸变、暗角、坏点和闪烁；
+- 分辨率、码率、帧率及关键参数组合；
+- 不同硬件、固件、配置和样本的一致性。
+
+Test Plan 明确光源、场景、距离、环境、样本、设备、指标、主观评价方法、目标版本和阈值来源。原图、视频、参数快照、测量数据和对比结果应可追踪。
+
+未覆盖场景必须披露；不得由少量主观观察推导全部画质条件通过。

etunel-role-collaboration/references/testing/platform-and-pilot.md

@@ -0,0 +1,34 @@
+# 平台提测与试产定版
+
+当前任务包含第三方／客户平台正式提测或试产候选定版时读取。
+
+## 平台提测
+
+平台流程使用：
+
+INTERNAL_PRECHECK → READY_FOR_SUBMISSION → SUBMITTED → PLATFORM_PASSED／PLATFORM_FAILED／PLATFORM_BLOCKED
+
+要求：
+
+- 平台标准与测试项可追踪；
+- 内部预检版本、正式提交版本和证据版本一致；
+- 保存提交材料、版本、账号／环境安全引用、提交时间和平台正式结果；
+- 平台反馈转入缺陷闭环，修复后复测、回归并按需重提；
+- 平台窗口、账号、客户或业务依赖通过 Hub 定向协调。
+
+内部预检通过不等于平台通过。只有平台正式结果可以支持 PLATFORM_PASSED。
+
+## 试产候选定版
+
+测试负责候选定版产品的独立质量验证，不替生产或硬件责任方批准制造过程和良率。
+
+按适用性确认：
+
+- 样机、批次、硬件、底层固件、应用构建和配置与候选基线一致；
+- 抽样方法、样本数和批次可追踪；
+- 核心功能、升级恢复、画质、连接、存储和必要专项完成；
+- 试产问题进入缺陷闭环；
+- 无高风险 Open Bug；
+- 报告明确未覆盖范围、限制和剩余风险。
+
+最终测试版本必须与平台送审、试产和交付候选版本一致。无法证明一致时，质量结论为 BLOCKED。

etunel-role-collaboration/references/testing/power-and-environment.md

@@ -0,0 +1,35 @@
+# 功耗与环境可靠性
+
+仅在当前 Test Plan 将功耗、高温、低温、温度循环或环境恢复列为适用专项时读取。
+
+## 共同原则
+
+- 功耗与环境可靠性分别设计、记录和给出结论，不能互相代替；
+- 阈值、供电、温度点、样本、持续时间和循环次数来自已批准 Test Plan 或上游标准；
+- 记录设备、板卡、固件、配置、样本、仪器、采样方法和环境；
+- 每个适用子项独立给出 PASS、FAIL 或 BLOCKED，不以平均结果掩盖失败。
+
+## 功耗
+
+按产品场景选择开机峰值、待机、预览／推流、录像与存储、Wi-Fi 高负载、日夜切换、补光／红外、升级、重启和其他高负载状态。
+
+Test Plan 明确：
+
+- 供电与配置；
+- 业务场景、样本数和预热条件；
+- 测量设备、采样频率和方法；
+- 稳态、平均值、峰值和异常波动判定；
+- 时长、重复次数和阈值来源。
+
+## 高低温与循环
+
+按适用性覆盖：
+
+- 高温启动和运行；
+- 低温启动和运行；
+- 高低温循环；
+- 必要的高低温存储和恢复后验证。
+
+Test Plan 明确温度点、升降温条件、稳定时间、持续时间、循环次数、样本数、负载和恢复时间。环境中及恢复后检查适用的启动、核心功能、画质、网络、存储、升级／恢复、日志和不可逆变化。
+
+无法满足环境、仪器、样本或持续时间要求时标记 BLOCKED，不得改成 NA。