revert: 恢复至 39ed5a1 文件状态并保留当前 V0.15 流程图

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

@@ -18,89 +18,191 @@ Hub 选择阶段、正式成果、任务波次、门禁或结项时读取。成
 
 ## 阶段 1：业务需求
 
-1. 业务形成《项目背景说明》《客户里程碑要求》，明确业务对象、目标与范围，完成自查及业务负责人确认后提交。
-2. Hub 校验文件、版本、证据与跨来源冲突，将评审版本交产品；仅有形式错误或冲突时退回业务。
-3. 产品与业务经 Hub 澄清并分别确认同一需求基线。确认后 Hub 登记、留档并向产品分发，启动阶段 2。
-4. 不再设置早期风险预检请求、预检任务路由和预检结果回传的固定流程，不把它们作为进入产品定义的条件。
+### 正常任务链
 
-背景说明区分对接客户与最终客户，预期价值、订单及预计销售额为选填，不要求成功指标。客户里程碑包含提测、入库时间，小批量试产和量产时间为选填。客户期望日期不自动成为正式承诺；具体栏目见 [业务职责](roles/business.md)。
+1. 业务形成待评审的业务草案，澄清背景、客户目标、价值、范围、优先级、合作边界、成功指标和目标里程碑。
+2. 产品判断是否需要早期专业风险预审，并精确选择角色、问题和必要输入。
+3. 如需要，Hub 只向产品指定角色派发预审任务，不擅自增删名单；预审只识别约束与风险，不替代后续设计和测试。
+4. 产品整理预审影响，业务负责人确认阶段 1 基线。
 
-门禁：产品与业务确认同一需求基线，形式问题与影响该基线的冲突已处理，产品具备继续定义的输入。
+### 正式成果
+
+- 项目背景说明
+- 项目目标与里程碑计划
+
+早期风险预审记录、客户材料索引和开放项是支持材料，不新增正式门禁成果。客户期望日期只有获得相应授权才成为正式承诺。
+
+### 门禁
+
+有权业务负责人确认项目目标、范围、业务边界和成果版本；开放项、假设和风险如实保留；产品取得足够输入继续定义。
 
 ## 阶段 2：产品定义
 
-1. 产品基于业务基线形成《立项资料》《测试验收标准》《里程碑要求》《项目风险》草案；立项资料纳入平台 SDK、个参资料，具体组成见 [产品职责](roles/product.md)。
-2. 产品明确专业评审角色、问题、范围和期望输出。测试检查产品结果是否可判断；技术负责人组织可行性评估，应用层、底层与硬件按实际影响评估专业约束。
-3. Hub 定向分发同版本资料；各角色返回本领域结论、缺口和风险，不代产品改需求。
-4. 产品汇总专业角色意见，维护《项目风险》（技术风险、时间风险、其他风险），并处理反馈、确认产品基线；业务批准客户范围与验收边界。结构板框图在本阶段选填；后续硬件任务需使用时再补齐，不提前阻塞产品定义。
-5. 测试验收标准包含平台测试用例、客户验收测试用例和验收标准。里程碑要求包含提测、客户验收时间，试产与量产时间为选填。
+### 正常任务链
 
