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