151 lines
15 KiB
Markdown
151 lines
15 KiB
Markdown
# 成果与完成判定
|
|
|
|
Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读取。具体职责和上下游见 [项目生命周期](project-lifecycle.md) 与当前角色契约。
|
|
|
|
## 正式成果集合
|
|
|
|
人工可读的正式成果统一使用以下中文名称：
|
|
|
|
| 阶段 | 正式成果 |
|
|
|---|---|
|
|
| 1 业务需求 | 项目背景说明；客户里程碑要求 |
|
|
| 2 产品定义 | 立项资料（含平台 SDK、个参资料）；测试验收标准；里程碑要求；项目风险 |
|
|
| 3 方案设计 | 测试计划；总体技术方案（选填） |
|
|
| 4 项目规划 | 项目计划；角色分工；项目状态内部记录 |
|
|
| 5 软硬件实现 | 硬件设计包；嵌入式底层实现资料；嵌入式应用层固件包 |
|
|
| 6 测试验证 | 功能测试报告；缺陷清单；可靠性测试报告（选填）；专项测试报告（选填）；提测佐证（选填） |
|
|
| 7 平台/客户验收 | 平台验收报告或结论；客户验收通过报告；遗留问题清单 |
|
|
| 8 复盘结项 | 结项资料归档；变更记录；结项报告；流程闭环总结（项目复盘） |
|
|
|
|
不单列软硬件接口契约、架构决策记录、硬件实现资料、产品资料整合、测试证据包或缺陷分析报告。项目风险由产品在阶段 2 汇总并维护，相关专业角色提供风险意见，后续阶段引用而非重复创建。必要接口确认、技术决定、实施或调试事实留在已有过程记录及实际成果中，不通过改名重新增加独立交付物。具体内容和责任见 [项目生命周期](project-lifecycle.md) 及对应角色职责。
|
|
|
|
选填成果和选填栏目未提交不阻塞阶段推进，无需另行豁免；已提交时仍需版本登记和相关负责人确认。阶段 3 的硬件器件、PCB、电源/信号/热及接口约束为选填；阶段 5 硬件输入及设计包仍按本阶段要求交付。WiFi 设备定频测试固件亦为选填，仅用于专项测试。已批准的必测范围仍需执行，文件选填不能用来掩盖未验证结论。只有仍属必需的成果需要不适用/豁免时，才走后述豁免流程。
|
|
|
|
角色额外材料不能替代必需正式成果，也不能自动成为门禁。功能测试报告写测试结论（通过/不通过）、用例执行结果和 bug log；无法形成结论时说明阻塞，不伪造通过。缺陷由测试维护在《缺陷清单》中，责任人由实际相关负责人共同确认。
|
|
|
|
## 测试选填材料的提交决定
|
|
|
|
《可靠性测试报告》《专项测试报告》《提测佐证》保持选填，由项目负责人（项目Hub对应真人负责人）确认是否提交，Hub 登记决定和适用范围并同步测试、产品；已有仍有效的决定直接沿用，不为每个任务重复询问。未确认时只标明提交选择待确认，不由 AI 默认为必交或擅自批准不交，不新增阶段门禁或独立审批文件。
|
|
|
|
决定不提交时，不因缺少这三类文件阻塞推进或要求另行豁免；决定提交时按约定交付并核对实际版本、负责人确认与接收状态，不把尚未提供写成已收。此规则只针对这三类测试成果，不扩大为所有选填栏目均须审批。
|
|
|
|
平台模板中的“必填截图”“提交长稳报告”等文字，不自动升级为内部通用提交门禁；测试说明实际平台要求及影响，经 Hub 取得上述真人决定。决定是否提交材料不等于平台已接受、验收已通过，也不能免除已批准的必测范围或必要质量依据。正式测试结果仍走下文的项目负责人确认。
|
|
|
|
## 先定义产出要求
|
|
|
|
正式执行任务的产出和完成条件只来自“本阶段必须完成”的内容。后续阶段处理和当前不需要的内容可以登记，但不能自动成为当前成果、任务完成条件或门禁。“本阶段完成约定”不能替代正式成果的适用性判断、受控跳转或《成果豁免申请》。派发时明确：
|
|
|
|
1. 正式成果或成果包名称及唯一主责角色；
|
|
2. 每项最低内容、适用子项和协作边界；
|
|
3. 输入基线、版本、旧版替代关系和可追踪引用；
|
|
4. 所需证据及未执行验证应如何说明；
|
|
5. 下游用途、期限和可以检查的完成条件；
|
|
6. 本角色必须给出的专业结论；
|
|
7. 专业自审和负责人确认要求。
|
|
|
|
任务要求和实际产出必须一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需来源清楚、经有权角色确认且结论明确。
|
|
|
|
## 正式结果最低内容
|
|
|
|
不强制所有角色填写复杂 JSON，但正式结果必须让 Hub 找到：
|
|
|
|
- 当前阶段和使用的输入基线；
|
|
- 实际完成内容和期限状态；
|
|
- 成果中文名称、文件位置或附件、版本和旧版替代关系；
|
|
- 每项完成条件对应的证据；
|
|
- 不适用项、未执行项、开放问题、依赖和剩余风险；
|
|
- 本角色明确结论：满足、部分满足或无法满足；
|
|
- 专业自审结果；
|
|
- 负责人、确认时间、确认范围和附带条件。
|
|
|
|
一句“已完成”“没问题”或“测试通过”不能关闭任务。运行时消息标识由 Etunel 工具关联，不进入成果正文。
|
|
|
|
## 状态分层
|
|
|
|
以下层级彼此独立：
|
|
|
|
1. 项目运行模式；
|
|
2. 任务执行结果；
|
|
3. 成果生命周期；
|
|
4. 成果适用性；
|
|
5. 阶段与门禁；
|
|
6. 测试结论（通过/不通过；无法判定时单独说明阻塞状态）；
|
|
7. 业务验收结论；
|
|
8. Etunel 消息或钉钉通知状态。
|
|
|
|
任务成功不等于成果已经成为基线；成果存在不等于门禁满足；测试通过不等于业务验收；消息已处理或钉钉已接受不等于项目完成。机器记录可以保留运行时枚举，但面向负责人时使用中文解释。
|
|
|
|
## 任务包与多任务
|
|
|
|
- 同一角色、同一基线、紧密相关且共同交付的成果可以组成一个任务包；全部必需产出满足才算完成。
|
|
- 能独立验收、失败或服务不同依赖的工作保持独立任务，即使在同一波次发送。
|
|
- 包内有效成果保留，未完成部分可以拆成后续任务；一个子项失败不能被其他成功掩盖。
|
|
|
|
## 专业自审和人类确认
|
|
|
|
自审结果说明角色如何按任务要求检查产出，可以是“通过”“部分通过”或“未通过”，并列出依据与例外。
|
|
|
|
负责人确认表示当前负责人实际查看本次结果并确认可以作为该角色正式提交。Hub 以 `etunel_list_roles` 返回的 `member_alias` 作为该角色实际负责人身份，不再要求额外人员 ID 或二次身份核对；该负责人可在当前角色会话或钉钉中明确确认。至少记录确认人、时间、文件或版本、范围和附带条件。通知送达、已读或仅被 @ 不构成批准。AI 不得自行声称已获确认；模拟项目只确认模拟材料的使用和流程推进，不证明模拟值真实。
|
|
|
|
负责人确认随对应文件、版本、适用范围和附带条件继续有效。Hub 归档、移动或引用同一成果不需要重新确认；只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。另一角色对该成果作新的专业评估时，仍须取得该角色自己的负责人确认。
|
|
|
|
## 测试结果的项目负责人确认
|
|
|
|
测试专业结论、测试结果提交完成、正式验收准入是三个不同判断。测试负责人确认专业结果后，还必须由 Hub 请求项目负责人（项目 Hub 对应的真人负责人）实际确认；此人不是新增 Agent 角色，不能由 Hub AI、测试 AI 或通知状态代替。
|
|
|
|
1. 测试执行完成，阻断缺陷清零、必需成果与测试依据齐全、剩余风险有接受方，并完成专业自审及测试负责人确认后，向 Hub 返回功能测试报告、缺陷清单及已提供的选填成果信息（F6.10），标记“待项目负责人确认”，不宣称正式提交完成。大文件保留可查索引，不因人工确认而增加整包上传要求。
|
|
2. Hub 核对当前版本、必需成果、质量结论和剩余风险，再请求自己的真人负责人确认（F6.11）。记录真实的确认或退回意见（F6.12），包括确认人、时间、成果与被测版本、范围、附带条件和可查依据，并向测试同步登记结果及后续动作。
|
|
3. 明确确认且完成登记后，才算该版本测试结果提交完成；仍须满足测试质量门禁，才能进入正式平台/客户验收。人工确认不能将不通过改成通过，不能取消必测范围、缺陷复验或双线验收。
|
|
4. 未回复、仅送达、已读、测试负责人单方确认、工具显示任务完成或协调消息结算，都不算此人工确认。Hub 保持“待项目负责人确认”，不伪造已批准；这不是 Etunel 的新机器枚举。
|
|
5. 被退回时，测试补充材料，必要时回到相关修复、合版与独立复验，再重新提交确认。测试结果或被测版本实质变化必须重新经过 F6.10–F6.12；旧确认不能覆盖新版本。相同版本、范围与条件的有效确认可追踪复用，不为索引移动或排版重复审批。
|
|
6. 测试已完成且无缺陷时，从 F6.2 直接到 F6.10，再经过 F6.11–F6.12；仍提交功能测试报告和零缺陷清单，不创建无必要的修复任务。无缺陷不等于未执行必测项也可跳过。
|
|
7. 在最终确认前，可以依据真实的阶段性结果协调缺陷与修复，但不得据此宣布最终提交完成或正式进入验收。工具使用和技术任务结算见 [Etunel 任务消息流程](etunel-message-lifecycle.md)。
|
|
|
|
## 不适用、延期与成果豁免
|
|
|
|
- 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
|
|
- 不适用不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
|
|
- 延期和正式豁免都不等于不适用。
|
|
- 适用内容缺失不能靠空文件或虚假“通过”穿过门禁。
|
|
|
|
《成果豁免申请》由成果主责角色提出，写明成果名称、阶段、不适用原因、事实证据、替代方案、下游影响、风险及负责人确认。流程为：
|
|
|
|
1. Hub 校验发起资格、资料结构和可豁免性，缺口退回补正，不自行作最终批准或拒绝。
|
|
2. 项目负责人（项目Hub对应的真人负责人）依据申请、证据、替代方案和影响，明确批准或拒绝。所有成果豁免均须此人工决定，不能以低影响、沉默、形式校验或 AI 推断代替。
|
|
3. Hub 登记决定人、时间、范围、基线、附加条件和失效条件；批准后分发豁免记录，拒绝或未获确认时仍需该成果。
|
|
4. 不再设置独立的下游征询、意见回传或业务高影响确认环节；必要的事实和影响写在申请中，缺少时补正，不凭空补造意见。
|
|
5. 决定只适用于当前项目、阶段和基线。不可豁免要求不能借本流程绕过；批准仅满足被豁免的文件要求，其他测试、验收和阶段门禁仍须满足，不能替代测试结果的项目负责人确认。保留原必需项和豁免记录，不删除要求；项目范围或输入基线变化时，旧豁免失效并重新评估。附加条件未满足时仍需该成果，Hub 向主责角色明确补交内容、证据和期限，相关阶段保持阻塞。
|
|
|
|
|
|
## 额外产出
|
|
|
|
角色可以提交职责内有价值的额外文件，说明它与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
|
|
|
|
Hub 可以将其作为支持材料保存。额外文件不会自动成为正式成果、增加当前完成条件、制造新阻塞或激活下游依赖。若确实需要改变范围、接口、角色责任、基线、排期、正式成果或验收，先由有权负责人批准并走《变更申请》，不能静默生效。
|
|
|
|
## 事实、判断和证据
|
|
|
|
结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标和正式承诺。模拟数据必须清楚标明，不能混入真实结果。
|
|
|
|
研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。
|
|
|
|
## 版本、留档与可追踪性
|
|
|
|
代码、固件、硬件、配置、设计、计划或报告给出足以识别对象的版本或引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口、板卡、BOM、ECO、构建或环境的匹配关系和下游约束。
|
|
|
|
文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时，才创建新版本并按需要重新确认。只更新任务状态、转交说明或排版，生成内容相同的重复副本，或补充不改变结论的过程说明，不升正式版本；有复盘价值时写入阶段记录。不得为排版或状态更新覆盖已经接受的文件。代码、固件、硬件、配置和构建物继续遵循本领域版本规则，实际对象或构建发生变化时必须能区分版本。
|
|
|
|
新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。成果索引为每项成果明确一个当前有效版本，下游默认只接收该版本；历史版本和过程材料不参与当前完成判断，除非被明确恢复为有效版本。
|
|
|
|
## Hub 校验边界
|
|
|
|
Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
|
|
|
|
阶段 6 测试大文件按可访问索引校验并保留确认记录，不要求 Hub 收存原文件；阶段 7 按下述产品直交收讫规则处理。除此之外，成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。
|
|
|
|
成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未按适用交付方式收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。
|
|
|
|
阶段 7 正式验收前须已完成上述项目负责人确认及测试质量门禁。测试报告及已提供的提测佐证按已确认的负责人直接交付路径处理：测试保管原文件，产品确认接收，Hub 登记文件名、版本、保存位置、测试负责人确认、项目负责人确认引用和产品接收确认，不要求大文件上传或转发。此前关于 Hub 实际收件、附件及本地归档的通用要求不强制适用于这条交付路径；必须能追踪实际文件与接收状态，不能只凭消息已处理宣布交接完成。
|
|
|
|
向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
|