-门禁：产品确认方案、业务批准范围，直接影响产品定义的约束和可判断的验收标准完整；仅属于后续阶段的依赖如实登记。
+1. 产品优先使用阶段 1 基线、项目已确认规则和已有资料，明确产品做什么、不做什么、外部可见行为以及如何判断结果符合要求，形成三类正式成果草案；只补当前阶段确实需要的客户输入，不提前收齐后续设计、实现、测试或生产资料。
+2. 产品在评审请求中明确目标角色、具体问题、关联内容和期望输出。测试检查产品结果是否可判断；技术负责人、应用层、底层和硬件只在产品内容确实涉及本领域约束时参与。影响范围不清时，可先由技术负责人界定相关专业领域，不能因此默认让所有角色全面评估。
+3. Hub 以同一草案版本按产品指定范围定向派发；依赖独立时可以形成波次，但不得自行增加评审对象或专业问题。
+4. 各角色只返回本领域对当前产品定义的可行性、约束、缺口、风险和建议，并说明是否直接影响本阶段完成约定；不代产品改需求，也不把后续阶段的完整资料要求变成当前阻塞。
+5. 测试在本阶段判断预期结果是否清楚、可区分通过与不通过；样机数量、执行轮次、工具和详细环境通常留到《测试计划》或后续测试准备，除非它们本身是已批准的产品承诺。
+6. 产品处置反馈、解决需求冲突并收口产品基线。
+7. 业务批准客户范围、验收边界和需要组织授权的结论。
+
+### 正式成果
+
+- 立项资料
+- 测试验收标准
+- 里程碑要求
+
+客户输入矩阵、平台 SDK、串号、对接资料、功能清单、器件和板框资料在当前产品定义确实需要时，可以作为包内内容或支持输入；不另立旧版开发资料包，也不因后续阶段可能使用而要求阶段 2 全部收齐。
+
+### 门禁
+
+产品行为、范围、异常边界、确有需要的接口期望和可判断的验收结果明确；直接影响当前定义的关键专业约束已处置；产品负责人确认，业务完成范围批准。已经登记的后续依赖不妨碍阶段交接，下一阶段启动后按需取得资料。
 
 ## 阶段 3：方案设计
 
-1. 技术负责人依据产品基线及阶段 2 已有评审结论，提交设计要点、待确认接口约束和风险；不得依赖尚未形成的《项目计划》。
-2. Hub 向相关角色分发设计任务。应用层设计业务模块与应用接口；底层设计 BSP、驱动、RTOS、HAL；硬件约束（器件、PCB、电源、信号、热及接口）为选填，提供时按本领域确认；产品确认需求不偏离。
-3. 测试编制并提交《测试计划》，包含测试标准、测试用例范围、测试项。无问题时 Hub 汇总给技术负责人确认；存在不可测试项或环境、治具缺口时，Hub 先转交相关角色确认，再由测试修订计划并汇总。
-4. 技术负责人确认方案、接口及测试计划；相关角色确认本领域可实施性、可验证性及同一版本关系。
+### 正常任务链
 
-正式成果为《测试计划》和选填的《总体技术方案》。不单列软硬件接口契约或架构决策记录，也不在此阶段要求硬件设计包。必要决定、接口约束及确认保留在已有过程记录中，不能仅换名重新要求独立成果文件。总体技术方案和本阶段硬件约束未提供不阻塞推进，无需豁免；已提供时完成相应版本登记和确认。阶段 5 所需硬件前置输入与设计包不受此选填设置影响。
+1. 技术负责人基于产品基线形成总体方案、接口契约和设计任务草案；方案不得依赖尚未形成的《项目计划》。
+2. Hub 以同一方案和接口版本向适用角色形成设计波次：
+   - 嵌入式应用层：应用架构、模块、状态、应用接口和集成需求；
+   - 嵌入式底层：BSP、Bootloader、驱动、RTOS、HAL 和底层接口；
+   - 硬件：电路、PCB、器件、BOM、电源、信号、热和板卡接口；
+   - 测试：测试计划、环境、策略、覆盖、可测试性和通过标准；
+   - 产品：确认方案没有需求漂移。
+3. 技术负责人处理冲突并收口统一架构、接口和关键决定。
+4. 受影响角色分别确认本领域约束与统一版本一致。
 
-门禁：方案已确认、接口可实施、需求不偏离、测试可验证，测试计划经技术负责人确认；测试仍负责计划编制与维护。
+### 正式成果
+
+- 总体技术方案
+- 软硬件接口契约
+- 硬件设计包
+- 架构决策记录
+- 测试计划
+
+技术负责人主责《总体技术方案》《软硬件接口契约》和《架构决策记录》；硬件主责《硬件设计包》；测试主责《测试计划》。
+
+### 门禁
+
+方案、接口、职责、验证方式、版本和风险形成一致基线；技术负责人确认可用于规划，受影响专业角色和产品完成各自范围确认。
 
 ## 阶段 4：项目规划
 
