Codex 多角色项目推进总流程图与信息流图谱

VERSION / CHANGELOG

版本变更记录

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

版本管理规则：从 V0.8 开始，新版本通过复制当前最新文件创建，禁止覆盖或删除历史版本。每次变更同步更新文件名、页面标题、导航、页脚、本表和项目Hub提示词的当前流程基线引用。

版本号口径：V0.x 用于验证期的角色、阶段、成果、信息流和文档管理调整；当角色责任与八阶段流程稳定且完成整体验证后，再升级为 V1.0。

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

从业务需求到发布结项

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

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

业务需求

主责：业务

明确问题与价值。补齐业务目标、范围、规则、优先级和可度量成功指标。

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

业务确认需求基线

产品定义

主责：产品 · 批准：业务

把目标转成可实现、可验证的产品定义。技术负责人组织可行性评估，嵌入式应用层、嵌入式底层和硬件分别评估实现约束，测试评估可测试性。

正式成果立项资料
立项书：包含产品详细信息、开发模式、开发范围、测试范围及其他补充信息
规格书：包含产品硬件规格和主要元器件型号（主控芯片、Sensor、镜头、WiFi 芯片）
功能清单：定义设备支持的功能
灯态：描述设备上电、绑定、升级、网络断开等状态下的指示灯状态与语音播报内容
产测功能清单：描述产测工具支持项
版本说明：描述当前版本的背景、主要功能等关键信息，并包含该项目此前所有版本和阶段的信息
结构板框图：包含主要器件位置和禁止限制区域测试验收标准
平台测试用例
客户验收测试用例和验收标准里程碑要求
提测时间
客户验收时间
试产、量产时间

产品确认方案，业务批准范围

方案设计

主责：技术负责人 · 协作：嵌入式应用层 + 嵌入式底层 + 硬件 + 测试

基于产品定义和前期可行性评估形成可实施方案。

技术负责人：总体架构、软硬件边界、关键决策嵌入式应用层：业务逻辑、应用协议、功能模块设计嵌入式底层：BSP、驱动、RTOS、HAL 设计硬件：原理图、PCB、BOM、电源/信号/热设计测试：范围、环境、用例、通过标准

正式成果总体技术方案软硬件接口契约硬件设计包架构决策记录测试计划

技术负责人确认整体方案，嵌入式应用层/嵌入式底层/硬件确认接口可实施，产品确认不偏离，测试确认可验证

项目规划

主责：项目Hub

基于已确认的产品基线和方案设计成果，生成实际任务、人员分工、排期和风险计划。任务计划草案先由技术负责人确认；项目Hub只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。

正式成果项目计划
项目任务拆分
实际项目排期项目风险
技术风险
时间风险
其他风险角色分工
Etunel 实际 role 与 display_name
职责边界、任务主责和协作关系
加入、退出、替换与交接要求
每项任务只有一个主责角色产品资料整合
现有器件规格和板框约束
平台 SDK、串号表
平台对接文档
平台接入标准及开发规范
方案设计成果索引
其他项目输入参考资料项目状态内部记录
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限
项目创建期内部状态在阶段 4 正式化

技术负责人确认任务计划，问题任务由对应执行角色定向确认，业务确认实际人员、资源与日期基线

嵌入式软硬件实现

并行：嵌入式应用层 + 嵌入式底层 + 硬件

嵌入式应用层、嵌入式底层和硬件依据已确认的方案设计基线、项目任务计划和角色分工并行实现、样机调试和自测。嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口、任务或器件约束发生重大偏离时返回技术负责人和项目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
串口使能证书

嵌入式底层提交可消费版本，嵌入式应用层合版并提交最终固件，技术负责人确认固件与硬件版本匹配

测试验证

主责：测试 · 修复：嵌入式应用层/嵌入式底层/硬件

执行功能、接口、软硬件集成和回归测试。

不通过应用问题→嵌入式应用层；BSP/驱动问题→嵌入式底层；电路/PCB/器件问题→硬件；接口/架构问题→技术负责人

通过形成五类测试正式成果及质量结论

正式成果功能测试报告
功能、流程、状态、配置、接口、异常与恢复
验收标准追踪
用例状态统计、缺陷、回归和质量结论可靠性测试报告
样本、环境、仪器、时长/循环和负载
高低温、跌落及其他适用项
原始数据、失效、恢复和不可逆变化专项测试报告
画质、Wi-Fi/路由器、SD 卡、功耗、长稳、平台、试产等适用专项
专项矩阵、阈值来源、原始证据和分项结论测试证据包
证据索引和用例/标准映射
原始日志、截图/视频、测量、波形、平台结果和文件校验缺陷分析报告
现象、版本、环境、复现、期望/实际、频率和证据
Severity/风险/优先级、建议责任边界、根因/修复引用、复验与状态

