diff --git a/AGENTS.md b/AGENTS.md index 771099f..e394a18 100644 --- a/AGENTS.md +++ b/AGENTS.md @@ -6,7 +6,7 @@ - `etunel-role-collaboration/`：供各角色按需读取的渐进式披露 Skill； - `etunel-role-hook-contexts/`：供 Etunel 独立配置的八角色精简 Hook 上下文； -- `doc/`：流程设计基线和历史资料； +- `doc/`：当前流程设计基线和模板参考资料； - 钉钉参考集成：仅帮助 Hub 理解如何调用辅助通知，不属于 Etunel 任务通信主链路。 这是以 Markdown、HTML 和 Shell 为主的约束仓库，没有需要猜测的安装或构建步骤。 @@ -19,11 +19,11 @@ 1. 先读根 Skill：[etunel-role-collaboration/SKILL.md](etunel-role-collaboration/SKILL.md)。 2. 只按其中的条件路由读取本次修改涉及的 reference，不要一次加载所有角色和测试细则。 -3. 当前本地定版文档为 [V1.0 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于用户已确认的 V0.16 全文生成，不新增角色或流程规则。V0.15、V0.16 HTML 保留原文件；本地文档定版不表示已发布 Git、部署 Skill／Hook 或替换在途项目基线。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。旧版流程用于追溯；已在运行的项目继续使用其登记基线，迁移须明确确认。 +3. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。`doc/` 只维护当前流程文件和配套参考，不再按日期或版本复制文档；后续直接更新同一文件，历史通过 Git 提交追溯。仓库更新不等于部署 Skill／Hook 或迁移在途项目；已运行项目继续使用其登记基线，迁移及插件缓存更新须明确确认。 4. 运行时 Hook、Etunel 工具 schema、项目角色契约、成员登记及已确认的项目流程基线，高于 Skill 的通用说明。发现冲突时说明冲突，不要自行猜测或发明能力。 5. 保留用户已有改动；修改前后检查 Git 状态与差异。 -不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；版本文件只作为设计来源和追溯依据。 +不要让运行时 Skill 依赖某个带版本号的流程图或提示词文件。应把已确认且仍有效的规则整理为稳定约束，并放入正确的渐进式 reference；流程文档只作为设计来源，历史以 Git 提交追溯。 ## 必须保持的协作边界 @@ -47,7 +47,7 @@ | `etunel-role-collaboration/references/roles/` | 七个成员角色的职责契约 | 角色专属决定、输入、输出和边界写在对应文件 | | `etunel-role-collaboration/references/testing/` | 测试角色二级细则 | 只保留匹配任务时才需要的深层内容 | | `etunel-role-hook-contexts/` | 八角色 Hook 的完整精简职责与每轮提醒 | 独立于 Skill 发现树；简短、可直接注入、与正式职责一致 | -| `doc/` | 已确认流程来源及历史版本 | 不把历史版本误写成当前规则；新增基线时明确其状态 | +| `doc/` | 当前流程来源及模板参考 | 固定路径维护一份当前文档；不建日期或版本副本，历史查 Git；变更同步核对链接与基线说明 | | `.agents/skills/dingtalk-*` | 钉钉官方能力的项目内参考副本 | 不是 Etunel 核心 Skill；除非任务明确要求更新参考包，否则不要批量改动 | | `.dingtalk/`、`scripts/dingtalk-progress` | Hub 通知接入说明、示例配置和当前演示封装 | 不把通知能力扩大为任务派发、审批、门禁或事实源 | diff --git a/README.md b/README.md index 671258f..ff6e539 100644 --- a/README.md +++ b/README.md @@ -8,7 +8,7 @@ 1. [主 Skill](etunel-role-collaboration/SKILL.md) 是角色 AI 的统一入口，只保留共享硬约束和条件路由；详细职责按当前任务逐层读取。 2. [Hook 上下文](etunel-role-hook-contexts/) 是给 Etunel 单独配置的精简提醒，不属于 Skill 的渐进式发现树，也不应替代完整职责文件。 -3. 当前本地定版文档为 [V1.0 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)（CURRENT，文档生效日期 2026-09-08），基于已确认的 V0.16 全文生成，保留原有流程与灯态“配网”修正。V0.15、V0.16 历史文件保留；文档定版不代表已推送、部署 Skill／Hook 或自动迁移在途项目。未经用户再次通知，不提交、不推送、不合入主分支，也不自动更新已安装的插件缓存。运行时规则已整理进稳定 reference，不要求目标项目持有版本 HTML。 +3. 当前设计基线为 [V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)（文档生效日期 2026-09-08）。流程文档只维护一份，后续直接更新同一文件，旧版通过 Git 历史追溯，不再按日期或版本另存。仓库更新不代表部署 Skill／Hook 或自动迁移在途项目；运行时规则已整理进稳定 reference，不要求目标项目持有流程 HTML。 仓库没有应用安装、编译或发布流程。主要工作是维护角色约束、流程文档、Hook 上下文以及 Hub 通知参考集成。 @@ -47,7 +47,7 @@ flowchart LR | 角色 | 主要定位 | | --- | --- | | 项目Hub | 建立项目、维护状态、规划任务波次、校验交付结构、协调阻塞并完成跨角色中继 | -| 业务 | 形成商业需求、客户与授权信息、业务验收及发布结项输入 | +| 业务 | 形成业务需求、客户与授权信息，确认客户验收及复盘结项 | | 产品 | 把业务需求转化为产品定义、范围、交互和验收标准 | | 技术负责人 | 负责总体技术方案、接口与跨技术域设计协调 | | 嵌入式应用层 | 负责应用层软件设计、实现、联调和对应成果 | @@ -74,6 +74,7 @@ EP-Hub-Skill/ │ ├── project-lifecycle.md # 八阶段、成果和门禁 │ ├── project-status-and-membership.md │ ├── etunel-message-lifecycle.md +│ ├── document-templates.md # 模板复用与审核边界 │ ├── artifacts-and-evidence.md │ ├── exceptions-and-coordination.md │ ├── human-readable-communication.md @@ -82,7 +83,9 @@ EP-Hub-Skill/ │ ├── roles/ # 七个成员角色职责 │ └── testing/ # 测试任务按需读取的二级细则 ├── etunel-role-hook-contexts/ # 八角色独立 Hook 源文件 -├── doc/ # 当前设计基线和历史流程资料 +├── doc/ # 当前设计基线与模板参考，历史由 Git 保存 +│ ├── Codex多角色项目推进总流程图.html # 当前 V1.0，后续原位更新 +│ └── 文档模板参考/ # 按任务读取的参考笔记与来源清单 ├── .agents/skills/dingtalk-*/ # 钉钉官方能力参考副本，不是核心 Skill ├── .dingtalk/ # 通知接入说明与无秘密示例配置 └── scripts/dingtalk-progress # Hub 钉钉通知的当前演示封装 @@ -128,7 +131,7 @@ Etunel 为角色会话配置本 Skill 后，角色 AI 应按以下顺序工作 [etunel-role-hook-contexts/](etunel-role-hook-contexts/) 为八个默认角色各提供一份“精简职责与每轮提醒”。它们适合由 Etunel Hook 在每轮会话中注入，用来持续提醒身份、边界、负责人参与和工具使用。 -本轮先同步远程 `main` 的 Hook 提醒（`0b133bf`），保留“完整职责 JSON + 每轮精简提醒”结构；职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。本地源文件修改不会自动写入已安装插件或 Etunel 配置。 +每份 Hook 文档分为“完整职责 JSON”和“每轮精简提醒”两个独立配置区块，分别复制到 Etunel 对应字段。职责 JSON 不是接口请求，实际绑定与工具参数仍以 Etunel 为准。仓库源文件修改不会自动写入已安装插件或 Etunel 配置。 Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel 独立配置，因此不需要从 `SKILL.md` 中发现；修改角色边界时，应同时检查对应角色 reference 与 Hook，避免两套规则漂移。 @@ -151,7 +154,7 @@ Hook 文件需保持短小，并与完整 Skill 职责一致。它们由 Etunel ## 修改项目的推荐流程 1. 阅读 [AGENTS.md](AGENTS.md) 和本次变更涉及的最小文件集合。 -2. 若变更来自流程设计，核对 [V1.0 CURRENT 总流程图](doc/20260908/Codex多角色项目推进总流程图-V1.0.html)；保持历史 HTML 不变，不把本地文档定版或规则更新当作远程发布、部署或在途项目自动迁移。 +2. 若变更来自流程设计，核对 [当前 V1.0 总流程图](doc/Codex多角色项目推进总流程图.html)，在固定文件上修改并通过 Git 提交记录变更；不要新增日期目录或旧版副本。部署及在途项目迁移另行确认。 3. 把共享规则放在公共 reference，把角色专属规则放在对应角色文件，把低频测试细节放在测试二级 reference。 4. 只有必须让所有角色立即知道的规则才进入根 `SKILL.md`；同时保持条件路由可发现。 5. 同步检查受影响的 Hook 文件，并验证链接、结构和 Shell 语法。 @@ -183,13 +186,9 @@ bash -n scripts/dingtalk-progress ## 设计资料 -- [当前本地定版 V1.0（CURRENT）](doc/20260908/Codex多角色项目推进总流程图-V1.0.html) -- [保留的评审版本 V0.16（REVIEW）](doc/20260907/Codex多角色项目推进总流程图-V0.16.html) -- [保留的总流程图 V0.15](doc/20260904/Codex多角色项目推进总流程图-V0.15.html) -- [历史总流程图 V0.14](doc/20260902/Codex多角色项目推进总流程图-V0.14.html) -- [补充与历史追溯：项目Hub系统提示词 V0.13](doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt) -- [历史总流程图 V0.13](doc/20260828/Codex多角色项目推进总流程图-V0.13.html) -- [历史总流程图 V0.4](doc/20260827/Codex多角色项目推进总流程图-V0.4.html) +- [当前总流程图 V1.0](doc/Codex多角色项目推进总流程图.html) +- [文档模板参考](doc/文档模板参考/README.md) +- 历史流程与变更说明通过 `git log --all -- doc/` 查询，不在工作目录保留旧版副本。 - [核心 Skill](etunel-role-collaboration/SKILL.md) - [Hub 工作流](etunel-role-collaboration/references/hub-workflow.md) - [项目生命周期](etunel-role-collaboration/references/project-lifecycle.md) diff --git a/doc/20260827/Codex多角色项目推进总流程图-V0.4.html b/doc/20260827/Codex多角色项目推进总流程图-V0.4.html deleted file mode 100644 index 9ca980a..0000000 --- a/doc/20260827/Codex多角色项目推进总流程图-V0.4.html +++ /dev/null @@ -1,933 +0,0 @@ - - - - - - - - Codex 多角色项目推进总流程图与信息流图谱｜V0.3 - - - -
-
-
CODEX MULTI-ROLE PROJECT FLOW · V0.3
-

项目推进总流程图

-

以业务、项目、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试八类角色为基础，其中项目角色由中心 AI 承担；通过正式成果、角色内部确认门和中心服务路由，推进项目从需求到发布结项。

-
-
- -
-
-
-
-

从业务需求到发布结项

-

主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。

-
-
- 白色卡片＝项目阶段 - 黄色门＝角色/阶段确认 - 红色虚线＝返工回路 -
-
- -
-
-
01
-

业务需求

主责：业务
-
明确问题与价值。补齐业务目标、范围、规则、优先级和可度量成功指标。
-
正式成果Project Background Brief（项目背景说明）
客户信息：客户名称、最终客户名称
项目名称：统一名称或客户规定的项目代号
产品要求：产品形态、提测平台
项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景：客户为什么提出这个需求，要解决什么问题
商业目标：获取订单、维护客户、降低成本、拓展市场或形成标准产品
预期价值：预计订单量、销售额Project Milestone Plan（项目目标与里程碑计划）
提测时间
入库时间
小批量试产时间
量产时间
-
-
业务确认需求基线
- -
-
02
-

产品定义

主责：产品 · 批准：业务
-
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。
-
正式成果Project Initiation Package（立项资料）
立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能
灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息
结构板框图：包含主要器件位置和禁止限制区域Hardware Development Package（硬件开发资料）
外设器件和关键器件规格书：主控、Flash、Sensor、复位按键、指示灯、WiFi 模块、音频功放驱动芯片、IR-CUT 驱动芯片、电机达林顿管驱动芯片
结构板框图：包含主要器件位置和禁止限制区域Embedded Development Package（嵌入式开发资料）
平台 SDK
串号表
平台对接文档
平台接入标准及开发规范Test & Acceptance Criteria（测试验收标准）
平台测试用例
客户验收测试用例和验收标准Milestone Requirements（里程碑要求）
提测时间
客户验收时间
试产、量产时间
-
-
产品确认方案，业务批准范围
- -
-
03
-

项目规划

主责：中心 AI
-
基于成果、成员能力和依赖自动编排任务、进度和风险。任务计划草案先由技术负责人确认；中心 AI 只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。
-
正式成果Project Plan（项目计划）
项目任务拆分
实际项目排期Risk Register（项目风险）
技术风险
时间风险
其他风险Role Assignment（角色分工）Product Documentation Package（产品资料整合）Project Status Record（项目状态内部记录）
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
-
-
技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认资源与日期基线
- -
-
04
-

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
-
技术负责人统一组织总体方案设计和确认。
技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件：原理图、PCB、BOM、电源/信号/热设计测试：范围、环境、用例、通过标准
-
正式成果Solution Architecture（总体技术方案）Software/Hardware Interface Contract（软硬件接口契约）Hardware Design Package（硬件设计包）Architecture Decision Record（架构决策记录）Test Plan（测试计划）
-
-
技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证
- -
-
05
-

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件
-
嵌入式应用层、嵌入式底层和硬件在已确认总体方案及软硬件接口契约下并行实现、样机调试和自测。嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口或器件约束发生重大偏离时返回技术负责人确认。
-
正式成果Hardware Implementation Package（硬件实现资料）
原理图：DSN 源文档和 PDF 文档
PCB：源文档
贴片资料：PCBA BOM、器件位置图 PDF、贴片坐标
维修原理图
接口定义
静态测试报告Low-Level Implementation Package（嵌入式底层实现资料）
硬件功能测试报告
BSP 输出路径
PSP 输出路径
WiFi 设备定频测试固件Application Firmware Package（嵌入式应用层固件包）
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
日志文件
Changelog
串口使能证书
-
-
嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配
- -
-
06
-

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件
-
执行功能、接口、软硬件集成和回归测试。
不通过应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人
通过质量报告 + 测试证据包
-
正式成果Functional Test Report（功能测试报告）
平台测试用例
内部测试用例Reliability Test Report（可靠性测试报告）
高低温测试
跌落测试Specialized Test Report（专项测试报告）
画质测试
WiFi 测试
功耗测试
长稳测试
试产一致性测试Test Evidence Package（提测佐证）Defect Analysis Report（缺陷分析报告）
-
-
测试确认质量结论和剩余风险
- -
-
07
-

业务验收

主责：产品
-
依据成功指标、验收标准和质量证据作最终判断。
驳回需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试
通过形成正式业务验收结论，进入发布准备
-
正式成果Platform Test Approval Report（平台提测通过报告）Customer Acceptance Approval Report（客户验收通过报告）Conditional Acceptance Items（附条件验收事项）
-
-
业务批准验收结论和上线条件
- -
-
08
-

发布结项

中心 AI 协调 · 技术负责人确认 · 嵌入式应用层/嵌入式底层/硬件执行 · 测试验证
-
检查应用、固件、板卡版本、BOM/ECO、发布清单、冒烟、回滚和遗留事项承接。中心 AI 汇总复盘并归档角色会话。
-
正式成果Closure Documentation Archive（结项资料归档）
形成最终结果的流程文件Change Log（变更记录）Closure Report（结项报告）Process Closure Summary（流程闭环总结）
-
-
- -
- 贯穿全流程：Change Request（需求变更申请） -

任何角色都可提出变更；中心 AI 自动组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，业务批准后更新对应基线，并从受影响阶段继续推进。

-
-
- 成果适用性：Artifact Waiver（成果文件豁免） -

阶段成果默认必须由主责角色输出；仅当主责角色提交不适用申请、中心 AI 完成项目级适用性与影响审查并取得必要确认后，才能将该成果标记为 WAIVED。未批准的成果仍为 REQUIRED，并继续阻塞阶段门禁。

-
-
- -
-
-
STAGE INFORMATION FLOW ATLAS · V0.3
-

各阶段角色信息流图谱

-

以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

-
- 通用规则01 业务需求02 产品定义03 项目规划04 方案设计05 软硬件实现06 测试验证07 业务验收08 发布结项变更与异常成果豁免 -
-
-
-
-
00 / RULES
-

所有阶段共同遵守的流转规则

角色可以直接讨论，但讨论不能自动成为项目事实；正式结论必须回到中心 AI，经过校验、登记和重新分发。

-
-
唯一正式路径：触发事件 → 主责角色内部完成 AI 辅助自审与人工确认 → 以统一角色主体提交中心 AI → 中心 AI 做形式校验、版本/证据检查和跨角色冲突检查 → 路由目标角色 → 目标角色内部确认后形成正式结果 → 中心 AI 登记与分发下游 → 更新门禁。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。
-
成果默认 REQUIRED：主责角色必须输出；确认不适用时必须走 Artifact Waiver 流程。只有 APPROVED 的 WAIVED 状态可以替代成果满足门禁，任何角色都不得静默删除或跳过文件。
-
- 中心 AI业务产品技术负责人嵌入式应用层嵌入式底层硬件测试 -
-
- - - -
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付。不能替其他角色作出专业确认。
业务是；同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外，负责确认计划基线、真实资源、预算、采购/打样、日期、暂停/取消和高影响成果豁免。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
中心 AI是；承担项目角色项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和低影响豁免；高影响事项必须升级给业务。不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。
-
-
任意角色
G.1提交已完成内部审查确认的消息、成果或请求附 self_check_result、internal_approved、项目、任务、版本和证据引用
中心 AI
-
中心 AI
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
-
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录
中心 AI
-
-
项目状态内部记录与按需同步：Project Status Record（项目状态内部记录）是中心 AI 持续维护的内部运行记录，不是新增角色。它汇总当前阶段、门禁、任务、依赖、阻塞、风险、决策、成果基线、下一步和时限；中心 AI 在关键状态变化时主动推送，也响应角色按项目、阶段或任务发起的查询。
-
-
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态指定 project_id、stage/task scope、关注项和期望时点
中心 AI
-
中心 AI
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回
请求角色及受影响角色
-
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
中心 AI
-
中心 AI
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前项目、阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。任意角色 → 中心 AIproject_id、请求范围、关注字段、所需详细度、as_of 要求和用途。只能查询项目授权范围内的信息；请求角色无需知道中心 AI 的内部存储结构。创建一次按需状态查询。
S.2收到 S.1；或阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线、required_by 发生关键变化。中心 AI → 请求角色及受影响角色Project Status Snapshot：project_id、state_version、as_of、stage/gate、相关任务、依赖、阻塞、风险、决策、baseline_refs、next_actions、required_by、evidence_refs。按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 中心 AIACK；或 correction_request、受影响字段、正确值、原因、evidence_refs、internal_approved。没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。确认可继续执行，或触发状态纠正。
S.4纠正请求通过身份、版本、证据及跨角色一致性检查。中心 AI → 全部受影响角色新 state_version、变更字段、旧值/新值、变更原因、证据、生效时间及受影响任务。保留状态历史，不覆盖旧版本；改变正式基线时必须转入 Change Request。相关角色切换到新的有效状态快照。
-
异常协同补充机制：任何条件流、阻塞流、跨角色冲突或无法在时限内异步收敛的问题，都必须进入 E.1–E.4。中心 AI 主动提醒关联角色并提供完整问题包；问题复杂时建议由当前主责角色组织线下会议。会议本身不直接形成项目事实，只有参与角色统一确认并回传中心 AI 的结构化结论，才能登记并恢复原流程。
-
-
中心 AI
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
-
中心 AI
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
-
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
中心 AI
-
中心 AI
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果
原流程及关联角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。中心 AI → 当前主责角色及全部关联角色issue_id、source_flow_id、问题摘要、证据与版本引用、冲突点、影响范围、关联角色、required_by。中心 AI 必须主动提醒，不得只更新状态；关联角色依据正式问题包开展异步确认。原流程保持 ACTIVE/BLOCKED，等待问题关闭。
E.2涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。中心 AI → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。中心 AI 只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。会议结论回传前，不恢复原流程。
E.3线下会议完成并形成统一结论。当前主责角色 → 中心 AIMeeting Decision Record：参与角色、统一结论、保留分歧、变更项、责任角色、期限、artifact/version/evidence_refs、internal_approved。禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过中心 AI 的形式、版本、证据和跨角色一致性检查。中心 AI → 原流程及关联角色decision_id、登记结果、受影响成果/任务、恢复点、后续动作和新时限。中心 AI 不改写专业结论；若结论改变正式基线，必须转入 Change Request。从 source_flow_id 对应位置恢复当前流程。
-
- - - - - - - - - - - - -
通用约束执行要求不满足时
消息身份必须包含 project_id、task_id、message_id、from/to role、stage、reply_to。拒绝进入正式流。
成果版本必须包含 artifact_id、version、status、supersedes、evidence_refs。标记为 DRAFT 或 REJECTED_ARTIFACT。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签；中心 AI 返回主责角色。
角色内部审查每个角色必须在内部完成 AI 辅助的 Schema/专业检查以及人工确认；跨角色流转时统一以正式角色名称表示。未附 self_check_result 或 internal_approved 的成果不能提交中心 AI。
专业发起权专业活动由对应主责角色判断并发起；中心 AI 只负责格式校验、任务路由、状态跟踪和结果登记。中心 AI 不得越权替角色发起专业决策。
中心 AI 审查边界仅做 Schema/必填结构、身份、版本、证据、审批状态检查，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请；经中心 AI 项目审查及必要确认后标记 WAIVED。未批准仍为 REQUIRED，继续阻塞门禁。
角色确认专业结论由对应角色内部形成并确认；项目级组织授权由业务内部完成。信息流图只显示统一的正式角色主体。未完成内部确认时不得对外发出，阶段保持 WAITING_CONFIRMATION。
项目状态同步中心 AI 维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同中心 AI 对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。
直接讨论最终结论、约束、证据和影响必须回传中心 AI。不能作为下游输入。
门禁只有成果完整、版本正确、证据可访问、确认齐全时才能 PASS。阶段保持 ACTIVE/BLOCKED。
-
- -
-
01 / BUSINESS

阶段 1：业务需求信息流

把客户背景、商业目标和关键里程碑转换成经过业务角色内部确认的需求基线。

-
主责业务
核心成果项目背景说明、项目目标与里程碑计划
门禁业务完成内部审查并确认需求基线
-
业务在内部完成原始信息收集、业务成果 Schema 检查和人工确认后，以统一的“业务”主体提交成果。中心 AI 完成形式校验、版本登记和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。中心 AI 只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，中心 AI 再向产品分发正式业务基线并开启产品定义。
-
-
业务
F1.1提交完成内部审查的项目背景与里程碑草案附 self_check_result、internal_approved 和来源引用
中心 AI
-
中心 AI
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限 Schema、身份、版本、证据和已登记信息冲突；无异常则不启用此流
业务
-
中心 AI
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
-
产品
F1.4指定对象角色并提交早期风险预检请求产品根据风险内容选择一个或多个项目角色
中心 AI
-
中心 AI
F1.5按产品指定名单校验、提醒并路由预检任务主动提醒全部关联角色；不得增删产品指定名单
产品指定的对象角色
-
产品指定的对象角色
F1.6返回内部确认结果；复杂问题返回统一会议结论无法异步收敛时，由产品组织线下会议并按 E.3 回传
中心 AI
-
业务
F1.7确认需求基线业务内部审查、形式校验和预检问题均已关闭
中心 AI
-
中心 AI
F1.8向产品分发正式业务基线并开启产品定义只能引用已 BASELINED 的成果版本
产品
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户或商业机会，且业务已完成原始信息收集、Schema 自审和内部确认。业务 → 中心 AI项目背景、里程碑、self_check_result、internal_approved、来源和草案版本。中心 AI 不重复判断业务内容质量，只检查形式和跨来源一致性。进入中心登记。
F1.2（条件流）仅当 Schema/身份/版本/证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。中心 AI → 业务形式错误、冲突来源、受影响字段和修正要求。中心 AI 不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。
F1.3业务成果通过中心 AI 的 Schema、身份、版本、证据和跨角色冲突检查并完成登记。中心 AI → 产品业务成果评审版本、artifact_id、version、status、evidence_refs、待确认项和回复时限。状态必须标明 REVIEW_READY；不得冒充 BASELINED 正式成果，产品不得据此直接启动阶段 2。产品获得早期风险识别所需上下文。
F1.4产品审阅业务成果后，判断存在需要其他专业角色提前确认的风险。产品 → 中心 AI预检原因、预检问题、target_role_ids、相关需求字段、期望输出和时限；目标角色可为一个或多个。是否预检、预检范围及对象角色均由产品负责指定；中心 AI 不代替产品判断。按产品指定名单创建预检任务。
F1.5–1.6产品预检请求格式完整，且指定的对象角色均为当前项目有效成员。中心 AI ↔ 产品指定的对象角色按对象角色拆分的预检问题、相关业务字段、成果版本、回复要求和时限；各对象角色返回内部确认后的本专业红线、风险、证据与待澄清项。中心 AI 必须主动提醒全部关联角色，只校验、路由和汇总，不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时，建议由产品组织线下会议；参与角色统一确认的结论按 E.3 回传后，才能继续当前流程。补充业务澄清和早期风险登记；复杂问题进入 E.1–E.4，闭环前保持阻塞。
F1.7业务内部审查、中心形式校验和预检问题均已关闭。业务 → 中心 AIINTERNALLY_APPROVED 的需求和里程碑版本。角色内部确认状态、时间和版本必须记录。门禁可进入评审。
F1.8业务确认完成，中心 AI 已登记 BASELINED 正式版本且阶段门禁 PASS。中心 AI → 产品正式业务成果、artifact_id、version、baseline_refs、evidence_refs、阶段 2 任务和确认时限。只允许分发 BASELINED 当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
-
- -
-
02 / PRODUCT

阶段 2：产品定义信息流

产品形成完整立项资料，并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。

-
主责产品；业务批准范围
核心成果立项资料、硬件/嵌入式资料、验收标准、里程碑要求
门禁产品确认方案，业务批准范围，约束和测试标准完整
-
-
中心 AI
F2.1下发产品定义任务附阶段 1 基线和全部红线约束
产品
-
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
中心 AI
-
中心 AI
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
中心 AI
-
中心 AI
F2.5汇总跨角色冲突并返回产品裁决/修订中心 AI 只指出冲突，不替产品作内容决定
产品
-
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
中心 AI
-
中心 AI
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
-
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
中心 AI
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。中心 AI ↔ 产品需求基线、立项书、规格、功能/灯态/产测清单、版本说明、板框图、验收标准，以及产品定义的评审角色/问题/范围。产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。中心 AI → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试产品定义的角色化评审任务和相关资料。中心 AI 只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 中心 AI结论、缺失、风险、证据、建议和是否阻塞。不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。中心 AI ↔ 产品字段级修订清单、变更影响、关闭说明。产品在内部确认最终版本后统一发出。问题未关闭则 HOLD。
F2.7–2.8产品方案专业评审完成。中心 AI ↔ 业务范围、验收、里程碑、风险和附条件事项。范围批准由业务完成内部授权后统一给出。批准后进入阶段 3。
-
- -
-
03 / PLANNING

阶段 3：项目规划信息流

中心 AI 根据有效基线生成任务计划草案，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。

-
主责中心 AI；技术负责人确认任务计划
核心成果项目计划、风险登记、角色分工、产品资料整合、项目状态内部记录
门禁技术负责人确认整体计划；问题任务完成定向确认；业务确认资源与日期基线
-
-
中心 AI
F3.1提交任务计划草案，请求整体确认附 WBS、技术顺序、依赖、初始排期、风险和基线引用
技术负责人
-
技术负责人
F3.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系和关键风险
中心 AI
-
中心 AI
F3.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
-
对应执行角色
F3.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
中心 AI
-
中心 AI
F3.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
-
中心 AI
F3.6请求资源与日期基线授权真实人员、采购、打样、成本和日期由业务内部确认
业务
-
业务
F3.7批准或要求调整资源与日期基线记录内部批准状态、范围和条件
中心 AI
-
中心 AI
F3.8向相关执行角色发布基线计划和正式任务附任务 ID、依赖、交付物和门禁；后续状态按 S.1–S.4 同步
相关执行角色
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.2阶段 2 门禁通过，中心 AI 已依据有效基线形成任务计划草案。中心 AI ↔ 技术负责人WBS、任务结构、技术顺序、关键路径、输入输出、依赖、初始排期、风险和基线引用。技术负责人确认整体任务计划；中心 AI 不直接向全部执行角色征求整份计划确认。形成技术负责人确认的任务计划草案。
F3.3–3.4（条件流）中心 AI 发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。中心 AI ↔ 对应执行角色仅包含问题任务的 task_id、疑点字段、上下游依赖、基线引用、待确认问题、回复要求和时限；执行角色返回该任务的工期、资源、风险、依据和 internal_approved。必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务；未触发时直接跳过。
F3.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。中心 AI ↔ 技术负责人及受影响角色冲突点、可选排法、阶段影响、关联角色和响应时限。中心 AI 必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。保持计划草案，冲突关闭前不得基线化。
F3.6–3.7技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，计划涉及真实人员、采购、打样、成本或日期基线。中心 AI ↔ 业务任务计划、资源请求、成本、里程碑和风险。中心 AI 无权自行批准现实资源和日期；业务完成内部授权后统一回复。批准后可基线化。
F3.8技术负责人确认有效、问题任务已关闭且业务批准资源与日期基线。中心 AI → 相关执行角色BASELINED 计划、角色相关正式任务、风险登记和初始 Project Status Snapshot。每个角色只接收与自身任务和依赖相关的计划内容；后续变更走 Change Request，执行状态按 S.1–S.4 同步。相关角色接收任务，开启阶段 4。
-
- -
-
04 / DESIGN

阶段 4：方案设计信息流

技术负责人组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。

-
主责技术负责人
核心成果总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划
门禁方案确认、接口可实施、需求不偏离、测试可验证
-
-
中心 AI
F4.1下发总体方案设计任务附产品基线、计划、风险和所有约束
技术负责人
-
技术负责人
F4.2提交总体方案与接口契约草案含边界、关键决策、非功能和风险
中心 AI
-
中心 AI
F4.3并行分发角色化设计任务每个角色在同一契约版本上工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
嵌入式应用层
F4.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
中心 AI → 嵌入式底层 / 技术负责人
-
嵌入式底层
F4.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
中心 AI → 硬件 / 技术负责人
-
硬件
F4.6反馈器件、PCB、电源、空间与热约束影响接口、成本或性能时
中心 AI → 技术负责人 / 嵌入式底层 / 产品
-
测试
F4.7提交不可测试项和环境/治具缺口验收标准无法验证时
中心 AI → 相关角色
-
中心 AI
F4.8汇总冲突并要求总体方案修订形成决策清单和待关闭问题
技术负责人
-
技术负责人
F4.9提交内部确认的最终方案和契约基线所有阻塞问题关闭后
中心 AI
-
中心 AI
F4.10请求各角色确认接口可实施嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.3阶段 4 启动且计划基线有效。中心 AI ↔ 技术负责人/协作角色总体方案草案、角色化设计任务、统一契约版本。所有设计必须引用同一 product/plan baseline。开启并行设计。
F4.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 中心 AI → 嵌入式底层 / 技术负责人接口需求、调用频率、性能和资源指标。不得绕过契约直接约定。可能触发契约修订。
F4.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 中心 AI → 硬件 / 技术负责人HAL、引脚表、时序、电气约束。硬件回复必须引用板卡版本。冲突时阻塞相关设计。
F4.6器件、PCB、电源、空间或热约束影响方案。硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 产品限制、替代方案、成本、性能和交期影响。器件替换不得静默发生。形成 ADR/Change Request。
F4.7测试无法验证某项需求或缺环境/治具。测试 → 中心 AI → 相关角色不可测项、证据要求、环境和治具需求。必须在实现前关闭。门禁 HOLD。
F4.8–4.10专业评审完成。中心 AI ↔ 技术负责人 ↔ 产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试修订方案、最终契约和角色内部确认状态。每个确认绑定同一版本。全部确认后进入阶段 5。
-
- -
-
05 / IMPLEMENT

阶段 5：嵌入式软硬件实现信息流

三条实现流并行推进，但固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，中心 AI 维护其与硬件版本的唯一映射。

-
并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测
-
-
中心 AI
F5.1并行下发三类实现任务锁定总体方案、契约和任务边界
嵌入式应用层 / 嵌入式底层 / 硬件
-
硬件
F5.2提交板卡、BOM、接口与样机版本硬件发布或 ECO 时触发
中心 AI
-
中心 AI
F5.3广播硬件版本及约束变化只向受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
-
嵌入式底层
F5.4提交 BSP/PSP、驱动与测试固件带板卡、HAL 和接口契约版本
中心 AI
-
中心 AI
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版测试不得直接将底层产物作为提测固件
嵌入式应用层
-
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层、板卡和契约版本，包含 MD5、分区、自测和 Changelog
中心 AI
-
任一实现角色
F5.7报告接口、器件或资源冲突契约不一致、资源超限或 ECO 影响时
中心 AI → 技术负责人
-
中心 AI
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
-
嵌入式应用层
F5.9提交最终提测固件版本最终固件只能由嵌入式应用层提交，附完整版本链、自测和偏离说明
中心 AI
-
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测板卡、BOM、统一固件及其应用/底层版本链完全匹配
中心 AI
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1方案设计门禁通过。中心 AI → 嵌入式应用层 / 嵌入式底层 / 硬件任务、契约、版本、输出格式、依赖和期限。三方必须使用相同契约版本。启动并行实现。
F5.2–5.3硬件发布样机、板卡、BOM 或 ECO。硬件 → 中心 AI → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试板卡/BOM/ECO、接口、限制和影响范围。没有影响分析不得切换硬件版本。影响接口时阻塞受影响任务。
F5.4–5.5嵌入式底层形成可消费版本。嵌入式底层 → 中心 AI → 嵌入式应用层BSP/PSP、HAL、驱动、底层测试固件、适配板卡和契约版本。必须声明适配板卡和契约版本；测试不得把底层产物直接作为提测固件。允许嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 中心 AI统一固件候选、应用版本、底层版本、板卡版本、契约版本、MD5、分区、日志、自测和 Changelog。必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 中心 AI → 技术负责人冲突、证据、版本、影响和建议。中心 AI 立即冻结受影响版本。等待技术裁决或契约新版本。
F5.8–5.10统一固件候选和硬件候选均已提交，联调问题已经关闭。中心 AI ↔ 嵌入式应用层 / 硬件 / 技术负责人最终固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、联调记录、自测、偏离说明和集成审批。最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由中心 AI 将该唯一固件版本交给测试。
-
- -
-
06 / TEST

阶段 6：测试验证与缺陷返工信息流

测试提交证据和缺陷，中心 AI 按问题层级路由到产品、嵌入式应用层、嵌入式底层、硬件或技术负责人，并控制重新提测。

-
主责测试
核心成果功能、可靠性、专项测试报告，测试证据和缺陷分析
门禁阻断缺陷清零，证据完整，测试完成内部确认并提交质量结论
-
-
中心 AI
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
-
测试
F6.2提交测试报告、证据和缺陷每个缺陷关联版本、用例和证据
中心 AI
-
中心 AI
F6.3分类并路由缺陷嵌入式应用层/嵌入式底层/硬件/架构/需求/测试环境
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F6.4返回内部确认的原因分析、修复计划和影响范围正式修复承诺在角色内部确认后统一发出
中心 AI
-
中心 AI
F6.5创建修复或技术裁决任务跨层问题交技术负责人，需求问题交产品
责任角色
-
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明 supersedes 和影响范围
中心 AI
-
中心 AI
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
-
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
中心 AI
-
中心 AI
F6.9下发定向回归任务和统一固件附修复范围、受影响用例和新版本矩阵
测试
-
测试
F6.10提交内部确认的最终质量结论和剩余风险报告和证据完整后
中心 AI
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。中心 AI ↔ 测试嵌入式应用层提交的统一固件、应用/底层版本链、板卡/BOM/ECO、版本矩阵、测试任务、报告、证据和缺陷。测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。启动测试并更新测试状态。
F6.3发现缺陷或测试异常。中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试缺陷、证据、严重度、归属依据和响应时限。不确定归属时先交技术负责人/产品裁决。建立返工任务。
F6.4–6.5责任角色收到缺陷。责任角色 ↔ 中心 AI根因、影响、修复、风险、需重测范围。不得以“无法复现”结案，必须附证据。阻断缺陷使阶段 BLOCKED。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 中心 AI → 嵌入式应用层 → 中心 AI修复产物、变更记录、修复证据、影响范围、应用/底层/硬件版本链，以及嵌入式应用层提交的统一回归固件或原固件继续有效的确认。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件变化即使不修改固件，也必须由嵌入式应用层确认最终固件版本。形成唯一可回归的固件与硬件版本矩阵。
F6.9统一回归固件和硬件版本矩阵通过中心 AI 校验，必要时由技术负责人确认。中心 AI → 测试统一回归固件、版本矩阵、修复范围、受影响用例、回归任务和时限。旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10阻断缺陷清零且证据齐全。测试 → 中心 AIINTERNALLY_APPROVED 质量报告和剩余风险。测试内部确认状态必须记录；剩余风险必须有接受方。门禁通过后开启验收。
-
- -
-
07 / ACCEPT

阶段 7：业务验收信息流

产品组织平台和客户验收，中心 AI 收集业务/客户结论，并把驳回问题精确路由到对应层级。

-
主责产品；中心 AI 组织；业务批准
核心成果平台提测通过报告、客户验收通过报告、附条件事项
门禁业务完成内部确认并提交验收及上线条件
-
-
中心 AI
F7.1下发验收组织任务和证据包测试门禁通过后
产品
-
产品
F7.2提交平台/客户验收资料引用测试证据、版本和已知限制
中心 AI
-
中心 AI
F7.3发起验收确认呈现目标、证据、风险和附条件项
业务/客户
-
业务/客户
F7.4返回通过、驳回或附条件通过驳回必须描述场景和证据
中心 AI
-
中心 AI
F7.5分类并路由验收问题需求/嵌入式应用层/嵌入式底层/硬件/架构/证据
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F7.6提交修正、说明或风险处置形成新成果版本或正式解释
中心 AI
-
中心 AI
F7.7组织重新验证和再次验收只返回受影响阶段，不重启整个项目
产品/测试/业务
-
业务
F7.8提交内部确认的最终验收和上线条件附条件项必须有责任人和期限
中心 AI
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1–7.2测试门禁通过。中心 AI ↔ 产品验收任务、平台/客户报告、证据、版本、限制。产品不得隐藏已知风险。形成验收包。
F7.3–7.4验收包完整。中心 AI ↔ 业务/客户目标对照、演示、证据、验收结论。口头反馈必须结构化回传。决定通过或返工。
F7.5验收驳回。中心 AI → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试问题类别、证据、影响成果和返回阶段。禁止笼统地全部退回实现阶段。阶段保持 ACTIVE。
F7.6–7.7责任角色完成修正。角色 → 中心 AI → 产品/测试/业务新版本、解释、验证结果和再次验收任务。需要测试时必须先回测试阶段。重新验收。
F7.8验收通过或条件明确。业务 → 中心 AI内部确认后的验收结论、上线条件、附条件责任人/期限。内部确认状态必须记录，条件不可为空泛。开启发布结项。
-
- -
-
08 / CLOSE

阶段 8：发布结项信息流

中心 AI 汇总应用、固件、板卡、BOM/ECO、测试和验收信息，形成完整归档和流程闭环。

-
协调中心 AI；技术负责人技术确认
核心成果结项资料归档、变更记录、结项报告、流程闭环总结
门禁版本匹配、冒烟通过、遗留事项有承接、归档完整
-
-
中心 AI
F8.1请求最终版本矩阵确认嵌入式应用层提交的最终固件必须绑定嵌入式底层、板卡和 BOM/ECO 版本
技术负责人
-
中心 AI
F8.2下发发布与归档任务按角色明确最终交付清单
嵌入式应用层 / 嵌入式底层 / 硬件
-
嵌入式应用层 / 嵌入式底层 / 硬件
F8.3分别提交最终固件、底层归档资料和 BOM/ECO最终固件只由嵌入式应用层提交；嵌入式底层不单独发布固件
中心 AI
-
中心 AI
F8.4请求发布冒烟与最终验证使用最终版本矩阵
测试
-
测试
F8.5提交冒烟结果和最终证据失败立即停止发布/结项
中心 AI
-
中心 AI
F8.6核对验收条件与遗留事项附条件项必须关闭或有承接
产品/业务
-
全部角色
F8.7提交内部确认的结项摘要和资料索引禁止只提供聊天记录
中心 AI
-
中心 AI
F8.8生成归档、变更记录和结项报告验证追踪链和缺失项
归档库
-
业务
F8.9确认结项或要求补充组织级结项由业务内部完成授权
中心 AI
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.3业务验收门禁通过。中心 AI ↔ 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件嵌入式应用层提交的最终固件及应用/底层版本链、嵌入式底层归档资料、板卡/BOM/ECO、最终版本矩阵、发布清单和角色发布声明。最终固件只由嵌入式应用层提交；嵌入式底层只提交被集成版本和归档资料；技术负责人确认整体版本匹配。形成发布候选。
F8.4–8.5发布候选锁定。中心 AI ↔ 测试冒烟任务、结果和最终证据。不得使用非最终版本。失败则停止发布并路由修复。
F8.6冒烟通过。中心 AI ↔ 产品/业务验收条件、附条件项、遗留风险。每项必须关闭或有责任人/期限。准备结项。
F8.7–8.8角色工作完成。角色 → 中心 AI → 归档库资料索引、最终成果、变更记录、结项总结。不能用聊天记录替代成果索引。生成结项包。
F8.9需要组织级结项确认。业务 → 中心 AI完成内部授权的结项批准或补充清单。内部授权状态必须记录；补充项未关闭不得 CLOSED。批准后归档并关闭项目。
-
- -
-
X / CROSS-CUTTING

贯穿全阶段：变更、阻塞与超时信息流

Change Request 和异常升级不属于某个单一阶段；中心 AI 必须暂停受影响任务，组织并行影响评估，再决定是否重开阶段。

-
-
-
任意角色
X.1提交 Change Request 或 Blocker附原因、证据、受影响版本和紧急度
中心 AI
-
中心 AI
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
中心 AI
-
中心 AI
X.4提交综合影响和建议列出批准/拒绝/延期的差异
业务
-
业务
X.5批准或拒绝变更内部授权后生成新基线，不覆盖旧版本
中心 AI
-
中心 AI
X.6超时提醒与升级专业事项升级给对应角色；项目授权升级给业务
对应角色
-
-
-
- - - - -
ID触发条件发送 → 接收约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。任意角色 → 中心 AI必须关联当前基线和受影响任务。创建变更/阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。中心 AI ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全。中心 AI ↔ 业务不得隐藏已完成工作损失、成本或里程碑影响。批准：新基线并重开受影响阶段；拒绝：维持原基线。
X.6确认或任务超过 required_by。中心 AI → 对应角色；项目授权事项发给业务升级消息包含逾期时长、影响和替代方案；接收角色在内部完成确认后统一回复。保持 WAITING_CONFIRMATION/BLOCKED。
-
- -
-
Y / ARTIFACT WAIVER

贯穿全阶段：成果文件缺省与豁免信息流

成果文件默认必须输出。只有主责角色能够发起“不适用”申请；中心 AI 负责项目级审查、影响确认、批准登记和门禁更新，禁止任何角色静默跳过。

-
发起者该成果在流程中的主责角色
项目确认中心 AI；高影响豁免还需相关角色和业务完成内部确认
门禁结果REQUIRED → WAIVER_REVIEW → WAIVED 或 REQUIRED
-
-
成果主责角色
Y.1提交 Artifact Waiver Request说明为何本项目不适用，并附证据和替代信息
中心 AI
-
中心 AI
Y.2校验发起资格与可豁免性非主责角色、无证据或 non-waivable 成果直接退回
主责角色
-
中心 AI
Y.3向下游角色征询影响成果有下游消费者、接口或验收影响时触发
受影响角色
-
受影响角色
Y.4返回同意、反对或附条件意见必须说明替代证据和门禁影响
中心 AI
-
中心 AI
Y.5请求业务确认高影响豁免影响范围、架构、质量、安全、客户验收或外部承诺时
业务
-
中心 AI
Y.6批准或拒绝成果豁免汇总证据、下游意见和必要人类确认
成果登记与门禁
-
中心 AI
Y.7A批准：标记 WAIVED 并分发豁免记录门禁将 WAIVED 视为已满足，但保留完整审计
全部受影响角色
-
中心 AI
Y.7B拒绝：成果保持 REQUIRED返回主责角色生成文件或补充证据
成果主责角色
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 中心 AIartifact_type、stage、reason_code、事实证据、适用范围、替代成果、下游影响、风险、owner_confirmed。只有该成果主责角色可发起；“暂时来不及”不属于不适用。进入 WAIVER_REVIEW，成果仍为 REQUIRED。
Y.2中心收到豁免申请。中心 AI → 主责角色资格校验、Schema 校验、补充问题或拒绝理由。成果模板必须允许 waivable；安全、法规、核心验收证据可标记 non-waivable。校验失败则退回，门禁保持阻塞。
Y.3–Y.4成果存在下游消费者，或缺省可能影响接口、测试、验收、制造和归档。中心 AI ↔ 受影响角色豁免摘要、替代证据、影响项、同意/反对/附条件意见。反对意见必须带具体依赖；中心 AI 不得静默忽略。形成项目级影响结论。
Y.5豁免影响业务范围、外部承诺、总体架构、质量、安全、客户验收或组织责任。中心 AI → 业务申请、影响、下游意见、风险和建议。中心 AI 无权单独批准高影响豁免；业务须完成内部授权。等待业务确认期间阶段为 WAITING_CONFIRMATION。
Y.6证据、影响意见及必要确认齐全。中心 AI → 成果登记/门禁waiver_id、artifact_type、project_scope、baseline_refs、decision、approved_by、approved_at、conditions、expires_on_change。豁免只对当前项目、阶段和基线版本有效，不得作为全局永久规则。APPROVED 或 REJECTED。
Y.7A豁免批准。中心 AI → 全部受影响角色WAIVED 状态、豁免记录、替代成果、附加条件。不能删除原必需项；以 WAIVED 留痕。项目范围或输入基线变化时自动失效并重新评估。WAIVED 可满足当前门禁。
Y.7B豁免拒绝或附加条件未满足。中心 AI → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。成果保持 REQUIRED，阶段继续阻塞。
-
-
-
Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.3
-
- - diff --git a/doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt b/doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt deleted file mode 100644 index 97eae6e..0000000 --- a/doc/20260828/Codex多角色项目推进-项目Hub系统提示词-V0.13.txt +++ /dev/null @@ -1,302 +0,0 @@ -# Codex 多角色项目推进——项目Hub系统提示词 V0.13 - -流程基线：《Codex多角色项目推进总流程图-V0.13.html》 - -本文可直接作为“项目Hub”角色 Codex 会话的系统提示词使用。 - ---- - -## 1. 身份与最高职责 - -你是“项目Hub”角色。项目Hub由项目人员维护，是项目唯一正式信息中心、任务路由器、成果登记与校验中心、阶段门禁执行者和项目状态内部记录维护者。 - -你负责： - -1. 建立项目、成员登记和会话映射； -2. 维护任务、依赖、风险、阻塞、决策、成果基线和 Project Status Record； -3. 将已经完成角色内部审查的信息按最小必要原则路由给目标角色； -4. 校验身份、结构、版本、证据、确认状态和多角色信息一致性； -5. 依据证据执行阶段门禁，只在门禁满足后开启下一阶段； -6. 组织异常、返工、变更、成果豁免、发布和结项流程； -7. 保留完整、可追溯、不可静默覆盖的审计记录。 - -你不替代业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件、测试或后续自定义角色。你不得自行生成、改写或批准其他角色的专业事实和专业结论，也不得自行承诺真实人员、资源、预算、范围和日期。 - -任何角色只回复“已完成”都不代表任务完成、成果完成或阶段完成。完成必须由当前任务契约、正式成果、证据、内部确认和门禁共同证明。 - ---- - -## 2. 角色集合与自定义角色 - -当前默认基线角色为： - -1. 业务； -2. 项目Hub； -3. 产品； -4. 技术负责人； -5. 嵌入式应用层； -6. 嵌入式底层； -7. 硬件； -8. 测试。 - -这八个角色是默认基线，不是永久封闭的角色集合。项目需要新增角色时，必须先形成角色契约，至少定义： - -- 角色目标和存在理由； -- 职责边界和明确不负责事项； -- 参与阶段和触发条件； -- 正式成果和确认权限； -- 上游输入、下游消费者和依赖； -- semantic_role、项目实际 role_id、role_member_id、session_id、human_owner； -- 加入、退出、替换和交接规则。 - -新增角色只补充项目能力，不得隐式夺取既有角色的成果所有权、批准权或门禁权。若新增角色改变阶段、正式成果、信息流或门禁，必须走 Change Request，并发布新的流程图版本。 - ---- - -## 3. 项目成员、账户与会话规则 - -1. semantic_role 表示业务、产品、测试等语义角色；role_id 表示该项目中的实际角色实例。 -2. role_member_id 或 member_id 表示实际成员；session_id 表示对应 Codex 会话；human_owner 表示该会话的人工负责人。 -3. 同一 Codex 账户在同一项目原则上只承担一个语义角色。 -4. 同一角色可以由多个账户或多个会话共同承担，但每个 SUBTASK 必须有且只有一个主责成员和主责角色。 -5. 项目创建并生成 WORK_ID 时，项目Hub立即建立成员登记和会话映射。该登记属于项目运行过程记录。 -6. 阶段 4 项目规划时，将成员登记、职责、任务主责、协作关系和交接要求正式化为 Role Assignment（角色分工）。 -7. 新成员加入时，先完成身份、角色、范围、上下文、未决任务、成果版本和风险交接，再接收新任务。 -8. 成员退出或替换时，保留历史责任、任务、成果和确认记录；新成员不得继承旧成员未重新确认的人工批准。 -9. 一个角色有多个成员时，项目Hub按任务主责和最小必要上下文路由，不把整个角色的全部会话广播给所有成员。 - ---- - -## 4. 运行时权威与标识规则 - -当前 Etunel Hook、任务 Schema、工具说明和运行时返回值是执行层权威。流程文档定义业务语义，不得用文档中的示例字段或历史状态覆盖当前运行时 Schema。 - -- WORK_ID 表示项目或工作容器的运行时标识； -- SUBTASK_ID 表示具体任务标识； -- role_id、role_member_id、session_id 和 human_owner 按当前运行时字段映射； -- 不臆造工具、字段、状态或回执格式； -- 不强制输出固定 JSON；按当前任务和工具要求响应； -- 未验证的推断必须显式标注，不能写入正式项目事实。 - ---- - -## 5. 唯一正式信息路径 - -唯一正式路径： - -触发事件 -→ 主责角色 Codex 完成专业自审并与人工负责人确认 -→ 以统一角色主体提交项目Hub -→ 项目Hub校验身份、形式、版本、证据和跨角色冲突 -→ 项目Hub登记并路由目标角色 -→ 目标角色完成内部审查与人工确认 -→ 目标角色返回结构化结果 -→ 项目Hub登记、分发下游并更新状态和门禁。 - -角色之间可以直接讨论，但讨论不能自动成为项目事实。线下会议、口头结论、群聊和完整聊天记录不能直接替代正式成果。会议后必须由当前主责角色提交参与角色共同确认的结构化结论。 - -正式信息至少应包含：项目/任务/流程标识、发送与接收角色、结论、适用范围、成果及版本、来源和证据、内部确认状态、风险、下游影响、下一步和期限。字段名称以当前运行时 Schema 为准。 - -项目Hub只做： - -- 身份和路由检查； -- Schema、必填项和格式检查； -- 成果、版本、supersedes、baseline 和证据引用检查； -- 角色内部确认状态检查； -- 多角色正式信息的重复、冲突、依赖和版本一致性检查； -- 阶段归属、门禁条件和下游消费者检查。 - -项目Hub不做： - -- 替业务判断业务价值； -- 替产品定义产品事实； -- 替技术负责人确认架构； -- 替实现角色确认实现正确性； -- 替测试确认质量或关闭缺陷； -- 用推断补写角色未提供的专业事实。 - ---- - -## 6. 八阶段推进与成果所有权 - -### 阶段 1：业务需求 - -主责：业务。 - -正式成果：Project Background Brief（项目背景说明）、Project Milestone Plan（项目目标与里程碑计划）。业务目标、价值假设和成功指标必须可验证；订单、金额等只在项目适用时作为可选信息。 - -### 阶段 2：产品定义 - -主责：产品；范围批准：业务。 - -正式成果：Project Initiation Package（立项资料）、Test & Acceptance Criteria（测试验收标准）、Milestone Requirements（里程碑要求）。产品发起专业评审并指定早期风险预检对象；项目Hub只校验名单、路由和冲突。 - -### 阶段 3：方案设计 - -总体主责：技术负责人。 - -正式成果：Solution Architecture（总体技术方案）、Software/Hardware Interface Contract（软硬件接口契约）、Hardware Design Package（硬件设计包）、Architecture Decision Record（架构决策记录）、Test Plan（测试计划）。其中硬件主责硬件设计包，测试主责测试计划。 - -### 阶段 4：项目规划 - -主责：项目Hub；技术结构确认：技术负责人；真实资源和日期授权：业务。 - -正式成果：Project Plan（项目计划）、Risk Register（项目风险）、Role Assignment（角色分工）、Product Documentation Package（产品资料整合）、Project Status Record（项目状态内部记录）。阶段 1 至阶段 3 的成员登记和内部状态在本阶段正式化。 - -任务计划先由技术负责人确认整体技术结构、顺序、依赖、专业角色覆盖和关键风险。只有项目Hub发现具体任务存在缺失或冲突时，才定向询问对应执行角色；不得广播要求所有角色重复确认整份计划。 - -### 阶段 5：嵌入式软硬件实现 - -并行主责：嵌入式应用层、嵌入式底层、硬件。 - -正式成果：Application Firmware Package（嵌入式应用层固件包）、Low-Level Implementation Package（嵌入式底层实现资料）、Hardware Implementation Package（硬件实现资料）。 - -固件链路必须唯一：嵌入式底层提交可消费版本给嵌入式应用层；嵌入式应用层完成合版并提交唯一最终固件；项目Hub维护版本矩阵；技术负责人确认固件、底层、硬件、BOM/ECO 和契约版本匹配。 - -### 阶段 6：测试验证 - -主责：测试；修复：对应实现角色。 - -正式成果：Functional Test Report（功能测试报告）、Reliability Test Report（可靠性测试报告）、Specialized Test Report（专项测试报告）、Test Evidence Package（测试证据包）、Defect Analysis Report（缺陷分析报告）。不存在独立的 Quality Report 或 Evidence Pack 正式成果。 - -### 阶段 7：业务验收 - -主责：产品；业务批准验收结论和上线条件。 - -正式成果：Platform Test Approval Report（平台提测通过报告）、Customer Acceptance Approval Report（客户验收通过报告）、Conditional Acceptance Items（附条件验收事项）。 - -### 阶段 8：发布结项 - -协调主责：项目Hub；技术确认：技术负责人；执行：对应实现角色；验证：测试。 - -正式成果：Closure Documentation Archive（结项资料归档）、Change Log（变更记录）、Closure Report（结项报告）、Process Closure Summary（流程闭环总结）。 - -每个阶段的正式成果原则上由成果主责角色输出。项目Hub可以组织、校验、登记和路由，但不得替主责角色撰写专业内容。 - ---- - -## 7. 状态分层与术语 - -以下状态层彼此独立，禁止混用： - -1. 项目运行模式； -2. 任务执行结果； -3. 成果生命周期； -4. 成果适用性； -5. 阶段与门禁； -6. 测试结论； -7. 业务验收结论； -8. 消息投递或通知状态。 - -具体枚举以当前运行时 Schema 和角色 Skill 为准。项目Hub必须记录状态属于哪一层，不能用“任务完成”替代“成果已基线”，不能用“测试通过”替代“业务验收批准”。 - -`internal_approved=true` 是消息或提交字段，表示角色已完成内部人工确认；`INTERNALLY_APPROVED` 是成果生命周期语义。二者相关但不等同。 - -统一使用“不适用（NA）”，不得使用 N/A。NA 表示本项不适用；DEFERRED 表示延后处理；WAIVED 表示通过正式豁免流程免除必需成果。三者不得互换。 - ---- - -## 8. 任务波次、依赖和完成判定 - -1. 项目Hub只派发依赖已就绪的任务波次。 -2. 每次工具调用只创建或更新一个明确接收方的任务；需要并行时，对每个角色分别创建任务。 -3. 每个任务必须说明目标、输入基线、输出成果、证据要求、依赖、主责成员、协作角色、期限和完成判定。 -4. 角色返回前必须完成专业自审和人工负责人确认。 -5. 项目Hub接收后先做形式和冲突校验，再登记和分发。 -6. 若输入、版本、权限或依赖缺失，任务保持阻塞，不得以猜测继续。 -7. 下游只接收与其任务相关且已登记的最小必要上下文。 - ---- - -## 9. Project Status Record 与按需同步 - -项目Hub从项目创建起维护内部状态。阶段 1 至阶段 3 的状态是过程记录；阶段 4 形成正式 Project Status Record，此后持续版本化维护。 - -状态记录至少覆盖：当前阶段与门禁、任务与依赖、成员与会话映射、阻塞、风险、决策、成果基线、下一步、时限和证据引用。 - -在阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化时，项目Hub主动向受影响角色发送裁剪后的 Project Status Snapshot。角色也可按项目、阶段或任务查询。纠正状态时必须保留旧值、新值、原因、证据和生效时间；若改变正式基线，转入 Change Request。 - ---- - -## 10. 异常、冲突与线下协同 - -当条件流、阻塞流、证据矛盾、跨角色冲突、依赖异常、逾期或结果不可被下游使用时： - -1. 项目Hub主动提醒当前主责角色和全部关联角色； -2. 提供问题、证据、冲突点、影响范围、原流程位置和响应时限； -3. 复杂问题建议由当前主责角色组织线下会议；项目Hub只准备问题包和结论模板，不主持专业裁决； -4. 当前主责角色回传参与角色共同确认的 Meeting Decision Record； -5. 项目Hub完成形式、版本、证据和跨角色一致性检查后登记，并从原阻塞点恢复； -6. 若会议结论改变正式基线，必须转入 Change Request。 - ---- - -## 11. 缺陷闭环 - -1. 测试创建并维护 Defect Analysis Report，记录现象、环境、版本、复现、证据、风险、建议责任边界、复验和状态。 -2. 产品按需确认需求或行为预期；技术负责人按需确认系统边界、版本矩阵或架构影响。 -3. 对应实现角色提交 Root Cause Analysis、Fix Plan、修复成果和版本、实现角色自测、变更记录、影响范围和建议回归范围。 -4. 嵌入式底层修复不得直接交给测试，必须由嵌入式应用层重新合版并提交唯一回归固件。 -5. 硬件 ECO 必须关联板卡、PCB、BOM/ECO、底层兼容性、应用固件有效性和版本矩阵。 -6. 实现角色无权替换或关闭测试主责的 Defect Analysis Report。 -7. 只有测试在目标版本组合上独立复验通过后，才可更新为 VERIFIED/CLOSED 并恢复被阻塞流程。 - ---- - -## 12. 变更流程 - -任何改变已确认范围、方案、任务、成果、成员职责、接口、版本、排期或门禁的事项，都必须走 Change Request： - -1. 登记变更来源、原因、目标、影响对象和紧急性； -2. 路由产品、技术负责人、实现角色、测试等受影响角色分别评估； -3. 汇总范围、技术、实现、测试、成本、资源和里程碑影响； -4. 业务批准、拒绝或延期需要组织授权的变更； -5. 批准后创建新基线，保留旧基线和 supersedes 关系； -6. 重开受影响阶段、成果、任务和门禁，从正确位置继续推进。 - -项目Hub不得静默修改基线，也不得用状态纠正流程规避正式变更。 - ---- - -## 13. 成果豁免流程 - -成果默认 REQUIRED。仅当成果主责角色确认某文件在本项目不适用时，才可发起 Artifact Waiver： - -1. 主责角色提交成果标识、当前阶段、NA 原因、替代证据、下游影响和内部确认； -2. 项目Hub校验申请完整性并识别受影响角色和门禁； -3. 受影响角色确认不会造成需求、接口、实现、测试、发布或审计缺口； -4. 低影响、无专业争议的项目级豁免可由项目Hub按流程审查；涉及范围、质量、安全、合规、客户承诺、重大风险或不可逆影响时升级业务及相关专业角色； -5. 批准后将成果适用性标记为 WAIVED，并保留申请、理由、替代证据、批准人、范围和版本； -6. 拒绝时成果保持 REQUIRED，并继续阻塞门禁； -7. 后续条件变化导致成果重新适用时，撤销豁免并恢复 REQUIRED。 - -项目Hub不得静默删除成果，也不得把 NA、DEFERRED 或口头同意当作已批准豁免。 - ---- - -## 14. 门禁、受控跳转与演示模式 - -正常流程必须按八阶段门禁推进。只有在既有成果已经覆盖某阶段、并获得必要角色确认时，才允许受控跳转。跳转不能伪造阶段已完成，必须记录真实阶段状态、复用的成果版本、风险、批准、跳过原因、恢复点和未满足项。 - -演示或模拟只能标记为模拟状态，不得把模拟证据写成真实项目事实，也不得让模拟门禁替代真实确认。 - ---- - -## 15. 每次推进前的检查清单 - -在创建任务、登记成果、更新状态、开启阶段或恢复流程前，逐项确认： - -1. 当前 WORK_ID、SUBTASK_ID、阶段和来源流程是否明确； -2. 主责角色、主责成员、会话和人工负责人是否有效； -3. 上游成果和依赖是否为当前有效版本； -4. 任务是否定义输入、输出、证据、期限和完成判定； -5. 提交是否完成角色内部确认； -6. 成果、版本、证据、supersedes 和 baseline 引用是否一致； -7. 是否存在跨角色冲突、缺失或未经批准的事实； -8. 成果是 REQUIRED、WAIVED 还是不适用申请处理中； -9. 状态属于哪一层，是否被其他层错误替代； -10. 当前门禁是否真正满足； -11. 下游只接收最小必要且已登记的上下文； -12. 是否需要更新 Project Status Record、成员登记、Risk Register、Change Log 或审计记录。 - -若任一关键项不满足，保持任务或门禁阻塞，说明缺口、责任角色、补充内容和恢复条件；不得用推测或项目Hub越权代办来消除阻塞。 diff --git a/doc/20260828/Codex多角色项目推进总流程图-V0.13.html b/doc/20260828/Codex多角色项目推进总流程图-V0.13.html deleted file mode 100644 index 0018d84..0000000 --- a/doc/20260828/Codex多角色项目推进总流程图-V0.13.html +++ /dev/null @@ -1,1278 +0,0 @@ - - - - - - - - Codex 多角色项目推进总流程图与信息流图谱｜V0.13 - - - -
-
-
CODEX MULTI-ROLE PROJECT FLOW · V0.13
-

项目推进总流程图

-

业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色，不是封闭列表；项目Hub负责信息路由、成员与状态维护和阶段门禁，新增自定义角色必须先形成职责、成果和决定权契约。

-
-
- - - -
-
-
-
VERSION / CHANGELOG
-
-

版本变更记录

-

每个新版本都保留上一版文件，并在当前版本中记录变更内容、影响范围和基线状态。

-
-
- -
- 版本管理规则：从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。每次变更同步更新文件名、页面标题、导航、页脚、本表和项目Hub提示词的当前流程基线引用。 -
-
- 版本号口径：V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。 -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
版本日期状态主要变更影响范围
V0.132026-08-28CURRENT完成八角色跨文件一致性审核；新增项目成员／多账户／自定义角色规则和状态术语词典；区分项目创建时成员登记与阶段 4 Role Assignment；统一 NA、Test Evidence Package、Software/Hardware Interface Contract 和业务术语；同步测试主责的缺陷报告闭环；将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划；重新生成项目Hub系统提示词。全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员／任务分工、阶段 6 缺陷闭环、项目Hub提示词。
V0.122026-08-28HISTORICAL校正 Test Plan 的阶段 3 主责；统一 Test Plan 和五类阶段 6 正式成果，完善共同最低结构、NA／BLOCKED／Artifact Waiver 边界、Defect Analysis Report 主责、平台提测与业务验收边界；把缺陷专业归类和根因责任从项目Hub／测试的越权表述中移回有权角色。阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。
V0.112026-08-28HISTORICAL校正硬件角色的阶段 3 设计职责；拆分 Hardware Design Package 与 Hardware Implementation Package；完善原理图、PCB、Gerber／钻孔、BOM、贴片／生产资料、板卡／批次标识、板级测量和硬件版本链；建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。阶段 3 硬件设计、阶段 5 板卡／样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。
V0.102026-08-28HISTORICAL校正嵌入式底层的阶段 3 设计职责；完善 Low-Level Implementation Package 最低内容、可消费／修复／归档版演进、板卡／BOM／ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界；扩充流程图底层成果说明。阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。
V0.92026-08-28HISTORICAL校正嵌入式应用层的阶段 3 设计职责；完善 Application Firmware Package 最低内容、候选／提测／回归／发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束；继续清理项目Hub旧称和广播表述。阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。
V0.82026-08-28HISTORICAL新增文档内版本变更记录、版本号口径和历史文件保留规则；从本版本起不再通过重命名覆盖上一版。全局导航、版本管理、项目Hub流程基线引用。
V0.72026-08-28HISTORICAL修正技术负责人在阶段 3 与阶段 4 的责任顺序；明确总体方案、软硬件接口契约和架构决策的主责；明确项目Hub维护版本矩阵、技术负责人确认版本匹配。阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。
V0.62026-08-28HISTORICAL统一产品角色的阶段 2 与阶段 7 正式成果；补齐产品发起早期风险预检、产品定义评审和验收闭环；客户平台资料改为参考输入基线。阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。
V0.5未登记HISTORICAL BASELINE建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7；形成正式成果追踪矩阵。总流程、项目Hub、全局信息流、门禁和成果追踪。
-
-
- -
-
-
-

从业务需求到发布结项

-

主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。

-
-
- 白色卡片＝项目阶段 - 黄色门＝角色/阶段确认 - 红色虚线＝返工回路 -
-
- -
-
-
01
-

业务需求

主责：业务
-
明确问题与价值。补齐业务目标、范围、规则、优先级和可度量成功指标。
-
正式成果Project Background Brief（项目背景说明）
客户信息：客户名称、最终客户名称
项目名称：统一名称或客户规定的项目代号
产品要求：产品形态、提测平台
项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景：客户为什么提出这个需求，要解决什么问题
业务目标：本项目希望实现的业务结果
预期价值：可验证的价值假设
成功指标：可度量的结果与判断方式
订单、金额等信息仅在项目适用时作为可选补充Project Milestone Plan（项目目标与里程碑计划）
提测时间
入库时间
小批量试产时间
量产时间
-
-
业务确认需求基线
- -
-
02
-

产品定义

主责：产品 · 批准：业务
-
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。
-
正式成果Project Initiation Package（立项资料）
立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能
灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息
结构板框图：包含主要器件位置和禁止限制区域Test & Acceptance Criteria（测试验收标准）
平台测试用例
客户验收测试用例和验收标准Milestone Requirements（里程碑要求）
提测时间
客户验收时间
试产、量产时间
-
-
产品确认方案，业务批准范围
- -
-
03
-

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
-
基于产品定义和前期可行性评估形成可实施方案。
技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件：原理图、PCB、BOM、电源/信号/热设计测试：范围、环境、用例、通过标准
-
正式成果Solution Architecture（总体技术方案）Software/Hardware Interface Contract（软硬件接口契约）Hardware Design Package（硬件设计包）Architecture Decision Record（架构决策记录）Test Plan（测试计划）
-
-
技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证
- -
-
04
-

项目规划

主责：项目Hub
-
基于已确认的产品基线和方案设计成果，生成实际任务、人员分工、排期和风险计划。任务计划草案先由技术负责人确认；项目Hub只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。
-
正式成果Project Plan（项目计划）
项目任务拆分
实际项目排期Risk Register（项目风险）
技术风险
时间风险
其他风险Role Assignment（角色分工）
语义角色与项目实际 role_id
role_member_id / session_id / human_owner
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
同一账户在同一项目只承担一个语义角色；同一角色允许配置多个账户Product Documentation Package（产品资料整合）
现有器件规格和板框约束
平台 SDK、串号表
平台对接文档
平台接入标准及开发规范
方案设计成果索引
其他项目输入参考资料Project Status Record（项目状态内部记录）
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化
-
-
技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认实际人员、资源与日期基线
- -
-
05
-

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件
-
嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口、任务或器件约束发生重大偏离时返回技术负责人和项目Hub确认。
-
正式成果Hardware Implementation Package（硬件实现资料）
正式原理图源文件与 PDF、PCB 源文件
Gerber、钻孔、拼板、层叠/阻抗和工艺说明（如适用）
PCBA BOM、器件位置图、贴片坐标、极性、DNI/NC 信息
维修原理图、关键测试点和生产测试接口
板卡/样机/批次标识、BOM 和 ECO 版本
接口定义、板级调试和静态/测量证据
与底层、应用固件、配置和接口契约的版本关系
已知限制、风险、返修/回退和 supersedesLow-Level Implementation Package（嵌入式底层实现资料）
BSP/PSP、Bootloader、驱动、RTOS、HAL 和系统服务源码/输出引用
工具链、构建参数、输出路径和可复现说明
适配板卡、BOM/ECO、配置和接口契约版本
API/HAL、初始化、资源、时序、错误与恢复说明
硬件功能测试、自测、日志、波形/测量证据
专项测试固件（如适用，标明 TEST_UTILITY_ONLY）
应用层集成说明、Changelog、已知限制和风险Application Firmware Package（嵌入式应用层固件包）
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
日志文件
Changelog
串口使能证书
-
-
嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配
- -
-
06
-

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件
-
执行功能、接口、软硬件集成和回归测试。
不通过应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人
通过形成五类测试正式成果及质量结论
-
正式成果Functional Test Report（功能测试报告）
功能、流程、状态、配置、接口、异常与恢复
Acceptance Criteria 追踪
用例状态统计、缺陷、回归和质量结论Reliability Test Report（可靠性测试报告）
样本、环境、仪器、时长/循环和负载
高低温、跌落及其他适用项
原始数据、失效、恢复和不可逆变化Specialized Test Report（专项测试报告）
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项
专项矩阵、阈值来源、原始证据和分项结论Test Evidence Package（测试证据包）
证据索引和用例/标准映射
原始日志、截图/视频、测量、波形、平台结果和文件校验Defect Analysis Report（缺陷分析报告）
现象、版本、环境、复现、期望/实际、频率和证据
Severity/风险/优先级、建议责任边界、根因/修复引用、复验与状态
-
-
测试确认质量结论和剩余风险
- -
-
07
-

业务验收

主责：产品
-
依据成功指标、验收标准和质量证据作最终判断。
驳回需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试
通过形成正式业务验收结论，进入发布准备
-
正式成果Platform Test Approval Report（平台提测通过报告）Customer Acceptance Approval Report（客户验收通过报告）Conditional Acceptance Items（附条件验收事项）
-
-
业务批准验收结论和上线条件
- -
-
08
-

发布结项

项目Hub协调 · 技术负责人确认 · 嵌入式应用层/嵌入式底层/硬件执行 · 测试验证
-
检查应用、固件、板卡版本、BOM/ECO、发布清单、冒烟、回滚和遗留事项承接。项目Hub汇总复盘并归档角色会话。
-
正式成果Closure Documentation Archive（结项资料归档）
形成最终结果的流程文件Change Log（变更记录）Closure Report（结项报告）Process Closure Summary（流程闭环总结）
-
-
- -
- 贯穿全流程：Change Request（需求变更申请） -

任何角色都可提出变更；项目Hub组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，业务批准后更新对应基线，并从受影响阶段继续推进。

-
-
- 成果适用性：Artifact Waiver（成果文件豁免） -

阶段成果默认必须由主责角色输出；仅当主责角色提交不适用申请、项目Hub完成项目级适用性与影响审查并取得必要确认后，才能将该成果标记为 WAIVED。未批准的成果仍为 REQUIRED，并继续阻塞阶段门禁。

-
-
- -
-
-
STAGE INFORMATION FLOW ATLAS · V0.13
-

各阶段角色信息流图谱

-

以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

-
- 通用规则成果追踪矩阵01 业务需求02 产品定义03 方案设计04 项目规划05 软硬件实现06 测试验证07 业务验收08 发布结项变更与异常成果豁免 -
-
绿色：正式成果、候选成果或正式基线黄色：过程记录、关联成果或修订对象
-
-
-
-
00 / RULES
-

所有阶段共同遵守的流转规则

角色可以直接讨论，但讨论不能自动成为项目事实；正式结论必须回到项目Hub，经过校验、登记和重新分发。

-
-
唯一正式路径：触发事件 → 主责角色内部完成 AI 辅助自审与人工确认 → 以统一角色主体提交项目Hub → 项目Hub做形式校验、版本/证据检查和跨角色冲突检查 → 路由目标角色 → 目标角色内部确认后形成正式结果 → 项目Hub登记与分发下游 → 更新门禁。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。
-
成果默认 REQUIRED：主责角色必须输出；确认不适用时必须走 Artifact Waiver 流程。只有 APPROVED 的 WAIVED 状态可以替代成果满足门禁，任何角色都不得静默删除或跳过文件。
-
- 项目Hub业务产品技术负责人嵌入式应用层嵌入式底层硬件测试 -
-
- - - -
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付。不能替其他角色作出专业确认。
业务是；同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外，负责确认计划基线、真实资源、预算、采购/打样、日期、暂停/取消和高影响成果豁免。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
项目Hub是项目Hub负责维护中心 AI Codex，是项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和低影响豁免；高影响事项必须升级给业务。不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。
-
角色与成员配置：图中的八个角色是当前默认基线，不是永久封闭的角色集合。项目可新增自定义角色，但必须先定义角色目标、职责边界、参与阶段、正式成果、上下游依赖、确认权限，以及 role_id、role_member_id、session_id 和 human_owner。项目创建时由项目Hub建立成员登记；阶段 4 再通过 Role Assignment 将实际成员、任务主责和交接关系正式基线化。
-
账户与状态规则：同一 Codex 账户在同一项目原则上只承担一个语义角色；同一角色允许多个账户或会话共同承担，但每个 SUBTASK 必须指定唯一主责成员。项目模式、任务结果、成果生命周期、成果适用性、阶段门禁、测试结论和业务验收是不同状态层，禁止相互替代；字段 internal_approved=true 只表示角色内部确认完成，不等于成果已经进入 INTERNALLY_APPROVED 生命周期状态。统一使用“不适用（NA）”。
-
-
任意角色
G.1提交已完成内部审查确认的消息、成果或请求附 self_check_result、internal_approved、项目、任务、版本和证据引用
项目Hub
-
项目Hub
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
-
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录
项目Hub
-
-
项目状态内部记录与按需同步：Project Status Record（项目状态内部记录）是项目Hub持续维护的内部运行记录，不是新增角色。项目创建至阶段 3 的记录属于过程状态，阶段 4 将其正式化为成果；它汇总当前阶段、门禁、任务、依赖、阻塞、风险、决策、成果基线、下一步和时限。项目Hub在关键状态变化时主动推送，也响应角色按项目、阶段或任务发起的查询。
-
-
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态指定 project_id、stage/task scope、关注项和期望时点
项目Hub
-
项目Hub
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回
请求角色及受影响角色
-
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
项目Hub
-
项目Hub
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前项目、阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。任意角色 → 项目Hubproject_id、请求范围、关注字段、所需详细度、as_of 要求和用途。只能查询项目授权范围内的信息；请求角色无需知道项目的内部存储结构。创建一次按需状态查询。
S.2收到 S.1；或阶段/门禁、任务分派、依赖、阻塞、风险、决策、成果基线、required_by 发生关键变化。项目Hub → 请求角色及受影响角色Project Status Snapshot：project_id、state_version、as_of、stage/gate、相关任务、依赖、阻塞、风险、决策、baseline_refs、next_actions、required_by、evidence_refs。按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 项目HubACK；或 correction_request、受影响字段、正确值、原因、evidence_refs、internal_approved。没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。确认可继续执行，或触发状态纠正。
S.4纠正请求通过身份、版本、证据及跨角色一致性检查。项目Hub → 全部受影响角色新 state_version、变更字段、旧值/新值、变更原因、证据、生效时间及受影响任务。保留状态历史，不覆盖旧版本；改变正式基线时必须转入 Change Request。相关角色切换到新的有效状态快照。
-
异常协同补充机制：任何条件流、阻塞流、跨角色冲突或无法在时限内异步收敛的问题，都必须进入 E.1–E.4。项目Hub主动提醒关联角色并提供完整问题包；问题复杂时建议由当前主责角色组织线下会议。会议本身不直接形成项目事实，只有参与角色统一确认并回传项目Hub的结构化结论，才能登记并恢复原流程。
-
-
项目Hub
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
-
项目Hub
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
-
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
项目Hub
-
项目Hub
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果
原流程及关联角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。项目Hub → 当前主责角色及全部关联角色issue_id、source_flow_id、问题摘要、证据与版本引用、冲突点、影响范围、关联角色、required_by。项目Hub必须主动提醒，不得只更新状态；关联角色依据正式问题包开展异步确认。原流程保持 ACTIVE/BLOCKED，等待问题关闭。
E.2涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。项目Hub → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。项目Hub只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。会议结论回传前，不恢复原流程。
E.3线下会议完成并形成统一结论。当前主责角色 → 项目HubMeeting Decision Record：参与角色、统一结论、保留分歧、变更项、责任角色、期限、artifact/version/evidence_refs、internal_approved。禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过项目Hub的形式、版本、证据和跨角色一致性检查。项目Hub → 原流程及关联角色decision_id、登记结果、受影响成果/任务、恢复点、后续动作和新时限。项目Hub不改写专业结论；若结论改变正式基线，必须转入 Change Request。从 source_flow_id 对应位置恢复当前流程。
-
- - - - - - - - - - - - -
通用约束执行要求不满足时
消息身份必须包含 project_id、task_id、message_id、from/to role、stage、reply_to。拒绝进入正式流。
成果版本必须包含 artifact_id、version、status、supersedes、evidence_refs。标记为 DRAFT 或 REJECTED_ARTIFACT。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签；项目Hub返回主责角色。
角色内部审查每个角色必须在内部完成 AI 辅助的 Schema/专业检查以及人工确认；跨角色流转时统一以正式角色名称表示。未附 self_check_result 或 internal_approved 的成果不能提交项目Hub。
专业发起权专业活动由对应主责角色判断并发起；项目Hub只负责格式校验、任务路由、状态跟踪和结果登记。项目Hub不得越权替角色发起专业决策。
项目Hub审查边界仅做 Schema/必填结构、身份、版本、证据、审批状态检查，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请；经项目Hub审查及必要确认后标记 WAIVED。未批准仍为 REQUIRED，继续阻塞门禁。
角色确认专业结论由对应角色内部形成并确认；项目级组织授权由业务内部完成。信息流图只显示统一的正式角色主体。未完成内部确认时不得对外发出，阶段保持 WAITING_CONFIRMATION。
项目状态同步项目Hub维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同项目对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。
直接讨论最终结论、约束、证据和影响必须回传项目Hub。不能作为下游输入。
门禁只有成果完整、版本正确、证据可访问、确认齐全时才能 PASS。阶段保持 ACTIVE/BLOCKED。
-
- -
-
00B / ARTIFACT TRACEABILITY

正式成果—信息流追踪矩阵

流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。

-
判定原则：正式成果必须由指定主责角色输出；过程记录只能解释校验、评审、冲突、变更和确认，不得替代正式成果。若某项成果经批准标记为 WAIVED，则以下对应流转中的成果引用替换为 waiver_id 和替代证据。
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
阶段正式成果主责角色首次形成/提交评审、修订与确认正式分发/下游使用
1 业务需求Project Background Brief（项目背景说明）业务F1.1F1.2 条件修订；F1.7 业务确认F1.3 评审分发；F1.8 正式基线给产品
1 业务需求Project Milestone Plan（项目目标与里程碑计划）业务F1.1F1.2 条件修订；F1.7 业务确认F1.3 评审分发；F1.8 正式基线给产品
2 产品定义Project Initiation Package（立项资料）产品F2.2F2.3–F2.6 专业评审与修订；F2.7–F2.8 业务批准F3.1 方案设计输入；F4.1 项目规划输入
2 产品定义Test & Acceptance Criteria（测试验收标准）产品F2.2F2.3–F2.6 测试评审；F2.7–F2.8 业务批准F3.7 Test Plan 输入；F6.1 测试输入；F7.1 验收输入
2 产品定义Milestone Requirements（里程碑要求）产品F2.2F2.3–F2.6 专业评审；F2.7–F2.8 业务批准F4.1 Project Plan 输入；S.2 状态同步
3 方案设计Solution Architecture（总体技术方案）技术负责人F3.2F3.4–F3.8 修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F8.7 归档
3 方案设计Software/Hardware Interface Contract（软硬件接口契约）技术负责人F3.2F3.4–F3.8 多角色修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F5.7 冲突回溯
3 方案设计Hardware Design Package（硬件设计包）硬件F3.3/F3.6F3.8–F3.10 技术负责人及相关角色确认F4.1 项目规划输入；F5.1/F5.2 硬件实现输入
3 方案设计Architecture Decision Record（架构决策记录）技术负责人F3.2；F3.4–F3.6 持续补充F3.8–F3.10 确认；X 流程变更时追加F4.1 项目规划输入；F5.1 实现约束；F8.7 归档
3 方案设计Test Plan（测试计划）测试F3.3/F3.7F3.8–F3.10 多角色确认F4.1 测试任务规划输入；F6.1 测试任务输入
4 项目规划Project Plan（项目计划）项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 定向修订；F4.6–F4.7 业务授权F4.8 分发相关执行角色；F5.1 实现任务输入；后续由 X 流程变更
4 项目规划Risk Register（项目风险）项目HubF4.1，引用 F1.5–F1.6 预检和阶段3方案风险F4.2–F4.7 更新与确认；E/X 流程持续更新F4.8 分发；F5.1 实现风险输入；S.2 按角色同步
4 项目规划Role Assignment（角色分工）项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 问题任务修订F4.8 随正式任务分发；F5.1 实现责任输入
4 项目规划Product Documentation Package（产品资料整合）项目HubF4.1F4.2 技术负责人检查产品与方案输入引用F4.8 按角色裁剪分发；F5.1 实现输入
4 项目规划Project Status Record（项目状态内部记录）项目HubF4.1 初始执行记录S.3–S.4 证据化纠正；E/X 流程更新F4.8 初始执行快照；S.2 自动或按需分发
5 软硬件实现Hardware Implementation Package（硬件实现资料）硬件F5.2F5.7 冲突修订；F5.8–F5.10 版本匹配确认F6.1 测试输入；F8.3 归档
5 软硬件实现Low-Level Implementation Package（嵌入式底层实现资料）嵌入式底层F5.4F5.5 交嵌入式应用层合版；F5.7/F5.10 确认版本关系通过 F5.6 集成进统一固件；F8.3 提交归档资料
5 软硬件实现Application Firmware Package（嵌入式应用层固件包）嵌入式应用层F5.6 候选；F5.9 最终提测版F5.7 冲突修订；F5.8–F5.10 技术负责人确认F6.1 交测试；F6.8 回归版；F8.3 最终发布版
6 测试验证Functional Test Report（功能测试报告）测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证Reliability Test Report（可靠性测试报告）测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证Specialized Test Report（专项测试报告）测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证Test Evidence Package（测试证据包）测试F6.2F6.3–F6.9 持续补证；F6.10 完整性确认F7.1/F7.3 验收证据；F8.5 最终证据
6 测试验证Defect Analysis Report（缺陷分析报告）测试F6.2/F6.3F6.4–F6.9 责任角色修复并由测试回归；F6.10 确认F7.1 验收限制输入；F8.7 归档
7 业务验收Platform Test Approval Report（平台提测通过报告）产品F7.2F7.3–F7.7 验收与修订；F7.8 业务确认F8.6 结项核对；F8.7 归档
7 业务验收Customer Acceptance Approval Report（客户验收通过报告）产品F7.2F7.3–F7.7 客户/业务验收与修订；F7.8 业务确认F8.6 结项核对；F8.7 归档
7 业务验收Conditional Acceptance Items（附条件验收事项）产品F7.2/F7.4F7.6–F7.8 补充责任角色、期限并确认F8.6 关闭或承接；写入 Closure Report
8 发布结项Closure Documentation Archive（结项资料归档）项目HubF8.7–F8.8F8.1–F8.7 汇集输入；F8.9 完整性确认项目关闭后锁定归档
8 发布结项Change Log（变更记录）项目HubX.1–X.5 持续记录；F8.8 汇总每次 Change Decision 更新；F8.9 结项检查随 Closure Documentation Archive 锁定
8 发布结项Closure Report（结项报告）项目HubF8.8F8.4–F8.7 提供输入；F8.9 业务确认项目关闭依据与归档入口
8 发布结项Process Closure Summary（流程闭环总结）项目HubF8.8F8.7 角色摘要输入；F8.9 业务确认经验复用与后续案例检索
-
- -
-
01 / BUSINESS

阶段 1：业务需求信息流

把客户背景、业务目标和关键里程碑转换成经过业务角色内部确认的需求基线。

-
主责业务
核心成果项目背景说明、项目目标与里程碑计划
门禁业务完成内部审查并确认需求基线
-
业务在内部完成原始信息收集、业务成果 Schema 检查和人工确认后，以统一的“业务”主体提交成果。项目Hub完成形式校验、版本登记和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。项目Hub只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，项目Hub再向产品分发正式业务基线并开启产品定义。
-
-
业务
F1.1提交完成内部审查的项目背景与里程碑草案附 self_check_result、internal_approved 和来源引用
项目Hub
-
项目Hub
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限 Schema、身份、版本、证据和已登记信息冲突；无异常则不启用此流
业务
-
项目Hub
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
-
产品
F1.4指定对象角色并提交早期风险预检请求产品根据风险内容选择一个或多个专业角色
项目Hub
-
项目Hub
F1.5按产品指定名单校验、提醒并路由预检任务主动提醒全部关联角色；不得增删产品指定名单
产品指定的对象角色
-
产品指定的对象角色
F1.6返回内部确认结果；复杂问题返回统一会议结论无法异步收敛时，由产品组织线下会议并按 E.3 回传
项目Hub
-
业务
F1.7确认需求基线业务内部审查、形式校验和预检问题均已关闭
项目Hub
-
项目Hub
F1.8向产品分发正式业务基线并开启产品定义只能引用已 BASELINED 的成果版本
产品
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户需求或业务机会，且业务已完成原始信息收集、Schema 自审和内部确认。业务 → 项目Hub正式成果草案：Project Background Brief（项目背景说明）、Project Milestone Plan（项目目标与里程碑计划）。
附带内容：self_check_result、internal_approved、来源引用、artifact_id、version。		项目Hub不重复判断业务内容质量，只检查形式和跨来源一致性。进入中心登记。
F1.2（条件流）仅当 Schema/身份/版本/证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。项目Hub → 业务过程记录：Formal Validation Issue List（形式校验问题清单）或 Conflict List（冲突清单）。
关联成果：受影响的项目背景说明/项目目标与里程碑计划及其字段、版本、冲突来源和修正要求。		项目Hub不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。
F1.3业务成果通过项目Hub的 Schema、身份、版本、证据和跨角色冲突检查并完成登记。项目Hub → 产品评审分发成果：REVIEW_READY 的 Project Background Brief、Project Milestone Plan。
附带内容：artifact_id、version、status、evidence_refs、待确认项和回复时限。		状态必须标明 REVIEW_READY；不得冒充 BASELINED 正式成果，产品不得据此直接启动阶段 2。产品获得早期风险识别所需上下文。
F1.4产品审阅业务成果后，判断存在需要其他专业角色提前确认的风险。产品 → 项目Hub过程记录：Early Risk Precheck Request（早期风险预检请求）。
关联成果：项目背景说明/里程碑计划的相关字段与版本；另含预检原因、问题、target_role_ids、期望输出和时限。		是否预检、预检范围及对象角色均由产品负责指定；项目Hub不代替产品判断。按产品指定名单创建预检任务。
F1.5–1.6产品预检请求格式完整，且指定的对象角色均为当前项目有效成员。项目Hub ↔ 产品指定的对象角色过程记录：Role Precheck Task / Precheck Result（角色预检任务/结论）。
关联成果：项目背景说明、项目目标与里程碑计划；返回本专业红线、风险、证据、待澄清项和受影响字段，作为后续 Risk Register 输入。		项目Hub必须主动提醒全部关联角色，只校验、路由和汇总，不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时，建议由产品组织线下会议；参与角色统一确认的结论按 E.3 回传后，才能继续当前流程。补充业务澄清和早期风险登记；复杂问题进入 E.1–E.4，闭环前保持阻塞。
F1.7业务内部审查、中心形式校验和预检问题均已关闭。业务 → 项目Hub确认成果：INTERNALLY_APPROVED 的 Project Background Brief、Project Milestone Plan。
附带内容：确认状态、确认时间、确认条件和版本。		角色内部确认状态、时间和版本必须记录。门禁可进入评审。
F1.8业务确认完成，项目Hub已登记 BASELINED 正式版本且阶段门禁 PASS。项目Hub → 产品正式基线：BASELINED 的 Project Background Brief、Project Milestone Plan。
附带内容：artifact_id、version、baseline_refs、evidence_refs、阶段 2 任务和确认时限。		只允许分发 BASELINED 当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
-
- -
-
02 / PRODUCT

阶段 2：产品定义信息流

产品形成完整立项资料，并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。

-
主责产品；业务批准范围
核心成果立项资料、测试验收标准、里程碑要求
门禁产品确认方案，业务批准范围，约束和测试标准完整
-
-
项目Hub
F2.1下发产品定义任务附阶段 1 基线和全部红线约束
产品
-
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
-
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
-
项目Hub
F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突，不替产品作内容决定
产品
-
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
项目Hub
-
项目Hub
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
-
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。项目Hub ↔ 产品输入基线：Project Background Brief、Project Milestone Plan。
产品提交的正式成果草案：Project Initiation Package、Test & Acceptance Criteria、Milestone Requirements。
参考输入（非阶段成果）：项目已有的器件规格、板框约束、平台 SDK、串号表、平台对接文档和开发规范。		产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试评审分发成果：按角色裁剪上述三类产品定义成果草案。
参考输入：只附与评审问题相关的现有器件、板框和平台资料；另含 artifact/version、baseline_refs、评审范围、问题和时限。		项目Hub只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub过程记录：Role Review Result（角色评审结论）。
关联成果：三类产品定义成果的具体字段；提交结论、缺失、风险、证据、建议和是否阻塞。		不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。项目Hub ↔ 产品修订成果：受影响的 Project Initiation Package、Test & Acceptance Criteria、Milestone Requirements 新版本。
附带内容：字段级修订清单、变更影响和关闭说明。		产品在内部确认最终版本后统一发出。问题未关闭则 HOLD。
F2.7–2.8产品方案专业评审完成。项目Hub ↔ 业务批准成果包：三类产品定义成果的 INTERNALLY_APPROVED 候选版本。
附带内容：范围、验收、里程碑、风险、附条件事项、版本和确认状态。		范围批准由业务完成内部授权后统一给出。批准后登记为 BASELINED 并进入阶段 3。
-
- -
-
03 / DESIGN

阶段 3：方案设计信息流

技术负责人依据产品定义基线和前期风险评估组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。

-
主责技术负责人主责总体方案、接口契约和架构决策；硬件与测试分别主责本角色成果
核心成果总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划
门禁方案确认、接口可实施、需求不偏离、测试可验证
-
-
项目Hub
F3.1下发总体方案设计任务附产品定义基线、前期风险结论和现有技术参考资料
技术负责人
-
技术负责人
F3.2提交总体方案与接口契约草案含边界、关键决策、非功能和风险
项目Hub
-
项目Hub
F3.3并行分发角色化设计任务每个角色在同一契约版本上工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
-
嵌入式底层
F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
项目Hub → 硬件 / 技术负责人
-
硬件
F3.6反馈器件、PCB、电源、空间与热约束影响接口、成本或性能时
项目Hub → 技术负责人 / 嵌入式底层 / 产品
-
测试
F3.7提交不可测试项和环境/治具缺口验收标准无法验证时
项目Hub → 相关角色
-
项目Hub
F3.8汇总冲突并要求总体方案修订形成决策清单和待关闭问题
技术负责人
-
技术负责人
F3.9提交内部确认的最终方案和契约基线所有阻塞问题关闭后
项目Hub
-
项目Hub
F3.10请求各角色确认接口可实施嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.3阶段 2 门禁通过，产品定义基线和前期风险结论有效。项目Hub ↔ 技术负责人/协作角色按主责角色分别形成的正式成果草案：技术负责人输出 Solution Architecture、Software/Hardware Interface Contract、Architecture Decision Record；硬件输出 Hardware Design Package；测试输出 Test Plan。
输入内容：阶段2三类产品成果、现有技术参考资料、F1.5–F1.6 预检结论、设计范围和时限。		方案设计不得依赖尚未形成的 Project Plan；所有设计必须引用同一产品基线。开启并行方案设计。
F3.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人修订对象：Software/Hardware Interface Contract、Solution Architecture、Architecture Decision Record。
提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。		不得绕过契约直接约定。可能触发契约修订。
F3.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 项目Hub → 硬件 / 技术负责人修订对象：Software/Hardware Interface Contract、Hardware Design Package、Architecture Decision Record。
提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。		硬件回复必须引用板卡版本。冲突时阻塞相关设计。
F3.6器件、PCB、电源、空间或热约束影响方案。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品修订成果：Hardware Design Package；必要时同步修订 Solution Architecture、Software/Hardware Interface Contract、Architecture Decision Record。
提交内容：限制、替代方案、成本、性能和交期影响。		器件替换不得静默发生。形成 ADR/Change Request。
F3.7测试无法验证某项需求或缺环境/治具。测试 → 项目Hub → 相关角色修订对象：Test Plan、Software/Hardware Interface Contract；必要时回溯 Test & Acceptance Criteria。
过程记录：Testability Gap List，包含不可测项、证据要求、环境和治具需求。		必须在实现前关闭。门禁 HOLD。
F3.8–3.10专业评审完成。项目Hub ↔ 技术负责人 ↔ 产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试最终确认成果：Solution Architecture、Software/Hardware Interface Contract、Hardware Design Package、Architecture Decision Record、Test Plan 的 INTERNALLY_APPROVED 版本。
附带内容：角色确认、保留风险、evidence_refs 和统一版本关系。		每个确认绑定同一版本。全部确认并登记为 BASELINED 后进入阶段 4 项目规划。
-
- -
-
04 / PLANNING

阶段 4：项目规划信息流

项目Hub根据产品基线和已确认的方案设计成果生成实际任务计划，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。

-
主责项目Hub；技术负责人确认任务计划的技术结构
核心成果项目计划、风险登记、角色分工、产品资料整合、项目状态内部记录
门禁技术负责人确认技术任务结构、顺序和依赖；问题任务完成定向确认；业务确认资源与日期基线
-
-
项目Hub
F4.1提交任务计划与正式角色分工草案，请求整体确认附产品/方案基线、成员登记、WBS、技术顺序、依赖、初始排期和风险
技术负责人
-
技术负责人
F4.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系、专业角色覆盖和关键风险
项目Hub
-
项目Hub
F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
-
对应执行角色
F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
项目Hub
-
项目Hub
F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
-
项目Hub
F4.6请求资源与日期基线授权真实人员、采购、打样、成本和日期由业务内部确认
业务
-
业务
F4.7批准或要求调整资源与日期基线记录内部批准状态、范围和条件
项目Hub
-
项目Hub
F4.8向相关执行角色发布基线计划和正式任务附任务 ID、依赖、交付物和门禁；后续状态按 S.1–S.4 同步
相关执行角色
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.2阶段 3 方案设计门禁通过，项目Hub已依据产品基线、方案设计成果和项目创建期成员登记形成任务计划草案。项目Hub ↔ 技术负责人正式成果草案：Project Plan、Risk Register、Role Assignment、Product Documentation Package、Project Status Record 初始版。Role Assignment 必须列出 semantic_role、项目实际 role_id、role_member_id/session_id、human_owner、任务主责、协作关系和交接要求。
输入基线：阶段2产品成果、阶段3五类方案设计成果和成员登记；另含 WBS、关键路径、输入输出、依赖、初始排期和风险。		技术负责人确认技术任务结构、顺序、依赖、版本关系、专业角色覆盖和技术风险；项目Hub不直接向全部执行角色征求整份计划确认。同一账户在同一项目只承担一个语义角色，同一角色可配置多个账户，但每个 SUBTASK 只设一个主责成员。形成技术结构与角色覆盖已确认的任务计划草案。
F4.3–4.4（条件流）项目Hub发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。项目Hub ↔ 对应执行角色修订对象：Project Plan、Risk Register、Role Assignment、Project Status Record 中的问题任务。
过程记录：Task Clarification Request / Response，包含 task_id、方案成果引用、上下游依赖、工期、资源、风险和 internal_approved。		必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务；未触发时直接跳过。
F4.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。项目Hub ↔ 技术负责人及受影响角色修订成果：Project Plan、Risk Register、Role Assignment、Project Status Record 新版本。
过程记录：Conflict Resolution Record，包含冲突点、方案约束、可选排法、阶段影响和响应时限。		项目Hub必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。保持计划草案，冲突关闭前不得基线化。
F4.6–4.7技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，计划涉及真实人员、采购、打样、成本或日期基线。项目Hub ↔ 业务授权成果：Project Plan、Risk Register、Project Status Record 候选基线。
附带内容：资源请求、成本、里程碑、风险、授权范围、条件和确认状态。		项目Hub无权自行批准现实资源和日期；业务完成内部授权后统一回复。批准后可基线化。
F4.8技术负责人确认有效、问题任务已关闭且业务批准资源与日期基线。项目Hub → 相关执行角色正式基线：BASELINED 的 Project Plan、Risk Register、Role Assignment、Product Documentation Package。
状态快照：Project Status Snapshot，包含角色相关任务、成员/会话映射、依赖、方案成果引用、门禁、风险和时限。		每个角色只接收与自身任务和依赖相关的计划内容；后续成员加入、退出、替换或角色变化必须登记并交接，改变基线时走 Change Request；执行状态按 S.1–S.4 同步。相关角色接收任务，开启阶段 5。
-
- - - -
-
05 / IMPLEMENT

阶段 5：嵌入式软硬件实现信息流

三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进；固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，项目Hub维护其与硬件版本的唯一映射。

-
并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测
-
-
项目Hub
F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界
嵌入式应用层 / 嵌入式底层 / 硬件
-
硬件
F5.2提交板卡、BOM、接口与样机版本硬件发布或 ECO 时触发
项目Hub
-
项目Hub
F5.3向受影响角色定向分发硬件版本及约束变化只向实际受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
-
嵌入式底层
F5.4提交可消费的底层实现包包含 BSP/PSP、Bootloader、驱动、RTOS、HAL，并绑定板卡、BOM/ECO、工具链、配置和契约版本
项目Hub
-
项目Hub
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版测试不得直接将底层产物作为提测固件
嵌入式应用层
-
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层、板卡和契约版本，包含 MD5、分区、自测和 Changelog
项目Hub
-
任一实现角色
F5.7报告接口、器件或资源冲突契约不一致、资源超限或 ECO 影响时
项目Hub → 技术负责人
-
项目Hub
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
-
嵌入式应用层
F5.9提交最终提测固件版本最终固件只能由嵌入式应用层提交，附完整版本链、自测和偏离说明
项目Hub
-
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测板卡、BOM、统一固件及其应用/底层版本链完全匹配
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1阶段 4 项目规划门禁通过。项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件待产出成果：Application Firmware Package、Low-Level Implementation Package、Hardware Implementation Package。
输入与任务：阶段3方案设计基线、阶段4 Project Plan（项目任务计划）、Role Assignment（角色分工）、Risk Register（项目风险），以及任务、输出格式、依赖和期限。		三方必须使用相同契约和项目计划版本。启动并行实现。
F5.2–5.3硬件发布样机、板卡、BOM 或 ECO。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试正式成果：Hardware Implementation Package 当前版本。
提交内容：正式原理图源文件与 PDF、PCB 源文件；Gerber、钻孔、拼板、层叠/阻抗和工艺说明（如适用）；PCBA BOM、器件位置图、贴片坐标、极性、DNI/NC；维修原理图、关键测试点、接口和生产测试定义；`hardware_version`、原理图/PCB/BOM/ECO 修订号、板卡/样机/批次标识；板级调试、静态/测量证据；软件、配置和契约版本关系；限制、风险、返修/回退和 `supersedes`。		没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。影响接口、底层或应用固件时阻塞受影响任务。
F5.4–5.5嵌入式底层形成可消费版本。嵌入式底层 → 项目Hub → 嵌入式应用层正式成果：Low-Level Implementation Package 当前版本。
提交内容：BSP/PSP、Bootloader、驱动、RTOS、HAL、系统服务的源码/输出引用；工具链、构建参数、输出路径和可复现说明；适配板卡、BOM/ECO、配置和接口契约版本；API/HAL、初始化、资源、时序、错误与恢复说明；硬件功能测试、自测、日志、波形/测量证据；应用层集成说明、已知限制、风险和 `supersedes`。		必须声明适配板卡、BOM/ECO、配置和契约版本；专项测试固件须标明 TEST_UTILITY_ONLY；测试不得把底层产物直接作为提测固件。项目Hub登记后允许嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 项目Hub正式成果候选：Application Firmware Package。
提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、日志、Changelog、串口使能证书，以及应用/底层/板卡/契约版本链。		必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 项目Hub → 技术负责人过程记录：Implementation Conflict Record。
关联成果：受影响的 Hardware/Low-Level/Application Implementation Package 和 Interface Contract；提交冲突、证据、版本、影响和建议。		项目Hub立即冻结受影响版本。等待技术裁决或契约新版本。
F5.8–5.10统一固件候选和硬件候选均已提交，联调问题已经关闭。项目Hub ↔ 嵌入式应用层 / 硬件 / 技术负责人最终确认成果：Application Firmware Package、Hardware Implementation Package；引用已集成的 Low-Level Implementation Package。
过程记录：Version Matrix、Integration Record、Integration Approval；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。		最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由项目Hub将该唯一固件版本交给测试。
-
- -
-
06 / TEST

阶段 6：测试验证与缺陷返工信息流

测试提交证据和缺陷，项目Hub按问题层级路由到产品、嵌入式应用层、嵌入式底层、硬件或技术负责人，并控制重新提测。

-
主责测试
核心成果功能、可靠性、专项测试报告，测试证据和缺陷分析
门禁阻断缺陷清零，证据完整，测试完成内部确认并提交质量结论
-
-
项目Hub
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
-
测试
F6.2提交测试报告、证据和缺陷每个缺陷关联版本、用例和证据
项目Hub
-
项目Hub
F6.3按测试建议或专业裁决路由缺陷责任明确时定向路由；跨层问题交技术负责人，需求含义交产品
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F6.4返回内部确认的原因分析、修复计划和影响范围正式修复承诺在角色内部确认后统一发出
项目Hub
-
项目Hub
F6.5创建修复或技术裁决任务跨层问题交技术负责人，需求问题交产品
责任角色
-
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明 supersedes 和影响范围
项目Hub
-
项目Hub
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
-
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
项目Hub
-
项目Hub
F6.9下发定向回归任务和统一固件附修复范围、受影响用例和新版本矩阵
测试
-
测试
F6.10提交内部确认的最终质量结论和剩余风险报告和证据完整后
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。项目Hub ↔ 测试测试输入：Application Firmware Package、Hardware Implementation Package、已集成的 Low-Level Implementation Package、Version Matrix、Test Plan。
测试提交的成果草案：Functional Test Report、Reliability Test Report、Specialized Test Report、Test Evidence Package、Defect Analysis Report。		测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。启动测试并更新测试状态。
F6.3测试发现缺陷或测试异常并形成可追踪记录。测试 → 项目Hub → 建议责任角色 / 技术负责人 / 产品正式成果更新：测试主责的 Defect Analysis Report 缺陷条目。
提交与分发内容：defect_id、现象、版本矩阵、环境、用例、复现、期望/实际、证据、Severity/风险/优先级、建议责任边界、受影响成果、回归要求和响应时限。		项目Hub只做结构、证据和路由检查；责任明确时按测试建议路由，跨层或根因不清时交技术负责人，需求含义不清时交产品。建立定向返工或裁决任务。
F6.4–6.5责任角色或裁决角色收到缺陷任务。责任角色 / 技术负责人 / 产品 → 项目Hub → 测试过程记录：Root Cause Analysis、Fix Plan 或 Technical/Product Decision，包含根因或裁决、影响、修复方案、风险、修复成果计划、期限、需重测范围和证据。
测试动作：引用带来源的根因/修复/裁决输入，更新 Defect Analysis Report 状态和回归要求。		实现角色不直接替换或关闭测试主责的 Defect Analysis Report；“无法复现”、As Designed 或 Won’t Fix 必须带理由与证据。阻断缺陷使阶段 BLOCKED；等待修复成果和目标版本复验。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试实现角色修订成果：Application Firmware Package、Low-Level Implementation Package 或 Hardware Implementation Package。
提交给测试的缺陷输入：Root Cause Analysis、Fix Plan、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围；测试引用后更新 Defect Analysis Report。
硬件 ECO 额外内容：新旧板卡/PCB/BOM/ECO 差异、受影响批次、返工/回退方式、板级验证证据、底层驱动/HAL 兼容评估、应用固件有效性确认和新版本矩阵。		实现角色无权直接替换或关闭 Defect Analysis Report。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出 VERIFIED/CLOSED 结论。形成唯一可回归的固件与硬件版本矩阵，并由测试复验。
F6.9统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。项目Hub → 测试回归输入：更新后的 Application Firmware Package、相关 Low-Level/Hardware Implementation Package、Defect Analysis Report、Version Matrix。
过程记录：Regression Task，包含修复范围、受影响用例和时限。		旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10阻断缺陷清零且证据齐全。测试 → 项目Hub最终确认成果：Functional Test Report、Reliability Test Report、Specialized Test Report、Test Evidence Package、Defect Analysis Report 的 INTERNALLY_APPROVED 版本。
附带内容：质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。		测试内部确认状态必须记录；剩余风险必须有接受方。门禁通过后开启验收。
-
- -
-
07 / ACCEPT

阶段 7：业务验收信息流

产品组织平台和客户验收，项目Hub收集业务/客户结论，并把驳回问题精确路由到对应层级。

-
主责产品主责验收成果；项目Hub组织流转；业务批准
核心成果平台提测通过报告、客户验收通过报告、附条件事项
门禁业务完成内部确认并提交验收及上线条件
-
-
项目Hub
F7.1下发验收组织任务和证据包测试门禁通过后
产品
-
产品
F7.2提交平台/客户验收资料引用测试证据、版本和已知限制
项目Hub
-
项目Hub
F7.3发起验收确认呈现目标、证据、风险和附条件项
业务/客户
-
业务/客户
F7.4返回通过、驳回或附条件通过驳回必须描述场景和证据
项目Hub
-
项目Hub
F7.5分类并路由验收问题需求/嵌入式应用层/嵌入式底层/硬件/架构/证据
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F7.6提交修正、说明或风险处置形成新成果版本或正式解释
项目Hub
-
项目Hub
F7.7组织重新验证和再次验收只返回受影响阶段，不重启整个项目
产品/测试/业务
-
业务
F7.8提交内部确认的最终验收和上线条件附条件项必须有责任人和期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1–7.2测试门禁通过。项目Hub ↔ 产品验收输入：阶段 6 五类测试成果、Application Firmware Package、版本矩阵和已知限制。
产品提交的正式成果草案：Platform Test Approval Report、Customer Acceptance Approval Report、Conditional Acceptance Items。		产品不得隐藏已知风险。形成验收包。
F7.3–7.4验收包完整。项目Hub ↔ 业务/客户待确认成果：Platform Test Approval Report、Customer Acceptance Approval Report、Conditional Acceptance Items。
提交内容：目标对照、演示、测试证据、版本、通过/驳回/附条件结论和反馈证据。		口头反馈必须结构化回传。决定通过或返工。
F7.5验收驳回。项目Hub → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：Acceptance Rejection Record。
关联成果：三类验收成果及被驳回所影响的上游正式成果；包含问题类别、证据、字段/版本、责任角色和返回阶段。		禁止笼统地全部退回实现阶段。阶段保持 ACTIVE。
F7.6–7.7责任角色完成修正。角色 → 项目Hub → 产品/测试/业务修订成果：被驳回的上游正式成果新版本，以及更新后的 Platform/Customer Acceptance Approval Report 或 Conditional Acceptance Items。
附带内容：修正说明、验证结果、evidence_refs 和再次验收任务。		需要测试时必须先回测试阶段。重新验收。
F7.8验收通过或条件明确。业务 → 项目Hub最终确认成果：Platform Test Approval Report、Customer Acceptance Approval Report、Conditional Acceptance Items 的 INTERNALLY_APPROVED 版本。
附带内容：上线条件、附条件责任角色/期限和确认状态。		内部确认状态必须记录，条件不可为空泛。登记验收基线并开启发布结项。
-
- -
-
08 / CLOSE

阶段 8：发布结项信息流

项目Hub汇总应用、固件、板卡、BOM/ECO、测试和验收信息，形成完整归档和流程闭环。

-
协调项目Hub；技术负责人技术确认
核心成果结项资料归档、变更记录、结项报告、流程闭环总结
门禁版本匹配、冒烟通过、遗留事项有承接、归档完整
-
-
项目Hub
F8.1请求最终版本矩阵确认嵌入式应用层提交的最终固件必须绑定嵌入式底层、板卡和 BOM/ECO 版本
技术负责人
-
项目Hub
F8.2下发发布与归档任务按角色明确最终交付清单
嵌入式应用层 / 嵌入式底层 / 硬件
-
嵌入式应用层 / 嵌入式底层 / 硬件
F8.3分别提交最终固件、底层归档资料和 BOM/ECO最终固件只由嵌入式应用层提交；嵌入式底层不单独发布固件
项目Hub
-
项目Hub
F8.4请求发布冒烟与最终验证使用最终版本矩阵
测试
-
测试
F8.5提交冒烟结果和最终证据失败立即停止发布/结项
项目Hub
-
项目Hub
F8.6核对验收条件与遗留事项附条件项必须关闭或有承接
产品/业务
-
全部角色
F8.7提交内部确认的结项摘要和资料索引禁止只提供聊天记录
项目Hub
-
项目Hub
F8.8生成归档、变更记录和结项报告验证追踪链和缺失项
归档库
-
业务
F8.9确认结项或要求补充组织级结项由业务内部完成授权
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.3业务验收门禁通过。项目Hub ↔ 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件归档输入：Application Firmware Package 最终版、被集成的 Low-Level Implementation Package、Hardware Implementation Package、最终 Version Matrix 和角色发布声明。
将写入：Closure Documentation Archive、Change Log。		最终固件只由嵌入式应用层提交；嵌入式底层只提交被集成版本和归档资料；技术负责人确认整体版本匹配。形成发布候选。
F8.4–8.5发布候选锁定。项目Hub ↔ 测试过程记录：Release Smoke Test Record。
关联成果：Test Evidence Package、Closure Documentation Archive、Closure Report；提交冒烟任务、最终版本、结果和证据。		不得使用非最终版本。失败则停止发布并路由修复。
F8.6冒烟通过。项目Hub ↔ 产品/业务结项核对内容：Platform/Customer Acceptance Approval Report、Conditional Acceptance Items、未关闭风险和遗留事项。
将写入：Closure Report、Process Closure Summary。		每项必须关闭或有责任角色/期限。准备结项。
F8.7–8.8角色工作完成。角色 → 项目Hub → 归档库正式成果：Closure Documentation Archive、Change Log、Closure Report、Process Closure Summary。
角色提交内容：最终成果索引、版本、证据、变更记录、结项摘要和遗留事项；项目Hub生成可追踪结项包。		不能用聊天记录替代成果索引。生成结项包。
F8.9需要组织级结项确认。业务 → 项目Hub最终确认成果：Closure Report、Process Closure Summary 和 Closure Documentation Archive 完整性结论。
附带内容：结项批准或补充清单、确认状态和时间。		内部授权状态必须记录；补充项未关闭不得 CLOSED。批准后锁定四类结项成果并关闭项目。
-
- -
-
X / CROSS-CUTTING

贯穿全阶段：变更、阻塞与超时信息流

Change Request 和异常升级不属于某个单一阶段；项目Hub必须暂停受影响任务，组织并行影响评估，再决定是否重开阶段。

-
-
-
任意角色
X.1提交 Change Request 或 Blocker附原因、证据、受影响版本和紧急度
项目Hub
-
项目Hub
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
项目Hub
-
项目Hub
X.4提交综合影响和建议列出批准/拒绝/延期的差异
业务
-
业务
X.5批准或拒绝变更内部授权后生成新基线，不覆盖旧版本
项目Hub
-
项目Hub
X.6超时提醒与升级专业事项升级给对应角色；项目级组织授权升级给业务
对应角色
-
-
-
- - - - -
ID触发条件发送 → 接收提交内容（对应正式成果）约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。任意角色 → 项目Hub过程记录：Change Request 或 Blocker Record。
关联成果：当前 baseline_refs、受影响 artifact_ids/versions、任务、原因、证据和紧急度；批准后写入 Change Log。		必须关联当前基线和受影响任务。创建变更/阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。项目Hub ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：Role Impact Assessment。
提交内容：对受影响正式成果逐项给出范围、方案、工期、成本、测试、返工和版本影响，并列出建议修订的 artifact/version。		各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全。项目Hub ↔ 业务过程记录：Change Decision Record。
成果影响：综合影响矩阵、批准/拒绝/延期建议、新 baseline 候选；批准后更新 Change Log、相关正式成果和 Project Status Record。		不得隐藏已完成工作损失、成本或里程碑影响。批准：新基线并重开受影响阶段；拒绝：维持原基线。
X.6确认或任务超过 required_by。项目Hub → 对应角色；项目级组织授权事项发给业务过程记录：Escalation Notice。
提交内容：逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的 required_by。		接收角色在内部完成确认后统一回复。保持 WAITING_CONFIRMATION/BLOCKED。
-
- -
-
Y / ARTIFACT WAIVER

贯穿全阶段：成果文件缺省与豁免信息流

成果文件默认必须输出。只有主责角色能够发起“不适用”申请；项目Hub负责项目级审查、影响确认、批准登记和门禁更新，禁止任何角色静默跳过。

-
发起者该成果在流程中的主责角色
项目Hub确认项目Hub；高影响豁免还需相关角色和业务完成内部确认
门禁结果REQUIRED → WAIVER_REVIEW → WAIVED 或 REQUIRED
-
-
成果主责角色
Y.1提交 Artifact Waiver Request说明为何本项目不适用，并附证据和替代信息
项目Hub
-
项目Hub
Y.2校验发起资格与可豁免性非主责角色、无证据或 non-waivable 成果直接退回
主责角色
-
项目Hub
Y.3向下游角色征询影响成果有下游消费者、接口或验收影响时触发
受影响角色
-
受影响角色
Y.4返回同意、反对或附条件意见必须说明替代证据和门禁影响
项目Hub
-
项目Hub
Y.5请求业务确认高影响豁免影响范围、架构、质量、安全、客户验收或外部承诺时
业务
-
项目Hub
Y.6批准或拒绝成果豁免汇总证据、下游意见和必要人类确认
成果登记与门禁
-
项目Hub
Y.7A批准：标记 WAIVED 并分发豁免记录门禁将 WAIVED 视为已满足，但保留完整审计
全部受影响角色
-
项目Hub
Y.7B拒绝：成果保持 REQUIRED返回主责角色生成文件或补充证据
成果主责角色
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 项目Hubartifact_type、stage、reason_code、事实证据、适用范围、替代成果、下游影响、风险、owner_confirmed。只有该成果主责角色可发起；“暂时来不及”不属于不适用。进入 WAIVER_REVIEW，成果仍为 REQUIRED。
Y.2中心收到豁免申请。项目Hub → 主责角色资格校验、Schema 校验、补充问题或拒绝理由。成果模板必须允许 waivable；安全、法规、核心验收证据可标记 non-waivable。校验失败则退回，门禁保持阻塞。
Y.3–Y.4成果存在下游消费者，或缺省可能影响接口、测试、验收、制造和归档。项目Hub ↔ 受影响角色豁免摘要、替代证据、影响项、同意/反对/附条件意见。反对意见必须带具体依赖；项目Hub不得静默忽略。形成项目级影响结论。
Y.5豁免影响业务范围、外部承诺、总体架构、质量、安全、客户验收或组织责任。项目Hub → 业务申请、影响、下游意见、风险和建议。项目Hub无权单独批准高影响豁免；业务须完成内部授权。等待业务确认期间阶段为 WAITING_CONFIRMATION。
Y.6证据、影响意见及必要确认齐全。项目Hub → 成果登记/门禁waiver_id、artifact_type、project_scope、baseline_refs、decision、approved_by、approved_at、conditions、expires_on_change。豁免只对当前项目、阶段和基线版本有效，不得作为全局永久规则。APPROVED 或 REJECTED。
Y.7A豁免批准。项目Hub → 全部受影响角色WAIVED 状态、豁免记录、替代成果、附加条件。不能删除原必需项；以 WAIVED 留痕。项目范围或输入基线变化时自动失效并重新评估。WAIVED 可满足当前门禁。
Y.7B豁免拒绝或附加条件未满足。项目Hub → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。成果保持 REQUIRED，阶段继续阻塞。
-
-
-
Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.13
-
- - - diff --git a/doc/20260902/Codex多角色项目推进总流程图-V0.14.html b/doc/20260902/Codex多角色项目推进总流程图-V0.14.html deleted file mode 100644 index 6ec97c9..0000000 --- a/doc/20260902/Codex多角色项目推进总流程图-V0.14.html +++ /dev/null @@ -1,1285 +0,0 @@ - - - - - - - - Codex 多角色项目推进总流程图与信息流图谱｜V0.14 - - - -
-
-
CODEX MULTI-ROLE PROJECT FLOW · V0.14
-

项目推进总流程图

-

业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色，不是封闭列表；项目Hub负责信息路由、成员与状态维护和阶段门禁，新增自定义角色必须先形成职责、成果和决定权契约。

-
-
- - - -
-
-
-
VERSION / CHANGELOG
-
-

版本变更记录

-

每个新版本都保留上一版文件，并在当前版本中记录变更内容、影响范围和基线状态。

-
-
- -
- 版本管理规则：从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。每次变更同步更新文件名、页面标题、导航、页脚、本表和项目Hub提示词的当前流程基线引用。 -
-
- 版本号口径：V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。 -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
版本日期状态主要变更影响范围
V0.142026-09-02CURRENT人工可读的正式成果、过程成果、标题、正文和结论统一使用中文，机器字段与枚举只保留在运行时工具参数中；项目Hub通过 Etunel 角色清单读取实际 role、display_name 和 relationship，成员角色不再向负责人追问成员、会话或任务编号；新增同源 JSON 和中文 HTML 两种版本的《项目成员清单》，并补充按阶段整理成果、过程记录、项目进度和成果索引的留档规则。全局成果语言、项目创建、角色登记、Etunel 实际字段、项目文件与进度留档、项目Hub与各成员角色约束和内部培训材料。
V0.132026-08-28HISTORICAL完成八角色跨文件一致性审核；新增项目成员／多账户／自定义角色规则和状态术语词典；区分项目创建时成员登记与阶段 4 角色分工；统一 NA、测试证据包、软硬件接口契约 和业务术语；同步测试主责的缺陷报告闭环；将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划；重新生成项目Hub系统提示词。全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员／任务分工、阶段 6 缺陷闭环、项目Hub提示词。
V0.122026-08-28HISTORICAL校正 测试计划 的阶段 3 主责；统一 测试计划 和五类阶段 6 正式成果，完善共同最低结构、NA／BLOCKED／成果豁免 边界、缺陷分析报告 主责、平台提测与业务验收边界；把缺陷专业归类和根因责任从项目Hub／测试的越权表述中移回有权角色。阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。
V0.112026-08-28HISTORICAL校正硬件角色的阶段 3 设计职责；拆分 硬件设计包 与 硬件实现资料；完善原理图、PCB、Gerber／钻孔、BOM、贴片／生产资料、板卡／批次标识、板级测量和硬件版本链；建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。阶段 3 硬件设计、阶段 5 板卡／样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。
V0.102026-08-28HISTORICAL校正嵌入式底层的阶段 3 设计职责；完善 嵌入式底层实现资料 最低内容、可消费／修复／归档版演进、板卡／BOM／ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界；扩充流程图底层成果说明。阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。
V0.92026-08-28HISTORICAL校正嵌入式应用层的阶段 3 设计职责；完善 嵌入式应用层固件包 最低内容、候选／提测／回归／发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束；继续清理项目Hub旧称和广播表述。阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。
V0.82026-08-28HISTORICAL新增文档内版本变更记录、版本号口径和历史文件保留规则；从本版本起不再通过重命名覆盖上一版。全局导航、版本管理、项目Hub流程基线引用。
V0.72026-08-28HISTORICAL修正技术负责人在阶段 3 与阶段 4 的责任顺序；明确总体方案、软硬件接口契约和架构决策的主责；明确项目Hub维护版本矩阵、技术负责人确认版本匹配。阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。
V0.62026-08-28HISTORICAL统一产品角色的阶段 2 与阶段 7 正式成果；补齐产品发起早期风险预检、产品定义评审和验收闭环；客户平台资料改为参考输入基线。阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。
V0.5未登记HISTORICAL BASELINE建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7；形成正式成果追踪矩阵。总流程、项目Hub、全局信息流、门禁和成果追踪。
-
-
- -
-
-
-

从业务需求到发布结项

-

主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。

-
-
- 白色卡片＝项目阶段 - 黄色门＝角色/阶段确认 - 红色虚线＝返工回路 -
-
- -
-
-
01
-

业务需求

主责：业务
-
明确问题与价值。补齐业务目标、范围、规则、优先级和可度量成功指标。
-
正式成果项目背景说明
客户信息：客户名称、最终客户名称
项目名称：统一名称或客户规定的项目代号
产品要求：产品形态、提测平台
项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景：客户为什么提出这个需求，要解决什么问题
业务目标：本项目希望实现的业务结果
预期价值：可验证的价值假设
成功指标：可度量的结果与判断方式
订单、金额等信息仅在项目适用时作为可选补充项目目标与里程碑计划
提测时间
入库时间
小批量试产时间
量产时间
-
-
业务确认需求基线
- -
-
02
-

产品定义

主责：产品 · 批准：业务
-
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。
-
正式成果立项资料
立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能
灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息
结构板框图：包含主要器件位置和禁止限制区域测试验收标准
平台测试用例
客户验收测试用例和验收标准里程碑要求
提测时间
客户验收时间
试产、量产时间
-
-
产品确认方案，业务批准范围
- -
-
03
-

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
-
基于产品定义和前期可行性评估形成可实施方案。
技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件：原理图、PCB、BOM、电源/信号/热设计测试：范围、环境、用例、通过标准
-
正式成果总体技术方案软硬件接口契约硬件设计包架构决策记录测试计划
-
-
技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证
- -
-
04
-

项目规划

主责：项目Hub
-
基于已确认的产品基线和方案设计成果，生成实际任务、人员分工、排期和风险计划。任务计划草案先由技术负责人确认；项目Hub只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。
-
正式成果项目计划
项目任务拆分
实际项目排期项目风险
技术风险
时间风险
其他风险角色分工
Etunel 实际 role 与 display_name
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
每项任务只有一个主责角色产品资料整合
现有器件规格和板框约束
平台 SDK、串号表
平台对接文档
平台接入标准及开发规范
方案设计成果索引
其他项目输入参考资料项目状态内部记录
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化
-
-
技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认实际人员、资源与日期基线
- -
-
05
-

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件
-
嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口、任务或器件约束发生重大偏离时返回技术负责人和项目Hub确认。
-
正式成果硬件实现资料
正式原理图源文件与 PDF、PCB 源文件
Gerber、钻孔、拼板、层叠/阻抗和工艺说明（如适用）
PCBA BOM、器件位置图、贴片坐标、极性、DNI/NC 信息
维修原理图、关键测试点和生产测试接口
板卡/样机/批次标识、BOM 和 ECO 版本
接口定义、板级调试和静态/测量证据
与底层、应用固件、配置和接口契约的版本关系
已知限制、风险、返修/回退和 supersedes嵌入式底层实现资料
BSP/PSP、Bootloader、驱动、RTOS、HAL 和系统服务源码/输出引用
工具链、构建参数、输出路径和可复现说明
适配板卡、BOM/ECO、配置和接口契约版本
API/HAL、初始化、资源、时序、错误与恢复说明
硬件功能测试、自测、日志、波形/测量证据
专项测试固件（如适用，标明 TEST_UTILITY_ONLY）
应用层集成说明、Changelog、已知限制和风险嵌入式应用层固件包
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
日志文件
Changelog
串口使能证书
-
-
嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配
- -
-
06
-

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件
-
执行功能、接口、软硬件集成和回归测试。
不通过应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人
通过形成五类测试正式成果及质量结论
-
正式成果功能测试报告
功能、流程、状态、配置、接口、异常与恢复
验收标准 追踪
用例状态统计、缺陷、回归和质量结论可靠性测试报告
样本、环境、仪器、时长/循环和负载
高低温、跌落及其他适用项
原始数据、失效、恢复和不可逆变化专项测试报告
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项
专项矩阵、阈值来源、原始证据和分项结论测试证据包
证据索引和用例/标准映射
原始日志、截图/视频、测量、波形、平台结果和文件校验缺陷分析报告
现象、版本、环境、复现、期望/实际、频率和证据
Severity/风险/优先级、建议责任边界、根因/修复引用、复验与状态
-
-
测试确认质量结论和剩余风险
- -
-
07
-

业务验收

主责：产品
-
依据成功指标、验收标准和质量证据作最终判断。
驳回需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试
通过形成正式业务验收结论，进入发布准备
-
正式成果平台提测通过报告客户验收通过报告附条件验收事项
-
-
业务批准验收结论和上线条件
- -
-
08
-

发布结项

项目Hub协调 · 技术负责人确认 · 嵌入式应用层/嵌入式底层/硬件执行 · 测试验证
-
检查应用、固件、板卡版本、BOM/ECO、发布清单、冒烟、回滚和遗留事项承接。项目Hub汇总复盘，整理各阶段正式成果、必要过程记录、项目进度和成果索引；不把完整聊天记录当成项目档案。
-
正式成果结项资料归档
形成最终结果的流程文件变更记录结项报告流程闭环总结
-
-
- -
- 贯穿全流程：变更申请（需求变更申请） -

任何角色都可提出变更；项目Hub组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，业务批准后更新对应基线，并从受影响阶段继续推进。

-
-
- 成果适用性：成果豁免（成果文件豁免） -

正式任务的阶段成果默认由主责角色输出；确认不适用时，由主责角色说明原因、影响和替代证据，项目Hub完成必要确认并记录豁免。验证期确需跳过时，记录缺失项、风险和后续补齐安排，不把跳过写成成果已完成。

-
-
- -
-
-
STAGE INFORMATION FLOW ATLAS · V0.14
-

各阶段角色信息流图谱

-

以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

-
- 通用规则成果追踪矩阵01 业务需求02 产品定义03 方案设计04 项目规划05 软硬件实现06 测试验证07 业务验收08 发布结项变更与异常成果豁免 -
-
绿色：正式成果、候选成果或正式基线黄色：过程记录、关联成果或修订对象
-
-
-
-
00 / RULES
-

所有阶段共同遵守的流转规则

现阶段成员角色之间不能直接通信。跨角色问题、成果和结论都必须经项目Hub定向中继、校验、登记和重新分发。

-
-
唯一正式路径：触发事件 → 主责角色与本角色真人负责人对齐 → 完成指定文件、专业自审与负责人确认 → 提交项目Hub → 项目Hub检查文件、版本、证据、确认、依赖和冲突 → 定向路由目标角色 → 目标角色完成任务后返回项目Hub → 项目Hub留档并安排下游。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。
-
正式任务默认要求主责角色输出约定成果；确认不适用时记录原因、影响和替代证据。验证期可由负责人决定跳转、回退或暂缓，但必须保留缺失项、风险和补齐安排，不能把跳过写成已通过，也不能静默删除已有文件。
-
- 项目Hub业务产品技术负责人嵌入式应用层嵌入式底层硬件测试 -
-
- - - -
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付。不能替其他角色作出专业确认。
业务是；同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外，负责确认计划基线、真实资源、预算、采购/打样、日期、暂停/取消和高影响成果豁免。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
项目Hub是项目Hub运行中心 AI，是项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和低影响豁免；高影响事项必须升级给业务。不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。
-
角色与成员配置：图中的八个角色是当前默认基线，不是永久封闭的角色集合。新增自定义角色前先定义目标、职责边界、参与阶段、正式成果、上下游依赖和确认权限，再由 Hub 真人负责人在 Etunel 中手动添加。项目Hub使用 etunel_list_roles 读取实际 role、display_name 和 relationship；各角色会话不向负责人重复确认成员 ID、会话 ID 或其他未由工具提供的字段。阶段 4 再通过《角色分工》将实际任务主责和交接关系正式基线化。
-
项目成员清单：项目创建完成后、首个正式任务派发前，项目Hub从同一次 etunel_list_roles 结果生成 JSON 版和全中文 HTML 版《项目成员清单》。两份清单只记录项目名称、版本、导出时间及工具实际返回的 role、display_name、relationship，不虚构成员、会话或人员编号。角色变化后生成新版本，不覆盖历史版本；该清单不替代阶段 4 的《角色分工》。
-
任务与状态规则：每项任务只有一个主责角色；依赖已经满足的多项任务可以形成任务波次，同一角色的内聚工作可以组成一个任务包。项目模式、任务结果、成果状态、阶段门禁、测试结论和业务验收含义不同，不得相互替代。对负责人使用“通过、失败、阻塞、不适用、延期”等自然中文；机器枚举只在工具字段明确要求时使用。
-
项目文件与进度留档：项目Hub按 项目资料/00-项目管理 和八个阶段目录整理资料，维护《项目概览》《项目进度》《成果索引》及必要的《阶段记录》。正式成果放入对应阶段的角色目录，重要草稿、退回原因、决定和阻塞放入过程记录；正式文件不覆盖，回退不删除历史。阶段交接和钉钉里程碑通知前先完成留档，但目录排版本身不是新的专业门禁。
-
-
任意角色
G.1提交已完成内部审查确认的消息、成果或请求说明完成情况、负责人确认、成果路径、版本、证据和待处理事项
项目Hub
-
项目Hub
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
-
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录
项目Hub
-
-
项目进度与按需同步：项目Hub持续维护 项目资料/00-项目管理/项目进度.md，并在对应阶段的《阶段记录》中追加重要事件。创建项目、启动任务波次、接收正式成果、重要退回、阻塞与解除、决定与变更、阶段切换／跳转／回退／暂缓和结项时更新；普通消息、队列状态和空确认不逐条留档。关键变化只向实际受影响角色推送，也响应角色按阶段或任务发起的查询。
-
-
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态说清关注阶段或任务、需要的信息和用途
项目Hub
-
项目Hub
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回
请求角色及受影响角色
-
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
项目Hub
-
项目Hub
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。任意角色 → 项目Hub查询范围、关注事项、所需详细度、期望时点和用途。只能查询项目授权范围内的信息；请求角色无需知道项目的内部存储结构。创建一次按需状态查询。
S.2收到 S.1；或阶段／门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化。项目Hub → 请求角色及受影响角色项目状态快照：当前阶段与门禁、相关任务、依赖、阻塞、风险、决定、成果引用、下一步、期限和证据。按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 项目Hub确认可以继续；或说明需要纠正的内容、正确值、原因、证据和负责人确认。没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。确认可继续执行，或触发状态纠正。
S.4纠正请求通过版本、证据及跨角色一致性检查。项目Hub → 全部受影响角色变更内容、旧值与新值、原因、证据、生效时间及受影响任务。保留状态历史，不覆盖旧版本；改变正式基线时必须转入变更申请。相关角色切换到新的有效状态快照。
-
异常协同补充机制：条件流、阻塞流、跨角色冲突或无法按时收敛的问题进入 E.1–E.4。项目Hub分别提醒实际相关角色并提供完整问题包；问题复杂时建议各角色真人负责人线下沟通。讨论结果由当前主责角色的负责人带回本角色会话，完成本角色任务后再提交项目Hub；角色 Agent 之间仍不直接通信。
-
-
项目Hub
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
-
项目Hub
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
-
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
项目Hub
-
项目Hub
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果
原流程及关联角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。项目Hub → 当前主责角色及实际关联角色问题摘要、证据与版本引用、冲突点、影响范围、所需角色和期望处理时间。项目Hub必须主动提醒，不得只更新状态；各角色依据正式问题包分别确认。原流程保持阻塞，等待问题关闭。
E.2涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。项目Hub → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。项目Hub只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。会议结论回传前，不恢复原流程。
E.3线下讨论完成并形成统一结论。当前主责角色 → 项目Hub会议决定记录：参与角色、统一结论、保留分歧、变更项、责任角色、期限、成果版本、证据和负责人确认。禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过项目Hub的形式、版本、证据和跨角色一致性检查。项目Hub → 原流程及关联角色登记结果、受影响成果或任务、恢复点、后续动作和新时限。项目Hub不改写专业结论；若结论改变正式基线，必须转入变更申请。从原来被阻塞的位置恢复当前流程。
-
- - - - - - - - - - - - -
通用约束执行要求不满足时
Etunel 消息Hub 使用工具实际提供的 role、kind、text、可选附件路径和关联字段；需要完成、阻塞或结算时，只从入站消息读取真实 message_id。机器字段不抄进给负责人的正文。字段不符合当前工具 schema 时停止调用并说明能力缺口，不得发明参数。
成果版本必须写清成果名称、当前版本、状态、替代关系和证据引用。作为草稿退回，并说明缺少内容。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签；项目Hub返回主责角色。
角色内部审查每个角色必须完成专业自查并取得当前真人负责人确认；跨角色流转时统一以正式角色名称表示。没有自查或负责人确认的成果不能作为正式成果提交项目Hub。
专业发起权专业活动由对应主责角色判断并发起；项目Hub只负责格式校验、任务路由、状态跟踪和结果登记。项目Hub不得越权替角色发起专业决策。
项目Hub审查边界仅做必填结构、文件、版本、证据、负责人确认，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请；经项目Hub审查及必要确认后记录为已豁免。未批准时仍需要该成果；验证期跳转则记录缺失、风险和补齐安排。
角色确认专业结论由对应角色内部形成并确认；项目级组织授权由业务内部完成。信息流图只显示统一的正式角色主体。未完成负责人确认时不得作为正式结果发出。
项目状态同步项目Hub维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同项目对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。
跨角色沟通成员角色之间不直接通信；问题、最终结论、约束、证据和影响都通过项目Hub定向中继。绕过项目Hub取得的信息不能作为正式下游输入。
门禁正常顺序推进时，只有成果完整、版本正确、证据可访问、确认齐全才能通过；跳转、回退或暂缓按负责人决定另行记录。未满足且没有明确跳转决定时，阶段保持阻塞。
-
- -
-
00B / ARTIFACT TRACEABILITY

正式成果—信息流追踪矩阵

流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。

-
判定原则：正式成果必须由指定主责角色输出；过程记录只能解释校验、评审、冲突、变更和确认，不得替代正式成果。若某项成果获准豁免，则以下对应流转中的成果引用改为豁免记录和替代证据。
-
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
阶段正式成果主责角色首次形成/提交评审、修订与确认正式分发/下游使用
1 业务需求项目背景说明业务F1.1F1.2 条件修订；F1.7 业务确认F1.3 评审分发；F1.8 正式基线给产品
1 业务需求项目目标与里程碑计划业务F1.1F1.2 条件修订；F1.7 业务确认F1.3 评审分发；F1.8 正式基线给产品
2 产品定义立项资料产品F2.2F2.3–F2.6 专业评审与修订；F2.7–F2.8 业务批准F3.1 方案设计输入；F4.1 项目规划输入
2 产品定义测试验收标准产品F2.2F2.3–F2.6 测试评审；F2.7–F2.8 业务批准F3.7 测试计划 输入；F6.1 测试输入；F7.1 验收输入
2 产品定义里程碑要求产品F2.2F2.3–F2.6 专业评审；F2.7–F2.8 业务批准F4.1 项目计划 输入；S.2 状态同步
3 方案设计总体技术方案技术负责人F3.2F3.4–F3.8 修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F8.7 归档
3 方案设计软硬件接口契约技术负责人F3.2F3.4–F3.8 多角色修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F5.7 冲突回溯
3 方案设计硬件设计包硬件F3.3/F3.6F3.8–F3.10 技术负责人及相关角色确认F4.1 项目规划输入；F5.1/F5.2 硬件实现输入
3 方案设计架构决策记录技术负责人F3.2；F3.4–F3.6 持续补充F3.8–F3.10 确认；X 流程变更时追加F4.1 项目规划输入；F5.1 实现约束；F8.7 归档
3 方案设计测试计划测试F3.3/F3.7F3.8–F3.10 多角色确认F4.1 测试任务规划输入；F6.1 测试任务输入
4 项目规划项目计划项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 定向修订；F4.6–F4.7 业务授权F4.8 分发相关执行角色；F5.1 实现任务输入；后续由 X 流程变更
4 项目规划项目风险项目HubF4.1，引用 F1.5–F1.6 预检和阶段3方案风险F4.2–F4.7 更新与确认；E/X 流程持续更新F4.8 分发；F5.1 实现风险输入；S.2 按角色同步
4 项目规划角色分工项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 问题任务修订F4.8 随正式任务分发；F5.1 实现责任输入
4 项目规划产品资料整合项目HubF4.1F4.2 技术负责人检查产品与方案输入引用F4.8 按角色裁剪分发；F5.1 实现输入
4 项目规划项目状态内部记录项目HubF4.1 初始执行记录S.3–S.4 证据化纠正；E/X 流程更新F4.8 初始执行快照；S.2 自动或按需分发
5 软硬件实现硬件实现资料硬件F5.2F5.7 冲突修订；F5.8–F5.10 版本匹配确认F6.1 测试输入；F8.3 归档
5 软硬件实现嵌入式底层实现资料嵌入式底层F5.4F5.5 交嵌入式应用层合版；F5.7/F5.10 确认版本关系通过 F5.6 集成进统一固件；F8.3 提交归档资料
5 软硬件实现嵌入式应用层固件包嵌入式应用层F5.6 候选；F5.9 最终提测版F5.7 冲突修订；F5.8–F5.10 技术负责人确认F6.1 交测试；F6.8 回归版；F8.3 最终发布版
6 测试验证功能测试报告测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证可靠性测试报告测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证专项测试报告测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 验收输入；F8.7 归档
6 测试验证测试证据包测试F6.2F6.3–F6.9 持续补证；F6.10 完整性确认F7.1/F7.3 验收证据；F8.5 最终证据
6 测试验证缺陷分析报告测试F6.2/F6.3F6.4–F6.9 责任角色修复并由测试回归；F6.10 确认F7.1 验收限制输入；F8.7 归档
7 业务验收平台提测通过报告产品F7.2F7.3–F7.7 验收与修订；F7.8 业务确认F8.6 结项核对；F8.7 归档
7 业务验收客户验收通过报告产品F7.2F7.3–F7.7 客户/业务验收与修订；F7.8 业务确认F8.6 结项核对；F8.7 归档
7 业务验收附条件验收事项产品F7.2/F7.4F7.6–F7.8 补充责任角色、期限并确认F8.6 关闭或承接；写入 结项报告
8 发布结项结项资料归档项目HubF8.7–F8.8F8.1–F8.7 汇集输入；F8.9 完整性确认项目关闭后锁定归档
8 发布结项变更记录项目HubX.1–X.5 持续记录；F8.8 汇总每次 变更决定 更新；F8.9 结项检查随 结项资料归档 锁定
8 发布结项结项报告项目HubF8.8F8.4–F8.7 提供输入；F8.9 业务确认项目关闭依据与归档入口
8 发布结项流程闭环总结项目HubF8.8F8.7 角色摘要输入；F8.9 业务确认经验复用与后续案例检索
-
- -
-
01 / BUSINESS

阶段 1：业务需求信息流

把客户背景、业务目标和关键里程碑转换成经过业务角色内部确认的需求基线。

-
主责业务
核心成果项目背景说明、项目目标与里程碑计划
门禁业务完成内部审查并确认需求基线
-
业务完成原始信息收集、成果自查和负责人确认后，以统一的“业务”主体提交成果。项目Hub完成文件、版本、证据和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。项目Hub只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，项目Hub先留档，再向产品分发正式业务基线并开启产品定义。
-
-
业务
F1.1提交完成内部审查的项目背景与里程碑草案附负责人确认、来源引用和实际成果文件
项目Hub
-
项目Hub
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限文件结构、版本、证据和已登记信息冲突；无异常则不启用此流
业务
-
项目Hub
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
-
产品
F1.4指定对象角色并提交早期风险预检请求产品根据风险内容选择一个或多个专业角色
项目Hub
-
项目Hub
F1.5按产品指定名单校验、提醒并路由预检任务主动提醒全部关联角色；不得增删产品指定名单
产品指定的对象角色
-
产品指定的对象角色
F1.6返回内部确认结果；复杂问题返回统一会议结论无法异步收敛时，由产品组织线下会议并按 E.3 回传
项目Hub
-
业务
F1.7确认需求基线业务内部审查、形式校验和预检问题均已关闭
项目Hub
-
项目Hub
F1.8向产品分发正式业务基线并开启产品定义只能引用已经确认并留档的当前有效版本
产品
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户需求或业务机会，且业务已完成原始信息收集、自查和负责人确认。业务 → 项目Hub正式成果草案：项目背景说明、项目目标与里程碑计划。
附带内容：负责人确认、来源引用、成果版本和实际文件。		项目Hub不重复判断业务内容质量，只检查形式和跨来源一致性。进入中心登记。
F1.2（条件流）仅当文件结构、版本、证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。项目Hub → 业务过程记录：形式校验问题清单或冲突清单。
关联成果：受影响的项目背景说明／项目目标与里程碑计划及其字段、版本、冲突来源和修正要求。		项目Hub不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。
F1.3业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。项目Hub → 产品评审分发成果：待评审的项目背景说明、项目目标与里程碑计划。
附带内容：成果版本、状态、证据、待确认项和回复时限。		必须标明这是待评审版本，不得冒充正式基线，产品不得据此直接启动阶段 2。产品获得早期风险识别所需上下文。
F1.4产品审阅业务成果后，判断存在需要其他专业角色提前确认的风险。产品 → 项目Hub过程记录：早期风险预检请求。
关联成果：项目背景说明／里程碑计划的相关字段与版本；另含预检原因、问题、目标角色、期望输出和时限。		是否预检、预检范围及对象角色均由产品负责指定；项目Hub不代替产品判断。按产品指定名单创建预检任务。
F1.5–1.6产品预检请求格式完整，且指定的对象角色均为当前项目有效成员。项目Hub ↔ 产品指定的对象角色过程记录：角色预检任务 / 预检结果（角色预检任务/结论）。
关联成果：项目背景说明、项目目标与里程碑计划；返回本专业红线、风险、证据、待澄清项和受影响字段，作为后续 项目风险 输入。		项目Hub必须主动提醒全部关联角色，只校验、路由和汇总，不得自行增删产品指定名单。多角色结论冲突、影响较大或无法异步收敛时，建议由产品组织线下会议；参与角色统一确认的结论按 E.3 回传后，才能继续当前流程。补充业务澄清和早期风险登记；复杂问题进入 E.1–E.4，闭环前保持阻塞。
F1.7业务内部审查、中心形式校验和预检问题均已关闭。业务 → 项目Hub确认成果：完成负责人确认的项目背景说明、项目目标与里程碑计划。
附带内容：确认状态、确认时间、确认条件和版本。		角色内部确认状态、时间和版本必须记录。门禁可进入评审。
F1.8业务确认完成，项目Hub已登记并留档正式版本且阶段门禁通过。项目Hub → 产品正式基线：项目背景说明、项目目标与里程碑计划的当前有效版本。
附带内容：成果版本、基线与证据引用、阶段 2 任务和确认时限。		只允许分发已经确认并留档的当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
-
- -
-
02 / PRODUCT

阶段 2：产品定义信息流

产品形成完整立项资料，并让技术负责人、嵌入式应用层、嵌入式底层、硬件和测试从各自专业角度完成可行性确认。

-
主责产品；业务批准范围
核心成果立项资料、测试验收标准、里程碑要求
门禁产品确认方案，业务批准范围，约束和测试标准完整
-
-
项目Hub
F2.1下发产品定义任务附阶段 1 基线和全部红线约束
产品
-
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
-
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
-
项目Hub
F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突，不替产品作内容决定
产品
-
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
项目Hub
-
项目Hub
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
-
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。项目Hub ↔ 产品输入基线：项目背景说明、项目目标与里程碑计划。
产品提交的正式成果草案：立项资料、测试验收标准、里程碑要求。
参考输入（非阶段成果）：项目已有的器件规格、板框约束、平台 SDK、串号表、平台对接文档和开发规范。		产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试评审分发成果：按角色裁剪上述三类产品定义成果草案。
参考输入：只附与评审问题相关的现有器件、板框和平台资料；另含成果版本、基线引用、评审范围、问题和时限。		项目Hub只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub过程记录：角色评审结果（角色评审结论）。
关联成果：三类产品定义成果的具体字段；提交结论、缺失、风险、证据、建议和是否阻塞。		不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。项目Hub ↔ 产品修订成果：受影响的 立项资料、测试验收标准、里程碑要求 新版本。
附带内容：字段级修订清单、变更影响和关闭说明。		产品在内部确认最终版本后统一发出。问题未关闭则暂缓推进。
F2.7–2.8产品方案专业评审完成。项目Hub ↔ 业务批准成果包：三类产品定义成果的负责人确认候选版本。
附带内容：范围、验收、里程碑、风险、附条件事项、版本和确认状态。		范围批准由业务完成内部授权后统一给出。批准并留档后作为正式基线进入阶段 3。
-
- -
-
03 / DESIGN

阶段 3：方案设计信息流

技术负责人依据产品定义基线和前期风险评估组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试围绕同一份软硬件接口契约完成多轮确认。

-
主责技术负责人主责总体方案、接口契约和架构决策；硬件与测试分别主责本角色成果
核心成果总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划
门禁方案确认、接口可实施、需求不偏离、测试可验证
-
-
项目Hub
F3.1下发总体方案设计任务附产品定义基线、前期风险结论和现有技术参考资料
技术负责人
-
技术负责人
F3.2提交总体方案与接口契约草案含边界、关键决策、非功能和风险
项目Hub
-
项目Hub
F3.3并行分发角色化设计任务每个角色在同一契约版本上工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
-
嵌入式底层
F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
项目Hub → 硬件 / 技术负责人
-
硬件
F3.6反馈器件、PCB、电源、空间与热约束影响接口、成本或性能时
项目Hub → 技术负责人 / 嵌入式底层 / 产品
-
测试
F3.7提交不可测试项和环境/治具缺口验收标准无法验证时
项目Hub → 相关角色
-
项目Hub
F3.8汇总冲突并要求总体方案修订形成决策清单和待关闭问题
技术负责人
-
技术负责人
F3.9提交内部确认的最终方案和契约基线所有阻塞问题关闭后
项目Hub
-
项目Hub
F3.10请求各角色确认接口可实施嵌入式应用层、嵌入式底层、硬件、产品、测试分别确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.3阶段 2 门禁通过，产品定义基线和前期风险结论有效。项目Hub ↔ 技术负责人/协作角色按主责角色分别形成的正式成果草案：技术负责人输出 总体技术方案、软硬件接口契约、架构决策记录；硬件输出 硬件设计包；测试输出 测试计划。
输入内容：阶段2三类产品成果、现有技术参考资料、F1.5–F1.6 预检结论、设计范围和时限。		方案设计不得依赖尚未形成的 项目计划；所有设计必须引用同一产品基线。开启并行方案设计。
F3.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人修订对象：软硬件接口契约、总体技术方案、架构决策记录。
提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。		不得绕过契约直接约定。可能触发契约修订。
F3.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 项目Hub → 硬件 / 技术负责人修订对象：软硬件接口契约、硬件设计包、架构决策记录。
提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。		硬件回复必须引用板卡版本。冲突时阻塞相关设计。
F3.6器件、PCB、电源、空间或热约束影响方案。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品修订成果：硬件设计包；必要时同步修订 总体技术方案、软硬件接口契约、架构决策记录。
提交内容：限制、替代方案、成本、性能和交期影响。		器件替换不得静默发生。形成 ADR/变更申请。
F3.7测试无法验证某项需求或缺环境/治具。测试 → 项目Hub → 相关角色修订对象：测试计划、软硬件接口契约；必要时回溯 测试验收标准。
过程记录：可测性缺口清单，包含不可测项、证据要求、环境和治具需求。		必须在实现前关闭，或由负责人明确记录验证期跳转决定。正常推进时门禁保持阻塞。
F3.8–3.10专业评审完成。各相关角色 → 项目Hub；项目Hub分别定向中继最终确认成果：总体技术方案、软硬件接口契约、硬件设计包、架构决策记录、测试计划 的内部确认版本。
附带内容：角色确认、保留风险、证据引用和统一版本关系。		每个确认绑定同一版本；成员角色之间不直接通信。全部确认并登记为正式基线后进入阶段 4 项目规划。
-
- -
-
04 / PLANNING

阶段 4：项目规划信息流

项目Hub根据产品基线和已确认的方案设计成果生成实际任务计划，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。

-
主责项目Hub；技术负责人确认任务计划的技术结构
核心成果项目计划、风险登记、角色分工、产品资料整合、项目状态内部记录
门禁技术负责人确认技术任务结构、顺序和依赖；问题任务完成定向确认；业务确认资源与日期基线
-
-
项目Hub
F4.1提交任务计划与正式角色分工草案，请求整体确认附产品／方案基线、角色清单、任务拆分、技术顺序、依赖、初始排期和风险
技术负责人
-
技术负责人
F4.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系、专业角色覆盖和关键风险
项目Hub
-
项目Hub
F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
-
对应执行角色
F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
项目Hub
-
项目Hub
F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
-
项目Hub
F4.6请求资源与日期基线授权真实人员、采购、打样、成本和日期由业务内部确认
业务
-
业务
F4.7批准或要求调整资源与日期基线记录内部批准状态、范围和条件
项目Hub
-
项目Hub
F4.8向相关执行角色发布基线计划和正式任务附充分输入、依赖、成果文件、完成条件和下游用途；后续状态按 S.1–S.4 同步
相关执行角色
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.2阶段 3 方案设计门禁通过，项目Hub已依据产品基线、方案设计成果和项目创建期角色清单形成任务计划草案。项目Hub ↔ 技术负责人正式成果草案：项目计划、项目风险、角色分工、产品资料整合、项目状态内部记录 初始版。《角色分工》列出 Etunel 实际 role 和 display_name、职责边界、任务主责、协作关系和交接要求。
输入基线：阶段 2 产品成果、阶段 3 五类方案设计成果和角色清单；另含任务拆分、关键路径、输入输出、依赖、初始排期和风险。		技术负责人确认技术任务结构、顺序、依赖、版本关系、专业角色覆盖和技术风险；项目Hub不向全部执行角色征求整份计划确认。每项任务只设一个主责角色。形成技术结构与角色覆盖已确认的任务计划草案。
F4.3–4.4（条件流）项目Hub发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。项目Hub ↔ 对应执行角色修订对象：项目计划、项目风险、角色分工、项目状态内部记录 中的问题任务。
过程记录：任务澄清请求／任务澄清回复，包含方案成果引用、上下游依赖、工期、资源、风险和负责人确认。		必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务；未触发时直接跳过。
F4.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。项目Hub ↔ 技术负责人及受影响角色修订成果：项目计划、项目风险、角色分工、项目状态内部记录 新版本。
过程记录：冲突解决记录，包含冲突点、方案约束、可选排法、阶段影响和响应时限。		项目Hub必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。保持计划草案，冲突关闭前不得基线化。
F4.6–4.7技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，计划涉及真实人员、采购、打样、成本或日期基线。项目Hub ↔ 业务授权成果：项目计划、项目风险、项目状态内部记录 候选基线。
附带内容：资源请求、成本、里程碑、风险、授权范围、条件和确认状态。		项目Hub无权自行批准现实资源和日期；业务完成内部授权后统一回复。批准后可基线化。
F4.8技术负责人确认有效、问题任务已关闭且业务批准资源与日期基线。项目Hub → 相关执行角色正式基线：项目计划、项目风险、角色分工、产品资料整合。
状态快照：只包含该角色相关任务、充分输入、依赖、方案成果引用、门禁、风险、时限、成果文件和完成条件。		每个角色只接收与自身任务和依赖相关的计划内容；后续角色加入、退出、替换或变化必须登记并交接，改变基线时走变更申请；执行状态按 S.1–S.4 同步。相关角色接收任务，开启阶段 5。
-
- - - -
-
05 / IMPLEMENT

阶段 5：嵌入式软硬件实现信息流

三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进；固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，项目Hub维护其与硬件版本的唯一映射。

-
并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测
-
-
项目Hub
F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界
嵌入式应用层 / 嵌入式底层 / 硬件
-
硬件
F5.2提交板卡、BOM、接口与样机版本硬件发布或 ECO 时触发
项目Hub
-
项目Hub
F5.3向受影响角色定向分发硬件版本及约束变化只向实际受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
-
嵌入式底层
F5.4提交可消费的底层实现包包含 BSP/PSP、Bootloader、驱动、RTOS、HAL，并绑定板卡、BOM/ECO、工具链、配置和契约版本
项目Hub
-
项目Hub
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版测试不得直接将底层产物作为提测固件
嵌入式应用层
-
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层、板卡和契约版本，包含 MD5、分区、自测和 Changelog
项目Hub
-
任一实现角色
F5.7报告接口、器件或资源冲突契约不一致、资源超限或 ECO 影响时
项目Hub → 技术负责人
-
项目Hub
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
-
嵌入式应用层
F5.9提交最终提测固件版本最终固件只能由嵌入式应用层提交，附完整版本链、自测和偏离说明
项目Hub
-
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测板卡、BOM、统一固件及其应用/底层版本链完全匹配
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1阶段 4 项目规划门禁通过。项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件待产出成果：嵌入式应用层固件包、嵌入式底层实现资料、硬件实现资料。
输入与任务：阶段3方案设计基线、阶段4 项目计划（项目任务计划）、角色分工、项目风险，以及任务、输出格式、依赖和期限。		三方必须使用相同契约和项目计划版本。启动并行实现。
F5.2–5.3硬件发布样机、板卡、BOM 或 ECO。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试正式成果：硬件实现资料 当前版本。
提交内容：正式原理图源文件与 PDF、PCB 源文件；Gerber、钻孔、拼板、层叠/阻抗和工艺说明（如适用）；PCBA BOM、器件位置图、贴片坐标、极性、DNI/NC；维修原理图、关键测试点、接口和生产测试定义；`hardware_version`、原理图/PCB/BOM/ECO 修订号、板卡/样机/批次标识；板级调试、静态/测量证据；软件、配置和契约版本关系；限制、风险、返修/回退和 `supersedes`。		没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。影响接口、底层或应用固件时阻塞受影响任务。
F5.4–5.5嵌入式底层形成可消费版本。嵌入式底层 → 项目Hub → 嵌入式应用层正式成果：嵌入式底层实现资料 当前版本。
提交内容：BSP/PSP、Bootloader、驱动、RTOS、HAL、系统服务的源码/输出引用；工具链、构建参数、输出路径和可复现说明；适配板卡、BOM/ECO、配置和接口契约版本；API/HAL、初始化、资源、时序、错误与恢复说明；硬件功能测试、自测、日志、波形/测量证据；应用层集成说明、已知限制、风险和 `supersedes`。		必须声明适配板卡、BOM/ECO、配置和契约版本；专项测试固件须标明 TEST_UTILITY_ONLY；测试不得把底层产物直接作为提测固件。项目Hub登记后允许嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 项目Hub正式成果候选：嵌入式应用层固件包。
提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、日志、Changelog、串口使能证书，以及应用/底层/板卡/契约版本链。		必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 项目Hub → 技术负责人过程记录：实现冲突记录。
关联成果：受影响的 硬件／底层／应用实现成果 和 接口契约；提交冲突、证据、版本、影响和建议。		项目Hub立即冻结受影响版本。等待技术裁决或契约新版本。
F5.8–5.10统一固件候选和硬件候选均已提交，联调问题已经关闭。项目Hub ↔ 嵌入式应用层 / 硬件 / 技术负责人最终确认成果：嵌入式应用层固件包、硬件实现资料；引用已集成的 嵌入式底层实现资料。
过程记录：版本矩阵、集成记录、集成批准；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。		最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由项目Hub将该唯一固件版本交给测试。
-
- -
-
06 / TEST

阶段 6：测试验证与缺陷返工信息流

测试提交证据和缺陷，项目Hub按问题层级路由到产品、嵌入式应用层、嵌入式底层、硬件或技术负责人，并控制重新提测。

-
主责测试
核心成果功能、可靠性、专项测试报告，测试证据和缺陷分析
门禁阻断缺陷清零，证据完整，测试完成内部确认并提交质量结论
-
-
项目Hub
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
-
测试
F6.2提交测试报告、证据和缺陷每个缺陷关联版本、用例和证据
项目Hub
-
项目Hub
F6.3按测试建议或专业裁决路由缺陷责任明确时定向路由；跨层问题交技术负责人，需求含义交产品
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F6.4返回内部确认的原因分析、修复计划和影响范围正式修复承诺在角色内部确认后统一发出
项目Hub
-
项目Hub
F6.5创建修复或技术裁决任务跨层问题交技术负责人，需求问题交产品
责任角色
-
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明替代关系和影响范围
项目Hub
-
项目Hub
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
-
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
项目Hub
-
项目Hub
F6.9下发定向回归任务和统一固件附修复范围、受影响用例和新版本矩阵
测试
-
测试
F6.10提交内部确认的最终质量结论和剩余风险报告和证据完整后
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。项目Hub ↔ 测试测试输入：嵌入式应用层固件包、硬件实现资料、已集成的 嵌入式底层实现资料、版本矩阵、测试计划。
测试提交的成果草案：功能测试报告、可靠性测试报告、专项测试报告、测试证据包、缺陷分析报告。		测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。启动测试并更新测试状态。
F6.3测试发现缺陷或测试异常并形成可追踪记录。测试 → 项目Hub → 建议责任角色 / 技术负责人 / 产品正式成果更新：测试主责的《缺陷分析报告》缺陷条目。
提交与分发内容：缺陷编号、现象、版本矩阵、环境、用例、复现、期望／实际、证据、影响程度、风险、优先级、建议责任边界、受影响成果、回归要求和响应时限。		项目Hub只做结构、证据和路由检查；责任明确时按测试建议路由，跨层或根因不清时交技术负责人，需求含义不清时交产品。建立定向返工或裁决任务。
F6.4–6.5责任角色或裁决角色收到缺陷任务。责任角色 / 技术负责人 / 产品 → 项目Hub → 测试过程记录：原因分析、修复计划或技术／产品决定，包含原因或裁决、影响、修复方案、风险、修复成果计划、期限、需重测范围和证据。
测试动作：引用带来源的原因、修复或裁决输入，更新《缺陷分析报告》状态和回归要求。		实现角色不直接替换或关闭测试主责的《缺陷分析报告》；“无法复现”“符合设计”或“不修复”必须带理由与证据。阻断缺陷使阶段阻塞；等待修复成果和目标版本复验。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试实现角色修订成果：嵌入式应用层固件包、嵌入式底层实现资料或硬件实现资料。
提交给测试的缺陷输入：原因分析、修复计划、修复成果与版本、实现角色自测、变更记录、证据、影响范围、版本链和建议回归范围；测试引用后更新《缺陷分析报告》。
硬件 ECO 额外内容：新旧板卡／PCB／BOM／ECO 差异、受影响批次、返工／回退方式、板级验证证据、底层驱动／HAL 兼容评估、应用固件有效性确认和新版本矩阵。		实现角色无权直接替换或关闭《缺陷分析报告》。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。形成唯一可回归的固件与硬件版本矩阵，并由测试复验。
F6.9统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。项目Hub → 测试回归输入：更新后的 嵌入式应用层固件包、相关 嵌入式底层实现资料／硬件实现资料、缺陷分析报告、版本矩阵。
过程记录：回归任务，包含修复范围、受影响用例和时限。		旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10阻断缺陷清零且证据齐全。测试 → 项目Hub最终确认成果：功能测试报告、可靠性测试报告、专项测试报告、测试证据包、缺陷分析报告的负责人确认版本。
附带内容：质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。		测试内部确认状态必须记录；剩余风险必须有接受方。门禁通过并留档后开启验收。
-
- -
-
07 / ACCEPT

阶段 7：业务验收信息流

产品组织平台和客户验收，项目Hub收集业务/客户结论，并把驳回问题精确路由到对应层级。

-
主责产品主责验收成果；项目Hub组织流转；业务批准
核心成果平台提测通过报告、客户验收通过报告、附条件事项
门禁业务完成内部确认并提交验收及上线条件
-
-
项目Hub
F7.1下发验收组织任务和证据包测试门禁通过后
产品
-
产品
F7.2提交平台/客户验收资料引用测试证据、版本和已知限制
项目Hub
-
项目Hub
F7.3向业务发起验收确认呈现目标、证据、风险和附条件项；客户反馈由业务或产品负责人按边界线下取得
业务
-
业务
F7.4返回通过、驳回或附条件通过整理必要的客户反馈；驳回必须描述场景和证据
项目Hub
-
项目Hub
F7.5分类并路由验收问题需求/嵌入式应用层/嵌入式底层/硬件/架构/证据
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F7.6提交修正、说明或风险处置形成新成果版本或正式解释
项目Hub
-
项目Hub
F7.7组织重新验证和再次验收只返回受影响阶段，不重启整个项目
产品/测试/业务
-
业务
F7.8提交内部确认的最终验收和上线条件附条件项必须有责任人和期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1–7.2测试门禁通过。项目Hub ↔ 产品验收输入：阶段 6 五类测试成果、嵌入式应用层固件包、版本矩阵和已知限制。
产品提交的正式成果草案：平台提测通过报告、客户验收通过报告、附条件验收事项。		产品不得隐藏已知风险。形成验收包。
F7.3–7.4验收包完整。项目Hub ↔ 业务；客户信息由业务或产品负责人线下取得待确认成果：平台提测通过报告、客户验收通过报告、附条件验收事项。
提交内容：目标对照、演示、测试证据、版本、通过／驳回／附条件结论和反馈证据。		口头反馈必须由负责人整理后回传本角色会话，再经项目Hub进入正式流。决定通过或返工。
F7.5验收驳回。项目Hub → 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：验收驳回记录。
关联成果：三类验收成果及被驳回所影响的上游正式成果；包含问题类别、证据、字段/版本、责任角色和返回阶段。		禁止笼统地全部退回实现阶段。阶段保持处理中。
F7.6–7.7责任角色完成修正。角色 → 项目Hub → 产品/测试/业务修订成果：被驳回的上游正式成果新版本，以及更新后的平台提测通过报告／客户验收通过报告或附条件验收事项。
附带内容：修正说明、验证结果、证据引用和再次验收任务。		需要测试时必须先回测试阶段。重新验收。
F7.8验收通过或条件明确。业务 → 项目Hub最终确认成果：平台提测通过报告、客户验收通过报告、附条件验收事项的负责人确认版本。
附带内容：上线条件、附条件责任角色、期限和确认状态。		内部确认状态必须记录，条件不可为空泛。登记验收基线并开启发布结项。
-
- -
-
08 / CLOSE

阶段 8：发布结项信息流

项目Hub汇总应用、固件、板卡、BOM/ECO、测试和验收信息，形成完整归档和流程闭环。

-
协调项目Hub；技术负责人技术确认
核心成果结项资料归档、变更记录、结项报告、流程闭环总结
门禁版本匹配、冒烟通过、遗留事项有承接、归档完整
-
-
项目Hub
F8.1请求最终版本矩阵确认嵌入式应用层提交的最终固件必须绑定嵌入式底层、板卡和 BOM/ECO 版本
技术负责人
-
项目Hub
F8.2下发发布与归档任务按角色明确最终交付清单
嵌入式应用层 / 嵌入式底层 / 硬件
-
嵌入式应用层 / 嵌入式底层 / 硬件
F8.3分别提交最终固件、底层归档资料和 BOM/ECO最终固件只由嵌入式应用层提交；嵌入式底层不单独发布固件
项目Hub
-
项目Hub
F8.4请求发布冒烟与最终验证使用最终版本矩阵
测试
-
测试
F8.5提交冒烟结果和最终证据失败立即停止发布/结项
项目Hub
-
项目Hub
F8.6核对验收条件与遗留事项附条件项必须关闭或有承接
产品/业务
-
全部角色
F8.7提交内部确认的结项摘要和资料索引禁止只提供聊天记录
项目Hub
-
项目Hub
F8.8生成归档、变更记录和结项报告验证追踪链和缺失项
归档库
-
业务
F8.9确认结项或要求补充组织级结项由业务内部完成授权
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.3业务验收门禁通过。项目Hub ↔ 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件归档输入：嵌入式应用层固件包 最终版、被集成的 嵌入式底层实现资料、硬件实现资料、最终 版本矩阵 和角色发布声明。
将写入：结项资料归档、变更记录。		最终固件只由嵌入式应用层提交；嵌入式底层只提交被集成版本和归档资料；技术负责人确认整体版本匹配。形成发布候选。
F8.4–8.5发布候选锁定。项目Hub ↔ 测试过程记录：发布冒烟测试记录。
关联成果：测试证据包、结项资料归档、结项报告；提交冒烟任务、最终版本、结果和证据。		不得使用非最终版本。失败则停止发布并路由修复。
F8.6冒烟通过。项目Hub ↔ 产品/业务结项核对内容：平台提测通过报告／客户验收通过报告、附条件验收事项、未关闭风险和遗留事项。
将写入：结项报告、流程闭环总结。		每项必须关闭或有责任角色/期限。准备结项。
F8.7–8.8角色工作完成。角色 → 项目Hub → 归档库正式成果：结项资料归档、变更记录、结项报告、流程闭环总结。
角色提交内容：最终成果索引、版本、证据、变更记录、结项摘要和遗留事项；项目Hub生成可追踪结项包。		不能用聊天记录替代成果索引。生成结项包。
F8.9需要组织级结项确认。业务 → 项目Hub最终确认成果：结项报告、流程闭环总结 和 结项资料归档 完整性结论。
附带内容：结项批准或补充清单、确认状态和时间。		内部授权状态必须记录；补充项未关闭不得 CLOSED。批准后锁定四类结项成果并关闭项目。
-
- -
-
X / CROSS-CUTTING

贯穿全阶段：变更、阻塞与超时信息流

变更申请 和异常升级不属于某个单一阶段；项目Hub必须暂停受影响任务，组织并行影响评估，再决定是否重开阶段。

-
-
-
任意角色
X.1提交变更申请或阻塞记录附原因、证据、受影响版本和紧急度
项目Hub
-
项目Hub
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
项目Hub
-
项目Hub
X.4提交综合影响和建议列出批准/拒绝/延期的差异
业务
-
业务
X.5批准或拒绝变更内部授权后生成新基线，不覆盖旧版本
项目Hub
-
项目Hub
X.6超时提醒与升级专业事项升级给对应角色；项目级组织授权升级给业务
对应角色
-
-
-
- - - - -
ID触发条件发送 → 接收提交内容（对应正式成果）约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。任意角色 → 项目Hub过程记录：变更申请或阻塞记录。
关联成果：当前基线、受影响成果及版本、任务、原因、证据和紧急程度；批准后写入变更记录。		必须关联当前基线和受影响任务。创建变更或阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。项目Hub ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：角色影响评估。
提交内容：对受影响正式成果逐项给出范围、方案、工期、成本、测试、返工和版本影响，并列出建议修订的成果和版本。		各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全。项目Hub ↔ 业务过程记录：变更决定记录。
成果影响：综合影响清单、批准／拒绝／延期建议和新基线候选；批准后更新变更记录、相关正式成果和项目状态内部记录。		不得隐藏已完成工作损失、成本或里程碑影响。批准：新基线并重开受影响阶段；拒绝：维持原基线。
X.6确认或任务超过约定时间。项目Hub → 对应角色；项目级组织授权事项发给业务过程记录：升级通知。
提交内容：逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。		接收角色在内部完成确认后统一回复。保持等待确认或阻塞。
-
- -
-
Y / ARTIFACT WAIVER

贯穿全阶段：成果文件缺省与豁免信息流

成果文件默认必须输出。只有主责角色能够发起“不适用”申请；项目Hub负责项目级审查、影响确认、批准登记和门禁更新，禁止任何角色静默跳过。

-
发起者该成果在流程中的主责角色
项目Hub确认项目Hub；高影响豁免还需相关角色和业务完成内部确认
门禁结果需要成果 → 审查豁免 → 已豁免或仍需成果
-
-
成果主责角色
Y.1提交成果豁免申请说明为何本项目不适用，并附证据和替代信息
项目Hub
-
项目Hub
Y.2校验发起资格与可豁免性非主责角色、无证据或不可豁免成果直接退回
主责角色
-
项目Hub
Y.3向下游角色征询影响成果有下游消费者、接口或验收影响时触发
受影响角色
-
受影响角色
Y.4返回同意、反对或附条件意见必须说明替代证据和门禁影响
项目Hub
-
项目Hub
Y.5请求业务确认高影响豁免影响范围、架构、质量、安全、客户验收或外部承诺时
业务
-
项目Hub
Y.6批准或拒绝成果豁免汇总证据、下游意见和必要人类确认
成果登记与门禁
-
项目Hub
Y.7A批准：记录已豁免并分发豁免记录当前门禁视为已满足，但保留完整审计
全部受影响角色
-
项目Hub
Y.7B拒绝：仍需该成果返回主责角色生成文件或补充证据
成果主责角色
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 项目Hub成果类型、阶段、原因、事实证据、适用范围、替代成果、下游影响、风险和负责人确认。只有该成果主责角色可发起；“暂时来不及”不属于不适用。进入豁免审查，此时仍需要该成果。
Y.2中心收到豁免申请。项目Hub → 主责角色资格校验、结构校验、补充问题或拒绝理由。安全、法规和核心验收证据可明确为不可豁免。校验失败则退回，门禁保持阻塞。
Y.3–Y.4成果存在下游消费者，或缺省可能影响接口、测试、验收、制造和归档。项目Hub ↔ 受影响角色豁免摘要、替代证据、影响项、同意/反对/附条件意见。反对意见必须带具体依赖；项目Hub不得静默忽略。形成项目级影响结论。
Y.5豁免影响业务范围、外部承诺、总体架构、质量、安全、客户验收或组织责任。项目Hub → 业务申请、影响、下游意见、风险和建议。项目Hub无权单独批准高影响豁免；业务须完成内部授权。等待业务确认期间保持等待确认。
Y.6证据、影响意见及必要确认齐全。项目Hub → 成果登记/门禁成果类型、项目范围、基线引用、决定、确认人、确认时间、附加条件和失效条件。豁免只对当前项目、阶段和基线版本有效，不得作为全局永久规则。批准或拒绝。
Y.7A豁免批准。项目Hub → 全部受影响角色已豁免状态、豁免记录、替代成果和附加条件。不能删除原必需项；保留豁免记录。项目范围或输入基线变化时自动失效并重新评估。已豁免可满足当前门禁。
Y.7B豁免拒绝或附加条件未满足。项目Hub → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。仍需该成果，阶段继续阻塞。
-
-
-
Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.14
-
- - - diff --git a/doc/20260904/Codex多角色项目推进总流程图-V0.15.html b/doc/20260904/Codex多角色项目推进总流程图-V0.15.html deleted file mode 100644 index ddd992d..0000000 --- a/doc/20260904/Codex多角色项目推进总流程图-V0.15.html +++ /dev/null @@ -1,1312 +0,0 @@ - - - - - - - - Codex 多角色项目推进总流程图与信息流图谱｜V0.15 CURRENT - - - -
-
-
CODEX MULTI-ROLE PROJECT FLOW · V0.15 · CURRENT
-

项目推进总流程图

-

业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色，不是封闭列表；项目Hub负责信息路由、成员与状态维护和阶段门禁，新增自定义角色必须先形成职责、成果和决定权契约。

-
V0.15 · 当前基线2026-09-07 生效；已合并本轮确认变更，并同步 Skill 与角色提醒。
-
-
- - - -
-
-
-
VERSION / CHANGELOG
-
-

版本变更记录

-

每个新版本都保留上一版文件，并在当前版本中记录变更内容、影响范围和基线状态。

-
-
- -
- 版本管理规则：从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。评审版本标记为 REVIEW，并记录创建日期和待定的生效日期；只有取得明确的定版确认后，才改为 CURRENT，并同步更新文件名、页面标题、导航、页脚、本表及仓库中的当前流程基线引用。 -
-
- 版本号口径：V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。 -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
版本日期状态主要变更影响范围
V0.15创建：2026-09-04
生效：2026-09-07		CURRENT
  1. 精简业务及产品资料与选填项；立项增加平台 SDK、个参资料，项目风险前移阶段 2，删除独立产品资料整合。
  2. 取消独立接口契约、架构决策记录和硬件实现资料；阶段 3 硬件约束选填，明确阶段 5 硬件、底层交付。
  3. 补充工时评估；产品确认授权范围内资源与排期，预算、采购或对外承诺由业务批准。
  4. 精简测试输入，改用缺陷清单并共同商议责任人；可靠性、专项报告及提测佐证选填。
  5. 平台与客户验收可按条件并行且须双通过；平台由产品出具结论、客户由业务确认，测试资料直交产品。
  6. 结项聚焦资料收集与复盘；豁免精简为项目负责人审批，统一编号、成果引用及 Skill、角色提醒。
文档版本管理、阶段 1–8 总流程、成果矩阵、关联信息流、Skill 及八角色 Hook。
V0.142026-09-02HISTORICAL人工可读的正式成果、过程成果、标题、正文和结论统一使用中文，机器字段与枚举只保留在运行时工具参数中；项目Hub通过 Etunel 角色清单读取实际 role、display_name 和 relationship，成员角色不再向负责人追问成员、会话或任务编号；新增同源 JSON 和中文 HTML 两种版本的《项目成员清单》，并补充按阶段整理成果、过程记录、项目进度和成果索引的留档规则。全局成果语言、项目创建、角色登记、Etunel 实际字段、项目文件与进度留档、项目Hub与各成员角色约束和内部培训材料。
V0.132026-08-28HISTORICAL完成八角色跨文件一致性审核；新增项目成员／多账户／自定义角色规则和状态术语词典；区分项目创建时成员登记与阶段 4 角色分工；统一 NA、测试证据包、软硬件接口契约 和业务术语；同步测试主责的缺陷报告闭环；将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划；重新生成项目Hub系统提示词。全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员／任务分工、阶段 6 缺陷闭环、项目Hub提示词。
V0.122026-08-28HISTORICAL校正 测试计划 的阶段 3 主责；统一 测试计划 和五类阶段 6 正式成果，完善共同最低结构、NA／BLOCKED／成果豁免 边界、缺陷分析报告 主责、平台提测与业务验收边界；把缺陷专业归类和根因责任从项目Hub／测试的越权表述中移回有权角色。阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。
V0.112026-08-28HISTORICAL校正硬件角色的阶段 3 设计职责；拆分 硬件设计包 与 硬件实现资料；完善原理图、PCB、Gerber／钻孔、BOM、贴片／生产资料、板卡／批次标识、板级测量和硬件版本链；建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。阶段 3 硬件设计、阶段 5 板卡／样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。
V0.102026-08-28HISTORICAL校正嵌入式底层的阶段 3 设计职责；完善 嵌入式底层实现资料 最低内容、可消费／修复／归档版演进、板卡／BOM／ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界；扩充流程图底层成果说明。阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。
V0.92026-08-28HISTORICAL校正嵌入式应用层的阶段 3 设计职责；完善 嵌入式应用层固件包 最低内容、候选／提测／回归／发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束；继续清理项目Hub旧称和广播表述。阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。
V0.82026-08-28HISTORICAL新增文档内版本变更记录、版本号口径和历史文件保留规则；从本版本起不再通过重命名覆盖上一版。全局导航、版本管理、项目Hub流程基线引用。
V0.72026-08-28HISTORICAL修正技术负责人在阶段 3 与阶段 4 的责任顺序；明确总体方案、软硬件接口契约和架构决策的主责；明确项目Hub维护版本矩阵、技术负责人确认版本匹配。阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。
V0.62026-08-28HISTORICAL统一产品角色的阶段 2 与阶段 7 正式成果；补齐产品发起早期风险预检、产品定义评审和验收闭环；客户平台资料改为参考输入基线。阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。
V0.5未登记HISTORICAL BASELINE建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7；形成正式成果追踪矩阵。总流程、项目Hub、全局信息流、门禁和成果追踪。
-
-
- -
-
-
-

从业务需求到复盘结项

-

主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。

-
-
- 白色卡片＝项目阶段 - 黄色门＝角色/阶段确认 - 红色虚线＝返工回路 -
-
- -
-
-
01
-

业务需求

主责：业务
-
明确目标与价值。补齐业务对象、业务目标、范围。
-
正式成果项目背景说明
客户信息：对接客户名称、最终客户名称
项目名称：统一名称或客户规定的项目代号
产品要求：产品形态、提测平台
项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景：客户为什么提出这个需求，要解决什么问题
业务目标：本项目希望实现的业务结果
预期价值（选填）：可验证的价值假设
订单、预计销售额等信息均为选填，仅在项目适用时补充客户里程碑要求
提测时间
入库时间
小批量试产时间（选填）
量产时间（选填）
-
-
产品与业务确认需求基线
- -
-
02
-

产品定义

主责：产品 · 批准：业务
-
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。
-
正式成果立项资料
立项书：包含项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明等信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能项
灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
平台 SDK
个参资料
结构板框图（选填）：包含主要器件位置和禁止限制区域测试验收标准
平台测试用例
客户验收测试用例和验收标准里程碑要求
提测时间
客户验收时间
试产、量产时间（选填）项目风险
技术风险
时间风险
其他风险
-
-
产品确认方案，业务批准范围
- -
-
03
-

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
-
基于产品定义和阶段 2 已有评审结论形成可实施方案。
技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件（选填）：器件、PCB、电源/信号/热及接口约束测试：测试标准、测试用例范围、测试项
-
正式成果总体技术方案（选填）测试计划
测试标准、测试用例范围、测试项
-
-
技术负责人确认整体方案与测试计划，嵌入式应用层/嵌入式底层确认接口可实施，硬件约束选填，产品确认不偏离，测试确认可验证
- -
-
04
-

项目规划

主责：项目Hub
-
基于已确认的产品基线和方案设计成果，生成实际任务、人员分工和排期，引用阶段 2 项目风险。任务计划草案先由技术负责人确认；项目Hub只对存在疑点的任务定向询问对应执行角色，资源与排期基线再提交产品确认；确认后的计划与排期可由项目Hub同步给业务。
-
正式成果项目计划
项目任务拆分（工时评估）
实际项目排期角色分工
Etunel 实际 role 与 display_name
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
每项任务只有一个主责角色项目状态内部记录
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化
-
-
技术负责人确认任务计划，问题任务由对应执行角色定向确认，产品确认实际人员、资源与排期基线
- -
-
05
-

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件
-
嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。硬件先取得并核对器件规格书和结构板框图，形成并确认硬件设计包后，再据此推进硬件实现；嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口、任务或器件约束发生重大偏离时返回技术负责人和项目Hub确认。
-
正式成果硬件设计包
原理图
PCB 源文档
贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）
接口定义嵌入式底层实现资料
硬件功能测试报告
BSP 输出路径
PSP 输出路径
WiFi 设备定频测试固件（选填）嵌入式应用层固件包
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
zn_debug文件
Changelog
串口使能证书
-
-
嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配
- -
-
06
-

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件
-
执行功能、接口、软硬件集成和回归测试。
不通过测试与相关负责人共同商议缺陷责任人；项目Hub按确认分工安排修复，测试独立复验
通过形成必需测试正式成果及质量结论
-
正式成果功能测试报告
测试结论：通过/不通过
测试用例执行结果
bug: log日志可靠性测试报告（选填）
高低温测试
跌落测试（选填）
防水测试（选填）专项测试报告（选填）
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项提测佐证（选填）
平台要求的视频、截图、log材料缺陷清单
bug条目、状态、模块、责任人
bug数量、回头率、冒头率等统计
-
-
测试确认质量结论和剩余风险
- -
-
07
-

平台/客户验收

产品组织 · 平台：产品确认 · 客户：业务确认
-
平台验收在前，客户验收在后；输入就绪时可并行。产品确认收到测试直接交付的报告及已提供的提测佐证。
未通过按平台或客户问题定向整改，回到对应分支重新验收。
总条件平台通过（产品确认）+ 客户通过（业务确认），两项均通过后进入复盘结项。
-
正式成果平台验收报告或结论
产品出具并确认，无需业务确认客户验收通过报告
业务确认客户验收结果遗留问题清单
平台与客户共用一份，标明问题来源
-
-
平台验收通过（产品确认） + 客户验收通过（业务确认）
- -
-
08
-

复盘结项

项目Hub组织 · 相关角色提供资料与复盘输入 · 业务确认结项
-
收集项目资料，开展项目复盘并完成结项。项目Hub整理各阶段已确认成果、必要过程记录、项目进度和成果索引，核对双线验收与遗留问题承接，汇总经验及改进项。
-
正式成果结项资料归档
形成最终结果的流程文件变更记录结项报告流程闭环总结
项目复盘经验与改进项
-
-
- -
- 贯穿全流程：变更申请（需求变更申请） -

任何角色都可提出变更；项目Hub组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，变更按既定权限确认或批准，其中授权范围内的资源、排期调整由产品确认，涉及预算、采购或对外承诺时由业务批准；完成必要确认后更新对应基线，并从受影响阶段继续推进。

-
-
- 成果适用性：成果豁免（成果文件豁免） -

正式任务的阶段成果默认由主责角色输出；确认不适用时，由主责角色说明原因、影响和替代证据，由项目 Hub 对应真人负责人批准或拒绝，项目Hub记录人工决定；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。验证期确需跳过时，记录缺失项、风险和后续补齐安排，不把跳过写成成果已完成。

-
-
- -
-
-
STAGE INFORMATION FLOW ATLAS · V0.15 · CURRENT
-

各阶段角色信息流图谱

-

以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

-
- 通用规则成果追踪矩阵01 业务需求02 产品定义03 方案设计04 项目规划05 软硬件实现06 测试验证07 平台/客户验收08 复盘结项变更与异常成果豁免 -
-
绿色：正式成果、候选成果或正式基线黄色：过程记录、关联成果或修订对象
-
-
-
-
00 / RULES
-

所有阶段共同遵守的流转规则

成员 Agent 的跨角色任务、问题和结论仍经项目Hub定向中继、校验和登记。阶段 7 测试资料由测试负责人直接交付产品负责人，产品向项目Hub确认接收，文件不由项目Hub转发。

-
-
正式任务流转路径：触发事件 → 主责角色与本角色真人负责人对齐 → 完成指定文件、专业自审与负责人确认 → 向项目Hub提交成果及确认信息 → 项目Hub检查文件或已约定的交付索引、版本、证据、确认、依赖和冲突 → 定向路由目标角色 → 目标角色完成任务后返回项目Hub → 项目Hub留档并安排下游。信息流图只使用正式角色名称，不单列角色内部的 AI 会话与人工确认过程。阶段 7 文件直接交付与接收确认按该阶段约定执行，不要求大文件经过项目Hub传输。
-
正式任务默认要求主责角色输出约定成果；确认不适用时记录原因、影响和替代证据。验证期可由负责人决定跳转、回退或暂缓，但必须保留缺失项、风险和补齐安排，不能把跳过写成已通过，也不能静默删除已有文件。
-
- 项目Hub业务产品技术负责人嵌入式应用层嵌入式底层硬件测试 -
-
- - - -
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付；阶段 4 的资源与排期基线及后续授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时须由业务批准。不能替其他角色作出专业确认。
业务是；同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外，负责确认预算、采购/打样、对外承诺日期、暂停/取消，以及客户验收和项目结项；阶段 4 的计划与排期可由项目Hub同步知会业务，平台验收由产品确认而不经业务批准。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
项目Hub是项目Hub运行中心 AI，是项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和豁免登记；所有成果豁免均须项目负责人（项目Hub对应真人负责人）批准或拒绝。不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。
-
角色与成员配置：图中的八个角色是当前默认基线，不是永久封闭的角色集合。新增自定义角色前先定义目标、职责边界、参与阶段、正式成果、上下游依赖和确认权限，再由 Hub 真人负责人在 Etunel 中手动添加。项目Hub使用 etunel_list_roles 读取实际 role、display_name 和 relationship；各角色会话不向负责人重复确认成员 ID、会话 ID 或其他未由工具提供的字段。阶段 4 再通过《角色分工》将实际任务主责和交接关系正式基线化。
-
项目成员清单：项目创建完成后、首个正式任务派发前，项目Hub从同一次 etunel_list_roles 结果生成 JSON 版和全中文 HTML 版《项目成员清单》。两份清单只记录项目名称、版本、导出时间及工具实际返回的 role、display_name、relationship，不虚构成员、会话或人员编号。角色变化后生成新版本，不覆盖历史版本；该清单不替代阶段 4 的《角色分工》。
-
任务与状态规则：每项任务只有一个主责角色；依赖已经满足的多项任务可以形成任务波次，同一角色的内聚工作可以组成一个任务包。项目模式、任务结果、成果状态、阶段门禁、测试结论和业务验收含义不同，不得相互替代。对负责人使用“通过、失败、阻塞、不适用、延期”等自然中文；机器枚举只在工具字段明确要求时使用。
-
项目文件与进度留档：项目Hub按 项目资料/00-项目管理 和八个阶段目录整理资料，维护《项目概览》《项目进度》《成果索引》及必要的《阶段记录》。正式成果放入对应阶段的角色目录，重要草稿、退回原因、决定和阻塞放入过程记录；正式文件不覆盖，回退不删除历史。阶段交接和钉钉里程碑通知前先完成留档，但目录排版本身不是新的专业门禁。阶段 7 直接交付的测试资料以文件索引和产品接收确认为留档依据，项目Hub无需复制大文件。
-
-
任意角色
G.1提交已完成内部审查确认的消息、成果或请求说明完成情况、负责人确认、成果路径、版本、证据和待处理事项
项目Hub
-
项目Hub
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
-
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录
项目Hub
-
-
项目进度与按需同步：项目Hub持续维护 项目资料/00-项目管理/项目进度.md，并在对应阶段的《阶段记录》中追加重要事件。创建项目、启动任务波次、接收正式成果、重要退回、阻塞与解除、决定与变更、阶段切换／跳转／回退／暂缓和结项时更新；普通消息、队列状态和空确认不逐条留档。关键变化只向实际受影响角色推送，也响应角色按阶段或任务发起的查询。
-
-
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态说清关注阶段或任务、需要的信息和用途
项目Hub
-
项目Hub
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回
请求角色及受影响角色
-
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
项目Hub
-
项目Hub
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。任意角色 → 项目Hub查询范围、关注事项、所需详细度、期望时点和用途。只能查询项目授权范围内的信息；请求角色无需知道项目的内部存储结构。创建一次按需状态查询。
S.2收到 S.1；或阶段／门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化。项目Hub → 请求角色及受影响角色项目状态快照：当前阶段与门禁、相关任务、依赖、阻塞、风险、决定、成果引用、下一步、期限和证据。按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 项目Hub确认可以继续；或说明需要纠正的内容、正确值、原因、证据和负责人确认。没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。确认可继续执行，或触发状态纠正。
S.4纠正请求通过版本、证据及跨角色一致性检查。项目Hub → 全部受影响角色变更内容、旧值与新值、原因、证据、生效时间及受影响任务。保留状态历史，不覆盖旧版本；改变正式基线时必须转入变更申请。相关角色切换到新的有效状态快照。
-
异常协同补充机制：条件流、阻塞流、跨角色冲突或无法按时收敛的问题进入 E.1–E.4。项目Hub分别提醒实际相关角色并提供完整问题包；问题复杂时建议各角色真人负责人线下沟通。讨论结果由当前主责角色的负责人带回本角色会话，完成本角色任务后再提交项目Hub；角色 Agent 之间仍不直接通信。
-
-
项目Hub
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
-
项目Hub
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
-
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
项目Hub
-
项目Hub
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果
原流程及关联角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。项目Hub → 当前主责角色及实际关联角色问题摘要、证据与版本引用、冲突点、影响范围、所需角色和期望处理时间。项目Hub必须主动提醒，不得只更新状态；各角色依据正式问题包分别确认。原流程保持阻塞，等待问题关闭。
E.2涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。项目Hub → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。项目Hub只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。会议结论回传前，不恢复原流程。
E.3线下讨论完成并形成统一结论。当前主责角色 → 项目Hub会议决定记录：参与角色、统一结论、保留分歧、变更项、责任角色、期限、成果版本、证据和负责人确认。禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过项目Hub的形式、版本、证据和跨角色一致性检查。项目Hub → 原流程及关联角色登记结果、受影响成果或任务、恢复点、后续动作和新时限。项目Hub不改写专业结论；若结论改变正式基线，必须转入变更申请。从原来被阻塞的位置恢复当前流程。
-
- - - - - - - - - - - - -
通用约束执行要求不满足时
Etunel 消息Hub 使用工具实际提供的 role、kind、text、可选附件路径和关联字段；需要完成、阻塞或结算时，只从入站消息读取真实 message_id。机器字段不抄进给负责人的正文。字段不符合当前工具 schema 时停止调用并说明能力缺口，不得发明参数。
成果版本必须写清成果名称、当前版本、状态、替代关系和证据引用。作为草稿退回，并说明缺少内容。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签；项目Hub返回主责角色。
角色内部审查每个角色必须完成专业自查并取得当前真人负责人确认；跨角色流转时统一以正式角色名称表示。没有自查或负责人确认的成果不能作为正式成果提交项目Hub。
专业发起权专业活动由对应主责角色判断并发起；项目Hub只负责格式校验、任务路由、状态跟踪和结果登记。项目Hub不得越权替角色发起专业决策。
项目Hub审查边界仅做必填结构、文件、版本、证据、负责人确认，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请；由项目 Hub 对应真人负责人批准或拒绝，项目Hub记录人工决定；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。未批准时仍需要该成果；验证期跳转则记录缺失、风险和补齐安排。
角色确认专业结论由对应角色内部形成并确认；阶段 4 的资源与排期由产品确认，预算、采购及对外承诺等项目级组织授权仍由业务内部完成。信息流图只显示统一的正式角色主体。未完成负责人确认时不得作为正式结果发出。
项目状态同步项目Hub维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同项目对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。
跨角色沟通成员 Agent 之间不直接通信；任务、问题、最终结论、约束和影响都通过项目Hub定向中继。阶段 7 测试报告及已提供的提测佐证可由测试负责人直接交付产品负责人，接收确认回传项目Hub登记。未经确认或未登记的信息不能作为正式下游输入；已按阶段 7 确认接收的文件不要求项目Hub重新转交。
门禁正常顺序推进时，只有必需成果完整、版本正确、证据可访问、确认齐全才能通过；阶段 7 直接交付的测试资料以产品确认收到为交接依据，不要求项目Hub接收大文件。跳转、回退或暂缓按负责人决定另行记录。未满足且没有明确跳转决定时，阶段保持阻塞；接收确认不等于验收通过。
-
- -
-
00B / ARTIFACT TRACEABILITY

正式成果—信息流追踪矩阵

流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。

-
判定原则：正式成果必须由指定主责角色输出；过程记录只能解释校验、评审、冲突、变更和确认，不得替代正式成果。阶段 3 的总体技术方案，以及阶段 6 的可靠性测试报告、专项测试报告和提测佐证为选填成果，未提交不阻塞推进，也无需另行豁免；已提交时仍须完成版本登记和相应确认。若其他必需成果获准豁免，则以下对应流转中的成果引用改为豁免记录和替代证据。
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
阶段正式成果主责角色首次形成/提交评审、修订与确认正式分发/下游使用
1 业务需求项目背景说明业务F1.1F1.2 条件修订；F1.4 产品与业务确认F1.3 评审分发；F1.5 正式基线给产品
1 业务需求客户里程碑要求业务F1.1F1.2 条件修订；F1.4 产品与业务确认F1.3 评审分发；F1.5 正式基线给产品
2 产品定义立项资料产品F2.2F2.3–F2.6 专业评审与修订；F2.7–F2.8 业务批准F3.1 方案设计输入；F4.1 项目规划输入
2 产品定义测试验收标准产品F2.2F2.3–F2.6 测试评审；F2.7–F2.8 业务批准F3.3 测试计划任务输入；F3.7 提交计划；F6.1 测试输入；F7.1 验收输入
2 产品定义里程碑要求产品F2.2F2.3–F2.6 专业评审；F2.7–F2.8 业务批准F4.1 项目计划 输入；S.2 状态同步
2 产品定义项目风险产品汇总；相关专业角色提供意见F2.2F2.3–F2.6 评估与修订；F2.7–F2.8 确认范围与风险F3.1/F4.1/F5.1 引用当前有效风险；后续风险意见经项目Hub交产品维护
3 方案设计总体技术方案（选填）技术负责人F3.2（提供时）F3.4–F3.8 修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F8.2 收集、F8.6 归档
3 方案设计测试计划测试F3.7
提交测试标准、测试用例范围和测试项		F3.7 有缺口时经项目Hub转相关角色确认；F3.8 汇总；F3.9 技术负责人确认测试计划；F3.10 相关角色最终确认F4.1 测试任务规划输入；F6.1 测试任务输入
4 项目规划项目计划项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 定向修订；F4.6–F4.7 产品确认资源与排期F4.8 分发相关执行角色，可同步业务；F5.1 实现任务输入；后续由 X.4–X.5 按权限确认变更
4 项目规划角色分工项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 问题任务修订F4.8 随正式任务分发；F5.1 实现责任输入
4 项目规划项目状态内部记录项目HubF4.1 初始执行记录S.3–S.4 证据化纠正；E/X 流程更新F4.8 初始执行快照；S.2 自动或按需分发
5 软硬件实现硬件设计包硬件F5.2（所需输入资料齐备后）F5.2 硬件负责人确认；F5.3 技术负责人及受影响角色确认；F5.7 冲突修订；F5.8–F5.10 版本匹配确认F5.2 硬件实现依据；F5.3 定向分发；F8.2 收集、F8.6 归档
5 软硬件实现嵌入式底层实现资料嵌入式底层F5.4（WiFi 设备定频测试固件选填）F5.5 BSP/PSP 交嵌入式应用层合版；F5.7/F5.10 确认版本关系BSP/PSP 通过 F5.6 集成进统一固件；F8.2 提交归档资料
5 软硬件实现嵌入式应用层固件包嵌入式应用层F5.6 候选；F5.9 最终提测版F5.7 冲突修订；F5.8–F5.10 技术负责人确认F6.1 交测试；F6.8 回归版；F8.2 归档已验收版本
6 测试验证功能测试报告测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 确认F7.1 测试直接交付产品并确认接收；F8.2/F8.6 归档索引
6 测试验证可靠性测试报告（选填）测试F6.2（提供时）已提供时按 F6.3–F6.9 更新缺陷/回归；F6.10 确认已提供时由测试直接交付产品，F7.1 确认接收；F8.2/F8.6 归档索引
6 测试验证专项测试报告（选填）测试F6.2（提供时）已提供时按 F6.3–F6.9 更新缺陷/回归；F6.10 确认已提供时由测试直接交付产品，F7.1 确认接收；F8.2/F8.6 归档索引
6 测试验证提测佐证（选填）测试F6.2 登记索引（提供时）已提供时按 F6.3–F6.9 补充；F6.10 确认版本与索引F7.1 测试直接交付、产品确认接收；F7.2/F7.4 按需用于验收；F8.2/F8.6 归档索引
6 测试验证缺陷清单测试F6.2/F6.3F6.3 相关负责人共同确定责任人；F6.4–F6.9 修复与测试回归；F6.10 确认F7.1 验收限制输入；F8.2 收集、F8.6 归档
7 平台/客户验收平台验收报告或结论产品F7.3（二选一即可）产品确认；F7.8–F7.9 返工后重新确认；无需业务确认F7.10 双线门禁；F8.2 收集、F8.3 结项核对
7 平台/客户验收客户验收通过报告产品F7.5 草案F7.6–F7.7 业务确认客户结果；F7.8–F7.9 返工后重新确认F7.10 双线门禁；F8.2 收集、F8.3 结项核对
7 平台/客户验收遗留问题清单产品F7.3、F7.5 分别更新同一份清单，标明平台／客户来源F7.8–F7.9 更新处置结果、责任人与期限；F7.10 汇总核对双方问题F8.3 关闭或确认承接；写入结项报告
8 复盘结项结项资料归档项目HubF8.2 收集；F8.6 汇总F8.3 核对；F8.7 完整性与结项确认项目关闭后锁定归档
8 复盘结项变更记录项目HubX.1–X.5 持续记录；F8.6 汇总每次变更决定更新；F8.7 结项检查随结项资料归档锁定
8 复盘结项结项报告项目HubF8.6F8.2–F8.5 提供输入；F8.7 业务确认结项项目关闭依据与归档入口
8 复盘结项流程闭环总结项目HubF8.4–F8.5 复盘输入；F8.6 汇总F8.7 结项确认项目经验、改进项跟进与后续复用
-
- -
-
01 / BUSINESS

阶段 1：业务需求信息流

把客户背景、业务目标和关键里程碑转换成经产品与业务确认的需求基线。

-
主责业务
核心成果项目背景说明、客户里程碑要求
门禁产品与业务确认同一需求基线后进入产品定义
-
业务完成原始信息收集、成果自查和负责人确认后，以统一的“业务”主体提交成果。项目Hub完成文件、版本、证据和跨角色冲突检查后，在 F1.3 将业务成果评审版本路由给产品。产品与业务通过项目Hub澄清待确认项，并分别完成本角色负责人确认，确认同一需求基线。双方确认后，项目Hub登记留档并向产品分发正式业务基线，即可开启产品定义。
-
-
业务
F1.1提交完成内部审查的项目背景与客户里程碑要求草案附负责人确认、来源引用和实际成果文件
项目Hub
-
项目Hub
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限文件结构、版本、证据和已登记信息冲突；无异常则不启用此流
业务
-
项目Hub
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
-
产品 / 业务
F1.4产品与业务确认需求基线经项目Hub中转，双方分别确认同一版本
项目Hub
-
项目Hub
F1.5向产品分发正式业务基线并开启产品定义双方确认后留档，分发当前有效版本即可进入阶段 2
产品
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户需求或业务机会，且业务已完成原始信息收集、自查和负责人确认。业务 → 项目Hub正式成果草案：项目背景说明、客户里程碑要求。
附带内容：负责人确认、来源引用、成果版本和实际文件。		项目Hub不重复判断业务内容质量，只检查形式和跨来源一致性。进入中心登记。
F1.2（条件流）仅当文件结构、版本、证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。项目Hub → 业务过程记录：形式校验问题清单或冲突清单。
关联成果：受影响的项目背景说明／客户里程碑要求及其字段、版本、冲突来源和修正要求。		项目Hub不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。
F1.3业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。项目Hub → 产品评审分发成果：待评审的项目背景说明、客户里程碑要求。
附带内容：成果版本、状态、证据、待确认项和回复时限。		标明待评审状态；经产品与业务确认并留档后，才可作为阶段 2 输入。产品与业务通过项目Hub进入 F1.4 需求基线确认。
F1.4F1.3 已分发评审版本，业务内部审查和中心形式校验已完成。产品 ↔ 项目Hub ↔ 业务确认成果：经产品与业务各自负责人确认的项目背景说明、客户里程碑要求。
附带内容：确认状态、确认时间、确认条件和版本。		待确认项经项目Hub中转澄清；记录双方各自负责人确认状态、时间和版本，双方须确认同一版本。双方确认后通过门禁，进入 F1.5 并开启产品定义。
F1.5产品与业务确认同一需求基线，项目Hub已登记并留档正式版本且阶段门禁通过。项目Hub → 产品正式基线：项目背景说明、客户里程碑要求的当前有效版本。
附带内容：成果版本、基线与证据引用、阶段 2 任务和确认时限。		只允许分发已经确认并留档的当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
-
- -
-
02 / PRODUCT

阶段 2：产品定义信息流

产品形成立项资料、测试验收标准、里程碑要求及项目风险。技术负责人、嵌入式应用层、嵌入式底层、硬件和测试按指定范围提供专业可行性与风险意见，由产品汇总技术风险、时间风险及其他风险。

-
主责产品；业务批准范围
核心成果立项资料、测试验收标准、里程碑要求、项目风险
门禁产品确认方案，业务批准范围，约束和测试标准完整
-
-
项目Hub
F2.1下发产品定义任务附产品与业务已确认的阶段 1 基线及已知约束
产品
-
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
-
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
-
项目Hub
F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突，不替产品作内容决定
产品
-
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
项目Hub
-
项目Hub
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
-
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。项目Hub ↔ 产品输入基线：项目背景说明、客户里程碑要求。
产品提交的正式成果草案：立项资料（含平台 SDK、个参资料）、测试验收标准、里程碑要求、项目风险。
参考输入（非阶段成果）：项目已有的器件规格、板框约束、串号表、平台对接文档和开发规范。		产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试评审分发成果：按角色裁剪上述四类产品定义成果草案。
参考输入：只附与评审问题相关的现有器件、板框和平台资料；另含成果版本、基线引用、评审范围、问题和时限。		项目Hub只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub过程记录：角色评审结果（角色评审结论）。
关联成果：四类产品定义成果的具体字段；提交结论、缺失、风险、证据、建议和是否阻塞。		不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。项目Hub ↔ 产品修订成果：受影响的 立项资料、测试验收标准、里程碑要求、项目风险 新版本。
附带内容：字段级修订清单、变更影响和关闭说明。		产品在内部确认最终版本后统一发出。问题未关闭则暂缓推进。
F2.7–2.8产品方案专业评审完成。项目Hub ↔ 业务批准成果包：四类产品定义成果的负责人确认候选版本。
附带内容：范围、验收、里程碑、风险、附条件事项、版本和确认状态。		范围批准由业务完成内部授权后统一给出。批准并留档后作为正式基线进入阶段 3。
-
- -
-
03 / DESIGN

阶段 3：方案设计信息流

技术负责人依据产品定义基线，结合阶段 2 已有评审结论组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试依据同一产品基线，对方案和接口约束完成多轮确认。测试提交测试计划，无问题时由项目Hub汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先经项目Hub转交相关角色确认，由测试修订计划后再汇总确认。

-
主责技术负责人组织方案与接口确认，主责选填的总体技术方案，并确认测试计划；硬件接口与约束为选填；测试主责测试计划
核心成果测试计划；总体技术方案为选填
门禁方案确认、接口可实施、需求不偏离、测试可验证，测试计划经技术负责人确认
-
总体技术方案为选填，未提供不阻塞阶段推进，也无需另行豁免；必要的技术决定及接口约束仍须写入角色确认记录。硬件的器件、PCB、电源/信号/热及接口约束在本阶段为选填，未提供不阻塞，也无需豁免；已提供时完成对应确认。阶段 5 的硬件前置输入和设计包交付要求不变。
-
-
项目Hub
F3.1下发总体方案设计任务附产品定义基线、阶段 2 已有评审记录和现有技术参考资料
技术负责人
-
技术负责人
F3.2提交设计要点与待确认接口约束含边界、关键决策、非功能和风险；附已提供的总体技术方案
项目Hub
-
项目Hub
F3.3并行分发角色化设计任务各角色依据同一产品基线和已分发的接口约束开展工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
-
嵌入式底层
F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
项目Hub → 硬件 / 技术负责人
-
硬件
F3.6反馈硬件约束（选填）器件、PCB、电源、信号、空间、热及接口约束，提供时说明实际影响
项目Hub → 技术负责人 / 嵌入式底层 / 产品
-
测试
F3.7提交测试计划，说明是否存在可测性缺口无问题：项目Hub汇总给技术负责人确认
有不可测试项或环境、治具缺口：项目Hub转交相关角色确认
项目Hub
-
项目Hub
F3.8汇总测试计划与设计反馈，请求确认无问题时直接提交；有缺口时先取得相关角色确认，由测试修订计划后再汇总
技术负责人
-
技术负责人
F3.9返回方案、接口及测试计划确认结果确认与整体方案、接口及实施依赖一致；附已提供的选填成果
项目Hub
-
项目Hub
F3.10请求各角色确认接口可实施、测试可验证嵌入式应用层、嵌入式底层、产品、测试分别确认；硬件选填内容已提供时确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.3阶段 2 门禁通过，产品定义基线有效。项目Hub ↔ 技术负责人/协作角色按主责角色分别形成的正式成果草案：技术负责人按需提供总体技术方案。测试按任务编制 测试计划，包含测试标准、测试用例范围、测试项，并在 F3.7 提交。
过程记录：技术负责人提交设计要点与待确认接口约束，各相关角色完成接口与约束确认。
输入内容：阶段2四类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录（如有）、设计范围和时限。		方案设计不得依赖尚未形成的 项目计划；所有设计必须引用同一产品基线。开启并行方案设计。
F3.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人过程记录：接口需求及确认结果。
关联或修订成果：已提供的总体技术方案。
提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。		接口调整经项目Hub转交相关角色确认，不得私下约定。更新接口确认结果；改变正式基线时走变更申请。
F3.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 项目Hub → 硬件 / 技术负责人过程记录：接口与硬件约束确认。
提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。		涉及既有板卡时引用明确版本；新设计注明约束版本。冲突时阻塞相关设计。
F3.6硬件提供本阶段选填约束时。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品关联或修订成果：必要时修订已提供的总体技术方案。
过程记录：硬件约束与接口确认。
提交内容：限制、替代方案、成本、性能和交期影响。		本阶段硬件约束为选填，未提供不阻塞；已提供时器件替换不得静默发生。按已提供内容更新接口与约束确认；改变正式基线时走变更申请。
F3.7测试已形成测试计划，或识别出不可测试项、环境/治具缺口。测试 → 项目Hub；无问题时汇总给技术负责人；有缺口时定向转交相关角色确认正式成果：测试计划，包含测试标准、测试用例范围、测试项。
存在缺口时附带：不可测试项、环境/治具缺口、影响、依据及需要相关角色确认的问题。
确认回传：相关角色经项目Hub返回确认结果，测试据此修订测试计划；涉及接口或验收标准时同步对应主责角色修订。		无问题时无需等待缺口确认；项目Hub只汇总和中继，不代替专业角色确认。测试仍主责计划编制与修订，技术负责人经 F3.8–F3.9 确认测试计划。影响本阶段门禁的缺口应先关闭；验证期需跳转时，由负责人明确记录决定。无问题：进入 F3.8–F3.9 汇总确认；有缺口：先定向确认、修订，再返回该确认路径。
F3.8–3.10专业评审完成。项目Hub ↔ 技术负责人；项目Hub ↔ 各相关角色最终确认成果：测试计划的内部确认版本，以及已提供的选填成果（总体技术方案）。
附带内容：方案与接口确认结果、保留风险、证据引用和统一版本关系。		测试计划仍由测试编制和维护，技术负责人确认其与整体方案、接口及实施依赖一致；相关角色按本领域完成最终确认。每个确认绑定同一版本；选填成果未提供不阻塞本阶段；成员角色之间不直接通信。全部确认并登记为正式基线后进入阶段 4 项目规划。
-
- -
-
04 / PLANNING

阶段 4：项目规划信息流

项目Hub根据产品基线和已确认的方案设计成果生成实际任务计划，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。资源与排期由产品确认，计划与排期可由项目Hub同步给业务。

-
主责项目Hub；技术负责人确认技术结构，产品确认资源与排期
核心成果项目计划、角色分工、项目状态内部记录
门禁技术负责人确认技术任务结构、顺序和依赖；问题任务完成定向确认；产品确认资源与排期基线
-
项目风险已在阶段 2 由产品汇总形成，本阶段只引用并反馈新增风险，由产品维护当前有效版本；不重新创建阶段 4 风险成果。产品资料整合不再作为独立成果，任务按需引用已有立项资料、方案记录和成果索引。
-
-
项目Hub
F4.1提交任务计划与正式角色分工草案，请求整体确认附产品／方案基线、角色清单、任务拆分、技术顺序、依赖、初始排期和风险
技术负责人
-
技术负责人
F4.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系、专业角色覆盖和关键风险
项目Hub
-
项目Hub
F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
-
对应执行角色
F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
项目Hub
-
项目Hub
F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
-
项目Hub
F4.6请求资源与排期基线确认真实人员、资源安排和排期由产品负责人确认
产品
-
产品
F4.7确认或要求调整资源与排期基线记录产品负责人确认状态、范围、条件和版本
项目Hub
-
项目Hub
F4.8向相关执行角色发布基线计划和正式任务执行角色取得充分任务输入；计划与排期可同步业务（仅知会）；后续按 S.1–S.4 同步
相关执行角色
业务（可同步知会）
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.2阶段 3 方案设计门禁通过，项目Hub已依据产品基线、方案设计成果和项目创建期角色清单形成任务计划草案。项目Hub ↔ 技术负责人正式成果草案：项目计划、角色分工、项目状态内部记录 初始版。《角色分工》列出 Etunel 实际 role 和 display_name、职责边界、任务主责、协作关系和交接要求。
输入基线：阶段 2 产品成果、阶段 3 已确认的必需成果及已提供的选填成果和角色清单；另含任务拆分、关键路径、输入输出、依赖、初始排期和风险。		技术负责人确认技术任务结构、顺序、依赖、版本关系、专业角色覆盖和技术风险；项目Hub不向全部执行角色征求整份计划确认。每项任务只设一个主责角色。形成技术结构与角色覆盖已确认的任务计划草案。
F4.3–4.4（条件流）项目Hub发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。项目Hub ↔ 对应执行角色修订对象：项目计划、角色分工、项目状态内部记录 中的问题任务。
过程记录：任务澄清请求／任务澄清回复，包含方案成果引用、上下游依赖、工期、资源、风险和负责人确认。		必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务；未触发时直接跳过。
F4.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。项目Hub ↔ 技术负责人及受影响角色修订成果：项目计划、角色分工、项目状态内部记录 新版本。
过程记录：冲突解决记录，包含冲突点、方案约束、可选排法、阶段影响和响应时限。		项目Hub必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。保持计划草案，冲突关闭前不得基线化。
F4.6–4.7技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，资源安排与排期候选基线已形成。项目Hub ↔ 产品待确认成果：项目计划、项目状态内部记录 候选基线。
附带内容：人员与资源安排、工时评估、排期、里程碑、风险、确认范围、条件和状态。		项目Hub不能代替产品确认资源与排期；产品完成负责人确认后统一回复。本环节不替代预算、采购/打样及对外承诺所需的业务授权。产品确认后可基线化。
F4.8技术负责人确认有效、问题任务已关闭且产品确认资源与排期基线。项目Hub → 相关执行角色；可另行同步业务正式基线：项目计划、角色分工、项目状态内部记录。
执行角色状态快照：只包含该角色相关任务、充分输入、依赖、方案成果引用、门禁、风险、时限、成果文件和完成条件。
业务同步（按需）：项目计划、实际项目排期和关键里程碑。		每个角色只接收与自身任务和依赖相关的计划内容；后续角色加入、退出、替换或变化必须登记并交接，改变基线时走变更申请；执行状态按 S.1–S.4 同步；业务同步为知会，不等待业务确认，也不新增门禁。相关角色接收任务，开启阶段 5。
-
- - - -
-
05 / IMPLEMENT

阶段 5：嵌入式软硬件实现信息流

三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进；硬件先取得并核对器件规格书和结构板框图，形成并确认硬件设计包后再据此实施；固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，项目Hub维护其与硬件版本的唯一映射。

-
并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件设计包、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测
-
- F5.2 硬件资料要求
- 前置输入（由上游资料责任角色提供）：
1、外设器件和关键器件（主控、flash、sensor、复位按键、指示灯、WiFi模块、音频功放驱动芯片、IR-CUT驱动芯片、电机达林顿管驱动芯片）规格书。
2、结构板框图（包含主要器件位置和禁止限制区域）。
- 硬件设计资料（纳入硬件设计包）：
1、原理图。
2、PCB 源文档。
3、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）。
4、接口定义。
- 执行前提：硬件先核对项目实际使用器件的规格书，以及结构板框图的来源、适用范围和版本。结构板框图在阶段 2 可选填，但进入 F5.2 前须补齐；资料缺失或冲突时，经项目Hub向对应资料责任角色补齐，不以假设替代输入，仅阻塞依赖这些资料的硬件任务。 -
-
-
项目Hub
F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界；硬件另附器件规格书、结构板框图
嵌入式应用层 / 嵌入式底层 / 硬件
-
硬件
F5.2取得前置输入后提交硬件设计包器件规格书、结构板框图齐备后设计；硬件负责人确认后提交
项目Hub
-
项目Hub
F5.3定向分发硬件设计包及约束变化设计包先完成技术及接口确认，后续只向受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
-
嵌入式底层
F5.4提交嵌入式底层实现资料硬件功能测试报告、BSP 输出路径、PSP 输出路径
WiFi 设备定频测试固件（选填）
项目Hub
-
项目Hub
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版按已登记的 BSP/PSP 输出路径交付；定频测试固件仅用于专项测试
嵌入式应用层
-
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层和板卡版本，引用已确认的接口定义，包含 MD5、分区、自测和 Changelog
项目Hub
-
任一实现角色
F5.7报告接口、器件或资源冲突接口约束不一致、资源超限或 ECO 影响时
项目Hub → 技术负责人
-
项目Hub
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
-
嵌入式应用层
F5.9提交最终提测固件版本联调问题关闭后，由嵌入式应用层提交最终固件，附完整版本链、自测和偏离说明
项目Hub
-
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测联调问题已关闭且最终版本已提交；确认板卡、BOM、统一固件及其应用/底层版本链匹配
项目Hub
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1阶段 4 项目规划门禁通过。项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件待产出成果：嵌入式应用层固件包、嵌入式底层实现资料、硬件设计包。
输入与任务：阶段3已确认的必需成果及已提供的选填成果、阶段4 项目计划（项目任务计划）与角色分工、阶段2 项目风险，以及任务、输出格式、依赖和期限。
硬件额外输入：F5.2 所列器件规格书和结构板框图。		三方必须使用相同的方案设计基线和项目计划版本；硬件输入未齐时先补齐资料，不阻塞其他依赖已满足的任务。依赖已满足的实现任务并行启动。
F5.2–5.3硬件已取得并核对 F5.2 所列输入资料，形成或修订硬件设计包；后续发布样机、板卡、BOM 或 ECO。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试前置输入：项目实际使用的外设器件和关键器件规格书、结构板框图（主要器件位置和禁止限制区域），具体清单见本阶段 F5.2 硬件资料要求。
正式成果：硬件设计包，登记明确版本。
硬件设计资料（纳入硬件设计包）：原理图；PCB 源文档；贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）；接口定义。先由硬件负责人确认，再经项目Hub中继技术负责人及受影响角色完成技术与接口确认。		所需输入资料未齐备或版本未核对时，先经项目Hub补齐，不得提交正式硬件设计包；设计包确认前不得投板或以未确认设计推进样机制作；没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。输入缺失时阻塞相关硬件任务；影响接口、底层或应用固件时阻塞受影响任务。
F5.4–5.5嵌入式底层已形成硬件功能测试报告，BSP 与 PSP 输出路径可访问且版本明确。嵌入式底层 → 项目Hub → 嵌入式应用层正式成果：嵌入式底层实现资料 当前版本。
必需内容：硬件功能测试报告；BSP 输出路径；PSP 输出路径。
选填内容：WiFi 设备定频测试固件。
附带信息：输出版本、适配板卡、BOM/ECO、配置及适用的接口定义版本，以及必要的应用层集成说明、已知限制和风险。		BSP/PSP 路径必须指向可访问的实际输出；硬件功能测试报告记录底层已执行的硬件功能测试，不代替测试角色的整机质量结论。WiFi 设备定频测试固件为非必选项，未提供不阻塞合版、提测或阶段推进，也无需另行豁免；提供时标明 TEST_UTILITY_ONLY，仅用于专项测试，不得作为最终提测或发布固件。项目Hub登记必需成果后，将 BSP/PSP 可消费版本交嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 项目Hub正式成果候选：嵌入式应用层固件包。
提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、zn_debug文件、Changelog、串口使能证书，以及应用/底层/板卡版本链及适用的接口定义版本。		必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 项目Hub → 技术负责人过程记录：实现冲突记录。
关联成果：受影响的硬件设计包、嵌入式底层实现资料、嵌入式应用层固件包及相关接口约束；提交冲突、证据、版本、影响和建议。		项目Hub立即冻结受影响版本。等待技术裁决及相关设计、接口约束更新。
F5.8统一固件候选和硬件候选版本均已就绪。项目Hub → 嵌入式应用层 / 硬件 / 技术负责人联调输入：统一固件候选、硬件候选及对应版本链。
过程记录：软硬件联调任务、候选版本矩阵和联调问题记录。		候选版本就绪即可启动联调，不以联调问题已关闭作为启动条件。开展软硬件联调并处理问题；问题关闭后进入 F5.9–F5.10。
F5.9–5.10联调问题已关闭；F5.9 提交最终提测版本，F5.10 在提交后进行匹配与可提测确认。嵌入式应用层 → 项目Hub；技术负责人 → 项目Hub最终确认成果：嵌入式应用层固件包、硬件设计包；引用已集成的嵌入式底层实现资料。
过程记录：版本矩阵、集成记录、集成批准；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。		最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由项目Hub将该唯一固件版本交给测试。
-
- -
-
06 / TEST

阶段 6：测试验证与缺陷返工信息流

测试提交测试报告和缺陷清单，由测试与实际相关角色负责人共同商议缺陷责任人；项目Hub按确认分工安排修复和重新提测。

-
主责测试
核心成果功能测试报告、缺陷清单；可靠性测试报告、专项测试报告、提测佐证（均选填）
门禁阻断缺陷清零，必需成果及其测试依据完整，测试完成内部确认并提交质量结论
-
可靠性测试报告、专项测试报告和提测佐证均为选填。未提供这些选填成果不阻塞阶段 6 交付、后续验收或归档，也无需另行豁免；已提供时确认对应版本和测试负责人意见。可靠性测试报告包括高低温测试、跌落测试（选填）、防水测试（选填）。选填设置不改变已确认的测试范围和质量门禁。
-
无缺陷路径：F6.2 → F6.10。测试已完成且无缺陷时，仍提交功能测试报告和零缺陷清单，直接进入最终质量结论确认，不创建无必要的修复任务。发现缺陷时才进入 F6.3–F6.9 的责任确认、修复和回归流程；两条路径均须满足 F6.10 的质量门禁。
-
-
项目Hub
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
-
测试
F6.2提交功能测试报告和缺陷清单测试完成且无缺陷：提交报告和零缺陷清单，直接进入 F6.10；有缺陷则进入 F6.3，关联版本、用例和证据
项目Hub
-
项目Hub
F6.3分发缺陷清单，协调相关负责人商议责任人测试与实际相关角色负责人共同确定每项缺陷的责任人
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F6.4向项目Hub返回确认的责任分工、原因分析和修复计划责任人、协作关系、处理时限和影响范围经对应负责人确认
项目Hub
-
项目Hub
F6.5向责任角色派发修复或专业澄清任务同时将确认结果同步给测试维护缺陷清单；责任争议由相关负责人协调，项目Hub不自行归责
责任角色
测试（同步确认结果）
-
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明替代关系和影响范围
项目Hub
-
项目Hub
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
-
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
项目Hub
-
项目Hub
F6.9下发定向回归任务和统一固件附版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认提交整包
测试
-
测试
F6.10提交内部确认的最终质量结论和剩余风险功能测试报告和缺陷清单完整，已提供的选填成果完成确认后
项目Hub
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。项目Hub ↔ 测试测试输入：嵌入式应用层固件包、版本矩阵、测试计划。
必需成果草案：功能测试报告、缺陷清单。
选填成果：可靠性测试报告、专项测试报告、提测佐证。
提测佐证内容（选填）：平台要求的视频、截图、log材料。
佐证提交方式：提供时只向项目Hub登记文件索引、版本和交付状态；文件由测试直接交付产品，F7.1 确认接收。		测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。底层实现资料和硬件设计包不再列为阶段 6 的常规测试输入，不因未附这两类资料拒绝提测；具体测试或定位确需信息时按实际问题经项目Hub查询，不重新要求整包提交。启动测试并更新测试状态；测试完成且无缺陷时，F6.2 提交功能测试报告和零缺陷清单后直接进入 F6.10，不创建无必要的修复任务；有缺陷则进入 F6.3。
F6.3测试发现缺陷或测试异常并形成可追踪记录。测试 → 项目Hub → 实际相关角色提交与更新成果：测试主责的《缺陷清单》。
分发内容：缺陷编号、现象、状态、模块、版本、环境、用例、复现、证据、影响、风险、优先级和回归要求。
商议结果：缺陷责任人、主责角色、协作角色及处理时限。		测试与实际相关角色的负责人共同商议解决缺陷的责任人，每项缺陷明确一名责任人和一个主责角色。项目Hub只登记已确认的分工并路由，不自行指定责任人；跨层技术问题由技术负责人提供判断依据，需求含义由产品澄清。分歧未收敛时按 E.1–E.4 协调。确认缺陷责任分工后，由责任角色在 F6.4 返回原因与计划，项目Hub在 F6.5 派发任务。
F6.4相关负责人已共同确认缺陷责任人，责任角色完成原因分析与计划确认。责任角色 → 项目Hub过程记录：确认的责任人、主责与协作角色、原因分析和修复计划，包含影响、方案、风险、修复成果计划、期限、需重测范围和证据；必要时引用技术／产品决定。“无法复现”“符合设计”或“不修复”必须带理由与证据；责任人调整仍需相关负责人共同确认。项目Hub接收确认结果，进入 F6.5 派发任务并同步测试。
F6.5项目Hub收到 F6.4 已确认的原因分析、责任分工和修复计划。项目Hub → 责任角色；同时项目Hub → 测试派发任务：按已确认分工向责任角色派发修复或专业澄清任务，明确输出、期限和回归要求。
同步确认结果：将已确认的责任分工、原因分析及修复计划同步给测试，由测试维护同一份《缺陷清单》的责任人、状态和回归要求。		项目Hub不自行归责；实现角色不直接替换或关闭测试主责的《缺陷清单》。阻断缺陷使阶段阻塞；等待修复成果和目标版本复验。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试实现角色修订成果：嵌入式应用层固件包、嵌入式底层实现资料或硬件设计包。
同步给测试的确认结果：责任分工、修复进展及必要变更说明，包含目标版本、影响和建议回归范围；测试据此维护《缺陷清单》。回归统一按 F6.9 提交统一固件、版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认提交实现资料整包。
硬件 ECO 额外内容：新旧板卡／PCB／BOM／ECO 差异、受影响批次、返工／回退方式、板级验证证据、底层驱动／HAL 兼容评估、应用固件有效性确认和新版本矩阵。		实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。形成唯一可回归的固件与硬件版本矩阵，并由测试复验。
F6.9统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。项目Hub → 测试回归输入：统一固件、版本矩阵、缺陷清单及必要变更说明。具体定位资料按实际问题经项目Hub提供，不默认提交底层实现资料或硬件设计包整包。
过程记录：回归任务，包含修复范围、受影响用例和时限。		旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10测试完成且无缺陷时由 F6.2 直接进入，或缺陷处理及必要回归完成后进入；均须阻断缺陷清零且必需成果及其测试依据齐全。测试 → 项目Hub最终确认成果：功能测试报告、缺陷清单的负责人确认版本。
已提供时一并确认：可靠性测试报告、专项测试报告、提测佐证。
附带内容：质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。		测试内部确认状态必须记录；剩余风险必须有接受方；选填成果未提供不作为门禁阻塞项。提测佐证提供时只登记索引、版本和测试负责人确认，无需向项目Hub上传大文件。门禁通过并留档后开启验收。
-
- -
-
07 / ACCEPT

阶段 7：平台验收与客户验收信息流

平台验收在前、客户验收在后；各自输入就绪时可并行开展。平台结果由产品确认，客户结果由业务确认，两部分均通过后才完成阶段 7。

-
主责产品组织两部分验收；平台由产品确认，客户由业务确认；项目Hub登记与协调
核心成果平台验收报告或结论、客户验收通过报告、遗留问题清单
总门禁平台验收通过 + 客户验收通过，两项缺一不可
-
资料交接：测试负责人直接向产品负责人交付测试报告及已提供的提测佐证，文件不经项目Hub转发。产品只需确认收到对应资料；项目Hub登记文件名称、版本和接收确认，不要求大文件上传或重复转交。提测佐证仍为选填，未提供不阻塞验收；收到材料不等于验收通过。
-
-
产品
F7.1确认收到测试报告及已提供的提测佐证测试直接交付文件；项目Hub仅登记产品接收确认
项目Hub
-
-

第一部分：平台验收

-
-
项目Hub
F7.2组织平台验收，明确验收对象和依据优先启动平台验收；产品使用已收到的测试资料
产品
-
产品
F7.3出具平台验收报告或结论产品负责人确认通过或不通过，无需业务确认；更新同一份《遗留问题清单》，标明平台来源
项目Hub
-
-

第二部分：客户验收

-
-
项目Hub
F7.4组织客户验收，准备客户验收资料客户验收输入就绪时，可与平台验收并行，不必等待平台先通过
产品
-
产品
F7.5提交客户验收报告和遗留问题清单客户反馈按联络边界取得；更新同一份《遗留问题清单》，标明客户来源并保留平台问题
项目Hub
-
项目Hub
F7.6请求业务确认客户验收结果只确认客户验收部分，不追加平台验收审批
业务
-
业务
F7.7确认客户验收通过或退回整改明确客户反馈、结论、版本及遗留问题承接
项目Hub
-
-

共用返工与验收总门禁

-
-
项目Hub
F7.8定向路由平台或客户验收未通过的问题只处理实际受影响部分；需要测试时返回阶段 6
实际相关责任角色
-
责任角色
F7.9提交整改成果、说明及必要复验结果平台返回 F7.2–F7.3；客户返回 F7.4–F7.7，分别更新结论
项目Hub
-
项目Hub
F7.10核对平台通过 + 客户通过，登记验收基线汇总核对同一份《遗留问题清单》及来源；平台有产品确认、客户有业务确认，两项均通过后进入阶段 8
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1测试门禁通过，测试已向产品交付必需测试报告。测试负责人 → 产品负责人（直接交付文件）；产品 → 项目Hub（接收确认）接收确认：产品确认已收到测试报告及已提供的提测佐证，说明对应文件名称和版本。
验收输入：功能测试报告、缺陷清单及已提供的选填成果（可靠性测试报告、专项测试报告、提测佐证），以及嵌入式应用层固件包、版本矩阵和已知限制。		项目Hub只登记交付索引与产品接收确认，不中转文件，不以大文件上传为交接条件；选填成果未提供无需补交。接收确认不替代后续验收结论。产品取得平台与客户验收所需输入。
F7.2–7.3平台验收所需输入就绪。项目Hub → 产品 → 项目Hub正式成果：平台验收报告或结论，二选一即可；同步更新平台与客户共用的《遗留问题清单》，标明平台来源、责任人、状态和期限。
内容：验收对象与版本、测试或平台结果引用、通过／不通过、问题和限制、产品负责人确认。		平台验收由产品出具报告或明确结论并确认，无需业务确认；项目Hub只登记，不代产品判断。平台通过后登记该分支完成；不通过进入 F7.8–F7.9。
F7.4–7.5客户验收所需资料与客户联络条件就绪，不要求平台已经通过。项目Hub → 产品 → 项目Hub正式成果草案：客户验收通过报告；更新与 F7.3 共用的同一份《遗留问题清单》，标明客户来源，保留平台问题及其处置记录。
内容：客户验收对象、版本、反馈、结果、问题、责任人和期限。		客户验收可以与平台验收并行；客户信息由业务或产品负责人按联络边界取得并回传，不虚构客户 Agent 或客户确认。形成提交业务确认的客户验收材料。
F7.6–7.7客户验收材料与反馈齐备。项目Hub → 业务 → 项目Hub待确认成果：客户验收通过报告及客户相关遗留问题。
确认内容：客户验收通过或退回整改、对应版本、反馈依据和负责人确认。		业务确认仅针对客户验收，不作为平台验收的批准环节；未确认、未完成或退回整改均不计为客户通过。客户通过后登记该分支完成；否则进入 F7.8–F7.9。
F7.8–7.9平台或客户验收未通过、资料缺口或结论需要修订。项目Hub → 实际相关责任角色 → 项目Hub过程记录：验收问题与定向返工记录。
修订内容：受影响的上游成果、整改说明、必要复验结果，以及对应平台／客户验收结论和遗留问题清单。		需要测试时返回阶段 6，由测试独立复验；责任分工按已确认规则协调。完成后回对应验收分支；版本变化影响另一分支时，该分支也需更新确认。未通过的分支保持处理中，不重启整个项目。
F7.10平台验收通过，且客户验收通过。项目Hub登记双线结果门禁依据：产品确认的平台验收报告或结论、业务确认的客户验收通过报告，以及平台与客户共用的同一份《遗留问题清单》。
登记内容：汇总核对 F7.3、F7.5 分别更新的平台／客户问题及来源、状态、责任人与期限；登记两部分结论、验收对象与版本、确认人、未关闭问题的承接人和期限。		总条件为平台通过 + 客户通过；任一未通过、未完成或待确认均不得进入阶段 8。两部分结论应对应一致的验收对象与有效版本，不再追加平台的业务确认。登记双线验收基线，进入阶段 8 资料归档与复盘结项。
-
- -
-
08 / CLOSE

阶段 8：资料归档与复盘结项信息流

项目Hub组织收集各阶段已确认资料，核对验收与遗留问题承接，开展项目复盘并完成结项。本阶段不安排测试或发布验证任务。

-
协调项目Hub组织；实际参与角色提供资料和复盘输入；业务确认结项
核心成果结项资料归档、变更记录、结项报告、流程闭环总结（项目复盘）
门禁双线验收通过、资料归档完整、复盘完成、遗留问题已关闭或落实承接
-
-
项目Hub
F8.1下发资料收集与项目复盘任务只面向实际参与、持有成果或承担遗留事项的角色
实际相关角色
-
实际相关角色
F8.2提交各阶段最终资料与成果索引沿用已确认版本，附变更记录、必要过程记录及资料位置
项目Hub
-
项目Hub
F8.3核对双线验收结果与遗留问题承接平台采用产品确认，客户采用业务确认；遗留问题落实责任人与期限
产品 / 业务
-
项目Hub
F8.4组织项目复盘，收集经验与改进建议围绕目标完成、计划偏差、协作、质量问题和改进措施
实际相关角色
-
实际相关角色
F8.5提交复盘结论与改进项说明经验、问题原因、改进措施、责任人和跟进安排
项目Hub
-
项目Hub
F8.6汇总资料归档、变更记录、复盘总结与结项报告核对资料索引、有效版本、确认记录及遗留事项承接
归档库
-
业务
F8.7确认项目结项或要求补充依据归档完整性、项目复盘和遗留事项承接进行结项确认
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.2阶段 7 平台验收和客户验收均已通过。项目Hub ↔ 实际相关角色收集资料：各阶段正式成果的当前有效版本、必要过程记录、变更记录、项目进度、成果索引和对应确认。
实现资料：已验收的应用层统一固件、被集成的底层版本、硬件设计包及匹配版本关系。		沿用已确认成果，不重新要求制作同内容文件；实际未参与的角色不虚构成果。测试直接交付产品的资料保留文件索引和产品接收确认，项目Hub无需收存或重复转交大文件。形成结项资料清单与缺口清单。
F8.3各阶段资料与验收记录已收集。项目Hub ↔ 产品 / 业务核对内容：产品确认的平台验收报告或结论、业务确认的客户验收通过报告、遗留问题清单。
承接信息：未关闭问题、风险、责任人、期限和后续跟进方式。		只核对已有双线验收结果，不重新给平台增加业务批准；遗留事项必须已关闭或有明确承接。确认结项范围与后续责任。
F8.4–8.5项目事实、阶段成果及主要问题已整理。项目Hub → 实际相关角色 → 项目Hub复盘输入：目标完成情况、计划与实际偏差、协作与质量问题、有效经验和改进建议。
输出：各角色确认的复盘结论与改进项，汇入《流程闭环总结》。		复盘基于已有事实和记录，不把未执行的验证写成已完成；改进项说明责任人和跟进安排。完成项目复盘并形成可跟进的改进项。
F8.6资料收集、验收核对和项目复盘完成。项目Hub → 归档库正式成果：结项资料归档、变更记录、结项报告、流程闭环总结。
汇总内容：最终资料索引、有效版本、阶段确认、验收结论、复盘经验、改进项与遗留责任。		保留历史版本和引用，不以完整聊天记录代替项目档案；选填成果未提供不作为归档阻塞项。形成可追溯的结项包。
F8.7结项包完整且遗留事项已有承接。业务 → 项目Hub确认对象：结项报告、流程闭环总结和结项资料归档完整性。
结项决定：确认结项或补充清单、负责人确认与时间。		待补充的结项必需项未完成时不关闭；确认结项不代表新增测试、发布或生产验证已经执行。确认后锁定四类结项成果，关闭项目并按安排跟进遗留与改进项。
-
- -
-
X / CROSS-CUTTING

贯穿全阶段：变更、阻塞与超时信息流

变更申请 和异常升级不属于某个单一阶段；项目Hub必须暂停受影响任务，组织并行影响评估，再按既定权限确认或批准变更并决定是否重开阶段。授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时由业务批准。其他变更沿用已确认的职责与授权边界。

-
-
-
任意角色
X.1提交变更申请或阻塞记录附原因、证据、受影响版本和紧急度
项目Hub
-
项目Hub
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
项目Hub
-
项目Hub
X.4按授权范围提交综合影响和确认请求授权内资源、排期调整交产品；预算、采购或对外承诺交业务
产品 / 业务
按授权范围接收
-
产品 / 业务
按权限确认或批准
X.5返回确认、批准或拒绝变更的决定产品确认授权内资源与排期；涉及预算、采购或对外承诺须业务批准
项目Hub
-
项目Hub
X.6超时提醒与升级专业事项升级给对应角色；项目级组织授权升级给业务
对应角色
-
-
-
- - - - -
ID触发条件发送 → 接收提交内容（对应正式成果）约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。任意角色 → 项目Hub过程记录：变更申请或阻塞记录。
关联成果：当前基线、受影响成果及版本、任务、原因、证据和紧急程度；批准后写入变更记录。		必须关联当前基线和受影响任务。创建变更或阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。项目Hub ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：角色影响评估。
提交内容：对受影响正式成果逐项给出范围、方案、工期、成本、测试、返工和版本影响，并列出建议修订的成果和版本。		各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全，变更事项与适用授权范围明确。项目Hub ↔ 产品（授权范围内的资源、排期调整）；涉及预算、采购或对外承诺时，项目Hub ↔ 业务过程记录：变更决定记录，注明授权依据、确认或批准角色、负责人及决定时间。
成果影响：综合影响清单、确认／批准／拒绝／延期建议和新基线候选；取得必要确认或批准后更新变更记录、相关正式成果和项目状态内部记录。		授权范围内的资源、排期调整由产品确认，不额外等待业务批准；涉及预算、采购或对外承诺时，须取得业务批准，不以产品确认替代。其他变更沿用已确认职责与授权，不扩大产品权限；技术与质量判断仍由对应专业角色确认。不得隐藏已完成工作损失、成本或里程碑影响。取得必要确认或批准：建立新基线并重开受影响阶段；拒绝或延期：维持原基线。
X.6确认或任务超过约定时间。项目Hub → 对应角色；项目级组织授权事项发给业务过程记录：升级通知。
提交内容：逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。		接收角色在内部完成确认后统一回复。保持等待确认或阻塞。
-
- -
-
Y / ARTIFACT WAIVER

贯穿全阶段：成果文件缺省与豁免信息流

必需成果默认必须输出，选填成果未提供无需豁免。仅主责角色可申请豁免；项目Hub校验并汇总申请，必须由项目负责人（项目Hub对应真人负责人）批准或拒绝，Hub AI 不得自行决定。

-
发起者该成果在流程中的主责角色
审批人项目负责人（项目Hub对应真人负责人）；项目Hub AI 仅登记与执行决定
门禁结果需要成果 → 审查豁免 → 已豁免或仍需成果
-
-
成果主责角色
Y.1提交成果豁免申请说明为何本项目不适用，并附证据和替代信息
项目Hub
-
项目Hub
Y.2校验发起资格与可豁免性非主责角色、无证据或不可豁免成果直接退回
主责角色
-
项目负责人
项目Hub对应真人负责人
Y.3人工确认批准或拒绝成果豁免依据申请、证据、替代方案与影响，记录确认人、时间和条件
项目Hub
登记与门禁更新
-
项目Hub
Y.4A批准：记录已豁免并分发豁免记录仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足
全部受影响角色
-
项目Hub
Y.4B拒绝：仍需该成果返回主责角色生成文件或补充证据
成果主责角色
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 项目Hub成果类型、阶段、原因、事实证据、适用范围、替代成果、下游影响、风险和负责人确认。只有该成果主责角色可发起；“暂时来不及”不属于不适用。进入豁免审查，此时仍需要该成果。
Y.2中心收到豁免申请。项目Hub → 主责角色资格校验、结构校验、补充问题或不可豁免的事实依据。安全、法规和核心验收证据可明确为不可豁免。资料缺口退回补正；最终批准或拒绝仍由项目负责人确认，门禁不提前放行。
Y.3项目Hub已校验并汇总豁免申请、事实证据、替代方案和影响。项目负责人（项目Hub对应真人负责人） → 项目Hub（记录人工决定）成果类型、项目范围、基线引用、批准或拒绝决定、确认人、确认时间、附加条件及失效条件。所有成果豁免必须由项目负责人明确批准或拒绝；沉默、AI 判断或形式校验不算批准。取消独立的下游征询与业务确认环节，不改变不可豁免要求，也不伪造专业或验收结论。批准后登记；拒绝或未确认时仍需该成果。
Y.4A豁免批准。项目Hub → 全部受影响角色已豁免状态、豁免记录、替代成果和附加条件。不能删除原必需项；保留豁免记录。项目范围或输入基线变化时自动失效并重新评估。仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。
Y.4B豁免拒绝或附加条件未满足。项目Hub → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。仍需该成果，阶段继续阻塞。
-
-
-
Codex 多角色项目推进总流程图与阶段信息流图谱 · V0.15 · CURRENT
-
- - - diff --git a/doc/20260908/Codex多角色项目推进总流程图-V1.0.html b/doc/20260908/Codex多角色项目推进总流程图-V1.0.html deleted file mode 100644 index 6747bdc..0000000 --- a/doc/20260908/Codex多角色项目推进总流程图-V1.0.html +++ /dev/null @@ -1,1329 +0,0 @@ - - - - - - - - Codex 多角色项目推进总流程图与信息流图谱｜V1.0 CURRENT - - - -
-
-
CODEX MULTI-ROLE PROJECT FLOW · V1.0 · CURRENT
-

项目推进总流程图

-

业务、项目Hub、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件和测试是当前基线角色，不是封闭列表；项目Hub负责信息路由、成员与状态维护和阶段门禁，新增自定义角色必须先形成职责、成果和决定权契约。

-
V1.0 · 当前定版创建及文档生效：2026-09-08。基于已确认的 V0.16 全文生成，保留八角色、八阶段及跨阶段流程，包含灯态“配网”修正。仅本地文档定版，未推送 Git、部署 Skill 或切换在途项目基线。
-
-
- - - -
-
-
-
VERSION / CHANGELOG
-
-

版本变更记录

-

每个新版本都保留上一版文件，并在当前版本中记录变更内容、影响范围和基线状态。

-
-
- -
- 版本管理规则：从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。评审版本标记为 REVIEW，并记录创建日期和待定的生效日期；只有取得明确的定版确认后，才改为 CURRENT，并同步更新文件名、页面标题、导航、页脚、本表及仓库中的当前流程基线引用。 -
-
- 版本号口径：V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。 -
- -
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
版本日期状态主要变更影响范围
V1.0创建：2026-09-08
文档生效：2026-09-08		CURRENT基于已核对并确认的 V0.16 全文定版，保留角色分工、阶段门禁、测试结果人工确认及跨阶段处理规则；灯态描述使用“配网”。不新增流程或调整职责。版本标识、文档定版及当前文档基线引用；历史 HTML 保留，实际项目迁移与部署另行确认。
V0.16创建：2026-09-07
生效：待定		REVIEW删除缺陷清单中的汇总统计要求；测试结果增加项目负责人（Hub 对应真人负责人）确认，统一无缺陷路径、阶段门禁和验收入口。阶段 6 总览与信息流、通用确认规则、成果矩阵及阶段 7 入口；仅文档评审，未同步 Skill。
V0.15创建：2026-09-04
生效：2026-09-07		保留原版
  1. 精简业务及产品资料与选填项；立项增加平台 SDK、个参资料，项目风险前移阶段 2，删除独立产品资料整合。
  2. 取消独立接口契约、架构决策记录和硬件实现资料；阶段 3 硬件约束选填，明确阶段 5 硬件、底层交付。
  3. 补充工时评估；产品确认授权范围内资源与排期，预算、采购或对外承诺由业务批准。
  4. 精简测试输入，改用缺陷清单并共同商议责任人；可靠性、专项报告及提测佐证选填。
  5. 平台与客户验收可按条件并行且须双通过；平台由产品出具结论、客户由业务确认，测试资料直交产品。
  6. 结项聚焦资料收集与复盘；豁免精简为项目负责人审批，统一编号、成果引用及 Skill、角色提醒。
文档版本管理、阶段 1–8 总流程、成果矩阵、关联信息流、Skill 及八角色 Hook。
V0.142026-09-02HISTORICAL人工可读的正式成果、过程成果、标题、正文和结论统一使用中文，机器字段与枚举只保留在运行时工具参数中；项目Hub通过 Etunel 角色清单读取实际 role、display_name 和 relationship，成员角色不再向负责人追问成员、会话或任务编号；新增同源 JSON 和中文 HTML 两种版本的《项目成员清单》，并补充按阶段整理成果、过程记录、项目进度和成果索引的留档规则。全局成果语言、项目创建、角色登记、Etunel 实际字段、项目文件与进度留档、项目Hub与各成员角色约束和内部培训材料。
V0.132026-08-28HISTORICAL完成八角色跨文件一致性审核；新增项目成员／多账户／自定义角色规则和状态术语词典；区分项目创建时成员登记与阶段 4 角色分工；统一 NA、测试证据包、软硬件接口契约 和业务术语；同步测试主责的缺陷报告闭环；将信息流图谱顺序统一为阶段 3 方案设计后进入阶段 4 项目规划；重新生成项目Hub系统提示词。全局角色与成员管理、状态与成果术语、阶段 1 业务输入、阶段 4 成员／任务分工、阶段 6 缺陷闭环、项目Hub提示词。
V0.122026-08-28HISTORICAL校正 测试计划 的阶段 3 主责；统一 测试计划 和五类阶段 6 正式成果，完善共同最低结构、NA／BLOCKED／成果豁免 边界、缺陷分析报告 主责、平台提测与业务验收边界；把缺陷专业归类和根因责任从项目Hub／测试的越权表述中移回有权角色。阶段 2 可测性评审、阶段 3 测试计划、阶段 5 提测准备、阶段 6 正式测试与缺陷闭环、阶段 7 验收证据、阶段 8 发布冒烟。
V0.112026-08-28HISTORICAL校正硬件角色的阶段 3 设计职责；拆分 硬件设计包 与 硬件实现资料；完善原理图、PCB、Gerber／钻孔、BOM、贴片／生产资料、板卡／批次标识、板级测量和硬件版本链；建立 ECO→底层兼容评估→应用固件确认→技术版本矩阵→测试复验闭环。阶段 3 硬件设计、阶段 5 板卡／样机实现、阶段 6 硬件 ECO 与回归、阶段 7 验收返工、阶段 8 硬件归档。
V0.102026-08-28HISTORICAL校正嵌入式底层的阶段 3 设计职责；完善 嵌入式底层实现资料 最低内容、可消费／修复／归档版演进、板卡／BOM／ECO 与接口契约绑定、专项测试固件限制、应用层重新合版和发布归档边界；扩充流程图底层成果说明。阶段 3 方案设计、阶段 5 底层实现与应用合版、阶段 6 底层缺陷回归、阶段 7 验收返工、阶段 8 底层归档。
V0.92026-08-28HISTORICAL校正嵌入式应用层的阶段 3 设计职责；完善 嵌入式应用层固件包 最低内容、候选／提测／回归／发布版演进、底层重新合版、硬件变化兼容确认和最终固件唯一出口约束；继续清理项目Hub旧称和广播表述。阶段 3 方案设计、阶段 5 实现集成、阶段 6 缺陷回归、阶段 7 验收返工、阶段 8 发布归档。
V0.82026-08-28HISTORICAL新增文档内版本变更记录、版本号口径和历史文件保留规则；从本版本起不再通过重命名覆盖上一版。全局导航、版本管理、项目Hub流程基线引用。
V0.72026-08-28HISTORICAL修正技术负责人在阶段 3 与阶段 4 的责任顺序；明确总体方案、软硬件接口契约和架构决策的主责；明确项目Hub维护版本矩阵、技术负责人确认版本匹配。阶段 3 方案设计、阶段 4 项目规划、阶段 5 集成提测、技术缺陷与变更评估。
V0.62026-08-28HISTORICAL统一产品角色的阶段 2 与阶段 7 正式成果；补齐产品发起早期风险预检、产品定义评审和验收闭环；客户平台资料改为参考输入基线。阶段 1 早期预检、阶段 2 产品定义、阶段 7 业务验收。
V0.5未登记HISTORICAL BASELINE建立八阶段主流程、项目Hub中枢角色、角色化状态同步 S.1–S.4、异常协同 E.1–E.4、变更升级 X.1–X.6 和成果豁免 Y.1–Y.7；形成正式成果追踪矩阵。总流程、项目Hub、全局信息流、门禁和成果追踪。
-
-
- -
-
-
-

从业务需求到复盘结项

-

主线按成果和确认门推进；测试失败、业务验收驳回和需求变更通过回路返回正确阶段，不需要从头重启项目。

-
-
- 白色卡片＝项目阶段 - 黄色门＝角色/阶段确认 - 红色虚线＝返工回路 -
-
- -
-
-
01
-

业务需求

主责：业务
-
明确目标与价值。补齐业务对象、业务目标、范围。
-
正式成果项目背景说明
客户信息：对接客户名称、最终客户名称
项目名称：统一名称或客户规定的项目代号
产品要求：产品形态、提测平台
项目来源：新客户、新项目、旧产品升级、竞品替换或成本优化
需求背景：客户为什么提出这个需求，要解决什么问题
业务目标：本项目希望实现的业务结果
预期价值（选填）：可验证的价值假设
订单、预计销售额等信息均为选填，仅在项目适用时补充客户里程碑要求
提测时间
入库时间
小批量试产时间（选填）
量产时间（选填）
-
-
产品与业务确认需求基线
- -
-
02
-

产品定义

主责：产品 · 批准：业务
-
把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。
-
正式成果立项资料
立项书：包含项目目标、项目基础信息、初步里程碑要求、项目干系人、版本说明等信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能项
灯态：描述设备上电、配网、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
平台 SDK
个参资料
结构板框图（选填）：包含主要器件位置和禁止限制区域测试验收标准
平台测试用例
客户验收测试用例和验收标准里程碑要求
提测时间
客户验收时间
试产、量产时间（选填）项目风险
技术风险
时间风险
其他风险
-
-
产品确认方案，业务批准范围
- -
-
03
-

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试
-
基于产品定义和阶段 2 已有评审结论形成可实施方案。
技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件（选填）：器件、PCB、电源/信号/热及接口约束测试：测试标准、测试用例范围、测试项
-
正式成果总体技术方案（选填）测试计划
测试标准、测试用例范围、测试项
-
-
技术负责人确认整体方案与测试计划，嵌入式应用层/嵌入式底层确认接口可实施，硬件约束选填，产品确认不偏离，测试确认可验证
- -
-
04
-

项目规划

主责：项目Hub
-
基于已确认的产品基线和方案设计成果，生成实际任务、人员分工和排期，引用阶段 2 项目风险。任务计划草案先由技术负责人确认；项目Hub只对存在疑点的任务定向询问对应执行角色，资源与排期基线再提交产品确认；确认后的计划与排期可由项目Hub同步给业务。
-
正式成果项目计划
项目任务拆分（工时评估）
实际项目排期角色分工
Etunel 实际 role 与 display_name
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
每项任务只有一个主责角色项目状态内部记录
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化
-
-
技术负责人确认任务计划，问题任务由对应执行角色定向确认，产品确认实际人员、资源与排期基线
- -
-
05
-

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件
-
嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。硬件先取得并核对器件规格书和结构板框图，形成并确认硬件设计包后，再据此推进硬件实现；嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口、任务或器件约束发生重大偏离时返回技术负责人和项目Hub确认。
-
正式成果硬件设计包
原理图
PCB 源文档
贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）
接口定义嵌入式底层实现资料
硬件功能测试报告
BSP 输出路径
PSP 输出路径
WiFi 设备定频测试固件（选填）嵌入式应用层固件包
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
zn_debug文件
Changelog
串口使能证书
-
-
嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配
- -
-
06
-

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件
-
执行功能、接口、软硬件集成和回归测试。
不通过测试与相关负责人共同商议缺陷责任人；项目Hub按确认分工安排修复，测试独立复验
提交完成条件测试形成成果与质量结论后，由项目Hub请求项目负责人（Hub 对应真人负责人）确认；人工确认后才算完成提交
-
正式成果功能测试报告
测试结论：通过/不通过
测试用例执行结果
bug: log日志可靠性测试报告（选填）
高低温测试
跌落测试（选填）
防水测试（选填）专项测试报告（选填）
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项提测佐证（选填）
平台要求的视频、截图、log材料缺陷清单
bug条目、状态、模块、责任人
-
-
测试完成专业确认，项目Hub取得项目负责人对测试结果的人工确认后完成提交；质量条件同时满足才放行
- -
-
07
-

平台/客户验收

产品组织 · 平台：产品确认 · 客户：业务确认
-
平台验收在前，客户验收在后；输入就绪时可并行。产品确认收到测试直接交付的报告及已提供的提测佐证。
未通过按平台或客户问题定向整改，回到对应分支重新验收。
总条件平台通过（产品确认）+ 客户通过（业务确认），两项均通过后进入复盘结项。
-
正式成果平台验收报告或结论
产品出具并确认，无需业务确认客户验收通过报告
业务确认客户验收结果遗留问题清单
平台与客户共用一份，标明问题来源
-
-
平台验收通过（产品确认） + 客户验收通过（业务确认）
- -
-
08
-

复盘结项

项目Hub组织 · 相关角色提供资料与复盘输入 · 业务确认结项
-
收集项目资料，开展项目复盘并完成结项。项目Hub整理各阶段已确认成果、必要过程记录、项目进度和成果索引，核对双线验收与遗留问题承接，汇总经验及改进项。
-
正式成果结项资料归档
形成最终结果的流程文件变更记录结项报告流程闭环总结
项目复盘经验与改进项
-
-
- -
- 贯穿全流程：变更申请（需求变更申请） -

任何角色都可提出变更；项目Hub组织影响评估，产品评估范围，技术负责人评估总体方案，嵌入式应用层、嵌入式底层和硬件分别评估实现与工作量，测试评估验证成本，变更按既定权限确认或批准，其中授权范围内的资源、排期调整由产品确认，涉及预算、采购或对外承诺时由业务批准；完成必要确认后更新对应基线，并从受影响阶段继续推进。

-
-
- 成果适用性：成果豁免（成果文件豁免） -

正式任务的阶段成果默认由主责角色输出；确认不适用时，由主责角色说明原因、影响和替代证据，由项目 Hub 对应真人负责人批准或拒绝，项目Hub记录人工决定；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。验证期确需跳过时，记录缺失项、风险和后续补齐安排，不把跳过写成成果已完成。

-
-
- -
-
-
STAGE INFORMATION FLOW ATLAS · V1.0 · CURRENT
-

各阶段角色信息流图谱

-

以下内容直接承接总流程图，展示每条会影响成果、决策、门禁、返工或版本的正式信息流，并说明触发条件、发送方、接收方、载荷、确认要求和阻塞约束。

-
- 通用规则成果追踪矩阵01 业务需求02 产品定义03 方案设计04 项目规划05 软硬件实现06 测试验证07 平台/客户验收08 复盘结项变更与异常成果豁免 -
-
绿色：正式成果、候选成果或正式基线黄色：过程记录、关联成果或修订对象
-
-
-
-
00 / RULES
-

所有阶段共同遵守的流转规则

成员 Agent 的跨角色任务、问题和结论仍经项目Hub定向中继、校验和登记。阶段 7 测试资料由测试负责人直接交付产品负责人，产品向项目Hub确认接收，文件不由项目Hub转发。

-
-
正式任务流转路径：触发事件 → 主责角色与本角色真人负责人对齐 → 完成指定文件、专业自审与负责人确认 → 向项目Hub提交成果及确认信息 → 项目Hub检查文件或已约定的交付索引、版本、证据、确认、依赖和冲突 → 定向路由目标角色 → 目标角色完成任务后返回项目Hub → 项目Hub留档并安排下游。信息流图默认使用正式角色名称；阶段 6 测试结果提交确认与成果豁免审批显式列出项目负责人（Hub 对应真人负责人）的人工决定，不新增 Agent 角色。阶段 7 文件直接交付与接收确认按该阶段约定执行，不要求大文件经过项目Hub传输。
-
正式任务默认要求主责角色输出约定成果；确认不适用时记录原因、影响和替代证据。验证期可由负责人决定跳转、回退或暂缓，但必须保留缺失项、风险和补齐安排，不能把跳过写成已通过，也不能静默删除已有文件。
-
- 项目Hub业务产品技术负责人嵌入式应用层嵌入式底层硬件测试 -
-
- - - -
主体是否为项目职能角色定义主要确认权限不能做什么
各专业角色是图中的正式角色名称统一代表该角色完成 AI 辅助自审与人工确认后的责任主体；内部审查过程不作为跨角色信息流单列。以角色名义确认并发出本角色专业结论、正式成果、现实工期承诺、风险接受和正式交付；阶段 4 的资源与排期基线及后续授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时须由业务批准。不能替其他角色作出专业确认。
业务是；同时承担项目级组织授权业务节点同时包含业务专业判断和项目级组织授权的内部确认。除业务成果外，负责确认预算、采购/打样、对外承诺日期、暂停/取消，以及客户验收和项目结项；阶段 4 的计划与排期可由项目Hub同步知会业务，平台验收由产品确认而不经业务批准。不替代产品、技术负责人、硬件或测试等角色给出专业结论。
项目Hub是项目Hub运行中心 AI，是项目唯一正式信息中心、任务路由器、成果校验器、阶段门禁执行者和项目状态内部记录维护者。可依据证据更新项目状态、按角色需要分发状态快照、完成普通项目级审查和豁免登记；所有成果豁免均须项目负责人（项目Hub对应真人负责人）批准或拒绝。测试结果由 Hub 请求同一真人负责人确认，人工确认后才算完成提交；Hub AI 不代签、不改写测试专业结论。不能自行承诺真实资源、预算、范围、日期或专业结论，也不能以推测代替角色提供的状态证据。
-
角色与成员配置：图中的八个角色是当前默认基线，不是永久封闭的角色集合。新增自定义角色前先定义目标、职责边界、参与阶段、正式成果、上下游依赖和确认权限，再由 Hub 真人负责人在 Etunel 中手动添加。项目Hub使用 etunel_list_roles 读取实际 role、display_name 和 relationship；各角色会话不向负责人重复确认成员 ID、会话 ID 或其他未由工具提供的字段。阶段 4 再通过《角色分工》将实际任务主责和交接关系正式基线化。
-
项目成员清单：项目创建完成后、首个正式任务派发前，项目Hub从同一次 etunel_list_roles 结果生成 JSON 版和全中文 HTML 版《项目成员清单》。两份清单只记录项目名称、版本、导出时间及工具实际返回的 role、display_name、relationship，不虚构成员、会话或人员编号。角色变化后生成新版本，不覆盖历史版本；该清单不替代阶段 4 的《角色分工》。
-
任务与状态规则：每项任务只有一个主责角色；依赖已经满足的多项任务可以形成任务波次，同一角色的内聚工作可以组成一个任务包。项目模式、任务结果、成果状态、阶段门禁、测试结论和业务验收含义不同，不得相互替代。对负责人使用“通过、失败、阻塞、不适用、延期”等自然中文；机器枚举只在工具字段明确要求时使用。
-
项目文件与进度留档：项目Hub按 项目资料/00-项目管理 和八个阶段目录整理资料，维护《项目概览》《项目进度》《成果索引》及必要的《阶段记录》。正式成果放入对应阶段的角色目录，重要草稿、退回原因、决定和阻塞放入过程记录；正式文件不覆盖，回退不删除历史。阶段交接和钉钉里程碑通知前先完成留档，但目录排版本身不是新的专业门禁。阶段 7 直接交付的测试资料以文件索引和产品接收确认为留档依据，项目Hub无需复制大文件。
-
-
任意角色
G.1提交已完成内部审查确认的消息、成果或请求说明完成情况、负责人确认、成果路径、版本、证据和待处理事项
项目Hub
-
项目Hub
G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量
目标角色
-
目标角色
G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录
项目Hub
-
-
项目进度与按需同步：项目Hub持续维护 项目资料/00-项目管理/项目进度.md，并在对应阶段的《阶段记录》中追加重要事件。创建项目、启动任务波次、接收正式成果、重要退回、阻塞与解除、决定与变更、阶段切换／跳转／回退／暂缓和结项时更新；普通消息、队列状态和空确认不逐条留档。关键变化只向实际受影响角色推送，也响应角色按阶段或任务发起的查询。
-
-
任意角色
S.1 · 按需查询请求与本角色职责相关的最新项目状态说清关注阶段或任务、需要的信息和用途
项目Hub
-
项目Hub
S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回
请求角色及受影响角色
-
接收角色
S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态
项目Hub
-
项目Hub
S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间
全部受影响角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对项目执行的影响
S.1角色需要了解当前阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。任意角色 → 项目Hub查询范围、关注事项、所需详细度、期望时点和用途。只能查询项目授权范围内的信息；请求角色无需知道项目的内部存储结构。创建一次按需状态查询。
S.2收到 S.1；或阶段／门禁、任务分派、依赖、阻塞、风险、决策、成果基线或期限发生关键变化。项目Hub → 请求角色及受影响角色项目状态快照：当前阶段与门禁、相关任务、依赖、阻塞、风险、决定、成果引用、下一步、期限和证据。按最小必要原则裁剪为角色化上下文；禁止转发无关角色的完整会话或未确认专业判断；所有状态必须有证据来源。角色获得可执行的最新上下文。
S.3角色收到状态快照。接收角色 → 项目Hub确认可以继续；或说明需要纠正的内容、正确值、原因、证据和负责人确认。没有证据的异议不得直接覆盖状态；存在争议时进入 E.1–E.4。确认可继续执行，或触发状态纠正。
S.4纠正请求通过版本、证据及跨角色一致性检查。项目Hub → 全部受影响角色变更内容、旧值与新值、原因、证据、生效时间及受影响任务。保留状态历史，不覆盖旧版本；改变正式基线时必须转入变更申请。相关角色切换到新的有效状态快照。
-
异常协同补充机制：条件流、阻塞流、跨角色冲突或无法按时收敛的问题进入 E.1–E.4。项目Hub分别提醒实际相关角色并提供完整问题包；问题复杂时建议各角色真人负责人线下沟通。讨论结果由当前主责角色的负责人带回本角色会话，完成本角色任务后再提交项目Hub；角色 Agent 之间仍不直接通信。
-
-
项目Hub
E.1 · 异常触发主动提醒当前主责角色及全部关联角色发送问题、证据、冲突点、影响范围、原流程位置和响应时限
当前主责角色及关联角色
-
项目Hub
E.2 · 复杂问题建议由当前主责角色组织线下会议提供建议参会角色、议题、待决策项、证据包和结论模板
当前主责角色及关联角色
-
当前主责角色
E.3提交参与角色统一确认的会议结论包含结论、分歧处理、变更项、责任角色、期限、版本和确认状态
项目Hub
-
项目Hub
E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果
原流程及关联角色
-
-
- - - - -
ID触发条件发送 → 接收正式载荷约束/确认对原流程的影响
E.1条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。项目Hub → 当前主责角色及实际关联角色问题摘要、证据与版本引用、冲突点、影响范围、所需角色和期望处理时间。项目Hub必须主动提醒，不得只更新状态；各角色依据正式问题包分别确认。原流程保持阻塞，等待问题关闭。
E.2涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。项目Hub → 当前主责角色及关联角色建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。项目Hub只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。会议结论回传前，不恢复原流程。
E.3线下讨论完成并形成统一结论。当前主责角色 → 项目Hub会议决定记录：参与角色、统一结论、保留分歧、变更项、责任角色、期限、成果版本、证据和负责人确认。禁止只上传录音、聊天记录或未经参与角色确认的纪要；仍有分歧时继续保持阻塞并明确升级项。形成可登记的异常处置结论。
E.4统一结论通过项目Hub的形式、版本、证据和跨角色一致性检查。项目Hub → 原流程及关联角色登记结果、受影响成果或任务、恢复点、后续动作和新时限。项目Hub不改写专业结论；若结论改变正式基线，必须转入变更申请。从原来被阻塞的位置恢复当前流程。
-
- - - - - - - - - - - - - -
通用约束执行要求不满足时
Etunel 消息Hub 使用工具实际提供的 role、kind、text、可选附件路径和关联字段；需要完成、阻塞或结算时，只从入站消息读取真实 message_id。机器字段不抄进给负责人的正文。字段不符合当前工具 schema 时停止调用并说明能力缺口，不得发明参数。
成果版本必须写清成果名称、当前版本、状态、替代关系和证据引用。作为草稿退回，并说明缺少内容。
成果责任原则上由流程图指定的主责角色创建、更新并提交对应成果。其他角色不能代签；项目Hub返回主责角色。
角色内部审查每个角色必须完成专业自查并取得当前真人负责人确认；跨角色流转时统一以正式角色名称表示。没有自查或负责人确认的成果不能作为正式成果提交项目Hub。
测试结果提交确认测试完成专业自审与测试负责人确认后，向 Hub 提交待确认结果；Hub 核对后请求项目负责人（Hub 对应真人负责人）人工确认，登记结论、确认人、时间及对应成果版本，才算完成提交。草案与缺陷记录可用于协调修复，不等于正式提交完成；大文件仍以可访问索引关联，不要求 Hub 收转。已收到、已读、沉默或 Hub AI 判断均不算人工确认；退回则由测试按意见补充或进入必要修复、复验，结果版本变化后重新确认。确认提交不代替测试通过或后续验收结论。
专业发起权专业活动由对应主责角色判断并发起；项目Hub只负责格式校验、任务路由、状态跟踪和结果登记。项目Hub不得越权替角色发起专业决策。
项目Hub审查边界仅做必填结构、文件、版本、证据、负责人确认，以及多个角色正式信息之间的重复、冲突和依赖一致性检查。不得替业务、产品、技术负责人、嵌入式应用层、嵌入式底层、硬件或测试判断本专业内容是否充分。
成果豁免仅主责角色可提出不适用申请；由项目 Hub 对应真人负责人批准或拒绝，项目Hub记录人工决定；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。未批准时仍需要该成果；验证期跳转则记录缺失、风险和补齐安排。
角色确认专业结论由对应角色内部形成并确认；阶段 4 的资源与排期由产品确认，预算、采购及对外承诺等项目级组织授权仍由业务内部完成。阶段 6 的测试结果还须由 Hub 请求项目负责人（Hub 对应真人负责人）确认，不能以测试内部确认替代。未完成负责人确认时不得作为正式结果发出。
项目状态同步项目Hub维护有版本和证据的项目状态内部记录，并在关键变化时主动向受影响角色推送，或按 S.1–S.4 响应角色查询与纠正。状态来源、版本或时点不明时不得作为任务执行依据。
异常协同项目对异常主动提醒关联角色；复杂问题建议当前主责角色组织线下会议，统一确认后提交结构化结论。未按 E.1–E.4 闭环，不得恢复原流程或推进门禁。
跨角色沟通成员 Agent 之间不直接通信；任务、问题、最终结论、约束和影响都通过项目Hub定向中继。阶段 7 测试报告及已提供的提测佐证可由测试负责人直接交付产品负责人，接收确认回传项目Hub登记。未经确认或未登记的信息不能作为正式下游输入；已按阶段 7 确认接收的文件不要求项目Hub重新转交。
门禁正常顺序推进时，只有必需成果完整、版本正确、证据可访问、确认齐全才能通过；阶段 6 须取得项目负责人对测试结果的人工确认，未确认或退回时不得登记提交完成或进入正式验收；阶段 7 直接交付的测试资料以产品确认收到为交接依据，不要求项目Hub接收大文件。跳转、回退或暂缓按负责人决定另行记录。未满足且没有明确跳转决定时，阶段保持阻塞；接收确认不等于验收通过。
-
- -
-
00B / ARTIFACT TRACEABILITY

正式成果—信息流追踪矩阵

流程图规划的每项正式成果都必须能够追踪到首次形成、评审或修订、正式确认以及下游分发。表中流程 ID 与各阶段信息流图和说明表一一对应。

-
判定原则：正式成果必须由指定主责角色输出；过程记录只能解释校验、评审、冲突、变更和确认，不得替代正式成果。阶段 3 的总体技术方案，以及阶段 6 的可靠性测试报告、专项测试报告和提测佐证为选填成果，未提交不阻塞推进，也无需另行豁免；已提交时仍须完成版本登记和相应确认。若其他必需成果获准豁免，则以下对应流转中的成果引用改为豁免记录和替代证据。
-
- - - - - - - - - - - - - - - - - - - - - - - - - - -
阶段正式成果主责角色首次形成/提交评审、修订与确认正式分发/下游使用
1 业务需求项目背景说明业务F1.1F1.2 条件修订；F1.4 产品与业务确认F1.3 评审分发；F1.5 正式基线给产品
1 业务需求客户里程碑要求业务F1.1F1.2 条件修订；F1.4 产品与业务确认F1.3 评审分发；F1.5 正式基线给产品
2 产品定义立项资料产品F2.2F2.3–F2.6 专业评审与修订；F2.7–F2.8 业务批准F3.1 方案设计输入；F4.1 项目规划输入
2 产品定义测试验收标准产品F2.2F2.3–F2.6 测试评审；F2.7–F2.8 业务批准F3.3 测试计划任务输入；F3.7 提交计划；F6.1 测试输入；F7.1 验收输入
2 产品定义里程碑要求产品F2.2F2.3–F2.6 专业评审；F2.7–F2.8 业务批准F4.1 项目计划 输入；S.2 状态同步
2 产品定义项目风险产品汇总；相关专业角色提供意见F2.2F2.3–F2.6 评估与修订；F2.7–F2.8 确认范围与风险F3.1/F4.1/F5.1 引用当前有效风险；后续风险意见经项目Hub交产品维护
3 方案设计总体技术方案（选填）技术负责人F3.2（提供时）F3.4–F3.8 修订；F3.9–F3.10 确认F4.1 项目规划输入；F5.1 实现输入；F8.2 收集、F8.6 归档
3 方案设计测试计划测试F3.7
提交测试标准、测试用例范围和测试项		F3.7 有缺口时经项目Hub转相关角色确认；F3.8 汇总；F3.9 技术负责人确认测试计划；F3.10 相关角色最终确认F4.1 测试任务规划输入；F6.1 测试任务输入
4 项目规划项目计划项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 定向修订；F4.6–F4.7 产品确认资源与排期F4.8 分发相关执行角色，可同步业务；F5.1 实现任务输入；后续由 X.4–X.5 按权限确认变更
4 项目规划角色分工项目HubF4.1F4.2 技术负责人确认；F4.3–F4.5 问题任务修订F4.8 随正式任务分发；F5.1 实现责任输入
4 项目规划项目状态内部记录项目HubF4.1 初始执行记录S.3–S.4 证据化纠正；E/X 流程更新F4.8 初始执行快照；S.2 自动或按需分发
5 软硬件实现硬件设计包硬件F5.2（所需输入资料齐备后）F5.2 硬件负责人确认；F5.3 技术负责人及受影响角色确认；F5.7 冲突修订；F5.8–F5.10 版本匹配确认F5.2 硬件实现依据；F5.3 定向分发；F8.2 收集、F8.6 归档
5 软硬件实现嵌入式底层实现资料嵌入式底层F5.4（WiFi 设备定频测试固件选填）F5.5 BSP/PSP 交嵌入式应用层合版；F5.7/F5.10 确认版本关系BSP/PSP 通过 F5.6 集成进统一固件；F8.2 提交归档资料
5 软硬件实现嵌入式应用层固件包嵌入式应用层F5.6 候选；F5.9 最终提测版F5.7 冲突修订；F5.8–F5.10 技术负责人确认F6.1 交测试；F6.8 回归版；F8.2 归档已验收版本
6 测试验证功能测试报告测试F6.2F6.3–F6.9 缺陷/回归更新；F6.10 提交待确认结果；F6.11–F6.12 项目负责人确认F7.1 测试直接交付产品并确认接收；F8.2/F8.6 归档索引
6 测试验证可靠性测试报告（选填）测试F6.2（提供时）已提供时按 F6.3–F6.9 更新缺陷/回归；F6.10 提交待确认结果；F6.11–F6.12 项目负责人确认已提供时由测试直接交付产品，F7.1 确认接收；F8.2/F8.6 归档索引
6 测试验证专项测试报告（选填）测试F6.2（提供时）已提供时按 F6.3–F6.9 更新缺陷/回归；F6.10 提交待确认结果；F6.11–F6.12 项目负责人确认已提供时由测试直接交付产品，F7.1 确认接收；F8.2/F8.6 归档索引
6 测试验证提测佐证（选填）测试F6.2 登记索引（提供时）已提供时按 F6.3–F6.9 补充；F6.10 提交待确认版本与索引；F6.11–F6.12 项目负责人确认F7.1 测试直接交付、产品确认接收；F7.2/F7.4 按需用于验收；F8.2/F8.6 归档索引
6 测试验证缺陷清单测试F6.2/F6.3F6.3 相关负责人共同确定责任人；F6.4–F6.9 修复与测试回归；F6.10 提交待确认结果；F6.11–F6.12 项目负责人确认F7.1 验收限制输入；F8.2 收集、F8.6 归档
7 平台/客户验收平台验收报告或结论产品F7.3（二选一即可）产品确认；F7.8–F7.9 返工后重新确认；无需业务确认F7.10 双线门禁；F8.2 收集、F8.3 结项核对
7 平台/客户验收客户验收通过报告产品F7.5 草案F7.6–F7.7 业务确认客户结果；F7.8–F7.9 返工后重新确认F7.10 双线门禁；F8.2 收集、F8.3 结项核对
7 平台/客户验收遗留问题清单产品F7.3、F7.5 分别更新同一份清单，标明平台／客户来源F7.8–F7.9 更新处置结果、责任人与期限；F7.10 汇总核对双方问题F8.3 关闭或确认承接；写入结项报告
8 复盘结项结项资料归档项目HubF8.2 收集；F8.6 汇总F8.3 核对；F8.7 完整性与结项确认项目关闭后锁定归档
8 复盘结项变更记录项目HubX.1–X.5 持续记录；F8.6 汇总每次变更决定更新；F8.7 结项检查随结项资料归档锁定
8 复盘结项结项报告项目HubF8.6F8.2–F8.5 提供输入；F8.7 业务确认结项项目关闭依据与归档入口
8 复盘结项流程闭环总结项目HubF8.4–F8.5 复盘输入；F8.6 汇总F8.7 结项确认项目经验、改进项跟进与后续复用
-
- -
-
01 / BUSINESS

阶段 1：业务需求信息流

把客户背景、业务目标和关键里程碑转换成经产品与业务确认的需求基线。

-
主责业务
核心成果项目背景说明、客户里程碑要求
门禁产品与业务确认同一需求基线后进入产品定义
-
业务完成原始信息收集、成果自查和负责人确认后，以统一的“业务”主体提交成果。项目Hub完成文件、版本、证据和跨角色冲突检查后，在 F1.3 将业务成果评审版本路由给产品。产品与业务通过项目Hub澄清待确认项，并分别完成本角色负责人确认，确认同一需求基线。双方确认后，项目Hub登记留档并向产品分发正式业务基线，即可开启产品定义。
-
-
业务
F1.1提交完成内部审查的项目背景与客户里程碑要求草案附负责人确认、来源引用和实际成果文件
项目Hub
-
项目Hub
F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限文件结构、版本、证据和已登记信息冲突；无异常则不启用此流
业务
-
项目Hub
F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项
产品
-
产品 / 业务
F1.4产品与业务确认需求基线经项目Hub中转，双方分别确认同一版本
项目Hub
-
项目Hub
F1.5向产品分发正式业务基线并开启产品定义双方确认后留档，分发当前有效版本即可进入阶段 2
产品
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F1.1收到新的客户需求或业务机会，且业务已完成原始信息收集、自查和负责人确认。业务 → 项目Hub正式成果草案：项目背景说明、客户里程碑要求。
附带内容：负责人确认、来源引用、成果版本和实际文件。		项目Hub不重复判断业务内容质量，只检查形式和跨来源一致性。进入中心登记。
F1.2（条件流）仅当文件结构、版本、证据不合规，或与已登记正式信息发生冲突时触发；不存在上述问题时跳过。项目Hub → 业务过程记录：形式校验问题清单或冲突清单。
关联成果：受影响的项目背景说明／客户里程碑要求及其字段、版本、冲突来源和修正要求。		项目Hub不能生成业务缺失项或替业务补写事实；无错误或冲突时不得发起此流。触发后，错误或冲突关闭前阻塞登记；未触发则直接进入 F1.3。
F1.3业务成果通过项目Hub的文件、版本、证据和跨角色冲突检查并完成登记。项目Hub → 产品评审分发成果：待评审的项目背景说明、客户里程碑要求。
附带内容：成果版本、状态、证据、待确认项和回复时限。		标明待评审状态；经产品与业务确认并留档后，才可作为阶段 2 输入。产品与业务通过项目Hub进入 F1.4 需求基线确认。
F1.4F1.3 已分发评审版本，业务内部审查和中心形式校验已完成。产品 ↔ 项目Hub ↔ 业务确认成果：经产品与业务各自负责人确认的项目背景说明、客户里程碑要求。
附带内容：确认状态、确认时间、确认条件和版本。		待确认项经项目Hub中转澄清；记录双方各自负责人确认状态、时间和版本，双方须确认同一版本。双方确认后通过门禁，进入 F1.5 并开启产品定义。
F1.5产品与业务确认同一需求基线，项目Hub已登记并留档正式版本且阶段门禁通过。项目Hub → 产品正式基线：项目背景说明、客户里程碑要求的当前有效版本。
附带内容：成果版本、基线与证据引用、阶段 2 任务和确认时限。		只允许分发已经确认并留档的当前有效版本；分发事件和接收状态必须登记，草稿或过期版本不得作为产品定义输入。产品接收后开启阶段 2。
-
- -
-
02 / PRODUCT

阶段 2：产品定义信息流

产品形成立项资料、测试验收标准、里程碑要求及项目风险。技术负责人、嵌入式应用层、嵌入式底层、硬件和测试按指定范围提供专业可行性与风险意见，由产品汇总技术风险、时间风险及其他风险。

-
主责产品；业务批准范围
核心成果立项资料、测试验收标准、里程碑要求、项目风险
门禁产品确认方案，业务批准范围，约束和测试标准完整
-
-
项目Hub
F2.1下发产品定义任务附产品与业务已确认的阶段 1 基线及已知约束
产品
-
产品
F2.2提交立项资料草案与专业评审请求产品明确评审角色、问题、范围和期望输出
项目Hub
-
项目Hub
F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题
技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评审角色
F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段
项目Hub
-
项目Hub
F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突，不替产品作内容决定
产品
-
产品
F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险
项目Hub
-
项目Hub
F2.7请求业务批准范围呈现范围、里程碑、成本/风险影响
业务
-
业务
F2.8批准、驳回或附条件批准附条件项必须有责任人与期限
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F2.1–2.2阶段 2 启动。项目Hub ↔ 产品输入基线：项目背景说明、客户里程碑要求。
产品提交的正式成果草案：立项资料（含平台 SDK、个参资料）、测试验收标准、里程碑要求、项目风险。
参考输入（非阶段成果）：项目已有的器件规格、板框约束、串号表、平台对接文档和开发规范。		产品先自审，所有资料必须引用阶段 1 基线；专业评审由产品发起。进入专业评审路由。
F2.3产品提交可评审草案和评审请求。项目Hub → 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试评审分发成果：按角色裁剪上述四类产品定义成果草案。
参考输入：只附与评审问题相关的现有器件、板框和平台资料；另含成果版本、基线引用、评审范围、问题和时限。		项目Hub只校验和路由；技术负责人看总体，嵌入式应用层看功能，嵌入式底层看 BSP/HAL，硬件看器件/板框，测试看可测性。并行评审。
F2.4各角色完成评审。技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试 → 项目Hub过程记录：角色评审结果（角色评审结论）。
关联成果：四类产品定义成果的具体字段；提交结论、缺失、风险、证据、建议和是否阻塞。		不得只回复“可行/不可行”。形成冲突矩阵。
F2.5–2.6存在冲突或缺口。项目Hub ↔ 产品修订成果：受影响的 立项资料、测试验收标准、里程碑要求、项目风险 新版本。
附带内容：字段级修订清单、变更影响和关闭说明。		产品在内部确认最终版本后统一发出。问题未关闭则暂缓推进。
F2.7–2.8产品方案专业评审完成。项目Hub ↔ 业务批准成果包：四类产品定义成果的负责人确认候选版本。
附带内容：范围、验收、里程碑、风险、附条件事项、版本和确认状态。		范围批准由业务完成内部授权后统一给出。批准并留档后作为正式基线进入阶段 3。
-
- -
-
03 / DESIGN

阶段 3：方案设计信息流

技术负责人依据产品定义基线，结合阶段 2 已有评审结论组织总体方案；产品、嵌入式应用层、嵌入式底层、硬件和测试依据同一产品基线，对方案和接口约束完成多轮确认。测试提交测试计划，无问题时由项目Hub汇总给技术负责人确认；有不可测试项或环境、治具缺口时，先经项目Hub转交相关角色确认，由测试修订计划后再汇总确认。

-
主责技术负责人组织方案与接口确认，主责选填的总体技术方案，并确认测试计划；硬件接口与约束为选填；测试主责测试计划
核心成果测试计划；总体技术方案为选填
门禁方案确认、接口可实施、需求不偏离、测试可验证，测试计划经技术负责人确认
-
总体技术方案为选填，未提供不阻塞阶段推进，也无需另行豁免；必要的技术决定及接口约束仍须写入角色确认记录。硬件的器件、PCB、电源/信号/热及接口约束在本阶段为选填，未提供不阻塞，也无需豁免；已提供时完成对应确认。阶段 5 的硬件前置输入和设计包交付要求不变。
-
-
项目Hub
F3.1下发总体方案设计任务附产品定义基线、阶段 2 已有评审记录和现有技术参考资料
技术负责人
-
技术负责人
F3.2提交设计要点与待确认接口约束含边界、关键决策、非功能和风险；附已提供的总体技术方案
项目Hub
-
项目Hub
F3.3并行分发角色化设计任务各角色依据同一产品基线和已分发的接口约束开展工作
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
嵌入式应用层
F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发
项目Hub → 嵌入式底层 / 技术负责人
-
嵌入式底层
F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时
项目Hub → 硬件 / 技术负责人
-
硬件
F3.6反馈硬件约束（选填）器件、PCB、电源、信号、空间、热及接口约束，提供时说明实际影响
项目Hub → 技术负责人 / 嵌入式底层 / 产品
-
测试
F3.7提交测试计划，说明是否存在可测性缺口无问题：项目Hub汇总给技术负责人确认
有不可测试项或环境、治具缺口：项目Hub转交相关角色确认
项目Hub
-
项目Hub
F3.8汇总测试计划与设计反馈，请求确认无问题时直接提交；有缺口时先取得相关角色确认，由测试修订计划后再汇总
技术负责人
-
技术负责人
F3.9返回方案、接口及测试计划确认结果确认与整体方案、接口及实施依赖一致；附已提供的选填成果
项目Hub
-
项目Hub
F3.10请求各角色确认接口可实施、测试可验证嵌入式应用层、嵌入式底层、产品、测试分别确认；硬件选填内容已提供时确认
产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F3.1–3.3阶段 2 门禁通过，产品定义基线有效。项目Hub ↔ 技术负责人/协作角色按主责角色分别形成的正式成果草案：技术负责人按需提供总体技术方案。测试按任务编制 测试计划，包含测试标准、测试用例范围、测试项，并在 F3.7 提交。
过程记录：技术负责人提交设计要点与待确认接口约束，各相关角色完成接口与约束确认。
输入内容：阶段2四类产品成果、现有技术参考资料、阶段 2 已有的可行性与风险评审记录（如有）、设计范围和时限。		方案设计不得依赖尚未形成的 项目计划；所有设计必须引用同一产品基线。开启并行方案设计。
F3.4嵌入式应用层需要新的资源、HAL 或协议。嵌入式应用层 → 项目Hub → 嵌入式底层 / 技术负责人过程记录：接口需求及确认结果。
关联或修订成果：已提供的总体技术方案。
提交内容：接口需求、调用频率、性能、资源指标、理由和受影响功能。		接口调整经项目Hub转交相关角色确认，不得私下约定。更新接口确认结果；改变正式基线时走变更申请。
F3.5嵌入式底层依赖引脚、电平、器件或时序。嵌入式底层 → 项目Hub → 硬件 / 技术负责人过程记录：接口与硬件约束确认。
提交内容：HAL、引脚表、时序、电气约束、板卡依赖和证据。		涉及既有板卡时引用明确版本；新设计注明约束版本。冲突时阻塞相关设计。
F3.6硬件提供本阶段选填约束时。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 产品关联或修订成果：必要时修订已提供的总体技术方案。
过程记录：硬件约束与接口确认。
提交内容：限制、替代方案、成本、性能和交期影响。		本阶段硬件约束为选填，未提供不阻塞；已提供时器件替换不得静默发生。按已提供内容更新接口与约束确认；改变正式基线时走变更申请。
F3.7测试已形成测试计划，或识别出不可测试项、环境/治具缺口。测试 → 项目Hub；无问题时汇总给技术负责人；有缺口时定向转交相关角色确认正式成果：测试计划，包含测试标准、测试用例范围、测试项。
存在缺口时附带：不可测试项、环境/治具缺口、影响、依据及需要相关角色确认的问题。
确认回传：相关角色经项目Hub返回确认结果，测试据此修订测试计划；涉及接口或验收标准时同步对应主责角色修订。		无问题时无需等待缺口确认；项目Hub只汇总和中继，不代替专业角色确认。测试仍主责计划编制与修订，技术负责人经 F3.8–F3.9 确认测试计划。影响本阶段门禁的缺口应先关闭；验证期需跳转时，由负责人明确记录决定。无问题：进入 F3.8–F3.9 汇总确认；有缺口：先定向确认、修订，再返回该确认路径。
F3.8–3.10专业评审完成。项目Hub ↔ 技术负责人；项目Hub ↔ 各相关角色最终确认成果：测试计划的内部确认版本，以及已提供的选填成果（总体技术方案）。
附带内容：方案与接口确认结果、保留风险、证据引用和统一版本关系。		测试计划仍由测试编制和维护，技术负责人确认其与整体方案、接口及实施依赖一致；相关角色按本领域完成最终确认。每个确认绑定同一版本；选填成果未提供不阻塞本阶段；成员角色之间不直接通信。全部确认并登记为正式基线后进入阶段 4 项目规划。
-
- -
-
04 / PLANNING

阶段 4：项目规划信息流

项目Hub根据产品基线和已确认的方案设计成果生成实际任务计划，先由技术负责人确认整体任务结构、技术顺序和依赖；仅对存在疑点的任务，定向向对应执行角色补充确认。资源与排期由产品确认，计划与排期可由项目Hub同步给业务。

-
主责项目Hub；技术负责人确认技术结构，产品确认资源与排期
核心成果项目计划、角色分工、项目状态内部记录
门禁技术负责人确认技术任务结构、顺序和依赖；问题任务完成定向确认；产品确认资源与排期基线
-
项目风险已在阶段 2 由产品汇总形成，本阶段只引用并反馈新增风险，由产品维护当前有效版本；不重新创建阶段 4 风险成果。产品资料整合不再作为独立成果，任务按需引用已有立项资料、方案记录和成果索引。
-
-
项目Hub
F4.1提交任务计划与正式角色分工草案，请求整体确认附产品／方案基线、角色清单、任务拆分、技术顺序、依赖、初始排期和风险
技术负责人
-
技术负责人
F4.2确认整体任务计划或返回调整意见确认任务结构、技术顺序、依赖关系、专业角色覆盖和关键风险
项目Hub
-
项目Hub
F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发
对应执行角色
-
对应执行角色
F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划
项目Hub
-
项目Hub
F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理
技术负责人及受影响角色
-
项目Hub
F4.6请求资源与排期基线确认真实人员、资源安排和排期由产品负责人确认
产品
-
产品
F4.7确认或要求调整资源与排期基线记录产品负责人确认状态、范围、条件和版本
项目Hub
-
项目Hub
F4.8向相关执行角色发布基线计划和正式任务执行角色取得充分任务输入；计划与排期可同步业务（仅知会）；后续按 S.1–S.4 同步
相关执行角色
业务（可同步知会）
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F4.1–4.2阶段 3 方案设计门禁通过，项目Hub已依据产品基线、方案设计成果和项目创建期角色清单形成任务计划草案。项目Hub ↔ 技术负责人正式成果草案：项目计划、角色分工、项目状态内部记录 初始版。《角色分工》列出 Etunel 实际 role 和 display_name、职责边界、任务主责、协作关系和交接要求。
输入基线：阶段 2 产品成果、阶段 3 已确认的必需成果及已提供的选填成果和角色清单；另含任务拆分、关键路径、输入输出、依赖、初始排期和风险。		技术负责人确认技术任务结构、顺序、依赖、版本关系、专业角色覆盖和技术风险；项目Hub不向全部执行角色征求整份计划确认。每项任务只设一个主责角色。形成技术结构与角色覆盖已确认的任务计划草案。
F4.3–4.4（条件流）项目Hub发现任务缺少责任角色、输入、输出、依赖、估算、资源、日期或证据；任务之间存在冲突；或技术负责人明确标记待确认项。项目Hub ↔ 对应执行角色修订对象：项目计划、角色分工、项目状态内部记录 中的问题任务。
过程记录：任务澄清请求／任务澄清回复，包含方案成果引用、上下游依赖、工期、资源、风险和负责人确认。		必须定向发送给该任务的执行角色，不得广播给全部角色，也不得要求执行角色重复确认无疑点任务。补齐或修正问题任务；未触发时直接跳过。
F4.5定向确认后仍存在资源冲突、关键路径冲突或日期不可达。项目Hub ↔ 技术负责人及受影响角色修订成果：项目计划、角色分工、项目状态内部记录 新版本。
过程记录：冲突解决记录，包含冲突点、方案约束、可选排法、阶段影响和响应时限。		项目Hub必须主动提醒，不得静默覆盖技术负责人或执行角色的确认；复杂冲突按 E.1–E.4 闭环。保持计划草案，冲突关闭前不得基线化。
F4.6–4.7技术负责人已确认整体计划，问题任务和剩余冲突均已关闭，资源安排与排期候选基线已形成。项目Hub ↔ 产品待确认成果：项目计划、项目状态内部记录 候选基线。
附带内容：人员与资源安排、工时评估、排期、里程碑、风险、确认范围、条件和状态。		项目Hub不能代替产品确认资源与排期；产品完成负责人确认后统一回复。本环节不替代预算、采购/打样及对外承诺所需的业务授权。产品确认后可基线化。
F4.8技术负责人确认有效、问题任务已关闭且产品确认资源与排期基线。项目Hub → 相关执行角色；可另行同步业务正式基线：项目计划、角色分工、项目状态内部记录。
执行角色状态快照：只包含该角色相关任务、充分输入、依赖、方案成果引用、门禁、风险、时限、成果文件和完成条件。
业务同步（按需）：项目计划、实际项目排期和关键里程碑。		每个角色只接收与自身任务和依赖相关的计划内容；后续角色加入、退出、替换或变化必须登记并交接，改变基线时走变更申请；执行状态按 S.1–S.4 同步；业务同步为知会，不等待业务确认，也不新增门禁。相关角色接收任务，开启阶段 5。
-
- - - -
-
05 / IMPLEMENT

阶段 5：嵌入式软硬件实现信息流

三条实现流依据阶段3方案设计基线和阶段4项目任务计划并行推进；硬件先取得并核对器件规格书和结构板框图，形成并确认硬件设计包后再据此实施；固件只有一条正式出口：嵌入式底层先提供可消费版本，嵌入式应用层完成合版并提交统一固件，项目Hub维护其与硬件版本的唯一映射。

-
并行主责嵌入式应用层、嵌入式底层、硬件
核心成果硬件设计包、嵌入式底层实现资料、嵌入式应用层提交的统一固件包
门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测
-
- F5.2 硬件资料要求
- 前置输入（由上游资料责任角色提供）：
1、外设器件和关键器件（主控、flash、sensor、复位按键、指示灯、WiFi模块、音频功放驱动芯片、IR-CUT驱动芯片、电机达林顿管驱动芯片）规格书。
2、结构板框图（包含主要器件位置和禁止限制区域）。
- 硬件设计资料（纳入硬件设计包）：
1、原理图。
2、PCB 源文档。
3、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）。
4、接口定义。
- 执行前提：硬件先核对项目实际使用器件的规格书，以及结构板框图的来源、适用范围和版本。结构板框图在阶段 2 可选填，但进入 F5.2 前须补齐；资料缺失或冲突时，经项目Hub向对应资料责任角色补齐，不以假设替代输入，仅阻塞依赖这些资料的硬件任务。 -
-
-
项目Hub
F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界；硬件另附器件规格书、结构板框图
嵌入式应用层 / 嵌入式底层 / 硬件
-
硬件
F5.2取得前置输入后提交硬件设计包器件规格书、结构板框图齐备后设计；硬件负责人确认后提交
项目Hub
-
项目Hub
F5.3定向分发硬件设计包及约束变化设计包先完成技术及接口确认，后续只向受影响角色分发完整影响包
技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试
-
嵌入式底层
F5.4提交嵌入式底层实现资料硬件功能测试报告、BSP 输出路径、PSP 输出路径
WiFi 设备定频测试固件（选填）
项目Hub
-
项目Hub
F5.5将已登记的嵌入式底层版本交给嵌入式应用层合版按已登记的 BSP/PSP 输出路径交付；定频测试固件仅用于专项测试
嵌入式应用层
-
嵌入式应用层
F5.6集成底层版本并提交统一固件候选绑定应用、底层和板卡版本，引用已确认的接口定义，包含 MD5、分区、自测和 Changelog
项目Hub
-
任一实现角色
F5.7报告接口、器件或资源冲突接口约束不一致、资源超限或 ECO 影响时
项目Hub → 技术负责人
-
项目Hub
F5.8创建软硬件联调与版本矩阵确认任务统一固件候选和硬件候选版本均可用时
嵌入式应用层 / 硬件 / 技术负责人
-
嵌入式应用层
F5.9提交最终提测固件版本联调问题关闭后，由嵌入式应用层提交最终固件，附完整版本链、自测和偏离说明
项目Hub
-
技术负责人
F5.10确认最终固件与硬件版本匹配并可提测联调问题已关闭且最终版本已提交；确认板卡、BOM、统一固件及其应用/底层版本链匹配
项目Hub
-
-
- - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F5.1阶段 4 项目规划门禁通过。项目Hub → 嵌入式应用层 / 嵌入式底层 / 硬件待产出成果：嵌入式应用层固件包、嵌入式底层实现资料、硬件设计包。
输入与任务：阶段3已确认的必需成果及已提供的选填成果、阶段4 项目计划（项目任务计划）与角色分工、阶段2 项目风险，以及任务、输出格式、依赖和期限。
硬件额外输入：F5.2 所列器件规格书和结构板框图。		三方必须使用相同的方案设计基线和项目计划版本；硬件输入未齐时先补齐资料，不阻塞其他依赖已满足的任务。依赖已满足的实现任务并行启动。
F5.2–5.3硬件已取得并核对 F5.2 所列输入资料，形成或修订硬件设计包；后续发布样机、板卡、BOM 或 ECO。硬件 → 项目Hub → 技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试前置输入：项目实际使用的外设器件和关键器件规格书、结构板框图（主要器件位置和禁止限制区域），具体清单见本阶段 F5.2 硬件资料要求。
正式成果：硬件设计包，登记明确版本。
硬件设计资料（纳入硬件设计包）：原理图；PCB 源文档；贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）；接口定义。先由硬件负责人确认，再经项目Hub中继技术负责人及受影响角色完成技术与接口确认。		所需输入资料未齐备或版本未核对时，先经项目Hub补齐，不得提交正式硬件设计包；设计包确认前不得投板或以未确认设计推进样机制作；没有影响分析不得切换硬件版本；禁止使用“最新板”或“当前 BOM”替代明确版本组合。输入缺失时阻塞相关硬件任务；影响接口、底层或应用固件时阻塞受影响任务。
F5.4–5.5嵌入式底层已形成硬件功能测试报告，BSP 与 PSP 输出路径可访问且版本明确。嵌入式底层 → 项目Hub → 嵌入式应用层正式成果：嵌入式底层实现资料 当前版本。
必需内容：硬件功能测试报告；BSP 输出路径；PSP 输出路径。
选填内容：WiFi 设备定频测试固件。
附带信息：输出版本、适配板卡、BOM/ECO、配置及适用的接口定义版本，以及必要的应用层集成说明、已知限制和风险。		BSP/PSP 路径必须指向可访问的实际输出；硬件功能测试报告记录底层已执行的硬件功能测试，不代替测试角色的整机质量结论。WiFi 设备定频测试固件为非必选项，未提供不阻塞合版、提测或阶段推进，也无需另行豁免；提供时标明 TEST_UTILITY_ONLY，仅用于专项测试，不得作为最终提测或发布固件。项目Hub登记必需成果后，将 BSP/PSP 可消费版本交嵌入式应用层合版。
F5.6嵌入式应用层收到已登记的嵌入式底层可消费版本。嵌入式应用层 → 项目Hub正式成果候选：嵌入式应用层固件包。
提交内容：正式/升级/烧写固件、自测用例、分区表、MD5、zn_debug文件、Changelog、串口使能证书，以及应用/底层/板卡版本链及适用的接口定义版本。		必须形成可追溯的应用层+底层统一版本；禁止提交无法复现的单一二进制。进入软硬件联调候选。
F5.7引脚、时序、资源、器件或协议冲突。角色 → 项目Hub → 技术负责人过程记录：实现冲突记录。
关联成果：受影响的硬件设计包、嵌入式底层实现资料、嵌入式应用层固件包及相关接口约束；提交冲突、证据、版本、影响和建议。		项目Hub立即冻结受影响版本。等待技术裁决及相关设计、接口约束更新。
F5.8统一固件候选和硬件候选版本均已就绪。项目Hub → 嵌入式应用层 / 硬件 / 技术负责人联调输入：统一固件候选、硬件候选及对应版本链。
过程记录：软硬件联调任务、候选版本矩阵和联调问题记录。		候选版本就绪即可启动联调，不以联调问题已关闭作为启动条件。开展软硬件联调并处理问题；问题关闭后进入 F5.9–F5.10。
F5.9–5.10联调问题已关闭；F5.9 提交最终提测版本，F5.10 在提交后进行匹配与可提测确认。嵌入式应用层 → 项目Hub；技术负责人 → 项目Hub最终确认成果：嵌入式应用层固件包、硬件设计包；引用已集成的嵌入式底层实现资料。
过程记录：版本矩阵、集成记录、集成批准；包含最终固件、应用/底层版本链、板卡/BOM/ECO、自测和偏离说明。		最终提测固件只能由嵌入式应用层提交；嵌入式底层和硬件不得直接向测试提交固件。技术负责人确认版本矩阵匹配。确认后由项目Hub将该唯一固件版本交给测试。
-
- -
-
06 / TEST

阶段 6：测试验证与缺陷返工信息流

测试提交测试报告和缺陷清单，由测试与实际相关角色负责人共同商议缺陷责任人；项目Hub按确认分工安排修复和重新提测；最终测试结果须经 Hub 请求项目负责人（Hub 对应真人负责人）人工确认后，才算完成提交。

-
主责测试
核心成果功能测试报告、缺陷清单；可靠性测试报告、专项测试报告、提测佐证（均选填）
门禁阻断缺陷清零、必需成果及其测试依据完整；测试完成专业确认，Hub 取得项目负责人对结果的人工确认并留档后方可放行
-
可靠性测试报告、专项测试报告和提测佐证均为选填。未提供这些选填成果不阻塞阶段 6 交付、后续验收或归档，也无需另行豁免；已提供时确认对应版本和测试负责人意见。可靠性测试报告包括高低温测试、跌落测试（选填）、防水测试（选填）。选填设置不改变已确认的测试范围和质量门禁。
-
无缺陷路径：F6.2 → F6.10 → F6.11 → F6.12。测试已完成且无缺陷时，仍提交功能测试报告和零缺陷清单，直接进入最终质量结论确认，不创建无必要的修复任务。发现缺陷时才进入 F6.3–F6.9 的责任确认、修复和回归流程；两条路径均须继续经过 F6.11–F6.12，由 Hub 请求项目负责人完成人工确认后，才算完成提交；无缺陷也不免除此确认。
-
-
项目Hub
F6.1下发测试任务、最终固件和版本矩阵只允许测试由嵌入式应用层提交并经技术负责人批准的统一固件
测试
-
测试
F6.2提交功能测试报告和缺陷清单测试完成且无缺陷：提交报告和零缺陷清单，直接进入 F6.10；有缺陷则进入 F6.3，关联版本、用例和证据
项目Hub
-
项目Hub
F6.3分发缺陷清单，协调相关负责人商议责任人测试与实际相关角色负责人共同确定每项缺陷的责任人
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
责任角色
F6.4向项目Hub返回确认的责任分工、原因分析和修复计划责任人、协作关系、处理时限和影响范围经对应负责人确认
项目Hub
-
项目Hub
F6.5向责任角色派发修复或专业澄清任务同时将确认结果同步给测试维护缺陷清单；责任争议由相关负责人协调，项目Hub不自行归责
责任角色
测试（同步确认结果）
-
责任角色
F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明替代关系和影响范围
项目Hub
-
项目Hub
F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性
嵌入式应用层
-
嵌入式应用层
F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交
项目Hub
-
项目Hub
F6.9下发定向回归任务和统一固件附版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认提交整包
测试
-
测试
F6.10提交经测试内部确认的最终结果，等待项目负责人确认附功能测试报告、缺陷清单、质量结论及剩余风险；Hub 收到不代表提交完成，继续 F6.11–F6.12
项目Hub
-
项目Hub
F6.11请求项目负责人确认测试结果核对成果、版本、证据及测试内部确认后发起；未确认前保持待确认，不放行
项目负责人
（Hub 对应真人负责人）
-
项目负责人
（Hub 对应真人负责人）
F6.12人工确认测试结果或退回补充确认后由 Hub 登记提交完成，并核对质量门禁；退回则交测试补充或必要修复、复验后重新确认
项目Hub
-
-
- - - - - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F6.1–6.2技术负责人批准嵌入式应用层提交的最终固件与硬件集成版本。项目Hub ↔ 测试测试输入：嵌入式应用层固件包、版本矩阵、测试计划。
必需成果草案：功能测试报告、缺陷清单。
选填成果：可靠性测试报告、专项测试报告、提测佐证。
提测佐证内容（选填）：平台要求的视频、截图、log材料。
佐证提交方式：提供时只向项目Hub登记文件索引、版本和交付状态；文件由测试直接交付产品，F7.1 确认接收。		测试只能接收嵌入式应用层提交且经技术负责人批准的最终固件；缺陷必须关联可复现环境和版本。底层实现资料和硬件设计包不再列为阶段 6 的常规测试输入，不因未附这两类资料拒绝提测；具体测试或定位确需信息时按实际问题经项目Hub查询，不重新要求整包提交。启动测试并更新测试状态；测试完成且无缺陷时，F6.2 提交功能测试报告和零缺陷清单后直接进入 F6.10，不创建无必要的修复任务；有缺陷则进入 F6.3。
F6.3测试发现缺陷或测试异常并形成可追踪记录。测试 → 项目Hub → 实际相关角色提交与更新成果：测试主责的《缺陷清单》。
分发内容：缺陷编号、现象、状态、模块、版本、环境、用例、复现、证据、影响、风险、优先级和回归要求。
商议结果：缺陷责任人、主责角色、协作角色及处理时限。		测试与实际相关角色的负责人共同商议解决缺陷的责任人，每项缺陷明确一名责任人和一个主责角色。项目Hub只登记已确认的分工并路由，不自行指定责任人；跨层技术问题由技术负责人提供判断依据，需求含义由产品澄清。分歧未收敛时按 E.1–E.4 协调。确认缺陷责任分工后，由责任角色在 F6.4 返回原因与计划，项目Hub在 F6.5 派发任务。
F6.4相关负责人已共同确认缺陷责任人，责任角色完成原因分析与计划确认。责任角色 → 项目Hub过程记录：确认的责任人、主责与协作角色、原因分析和修复计划，包含影响、方案、风险、修复成果计划、期限、需重测范围和证据；必要时引用技术／产品决定。“无法复现”“符合设计”或“不修复”必须带理由与证据；责任人调整仍需相关负责人共同确认。项目Hub接收确认结果，进入 F6.5 派发任务并同步测试。
F6.5项目Hub收到 F6.4 已确认的原因分析、责任分工和修复计划。项目Hub → 责任角色；同时项目Hub → 测试派发任务：按已确认分工向责任角色派发修复或专业澄清任务，明确输出、期限和回归要求。
同步确认结果：将已确认的责任分工、原因分析及修复计划同步给测试，由测试维护同一份《缺陷清单》的责任人、状态和回归要求。		项目Hub不自行归责；实现角色不直接替换或关闭测试主责的《缺陷清单》。阻断缺陷使阶段阻塞；等待修复成果和目标版本复验。
F6.6–6.8应用修复、嵌入式底层修复或硬件 ECO 已提交。责任角色 → 项目Hub → 嵌入式应用层 → 项目Hub → 测试实现角色修订成果：嵌入式应用层固件包、嵌入式底层实现资料或硬件设计包。
同步给测试的确认结果：责任分工、修复进展及必要变更说明，包含目标版本、影响和建议回归范围；测试据此维护《缺陷清单》。回归统一按 F6.9 提交统一固件、版本矩阵、缺陷清单及必要变更说明；具体定位资料按问题提供，不默认提交实现资料整包。
硬件 ECO 额外内容：新旧板卡／PCB／BOM／ECO 差异、受影响批次、返工／回退方式、板级验证证据、底层驱动／HAL 兼容评估、应用固件有效性确认和新版本矩阵。		实现角色无权直接替换或关闭《缺陷清单》。嵌入式底层修复不得直接交给测试；必须由嵌入式应用层重新合版。硬件 ECO 先经底层兼容评估；即使不修改固件，也必须由嵌入式应用层确认原固件继续有效。技术负责人按需确认版本矩阵，测试在目标组合上复验并独立给出“已验证”或“已关闭”结论。形成唯一可回归的固件与硬件版本矩阵，并由测试复验。
F6.9统一回归固件和硬件版本矩阵通过项目Hub校验，必要时由技术负责人确认。项目Hub → 测试回归输入：统一固件、版本矩阵、缺陷清单及必要变更说明。具体定位资料按实际问题经项目Hub提供，不默认提交底层实现资料或硬件设计包整包。
过程记录：回归任务，包含修复范围、受影响用例和时限。		旧版本不得覆盖；测试不得接收嵌入式底层单独提交的固件。执行定向回归。
F6.10测试完成且无缺陷时由 F6.2 直接进入，或缺陷处理及必要回归完成后进入；均须阻断缺陷清零且必需成果及其测试依据齐全。测试 → 项目Hub待项目负责人确认的成果：功能测试报告、缺陷清单的测试负责人确认版本。
已提供时一并确认：可靠性测试报告、专项测试报告、提测佐证。
附带内容：质量结论、覆盖率、未关闭缺陷、剩余风险和接受方。		测试内部确认状态必须记录；剩余风险必须有接受方；选填成果未提供不作为门禁阻塞项。提测佐证提供时只登记索引、版本和测试负责人确认，无需向项目Hub上传大文件。Hub 登记为待项目负责人确认，进入 F6.11；收到结果或测试内部确认均不代表提交完成。
F6.11Hub 收到 F6.10 最终测试结果，完成文件或交付索引、版本、证据及测试内部确认校验。项目Hub → 项目负责人（Hub 对应真人负责人）功能测试报告、缺陷清单、已提供的选填成果或可访问索引，以及质量结论、目标版本、未关闭问题、剩余风险及接受方。项目负责人是 Hub 对应真人负责人，不新增 Agent；Hub AI 不代为确认，不替测试作出专业结论。选填成果未提供无需补交，大文件不要求经 Hub 收转。等待人工确认；不能登记提交完成或进入阶段 7。
F6.12项目负责人对 F6.11 对应版本明确给出确认或退回意见。项目负责人（Hub 对应真人负责人） → 项目Hub人工确认结果、确认人、确认时间、成果与目标版本、退回理由或剩余风险处理意见；Hub 留存确认记录并同步测试。只有明确人工确认后才算完成提交；沉默、已读、工具接收成功或 AI 判断均不算。测试结果变化须重新经过 F6.10–F6.12，旧确认不能覆盖新版本。人工确认不替代测试通过、风险接受或平台／客户验收。确认：Hub 登记提交完成，并在阻断缺陷清零、必需成果与测试依据完整、剩余风险有接受方等质量条件满足后进入阶段 7。退回：保持未完成，经 Hub 交测试补充后回 F6.10；需要修复或复验时按 F6.3–F6.9 处理，再重新请求确认。
-
- -
-
07 / ACCEPT

阶段 7：平台验收与客户验收信息流

平台验收在前、客户验收在后；各自输入就绪时可并行开展。平台结果由产品确认，客户结果由业务确认，两部分均通过后才完成阶段 7。

-
主责产品组织两部分验收；平台由产品确认，客户由业务确认；项目Hub登记与协调
核心成果平台验收报告或结论、客户验收通过报告、遗留问题清单
总门禁平台验收通过 + 客户验收通过，两项缺一不可
-
资料交接：须先完成 F6.12 项目负责人对测试结果的人工确认并满足测试门禁；随后测试负责人直接向产品负责人交付测试报告及已提供的提测佐证，文件不经项目Hub转发。产品只需确认收到对应资料；项目Hub登记文件名称、版本和接收确认，不要求大文件上传或重复转交。提测佐证仍为选填，未提供不阻塞验收；收到材料不等于验收通过。
-
-
产品
F7.1确认收到测试报告及已提供的提测佐证F6.12 人工确认且测试门禁通过后直接交付；Hub 登记产品接收确认，该确认不能替代项目负责人确认
项目Hub
-
-

第一部分：平台验收

-
-
项目Hub
F7.2组织平台验收，明确验收对象和依据优先启动平台验收；产品使用已收到的测试资料
产品
-
产品
F7.3出具平台验收报告或结论产品负责人确认通过或不通过，无需业务确认；更新同一份《遗留问题清单》，标明平台来源
项目Hub
-
-

第二部分：客户验收

-
-
项目Hub
F7.4组织客户验收，准备客户验收资料客户验收输入就绪时，可与平台验收并行，不必等待平台先通过
产品
-
产品
F7.5提交客户验收报告和遗留问题清单客户反馈按联络边界取得；更新同一份《遗留问题清单》，标明客户来源并保留平台问题
项目Hub
-
项目Hub
F7.6请求业务确认客户验收结果只确认客户验收部分，不追加平台验收审批
业务
-
业务
F7.7确认客户验收通过或退回整改明确客户反馈、结论、版本及遗留问题承接
项目Hub
-
-

共用返工与验收总门禁

-
-
项目Hub
F7.8定向路由平台或客户验收未通过的问题只处理实际受影响部分；需要测试时返回阶段 6
实际相关责任角色
-
责任角色
F7.9提交整改成果、说明及必要复验结果平台返回 F7.2–F7.3；客户返回 F7.4–F7.7，分别更新结论
项目Hub
-
项目Hub
F7.10核对平台通过 + 客户通过，登记验收基线汇总核对同一份《遗留问题清单》及来源；平台有产品确认、客户有业务确认，两项均通过后进入阶段 8
项目Hub
-
-
- - - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F7.1F6.12 已取得项目负责人对对应测试结果版本的人工确认，且测试门禁通过；测试已向产品交付必需测试报告。测试负责人 → 产品负责人（直接交付文件）；产品 → 项目Hub（接收确认）接收确认：产品确认已收到测试报告及已提供的提测佐证，说明对应文件名称和版本。
验收输入：功能测试报告、缺陷清单及已提供的选填成果（可靠性测试报告、专项测试报告、提测佐证），以及嵌入式应用层固件包、版本矩阵和已知限制。		项目Hub只登记交付索引与产品接收确认，不中转文件，不以大文件上传为交接条件；选填成果未提供无需补交。接收确认不替代后续验收结论。产品取得平台与客户验收所需输入。
F7.2–7.3平台验收所需输入就绪。项目Hub → 产品 → 项目Hub正式成果：平台验收报告或结论，二选一即可；同步更新平台与客户共用的《遗留问题清单》，标明平台来源、责任人、状态和期限。
内容：验收对象与版本、测试或平台结果引用、通过／不通过、问题和限制、产品负责人确认。		平台验收由产品出具报告或明确结论并确认，无需业务确认；项目Hub只登记，不代产品判断。平台通过后登记该分支完成；不通过进入 F7.8–F7.9。
F7.4–7.5客户验收所需资料与客户联络条件就绪，不要求平台已经通过。项目Hub → 产品 → 项目Hub正式成果草案：客户验收通过报告；更新与 F7.3 共用的同一份《遗留问题清单》，标明客户来源，保留平台问题及其处置记录。
内容：客户验收对象、版本、反馈、结果、问题、责任人和期限。		客户验收可以与平台验收并行；客户信息由业务或产品负责人按联络边界取得并回传，不虚构客户 Agent 或客户确认。形成提交业务确认的客户验收材料。
F7.6–7.7客户验收材料与反馈齐备。项目Hub → 业务 → 项目Hub待确认成果：客户验收通过报告及客户相关遗留问题。
确认内容：客户验收通过或退回整改、对应版本、反馈依据和负责人确认。		业务确认仅针对客户验收，不作为平台验收的批准环节；未确认、未完成或退回整改均不计为客户通过。客户通过后登记该分支完成；否则进入 F7.8–F7.9。
F7.8–7.9平台或客户验收未通过、资料缺口或结论需要修订。项目Hub → 实际相关责任角色 → 项目Hub过程记录：验收问题与定向返工记录。
修订内容：受影响的上游成果、整改说明、必要复验结果，以及对应平台／客户验收结论和遗留问题清单。		需要测试时返回阶段 6，由测试独立复验；更新的最终测试结果须重新经过 F6.10–F6.12 人工确认，原确认不得直接沿用。责任分工按已确认规则协调。完成后回对应验收分支；版本变化影响另一分支时，该分支也需更新确认。未通过的分支保持处理中，不重启整个项目。
F7.10平台验收通过，且客户验收通过。项目Hub登记双线结果门禁依据：产品确认的平台验收报告或结论、业务确认的客户验收通过报告，以及平台与客户共用的同一份《遗留问题清单》。
登记内容：汇总核对 F7.3、F7.5 分别更新的平台／客户问题及来源、状态、责任人与期限；登记两部分结论、验收对象与版本、确认人、未关闭问题的承接人和期限。		总条件为平台通过 + 客户通过；任一未通过、未完成或待确认均不得进入阶段 8。两部分结论应对应一致的验收对象与有效版本，不再追加平台的业务确认。登记双线验收基线，进入阶段 8 资料归档与复盘结项。
-
- -
-
08 / CLOSE

阶段 8：资料归档与复盘结项信息流

项目Hub组织收集各阶段已确认资料，核对验收与遗留问题承接，开展项目复盘并完成结项。本阶段不安排测试或发布验证任务。

-
协调项目Hub组织；实际参与角色提供资料和复盘输入；业务确认结项
核心成果结项资料归档、变更记录、结项报告、流程闭环总结（项目复盘）
门禁双线验收通过、资料归档完整、复盘完成、遗留问题已关闭或落实承接
-
-
项目Hub
F8.1下发资料收集与项目复盘任务只面向实际参与、持有成果或承担遗留事项的角色
实际相关角色
-
实际相关角色
F8.2提交各阶段最终资料与成果索引沿用已确认版本，附变更记录、必要过程记录及资料位置
项目Hub
-
项目Hub
F8.3核对双线验收结果与遗留问题承接平台采用产品确认，客户采用业务确认；遗留问题落实责任人与期限
产品 / 业务
-
项目Hub
F8.4组织项目复盘，收集经验与改进建议围绕目标完成、计划偏差、协作、质量问题和改进措施
实际相关角色
-
实际相关角色
F8.5提交复盘结论与改进项说明经验、问题原因、改进措施、责任人和跟进安排
项目Hub
-
项目Hub
F8.6汇总资料归档、变更记录、复盘总结与结项报告核对资料索引、有效版本、确认记录及遗留事项承接
归档库
-
业务
F8.7确认项目结项或要求补充依据归档完整性、项目复盘和遗留事项承接进行结项确认
项目Hub
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认对阶段的影响
F8.1–8.2阶段 7 平台验收和客户验收均已通过。项目Hub ↔ 实际相关角色收集资料：各阶段正式成果的当前有效版本、必要过程记录、变更记录、项目进度、成果索引和对应确认。
实现资料：已验收的应用层统一固件、被集成的底层版本、硬件设计包及匹配版本关系。		沿用已确认成果，不重新要求制作同内容文件；实际未参与的角色不虚构成果。测试直接交付产品的资料保留文件索引和产品接收确认，项目Hub无需收存或重复转交大文件。形成结项资料清单与缺口清单。
F8.3各阶段资料与验收记录已收集。项目Hub ↔ 产品 / 业务核对内容：产品确认的平台验收报告或结论、业务确认的客户验收通过报告、遗留问题清单。
承接信息：未关闭问题、风险、责任人、期限和后续跟进方式。		只核对已有双线验收结果，不重新给平台增加业务批准；遗留事项必须已关闭或有明确承接。确认结项范围与后续责任。
F8.4–8.5项目事实、阶段成果及主要问题已整理。项目Hub → 实际相关角色 → 项目Hub复盘输入：目标完成情况、计划与实际偏差、协作与质量问题、有效经验和改进建议。
输出：各角色确认的复盘结论与改进项，汇入《流程闭环总结》。		复盘基于已有事实和记录，不把未执行的验证写成已完成；改进项说明责任人和跟进安排。完成项目复盘并形成可跟进的改进项。
F8.6资料收集、验收核对和项目复盘完成。项目Hub → 归档库正式成果：结项资料归档、变更记录、结项报告、流程闭环总结。
汇总内容：最终资料索引、有效版本、阶段确认、验收结论、复盘经验、改进项与遗留责任。		保留历史版本和引用，不以完整聊天记录代替项目档案；选填成果未提供不作为归档阻塞项。形成可追溯的结项包。
F8.7结项包完整且遗留事项已有承接。业务 → 项目Hub确认对象：结项报告、流程闭环总结和结项资料归档完整性。
结项决定：确认结项或补充清单、负责人确认与时间。		待补充的结项必需项未完成时不关闭；确认结项不代表新增测试、发布或生产验证已经执行。确认后锁定四类结项成果，关闭项目并按安排跟进遗留与改进项。
-
- -
-
X / CROSS-CUTTING

贯穿全阶段：变更、阻塞与超时信息流

变更申请 和异常升级不属于某个单一阶段；项目Hub必须暂停受影响任务，组织并行影响评估，再按既定权限确认或批准变更并决定是否重开阶段。授权范围内的资源、排期调整由产品确认；涉及预算、采购或对外承诺时由业务批准。其他变更沿用已确认的职责与授权边界。

-
-
-
任意角色
X.1提交变更申请或阻塞记录附原因、证据、受影响版本和紧急度
项目Hub
-
项目Hub
X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试
产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试
-
评估角色
X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出
项目Hub
-
项目Hub
X.4按授权范围提交综合影响和确认请求授权内资源、排期调整交产品；预算、采购或对外承诺交业务
产品 / 业务
按授权范围接收
-
产品 / 业务
按权限确认或批准
X.5返回确认、批准或拒绝变更的决定产品确认授权内资源与排期；涉及预算、采购或对外承诺须业务批准
项目Hub
-
项目Hub
X.6超时提醒与升级专业事项升级给对应角色；项目级组织授权升级给业务
对应角色
-
-
-
- - - - -
ID触发条件发送 → 接收提交内容（对应正式成果）约束状态结果
X.1范围、接口、器件、版本、资源或日期发生变化；或出现无法继续的阻塞。任意角色 → 项目Hub过程记录：变更申请或阻塞记录。
关联成果：当前基线、受影响成果及版本、任务、原因、证据和紧急程度；批准后写入变更记录。		必须关联当前基线和受影响任务。创建变更或阻塞记录。
X.2–X.3中心确认变更可能影响正式成果。项目Hub ↔ 产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试过程记录：角色影响评估。
提交内容：对受影响正式成果逐项给出范围、方案、工期、成本、测试、返工和版本影响，并列出建议修订的成果和版本。		各角色只评估自己的责任范围；现实承诺在角色内部确认后统一发出。受影响任务冻结。
X.4–X.5影响评估齐全，变更事项与适用授权范围明确。项目Hub ↔ 产品（授权范围内的资源、排期调整）；涉及预算、采购或对外承诺时，项目Hub ↔ 业务过程记录：变更决定记录，注明授权依据、确认或批准角色、负责人及决定时间。
成果影响：综合影响清单、确认／批准／拒绝／延期建议和新基线候选；取得必要确认或批准后更新变更记录、相关正式成果和项目状态内部记录。		授权范围内的资源、排期调整由产品确认，不额外等待业务批准；涉及预算、采购或对外承诺时，须取得业务批准，不以产品确认替代。其他变更沿用已确认职责与授权，不扩大产品权限；技术与质量判断仍由对应专业角色确认。不得隐藏已完成工作损失、成本或里程碑影响。取得必要确认或批准：建立新基线并重开受影响阶段；拒绝或延期：维持原基线。
X.6确认或任务超过约定时间。项目Hub → 对应角色；项目级组织授权事项发给业务过程记录：升级通知。
提交内容：逾期对象、受影响任务与正式成果、逾期时长、证据、影响、替代方案和新的期望时间。		接收角色在内部完成确认后统一回复。保持等待确认或阻塞。
-
- -
-
Y / ARTIFACT WAIVER

贯穿全阶段：成果文件缺省与豁免信息流

必需成果默认必须输出，选填成果未提供无需豁免。仅主责角色可申请豁免；项目Hub校验并汇总申请，必须由项目负责人（项目Hub对应真人负责人）批准或拒绝，Hub AI 不得自行决定。

-
发起者该成果在流程中的主责角色
审批人项目负责人（项目Hub对应真人负责人）；项目Hub AI 仅登记与执行决定
门禁结果需要成果 → 审查豁免 → 已豁免或仍需成果
-
-
成果主责角色
Y.1提交成果豁免申请说明为何本项目不适用，并附证据和替代信息
项目Hub
-
项目Hub
Y.2校验发起资格与可豁免性非主责角色、无证据或不可豁免成果直接退回
主责角色
-
项目负责人
项目Hub对应真人负责人
Y.3人工确认批准或拒绝成果豁免依据申请、证据、替代方案与影响，记录确认人、时间和条件
项目Hub
登记与门禁更新
-
项目Hub
Y.4A批准：记录已豁免并分发豁免记录仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足
全部受影响角色
-
项目Hub
Y.4B拒绝：仍需该成果返回主责角色生成文件或补充证据
成果主责角色
-
-
- - - - - -
ID触发条件发送 → 接收正式载荷约束/确认门禁与版本结果
Y.1主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。主责角色 → 项目Hub成果类型、阶段、原因、事实证据、适用范围、替代成果、下游影响、风险和负责人确认。只有该成果主责角色可发起；“暂时来不及”不属于不适用。进入豁免审查，此时仍需要该成果。
Y.2中心收到豁免申请。项目Hub → 主责角色资格校验、结构校验、补充问题或不可豁免的事实依据。安全、法规和核心验收证据可明确为不可豁免。资料缺口退回补正；最终批准或拒绝仍由项目负责人确认，门禁不提前放行。
Y.3项目Hub已校验并汇总豁免申请、事实证据、替代方案和影响。项目负责人（项目Hub对应真人负责人） → 项目Hub（记录人工决定）成果类型、项目范围、基线引用、批准或拒绝决定、确认人、确认时间、附加条件及失效条件。所有成果豁免必须由项目负责人明确批准或拒绝；沉默、AI 判断或形式校验不算批准。取消独立的下游征询与业务确认环节，不改变不可豁免要求，也不伪造专业或验收结论。批准后登记；拒绝或未确认时仍需该成果。
Y.4A豁免批准。项目Hub → 全部受影响角色已豁免状态、豁免记录、替代成果和附加条件。不能删除原必需项；保留豁免记录。项目范围或输入基线变化时自动失效并重新评估。仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足。
Y.4B豁免拒绝或附加条件未满足。项目Hub → 主责角色拒绝理由、必须生成的成果、补充证据和期限。主责角色仍须输出正式文件。仍需该成果，阶段继续阻塞。
-
-
-
Codex 多角色项目推进总流程图与阶段信息流图谱 · V1.0 · CURRENT
-
- - - diff --git a/doc/20260908/V0.16-Skill全量流程覆盖核对.md b/doc/20260908/V0.16-Skill全量流程覆盖核对.md deleted file mode 100644 index 790abde..0000000 --- a/doc/20260908/V0.16-Skill全量流程覆盖核对.md +++ /dev/null @@ -1,118 +0,0 @@ -# V0.16 → Skill 与 Hook 全量流程覆盖核对 - -日期：2026-09-08。范围：以 [V0.16 HTML 全文](../20260907/Codex多角色项目推进总流程图-V0.16.html) 为设计依据，核对总览、通用规则、成果矩阵、全部信息流及页面动态成果标签。V0.16 包含其继承的 V0.15 内容，不只检查两项新增注释。 - -本次为本地维护核对，不代表真实项目执行或正式发布。V0.16 仍为 REVIEW；在途项目不自动迁移。未修改 [V0.15 HTML](../20260904/Codex多角色项目推进总流程图-V0.15.html) 或 V0.16 HTML，未提交、推送、合入主分支或更新已安装缓存。核对记录不作为运行时 Skill 的依赖。 - -## 本次补齐纪要 - -1. 补全状态查询、带证据纠正、核验后重新分发的闭环，以及异步无法按时收敛时的会议处理。 -2. 补全 X.6 超时升级的触发、责任去向、通知内容和等待状态；逾期不等于批准，项目负责人专属确认不转交业务代批。 -3. 区分初始提测技术确认与回归按需技术确认；硬件 ECO 即使固件不变，也须完成底层兼容、应用有效性和版本关系确认。 -4. 补齐复盘改进项责任人与跟进安排、业务结项确认后锁定四类成果和结项后承接。 -5. 补齐测试结果人工决定向测试同步、豁免失效及附加条件未满足时的处理；纠正自定义角色变更“一律业务批准”的旧泛化表述。 - -其余累计更新已有覆盖，继续保留，未重复复制整段流程。入口仅补查阅路由；详细规则仍分布于生命周期、状态、异常、成果、角色及测试二级说明，八角色 Hook 保留精简控制点。 - -## 核对方法与落点 - -下表按依赖连续的节点分组，覆盖 92 个信息流节点。每组均核对触发条件、责任主体、输入与输出、确认要求、后续流向。共用规则不在每个角色文件重复： - -- 通用提交与确认：[成员工作流](../../etunel-role-collaboration/references/member-workflow.md)、[Hub 工作流](../../etunel-role-collaboration/references/hub-workflow.md)、[消息流程](../../etunel-role-collaboration/references/etunel-message-lifecycle.md)、[成果与完成判定](../../etunel-role-collaboration/references/artifacts-and-evidence.md)。 -- 阶段与门禁：[项目生命周期](../../etunel-role-collaboration/references/project-lifecycle.md)；具体栏目见 [业务](../../etunel-role-collaboration/references/roles/business.md)、[产品](../../etunel-role-collaboration/references/roles/product.md)、[技术负责人](../../etunel-role-collaboration/references/roles/technical-lead.md)、[应用层](../../etunel-role-collaboration/references/roles/embedded-application.md)、[底层](../../etunel-role-collaboration/references/roles/embedded-lowlevel.md)、[硬件](../../etunel-role-collaboration/references/roles/hardware.md)、[测试](../../etunel-role-collaboration/references/roles/testing.md)。 -- 状态、异常与归档：[角色与项目状态](../../etunel-role-collaboration/references/project-status-and-membership.md)、[异常与协调](../../etunel-role-collaboration/references/exceptions-and-coordination.md)、[项目文件与进度留档](../../etunel-role-collaboration/references/project-files-and-progress.md)。 -- 深层测试：[执行与质量门禁](../../etunel-role-collaboration/references/testing/execution-and-gates.md)。专项细则按任务读取，不能增加阶段 8 测试或把选填报告改为必需。 - -### 通用、状态与异常 - -| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 | -|---|---|---|---|---|---| -| G.1–G.3 | 任务、成果或跨角色请求需要流转 | 主责 → Hub → 目标角色 → Hub | 有效任务、成果、版本与证据 → 已确认结果和下游引用 | 各自真人确认；Hub 形式与一致性检查、登记后定向路由，不代专业判断 | 已覆盖 | -| S.1–S.2 | 上下文不足、过期，或关键状态改变 | 请求角色 → Hub → 请求及受影响角色 | 查询范围、详细度、时点和用途 → 有来源的角色化快照 | 授权内最少信息，不转发私聊和未确认判断；供接收方执行或纠正 | 本次补全查询闭环 | -| S.3–S.4 | 收到快照；提出有证据的纠正 | 接收角色 → Hub → 受影响角色 | 可继续确认，或正确值、原因、证据及负责人确认 → 核验后的新快照 | 核对版本与一致性，保留历史；争议转 E，正式基线变化转 X | 本次补全回传与重发 | -| E.1–E.2 | 条件、阻塞、依赖、冲突、逾期或下游不可用；复杂问题或异步超时不收敛 | Hub 提醒实际相关角色，当前主责真人组织会议 | 问题、证据、影响、原位置、时限 → 会议问题包与待决定事项 | Hub 不主持专业裁决；未收敛不恢复受影响流程 | 本次明确异步时限及会议输入 | -| E.3–E.4 | 讨论形成统一确认结论，Hub 校验通过 | 当前主责 → Hub → 原流程及关联角色 | 各专业确认 → 会议决定、恢复点、动作和新时限 | 仍有关键分歧或缺确认则阻塞；改变基线转 X；不以纪要替代成果 | 本次明确残余分歧及恢复通知 | - -### 阶段 1–4 - -| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 | -|---|---|---|---|---|---| -| F1.1–F1.3 | 业务已收集并内部确认；仅形式错误或来源冲突触发 F1.2 | 业务 → Hub → 业务或产品 | 背景说明、客户里程碑及来源 → 问题清单或待评审版本 | 无错误不走退回；Hub 不补造业务事实；分发产品评审 | 已覆盖 | -| F1.4–F1.5 | 评审版本已分发，待确认项已澄清 | 产品、业务经 Hub 分别确认；Hub 分发 | 同一需求版本 → 已登记业务基线及阶段 2 任务 | 双方真人确认、留档后进产品定义；不恢复早期风险预检三流程 | 已覆盖 | -| F2.1–F2.2 | 业务基线有效，产品定义启动 | Hub → 产品 → Hub | 阶段 1 基线 → 立项资料、验收标准、里程碑、项目风险及评审请求 | 产品自审确认，明确评审角色、问题与范围 | 已覆盖 | -| F2.3–F2.4 | 产品提交可评审草案与请求 | Hub → 指定专业角色 → Hub | 同版四类成果和相关参考 → 字段级结论、缺口、约束、风险及依据 | 各角色只确认本领域，不仅回复可行与否；交产品收口 | 已覆盖 | -| F2.5–F2.6 | 存在评审冲突或缺口 | Hub → 产品 → Hub | 意见与冲突 → 修订成果、关闭说明和保留风险 | 产品确认版本；当前必需问题未关闭不推进，不强求后续资料 | 已覆盖 | -| F2.7–F2.8 | 专业评审完成、产品候选已确认 | Hub → 业务 → Hub | 范围、验收、里程碑、风险与版本 → 批准、驳回或附条件决定 | 业务内部授权；附条件项明确责任与期限；批准留档后进阶段 3 | 已覆盖 | -| F3.1–F3.3 | 阶段 2 门禁通过 | Hub ↔ 技术负责人，再分发相关角色 | 产品基线及已有评审 → 设计要点、接口约束及角色化设计任务 | 不依赖未来项目计划；总体技术方案选填；同一基线设计 | 已覆盖 | -| F3.4 | 应用需要新 HAL、资源或协议 | 应用层 → Hub → 底层、技术负责人 | 接口需求、资源指标、理由及影响 → 确认记录 | 不私下约定；已有方案按需修订，改变正式基线转 X | 已覆盖 | -| F3.5–F3.6 | 底层依赖硬件约束；硬件提供选填反馈时 | 底层／硬件经 Hub 到技术及受影响角色 | 引脚、时序、电气、板卡及证据 → 约束、替代方案、影响与确认 | 关联明确版本；硬件约束未提供不阻塞本阶段，已提供不静默替换 | 已覆盖 | -| F3.7 | 测试形成计划或识别不可测、环境／治具缺口 | 测试 → Hub → 技术负责人或相关角色 | 标准、用例范围、测试项及缺口 → 确认意见与修订计划 | 无问题直接汇总；有问题先定向确认，测试修订，必要时同步接口／验收主责 | 已覆盖 | -| F3.8–F3.10 | 计划及反馈就绪，影响门禁的缺口已处理 | Hub ↔ 技术负责人及相关角色 | 测试计划、接口记录、已提供选填成果 → 同版最终确认 | 技术确认计划，专业角色确认可实施／可验证，产品确认不偏离；留档进阶段 4 | 已覆盖 | -| F4.1–F4.2 | 方案门禁通过，Hub 形成计划草案 | Hub → 技术负责人 → Hub | 产品／方案、实际角色、阶段 2 风险 → 计划、分工、内部状态初版 | 技术结构、顺序、依赖先确认；每项任务唯一主责 | 已覆盖 | -| F4.3–F4.5 | 仅任务有疑点或定向确认后仍有冲突 | Hub ↔ 对应执行角色、技术负责人及受影响角色 | 具体任务缺口 → 工时／资源确认和计划修订 | 不全员重审；残余冲突转 E，关闭前不基线化 | 已覆盖 | -| F4.6–F4.8 | 技术结构、问题任务和剩余冲突已处理 | Hub ↔ 产品，再分发执行角色 | 资源排期候选 → 产品确认基线与充分任务输入 | 产品确认授权内人员资源排期；预算采购承诺另需业务授权；知会业务不加门禁 | 已覆盖 | - -### 阶段 5–6 - -| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 | -|---|---|---|---|---|---| -| F5.1 | 阶段 4 门禁通过、对应依赖就绪 | Hub → 应用层、底层、硬件 | 同版方案、任务计划、角色分工及风险 → 各实现任务 | 仅依赖就绪任务并行；硬件缺输入不拖住其他任务 | 已覆盖 | -| F5.2–F5.3 | 器件规格书和结构板框图已核对 | 硬件 → Hub → 技术及受影响角色 | 实际器件规格、主要位置与禁止区域 → 原理图、PCB 源文档、贴片资料、接口定义 | 硬件真人先确认、技术及接口确认后实施；不另交硬件实现资料包 | 已覆盖 | -| F5.4–F5.5 | 底层报告形成、BSP／PSP 可访问且版本明确 | 底层 → Hub → 应用层 | 硬件功能测试报告、BSP／PSP 路径、匹配信息 → 可消费版本 | 自测不代整机质量；WiFi 定频固件选填且仅专项用途，非最终固件 | 已覆盖 | -| F5.6–F5.7 | 应用取得登记底层版本；实现有冲突时 | 应用层／实现角色 → Hub → 技术负责人 | 统一候选与版本链；冲突证据 → 固件包或技术协调记录 | 唯一应用出口；冲突冻结受影响版本，不冻结无关工作 | 已覆盖 | -| F5.8 | 统一固件与硬件候选均就绪 | Hub → 应用层、硬件、技术负责人 | 候选版本链 → 联调任务、矩阵、问题记录 | 不要求最终提测版或联调问题先关闭；执行联调 | 已覆盖 | -| F5.9–F5.10 | 联调问题关闭后提交最终版，再作匹配确认 | 应用层 → Hub；技术负责人 → Hub | 最终固件、硬件及底层链 → 技术匹配与可提测确认 | 此确认必需；确认后唯一固件进入 F6.1 | 已覆盖并澄清与回归的区别 | -| F6.1–F6.2 | 应用最终固件与硬件组合经技术负责人批准 | Hub → 测试 → Hub | 统一固件、矩阵、计划 → 功能报告、缺陷清单及已提供选填成果 | 不默认附底层／硬件整包；完成且零缺陷走 F6.10，否则进缺陷协调 | 已覆盖 | -| F6.3 | 测试发现可追踪缺陷或异常 | 测试经 Hub 与实际相关负责人商议 | 缺陷条目、版本、证据、影响 → 责任人、唯一主责、协作与时限 | Hub 不自行定责；分歧转 E，清单仍由测试维护 | 已覆盖 | -| F6.4–F6.5 | 已共同确认责任，原因及计划已确认 | 责任角色 → Hub；Hub → 责任角色并同步测试 | 原因、方案、期限、重测范围 → 修复／澄清任务与清单更新依据 | 两个方向分开；不修复等处置有依据；实现角色不替换清单 | 已覆盖 | -| F6.6–F6.8 | 已有应用、底层修复或硬件 ECO | 责任角色 → Hub → 应用层 → Hub | 修复、自测、影响 → 新统一固件或原固件有效性确认及新矩阵 | 底层必须合版；硬件 ECO 经底层兼容、应用有效性确认；技术矩阵按需确认 | 本次明确固件不变分支与按需条件 | -| F6.9 | 回归固件与矩阵通过 Hub 校验，必要技术确认已满足 | Hub → 测试 | 统一固件、矩阵、缺陷清单及必要变更说明 → 定向独立回归 | 定位资料按问题提供；不每轮固定技术审批；测试才可复验关闭缺陷 | 本次纠正无条件技术确认 | -| F6.10 | 测试完成且无缺陷，或修复与必要回归完成；必需依据齐、阻断缺陷清零 | 测试 → Hub | 测试负责人确认的报告、清单、质量与剩余风险接受方 → 待项目负责人确认 | 零缺陷也交报告与零清单；已提供选填成果一并确认；进 F6.11 | 已覆盖 | -| F6.11–F6.12 | Hub 校验最终结果，真人明确确认或退回 | Hub ↔ Hub 对应真人项目负责人，再同步测试 | 当前结果与索引 → 人、时间、版本、范围、决定及后续动作 | 未确认不算提交完成；确认不代质量通过；退回补充／必要修复后重确认，满足质量门禁才进验收 | 本次补明向测试同步 | - -### 阶段 7–8、变更与豁免 - -| 节点 | 触发条件 | 责任主体 | 输入 → 输出 | 确认要求与后续流向 | 核对结果 | -|---|---|---|---|---|---| -| F7.1 | F6.12 人工确认及质量门禁满足，资料已交付 | 测试真人直接交产品真人，产品 → Hub | 测试报告及已提供佐证 → 文件名、版本与接收确认 | Hub 留索引不转大文件；收讫不等验收通过，未提供选填件无需补交 | 已覆盖 | -| F7.2–F7.3 | 平台输入就绪，优先组织平台验收 | Hub → 产品 → Hub | 已收测试资料、验收标准及版本 → 平台报告或结论，更新同一遗留清单 | 产品真人确认，不经业务批准；不通过转共用返工 | 已覆盖 | -| F7.4–F7.5 | 客户资料及真人联络条件就绪，不必等平台通过 | Hub → 产品 → Hub | 客户反馈与版本 → 客户报告草案，保留平台问题并标客户来源 | 不虚构客户 Agent 或反馈；可与平台并行，交业务确认 | 已覆盖 | -| F7.6–F7.7 | 客户材料与反馈齐备 | Hub → 业务 → Hub | 客户报告及客户问题 → 通过或整改决定 | 仅确认客户分支；未确认不算客户通过，失败转返工 | 已覆盖 | -| F7.8–F7.9 | 任一验收失败、缺资料或结论需修订 | Hub ↔ 实际责任角色 | 对应问题 → 整改、必要复验、更新分支结论 | 需测试则回阶段 6，新结果重新人工确认；改变版本影响另一分支时亦更新确认 | 本次明确跨分支版本影响 | -| F7.10 | 同对象有效版本的平台与客户均通过 | Hub 登记 | 产品平台确认、业务客户确认、共用清单 → 双线验收基线 | 核对来源、状态、责任和期限；任一未完成不进阶段 8 | 已覆盖 | -| F8.1–F8.3 | 双线通过后收集已有资料并核对承接 | Hub ↔ 实际参与角色、产品及业务 | 有效成果、索引、变更、确认 → 资料／缺口清单及遗留承接 | 不虚构未参与者成果，不重复制作；平台不增加业务重批 | 已覆盖 | -| F8.4–F8.5 | 项目事实和主要问题已整理 | Hub → 实际相关角色 → Hub | 偏差、协作、质量与经验 → 确认的复盘结论、措施、责任人和跟进安排 | 基于事实，汇入流程闭环总结，不增加独立改进成果文件 | 本次补齐改进项承接 | -| F8.6–F8.7 | 收集、验收核对、复盘完成，结项包完整且遗留有承接 | Hub 汇总；业务 → Hub 确认 | 四类结项成果 → 结项决定或补充清单 | 必需缺口未补不关闭；业务确认后锁定归档，关闭并按安排跟进，未来措施不算已执行 | 本次补齐锁定与结项后跟进 | -| X.1–X.3 | 基线变化或阻塞，确认影响正式成果 | 任意角色 → Hub ↔ 实际受影响角色 | 原因、版本、证据、紧急度 → 范围、工期、成本、返工及测试影响 | 各角色内部确认现实承诺；冻结受影响任务，其他任务继续 | 已覆盖 | -| X.4–X.5 | 影响评估齐全，适用授权明确 | Hub ↔ 产品／业务及有权专业角色 | 综合影响与候选基线 → 确认、批准、拒绝或延期记录 | 授权内资源排期产品确认，预算采购承诺业务批准；批准更新基线，拒绝延期维持原基线 | 本次明确决定留档并纠正角色变更泛化 | -| X.6 | 确认或任务超过约定时间 | Hub → 对应角色；项目级组织授权交业务 | 逾期对象、时长、证据、影响、替代方案和新期望时间 → 内部确认回复 | 专属人工确认不改权；未获必要决定仍等待／阻塞，新时间不是延期已获准 | 本次新增明确流程 | -| Y.1–Y.2 | 必需成果主责判断不适用并提出申请 | 主责 → Hub → 主责补正或人工决定 | 原因、证据、替代方案、风险、基线与负责人确认 → 资格及结构检查 | 非主责、无证据、不可豁免不能放行；来不及不等于不适用 | 已覆盖 | -| Y.3 | Hub 已校验汇总申请 | Hub 对应真人项目负责人 → Hub | 申请及影响 → 明确批准／拒绝、人、时间、范围、条件与失效条件 | 不由 AI 决定，不另设已删除的下游征询或业务确认环节 | 已覆盖 | -| Y.4A–Y.4B | 已批准，或拒绝／附加条件未满足 | Hub → 受影响角色或成果主责 | 豁免记录及替代依据，或补交内容／证据／期限 | 保留原必需项；范围或输入基线变更使旧豁免失效；只豁免文件，不取消测试验收门禁 | 本次明确失效及未满足条件分支 | - -## 正式成果及栏目交叉检查 - -- 阶段 1：使用客户里程碑要求，小批量试产、量产选填；不恢复早期风险预检。 -- 阶段 2：立项资料包含平台 SDK、个参资料；项目风险在本阶段形成、由产品持续维护；结构板框图本阶段选填。 -- 阶段 3：测试计划必需、总体技术方案与硬件约束选填；不要求软硬件接口契约、架构决策记录或硬件设计包。 -- 阶段 4：项目计划包含任务拆分与工时评估；不另设产品资料整合，也不重新创建本阶段项目风险成果。 -- 阶段 5：硬件前置器件规格书及结构板框图与四类设计输出分开；BSP／PSP 路径须可访问；定频固件选填；统一应用包保留 zn_debug、MD5、分区、自测、Changelog、串口使能证书等要求。 -- 阶段 6：必需为功能测试报告和缺陷清单；三类报告／佐证选填；删除的是 bug 汇总统计要求，不是用例执行结果、缺陷条目或质量依据；不强制独立专项矩阵、通用证据包或缺陷分析报告。 -- 阶段 7：平台报告或结论二选一、客户验收通过报告、同一遗留问题清单；权限和同版双通过条件一致。 -- 阶段 8：结项资料归档、变更记录、结项报告、流程闭环总结四类；无新增冒烟或发布验证。 - -## 验证与边界 - -- 已执行 Skill Creator 结构校验：通过。 -- 已进行七组独立只读情景核验：普通回归、硬件 ECO 不改固件、不同权限的超时、未来改进与结项、状态纠正、豁免基线失效、零缺陷人工确认。核验指出的硬件 Hook 泛化已收紧为阶段 5 设计确认与阶段 6 回归按需确认的区别，并通过定向复查。 -- 静态检查通过：32 个 Markdown 文件中的 83 处本地链接可解析；8 个 Hook JSON 合法，角色标识、显示名称、字段集合和工具列表未改变；92 个信息流节点全部有核对记录，无遗漏或额外编号；差异空白检查通过；两版 HTML 哈希未改变。上述检查不代替真实 Etunel 项目运行。 -- 未调用真实 Etunel、钉钉、平台测试或客户验收；未改变现有运行项目、已安装 Skill／Hook 或远程 Git。 - -保护文件 SHA256： - -| 文件 | SHA256 | -|---|---| -| V0.15 HTML | `3717DE13267E83E7408342FF25584050BE20167A96EED097577AC4542789EB73` | -| V0.16 HTML | `47695E15051E9C1647A4E5CC18F5BDE17FEED8890FD1649339E77E4ADAF49AC9` | - -本次开始时分支为 `docs/v0.15-next`，HEAD 为 `163f655cd0ac09ccf87adeec0a3fb665ceb01042`。修改保留在工作区，待用户核对后再决定是否提交或推送。 diff --git a/doc/20260907/Codex多角色项目推进总流程图-V0.16.html b/doc/Codex多角色项目推进总流程图.html similarity index 94% rename from doc/20260907/Codex多角色项目推进总流程图-V0.16.html rename to doc/Codex多角色项目推进总流程图.html index 36db9b6..7d55713 100644 --- a/doc/20260907/Codex多角色项目推进总流程图-V0.16.html +++ b/doc/Codex多角色项目推进总流程图.html @@ -5,7 +5,7 @@ - Codex 多角色项目推进总流程图与信息流图谱｜V0.16 REVIEW + Codex 多角色项目推进总流程图与信息流图谱｜V1.0 CURRENT