first commit

etunel-role-collaboration/references/artifacts-and-evidence.md

@@ -0,0 +1,118 @@
+# 成果与完成判定
+
+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 检查文件存在、最低结构、身份、版本、证据引用、自审、负责人确认、冲突、依赖、状态层和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
+
+向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。