测试确认质量结论和剩余风险

业务验收

主责：产品

依据成功指标、验收标准和质量证据作最终判断。

驳回需求→产品；应用问题→嵌入式应用层；嵌入式底层软件问题→嵌入式底层；硬件问题→硬件；架构问题→技术负责人；证据问题→测试

通过形成正式业务验收结论，进入发布准备

正式成果平台提测通过报告客户验收通过报告附条件验收事项

业务批准验收结论和上线条件

发布结项

项目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

G.2形式校验、跨角色冲突检查、登记并路由不替角色判断专业内容质量

目标角色

G.3完成内部审查后返回结构化结果角色内部确认不单列；禁止转发完整聊天记录

项目Hub

项目进度与按需同步：项目Hub持续维护 项目资料/00-项目管理/项目进度.md，并在对应阶段的《阶段记录》中追加重要事件。创建项目、启动任务波次、接收正式成果、重要退回、阻塞与解除、决定与变更、阶段切换／跳转／回退／暂缓和结项时更新；普通消息、队列状态和空确认不逐条留档。关键变化只向实际受影响角色推送，也响应角色按阶段或任务发起的查询。

任意角色

S.1 · 按需查询请求与本角色职责相关的最新项目状态说清关注阶段或任务、需要的信息和用途

项目Hub

S.2 · 自动或按需生成并分发角色化项目状态快照关键状态变化时主动推送；收到 S.1 后按查询范围返回

请求角色及受影响角色

接收角色

S.3确认状态或携带证据提出纠正不得仅凭口头判断覆盖已登记状态

项目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

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.1	F1.2 条件修订；F1.7 业务确认	F1.3 评审分发；F1.8 正式基线给产品
1 业务需求	项目目标与里程碑计划	业务	F1.1	F1.2 条件修订；F1.7 业务确认	F1.3 评审分发；F1.8 正式基线给产品
2 产品定义	立项资料	产品	F2.2	F2.3–F2.6 专业评审与修订；F2.7–F2.8 业务批准	F3.1 方案设计输入；F4.1 项目规划输入
2 产品定义	测试验收标准	产品	F2.2	F2.3–F2.6 测试评审；F2.7–F2.8 业务批准	F3.7 测试计划输入；F6.1 测试输入；F7.1 验收输入
2 产品定义	里程碑要求	产品	F2.2	F2.3–F2.6 专业评审；F2.7–F2.8 业务批准	F4.1 项目计划输入；S.2 状态同步
3 方案设计	总体技术方案	技术负责人	F3.2	F3.4–F3.8 修订；F3.9–F3.10 确认	F4.1 项目规划输入；F5.1 实现输入；F8.7 归档
3 方案设计	软硬件接口契约	技术负责人	F3.2	F3.4–F3.8 多角色修订；F3.9–F3.10 确认	F4.1 项目规划输入；F5.1 实现输入；F5.7 冲突回溯
3 方案设计	硬件设计包	硬件	F3.3/F3.6	F3.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.7	F3.8–F3.10 多角色确认	F4.1 测试任务规划输入；F6.1 测试任务输入
4 项目规划	项目计划	项目Hub	F4.1	F4.2 技术负责人确认；F4.3–F4.5 定向修订；F4.6–F4.7 业务授权	F4.8 分发相关执行角色；F5.1 实现任务输入；后续由 X 流程变更
4 项目规划	项目风险	项目Hub	F4.1，引用 F1.5–F1.6 预检和阶段3方案风险	F4.2–F4.7 更新与确认；E/X 流程持续更新	F4.8 分发；F5.1 实现风险输入；S.2 按角色同步
4 项目规划	角色分工	项目Hub	F4.1	F4.2 技术负责人确认；F4.3–F4.5 问题任务修订	F4.8 随正式任务分发；F5.1 实现责任输入
4 项目规划	产品资料整合	项目Hub	F4.1	F4.2 技术负责人检查产品与方案输入引用	F4.8 按角色裁剪分发；F5.1 实现输入
4 项目规划	项目状态内部记录	项目Hub	F4.1 初始执行记录	S.3–S.4 证据化纠正；E/X 流程更新	F4.8 初始执行快照；S.2 自动或按需分发
5 软硬件实现	硬件实现资料	硬件	F5.2	F5.7 冲突修订；F5.8–F5.10 版本匹配确认	F6.1 测试输入；F8.3 归档
5 软硬件实现	嵌入式底层实现资料	嵌入式底层	F5.4	F5.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.2	F6.3–F6.9 缺陷/回归更新；F6.10 确认	F7.1 验收输入；F8.7 归档
6 测试验证	可靠性测试报告	测试	F6.2	F6.3–F6.9 缺陷/回归更新；F6.10 确认	F7.1 验收输入；F8.7 归档
6 测试验证	专项测试报告	测试	F6.2	F6.3–F6.9 缺陷/回归更新；F6.10 确认	F7.1 验收输入；F8.7 归档
6 测试验证	测试证据包	测试	F6.2	F6.3–F6.9 持续补证；F6.10 完整性确认	F7.1/F7.3 验收证据；F8.5 最终证据
6 测试验证	缺陷分析报告	测试	F6.2/F6.3	F6.4–F6.9 责任角色修复并由测试回归；F6.10 确认	F7.1 验收限制输入；F8.7 归档
7 业务验收	平台提测通过报告	产品	F7.2	F7.3–F7.7 验收与修订；F7.8 业务确认	F8.6 结项核对；F8.7 归档
7 业务验收	客户验收通过报告	产品	F7.2	F7.3–F7.7 客户/业务验收与修订；F7.8 业务确认	F8.6 结项核对；F8.7 归档
7 业务验收	附条件验收事项	产品	F7.2/F7.4	F7.6–F7.8 补充责任角色、期限并确认	F8.6 关闭或承接；写入结项报告
8 发布结项	结项资料归档	项目Hub	F8.7–F8.8	F8.1–F8.7 汇集输入；F8.9 完整性确认	项目关闭后锁定归档
8 发布结项	变更记录	项目Hub	X.1–X.5 持续记录；F8.8 汇总	每次变更决定更新；F8.9 结项检查	随结项资料归档锁定
8 发布结项	结项报告	项目Hub	F8.8	F8.4–F8.7 提供输入；F8.9 业务确认	项目关闭依据与归档入口
8 发布结项	流程闭环总结	项目Hub	F8.8	F8.7 角色摘要输入；F8.9 业务确认	经验复用与后续案例检索

