@ohos-cpf/3rdloop 0.0.1

package/vendor/Server/Skills/arkts-library-interface-spec/SKILL.md

@@ -0,0 +1,97 @@
+---
+name: arkts-library-interface-spec
+description: 扫描提取鸿蒙ArkTs原生库源码中对外公开的方法级接口与接口签名，解析 Index.ets 导出链，生成接口规格文档，涵盖导出类、方法和函数。只分析对外公开导出项，输出完整接口签名（含参数、返回值、JSDoc）。当需要对鸿蒙原生库进行方法级接口规格提取、接口签名清单生成、Index.ets 导出链分析时调用。
+license: Apache-2.0
+compatibility: 适用于鸿蒙原生库工程（含 library 模块和 Index.ets 入口文件）。需要 git 命令行工具（用于克隆源码）和 Node.js（运行提取脚本）。
+metadata:
+  version: "1.1.0"
+  category: harmonyos-development
+  language: ArkTS/ETS
+  useWhen: 从鸿蒙原生库源码提取方法级接口规格时
+---
+
+# 鸿蒙ArkTs原生库方法级接口规格提取
+
+通过源码静态分析提取鸿蒙原生库所有对外公开导出的方法级接口，自动生成标准化的接口规格说明文档。
+
+> ⚠️ **核心原则：只分析对外公开导出的接口，不关注内部实现细节。所有输出内容必须来自实际源码，禁止推断或捏造任何接口、参数、类型或功能描述。**
+
+---
+
+## 任务参数
+
+| 参数 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `outputDir` | string | ✅ | 工作目录（仓库源码克隆/复用位置，也是所有产物的输出根目录） |
+| `reportPath` | string | ✅ | 报告输出路径（必须位于 `outputDir` 下，禁止指向 `repoDir` 内部，避免污染源码） |
+| `repoUrl` | string | ✅ | 仓库 Git 地址 |
+| `repoDir` | string | ❌ | 仓库源码目录（**显式覆盖**）。前置源码下载步骤已将源码克隆到固定路径时传入（如 `outputDir/source`），此时跳过步骤 0 的克隆，直接复用 |
+
+**派生变量**：
+- `repoName`：从 `repoUrl` 提取仓库名（取 URL 最后一段，去掉 `.git` 后缀）
+- `repoDir`：仓库源码目录 = 任务参数显式指定的值（优先）；否则 = `outputDir/repoName`
+- `mcpScriptsDir`：MCP 脚本目录 = `3rdLibraryLoop/MCP/scripts`（相对于 workspace 根目录）
+
+---
+
+## 输入依赖
+
+- **前置 SKILL**：无（可独立执行；若编排中存在前置源码下载步骤，则通过 `repoDir` 参数复用已克隆源码，跳过克隆）
+- **输入文件**：无（通过 `repoUrl` 克隆源码，或复用 `repoDir` 指定的已有源码）
+- **下游消费者**：`ArkTsLibraryDemoCoverageSkill`（`parse-spec.cjs` 解析本 Skill 生成的报告）、`ArkTsLibraryDemoScenarioSkill`、`ArkTsLibraryXTSDocSkill`、ArkTS 仓库检视流程的各检视 SKILL（稳定性/内存泄露/文档质量/用例覆盖度）
+
+---
+
+## 工作流程
+
+### 步骤 0：准备仓库源码（复用或克隆）
+
+**目标：** 确保 `repoDir` 下存在仓库源码。优先复用已存在的仓库源码，避免重复克隆。
+
+> ⚠️ **前置源码已就位时直接复用**：若任务参数显式提供了 `repoDir`（如源码已由前置源码下载 SKILL 克隆到 `outputDir/source`），先用 `list_dir` 验证该目录下存在源码（`.git` 子目录、`library/index.ets`（大小写不敏感，`Index.ets`/`index.ets` 皆可）、`oh-package.json5` 任一即可），验证通过后**跳过本步骤的全部克隆操作**，直接以该 `repoDir` 进入步骤 1。
+
+1. **提取仓库名**：从 `repoUrl` 末尾取仓库名，去掉 `.git` 后缀，确定 `repoDir = outputDir/repoName`
+
+2. **扫描工作目录**：用 `list_dir` 列出 `outputDir` 下所有条目，判定是否为可复用的仓库源码（满足其一即可）：
+   - 目录名与 `repoName` 一致；或
+   - 目录内含 `.git` 子目录；或
+   - 目录内含 `library/index.ets` 或 `library/src/main/ets/index.ets`（**大小写不敏感**，`Index.ets`/`index.ets` 皆可；部分移植库入口为小写，属正常结构）
+
+3. **条件克隆**：若不存在可用仓库：
+   ```bash
+   git clone --depth=1 {{repoUrl}} {{outputDir}}/{{repoName}}
+   ```
+   失败时去掉 `--depth=1` 改为完整克隆。克隆后用 `list_dir` 确认 `repoDir/library` 存在。
+
+> ⚠️ 若所有克隆方式均失败，在报告中说明原因并标注 `状态: 失败`，终止后续步骤。
+> ⚠️ 克隆目标为 `outputDir/repoName`（仓库名目录），**不要**克隆到 `outputDir/source`。
+
+---
+
+### 步骤 1：运行脚本生成接口规格文档
+
+> ⚠️ **本步骤严格使用本地脚本实现，禁止 AI 手工解析源码。** `render-spec-doc.cjs` 一条命令完成全部工作：TypeScript Compiler API 语义分析 → Index.ets 导出链追踪 → Native `.so` 检测 → 接口成员提取 → JSDoc 提取 → Markdown 文档渲染。无中间 JSON 文件。
+>
+> ⚠️ **输出路径约束**：`--output` 必须指向 `outputDir` 下的路径（如 `outputDir/interface-spec.md`），**禁止**写入 `repoDir`（clone 代码目录）内部，避免污染源码目录。
+
+```bash
+node "{{mcpScriptsDir}}/render-spec-doc.cjs" --libroot "{{repoDir}}" --output "{{reportPath}}"
+```
+
+脚本自动输出包含基本信息、接口统计、按类/接口分节（方法/属性/字段/枚举值/函数/变量/类型别名/事件方法汇总）、源文件列表的完整 Markdown 报告。
+
+**验证**：确认脚本退出码为 0、报告文件已生成。若脚本报错（如无法定位 index.ets），检查 `repoDir` 路径是否正确、仓库是否含 `library/index.ets` 或 `library/src/main/ets/index.ets`（**大小写不敏感**，`Index.ets`/`index.ets` 皆可，可用 `ls | grep -i index` 探测实际入口文件名）。
+
+> ⚠️ **移植库结构说明**：部分 Java 移植库（如 CPF-ApplicationTPC 系列的 mp3agic）入口为小写 `library/index.ets`，实现源码为 `.ts` 扩展名且位于 `library/src/main/ets/components/<libname>/` 下——这是移植工程的常见模式，属正常结构，`render-spec-doc.cjs` 可直接解析，无需人工干预。切勿因入口文件大小写差异误判"仓库缺少入口文件"（Linux 等大小写敏感文件系统上尤其注意）。
+
+---
+
+## 输出产物
+
+| 产物 | 文件名 | 说明 |
+|------|--------|------|
+| 接口规格说明文档 | `{reportPath}`（约定为 `{outputDir}/接口规格说明.md`） | 对外公开导出项的完整接口签名清单 |
+
+> ⚠️ **输出文件自检**：写入结果文件前，先确认 `reportPath` 指定的接口规格说明文档已存在且内容完整（**独立文件，禁止只写入 result 执行结果文件**）。若文档内容仅在草稿中，必须先将其保存为该独立文件。
+
+本 SKILL 无评分，无需输出结构化指标文件。

