@ohos-cpf/3rdloop 0.0.2 → 0.0.3

package/vendor/Server/Skills/acceptance-check/references/PHASE2_EVIDENCE_VERIFICATION.md

@@ -1,70 +1,70 @@
-# 关键声明核验规则指南（Phase 2.3 扩展）
-
-> 适用于验收标准中涉及关键声明（分支血缘、产物存在、依赖版本、测试结果）的核验场景，尤其是"loop N 复用 loop N-1 产物"的跨循环核验任务。
-
-## 1. 证据三角验证
-
-验收判定禁止仅凭前序步骤报告的"成功"结论。每类关键声明的交叉验证方式：
-
-| 声明类型 | 报告声明（第一角） | 实物产物（第二角） | 现场查询（第三角） |
-|----------|--------------------|--------------------|--------------------|
-| 分支血缘 | 前序报告的分支/commit 描述 | — | `git merge-base <升级分支> <基线分支>` 实测 |
-| 编译产物 | 编译记录的"成功"结论 | 文件存在性 + 大小 + 时间戳（HAR/tgz/HAP 实体文件） | — |
-| 依赖版本 | 版本分析报告结论 | — | 直接读依赖清单文件原文（package.json / oh-package.json5） |
-| 测试产物 | 测试记录的通过率 | 测试目录/文件实际清单 | 列目录与报告清单一一比对 |
-
-## 2. 依赖版本核验检查单
-
-### 2.1 版本字段定位（先懂架构再核字段）
-
-核验依赖版本前，先读版本分析报告确认包架构：
-
-| 包架构 | 上游版本所在位置 | 适配包自身版本 |
-|--------|------------------|----------------|
-| re-export（JS 层仅 re-export 上游 npm 包） | `dependencies` 中的上游源库条目 | `version` 字段（历史沿袭，与 tgz 文件名对应，可能与上游版本不同步） |
-| 源内复制 / fork | `version` 字段或源码内版本标注 | 同左 |
-
-检查项：
-- [ ] 同时检查 `version`（适配包自身）与 `dependencies`（上游源库）两个字段
-- [ ] 与交付物 tgz 文件名交叉确认适配包自身版本
-- [ ] 在核验记录中显式写明版本字段语义说明，避免后续循环按字面直读 `version` 误判
-
-### 2.2 依赖残留分层判定（二分法）
-
-| 判定维度 | 阻断项（核验失败） | 记录项（非阻断） |
-|----------|--------------------|------------------|
-| 属于 RNOH 框架依赖（react-native / react-native-harmony / @rnoh/react-native-openharmony / nitro-modules / harmony-cli） | 是 | 否 |
-| 参与编译链（HAR→tgz→codegen→JS Bundle→ohpm→devecocli build） | 是 | 否 |
-| 参与运行时 | 是 | 否 |
-
-记录项（如 ESLint 配置等代码风格工具滞后）定性需三对照：上游基线版本（diff-output 中上游 package.json）+ example 侧同款版本 + 编译链涉及范围。
-
-处置：如实写入报告"遗留记录"节 + 给出风险定性（如低风险）+ 不阻断验收。隐藏不报或直接判失败都是错误的。
-
-## 3. 汇总指标分解
-
-验收标准含汇总数字时，必须分解至报告分项逐项对账：
-
-- 示例："设备端 95/95" = 自动套件 85/85 + Hooks 探针 10/10；"共 154/154" = Jest 59 + 85 + 10
-- 判定口径一致的条件：分项之和 = 汇总数，且各分项均能在报告中找到直接对应的数字
-- 只对总数不分解，会漏掉口径错配
-
-## 4. 扫描执行安全指引
-
-核验类扫描（版本残留/引用检查）的执行约束：
-
-- 优先使用 `rg`，禁止对含 node_modules 的仓库做 grep 全量扫描（实测 120s 超时被强制终止）
-- 必须叠加排除参数：`-g '!node_modules' -g '!oh_modules' -g '!package-lock.json' -g '!*.har' -g '!*.hap' -g '!\.git'`
-- 只扫依赖清单白名单文件：根/example 的 package.json、oh-package.json5、nitro.json、overrides/resolutions
-- 只匹配框架相关包名的版本号模式，避免误报
-
-## 5. 自动生成产物权威级
-
-链路中自动生成的 diff/扫描件（如 rn-scan-exports.cjs 生成的 api-diff_*.md）存在已知偏差：
-
-- Nitro HybridObject 架构的库，Spec 文件为 `*.nitro.ts` 而非 `Native*.ts` 命名，扫描器规则不覆盖，可能误判"TurboModule Spec 变更：无"
-- "JS 导出变更：无"等结论可能为误报
-
-判定规则：
-- 自动生成件若在后续人工分析报告中被修正 → 验收一律以修正结论件为准，自动件仅作参考
-- 核验前先确认产物链中每个文件的权威级（自动生成件 / 人工修正结论件），否则会拿错误基线对账
+# 关键声明核验规则指南（Phase 2.3 扩展）
+
+> 适用于验收标准中涉及关键声明（分支血缘、产物存在、依赖版本、测试结果）的核验场景，尤其是"loop N 复用 loop N-1 产物"的跨循环核验任务。
+
+## 1. 证据三角验证
+
+验收判定禁止仅凭前序步骤报告的"成功"结论。每类关键声明的交叉验证方式：
+
+| 声明类型 | 报告声明（第一角） | 实物产物（第二角） | 现场查询（第三角） |
+|----------|--------------------|--------------------|--------------------|
+| 分支血缘 | 前序报告的分支/commit 描述 | — | `git merge-base <升级分支> <基线分支>` 实测 |
+| 编译产物 | 编译记录的"成功"结论 | 文件存在性 + 大小 + 时间戳（HAR/tgz/HAP 实体文件） | — |
+| 依赖版本 | 版本分析报告结论 | — | 直接读依赖清单文件原文（package.json / oh-package.json5） |
+| 测试产物 | 测试记录的通过率 | 测试目录/文件实际清单 | 列目录与报告清单一一比对 |
+
+## 2. 依赖版本核验检查单
+
+### 2.1 版本字段定位（先懂架构再核字段）
+
+核验依赖版本前，先读版本分析报告确认包架构：
+
+| 包架构 | 上游版本所在位置 | 适配包自身版本 |
+|--------|------------------|----------------|
+| re-export（JS 层仅 re-export 上游 npm 包） | `dependencies` 中的上游源库条目 | `version` 字段（历史沿袭，与 tgz 文件名对应，可能与上游版本不同步） |
+| 源内复制 / fork | `version` 字段或源码内版本标注 | 同左 |
+
+检查项：
+- [ ] 同时检查 `version`（适配包自身）与 `dependencies`（上游源库）两个字段
+- [ ] 与交付物 tgz 文件名交叉确认适配包自身版本
+- [ ] 在核验记录中显式写明版本字段语义说明，避免后续循环按字面直读 `version` 误判
+
+### 2.2 依赖残留分层判定（二分法）
+
+| 判定维度 | 阻断项（核验失败） | 记录项（非阻断） |
+|----------|--------------------|------------------|
+| 属于 RNOH 框架依赖（react-native / react-native-harmony / @rnoh/react-native-openharmony / nitro-modules / harmony-cli） | 是 | 否 |
+| 参与编译链（HAR→tgz→codegen→JS Bundle→ohpm→devecocli build） | 是 | 否 |
+| 参与运行时 | 是 | 否 |
+
+记录项（如 ESLint 配置等代码风格工具滞后）定性需三对照：上游基线版本（diff-output 中上游 package.json）+ example 侧同款版本 + 编译链涉及范围。
+
+处置：如实写入报告"遗留记录"节 + 给出风险定性（如低风险）+ 不阻断验收。隐藏不报或直接判失败都是错误的。
+
+## 3. 汇总指标分解
+
+验收标准含汇总数字时，必须分解至报告分项逐项对账：
+
+- 示例："设备端 95/95" = 自动套件 85/85 + Hooks 探针 10/10；"共 154/154" = Jest 59 + 85 + 10
+- 判定口径一致的条件：分项之和 = 汇总数，且各分项均能在报告中找到直接对应的数字
+- 只对总数不分解，会漏掉口径错配
+
+## 4. 扫描执行安全指引
+
+核验类扫描（版本残留/引用检查）的执行约束：
+
+- 优先使用 `rg`，禁止对含 node_modules 的仓库做 grep 全量扫描（实测 120s 超时被强制终止）
+- 必须叠加排除参数：`-g '!node_modules' -g '!oh_modules' -g '!package-lock.json' -g '!*.har' -g '!*.hap' -g '!\.git'`
+- 只扫依赖清单白名单文件：根/example 的 package.json、oh-package.json5、nitro.json、overrides/resolutions
+- 只匹配框架相关包名的版本号模式，避免误报
+
+## 5. 自动生成产物权威级
+
+链路中自动生成的 diff/扫描件（如 rn-scan-exports.cjs 生成的 api-diff_*.md）存在已知偏差：
+
+- Nitro HybridObject 架构的库，Spec 文件为 `*.nitro.ts` 而非 `Native*.ts` 命名，扫描器规则不覆盖，可能误判"TurboModule Spec 变更：无"
+- "JS 导出变更：无"等结论可能为误报
+
+判定规则：
+- 自动生成件若在后续人工分析报告中被修正 → 验收一律以修正结论件为准，自动件仅作参考
+- 核验前先确认产物链中每个文件的权威级（自动生成件 / 人工修正结论件），否则会拿错误基线对账