-1. Hub 基于产品基线和已确认方案形成《项目计划》《角色分工》《项目状态内部记录》，并引用阶段 2 产品维护的《项目风险》。
-2. 项目计划包含任务拆分（工时评估）和实际排期。技术负责人先确认任务技术结构、顺序和依赖。
-3. 仅对有疑点的任务定向询问执行角色的工期、资源、输入输出及风险，不要求全员重新确认整份计划。
-4. 产品确认授权范围内的资源与排期；涉及预算、采购或对外承诺时再由业务批准。
-5. Hub 向相关执行角色分发依赖就绪的任务；确认后的计划与排期可同步业务，不把同步回执当成额外批准门禁。
+### 正常任务链
 
-角色分工明确职责、任务主责与协作、加入退出替换及交接；每项任务只有一个主责角色。不另设《产品资料整合》成果，任务按需引用已有立项资料、方案确认记录和成果索引。项目风险在阶段 2 形成，后续新增风险由相关角色经 Hub 交产品维护，不重新创建阶段 4 风险成果。创建期内部状态在本阶段正式化。
+1. Hub 基于已确认方案形成《项目计划》《项目风险》《角色分工》《产品资料整合》和《项目状态内部记录》草案。
+2. 技术负责人先确认整体任务结构、技术顺序、依赖、角色覆盖、集成关系和关键风险。
+3. 只有具体任务存在缺失、冲突或确需专业估算时，Hub 才定向询问对应执行角色；不要求所有角色重复确认整份计划。
+4. Hub 收口计划和状态记录；业务授权真实人员、资源、采购、成本和正式日期。
+5. Hub 向相关主责角色下发依赖就绪的任务切片。
 
-门禁：技术结构及问题任务已确认，产品确认资源与排期，必要的业务授权完成，首批依赖就绪任务可以执行。
+### 正式成果
+
+- 项目计划
+- 项目风险
+- 角色分工
+- 产品资料整合
+- 项目状态内部记录
+
+项目创建时由 Etunel 提供的角色事实和阶段 1–3 状态在本阶段正式化；完整计划由 Hub 维护，不要求全员查看或重复确认。
+
+### 门禁
+
+每项计划任务有主责角色、输入、输出文件、证据、期限、完成条件和依赖；真实资源与日期状态明确，首批任务可以执行。
 
 ## 阶段 5：软硬件实现
 
-1. Hub 按已确认的产品、方案、项目计划和角色分工，向应用层、底层、硬件分发依赖就绪任务。
-2. 硬件开始设计前取得并核对实际使用的外设和关键器件规格书、结构板框图；缺失时经 Hub 向上游资料责任角色补齐，仅阻塞受影响硬件任务。具体器件清单见 [硬件职责](roles/hardware.md)。
-3. 硬件提交《硬件设计包》：原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义。硬件负责人先确认，再经 Hub 向技术负责人及受影响角色确认和分发。
-4. 不要求单独《硬件实现资料》成果；前置资料是输入，不是硬件产出。版本矩阵、实施或调试事实按实际任务留在已有过程记录，不另立重复交付物。
-5. 底层提交《嵌入式底层实现资料》：硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 设备定频测试固件选填。Hub 登记后将 BSP/PSP 可消费版本交应用层合版。
-6. 应用层形成唯一《嵌入式应用层固件包》，包含正式/升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug文件、Changelog、串口使能证书。
-7. 接口、器件或资源冲突经 Hub 交技术负责人确认；统一固件与硬件候选就绪后联调、核对版本矩阵，应用层提交最终提测固件。
+### 正常任务链
 