01 / BUSINESS

阶段 1：业务需求信息流

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

主责业务

核心成果项目背景说明、项目目标与里程碑计划

门禁业务完成内部审查并确认需求基线

业务完成原始信息收集、成果自查和负责人确认后，以统一的“业务”主体提交成果。项目Hub完成文件、版本、证据和跨角色冲突检查后，将业务成果评审版本路由给产品；产品据此判断是否需要早期风险预检，并负责指定一个或多个预检对象角色。项目Hub只能按照产品给出的角色名单路由，不得自行增删或替换。业务最终确认后，项目Hub先留档，再向产品分发正式业务基线并开启产品定义。

业务

F1.1提交完成内部审查的项目背景与里程碑草案附负责人确认、来源引用和实际成果文件

项目Hub

F1.2 · 条件触发仅在发现形式错误或跨来源冲突时返回问题触发范围仅限文件结构、版本、证据和已登记信息冲突；无异常则不启用此流

业务

项目Hub

F1.3分发已通过形式校验的业务成果评审版本附成果版本、证据引用、状态和待确认项

产品

F1.4指定对象角色并提交早期风险预检请求产品根据风险内容选择一个或多个专业角色

项目Hub

F1.5按产品指定名单校验、提醒并路由预检任务主动提醒全部关联角色；不得增删产品指定名单

产品指定的对象角色

F1.6返回内部确认结果；复杂问题返回统一会议结论无法异步收敛时，由产品组织线下会议并按 E.3 回传

项目Hub

业务

F1.7确认需求基线业务内部审查、形式校验和预检问题均已关闭

项目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

F2.3校验请求并并行路由专业评审按产品指定范围裁剪上下文，不新增专业问题

技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试

评审角色

F2.4返回可行性、缺口和约束每条意见必须关联具体成果字段

项目Hub

F2.5汇总跨角色冲突并返回产品裁决/修订项目Hub只指出冲突，不替产品作内容决定

产品

F2.6提交内部确认后的产品方案关闭评审问题并标明保留风险

项目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

F3.3并行分发角色化设计任务每个角色在同一契约版本上工作

产品 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试

嵌入式应用层

F3.4提出 HAL、资源和应用接口需求接口新增或资源不足时触发

项目Hub → 嵌入式底层 / 技术负责人

嵌入式底层

F3.5提出引脚、电平、时序和器件约束HAL 与硬件设计存在依赖时

项目Hub → 硬件 / 技术负责人

硬件

F3.6反馈器件、PCB、电源、空间与热约束影响接口、成本或性能时

项目Hub → 技术负责人 / 嵌入式底层 / 产品

