@ohos-cpf/3rdloop 0.0.1 → 0.0.3

package/vendor/Server/Skills/rnoh-lib-version-diff/scripts/package.json

@@ -1,5 +1,5 @@
-{
-  "type": "commonjs",
-  "private": true,
-  "comment": "Override parent package.json type:module to allow CommonJS require() in .js scripts"
-}
+{
+  "type": "commonjs",
+  "private": true,
+  "comment": "Override parent package.json type:module to allow CommonJS require() in .js scripts"
+}

package/vendor/Server/Skills/rnoh-lib-version-diff/templates/report-template.md

@@ -1,137 +1,180 @@
-# 三方库版本分析报告：{repo-name}
-
-**生成日期：** {YYYY-MM-DD}
-**鸿蒙化仓库：** {owner}/{repo}
-**上游 npm 包名：** {package-name}
-
----
-
-## 基本信息
-
-| 项目 | 值 |
-|------|-----|
-| 鸿蒙化仓库 | {owner}/{repo} |
-| 上游仓库 | {upstream-url} |
-| 上游 npm 包名 | {package-name} |
-| 当前 RNOH 版本 | {当前分支版本，如 0.77} |
-| 目标 RNOH 版本 | {目标版本，如 0.84} |
-| 升级类型 | 类型 A（上游版本升级 + 框架适配） / 类型 B（纯框架适配） |
-| 库类型 libraryType | {native-harmony / js-only-harmony / pure-js} |
-
----
-
-## 版本差距
-
-| 项目 | 值 |
-|------|-----|
-| 鸿蒙化基线版本 | v{version} |
-| npm 最新版本 | v{version} |
-| 版本状态 | {落后 N 个小版本 / ✅ 最新 / 超前} |
-| 最近版本列表 | {v1}, {v2}, {v3}, ... |
-
----
-
-## 差异概览（仅类型 A）
-
-- 变更文件数：{N} 个
-- 新增文件：{N} 个
-- 删除文件：{N} 个
-- 修改文件：{N} 个
-- 净增行数：+{N} / -{N}
-
-### 变更摘要（按模块分类）
-
-| 模块 | 变更说明 | 影响程度 | 文件数 |
-|------|----------|----------|--------|
-| JS/TS 公共 API | {说明} | 高/中/低 | {n} |
-| TurboModule Spec | {说明} | 高/中/低 | {n} |
-| Android 原生 | {说明} | 高/中/低 | {n} |
-| iOS 原生 | {说明} | 高/中/低 | {n} |
-| 构建/依赖 | {说明} | 高/中/低 | {n} |
-| 文档/测试/CI | {说明} | 高/中/低 | {n} |
-
----
-
-## 升级风险评估
-
-| 风险等级 | 判定依据 |
-|----------|----------|
-| 🟢 低风险 | 仅补丁版本差距，无 breaking change |
-| 🟡 中风险 | 小版本差距，有 API 变更但向后兼容 |
-| 🔴 高风险 | 大版本差距，有 breaking change 或原生层重构 |
-
-**当前评估：** {风险等级} — {判定依据说明}
-
----
-
-## 鸿蒙 API 核查（涉及原生能力时必填）
-
-> 凡涉及原生能力的需适配项，须使用 `devecocli docs search` 完成核查后再写结论。
-> 纯 JS 库标注「不适用 API 核查」并跳过下表。流程见 [references/OHOS_API_LOOKUP.md](../references/OHOS_API_LOOKUP.md)。
-
-| 上游能力 | 上游实现摘要 | 鸿蒙 Kit/API | 能力对比 | 约束与风险 | 可行性 | 建议动作 | 核查状态 |
-|----------|--------------|-------------|----------|------------|--------|----------|----------|
-| {capability} | {android_ios_summary} | {kit + api + 搜索关键词} | 一致/子集/无对等 | {docs_constraints} | ✅/⚠️/🔶/❌ | {harmony_files_strategy} | 分析中/已完成 |
-
----
-
-## 鸿蒙化适配分析
-
-> 判断规则见 [references/OHOS_ADAPTATION.md](../references/OHOS_ADAPTATION.md)。
-
-### 需适配项
-
-| 序号 | 上游变更 | 鸿蒙侧动作 | 优先级 | 适配依据 |
-|------|----------|------------|--------|----------|
-| 1 | {upstream_change} | {ohos_action} | 高/中/低 | {引用 API 核查表行号} |
-
-### 无需适配项
-
-- {no_adapt_item_1}
-
-### RNOH 框架版本变化（类型 B 或跨版本升级时填写）
-
-| 项目 | 当前版本 | 目标版本 |
-|------|----------|----------|
-| react-native | ... | ... |
-| react | ... | ... |
-| @react-native-oh/react-native-harmony | ... | ... |
-| CLI | ... | ... |
-
-### 需关注的适配点
-
-（列出 ETS 业务代码、Package 注册代码、C++ 层依赖的 RNOH API，
-以及 generated/ 代码需重新 codegen 的说明）
-
----
-
-## 差异文件位置（仅类型 A）
-
-> 工作目录：`{output-dir}`
-
-| 文件 | 完整路径 | 说明 |
-|------|----------|------|
-| 源码目录 (基线) | `{output-dir}/{b1}/` | 基线版本源码导出 |
-| 源码目录 (目标) | `{output-dir}/{b2}/` | 目标版本源码导出 |
-| diff patch | `{output-dir}/diff_{b1}_{b2}.patch` | JS/TS 核心文件变更补丁 |
-| 变更摘要 | `{output-dir}/summary_{b1}_{b2}.md` | 按文件统计增删行数 |
-| 接口差异检查清单 | `{output-dir}/api-diff_{b1}_{b2}.md` | TurboModule Spec 差异 |
-| 适配分析报告 | `{output-dir}/structure_{b1}_{b2}.md` | 接口驱动的适配分析 |
-
----
-
-## 升级步骤建议
-
-1. 从当前分支创建新的目标分支
-2. {类型 A：应用上游 diff patch 合并 JS 变更 / 类型 B：跳过}
-3. 更新 package.json / oh-package.json5 中的 RNOH 依赖版本
-4. 使用目标版本 CLI 重新执行 codegen
-5. 验证 RNOH API 兼容性（ETS/C++ 层）
-6. {类型 A：适配鸿蒙原生层变更 / 类型 B：跳过}
-7. 编译构建验证 + 功能测试
-
----
-
-## 下一步建议
-
-→ 使用 code-adapt skill 进行代码适配与编译验证
+# 三方库版本分析报告：{repo-name}
+
+**生成日期：** {YYYY-MM-DD}
+**鸿蒙化仓库：** {owner}/{repo}
+**上游 npm 包名：** {package-name}
+
+---
+
+## 基本信息
+
+| 项目 | 值 |
+|------|-----|
+| 鸿蒙化仓库 | {owner}/{repo} |
+| 上游仓库 | {upstream-url} |
+| 上游 npm 包名 | {package-name} |
+| 当前 RNOH 版本 | {当前分支版本，如 0.77} |
+| 目标 RNOH 版本 | {目标版本，如 0.84} |
+| 升级类型 | 类型 A（上游版本升级 + 框架适配） / 类型 B（纯框架适配） |
+| 库类型 libraryType | {native-harmony / js-only-harmony / pure-js} |
+
+---
+
+## 版本差距
+
+| 项目 | 值 |
+|------|-----|
+| 鸿蒙化基线版本 | v{version} |
+| 任务指定对比版本 | v{version}（与 latest 不同时填写） |
+| npm 最新版本 (dist-tags.latest) | v{version} |
+| 版本状态 | {落后 N 个小版本 / ✅ 最新 / 超前} |
+| 至任务指定版本差距 | {落后 N 个版本，主要变更概述} |
+| 至 npm latest 差距 | {落后 N 个版本，latest 增量说明（如仅 patch 修复），可提示顺带对齐} |
+| 最近版本列表 | {v1}, {v2}, {v3}, ... |
+
+---
+
+## 分支-基线核验（任务指定分支/基线与仓库不符时必填）
+
+> 以 `README.OpenSource` Version Number（最可靠）+ `git log --all --grep` + `git branch -a --contains` 核验；不符时以实际核验结果为准，并在报告开篇澄清。
+
+| 分支 | package.json 版本 | README.OpenSource 上游基线 | 说明 |
+|------|------------------|---------------------------|------|
+| {branch} | {version} | {version} | {如：任务指定分支，实际基线为 X} |
+| {branch} | {version} | {version} | {如：任务指定基线实际所在分支} |
+
+---
+
+## 自动判定修正（人工复核推翻脚本结论时必填）
+
+> 脚本（rn-scan-exports.cjs）自动判定仅覆盖 TurboModule Spec；Fabric 组件 Spec 变更须人工 diff `codegenNativeComponent` 输入文件复核。下游请勿直接采信 `api-diff_*.md` 的自动结论。
+
+| 项目 | 内容 |
+|------|------|
+| 脚本自动结论 | {如：✅ 无需原生适配 — 接口未变更} |
+| 修正后结论 | {如：需要原生适配（类型 A）} |
+| 修正原因 | {如：Fabric 组件 Spec 新增 N props + M 事件，为 codegen 直接输入} |
+
+---
+
+## 差异概览（仅类型 A）
+
+- 变更文件数：{N} 个
+- 新增文件：{N} 个
+- 删除文件：{N} 个
+- 修改文件：{N} 个
+- 净增行数：+{N} / -{N}
+
+### 变更摘要（按模块分类）
+
+| 模块 | 变更说明 | 影响程度 | 文件数 |
+|------|----------|----------|--------|
+| JS/TS 公共 API | {说明} | 高/中/低 | {n} |
+| TurboModule Spec | {说明} | 高/中/低 | {n} |
+| Fabric 组件 Spec | {说明} | 高/中/低 | {n} |
+| Android 原生 | {说明} | 高/中/低 | {n} |
+| iOS 原生 | {说明} | 高/中/低 | {n} |
+| 构建/依赖 | {说明} | 高/中/低 | {n} |
+| 文档/测试/CI | {说明} | 高/中/低 | {n} |
+
+---
+
+## 上游→鸿蒙目录映射（仅类型 A）
+
+> 鸿蒙化仓库并非原样保留上游 src/ 结构。Phase 2 筛选与后续 code-adapt 阶段按此表转写文件变更，不得假设鸿蒙仓库保留上游目录结构。
+
+| 类别 | 上游路径 | 鸿蒙仓库对应 | 说明 |
+|------|----------|-------------|------|
+| Fabric 组件 Spec | {path} | {path} | {重命名/扩展说明} |
+| TurboModule Spec | {path} | {path} | |
+| types | {path} | {path} | |
+| 平台实现 | {X.android.tsx / X.ios.tsx} | {X.tsx 自有实现等} | |
+| codegen 入口 | — | {scripts/codegen-lib.js 等} | {react-native-harmony-cli 调用方式、输出目录} |
+
+---
+
+## 升级风险评估
+
+| 风险等级 | 判定依据 |
+|----------|----------|
+| 🟢 低风险 | 仅补丁版本差距，无 breaking change |
+| 🟡 中风险 | 小版本差距，有 API 变更但向后兼容 |
+| 🔴 高风险 | 大版本差距，有 breaking change 或原生层重构 |
+
+**当前评估：** {风险等级} — {判定依据说明}
+
+> ⚠️ major 版本跨度 ≠ breaking change：须逐条核对 CHANGELOG / GitHub Releases 的 breaking 项是否触及 **JS 层接口契约**（原生侧 only 的 breaking 属性可降级处理）。
+
+---
+
+## 鸿蒙 API 核查（涉及原生能力时必填）
+
+> 凡涉及原生能力的需适配项，须使用 `devecocli docs search` 完成核查后再写结论。
+> 纯 JS 库标注「不适用 API 核查」并跳过下表。流程见 [references/OHOS_API_LOOKUP.md](../references/OHOS_API_LOOKUP.md)。
+
+| 上游能力 | 上游实现摘要 | 鸿蒙 Kit/API | 能力对比 | 约束与风险 | 可行性 | 建议动作 | 核查状态 |
+|----------|--------------|-------------|----------|------------|--------|----------|----------|
+| {capability} | {android_ios_summary} | {kit + api + 搜索关键词} | 一致/子集/无对等 | {docs_constraints} | ✅/⚠️/🔶/❌ | {harmony_files_strategy} | 分析中/已完成 |
+
+---
+
+## 鸿蒙化适配分析
+
+> 判断规则见 [references/OHOS_ADAPTATION.md](../references/OHOS_ADAPTATION.md)。
+
+### 需适配项
+
+| 序号 | 上游变更 | 鸿蒙侧动作 | 优先级 | 适配依据 |
+|------|----------|------------|--------|----------|
+| 1 | {upstream_change} | {ohos_action} | 高/中/低 | {引用 API 核查表行号} |
+
+### 无需适配项
+
+- {no_adapt_item_1}
+
+### RNOH 框架版本变化（类型 B 或跨版本升级时填写）
+
+| 项目 | 当前版本 | 目标版本 |
+|------|----------|----------|
+| react-native | ... | ... |
+| react | ... | ... |
+| @react-native-oh/react-native-harmony | ... | ... |
+| CLI | ... | ... |
+
+### 需关注的适配点
+
+（列出 ETS 业务代码、Package 注册代码、C++ 层依赖的 RNOH API，
+以及 generated/ 代码需重新 codegen 的说明）
+
+---
+
+## 差异文件位置（仅类型 A）
+
+> 工作目录：`{output-dir}`
+
+| 文件 | 完整路径 | 说明 |
+|------|----------|------|
+| 源码目录 (基线) | `{output-dir}/{b1}/` | 基线版本源码导出 |
+| 源码目录 (目标) | `{output-dir}/{b2}/` | 目标版本源码导出 |
+| diff patch | `{output-dir}/diff_{b1}_{b2}.patch` | JS/TS 核心文件变更补丁 |
+| 变更摘要 | `{output-dir}/summary_{b1}_{b2}.md` | 按文件统计增删行数 |
+| 接口差异检查清单 | `{output-dir}/api-diff_{b1}_{b2}.md` | TurboModule Spec 差异 |
+| 适配分析报告 | `{output-dir}/structure_{b1}_{b2}.md` | 接口驱动的适配分析 |
+
+---
+
+## 升级步骤建议
+
+1. 从当前分支创建新的目标分支
+2. {类型 A：应用上游 diff patch 合并 JS 变更 / 类型 B：跳过}
+3. 更新 package.json / oh-package.json5 中的 RNOH 依赖版本
+4. 使用目标版本 CLI 重新执行 codegen
+5. 验证 RNOH API 兼容性（ETS/C++ 层）
+6. {类型 A：适配鸿蒙原生层变更 / 类型 B：跳过}
+7. 编译构建验证 + 功能测试
+
+---
+
+## 下一步建议
+
+→ 使用 code-adapt skill 进行代码适配与编译验证