-门禁：适用成果齐备，技术负责人确认最终固件与硬件版本匹配且可提测。底层不得直接向测试交最终固件；定频测试固件选填且仅作专项测试工具，不作为正式提测或发布固件。
+1. Hub 按依赖向嵌入式应用层、嵌入式底层和硬件形成一个或多个实现波次。
+2. 各实现角色形成本领域实现成果、版本、自测、证据和负责人确认。
+3. 底层向 Hub 提交可消费的底层版本和集成说明；Hub 交应用层合版。
+4. 应用层解决集成问题并作为唯一出口形成《嵌入式应用层固件包》。
+5. 硬件形成匹配板卡、BOM、ECO、样机和实现资料。
+6. Hub 维护固件、底层、硬件、BOM／ECO、配置和接口匹配关系；技术负责人确认可提测组合。
+
+### 正式成果
+
+- 硬件实现资料
+- 嵌入式底层实现资料
+- 嵌入式应用层固件包
+
+版本矩阵、构建记录和角色自测是必要支持证据，但不新增正式成果类别。底层不得直接向测试提交最终固件。
+
+### 门禁
+
+适用实现成果形成；统一固件与底层、硬件、BOM／ECO、配置和接口版本匹配；技术负责人确认当前组合可交测试。
 
 ## 阶段 6：测试验证
 
-1. 测试接收应用层统一固件、版本矩阵和测试计划，按已批准范围执行并形成结论。
-2. 必需成果：《功能测试报告》《缺陷清单》。选填成果：《可靠性测试报告》《专项测试报告》《提测佐证》；未提供不阻塞推进，无需豁免，已提供时完成相应确认。
-3. 功能报告包含测试结论（通过/不通过）、测试用例执行结果及 bug 的 log 日志。可靠性报告列高低温测试，跌落、防水测试选填；专项报告列适用专项；提测佐证为平台要求的视频、截图、log 材料。
-4. 测试提交《缺陷清单》，不提交独立缺陷分析报告。测试与实际相关角色负责人共同商议解决缺陷的责任人，逐项明确一名责任人、一个主责角色和协作关系。Hub 只登记确认结果并路由，不自行定责。
-5. 实现角色提交原因、修复计划、修复成果和版本、自测与影响。底层修复经应用层重新合版；硬件 ECO 完成底层兼容评估、应用有效性确认及版本矩阵更新。
-6. 测试在目标组合独立复验、维护缺陷状态并给出质量结论；实现角色不得替换或关闭测试的《缺陷清单》。
+### 正常任务链
 
-选填文件不等于可以跳过已批准的必测范围；必需测试结果仍须可追踪，不能把未测写成通过。大文件由测试保管并登记索引，阶段 7 直接交产品，不强制向 Hub 上传。底层实现资料和硬件设计包不列为常规测试输入，不因未附这两类资料拒绝提测；具体测试或定位确需信息时经 Hub 按问题查询，不重新要求整包提交。
+1. Hub 将应用层统一固件、技术负责人确认的版本组合和对应环境基线交测试。
+2. 测试依据《测试计划》和《测试验收标准》执行功能、可靠性、专项和回归验证。
+3. 测试创建并维护《缺陷分析报告》；缺陷由 Hub 向实际责任角色形成修复波次。
+4. 实现角色提交根因分析、修复计划、修复成果、版本、自测和影响，不能替测试关闭缺陷报告。
+5. 底层修复先由应用层重新合版；硬件 ECO 同步完成底层兼容、应用有效性和版本组合确认。
+6. 测试在目标版本组合上独立复验并更新缺陷状态；全部适用验证完成后由测试负责人确认结论。
 
-门禁：阻断缺陷清零，必需成果与测试依据齐全，测试负责人确认质量结论和剩余风险；测试通过不替代验收。
+### 正式成果
 
-## 阶段 7：平台验收与客户验收
+- 功能测试报告
+- 可靠性测试报告
+- 专项测试报告
+- 测试证据包
+- 缺陷分析报告
 
-1. 测试负责人直接交付测试报告及已提供的提测佐证给产品负责人，文件不经 Hub 转发。产品向 Hub 确认接收文件及版本；Hub 只登记索引、确认和交付状态。收到资料不等于验收通过。
-2. 流程先展示平台验收、再展示客户验收；各自输入就绪时可以并行，不把平台完成一律作为客户验收启动条件。
-3. 平台验收由产品组织，依据实际平台结果出具《平台验收报告或结论》，不需要业务批准平台结果。
-4. 客户验收由产品组织，客户反馈由有联络权限的业务或产品真人负责人取得；《客户验收通过报告》须由业务确认。
-5. 产品维护《遗留问题清单》。发现问题时经 Hub 路由实际相关角色，从对应阶段修复或变更，保留两条验收线各自状态。
+质量结论、回归和缺陷证据写入上述适用正式成果，不另立其他测试门禁成果。
 
