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

从业务需求到发布结项

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

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

业务需求

主责：业务

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

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

业务确认需求基线

产品定义

主责：产品 · 批准：业务

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

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

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

项目规划

主责：中心 AI

基于成果、成员能力和依赖自动编排任务、进度和风险。任务计划草案先由技术负责人确认；中心 AI 只对存在疑点的任务定向询问对应执行角色，真实资源和日期基线再提交业务确认。

正式成果Project Plan（项目计划）
项目任务拆分
实际项目排期Risk Register（项目风险）
技术风险
时间风险
其他风险Role Assignment（角色分工）Product Documentation Package（产品资料整合）Project Status Record（项目状态内部记录）
阶段与门禁
任务与依赖
阻塞与风险
决策与成果基线
下一步与时限

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

方案设计

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

技术负责人统一组织总体方案设计和确认。

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

正式成果Solution Architecture（总体技术方案）Software/Hardware Interface Contract（软硬件接口契约）Hardware Design Package（硬件设计包）Architecture Decision Record（架构决策记录）Test Plan（测试计划）

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

嵌入式软硬件实现

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

嵌入式应用层、嵌入式底层和硬件在已确认总体方案及软硬件接口契约下并行实现、样机调试和自测。嵌入式底层将可消费版本交给嵌入式应用层合版，嵌入式应用层负责生成并提交唯一的最终固件版本；接口或器件约束发生重大偏离时返回技术负责人确认。

正式成果Hardware Implementation Package（硬件实现资料）
原理图：DSN 源文档和 PDF 文档
PCB：源文档
贴片资料：PCBA BOM、器件位置图 PDF、贴片坐标
维修原理图
接口定义
静态测试报告Low-Level Implementation Package（嵌入式底层实现资料）
硬件功能测试报告
BSP 输出路径
PSP 输出路径
WiFi 设备定频测试固件Application Firmware Package（嵌入式应用层固件包）
正式固件、升级固件
自测用例
分区表
MD5 值文件
Flash 烧写固件
日志文件
Changelog
串口使能证书

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

测试验证

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

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

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

通过质量报告 + 测试证据包

正式成果Functional Test Report（功能测试报告）
平台测试用例
内部测试用例Reliability Test Report（可靠性测试报告）
高低温测试
跌落测试Specialized Test Report（专项测试报告）
画质测试
WiFi 测试
功耗测试
长稳测试
试产一致性测试Test Evidence Package（提测佐证）Defect Analysis Report（缺陷分析报告）

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

业务验收

主责：产品

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

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

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

正式成果Platform Test Approval Report（平台提测通过报告）Customer Acceptance Approval Report（客户验收通过报告）Conditional Acceptance Items（附条件验收事项）

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

发布结项

中心 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

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

目标角色

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

中心 AI

项目状态内部记录与按需同步：Project Status Record（项目状态内部记录）是中心 AI 持续维护的内部运行记录，不是新增角色。它汇总当前阶段、门禁、任务、依赖、阻塞、风险、决策、成果基线、下一步和时限；中心 AI 在关键状态变化时主动推送，也响应角色按项目、阶段或任务发起的查询。

任意角色

S.1 · 按需查询请求与本角色职责相关的最新项目状态指定 project_id、stage/task scope、关注项和期望时点

中心 AI

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

请求角色及受影响角色

接收角色

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

中心 AI

S.4 · 状态纠正校验依据、更新内部记录并重新分发保留旧状态、变更原因、证据引用和生效时间

全部受影响角色

ID	触发条件	发送 → 接收	正式载荷	约束/确认	对项目执行的影响
S.1	角色需要了解当前项目、阶段、任务、依赖、风险或门禁状态，但现有上下文不足或可能已过期。	任意角色 → 中心 AI	project_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	角色收到状态快照。	接收角色 → 中心 AI	ACK；或 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

E.4校验、登记结论并恢复原异常流程只恢复被阻塞的原流程，不以会议记录替代正式成果

原流程及关联角色

