119 lines
6.9 KiB
Markdown
119 lines
6.9 KiB
Markdown
# 成果与完成判定
|
||
|
||
Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读取。具体职责和上下游见 [项目生命周期](project-lifecycle.md) 与当前角色契约。
|
||
|
||
## 正式成果集合
|
||
|
||
正式门禁成果只使用以下名称：
|
||
|
||
| 阶段 | 正式成果 |
|
||
|---|---|
|
||
| 1 业务需求 | Project Background Brief；Project Milestone Plan |
|
||
| 2 产品定义 | Project Initiation Package；Test & Acceptance Criteria；Milestone Requirements |
|
||
| 3 方案设计 | Solution Architecture；Software/Hardware Interface Contract；Hardware Design Package；Architecture Decision Record；Test Plan |
|
||
| 4 项目规划 | Project Plan；Risk Register；Role Assignment；Product Documentation Package；Project Status Record |
|
||
| 5 软硬件实现 | Hardware Implementation Package；Low-Level Implementation Package；Application Firmware Package |
|
||
| 6 测试验证 | Functional Test Report；Reliability Test Report；Specialized Test Report；Test Evidence Package；Defect Analysis Report |
|
||
| 7 业务验收 | Platform Test Approval Report；Customer Acceptance Approval Report；Conditional Acceptance Items |
|
||
| 8 发布结项 | Closure Documentation Archive；Change Log；Closure Report；Process Closure Summary |
|
||
|
||
角色自定义文件可作为 supporting、internal 或 ADDITIONAL 材料，但不能替代适用正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、Test Evidence Package 或 Defect Analysis Report，不另立正式成果类别。
|
||
|
||
## 先定义产出契约
|
||
|
||
正式执行任务派发时明确：
|
||
|
||
1. 正式成果或内聚成果包名称及主责角色、主责成员；
|
||
2. 每项最低内容、适用子项和协作边界；
|
||
3. 输入基线、版本、supersedes 和可追踪引用；
|
||
4. 所需证据及未执行验证的表达方式；
|
||
5. 下游用途、期限和可检查完成条件；
|
||
6. 本角色必须给出的专业结论；
|
||
7. 专业自审和 human owner 确认要求。
|
||
|
||
任务要求和实际产出应一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需可追踪、经有权角色确认且结论明确。
|
||
|
||
## 任务结果最低结构
|
||
|
||
不强制统一复杂 JSON，但正式结果必须让 Hub 找到：
|
||
|
||
- WORK_ID、SUBTASK_ID、模式、流程基线、阶段、波次；
|
||
- semantic role、实际 role ID、主责成员、session、human owner 和输入基线；
|
||
- 实际完成内容和要求完成时间状态；
|
||
- 成果名称、位置或传输引用、版本及 supersedes；
|
||
- 每项完成条件对应的证据；
|
||
- NA、未执行项、开放问题、依赖和剩余风险；
|
||
- 本角色明确结论：满足、部分满足或无法满足；
|
||
- self_check_result；
|
||
- internal_approved，以及确认人、时间、范围和条件。
|
||
|
||
一句“已完成”“没问题”或“测试通过”不能关闭任务。
|
||
|
||
## 状态分层
|
||
|
||
以下层级彼此独立：
|
||
|
||
1. 项目运行模式；
|
||
2. 任务执行结果；
|
||
3. 成果生命周期；
|
||
4. 成果适用性；
|
||
5. 阶段与门禁；
|
||
6. 测试结论；
|
||
7. 业务验收结论；
|
||
8. Etunel 消息或钉钉通知状态。
|
||
|
||
按当前运行时或角色规则记录状态属于哪一层。任务成功不等于成果已基线；成果存在不等于门禁满足；测试 PASS 不等于业务验收；消息 Consumed 或通知 ACCEPTED 不等于项目完成。
|
||
|
||
internal_approved=true 是本次消息／提交的人工确认字段；INTERNALLY_APPROVED 是成果生命周期语义。前者不能自动替代后者，成果状态仍需按其版本、证据和流程明确更新。
|
||
|
||
## 内聚任务包与多任务
|
||
|
||
- 同一角色、同一基线、紧密相关且共同交付的成果可组成一个任务包；全部必需产出满足才成功。
|
||
- 能独立验收、失败或服务不同依赖的工作使用独立 SUBTASK_ID，即使同批发送。
|
||
- 包内有效成果保留，未完成部分可拆为关联新任务；一个子项失败不能被其他成功掩盖。
|
||
|
||
## 专业自审和人类确认
|
||
|
||
self_check_result 说明角色如何按任务契约检查产出，可为 PASS、PARTIAL 或 FAIL，并列出依据与例外。
|
||
|
||
internal_approved 表示本角色 human owner 实际查看本次结果并确认可作为角色正式提交。至少记录确认人、时间、文件／版本／范围和附带条件。AI 不得自行设为 true；模拟项目只确认模拟使用和流程推进，不证明模拟值真实。
|
||
|
||
## 适用性、NA 与豁免
|
||
|
||
- 适用内容必须形成；不适用统一标记 NA，并说明条件和依据。
|
||
- NA 只表示不适用，不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
|
||
- DEFERRED 是延后；WAIVED 是完成正式豁免；二者都不等于 NA。
|
||
- 适用内容缺失不能用 NA 掩盖；固定成果不能靠空文件或虚假 PASS 通过。
|
||
|
||
Artifact Waiver 由成果主责角色提出，提供成果标识、阶段、NA 原因、替代证据、下游影响、风险和内部确认。Hub 识别受影响角色与门禁：
|
||
|
||
1. 受影响角色负责人确认不会产生需求、接口、实现、测试、发布或审计缺口；
|
||
2. 低影响、无专业争议时，Hub AI 可完成形式审查、批准和登记；
|
||
3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或存在争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
|
||
4. 只有状态为 WAIVED、批准记录完整才满足对应门禁；
|
||
5. 条件变化使成果重新适用时撤销豁免并恢复 REQUIRED。
|
||
|
||
## 额外产出
|
||
|
||
角色可提交职责内有价值的额外文件，标记 ADDITIONAL 并说明与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
|
||
|
||
Hub 可将其纳入成果索引。若改变范围、接口、成员责任、基线、排期、正式成果或验收，先走 Change Request，不静默生效。
|
||
|
||
## 事实、判断和证据
|
||
|
||
结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标、正式承诺、REAL 与 SIMULATED 数据。
|
||
|
||
研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。
|
||
|
||
## 版本与可追踪性
|
||
|
||
代码、固件、硬件、配置、设计、计划或报告给出足以唯一识别对象的版本／引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口／板卡／BOM／ECO／构建／环境的匹配关系和下游约束。
|
||
|
||
新结果不能静默覆盖旧基线。正式变更保留旧版本、新版本、生效范围和 supersedes 关系。
|
||
|
||
## Hub 校验边界
|
||
|
||
Hub 检查文件存在、最低结构、身份、版本、证据引用、自审、负责人确认、冲突、依赖、状态层和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
|
||
|
||
向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。
|