feat: 按 V2.1 更新中心 Skill、流程图与项目记录模板

ep-hub/references/project-lifecycle.md

@@ -4,7 +4,7 @@
 
 ## 通用推进规则
 
-- 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。
+- 正常顺序按以下八阶段；每次跨阶段须有中心真人决定。已有条件授权实际满足时，按原范围执行并记录授权、条件依据和实际切换日期，不重复申请；无授权时不因 Agent 判断满足条件自动推进。详见 [阶段汇报与推进决定](stage-reporting.md)。
 - 必需成果不能如期交付时，按 [异常与决定](exceptions-and-decisions.md) 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
 - 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
 - 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。
@@ -32,10 +32,10 @@
 
 ## 阶段四：项目规划
 
-- **组织者**：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。
+- **组织者**：中心真人负责总排期与跨角色资源协调；技术负责人、产品及执行真人按职责提供评估，Agent 协助汇总。
 - **成果**：《项目计划》、《角色分工》、《项目状态内部记录》。
-- **结果内容**：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
-- **推进依据**：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。
+- **结果内容**：先交接全部有效产品需求，再由应用层、底层和硬件分别评估范围、已有成果、剩余工作、工时、周期、投入及等待。初版与后续迭代分开，技术负责人核实范围、先后、并行、合版和依赖后交测试衔接周期；测试可先估自身工作量。评估沿原任务留表，具体字段、八列唯一计划主表和执行更新见 [工时、周期与项目计划](project-planning.md)。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
+- **推进依据**：技术结构及问题任务已有结论，中心真人统筹的整体排期和跨角色资源安排已明确，产品确认具体授权范围内的资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。产品不默认承担全部专业和工厂周期，不要求全员重签整份计划，同步业务的回执不增加批准条件。
 
 ## 阶段五：嵌入式软硬件实现
 
@@ -48,7 +48,9 @@
 | 嵌入式应用层 | 嵌入式应用层固件包 | 正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书 |
 
 - 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
+- 软硬件、环境或样机缺失只阻塞依赖它的工作，其他输入就绪的任务继续。到样、系统、PQ、AI 和环境状态取自真人实际回报，不按计划日期推定，也不把收到输入写成后续工作已完成。
 - 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
+- PSP 仓库／commit、BSP 构建及输入入口不等于最终固件身份，不将其他构建结果移用于最终包。现有配置中已有有效 BSP 消费入口，且真人确认无需另行获取时，直接沿用。已知包身份和入口交相关真人确认可用，Agent 无法访问不构成重做或反复上传的理由。
 - 设计、自测、联调由真人自行组织，中心核对提交结果。**推进依据**：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。
 
 ## 阶段六：测试验证
@@ -56,8 +58,8 @@
 - **主责**：测试，实际需要修复时由对应实现角色主责修复任务。
 - **成果**：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，**不要求缺陷清单文件，零缺陷也不另交零缺陷清单**。
 - **选填**：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
-- **输入与修复**：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
-- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。
+- **输入与修复**：每轮明确统一固件和硬件版本、版本矩阵、测试计划、变更、必测范围、期限及提交要求。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
+- **提交确认**：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前记录“已提交，待确认”，不写未提交，也不宣称已确认完成或进入正式验收。实质变化后的结果／被测版本重新确认。
 - **推进依据**：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。
 
 ## 阶段七：内部／外部验收
@@ -65,14 +67,19 @@
 - **组织者**：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
 - **成果**：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
 - **交接**：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
+- **执行分工**：联系平台、发包寄样、收件和跟进按具体项目明确唯一主责，不默认全部由产品或中心本人执行。实际协调、接收可用、平台结果和业务客户确认分别记录。
 - **结果内容**：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
 - **推进依据**：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
 - **返工**：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。
+- 共用遗留记录延续到阶段八的 Bug 双方确认，不给测试追加重复缺陷清单。
 
 ## 阶段八：复盘结项
 
 - **组织者**：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
 - **成果**：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
-- **结果内容**：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
-- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
+- **结果内容**：归档沿用已验收最终版及确认，逐项包含全部有效资料、配套资料或完整外部入口，不能只给目录或确认记录。阶段管理起止及依据写入既有《结项资料归档》，提交、采用、确认和工程实际日期分别记录，参见 [归档栏目](../assets/templates/结项资料归档.md)。过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
+- **成果格式**：结项报告及汇总沿用项目已确认格式；单工作表 Excel 只是可参考形式，不强制各项目采用同一表或字段。缺少工时、迭代、评审或签名时保留未知，不从文件数量推算或补造。
+- **Bug 处理**：覆盖全部 Bug，包括已处理及后续发现项。中心真人先确认事实和实际处理／承接，产品真人再次确认并在职责内决定处理，双方无异议后登记最终确认；复用有效确认。具体顺序和字段见 [Bug 双方确认](exceptions-and-decisions.md#bug-处理与双方最终确认)。
+- **关闭依据**：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，Bug 处理或承接已取得中心及产品双方确认，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
 - 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。
+- **关闭后**：按 [中心工作流](hub-workflow.md#关闭后的同步) 同步全部相关记录、锁定有效成果、停止重复催办并按授权发送一次结项总结。队列待送和工具未结算另记，不撤销真人关闭或重派业务任务；失败测试、未修复 Bug 和后续责任如实保留，不据此声称量产出货。