Refine project role collaboration guidance

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

@@ -4,50 +4,49 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 
 ## 正式成果集合
 
-正式门禁成果只使用以下名称：
+人工可读的正式成果统一使用以下中文名称：
 
 | 阶段 | 正式成果 |
 |---|---|
-| 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 |
+| 1 业务需求 | 项目背景说明；项目目标与里程碑计划 |
+| 2 产品定义 | 立项资料；测试验收标准；里程碑要求 |
+| 3 方案设计 | 总体技术方案；软硬件接口契约；硬件设计包；架构决策记录；测试计划 |
+| 4 项目规划 | 项目计划；项目风险；角色分工；产品资料整合；项目状态内部记录 |
+| 5 软硬件实现 | 硬件实现资料；嵌入式底层实现资料；嵌入式应用层固件包 |
+| 6 测试验证 | 功能测试报告；可靠性测试报告；专项测试报告；测试证据包；缺陷分析报告 |
+| 7 业务验收 | 平台提测通过报告；客户验收通过报告；附条件验收事项 |
+| 8 发布结项 | 结项资料归档；变更记录；结项报告；流程闭环总结 |
 
-角色自定义文件可作为 supporting、internal 或 ADDITIONAL 材料，但不能替代适用正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、Test Evidence Package 或 Defect Analysis Report，不另立正式成果类别。
+角色自定义文件可以作为支持材料、内部材料或额外成果，但不能替代适用的正式成果。阶段 6 的质量结论和通用证据必须归入对应测试报告、《测试证据包》或《缺陷分析报告》，不另立正式成果类别。
 
-## 先定义产出契约
+## 先定义产出要求
 
 正式执行任务派发时明确：
 
-1. 正式成果或内聚成果包名称及主责角色、主责成员；
+1. 正式成果或成果包名称及唯一主责角色；
 2. 每项最低内容、适用子项和协作边界；
-3. 输入基线、版本、supersedes 和可追踪引用；
-4. 所需证据及未执行验证的表达方式；
-5. 下游用途、期限和可检查完成条件；
+3. 输入基线、版本、旧版替代关系和可追踪引用；
+4. 所需证据及未执行验证应如何说明；
+5. 下游用途、期限和可以检查的完成条件；
 6. 本角色必须给出的专业结论；
-7. 专业自审和 human owner 确认要求。
+7. 专业自审和负责人确认要求。
 
-任务要求和实际产出应一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需可追踪、经有权角色确认且结论明确。
+任务要求和实际产出必须一一对应。纯信息、澄清和批准决定不为形式创建空文件，但答复仍需来源清楚、经有权角色确认且结论明确。
 
-## 任务结果最低结构
+## 正式结果最低内容
 
-不强制统一复杂 JSON，但正式结果必须让 Hub 找到：
+不强制所有角色填写复杂 JSON，但正式结果必须让 Hub 找到：
 
-- WORK_ID、SUBTASK_ID、模式、流程基线、阶段、波次；
-- semantic role、实际 role ID、主责成员、session、human owner 和输入基线；
-- 实际完成内容和要求完成时间状态；
-- 成果名称、位置或传输引用、版本及 supersedes；
+- 当前阶段和使用的输入基线；
+- 实际完成内容和期限状态；
+- 成果中文名称、文件位置或附件、版本和旧版替代关系；
 - 每项完成条件对应的证据；
-- NA、未执行项、开放问题、依赖和剩余风险；
+- 不适用项、未执行项、开放问题、依赖和剩余风险；
 - 本角色明确结论：满足、部分满足或无法满足；
-- self_check_result；
-- internal_approved，以及确认人、时间、范围和条件。
+- 专业自审结果；
+- 负责人、确认时间、确认范围和附带条件。
 
-一句“已完成”“没问题”或“测试通过”不能关闭任务。
+一句“已完成”“没问题”或“测试通过”不能关闭任务。运行时消息标识由 Etunel 工具关联，不进入成果正文。
 
 ## 状态分层
 
@@ -62,57 +61,55 @@ Hub 定义任务产出、成员提交结果、判断状态或校验门禁时读
 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；模拟项目只确认模拟使用和流程推进，不证明模拟值真实。
+负责人确认表示当前负责人实际查看本次结果并确认可以作为该角色正式提交。至少记录确认人、时间、文件或版本、范围和附带条件。AI 不得自行声称已获确认；模拟项目只确认模拟材料的使用和流程推进，不证明模拟值真实。
 
