# 成果与完成判定

Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读取。具体职责和上下游见 [项目生命周期](project-lifecycle.md) 与当前角色契约。

## 正式成果集合

人工可读的正式成果统一使用以下中文名称：

| 阶段 | 正式成果 |
|---|---|
| 1 业务需求 | 项目背景说明；项目目标与里程碑计划 |
| 2 产品定义 | 立项资料；测试验收标准；里程碑要求 |
| 3 方案设计 | 总体技术方案；软硬件接口契约；硬件设计包；架构决策记录；测试计划 |
| 4 项目规划 | 项目计划；项目风险；角色分工；产品资料整合；项目状态内部记录 |
| 5 软硬件实现 | 硬件实现资料；嵌入式底层实现资料；嵌入式应用层固件包 |
| 6 测试验证 | 功能测试报告；可靠性测试报告；专项测试报告；测试证据包；缺陷分析报告 |
| 7 业务验收 | 平台提测通过报告；客户验收通过报告；附条件验收事项 |
| 8 发布结项 | 结项资料归档；变更记录；结项报告；流程闭环总结 |

角色自定义文件可以作为支持材料、内部材料或额外成果，但不能替代适用的正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、《测试证据包》或《缺陷分析报告》，不另立正式成果类别。

## 先定义产出要求

正式执行任务的产出和完成条件只来自“本阶段必须完成”的内容。后续阶段处理和当前不需要的内容可以登记，但不能自动成为当前成果、任务完成条件或门禁。“本阶段完成约定”不能替代正式成果的适用性判断、受控跳转或《成果豁免申请》。派发时明确：

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 归档、移动或引用同一成果不需要重新确认；只有内容或版本发生实质变化、当前用途超出原确认范围、负责人发生变化、确认证据缺失，或出现与原结论冲突的新事实时，才重新确认。另一角色对该成果作新的专业评估时，仍须取得该角色自己的负责人确认。

## 不适用、延期与成果豁免

- 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
- 不适用不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
- 延期和正式豁免都不等于不适用。
- 适用内容缺失不能靠空文件或虚假“通过”穿过门禁。

《成果豁免申请》由成果主责角色提出，提供成果名称、阶段、不适用原因、替代证据、下游影响、风险和负责人确认。Hub 识别受影响角色与门禁：

1. 受影响角色负责人确认不会产生需求、接口、实现、测试、发布或审计缺口；
2. 低影响且无专业争议时，Hub 可以完成形式审查、批准和登记；
3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
4. 只有正式豁免记录完整，才满足对应门禁；
5. 条件变化使成果重新适用时，撤销豁免并恢复为必需。

## 额外产出

角色可以提交职责内有价值的额外文件，说明它与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。

Hub 可以将其作为支持材料保存。额外文件不会自动成为正式成果、增加当前完成条件、制造新阻塞或激活下游依赖。若确实需要改变范围、接口、角色责任、基线、排期、正式成果或验收，先由有权负责人批准并走《变更申请》，不能静默生效。

## 事实、判断和证据

结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标和正式承诺。模拟数据必须清楚标明，不能混入真实结果。

研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。

## 版本、留档与可追踪性

代码、固件、硬件、配置、设计、计划或报告给出足以识别对象的版本或引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口、板卡、BOM、ECO、构建或环境的匹配关系和下游约束。

文档类正式成果只有在范围、行为、验收、接口、专业决定或下游行动发生实质变化时，才创建新版本并按需要重新确认。只更新任务状态、转交说明或排版，生成内容相同的重复副本，或补充不改变结论的过程说明，不升正式版本；有复盘价值时写入阶段记录。不得为排版或状态更新覆盖已经接受的文件。代码、固件、硬件、配置和构建物继续遵循本领域版本规则，实际对象或构建发生变化时必须能区分版本。

新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。成果索引为每项成果明确一个当前有效版本，下游默认只接收该版本；历史版本和过程材料不参与当前完成判断，除非被明确恢复为有效版本。

## Hub 校验边界

Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。

成果只有在 Hub 实际收到并能访问文件、确认来源角色正确、核对任务与输入基线、检查必要版本、证据、自审和负责人确认、完成阶段归档和成果索引更新，并明确作出“接受”结论后，才成为当前有效成果。成员说明已完成、附件刚送达或消息状态变化都不能单独替代接受。

成果已经接受后，后续 Etunel 任务记录异常不撤销该成果，也不要求角色重复制作或重复提交；Hub 单独记录并说明运行时异常。文件未收到、不可访问或未经校验时，不能用任务或消息状态推进项目。本 Skill 不处理 Etunel 的队列、重试或去重逻辑。

向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。