package/vendor/Server/Skills/rnoh-lib-xts-coverage/SKILL.md

@@ -1,145 +1,145 @@
----
-name: rnoh-lib-xts-coverage
-description: 分析 RN 鸿蒙三方库现有测试用例对接口的覆盖情况。通过 rn-analyze-test-coverage.cjs 脚本一步完成接口提取、测试覆盖率匹配和 Markdown 报告生成。当需要对 RN 鸿蒙三方库的测试用例进行接口覆盖率分析时调用。
-license: Apache-2.0
-compatibility: 需要 Node.js 运行环境
-metadata:
-  version: "1.1.0"
-  category: rn-testing
-  language: JavaScript/TypeScript
-  useWhen: 分析 RN 鸿蒙三方库测试用例对接口的覆盖情况
-  consumed-by: rnohLibTestAlignSkill
----
-
-# RN 鸿蒙三方库测试用例接口覆盖率分析
-
-通过 `rn-analyze-test-coverage.cjs` 脚本一步完成接口提取、测试覆盖率匹配和 Markdown 报告生成，无需中间文件。
-
-> ⚠️ **核心约束**：基于静态 import 和接口调用分析，动态调用（`obj[methodName]()`）无法识别。
-
----
-
-## 脚本依赖
-
-本 Skill 直接调用以下本地脚本完成全部分析工作：
-
-```
-3rdLibraryLoop/MCP/scripts/rn-analyze-test-coverage.cjs
-```
-
-**调用方式**：通过 `node` 命令行直接执行，使用 `--` 参数传参。
-
----
-
-## 任务参数
-
-| 参数 | 类型 | 必填 | 说明 |
-|------|------|------|------|
-| `libroot` | string | ✅* | 库根目录路径（RN 三方库的鸿蒙化仓库目录，包含 `package.json`） |
-| `spec` | string | ✅* | 已有的 interface-spec.json 路径（与 `libroot` 二选一） |
-| `output` | string | ❌ | 输出 Markdown 报告路径，默认 `03-{库名}-Test覆盖率报告.md` |
-| `title` | string | ❌ | 报告标题 |
-| `mode` | string | ❌ | 匹配模式: `auto`(默认) \| `ast` \| `regex` |
-| `version` | string | ❌ | 上游 npm 版本号（如 `4.7.3`），未指定时自动从 dependencies/README 推断；⚠️ 勿用库自身 `package.json.version`（RNOH 库 version 常为团队自编版本号，非上游版本） |
-| `src` | string | ❌ | 测试源码目录覆盖，默认自动检测 |
-| `local-spec` | boolean | ❌ | 启用本地 `src/` 作为接口规格来源（默认从上游 npm 提取），用于 RNOH 扩展型库避免本地独有 API 盲区 |
-
-> `libroot` 与 `spec` 至少提供一个。提供 `spec` 时跳过接口提取步骤直接使用；仅提供 `libroot` 时脚本自动从源码提取接口（必要时拉取上游 npm 源码）。
-
-**派生变量**：
-- `skillDir`：本 Skill 所在目录
-- `scriptPath`：分析脚本路径 = `{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs`
-
----
-
-## 执行命令
-
-```bash
-node "{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs" \
-  --libroot "{{libroot}}" \
-  [--output "{{output}}"] [--title "{{title}}"] [--mode auto|ast|regex] [--version "{{上游版本}}"] [--src "{{测试源码目录}}"] [--local-spec]
-```
-
-或从已有 interface-spec.json 生成：
-
-```bash
-node "{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs" \
-  --spec "{{spec}}" --libroot "{{libroot}}" [--output "{{output}}"]
-```
-
-其中：
-- `{{skillDir}}` = SKILL.md 所在目录
-- `{{libroot}}` = RN 三方库的鸿蒙化仓库根目录
-- `{{workspaceRoot}}` = `3rdLibraryLoop` 工作区根目录
-
----
-
-## 脚本自动完成
-
-1. 获取接口规格（从 `--spec` 指定的 JSON 读取，或从 `libroot` 源码自动提取，必要时拉取上游 npm 源码 `index.js`/`index.d.ts` 及本地 TurboModule Spec `Native*.ts`）
-2. 自动检测测试源码目录（按优先级查找）：
-   - `example/src/test`、`example/src/tests`、`example/__tests__`
-   - `example/src/`（递归）、`example/src/*/`（RN3rdTemplate RNTesterList 模式 A：`example/src/<LibName>/`）
-   - `demo/__tests__`、`demo/src/test`、`demo/src/tests`
-   - `__tests__`、`test`、`tests`
-3. 递归扫描测试源码目录下所有 `.ts`、`.tsx`、`.js`、`.jsx`、`.ets` 文件（排除 `node_modules`、`harmony`、`android`、`ios`、`__mocks__`）
-4. 提取 `import { ... } from 'lib'` 语句（ES Module 默认/命名/别名/混合导入、CommonJS require、side-effect import）
-5. AST/正则双层匹配：静态方法、实例方法（追踪变量声明与类型）、链式调用、对象字面量属性、默认导入命名空间宽松兜底
-6. 直接渲染输出 Markdown 覆盖率报告
-
----
-
-## 库源码目录结构约定
-
-```
-{{libroot}}/
-  ├── package.json                     ← 库 package.json（依赖中含上游 npm 包名）
-  ├── src/                             ← JS 层导出源码
-  ├── harmony/                         ← 鸿蒙化原生代码（ArkTS/C++，扫描时排除）
-  ├── __tests__/                       ← 测试源码（自动检测目录之一）
-  └── example/
-      ├── __tests__/                   ← 测试源码（自动检测目录之一）
-      ├── src/test/                    ← 测试源码（自动检测目录之一）
-      └── ...
-```
-
-> 脚本自动检测测试目录，无需手动指定 `--src`；如自动检测失败或多目录共存，可用 `--src` 显式指定。
-> ⚠️ 使用 `rn-lib-add-example`（RN3rdTemplate 模板）创建的 example 工程，其 demo 位于 `example/src/<LibName>/`，需显式 `--src example/src`（或 `--src example/src/<LibName>`）。
-
----
-
-## 输入依赖
-
-- **前置SKILL**: rnoh-lib-code-adapt（可选；测试源码通常来自 rnoh-lib-test-align 的移植产物）
-- **输入文件**: 库源码目录（含 `package.json` 和测试源码目录）
-- **输出文件**: Markdown 覆盖率报告（脚本直接生成）
-
----
-
-## 输出
-
-生成 Markdown 报告，包含以下章节：
-- **基本信息**：库名、源文件数、生成时间
-- **覆盖率总览**：方法级覆盖率百分比、S/N/M 统计、进度条
-- **按接口类型统计**：method/constructor/property/field/enumValue/function/variable/type 分类别覆盖率
-- **类级覆盖率**：按类分组的覆盖明细（按覆盖率升序排列）
-- **未覆盖接口详情**：按类分组的未覆盖接口清单（含参数、返回类型、说明）
-- **已覆盖接口详情**：按类分组的已覆盖接口清单（含签名和覆盖来源文件）
-- **文件覆盖详情**：每个测试文件覆盖的接口数和接口列表
-- **覆盖率提升建议**：按优先级排列的未覆盖接口补充清单
-
-> 当未找到测试源文件时，报告会标注「无测试文档声明」并列出所有接口为未覆盖。
-
----
-
-## 注意事项
-
-1. **确定性**：所有计数和匹配由脚本完成，同一组输入必定产生相同输出
-2. **子目录排除**：自动排除 `node_modules`、`harmony`、`android`、`ios`、`__mocks__` 等目录
-3. **构造函数和枚举**：已在接口提取阶段排除
-4. **动态调用限制**：`obj[methodName]()` 无法识别；**命令式组件**（`forwardRef` + `useImperativeHandle` + `ref.current.method()`）的 ref 调用同样无法被 AST 归因，覆盖率会被低估。对这类库应更看重 field/props 层与 Hook 层指标，方法层覆盖率仅供参考
-5. **模式选择**：`auto` 优先 AST 匹配（需 TypeScript 模块），失败时降级正则；`ast` 强制 AST；`regex` 强制正则
-6. **版本推断**：未传 `--version` 时，脚本从 `package.json` 的 `dependencies` 或 README 自动推断上游 npm 版本号
-   > ⚠️ **版本核对**：RNOH 库的 `package.json.version` 常为团队自编版本号（非上游 npm 版本），勿直接用作 `--version`。执行前应先 `npm view <上游包名> versions --json` 核对真实可用版本，选择与本地 `src/` API 风格匹配的主版本线（看标志性导出符号，如 v4 的 `useCameraDevice`/`takePhoto` vs v5 的 `useCamera`/`CameraController`）。
-   > ⚠️ **降级风险**：若指定 `--version` 在 npm 不存在而脚本自动降级到 `latest`，且 `latest` 主版本号与指定版本不同（跨 major），可能导致拉取到重构后完全不兼容的 API 面（如 vision-camera 4.x→5.x）。务必核对降级后的 API 一致性，必要时显式指定同主版本最大号。
-7. **本地扩展 API 盲区**：接口规格默认取自上游 npm，本地 RNOH 扩展 API（未出现在上游导出中）不计入分母，覆盖率被轻微高估且扩展 API 不会出现在未覆盖清单中。使用 `--local-spec` 以本地 `src/index.tsx` 导出为规格来源可缓解此盲区。
+---
+name: rnoh-lib-xts-coverage
+description: 分析 RN 鸿蒙三方库现有测试用例对接口的覆盖情况。通过 rn-analyze-test-coverage.cjs 脚本一步完成接口提取、测试覆盖率匹配和 Markdown 报告生成。当需要对 RN 鸿蒙三方库的测试用例进行接口覆盖率分析时调用。
+license: Apache-2.0
+compatibility: 需要 Node.js 运行环境
+metadata:
+  version: "1.1.0"
+  category: rn-testing
+  language: JavaScript/TypeScript
+  useWhen: 分析 RN 鸿蒙三方库测试用例对接口的覆盖情况
+  consumed-by: rnohLibTestAlignSkill
+---
+
+# RN 鸿蒙三方库测试用例接口覆盖率分析
+
+通过 `rn-analyze-test-coverage.cjs` 脚本一步完成接口提取、测试覆盖率匹配和 Markdown 报告生成，无需中间文件。
+
+> ⚠️ **核心约束**：基于静态 import 和接口调用分析，动态调用（`obj[methodName]()`）无法识别。
+
+---
+
+## 脚本依赖
+
+本 Skill 直接调用以下本地脚本完成全部分析工作：
+
+```
+3rdLibraryLoop/MCP/scripts/rn-analyze-test-coverage.cjs
+```
+
+**调用方式**：通过 `node` 命令行直接执行，使用 `--` 参数传参。
+
+---
+
+## 任务参数
+
+| 参数 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `libroot` | string | ✅* | 库根目录路径（RN 三方库的鸿蒙化仓库目录，包含 `package.json`） |
+| `spec` | string | ✅* | 已有的 interface-spec.json 路径（与 `libroot` 二选一） |
+| `output` | string | ❌ | 输出 Markdown 报告路径，默认 `03-{库名}-Test覆盖率报告.md` |
+| `title` | string | ❌ | 报告标题 |
+| `mode` | string | ❌ | 匹配模式: `auto`(默认) \| `ast` \| `regex` |
+| `version` | string | ❌ | 上游 npm 版本号（如 `4.7.3`），未指定时自动从 dependencies/README 推断；⚠️ 勿用库自身 `package.json.version`（RNOH 库 version 常为团队自编版本号，非上游版本） |
+| `src` | string | ❌ | 测试源码目录覆盖，默认自动检测 |
+| `local-spec` | boolean | ❌ | 启用本地 `src/` 作为接口规格来源（默认从上游 npm 提取），用于 RNOH 扩展型库避免本地独有 API 盲区 |
+
+> `libroot` 与 `spec` 至少提供一个。提供 `spec` 时跳过接口提取步骤直接使用；仅提供 `libroot` 时脚本自动从源码提取接口（必要时拉取上游 npm 源码）。
+
+**派生变量**：
+- `skillDir`：本 Skill 所在目录
+- `scriptPath`：分析脚本路径 = `{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs`
+
+---
+
+## 执行命令
+
+```bash
+node "{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs" \
+  --libroot "{{libroot}}" \
+  [--output "{{output}}"] [--title "{{title}}"] [--mode auto|ast|regex] [--version "{{上游版本}}"] [--src "{{测试源码目录}}"] [--local-spec]
+```
+
+或从已有 interface-spec.json 生成：
+
+```bash
+node "{{skillDir}}/../../../MCP/scripts/rn-analyze-test-coverage.cjs" \
+  --spec "{{spec}}" --libroot "{{libroot}}" [--output "{{output}}"]
+```
+
+其中：
+- `{{skillDir}}` = SKILL.md 所在目录
+- `{{libroot}}` = RN 三方库的鸿蒙化仓库根目录
+- `{{workspaceRoot}}` = `3rdLibraryLoop` 工作区根目录
+
+---
+
+## 脚本自动完成
+
+1. 获取接口规格（从 `--spec` 指定的 JSON 读取，或从 `libroot` 源码自动提取，必要时拉取上游 npm 源码 `index.js`/`index.d.ts` 及本地 TurboModule Spec `Native*.ts`）
+2. 自动检测测试源码目录（按优先级查找）：
+   - `example/src/test`、`example/src/tests`、`example/__tests__`
+   - `example/src/`（递归）、`example/src/*/`（RN3rdTemplate RNTesterList 模式 A：`example/src/<LibName>/`）
+   - `demo/__tests__`、`demo/src/test`、`demo/src/tests`
+   - `__tests__`、`test`、`tests`
+3. 递归扫描测试源码目录下所有 `.ts`、`.tsx`、`.js`、`.jsx`、`.ets` 文件（排除 `node_modules`、`harmony`、`android`、`ios`、`__mocks__`）
+4. 提取 `import { ... } from 'lib'` 语句（ES Module 默认/命名/别名/混合导入、CommonJS require、side-effect import）
+5. AST/正则双层匹配：静态方法、实例方法（追踪变量声明与类型）、链式调用、对象字面量属性、默认导入命名空间宽松兜底
+6. 直接渲染输出 Markdown 覆盖率报告
+
+---
+
+## 库源码目录结构约定
+
+```
+{{libroot}}/
+  ├── package.json                     ← 库 package.json（依赖中含上游 npm 包名）
+  ├── src/                             ← JS 层导出源码
+  ├── harmony/                         ← 鸿蒙化原生代码（ArkTS/C++，扫描时排除）
+  ├── __tests__/                       ← 测试源码（自动检测目录之一）
+  └── example/
+      ├── __tests__/                   ← 测试源码（自动检测目录之一）
+      ├── src/test/                    ← 测试源码（自动检测目录之一）
+      └── ...
+```
+
+> 脚本自动检测测试目录，无需手动指定 `--src`；如自动检测失败或多目录共存，可用 `--src` 显式指定。
+> ⚠️ 使用 `rn-lib-add-example`（RN3rdTemplate 模板）创建的 example 工程，其 demo 位于 `example/src/<LibName>/`，需显式 `--src example/src`（或 `--src example/src/<LibName>`）。
+
+---
+
+## 输入依赖
+
+- **前置SKILL**: rnoh-lib-code-adapt（可选；测试源码通常来自 rnoh-lib-test-align 的移植产物）
+- **输入文件**: 库源码目录（含 `package.json` 和测试源码目录）
+- **输出文件**: Markdown 覆盖率报告（脚本直接生成）
+
+---
+
+## 输出
+
+生成 Markdown 报告，包含以下章节：
+- **基本信息**：库名、源文件数、生成时间
+- **覆盖率总览**：方法级覆盖率百分比、S/N/M 统计、进度条
+- **按接口类型统计**：method/constructor/property/field/enumValue/function/variable/type 分类别覆盖率
+- **类级覆盖率**：按类分组的覆盖明细（按覆盖率升序排列）
+- **未覆盖接口详情**：按类分组的未覆盖接口清单（含参数、返回类型、说明）
+- **已覆盖接口详情**：按类分组的已覆盖接口清单（含签名和覆盖来源文件）
+- **文件覆盖详情**：每个测试文件覆盖的接口数和接口列表
+- **覆盖率提升建议**：按优先级排列的未覆盖接口补充清单
+
+> 当未找到测试源文件时，报告会标注「无测试文档声明」并列出所有接口为未覆盖。
+
+---
+
+## 注意事项
+
+1. **确定性**：所有计数和匹配由脚本完成，同一组输入必定产生相同输出
+2. **子目录排除**：自动排除 `node_modules`、`harmony`、`android`、`ios`、`__mocks__` 等目录
+3. **构造函数和枚举**：已在接口提取阶段排除
+4. **动态调用限制**：`obj[methodName]()` 无法识别；**命令式组件**（`forwardRef` + `useImperativeHandle` + `ref.current.method()`）的 ref 调用同样无法被 AST 归因，覆盖率会被低估。对这类库应更看重 field/props 层与 Hook 层指标，方法层覆盖率仅供参考
+5. **模式选择**：`auto` 优先 AST 匹配（需 TypeScript 模块），失败时降级正则；`ast` 强制 AST；`regex` 强制正则
+6. **版本推断**：未传 `--version` 时，脚本从 `package.json` 的 `dependencies` 或 README 自动推断上游 npm 版本号
+   > ⚠️ **版本核对**：RNOH 库的 `package.json.version` 常为团队自编版本号（非上游 npm 版本），勿直接用作 `--version`。执行前应先 `npm view <上游包名> versions --json` 核对真实可用版本，选择与本地 `src/` API 风格匹配的主版本线（看标志性导出符号，如 v4 的 `useCameraDevice`/`takePhoto` vs v5 的 `useCamera`/`CameraController`）。
+   > ⚠️ **降级风险**：若指定 `--version` 在 npm 不存在而脚本自动降级到 `latest`，且 `latest` 主版本号与指定版本不同（跨 major），可能导致拉取到重构后完全不兼容的 API 面（如 vision-camera 4.x→5.x）。务必核对降级后的 API 一致性，必要时显式指定同主版本最大号。
+7. **本地扩展 API 盲区**：接口规格默认取自上游 npm，本地 RNOH 扩展 API（未出现在上游导出中）不计入分母，覆盖率被轻微高估且扩展 API 不会出现在未覆盖清单中。使用 `--local-spec` 以本地 `src/index.tsx` 导出为规格来源可缓解此盲区。