EP-Hub-Skill/ep-hub/references/project-lifecycle.md

八阶段与结果要求

仅在选择阶段、定义交付结果、判断推进或返工影响时读取相关部分。下列是中心所需的结果边界，角色内部流程由真人自行设计。具体项目沿用其已确认基线；变更先记录并取得有权真人决定。

通用推进规则

• 正常顺序按以下八阶段；每次跨阶段推进由中心真人决定，不因 Agent 判断满足条件自动进入下一阶段。
• 必需成果不能如期交付时，按 异常与决定 记录真人确认、影响和补齐／承接安排。延期不等于交付，跳转不等于通过。
• 选填成果未提交不阻塞、无需豁免；已提供时登记有效版本及专业结论。可靠性、专项、提测佐证是否提交由中心真人决定，沿用已有有效决定。
• 下面的成果名称可由连贯成果包承载，已经有效的同内容成果无需重做。既有记录能够承载专业结论时，不为配齐文件名新增文档。

阶段一：业务需求

• 主责：业务，产品参与需求对齐。
• 成果：一份《业务需求》，包含项目背景和客户里程碑要求。
• 结果内容：区分对接客户与最终客户，明确业务对象、目标、范围；提测、入库时间必需，小批量试产、量产时间选填。预期价值、订单和预计销售额选填，不强制成功指标。客户期望日期与已批准的对外承诺分开。
• 推进依据：业务与产品确认一致的需求基线，相关冲突已处理，产品具备定义输入；中心真人同意推进。不增加固定的早期风险预检。

阶段二：产品定义

• 主责：产品组织，相关专业真人参与。
• 成果：《立项资料》（含风险）、《测试验收标准》、《里程碑要求》。
• 结果内容：立项资料包含立项书、功能清单、产品规格书等；风险在其中维护，不另设《项目风险》。测试验收标准包含平台测试用例、客户验收测试用例及标准。里程碑包含提测、客户验收时间，试产、量产时间选填。结构板框图此阶段选填，硬件任务需要时补齐。
• 推进依据：产品提交专业评审结论与业务对客户范围、验收边界的批准，定义已确认，验收标准可判断，直接影响本阶段的约束已处理；中心真人决定推进。早期人力费用估算不代替后续资源、排期和预算授权。

阶段三：方案设计

• 主责：技术负责人组织方案和接口工作，测试主责编制计划。
• 成果：《测试计划》必需，《总体技术方案》选填。
• 结果内容：测试计划包含标准、用例范围和测试项，由技术负责人认可；方案、接口约束和专业决定可留在已有记录。产品给出需求一致性结论。应用层、底层、硬件按实际任务提供本领域结论。
• 推进依据：方案与接口可实施、需求未偏离、测试可验证，技术负责人确认方案结论及测试计划；中心真人决定推进。不新增独立接口契约、架构决策文件或本阶段硬件设计包，不以尚未形成的项目计划作前提。

阶段四：项目规划

• 组织者：中心真人；技术负责人、产品及执行真人提供评估，Agent 协助汇总。
• 成果：《项目计划》、《角色分工》、《项目状态内部记录》。
• 结果内容：计划含任务拆分、工时评估、实际排期；技术负责人给出技术结构、顺序与依赖结论。分工明确每项任务主责、协作、人员变化与交接，引用立项资料中的风险，不另建风险成果或《产品资料整合》。
• 推进依据：技术结构及问题任务已有结论，产品确认授权范围内资源和排期，预算、采购、对外承诺等必要业务授权完成，首批任务输入与依赖就绪；中心真人决定推进。不要求全员重签整份计划，同步业务的回执不增加批准条件。

阶段五：嵌入式软硬件实现

三个领域各自主责任务，技术负责人提供集成、版本匹配及可提测结论。

主责	成果	结果资料
硬件	硬件设计包	原理图、PCB 源文档、贴片资料（PCBA_BOM、器件位置图 PDF、贴片坐标）、接口定义
嵌入式底层	嵌入式底层实现资料	硬件功能测试报告、BSP 输出路径、PSP 输出路径；WiFi 定频测试固件选填
嵌入式应用层	嵌入式应用层固件包	正式／升级固件、自测用例、分区表、MD5 值文件、Flash 烧写固件、zn_debug 文件、Changelog、串口使能证书