-总门禁是平台验收通过 + 客户验收通过，两项缺一不可。不能用平台通过、内部测试通过、资料已收或单方确认替代双线通过；问题与风险有明确承接。
+### 门禁
 
-## 阶段 8：资料归档与复盘结项
+测试对象、环境、范围、结果、证据、缺陷、复验和剩余风险可追踪；测试明确给出通过、失败或阻塞。测试通过不替代业务验收。
 
-1. Hub 向实际参与角色收集各阶段有效成果、必要过程记录、变更、项目进度、成果索引及确认。沿用已验收版本，不重复制作同内容资料。
-2. 核对产品确认的平台结果、业务确认的客户结果及遗留问题；不重新给平台结果增加业务批准。
-3. 各角色提交基于事实的复盘输入：目标完成、计划偏差、协作与质量问题、经验和改进建议。Hub 汇入《流程闭环总结》。
-4. Hub 形成《结项资料归档》《变更记录》《结项报告》《流程闭环总结》，业务确认结项。
-5. 本阶段不安排冒烟、发布验证或其他测试，不要求重做发布固件。发现新的实现或质量问题时回到相应阶段处理，不能冒充已完成。
+## 阶段 7：业务验收
 
-门禁：双线验收通过，资料可追踪且归档完整，复盘完成，遗留问题已关闭或落实承接。大文件保留索引与产品接收确认，无需 Hub 重复收存；模拟项目只能记录模拟完成。
+### 正常任务链
+
+1. 产品基于产品基线、平台结果和测试结论组织验收材料、用例、演示或试用和差异处置。
+2. 外部客户不是默认 Etunel 角色；客户输入由业务或产品负责人按联络边界取得，并返回对应角色会话。只有已经定义职责并由 Hub 负责人手动加入 Etunel 的客户角色才可接收任务。
+3. 问题由产品判断为需求理解、实现缺陷、环境问题或正式变更；Hub 只路由实际受影响角色，并从正确阶段返工。
+4. 产品形成验收报告和附条件事项；业务批准验收结论、上线或交付条件和业务风险接受。
+
+### 正式成果
+
+- 平台提测通过报告
+- 客户验收通过报告
+- 附条件验收事项
+
+不适用的平台或客户验收成果按不适用或《成果豁免申请》规则处理，不能用内部测试自动替代。
+
+### 门禁
+
+平台与客户验收证据、差异、附条件事项、责任、期限和业务决定明确；未解决项有处置条件和承接人。
+
+## 阶段 8：发布结项
+
+### 正常任务链
+
+1. Hub 只向实际参与、拥有正式成果、遗留风险或发布责任的角色派发发布或结项任务：
+   - 应用层输出唯一最终发布固件和发布说明；
+   - 底层归档实际被集成的版本和接口信息；
+   - 硬件归档板卡、BOM、生产资料和适用 ECO；
+   - 技术负责人确认最终版本组合与发布技术前提；
+   - 测试对最终组合执行适用发布验证；
+   - 产品确认发布范围与已批准产品和验收一致；
+   - 业务确认交付、合同、授权、客户沟通和遗留责任。
+2. 实际参与角色提交成果索引、未决事项和本角色流程闭环输入；未参与角色说明不适用原因，不创建虚假任务。
+3. Hub 汇总归档、变更、结项报告和流程闭环总结，并完成必要确认。
+
+### 正式成果
+
+- 结项资料归档
+- 变更记录
+- 结项报告
+- 流程闭环总结
+
+### 门禁
+
+正式项目只有在适用交付、验证、批准、阶段文件留档和遗留承接完成后才可关闭。模拟项目只记录“模拟完成”，不得宣称真实发布、客户验收或生产就绪。