package/vendor/Server/Skills/arkts-library-memory-leak-check/SKILL.md

@@ -0,0 +1,392 @@
+---
+name: arkts-library-memory-leak-check
+description: 对 ArkTS 鸿蒙化库进行内存泄露检视，聚焦 ArkTS/ETS 与 C/C++ NAPI 绑定代码中的生命周期管理、系统资源释放、NAPI 引用管理、事件订阅管理、闭包与上下文泄露等维度，识别潜在内存泄露风险，生成严苛评分报告（0-100分）。作为 ArkTS 仓库检视流程的第四阶段。
+license: Apache-2.0
+compatibility: 需要访问 Git 仓库、分析 ArkTS/ETS 及 C/C++ NAPI 绑定源码
+metadata:
+  author: CPPAgent
+  version: "1.0.0"
+---
+
+# ArktsLibraryMemoryLeakCheckSkill
+
+对**已鸿蒙化的 ArkTS 库**进行内存泄露风险检视，识别 ArkTS/ETS 层与 C/C++ NAPI 绑定层代码中的潜在内存泄露问题，评估资源管理安全性。
+
+> ⚠️ **核心定位**：ArkTS 鸿蒙化库的内存泄露检视，**覆盖 ArkTS/ETS 层与 C/C++ NAPI 绑定层**，重点关注生命周期管理、系统资源释放、NAPI 引用管理、闭包上下文泄露、跨语言资源释放一致性等问题。
+
+---
+
+## 任务参数
+
+| 参数 | 必需 | 说明 |
+|------|------|------|
+| `repoUrl` | ✅ | Git 仓库地址，支持分支参数 `?branch=xxx` |
+| `outputDir` | ✅ | 输出目录绝对路径，存放检视报告 |
+| `interfaceDocPath` | ✅ | 接口规格说明文档路径（由 library-interface-analyzer 生成） |
+| `repoName` | ✅ | 仓库名称（用于报告标识） |
+
+---
+
+## 输入依赖
+
+本 SKILL 是 ArkTS 仓库检视流程的**第四阶段**，依赖：
+
+- **前置 SKILL**: `arkts-library-interface-spec`（接口规格说明已生成）
+- **输入文件**: `接口规格说明.md`（位于 outputDir）；`编码质量检视报告.md` 为**可选参考**（若本地流程无编码质量检视 SKILL，跳过该参考，独立完成检视）
+- **仓库源码**: 已克隆到 `{outputDir}/source/`
+
+> 💡 **利用前置报告**：参考编码质量检视报告中标记的架构问题和代码规范问题，重点关注其中涉及的资源管理相关代码段。
+
+---
+
+## 工作流程
+
+### Phase 1：源码范围识别
+
+**分层扫描**仓库中的鸿蒙化代码文件：
+
+1. **ArkTS/ETS 层**：扫描 `.ets`、`.ts`、`.json5` 文件
+2. **C/C++ NAPI 绑定层**：扫描 `.cpp`、`.c`、`.h`、`.hpp` 文件（重点关注 NAPI 绑定入口）
+
+**⚠️ 排除范围规则**：仅检视库的**核心源码**，以下目录和文件必须排除，不纳入内存泄露分析：
+
+| 排除类别 | 目录/文件特征 | 说明 |
+|----------|--------------|------|
+| Demo/示例用例 | `demo/`、`example/`、`examples/`、`sample/`、`samples/` 目录，文件名含 `demo`、`example`、`sample` | 示例代码仅用于演示库用法，不属于库的核心实现 |
+| 单元测试 | `test/`、`tests/`、`__tests__/`、`spec/`、`unittest/` 目录，文件名含 `test`、`spec`、`unittest` | 测试代码验证库功能而非生产运行，其资源管理模式与核心源码不同 |
+| 集成测试 | `integration-test/`、`e2e/`、`itest/` 目录 | 同上，非核心源码 |
+| 测试工具/辅助 | `mock/`、`fixture/`、`stub/`、`fuzz/` 目录 | 测试辅助代码不属于库运行时逻辑 |
+
+> **原则**：核心源码指库在**生产运行时**实际执行的代码，即被外部应用调用的公开 API 实现、内部模块逻辑、NAPI 绑定层。Demo 和测试代码中即使存在资源管理问题，也不影响库的实际运行安全性，因此不应纳入检视和评分。
+
+```bash
+# ArkTS/ETS 层（排除 demo 与测试）
+find {{outputDir}}/source -type f \( -name "*.ets" -o -name "*.ts" -o -name "*.json5" \) \
+  -not -path "*/demo/*" -not -path "*/example/*" -not -path "*/examples/*" \
+  -not -path "*/sample/*" -not -path "*/samples/*" \
+  -not -path "*/test/*" -not -path "*/tests/*" -not -path "*/__tests__/*" \
+  -not -path "*/spec/*" -not -path "*/unittest/*" \
+  -not -path "*/integration-test/*" -not -path "*/e2e/*" \
+  -not -path "*/mock/*" -not -path "*/fixture/*" \
+  -not -path "*/fuzz/*" -not -path "*/stub/*" \
+  -not -name "*demo*" -not -name "*example*" -not -name "*sample*" \
+  -not -name "*test*" -not -name "*spec*" -not -name "*unittest*"
+
+# C/C++ NAPI 绑定层（排除 demo 与测试）
+find {{outputDir}}/source -type f \( -name "*.cpp" -o -name "*.c" -o -name "*.h" -o -name "*.hpp" \) \
+  -not -path "*/demo/*" -not -path "*/example/*" -not -path "*/examples/*" \
+  -not -path "*/sample/*" -not -path "*/samples/*" \
+  -not -path "*/test/*" -not -path "*/tests/*" -not -path "*/unittest/*" \
+  -not -path "*/integration-test/*" -not -path "*/e2e/*" \
+  -not -path "*/mock/*" -not -path "*/fixture/*" \
+  -not -path "*/fuzz/*" -not -path "*/stub/*" \
+  -not -name "*demo*" -not -name "*example*" -not -name "*sample*" \
+  -not -name "*test*" -not -name "*unittest*" \
+  | xargs grep -l "napi_" 2>/dev/null || true
+```
+
+> `workdir: "{{outputDir}}"`
+
+### Phase 2：逐文件内存泄露分析
+
+对每个源码文件进行内存泄露检视，重点关注以下 7 个维度：
+
+#### 2.1 ArkTS 生命周期管理
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| aboutToDisappear 未清理 | Critical | 组件销毁时未释放资源/移除监听/断开连接 |
+| @State 大对象泄露 | Major | @State 变量持有大对象引用（如大数组/Map），组件销毁后未主动置空 |
+| @Link/@Prop 双向绑定泄露 | Major | 双向绑定在组件销毁后未断开，父组件仍持有子组件引用 |
+| 页面栈泄露 | Major | router.pushUrl 后未调用 router.back，页面未正确弹出 |
+| PersistentStorage 泄露 | Minor | 持久化存储键未在组件销毁时清理 |
+| CustomComponent 引用泄露 | Major | 父组件通过引用持有已销毁子组件实例 |
+
+#### 2.2 系统资源释放
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| Sensor 未注销 | Critical | sensor.on() 后无对应 sensor.off() |
+| Location 未关闭 | Critical | geoLocationManager 开启后未关闭 |
+| Network 连接未断开 | Major | HTTP/WebSocket 连接未调用 disconnect/close |
+| Timer 未清除 | Major | setInterval/setTimeout 未在生命周期结束时 clearInterval/clearTimeout |
+| Worker 未终止 | Major | Worker 创建后未调用 terminate |
+| Bitmap/Image 未释放 | Major | 图片资源未调用 recycle/release |
+| media.AVPlayer 未释放 | Major | AVPlayer 创建后未调用 release |
+| webview.WebView 未销毁 | Major | WebView 未正确销毁，可能持有 JS 上下文引用 |
+| XMLParser/JSONParser 未释放 | Minor | 解析器资源未释放 |
+| 数据库连接未关闭 | Critical | rdb 关闭未调用 close |
+
+#### 2.3 事件订阅管理
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| CommonEvent 未取消订阅 | Critical | emitter.subscribe/on() 后无 unsubscribe/off() |
+| Callback 未移除 | Major | 注册的回调在组件销毁时未移除 |
+| Listener on/off 不匹配 | Major | on/off 注册与移除次数不匹配 |
+| 全局事件泄露 | Critical | 全局事件订阅未在组件生命周期中管理 |
+| emitter 持久订阅泄露 | Major | emitter.on() 使用 Persistent 选项但无取消机制 |
+
+#### 2.4 闭包与上下文泄露
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| 闭包持有组件引用 | Major | 闭包捕获 this/组件引用，组件销毁后闭包仍存活 |
+| 全局回调持有组件上下文 | Critical | 全局注册的回调函数持有组件实例引用 |
+| 异步回调持有 stale context | Major | setTimeout/Promise 回调中引用已销毁组件上下文 |
+| 静态大对象缓存泄露 | Minor | 全局 Map/Array/缓存未在适当时机清理 |
+
+#### 2.5 NAPI 引用管理（ArkTS 层视角）
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| napi_create_reference 未释放 | Critical | napi_create_reference 后无 napi_delete_reference |
+| napi_handle_scope 泄露 | Major | napi_open_handle_scope 后无 napi_close_handle_scope |
+| napi_callback_info 泄露 | Minor | 回调信息未正确处理释放 |
+| ArrayBuffer 外部资源泄露 | Major | napi_create_external ArrayBuffer 的 finalize 回调缺失或未正确释放 |
+
+#### 2.6 C/C++ 层内存泄露
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| malloc/free 不匹配 | Critical | malloc 后无 free，或 calloc/realloc 后未释放 |
+| new/delete 不匹配 | Critical | new 后无 delete，new[] 后用 delete（而非 delete[]） |
+| 智能指针循环引用 | Critical | shared_ptr 循环引用导致引用计数永不为零 |
+| NAPI Native 对象泄露 | Critical | napi_wrap 包装的 Native 对象在 finalize 中未释放 |
+| 智能指针误用 | Major | unique_ptr 被 raw pointer 接管后未管理 |
+| 全局/静态缓冲区无限增长 | Major | 全局 vector/map 无上限增长，缺少清理机制 |
+| RAII 覆盖不全 | Major | 未使用 RAII 管理 C++ 资源（如文件句柄、锁） |
+| 内存池未释放 | Minor | 自定义内存池/allocator 未在析构时释放 |
+
+#### 2.7 跨语言资源释放一致性
+
+| 检查项 | 严重度 | 说明 |
+|--------|--------|------|
+| ArkTS on/C++ resource 不对称释放 | Critical | ArkTS 层调用 off() 但 C++ 层未释放对应资源，或反过来 |
+| Native 对象生命周期不一致 | Critical | C++ Native 对象与 ArkTS 包装对象生命周期不一致 |
+| finalize 回调缺失 | Critical | napi_wrap 未提供 finalize 回调，Native 对象无法被回收 |
+| 跨语言回调链泄露 | Major | C++ 层回调引用 ArkTS 函数，双向引用未正确断开 |
+
+### Phase 3：内存泄露评分计算
+
+基于检视结果进行**严苛评分**（0-100分），采用维度加权扣分与零容忍规则：
+
+#### 3.1 扣分规则
+
+```
+基础分 = 100
+
+标准扣分（按问题数量叠加）：
+- Critical 级别问题：每项 -20 分（上限 -60）
+- Major 级别问题：每项 -10 分（上限 -40）
+- Minor 级别问题：每项 -4 分（上限 -16）
+
+零容忍加重扣分（叠加于标准扣分之上）：
+- napi_ref/NAPI finalize 缺失：每项额外 -5 分（上限 -15）
+- malloc/free 或 new/delete 不匹配：每项额外 -5 分（上限 -15）
+- 闭包持有组件引用 + 全局事件泄露组合：额外 -10 分（上限 -10）
+
+最终分 = max(0, 基础分 - 标准扣分 - 零容忍加重扣分)
+```
+
+#### 3.2 维度子评分计算
+
+每个维度独立计算子评分（用于报告中明细展示）：
+
+```
+维度基础分 = 100
+维度扣分：
+  - 该维度 Critical 问题：每项 -20（上限 -60）
+  - 该维度 Major 问题：每项 -10（上限 -40）
+  - 该维度 Minor 问题：每项 -4（上限 -16）
+维度分 = max(0, 维度基础分 - 维度扣分)
+```
+
+#### 3.3 综合评分 = 各维度子评分加权平均
+
+```
+综合评分 = (
+  生命周期管理分 × 0.15 +
+  系统资源释放分 × 0.20 +
+  事件订阅管理分 × 0.15 +
+  闭包与上下文泄露分 × 0.10 +
+  NAPI 引用管理分 × 0.15 +
+  C/C++ 层内存泄露分 × 0.20 +
+  跨语言一致性分 × 0.05
+)
+```
+
+> **重要**：当综合评分与"基础分 - 总扣分"不一致时，取两者中的**较低值**作为最终综合评分。这确保了零容忍加重扣分和维度加权不会导致评分偏高。
+
+#### 3.4 评分标准说明
+
+| 分数区间 | 等级 | 说明 |
+|----------|------|------|
+| 95-100 分 | 优秀 | 资源管理完善，无任何泄露风险 |
+| 85-94 分 | 良好 | 仅存在少量 Minor 级别风险，无 Major/Critical 问题 |
+| 70-84 分 | 一般 | 存在 Major 级别泄露，需针对性修复 |
+| 55-69 分 | 较差 | 存在 Critical 级别泄露风险，内存安全受威胁 |
+| <55 分 | 严重不足 | 多个 Critical 泄露问题，内存风险极高，不可发布 |
+
+> ⚠️ **严苛标准**：内存泄露不同于一般代码质量问题，一旦发生即造成持续损害。因此 85 分以下即不建议发布，55 分以下视为严重不可用。
+
+### Phase 4：报告生成
+
+在 `{outputDir}` 下生成 `内存泄露检视报告.md`，格式如下：
+
+```markdown
+# {repoName} 内存泄露检视报告
+
+## 一、检视概览
+
+| 字段 | 内容 |
+|------|------|
+| **仓库名称** | {repoName} |
+| **检视类型** | ArkTS 内存泄露检视 |
+| **检视时间** | {timestamp} |
+| **分析文件数（ArkTS层）** | {etsFileCount} |
+| **分析文件数（C/C++层）** | {cppFileCount} |
+
+## 二、综合评分
+
+**综合评分：{score}/100**
+
+> 评分等级：{level}。{levelDescription}
+
+### 扣分明细
+
+| 扣分项 | 数量 | 单项扣分 | 小计 | 上限 |
+|--------|------|----------|------|------|
+| Critical 标准扣分 | {criticalCount} | -20 | {criticalTotal} | -60 |
+| Major 标准扣分 | {majorCount} | -10 | {majorTotal} | -40 |
+| Minor 标准扣分 | {minorCount} | -4 | {minorTotal} | -16 |
+| napi_ref/finalize 零容忍加重 | {napiCriticalCount} | -5 | {napiExtraTotal} | -15 |
+| malloc/new 零容忍加重 | {memCriticalCount} | -5 | {memExtraTotal} | -15 |
+| 闭包+全局事件组合加重 | {comboCount} | -10 | {comboExtraTotal} | -10 |
+
+## 三、检视维度明细
+
+### 3.1 ArkTS 生命周期管理
+
+**维度评分：{dim1Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.2 系统资源释放
+
+**维度评分：{dim2Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.3 事件订阅管理
+
+**维度评分：{dim3Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.4 闭包与上下文泄露
+
+**维度评分：{dim4Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.5 NAPI 引用管理
+
+**维度评分：{dim5Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.6 C/C++ 层内存泄露
+
+**维度评分：{dim6Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+### 3.7 跨语言资源释放一致性
+
+**维度评分：{dim7Score}/100**
+
+| 检查项 | 严重度 | 发现数量 | 详情 |
+|--------|--------|----------|------|
+| …… | …… | …… | …… |
+
+## 四、泄露风险清单
+
+| # | 文件 | 行号 | 语言层 | 严重度 | 泄露类型 | 泄露描述 | 影响范围 | 修复建议 |
+|---|------|------|--------|--------|----------|----------|----------|----------|
+| …… | …… | …… | ArkTS/C++ | …… | …… | …… | …… | …… |
+
+> **语言层**列标注问题所在的代码层：`ArkTS`（ETS/TS 层）或 `C++`（Native 层）或 `跨语言`（涉及两层交互）。
+
+## 五、改进建议
+
+### 5.1 Critical 级别修复优先级
+
+（列出所有 Critical 问题的修复建议，按影响排序）
+
+### 5.2 Major 级别修复建议
+
+……
+
+### 5.3 通用改进方案
+
+……
+
+---
+
+**报告生成时间**：{timestamp}
+```
+
+> **重要**：
+> 1. 报告必须包含 `**综合评分：XX/100**` 格式，以便后端 `_parseArktsLibraryScore` 函数自动解析评分。
+> 2. 每个维度必须包含 `**维度评分：XX/100**` 格式。
+> 3. 泄露风险清单必须标注 **语言层**（ArkTS/C++/跨语言）。
+
+---
+
+## 输出产物
+
+| 产物 | 文件名 | 说明 |
+|------|--------|------|
+| 内存泄露检视报告 | `内存泄露检视报告.md` | 综合评分 + 扣分明细 + 7维度评分 + 泄露清单 + 修复建议 |
+
+所有产物写入 `{outputDir}` 目录。
+
+> ⚠️ **输出文件自检**：写入结果文件前，先确认 `内存泄露检视报告.md` 已存在且内容完整（**独立文件，禁止只写入 result 执行结果文件**）。若报告内容仅在草稿中，必须先将其保存为上述独立文件。
+
+### 结构化指标输出（必须执行）
+
+执行环境会在任务 prompt 中下发一个**结构化指标文件输出路径**（`stepId{X}_loop{L}_meta_{N}.json`）。
+检视完成后，**必须**将最终评分以下述 JSON 对象写入该路径：
+
+```json
+{
+  "memoryLeakScore": 85,
+  "scoreReason": "Critical泄露1处-20等（一句话判定依据，≤50字；触发零容忍规则时必须注明）"
+}
+```
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `memoryLeakScore` | number | 内存泄露评分（0-100 整数，与报告中 `**综合评分：XX/100**` 的数值一致） |
+| `scoreReason` | string | 评分判定依据摘要（可选，前端悬浮提示展示；0 分时强烈建议写明触发的扣分/零容忍规则） |
+
+**说明**：该文件由执行框架自动收割入库（前端/历史列表直接读取评分，无需解析报告文本）。若 prompt 未下发该路径则跳过本节。
+
+---
+
+## 评分权重
+
+本 SKILL 在 ArkTS 仓库检视综合评分中权重为 **25%**。