• 硬件设计需要实际外设、关键器件规格书和结构板框图；缺失只影响对应任务，不将前置输入重新列为产出，不另设《硬件实现资料》。
• 底层提供可消费 BSP／PSP，应用层负责合版并交唯一最终提测固件；底层不直接交最终固件给测试，定频固件仅供专项测试。
• 设计、自测、联调由真人自行组织，中心核对提交结果。推进依据：适用成果齐备，最终统一固件和硬件版本匹配，技术负责人明确可提测，中心真人决定推进。

阶段六：测试验证

• 主责：测试，实际需要修复时由对应实现角色主责修复任务。
• 成果：《功能测试报告》必需，含通过／不通过结论、覆盖范围、用例执行结果及 bug log。缺陷信息可提供链接，不要求缺陷清单文件，零缺陷也不另交零缺陷清单。
• 选填：《可靠性测试报告》（高低温，跌落／防水选填）、《专项测试报告》、《提测佐证》（视频、截图、log）。中心真人决定是否提交，未提供不阻塞，仍须执行已约定必测范围；外部平台要求与内部提交决定分开记录。
• 输入与修复：使用统一固件、版本矩阵、测试计划及必要变更说明。底层实现资料、硬件设计包不作为常规必交输入。测试自行制定每次执行、复测和回归策略，不增加独立策略文件或审批。真人商议缺陷责任，每项缺陷一个主责角色和责任人；需修复时中心安排交付任务。底层修复由应用层重新合版，硬件 ECO 随结果交兼容、应用有效性及版本矩阵更新结论，测试独立复验。
• 提交确认：测试真人提交后，中心真人须实际查看并明确确认或退回测试结果；确认前不宣布正式测试提交完成或进入正式验收。实质变化后的结果／被测版本重新确认。
• 推进依据：测试通过并获中心真人确认推进；或测试不通过，但项目与产品双方真人核实后明确同意该版本放行，再由中心记录放行及推进决定。保留原“不通过”，分别记录放行版本、范围、条件、未通过项、责任安排及双方确认。放行不代表外部验收通过。

阶段七：内部／外部验收

• 组织者：项目；内部任务交相应真人，外部平台由产品确认、客户由业务确认。
• 成果：内部验收结果记入已有验收记录；产品汇总《平台验收报告或结论》《客户验收通过报告》及共用《遗留问题清单》，按项目已约定的适用验收范围办理。
• 交接：测试真人直接向产品真人交付已确认最终测试报告及已提供的提测佐证；中心沿用正式成果与确认，产品接收情况放过程记录。链接交付只记地址，不要求中心收转大文件。
• 结果内容：遗留清单标明内部／外部来源、实际验收方、版本、责任人、处置和状态。平台无需业务再次批准；客户报告由产品出具或更新，客户结果由业务确认。各项输入就绪可并行，客户反馈由有联络权限的真人取得。
• 推进依据：约定的内部验收完成，适用外部验收取得对应真人确认；同时要求平台和客户验收时两项均须通过。版本一致、风险有承接，中心真人同意进入结项。内部验收或版本放行不能代替外部结果。
• 返工：回到受影响环节。新测试结果重新执行阶段六的真人确认；仍不通过拟放行时重新取得项目、产品双方结论。版本变化影响其他验收项时更新对应结果。

阶段八：复盘结项

• 组织者：中心真人，各角色提供已有成果及复盘输入，Agent 协助整理，业务保留结项确认职责。
• 成果：《结项资料归档》、《变更记录》、《结项报告》、《流程闭环总结》。
• 结果内容：归档沿用已验收最终版及确认；过程资料包括草稿、旧版、历史确认、变更过程、进度和接收记录，单独保留。复盘说明目标完成、计划偏差、协作与质量问题、经验和改进；改进项写入流程闭环总结，明确责任与跟进，不另设正式成果。
• 关闭依据：约定内部与外部验收已确认，归档可追踪、复盘完成、遗留已处理或落实承接，业务确认结项，中心真人决定关闭。结项必需项完成后锁定四类成果。仍有延期成果时，由中心真人明确补齐或承接安排后决定是否关闭，待交仍写待交，不伪报已归档。
• 本阶段不安排冒烟、发布验证或重做固件；新实现／质量问题回相应环节。开始整理不等于关闭，结项不等于后续改进全部完成；模拟只能记录模拟完成。