ID	触发条件	发送 → 接收	正式载荷	约束/确认	对原流程的影响
E.1	条件流或阻塞流被触发；出现跨角色冲突、依赖异常、证据矛盾、任务逾期或结果无法被下游使用。	中心 AI → 当前主责角色及全部关联角色	issue_id、source_flow_id、问题摘要、证据与版本引用、冲突点、影响范围、关联角色、required_by。	中心 AI 必须主动提醒，不得只更新状态；关联角色依据正式问题包开展异步确认。	原流程保持 ACTIVE/BLOCKED，等待问题关闭。
E.2	涉及多个专业角色且结论冲突，影响范围/架构/接口/成本/进度/质量，或在要求时限内无法通过异步消息收敛。	中心 AI → 当前主责角色及关联角色	建议参会名单、会议目的、议题、冲突矩阵、证据包、待决策项、结论模板和完成时限。	中心 AI 只建议会议和准备输入，不主持专业裁决；当前主责角色负责组织，关联角色共同参与确认。	会议结论回传前，不恢复原流程。
E.3	线下会议完成并形成统一结论。	当前主责角色 → 中心 AI	Meeting 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

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

业务

中心 AI

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

产品

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

中心 AI

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

产品指定的对象角色

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

中心 AI

业务

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

中心 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	业务内部审查、中心形式校验和预检问题均已关闭。	业务 → 中心 AI	INTERNALLY_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

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

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

评审角色

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

中心 AI

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

产品

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

中心 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

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

对应执行角色

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

中心 AI

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

技术负责人及受影响角色

中心 AI

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

业务

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

中心 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。

阶段 4：方案设计信息流

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

主责技术负责人

核心成果总体技术方案、软硬件接口契约、硬件设计包、架构决策、测试计划

门禁方案确认、接口可实施、需求不偏离、测试可验证

中心 AI

F4.1下发总体方案设计任务附产品基线、计划、风险和所有约束

技术负责人

F4.2提交总体方案与接口契约草案含边界、关键决策、非功能和风险

中心 AI

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

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

嵌入式应用层

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

中心 AI → 嵌入式底层 / 技术负责人

嵌入式底层

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

中心 AI → 硬件 / 技术负责人

硬件

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

中心 AI → 技术负责人 / 嵌入式底层 / 产品

测试

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

中心 AI → 相关角色

中心 AI

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

技术负责人

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

中心 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

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

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

嵌入式底层

F5.4提交 BSP/PSP、驱动与测试固件带板卡、HAL 和接口契约版本

中心 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

F6.3分类并路由缺陷嵌入式应用层/嵌入式底层/硬件/架构/需求/测试环境

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

责任角色

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

中心 AI

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

责任角色

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

中心 AI

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

嵌入式应用层

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

中心 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	阻断缺陷清零且证据齐全。	测试 → 中心 AI	INTERNALLY_APPROVED 质量报告和剩余风险。	测试内部确认状态必须记录；剩余风险必须有接受方。	门禁通过后开启验收。

07 / ACCEPT

阶段 7：业务验收信息流

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

主责产品；中心 AI 组织；业务批准

核心成果平台提测通过报告、客户验收通过报告、附条件事项

门禁业务完成内部确认并提交验收及上线条件

中心 AI

F7.1下发验收组织任务和证据包测试门禁通过后

产品

F7.2提交平台/客户验收资料引用测试证据、版本和已知限制

中心 AI

F7.3发起验收确认呈现目标、证据、风险和附条件项

业务/客户

F7.4返回通过、驳回或附条件通过驳回必须描述场景和证据

中心 AI

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

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

责任角色

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

中心 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

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

测试

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

中心 AI

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

产品/业务

全部角色

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

中心 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

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

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

评估角色

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

中心 AI

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

业务

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

中心 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

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

主责角色

中心 AI

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

受影响角色

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

中心 AI

Y.5请求业务确认高影响豁免影响范围、架构、质量、安全、客户验收或外部承诺时

业务

中心 AI

Y.6批准或拒绝成果豁免汇总证据、下游意见和必要人类确认

成果登记与门禁

中心 AI

Y.7A批准：标记 WAIVED 并分发豁免记录门禁将 WAIVED 视为已满足，但保留完整审计

全部受影响角色

中心 AI

Y.7B拒绝：成果保持 REQUIRED返回主责角色生成文件或补充证据

成果主责角色

ID	触发条件	发送 → 接收	正式载荷	约束/确认	门禁与版本结果
Y.1	主责角色判断某个阶段成果在本项目范围、架构或交付模式下不适用。	主责角色 → 中心 AI	artifact_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，阶段继续阻塞。