测试

F3.7提交不可测试项和环境/治具缺口验收标准无法验证时

项目Hub → 相关角色

项目Hub

F3.8汇总冲突并要求总体方案修订形成决策清单和待关闭问题

技术负责人

F3.9提交内部确认的最终方案和契约基线所有阻塞问题关闭后

项目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

F4.3 · 问题任务仅对存在疑点的任务发起定向确认缺少责任、输入输出、依赖、估算、资源、日期、证据或存在冲突时触发

对应执行角色

F4.4只确认被询问任务的工期、资源和风险不得要求执行角色重复确认整份任务计划

项目Hub

F4.5提醒关联角色并协调剩余冲突、重排计划问题仍未关闭或日期不可达时按 E.1–E.4 处理

技术负责人及受影响角色

项目Hub

F4.6请求资源与日期基线授权真实人员、采购、打样、成本和日期由业务内部确认

业务

F4.7批准或要求调整资源与日期基线记录内部批准状态、范围和条件

项目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。

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

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

并行主责嵌入式应用层、嵌入式底层、硬件

核心成果硬件实现资料、嵌入式底层实现资料、嵌入式应用层提交的统一固件包

门禁嵌入式应用层提交最终固件，技术负责人确认固件与硬件版本匹配并可提测

项目Hub

F5.1并行下发三类实现任务附方案设计基线、项目任务计划、角色分工、风险和任务边界

嵌入式应用层 / 嵌入式底层 / 硬件

硬件

F5.2提交板卡、BOM、接口与样机版本硬件发布或 ECO 时触发

项目Hub

F5.3向受影响角色定向分发硬件版本及约束变化只向实际受影响角色分发完整影响包

技术负责人 / 嵌入式底层 / 嵌入式应用层 / 测试

嵌入式底层

F5.4提交可消费的底层实现包包含 BSP/PSP、Bootloader、驱动、RTOS、HAL，并绑定板卡、BOM/ECO、工具链、配置和契约版本

项目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

F6.3按测试建议或专业裁决路由缺陷责任明确时定向路由；跨层问题交技术负责人，需求含义交产品

产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试

责任角色

F6.4返回内部确认的原因分析、修复计划和影响范围正式修复承诺在角色内部确认后统一发出

项目Hub

F6.5创建修复或技术裁决任务跨层问题交技术负责人，需求问题交产品

责任角色

F6.6提交应用修复、底层修复或硬件 ECO必须生成新版本并声明替代关系和影响范围

项目Hub

F6.7将固件相关修复交给嵌入式应用层重新合版底层修复必须合版；硬件变化由嵌入式应用层确认固件兼容性

嵌入式应用层

F6.8提交统一回归固件或确认原固件继续有效最终回归固件仍只能由嵌入式应用层提交

项目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

F7.3向业务发起验收确认呈现目标、证据、风险和附条件项；客户反馈由业务或产品负责人按边界线下取得

业务

F7.4返回通过、驳回或附条件通过整理必要的客户反馈；驳回必须描述场景和证据

项目Hub

F7.5分类并路由验收问题需求/嵌入式应用层/嵌入式底层/硬件/架构/证据

产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试

责任角色

F7.6提交修正、说明或风险处置形成新成果版本或正式解释

项目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

F8.4请求发布冒烟与最终验证使用最终版本矩阵

测试

F8.5提交冒烟结果和最终证据失败立即停止发布/结项

项目Hub

F8.6核对验收条件与遗留事项附条件项必须关闭或有承接

产品/业务

全部角色

F8.7提交内部确认的结项摘要和资料索引禁止只提供聊天记录

项目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

X.2冻结受影响任务并并行征询影响产品/技术负责人/嵌入式应用层/嵌入式底层/硬件/测试

产品 / 技术负责人 / 嵌入式应用层 / 嵌入式底层 / 硬件 / 测试

评估角色

X.3返回内部确认的范围、方案、工期、成本和测试影响现实承诺由角色内部确认后统一发出

项目Hub

X.4提交综合影响和建议列出批准/拒绝/延期的差异

业务

X.5批准或拒绝变更内部授权后生成新基线，不覆盖旧版本

项目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

Y.2校验发起资格与可豁免性非主责角色、无证据或不可豁免成果直接退回

主责角色

项目Hub

Y.3向下游角色征询影响成果有下游消费者、接口或验收影响时触发

受影响角色

Y.4返回同意、反对或附条件意见必须说明替代证据和门禁影响

项目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 → 主责角色	拒绝理由、必须生成的成果、补充证据和期限。	主责角色仍须输出正式文件。	仍需该成果，阶段继续阻塞。