@ohos-cpf/3rdloop 0.0.2 → 0.0.3

package/vendor/Server/Skills/rn-library-test-coverage-check/references/CHECKLIST.md

@@ -1,280 +1,321 @@
-# RN 用例覆盖度检视检查清单
-
-本文档为 RNLibraryTestCoverageCheckSkill 的完整检查清单，供 AI 基于脚本输出进行评分时逐项核对。
-
-> ⚠️ **覆盖率数据来源**：覆盖率数据由脚本（`rn-analyze-test-coverage.cjs` 和 `rn-analyze-demo-coverage.cjs`）自动生成，AI 负责解读脚本输出并应用以下评分规则。
-
----
-
-## 评分概览
-
-| 维度 | 权重 | 基础分 | 扣分上限 | 检查项 |
-|------|------|--------|----------|--------|
-| 公开接口覆盖率 | 70% | 70 | -70 | RTC-01,RTC-02,RTC-04~RTC-06 |
-| 测试质量 | 30% | 30 | -30 | RTC-03,RTC-07 |
-
-**维度得分** = max(0, 基础分 - 该维度累计扣分)
-
-**综合评分** = Σ(各维度得分)，范围 0-100
-
----
-
-## 维度 1：公开接口覆盖率（RTC-01、RTC-02、RTC-04 ~ RTC-06）
-
-> 覆盖率数据来自脚本输出的 `covered[]` 和 `uncovered[]` 列表。
-
-### 覆盖率计算
-
-```
-公开接口覆盖率 = (有测试的接口数 / 总公开接口数) × 100%
-```
-
-**接口覆盖率来源**：覆盖率的计算同时考虑 DEMO 目录和 test 目录，两者取其高：
-- DEMO 目录覆盖：`demo-coverage-report.md` 中的覆盖率
-- test 目录覆盖：`test-coverage-report.md` 中的覆盖率
-- **任一来源达到 100% 即视为接口覆盖率满足要求**（无需两者都达到 100%）
-
-**综合接口覆盖率** = `max(test覆盖率, demo覆盖率)`
-
-**已覆盖/未覆盖接口合并逻辑**：
-- 已覆盖接口 = test已覆盖 ∪ demo已覆盖
-- 未覆盖接口（原始） = test未覆盖 ∩ demo未覆盖
-
-### 平台特有接口过滤
-
-> ⚠️ **核心规则**：其他平台（Android/iOS）特有的接口**不算未覆盖**，不计入扣分，不触发归零规则。鸿蒙化移植无需覆盖原平台专属接口。
-
-AI 需从原始未覆盖列表中识别并排除平台特有接口，得到**有效未覆盖列表**：
-
-```
-有效未覆盖列表 = 原始未覆盖列表 - 平台特有接口列表
-有效总接口数 = 总接口数 - 平台特有接口数
-有效覆盖率 = (已覆盖接口数 / 有效总接口数) × 100%
-```
-
-#### 平台特有接口识别特征
-
-满足以下任一特征即判定为平台特有接口：
-
-| # | 识别特征 | 示例 |
-|---|----------|------|
-| 1 | 接口名/类名包含平台关键词 | `getAndroidId`、`iOSVersion`、`AndroidPermission`、`isIOSNotch` |
-| 2 | 接口源文件位于 `android/` 或 `ios/` 目录 | `source: "./android/..."` |
-| 3 | 接口签名或描述明确标注平台限定 | `@platform android`、`(iOS only)`、`Android-specific` |
-| 4 | TurboModule 方法仅在原生 Android/iOS 代码中实现，鸿蒙侧无对应实现 | 鸿蒙化仓库 `source/ohos/` 中无该方法的 NAPI/TurboModule 实现 |
-| 5 | 接口涉及平台专有 API 类型 | `Activity`、`Context`（Android）；`UIView`、`UIApplicationDelegate`（iOS） |
-| 6 | 接口名含 `NativeAndroid`/`NativeIOS` 等前缀 | `NativeAndroidXxxModule`、`NativeIOSXxxSpec` |
-
-#### 判定流程
-
-1. 遍历原始 `uncovered[]` 中的每个接口
-2. 检查接口名/类名是否包含平台关键词（`android`/`ios`/`Android`/`iOS`/`AndroidOnly`/`iOSOnly`）
-3. 检查 `interface-spec.json` 中该接口的 `source` 字段是否指向 `android/` 或 `ios/` 目录
-4. 检查鸿蒙化仓库 `source/ohos/` 中是否存在该接口的鸿蒙侧实现（若无原生实现，说明该接口本身就是平台特有的）
-5. 满足任一特征 → 标记为「平台特有」，从有效未覆盖列表中移除
-6. 边界情况：接口名同时包含多平台关键词（如 `getPlatformInfo`）且非任一平台专属 → 不排除，正常计入未覆盖
-
-> ⚠️ **保守判定原则**：当无法确定接口是否为平台特有时，**不排除**该接口（按正常未覆盖处理），避免遗漏真实未覆盖的接口。只有明确证据表明是 Android/iOS 专属时才排除。
-
-#### 报告标注要求
-
-平台特有接口在报告中必须：
-- 在「覆盖度明细」表中标注覆盖来源为 `平台特有（排除）`
-- 在单独的「平台特有接口排除清单」章节中列出，包含接口名和判定依据
-- 不计入「未覆盖接口清单」
-- 不参与 RTC-01~06 扣分计算
-- 不影响归零规则 6 的覆盖率判定（使用有效覆盖率）
-
-### 检查项
-
-> 以下扣分基于 **平台特有接口过滤后的有效未覆盖列表**。
-
-| 编号 | 检查项 | 严重度 | 扣分 | 数据来源 |
-|------|--------|--------|------|----------|
-| RTC-01 | 核心接口未覆盖 | Critical | -20 | 有效未覆盖列表中标注为 required/核心的接口 |
-| RTC-02 | 重要接口未覆盖 | Major | -15 | 有效未覆盖列表中的重要公开接口 |
-| RTC-04 | 可选接口未覆盖 | Minor | -3 | 有效未覆盖列表中的可选/次要接口 |
-| RTC-05 | 接口参数组合未覆盖 | Major | -5 | AI 分析已覆盖接口的参数组合情况 |
-| RTC-06 | 回调/事件接口未覆盖 | Major | -8 | 有效未覆盖列表中 `isEvent=true` 的接口 |
-
-### 接口重要性判定
-
-AI 根据接口规格（`interface-spec.json`）中的接口信息判定重要性：
-
-| 重要性 | 判定依据 | 对应检查项 |
-|--------|----------|------------|
-| 核心 | TurboModule Spec 中的方法、库主入口导出的主要 API、标注为 required 的接口 | RTC-01 |
-| 重要 | 公开的类方法、组件 Props/方法、配置接口 | RTC-02 |
-| 可选 | 辅助工具函数、次要配置项、内部类型导出 | RTC-04 |
-
-### RTC-05 参数组合分析
-
-AI 对已覆盖接口分析参数组合覆盖情况：
-
-- 检查多参数接口是否测试了不同参数组合（含默认参数、缺失参数）
-- 数据来源：脚本 `covered[]` 中的接口 + AI 分析测试代码中的调用方式
-- 若已覆盖接口的参数组合不完整，按缺失数量扣分
-
-### RTC-06 事件接口判定
-
-脚本接口规格中 `isEvent=true` 的接口（匹配 `add*Listener`/`remove*Listener` 模式）：
-- 在 `uncovered[]` 中的事件接口 → 每个扣 -8 分
-- 在 `covered[]` 中的事件接口 → 不扣分
-
-### 扣分上限
-
-本维度扣分上限为 **-70 分**（维度基础分 70 分）。
-
-> ⚠️ **归零规则 6**：有效综合接口覆盖率（排除平台特有接口后）未达到 100% 时，综合评分直接为 0 分。
-
----
-
-## 维度 2：测试质量（RTC-03、RTC-07）
-
-> 本维度由 AI 评估，需要 AI 读取测试源码进行质量分析。
-
-### RTC-03 边界场景缺失
-
-逐接口分析是否需要边界场景测试，将结果记录到覆盖度明细的「边界场景覆盖」列。
-
-#### 不需要边界场景的接口
-
-以下接口特征的参数无语义约束或无边界可言，填写「不需要」：
-
-| 接口特征 | 判定理由 |
-|----------|----------|
-| 无参数 getter/查询方法 | 仅读取内部状态，无输入参数可测试边界 |
-| 简单 boolean toggle | 参数仅为 true/false，无中间值或边界可言 |
-| 简单 key 查找/注册方法 | 参数为简单字符串标识符，逻辑为 Map 操作，边界已在 key 为空时覆盖 |
-
-#### 需要边界场景的接口
-
-以下接口特征涉及有语义约束的参数、外部依赖或可失败路径，需要边界场景测试：
-
-| 接口特征 | 常见边界场景 | 覆盖度明细填写示例 |
-|----------|-------------|-------------------|
-| 带有语义约束的字符串/数字参数 | 空字符串、null、超长值、非法格式、越界数值 | `缺少空值、非法值的验证` |
-| 文件/资源路径参数 | 空路径、无效路径、不存在资源、超长路径 | `缺少空路径、不存在资源的验证` |
-| 网络/IO 操作接口 | 网络超时、连接失败、服务端错误响应 | `缺少网络超时、错误响应的验证` |
-| 回调/事件参数 | 回调返回 null、回调抛异常、回调超时未响应 | `缺少回调返回 null/异常的验证` |
-| 配置对象参数 | 必填字段缺失、字段类型错误、空对象 | `缺少必填字段缺失、类型错误的验证` |
-
-覆盖度明细填写规则：
-- 边界场景已有覆盖时填「✅ 已覆盖」
-- 边界场景缺失时填写具体缺失说明（参考上表示例）
-- 不需要边界场景时填「不需要」
-
-#### 扣分计算
-
-RTC-03 扣分数量 = 覆盖度明细中「边界场景覆盖」列填写了缺失说明的接口数（即非「不需要」且非「✅ 已覆盖」的接口数），每缺少一个接口扣 -5 分，小计上限 -15 分。
-
-### RTC-07 测试框架覆盖度
-
-检查鸿蒙化测试是否使用 `@rnoh/testerino` 框架，并遵循 Tester/TestSuite/TestCase 规范结构编写测试用例。
-
-#### 规范结构要求
-
-测试用例应遵循以下层次结构：
-
-```tsx
-<Tester>
-  <TestSuite name="{套件名称}">
-    <TestCase
-      key="{待测接口属性}"
-      itShould="{预期结果描述}"
-      initialState={false}
-      arrange={({ setState }) => {
-        // 正确渲染测试用例，调用 setState 反馈测试结果
-        return <View>...</View>;
-      }}
-      assert={async ({ expect, state }) => {
-        expect(state).to.be.true;
-      }}
-    />
-  </TestSuite>
-</Tester>
-```
-
-#### TestCase 渲染模式说明
-
-TestCase 有两种渲染模式：
-
-1. **arrange 模式（规范推荐）**：使用 `arrange={({ setState }) => { ... }}` + `initialState` 渲染测试组件，通过 `setState` 反馈测试结果，配合 `assert` 进行自动化断言。此模式可实现完整的自动化测试流程。
-
-2. **children 模式（允许但不推荐）**：将 Button/View 等组件直接作为 TestCase 的子元素（children），用户通过手动点击按钮触发接口调用，结果通过外部 ScrollView 或 setState 展示。此模式无法实现自动化断言，依赖人工观察，属于 ⚠️ 警告级别，不扣分但需在报告中标注。
-
-判定规则：
-- 使用 arrange 模式且正确调用 setState → ✅ 合规，不扣分
-- 使用 children 模式（TestCase 含子元素渲染内容） → ⚠️ 警告，不扣分，报告标注
-- TestCase 既无 arrange 也无 children 渲染内容 → ❌ 扣 -5 分
-
-#### 规范检查方面
-
-| # | 规范方面 | 不符合时的扣分 | 说明 |
-|---|----------|---------------|------|
-| 1 | 使用 `@rnoh/testerino` 框架 | -5 | 测试文件未导入 Tester/TestSuite/TestCase，或使用其他测试框架（如 Jest 直接测试）代替 |
-| 2 | `TestCase.key` 说明待测接口属性 | -5 | key 值未能明确标识正在测试的接口或属性（如仅用序号或泛泛描述） |
-| 3 | `TestCase.itShould` 说明预期结果 | -5 | itShould 值未能清晰描述测试的预期行为或结果 |
-| 4 | `TestCase.arrange` 正确渲染并调用 setState | -5 / ⚠️ | 优先使用 `arrange` + `initialState`/`setState` 模式（规范推荐）。若使用 TestCase children 模式（将 Button/View 等组件直接嵌套为 TestCase 子元素），不扣分，但在报告中列出⚠️警告：「使用 TestCase children 模式替代 arrange+setState，缺少自动化结果反馈机制，建议迁移至 arrange 模式」。仅当 TestCase 既无 arrange 也无 children 内容时才扣 -5 分 |
-| 5 | `TestCase.assert` 验证结果 | -5 | 缺少 assert 函数，或 assert 未基于 state 进行有效断言 |
-
-小计上限 -15 分（最多扣 3 个方面）。
-
-### 扣分上限
-
-本维度扣分上限为 **-30 分**（维度基础分 30 分）。其中 RTC-03 小计上限为 -15 分，RTC-07 小计上限为 -15 分。
-
----
-
-## 零容忍归零规则
-
-> 以下归零规则基于**有效接口列表**（排除平台特有接口后）判定。
-
-| 规则 | 条件 | 判定依据 | 结果 |
-|------|------|----------|------|
-| 归零 1 | 核心接口完全无测试 | 有效未覆盖列表包含所有核心接口 | 直接 0 分 |
-| 归零 2 | 有效公开接口覆盖率 < 10% | 排除平台特有接口后覆盖率 < 10% | 直接 0 分 |
-| 归零 3 | 仓库无任何测试文件 | 脚本报告显示 0 个源文件 | 直接 0 分 |
-| 归零 4 | 未发现鸿蒙化代码 | 接口提取脚本失败或提取 0 个接口 | 0 分 |
-| 归零 5 | 源码目录不可访问 | 目录不存在 | 0 分 |
-| 归零 6 | 有效综合接口覆盖率 < 100% | 排除平台特有接口后 `max(test覆盖率, demo覆盖率)` < 100% | 直接 0 分 |
-
-> ⚠️ 归零规则叠加于维度扣分之上。触发任一归零规则时，综合评分直接为 0 分，不再计算维度得分。
-
----
-
-## 脚本输出与评分映射
-
-### 从 test-coverage-report.md 提取数据
-
-| 报告内容 | 提取数据 | 评分用途 |
-|----------|----------|----------|
-| "方法级覆盖率: XX%" | test 覆盖率 | 综合接口覆盖率计算 |
-| "方法/属性总数 (N)" | 总接口数 | 检视概览 |
-| "已覆盖 (M)" | 已覆盖数 | 检视概览 |
-| "未覆盖接口详情"章节 | 未覆盖接口列表 | RTC-01~06 扣分 |
-| "已覆盖接口详情"章节 | 已覆盖接口列表 | 覆盖度明细表 |
-| "源文件数" | 测试文件数 | 归零规则 3 判定 |
-
-### 从 demo-coverage-report.md 提取数据
-
-| 报告内容 | 提取数据 | 评分用途 |
-|----------|----------|----------|
-| "方法级覆盖率: XX%" | demo 覆盖率 | 综合接口覆盖率计算 |
-| "未覆盖接口详情"章节 | demo 未覆盖接口 | 与 test 未覆盖取交集 |
-| "已覆盖接口详情"章节 | demo 已覆盖接口 | 与 test 已覆盖取并集 |
-| "源文件数" | demo 文件数 | 检视概览 |
-
-### 从 interface-spec.json 提取数据
-
-| JSON 字段 | 提取数据 | 评分用途 |
-|-----------|----------|----------|
-| `interfaces[].fullName` | 接口全名 | 覆盖度明细 |
-| `interfaces[].isEvent` | 是否事件接口 | RTC-06 判定 |
-| `interfaces[].kind` | 接口类型 | 重要性判定 |
-| `interfaces[].layer` | 层级（js/turbo） | 重要性判定 |
-| `interfaces[].source` | 接口源文件路径 | 平台特有接口判定（特征 2：是否位于 android/ios 目录） |
-| `interfaces[].memberName` | 接口成员名 | 平台特有接口判定（特征 1：是否包含平台关键词） |
-| `interfaces[].className` | 类名 | 平台特有接口判定（特征 1：是否包含平台关键词） |
-| `interfaces[].signature` | 接口签名 | 平台特有接口判定（特征 3/5：是否标注平台限定或引用平台专有类型） |
-| `summary.N` | 总接口数 | 检视概览 |
+# RN 用例覆盖度检视检查清单
+
+本文档为 RNLibraryTestCoverageCheckSkill 的完整检查清单，供 AI 基于脚本输出进行评分时逐项核对。
+
+> ⚠️ **覆盖率数据来源**：覆盖率数据由脚本（`rn-analyze-test-coverage.cjs` 和 `rn-analyze-demo-coverage.cjs`）自动生成，AI 负责解读脚本输出并应用以下评分规则。
+
+---
+
+## 评分概览
+
+| 维度 | 权重 | 基础分 | 扣分上限 | 检查项 |
+|------|------|--------|----------|--------|
+| 公开接口覆盖率 | 70% | 70 | -70 | RTC-01,RTC-02,RTC-04~RTC-06 |
+| 测试质量 | 30% | 30 | -30 | RTC-03,RTC-07 |
+
+**维度得分** = max(0, 基础分 - 该维度累计扣分)
+
+**综合评分** = Σ(各维度得分)，范围 0-100
+
+---
+
+## 维度 1：公开接口覆盖率（RTC-01、RTC-02、RTC-04 ~ RTC-06）
+
+> 覆盖率数据来自脚本输出的 `covered[]` 和 `uncovered[]` 列表。
+
+### 覆盖率计算
+
+```
+公开接口覆盖率 = (有测试的接口数 / 总公开接口数) × 100%
+```
+
+**接口覆盖率来源**：覆盖率的计算同时考虑 DEMO 目录和 test 目录，两者取其高：
+- DEMO 目录覆盖：`demo-coverage-report.md` 中的覆盖率
+- test 目录覆盖：`test-coverage-report.md` 中的覆盖率
+- **任一来源达到 100% 即视为接口覆盖率满足要求**（无需两者都达到 100%）
+
+**综合接口覆盖率** = `max(test覆盖率, demo覆盖率)`
+
+**已覆盖/未覆盖接口合并逻辑**：
+- 已覆盖接口 = test已覆盖 ∪ demo已覆盖
+- 未覆盖接口（原始） = test未覆盖 ∩ demo未覆盖
+
+### 平台特有接口过滤
+
+> ⚠️ **核心规则**：其他平台（Android/iOS）特有的接口**不算未覆盖**，不计入扣分，不触发归零规则。鸿蒙化移植无需覆盖原平台专属接口。
+
+AI 需从原始未覆盖列表中识别并排除平台特有接口，得到**有效未覆盖列表**：
+
+```
+有效未覆盖列表 = 原始未覆盖列表 - 平台特有接口列表
+有效总接口数 = 总接口数 - 平台特有接口数
+有效覆盖率 = (已覆盖接口数 / 有效总接口数) × 100%
+```
+
+#### 平台特有接口识别特征
+
+满足以下任一特征即判定为平台特有接口：
+
+| # | 识别特征 | 示例 |
+|---|----------|------|
+| 1 | 接口名/类名包含平台关键词 | `getAndroidId`、`iOSVersion`、`AndroidPermission`、`isIOSNotch` |
+| 2 | 接口源文件位于 `android/` 或 `ios/` 目录 | `source: "./android/..."` |
+| 3 | 接口签名或描述明确标注平台限定 | `@platform android`、`(iOS only)`、`Android-specific` |
+| 4 | TurboModule 方法仅在原生 Android/iOS 代码中实现，鸿蒙侧无对应实现 | 鸿蒙化仓库 `source/ohos/` 中无该方法的 NAPI/TurboModule 实现 |
+| 5 | 接口涉及平台专有 API 类型 | `Activity`、`Context`（Android）；`UIView`、`UIApplicationDelegate`（iOS） |
+| 6 | 接口名含 `NativeAndroid`/`NativeIOS` 等前缀 | `NativeAndroidXxxModule`、`NativeIOSXxxSpec` |
+
+> ⚠️ **判据优先级**：特征 3（上游 d.ts 平台限定注释，如 `// Android only`）**仅为线索，不能单独作为排除依据**；特征 4（鸿蒙侧 TurboModule/ArkTS/C++ 均无实现）是**决定性判据**。反例（rntpc_cookies）：`removeSessionCookies`（上游标注 Android only）与 `clearByName`（上游标注 iOS only）鸿蒙侧 TurboModule 均有实现，若按注释机械排除，会把鸿蒙侧真实存在的接口移出有效分母（过度排除，掩盖真实覆盖缺口）。建议三条证据齐备才排除：① 上游平台标注（线索）+ ② 鸿蒙 JS 入口平台门控（如仅 `Platform.OS === 'android'` 时调原生，鸿蒙为 no-op）+ ③ 鸿蒙侧无任何实现（决定性）。
+
+#### 判定流程
+
+1. 遍历原始 `uncovered[]` 中的每个接口
+2. 检查接口名/类名是否包含平台关键词（`android`/`ios`/`Android`/`iOS`/`AndroidOnly`/`iOSOnly`）
+3. 检查 `interface-spec.json` 中该接口的 `source` 字段是否指向 `android/` 或 `ios/` 目录
+4. 检查鸿蒙化仓库 `source/ohos/` 中是否存在该接口的鸿蒙侧实现（若无原生实现，说明该接口本身就是平台特有的）
+5. 满足任一特征 → 标记为「平台特有」，从有效未覆盖列表中移除
+6. 边界情况：接口名同时包含多平台关键词（如 `getPlatformInfo`）且非任一平台专属 → 不排除，正常计入未覆盖
+
+> ⚠️ **保守判定原则**：当无法确定接口是否为平台特有时，**不排除**该接口（按正常未覆盖处理），避免遗漏真实未覆盖的接口。只有明确证据表明是 Android/iOS 专属时才排除。
+
+#### 报告标注要求
+
+平台特有接口在报告中必须：
+- 在「覆盖度明细」表中标注覆盖来源为 `平台特有（排除）`
+- 在单独的「平台特有接口排除清单」章节中列出，包含接口名和判定依据
+- 不计入「未覆盖接口清单」
+- 不参与 RTC-01~06 扣分计算
+- 不影响归零规则 6 的覆盖率判定（使用有效覆盖率）
+
+### 未覆盖列表交叉验证（评分前强制对账）
+
+> ⚠️ **强制步骤**：任何基于 `uncovered[]` 的扣分或归零判定（尤其归零规则 6），必须先完成本节交叉验证。归零规则 6 的放大效应使**单个脚本假阴性即可翻转整个评分**（实例：rntpc_cookies 95 ↔ 0）。
+
+#### 脚本已知假阴性局限
+
+- 接口提取脚本 `rn-extract-interfaces.cjs` 会将上游 `index.d.ts` 中的索引签名 `[key: string]: T` 提取为**伪字段**（memberName=签名参数名，如 `Cookies.key`），运行时不存在该真实属性
+- 覆盖率脚本（`rn-analyze-test-coverage.cjs` / `rn-analyze-demo-coverage.cjs`）的 AST 匹配器只处理属性访问（`PropertyAccessExpression` 属性名等值匹配）、对象字面量与 JSX 属性，**不处理方括号索引访问（`ElementAccessExpression`）**——而索引签名的合法用法恰恰是 `obj["xxx"]` / `obj[变量]`
+- 即使测试写点访问 `obj.xxx`，属性名是业务名而非 `key`，同样不命中 → 索引签名伪成员在属性名等值匹配体系下**必然假阴性**
+
+#### 索引签名伪成员（提取伪影）识别信号
+
+三条可疑信号（命中即疑似伪成员）：
+
+| # | 可疑信号 | 实例 |
+|---|----------|------|
+| 1 | memberName 是"类型签名参数名"风格的通用词（`key`/`value`/`index`），而非业务命名 | `Cookies.key` |
+| 2 | 所属 className 是纯类型接口（kind=field、layer=js、type=type-decl，无运行时类），即索引签名宿主 | `Cookies` |
+| 3 | 测试代码中有该类型显式标注的变量（`const c: Cookies = {...}`），逻辑上不可能"完全没用" | `coverageCookies: Cookies` 有 6+ 处访问 |
+
+#### grep 盘点对账方法
+
+对有效未覆盖列表逐项在测试与 Demo 源码中 grep 宿主变量的所有访问形式：
+- 方括号访问：`varName[`（字面量键 `varName["xxx"]` / 变量键 `varName[k]` / 计算键 `varName[expr]` 三种形式）
+- 点访问：`varName.`（任意属性名，只要变量类型为该接口）
+
+**判定**：任一形式命中且语义上使用了该接口/索引签名 → 判定为脚本假阴性，修正为已覆盖（来源 test/demo/both），重新计算有效覆盖率；全部未命中 → 维持未覆盖。
+
+#### 归零边缘警觉
+
+排除平台特有接口后有效覆盖率恰好差 1-2 项达到 100% 时，是伪成员/假阴性的**高发信号**，必须逐项核验而非直接套用归零规则 6。
+
+#### 报告标注要求
+
+- 修正项写入报告「脚本假阴性修正清单」章节，附 grep 证据（文件+行号+访问形式）
+- 修正后重新计算的有效覆盖率方可用于归零规则 6 判定
+
+### 检查项
+
+> 以下扣分基于 **平台特有接口过滤并经交叉验证修正后的有效未覆盖列表**。
+
+| 编号 | 检查项 | 严重度 | 扣分 | 数据来源 |
+|------|--------|--------|------|----------|
+| RTC-01 | 核心接口未覆盖 | Critical | -20 | 有效未覆盖列表中标注为 required/核心的接口 |
+| RTC-02 | 重要接口未覆盖 | Major | -15 | 有效未覆盖列表中的重要公开接口 |
+| RTC-04 | 可选接口未覆盖 | Minor | -3 | 有效未覆盖列表中的可选/次要接口 |
+| RTC-05 | 接口参数组合未覆盖 | Major | -5 | AI 分析已覆盖接口的参数组合情况 |
+| RTC-06 | 回调/事件接口未覆盖 | Major | -8 | 有效未覆盖列表中 `isEvent=true` 的接口 |
+
+### 接口重要性判定
+
+AI 根据接口规格（`interface-spec.json`）中的接口信息判定重要性：
+
+| 重要性 | 判定依据 | 对应检查项 |
+|--------|----------|------------|
+| 核心 | TurboModule Spec 中的方法、库主入口导出的主要 API、标注为 required 的接口 | RTC-01 |
+| 重要 | 公开的类方法、组件 Props/方法、配置接口 | RTC-02 |
+| 可选 | 辅助工具函数、次要配置项、内部类型导出 | RTC-04 |
+
+### RTC-05 参数组合分析
+
+AI 对已覆盖接口分析参数组合覆盖情况：
+
+- 检查多参数接口是否测试了不同参数组合（含默认参数、缺失参数）
+- 数据来源：脚本 `covered[]` 中的接口 + AI 分析测试代码中的调用方式
+- 若已覆盖接口的参数组合不完整，按缺失数量扣分
+
+### RTC-06 事件接口判定
+
+脚本接口规格中 `isEvent=true` 的接口（匹配 `add*Listener`/`remove*Listener` 模式）：
+- 在 `uncovered[]` 中的事件接口 → 每个扣 -8 分
+- 在 `covered[]` 中的事件接口 → 不扣分
+
+### 扣分上限
+
+本维度扣分上限为 **-70 分**（维度基础分 70 分）。
+
+> ⚠️ **归零规则 6**：有效综合接口覆盖率（排除平台特有接口后）未达到 100% 时，综合评分直接为 0 分。
+
+---
+
+## 维度 2：测试质量（RTC-03、RTC-07）
+
+> 本维度由 AI 评估，需要 AI 读取测试源码进行质量分析。
+
+### RTC-03 边界场景缺失
+
+逐接口分析是否需要边界场景测试，将结果记录到覆盖度明细的「边界场景覆盖」列。
+
+#### 不需要边界场景的接口
+
+以下接口特征的参数无语义约束或无边界可言，填写「不需要」：
+
+| 接口特征 | 判定理由 |
+|----------|----------|
+| 无参数 getter/查询方法 | 仅读取内部状态，无输入参数可测试边界 |
+| 简单 boolean toggle | 参数仅为 true/false，无中间值或边界可言 |
+| 简单 key 查找/注册方法 | 参数为简单字符串标识符，逻辑为 Map 操作，边界已在 key 为空时覆盖 |
+
+#### 需要边界场景的接口
+
+以下接口特征涉及有语义约束的参数、外部依赖或可失败路径，需要边界场景测试：
+
+| 接口特征 | 常见边界场景 | 覆盖度明细填写示例 |
+|----------|-------------|-------------------|
+| 带有语义约束的字符串/数字参数 | 空字符串、null、超长值、非法格式、越界数值 | `缺少空值、非法值的验证` |
+| 文件/资源路径参数 | 空路径、无效路径、不存在资源、超长路径 | `缺少空路径、不存在资源的验证` |
+| 网络/IO 操作接口 | 网络超时、连接失败、服务端错误响应 | `缺少网络超时、错误响应的验证` |
+| 回调/事件参数 | 回调返回 null、回调抛异常、回调超时未响应 | `缺少回调返回 null/异常的验证` |
+| 配置对象参数 | 必填字段缺失、字段类型错误、空对象 | `缺少必填字段缺失、类型错误的验证` |
+
+覆盖度明细填写规则：
+- 边界场景已有覆盖时填「✅ 已覆盖」
+- 边界场景缺失时填写具体缺失说明（参考上表示例）
+- 不需要边界场景时填「不需要」
+
+#### 扣分计算
+
+RTC-03 扣分数量 = 覆盖度明细中「边界场景覆盖」列填写了缺失说明的接口数（即非「不需要」且非「✅ 已覆盖」的接口数），每缺少一个接口扣 -5 分，小计上限 -15 分。
+
+### RTC-07 测试框架覆盖度
+
+检查鸿蒙化测试是否使用 `@rnoh/testerino` 框架，并遵循 Tester/TestSuite/TestCase 规范结构编写测试用例。
+
+#### 规范结构要求
+
+测试用例应遵循以下层次结构：
+
+```tsx
+<Tester>
+  <TestSuite name="{套件名称}">
+    <TestCase
+      key="{待测接口属性}"
+      itShould="{预期结果描述}"
+      initialState={false}
+      arrange={({ setState }) => {
+        // 正确渲染测试用例，调用 setState 反馈测试结果
+        return <View>...</View>;
+      }}
+      assert={async ({ expect, state }) => {
+        expect(state).to.be.true;
+      }}
+    />
+  </TestSuite>
+</Tester>
+```
+
+#### TestCase 渲染模式说明
+
+TestCase 有两种渲染模式：
+
+1. **arrange 模式（规范推荐）**：使用 `arrange={({ setState }) => { ... }}` + `initialState` 渲染测试组件，通过 `setState` 反馈测试结果，配合 `assert` 进行自动化断言。此模式可实现完整的自动化测试流程。
+
+2. **children 模式（允许但不推荐）**：将 Button/View 等组件直接作为 TestCase 的子元素（children），用户通过手动点击按钮触发接口调用，结果通过外部 ScrollView 或 setState 展示。此模式无法实现自动化断言，依赖人工观察，属于 ⚠️ 警告级别，不扣分但需在报告中标注。
+
+判定规则：
+- 使用 arrange 模式且正确调用 setState → ✅ 合规，不扣分
+- 使用 children 模式（TestCase 含子元素渲染内容） → ⚠️ 警告，不扣分，报告标注
+- TestCase 既无 arrange 也无 children 渲染内容 → ❌ 扣 -5 分
+
+#### 规范检查方面
+
+| # | 规范方面 | 不符合时的扣分 | 说明 |
+|---|----------|---------------|------|
+| 1 | 使用 `@rnoh/testerino` 框架 | -5 | 测试文件未导入 Tester/TestSuite/TestCase，或使用其他测试框架（如 Jest 直接测试）代替 |
+| 2 | `TestCase.key` 说明待测接口属性 | -5 | key 值未能明确标识正在测试的接口或属性（如仅用序号或泛泛描述） |
+| 3 | `TestCase.itShould` 说明预期结果 | -5 | itShould 值未能清晰描述测试的预期行为或结果 |
+| 4 | `TestCase.arrange` 正确渲染并调用 setState | -5 / ⚠️ | 优先使用 `arrange` + `initialState`/`setState` 模式（规范推荐）。若使用 TestCase children 模式（将 Button/View 等组件直接嵌套为 TestCase 子元素），不扣分，但在报告中列出⚠️警告：「使用 TestCase children 模式替代 arrange+setState，缺少自动化结果反馈机制，建议迁移至 arrange 模式」。仅当 TestCase 既无 arrange 也无 children 内容时才扣 -5 分 |
+| 5 | `TestCase.assert` 验证结果 | -5 | 缺少 assert 函数，或 assert 未基于 state 进行有效断言 |
+
+小计上限 -15 分（最多扣 3 个方面）。
+
+### 扣分上限
+
+本维度扣分上限为 **-30 分**（维度基础分 30 分）。其中 RTC-03 小计上限为 -15 分，RTC-07 小计上限为 -15 分。
+
+---
+
+## 零容忍归零规则
+
+> 以下归零规则基于**有效接口列表**（排除平台特有接口并完成未覆盖列表交叉验证后）判定。
+
+| 规则 | 条件 | 判定依据 | 结果 |
+|------|------|----------|------|
+| 归零 1 | 核心接口完全无测试 | 有效未覆盖列表包含所有核心接口 | 直接 0 分 |
+| 归零 2 | 有效公开接口覆盖率 < 10% | 排除平台特有接口后覆盖率 < 10% | 直接 0 分 |
+| 归零 3 | 仓库无任何测试文件 | 脚本报告显示 0 个源文件 | 直接 0 分 |
+| 归零 4 | 未发现鸿蒙化代码 | 接口提取脚本失败或提取 0 个接口 | 0 分 |
+| 归零 5 | 源码目录不可访问 | 目录不存在 | 0 分 |
+| 归零 6 | 有效综合接口覆盖率 < 100% | 排除平台特有接口并交叉验证修正后 `max(test覆盖率, demo覆盖率)` < 100% | 直接 0 分 |
+
+> ⚠️ **归零规则 6 判定前置条件**：必须先完成「未覆盖列表交叉验证」（识别并修正脚本假阴性），再以修正后的有效覆盖率判定归零规则 6。
+
+> ⚠️ 归零规则叠加于维度扣分之上。触发任一归零规则时，综合评分直接为 0 分，不再计算维度得分。
+
+---
+
+## 脚本输出与评分映射
+
+### 从 test-coverage-report.md 提取数据
+
+| 报告内容 | 提取数据 | 评分用途 |
+|----------|----------|----------|
+| "方法级覆盖率: XX%" | test 覆盖率 | 综合接口覆盖率计算 |
+| "方法/属性总数 (N)" | 总接口数 | 检视概览 |
+| "已覆盖 (M)" | 已覆盖数 | 检视概览 |
+| "未覆盖接口详情"章节 | 未覆盖接口列表 | RTC-01~06 扣分 |
+| "已覆盖接口详情"章节 | 已覆盖接口列表 | 覆盖度明细表 |
+| "源文件数" | 测试文件数 | 归零规则 3 判定 |
+
+### 从 demo-coverage-report.md 提取数据
+
+| 报告内容 | 提取数据 | 评分用途 |
+|----------|----------|----------|
+| "方法级覆盖率: XX%" | demo 覆盖率 | 综合接口覆盖率计算 |
+| "未覆盖接口详情"章节 | demo 未覆盖接口 | 与 test 未覆盖取交集 |
+| "已覆盖接口详情"章节 | demo 已覆盖接口 | 与 test 已覆盖取并集 |
+| "源文件数" | demo 文件数 | 检视概览 |
+
+### 从 interface-spec.json 提取数据
+
+| JSON 字段 | 提取数据 | 评分用途 |
+|-----------|----------|----------|
+| `interfaces[].fullName` | 接口全名 | 覆盖度明细 |
+| `interfaces[].isEvent` | 是否事件接口 | RTC-06 判定 |
+| `interfaces[].kind` | 接口类型 | 重要性判定 |
+| `interfaces[].layer` | 层级（js/turbo） | 重要性判定 |
+| `interfaces[].source` | 接口源文件路径 | 平台特有接口判定（特征 2：是否位于 android/ios 目录） |
+| `interfaces[].memberName` | 接口成员名 | 平台特有接口判定（特征 1：是否包含平台关键词） |
+| `interfaces[].className` | 类名 | 平台特有接口判定（特征 1：是否包含平台关键词） |
+| `interfaces[].signature` | 接口签名 | 平台特有接口判定（特征 3/5：是否标注平台限定或引用平台专有类型） |
+| `summary.N` | 总接口数 | 检视概览 |