-## 适用性、NA 与豁免
+## 不适用、延期与成果豁免
 
-- 适用内容必须形成；不适用统一标记 NA，并说明条件和依据。
-- NA 只表示不适用，不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
-- DEFERRED 是延后；WAIVED 是完成正式豁免；二者都不等于 NA。
-- 适用内容缺失不能用 NA 掩盖；固定成果不能靠空文件或虚假 PASS 通过。
+- 不适用内容写“不适用”，机器记录可以使用 `NA`，并说明条件和依据。
+- 不适用不能表示时间不足、环境缺失、尚未执行、失败或阻塞。
+- 延期和正式豁免都不等于不适用。
+- 适用内容缺失不能靠空文件或虚假“通过”穿过门禁。
 
-Artifact Waiver 由成果主责角色提出，提供成果标识、阶段、NA 原因、替代证据、下游影响、风险和内部确认。Hub 识别受影响角色与门禁：
+《成果豁免申请》由成果主责角色提出，提供成果名称、阶段、不适用原因、替代证据、下游影响、风险和负责人确认。Hub 识别受影响角色与门禁：
 
 1. 受影响角色负责人确认不会产生需求、接口、实现、测试、发布或审计缺口；
-2. 低影响、无专业争议时，Hub AI 可完成形式审查、批准和登记；
-3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或存在争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
-4. 只有状态为 WAIVED、批准记录完整才满足对应门禁；
-5. 条件变化使成果重新适用时撤销豁免并恢复 REQUIRED。
+2. 低影响且无专业争议时，Hub 可以完成形式审查、批准和登记；
+3. 涉及范围、质量、安全、合规、客户承诺、重大风险、不可逆影响或争议时，升级业务和相关专业角色，必要时由 Hub 负责人介入；
+4. 只有正式豁免记录完整，才满足对应门禁；
+5. 条件变化使成果重新适用时，撤销豁免并恢复为必需。
 
 ## 额外产出
 
-角色可提交职责内有价值的额外文件，标记 ADDITIONAL 并说明与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
+角色可以提交职责内有价值的额外文件，说明它与原任务的关系、对完成结论的影响、下游用途以及新增依赖、风险和维护责任。
 
-Hub 可将其纳入成果索引。若改变范围、接口、成员责任、基线、排期、正式成果或验收，先走 Change Request，不静默生效。
+Hub 可以将其纳入成果索引。若改变范围、接口、角色责任、基线、排期、正式成果或验收，先走《变更申请》，不能静默生效。
 
 ## 事实、判断和证据
 
-结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标、正式承诺、REAL 与 SIMULATED 数据。
+结果应区分：已确认事实、原始证据、本角色专业判断、未验证假设、已批准决定、开放问题、外部依赖、剩余风险、客户期望、内部目标和正式承诺。模拟数据必须清楚标明，不能混入真实结果。
 
 研发自测不能替代测试独立结论；测试不能替代产品或业务验收。无法执行的检查说明原因、影响和恢复条件。
 
-## 版本与可追踪性
+## 版本、留档与可追踪性
 
-代码、固件、硬件、配置、设计、计划或报告给出足以唯一识别对象的版本／引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口／板卡／BOM／ECO／构建／环境的匹配关系和下游约束。
+代码、固件、硬件、配置、设计、计划或报告给出足以识别对象的版本或引用，并说明上游输入、产生或验证版本、被替代旧版本、与接口、板卡、BOM、ECO、构建或环境的匹配关系和下游约束。
 
-新结果不能静默覆盖旧基线。正式变更保留旧版本、新版本、生效范围和 supersedes 关系。
+新结果不能静默覆盖旧基线。Hub 按 [项目文件与进度留档](project-files-and-progress.md) 保存文件、更新成果索引和阶段记录；正式变更保留旧版本、新版本和生效范围。
 
 ## Hub 校验边界
 
-Hub 检查文件存在、最低结构、身份、版本、证据引用、自审、负责人确认、冲突、依赖、状态层和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
+Hub 检查文件存在、最低结构、来源角色、版本、证据引用、自审、负责人确认、冲突、依赖、状态层、留档和门禁；不替专业角色判断内容是否充分。专业冲突定向交拥有决定权的角色。
 
 向下游只传递任务需要的已登记成果、版本、约束、风险和证据引用，不复制完整聊天或全部资料。