package/vendor/Server/Skills/arkts-library-source-clone/SKILL.md

@@ -0,0 +1,113 @@
+---
+name: arkts-library-source-clone
+description: 克隆鸿蒙 ArkTS 三方库 Git 仓库源码到工作目录的固定路径 source/ 目录下（git clone，支持分支/子路径），并记录克隆元信息。作为 ArkTS 仓库检视流程的第一阶段（源码准备），供后续接口分析与各维度检视 SKILL 复用。当需要下载/克隆 ArkTS 三方库源码到固定路径时调用。
+license: Apache-2.0
+compatibility: 需要 git 命令行工具和网络访问（Gitee/GitCode/GitHub）。
+metadata:
+  version: "1.1.0"
+  category: harmonyos-development
+  language: ArkTS/ETS
+  useWhen: ArkTS 仓库检视流程第一步，克隆仓库源码到 {outputDir}/source/ 固定路径
+---
+
+# ArkTS 三方库源码下载（固定路径克隆）
+
+将 ArkTS 三方库仓库源码克隆到工作目录的**固定路径** `{outputDir}/source/`，供后续接口分析（arkts-library-interface-spec）与各维度检视 SKILL 直接复用。
+
+> ⚠️ **核心原则**：源码必须克隆到 `{outputDir}/source/` 固定路径（后续所有检视 SKILL 均从该路径读取源码）。**不要**克隆到 `{outputDir}/{仓库名}` 等其他目录。
+
+---
+
+## 任务参数
+
+| 参数 | 类型 | 必填 | 说明 |
+|------|------|------|------|
+| `outputDir` | string | ✅ | 工作目录（即任务下发的"工作目录"，绝对路径），源码克隆到 `outputDir/source/` |
+| `repoUrl` | string | ✅ | 仓库 Git 地址，支持分支参数 `?branch=xxx` 或 `/tree/xxx` 路径形式 |
+
+**派生变量**：
+- `repoName`：从 `repoUrl` 提取仓库名（取 URL 最后一段，去掉 `.git` 后缀，用于报告标识）
+- `sourceDir`：源码目录 = `outputDir/source`（**固定路径，禁止变更**）
+- `baseUrl`：去掉分支参数后的仓库基础地址
+
+---
+
+## 输入依赖
+
+- **前置 SKILL**：无（本 SKILL 是 ArkTS 仓库检视流程的第一阶段）
+- **输入文件**：无（通过 `repoUrl` 克隆源码）
+- **下游消费者**：`arkts-library-interface-spec`（接口分析）、`arkts-library-stability-check`、`arkts-library-memory-leak-check`、`arkts-library-documentation-quality-check`、`arkts-library-test-coverage-check`（均从 `{outputDir}/source/` 读取源码）
+
+---
+
+## 工作流程
+
+### 步骤 1：解析仓库地址
+
+从 `repoUrl` 解析出 `baseUrl` 与 `branch`：
+
+| URL 形式 | baseUrl | branch |
+|----------|---------|--------|
+| `https://gitee.com/openharmony-sig/lottie` | 同原 URL | 默认分支 |
+| `https://gitcode.com/xxx/repo/tree/dev_ohos` | `https://gitcode.com/xxx/repo` | `dev_ohos` |
+| `https://github.com/xxx/repo.git#branch=develop` | `https://github.com/xxx/repo.git` | `develop` |
+| `https://gitee.com/xxx/repo?branch=master` | `https://gitee.com/xxx/repo` | `master` |
+
+### 步骤 2：克隆源码到固定路径
+
+若 `sourceDir`（`outputDir/source`）已存在且含有效仓库源码（存在 `.git` 目录或 `oh-package.json5` / 入口文件，入口文件名大小写不敏感），直接复用，跳过克隆。
+
+否则执行克隆：
+
+```bash
+# 指定分支
+git clone --depth=1 -b {branch} {baseUrl} {outputDir}/source
+
+# 未指定分支（默认分支）
+git clone --depth=1 {baseUrl} {outputDir}/source
+```
+
+克隆失败时按序降级重试：
+1. 去掉 `--depth=1` 改为完整克隆
+2. 去掉 `-b {branch}`（克隆默认分支后 `git checkout {branch}`，失败则使用默认分支）
+
+> ⚠️ 判定克隆失败以**命令退出码非 0 或目标目录无仓库内容**为准。GitCode 仓库克隆时输出"警告：重定向到 .../xxx.git/"属**正常行为**（GitCode 自动补全 `.git` 后缀重定向），不代表克隆失败，**不应**因此触发降级重试。
+
+> ⚠️ 克隆目标必须是 `{outputDir}/source`（目录本身即仓库根），**不要**克隆成 `{outputDir}/source/{repoName}`。
+
+### 步骤 3：验证与记录元信息
+
+1. **验证**：用 `list_dir` 确认 `sourceDir` 下存在源码文件（`.ets` / `.ts` / `oh-package.json5` / 入口文件 / `module.json5` 任一即可）
+
+   > ⚠️ **验证注意事项**：
+   > - **入口文件大小写不敏感**：ArkTS 库入口文件可能是 `index.ets`（小写，如 mp3agic）或 `Index.ets`（大写），两者均视为有效。macOS（大小写不敏感文件系统）上按字面匹配可偶然命中，但在 Linux（大小写敏感文件系统）上按字面匹配会漏判，匹配时必须显式做大小写不敏感处理。
+   > - **源码文件可能是 `.ts` 扩展名**：部分 ArkTS 库（如 mp3agic，`src/main/ets/` 下 48 个源文件全部为 `.ts`）的实现源码是 `.ts` 文件，`library/` 下仅入口 `index.ets` 一个 `.ets` 文件。**禁止以 `.ets` 文件数量作为源码存在的唯一判据**，应以 `oh-package.json5` / `module.json5` / 入口文件的存在为准。
+
+2. **记录元信息**：将克隆信息写入 `{outputDir}/clone-info.json`：
+
+```json
+{
+  "repoUrl": "{原始 repoUrl}",
+  "baseUrl": "{baseUrl}",
+  "branch": "{branch 或 null}",
+  "commit": "{git rev-parse HEAD 结果}",
+  "repoName": "{repoName}",
+  "sourceDir": "{outputDir}/source",
+  "cloneTime": "{timestamp}"
+}
+```
+
+3. **失败处理**：若所有克隆方式均失败，在结果文件中说明失败原因并标注 `状态: 失败`，终止后续步骤。
+
+---
+
+## 输出产物
+
+| 产物 | 文件名 | 说明 |
+|------|--------|------|
+| 仓库源码 | `{outputDir}/source/` | 固定路径，后续所有检视 SKILL 的源码输入 |
+| 克隆元信息 | `{outputDir}/clone-info.json` | baseUrl / branch / commit / repoName |
+
+> ⚠️ **下游消费提示**：库实现源码文件可能为 `.ts` 扩展名（如 mp3agic），下游 SKILL 扫描源码时应同时包含 `*.ets` 与 `*.ts`（路径限定在 `src/main/ets/` 下），入口统一从 `index.ets` 解析导出。
+
+所有产物写入 `{outputDir}` 目录。本 SKILL 无评分，无需输出结构化指标文件。