@ohos-cpf/3rdloop 0.0.1

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

@@ -0,0 +1,52 @@
+# Phase 1：产物收集指南
+
+## 工作目录结构
+
+任务工作目录（`workDir`）通常包含以下文件：
+
+```
+{workDir}/
+├── stepId1_result_0.md       ← 步骤1第0次执行结果
+├── stepId1_Summary_0.md      ← 步骤1第0次执行摘要
+├── stepId2_result_0.md       ← 步骤2第0次执行结果
+├── stepId2_Summary_0.md      ← 步骤2第0次执行摘要
+├── stepId1_result_1.md       ← 步骤1第1次执行结果（重试）
+└── ...
+```
+
+## 收集策略
+
+1. **按 stepId 分组**：将同一步骤的所有产物归为一组
+2. **取最新 loopCount**：同一步骤多次执行时，取最后一次（loopCount 最大）的结果
+3. **结果文件优先**：result .md 包含执行状态和结论，是评估的主要依据
+4. **摘要文件辅助**：Summary .md 包含经验总结，可作为补充证据
+
+## 文件内容解析
+
+### result .md 格式
+
+```markdown
+## 执行状态
+成功 / 失败
+
+## 执行结果
+{具体执行内容和分析}
+```
+
+关键字段：
+- `## 执行状态` — 判断该步骤是否成功完成
+- `## 执行结果` — 获取步骤的产出内容
+
+### Summary .md 格式
+
+```markdown
+## 摘要
+{关键信息和经验总结}
+```
+
+## 产物完整性检查
+
+收集完成后，检查：
+- 每个步骤是否都有对应的 result 文件
+- 文件内容是否完整（非空）
+- 是否有步骤缺失产物（可能执行失败未生成）

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

@@ -0,0 +1,77 @@
+# Phase 2：验收标准评估指南
+
+## 评估原则
+
+1. **证据驱动**：每条标准的评估结论必须基于产物中的实际证据
+2. **逐条独立**：每条标准独立评估，不因其他标准通过/未通过而影响
+3. **可追溯**：记录评估依据，便于后续复核
+
+## 按 type 分类的评估策略
+
+### output（产物检查）
+
+验证目标：确认预期的产物文件/内容是否存在且完整。
+
+评估方法：
+- 检查产物文件是否存在
+- 检查文件内容是否非空
+- 检查内容是否包含预期的章节/维度
+- 检查格式是否符合要求
+
+示例：
+- 标准要求"产出完整的质量检查报告" → 检查报告文件是否存在、是否包含所有维度章节
+
+### quality（质量要求）
+
+验证目标：确认产物的质量是否达标。
+
+评估方法：
+- 检查分析深度是否足够
+- 检查覆盖范围是否完整
+- 检查结论是否有数据支撑
+- 检查建议是否具体可操作
+
+示例：
+- 标准要求"对高优先级问题提供具体代码位置和修复建议" → 检查报告中是否包含文件名、行号、修复方案
+
+### performance（性能指标）
+
+验证目标：确认性能相关指标是否满足要求。
+
+评估方法：
+- 检查扫描覆盖率
+- 检查执行时间是否在合理范围
+- 检查资源使用是否达标
+
+示例：
+- 标准要求"使用至少一种主流静态分析工具" → 检查报告中是否标注了工具名称和版本
+
+### compliance（合规性）
+
+验证目标：确认产物是否符合特定规范或标准。
+
+评估方法：
+- 检查是否引用了正确的规范标准
+- 检查是否符合规范的具体要求
+- 检查合规性检查项是否完整
+
+示例：
+- 标准要求"符合 OpenHarmony 编码规范" → 检查报告中是否引用了 OpenHarmony 社区规范
+
+## 评估结论记录
+
+每条标准的评估结果应包含：
+
+| 字段 | 说明 |
+|------|------|
+| id | 验收标准 ID |
+| criterion | 标准描述 |
+| satisfied | 是否满足（true/false） |
+| evidence | 支持结论的证据 |
+| note | 补充说明 |
+
+## 常见问题处理
+
+1. **产物缺失**：如果某个步骤的产物不存在，相关标准标记为"未满足"
+2. **产物不完整**：如果产物内容不完整，根据缺失程度判断
+3. **无法判断**：如果产物信息不足以判断，标记为"未满足"并说明原因

package/vendor/Server/Skills/arkts-code-check/SKILL.md

@@ -0,0 +1,314 @@
+---
+name: arkts-code-check
+description: 自动化检视 ArkTS 三方库 Pull Request，包括获取 PR 差异、深度分析代码变更、生成结构化检视报告。当用户需要对 ArkTS/OpenHarmony 三方库 PR 进行代码检视时调用。支持 GitCode、Gitee、GitHub、GitLab 平台。
+license: Apache-2.0
+compatibility: 需要 git、curl、网络访问代码仓库平台 API
+metadata:
+  version: "1.0.0"
+---
+
+# ArkTsCodeCheckSkill — ArkTS 三方库 PR 代码检视
+
+## 任务参数
+
+| 参数 | 必需 | 说明 |
+|------|------|------|
+| `prUrl` | ✅ | PR 地址，如 `https://gitee.com/openharmony-tpc/community/pulls/123` |
+| `outputDir` | ✅ | 输出目录绝对路径，如 `/path/to/codecheck/owner_repo_pr123` |
+| `branch` | ❌ | 目标分支名；若提供则优先使用 |
+| `accessToken` | ❌ | 平台 API 访问令牌 |
+
+---
+
+## 工作流程概览
+
+```
+Phase 1: 信息收集（含范围识别） → Phase 2: 差异分析 → Phase 3: 代码检视 → Phase 4: 影响分析 → Phase 5: 报告生成
+```
+
+---
+
+## Phase 1：信息收集
+
+### 1.1 解析 PR 地址
+
+从 `prUrl` 提取：`platform`、`owner`、`repo`、`prNumber`。
+
+> 详细步骤参见 [信息收集指南](references/PHASE1_INFO_COLLECTION.md)
+
+### 1.2 获取 PR 元数据
+
+```bash
+curl -s "https://api.gitcode.com/api/v5/repos/{owner}/{repo}/pulls/{prNumber}?access_token={accessToken}"
+```
+
+提取：`title`、`base.ref`、`head.sha`、`user.name`、`created_at`、`state`
+
+### 1.3 获取 Commit Patch（仅供参考）
+
+```bash
+curl -s "https://api.gitcode.com/api/v5/repos/{owner}/{repo}/commit/{head.sha}/patch?access_token={accessToken}" -o {outputDir}/pr.patch
+```
+
+返回最新 commit 的 patch，包含 commit 元数据（作者、日期、message）和单次 commit 的文件变更。
+
+> **注意**：
+> - 路径使用 `commit`（单数），不是 `commits`
+> - 此 patch 仅包含 PR **最新一次 commit** 的差异，不代表 PR 全量变更
+> - PR 若包含多个 commit，需使用 1.5 步骤的累积 diff 进行检视
+
+### 1.4 克隆仓库（必须）
+
+```bash
+git clone --depth=50 --branch {targetBranch} https://gitcode.com/{owner}/{repo}.git {outputDir}/source/
+```
+
+克隆后必须 fetch PR HEAD 并生成累积 diff（见 1.5）。
+
+### 1.5 获取 PR 累积差异（检视依据）
+
+> **核心步骤**：必须基于累积 diff 进行检视，而非单次 commit patch。
+
+```bash
+# 1. fetch PR HEAD 到本地分支
+cd {outputDir}/source/
+git fetch origin refs/merge-requests/{prNumber}/head:pr{prNumber}
+
+# 2. checkout PR 分支
+git checkout pr{prNumber}
+
+# 3. 生成累积 diff（base 分支 vs PR HEAD）
+git diff {targetBranch}..pr{prNumber} > {outputDir}/pr-diff-raw.txt
+```
+
+**为什么需要累积 diff**：
+- PR 可能包含多个 commit，单次 commit patch 无法反映全量变更
+- 本次检视中，head.sha patch 仅 1 个文件，但累积 diff 实际包含 21 个文件
+- 累积 diff 才是 PR 的真实变更范围
+
+**PR 更新检测**：
+- PR 推送新 commit 后 `head.sha` 会变化
+- 若 1.2 步骤获取的 `head.sha` 与上次不同，必须重新 fetch 并重新生成 `pr-diff.txt`
+- 已生成的报告文件也需重新生成
+
+### 1.6 识别 PR 检视范围（关键步骤）
+
+> **⚠️ 此步骤防止检视范围污染，是本次迭代新增的核心改进。**
+
+Monorepo（如 `openharmony_tpc_samples` 包含多个三方库子目录）中，fork 分支的 master 通常通过 merge commit 合入了其他 PR 的变更。此时 `git diff {targetBranch}..pr{prNumber}` 的累积 diff 会包含**不属于本 PR 意图范围**的文件变更（其他库的修改、删除等），导致检视误判。
+
+**识别方法**：
+
+1. 从 PR 标题提取目标库名称（如 `eventsource: fix: ...` → 目标库为 `eventsource`）
+2. 若标题不含库名，从 PR body（描述）或 commit message 中提取
+3. 若仍无法确定，取 PR 标题中第一个冒号前的部分，或取变更文件中最深层公共父目录
+
+**范围过滤**：
+
+```bash
+# 仅保留目标库目录下的 diff（关键：避免检视范围污染）
+git diff {targetBranch}..pr{prNumber} -- {targetLibraryDir}/ > {outputDir}/pr-diff.txt
+
+# 同时生成全量 diff 供参考（不用于检视，仅用于记录）
+# pr-diff-raw.txt 已在 1.5 中生成
+```
+
+**实际案例**：
+- PR #3042 标题为 `eventsource: fix: ...`，目标库为 `eventsource`
+- 累积 diff 包含 113 个文件（ohos_rive、ohos_7zip、spinec、GstreamerDemo 等），但仅 18 个 eventsource 文件属于本 PR
+- 若不过滤，ohos_rive 的内存安全回归会被误判为本 PR 的 Blocker，导致错误的 REJECT 结论
+- 过滤后仅检视 18 个 eventsource 文件，结果为 PASS
+
+**过滤后更新统计**：
+
+```bash
+# 重新统计（基于过滤后的 diff）
+git diff --stat {targetBranch}..pr{prNumber} -- {targetLibraryDir}/
+
+# 重新生成 changed-files.txt（基于过滤后的 diff）
+grep "^diff --git" {outputDir}/pr-diff.txt | sed 's/diff --git a\/.* b\/\//' > {outputDir}/changed-files.txt
+```
+
+> **原则**：检视应聚焦于 PR 的意图范围（单次提交涉及的目标库），不应将 fork 分支 divergent master 上的其他变更纳入检视和分级。
+
+---
+
+## Phase 2：差异分析
+
+> **必须基于 `pr-diff.txt`（经过范围过滤的累积 diff）进行分析，而非 `pr-diff-raw.txt`（全量累积 diff）或 `pr.patch`（单次 commit patch）**
+
+### 2.1 统计改动规模
+
+- 文件数、新增/删除行数：从 `pr-diff.txt` 统计，或使用 `git diff --stat {targetBranch}..pr{prNumber}`
+
+### 2.2 识别文件类型
+
+| 扩展名 | 类型 | 检视重点 |
+|--------|------|----------|
+| `.ets` | ArkTS | 语言约束、装饰器、UI |
+| `.ts` | TypeScript | 类型安全、异步 |
+| `oh-package.json5` | 配置 | 依赖版本 |
+| `module.json5` | 配置 | 权限、API Level |
+
+> 完整分类参见 [文件类型指南](references/FILE_TYPE_GUIDE.md)
+
+### 2.3 理解改动意图
+
+结合 PR 标题、commit message、diff 上下文分析修改目的。
+
+---
+
+## Phase 3：代码深度检视
+
+对每个 `.ets` / `.ts` 文件逐项检查。
+
+### 3.1 核心检视维度
+
+| 维度 | 检查要点 |
+|------|----------|
+| 非兼容变更 | 删除/修改公开 API、函数签名变更 |
+| ArkTS 约束 | 无 `any`、无动态代码、装饰器正确 |
+| API 兼容性 | minAPIVersion 匹配、权限正确 |
+| 异步处理 | await 不遗漏、try/catch 完整 |
+| 事件监听 | on/off 对称、生命周期正确 |
+| 错误处理 | 错误码完整、return/break 正确 |
+| 内存管理 | 监听器清理、定时器清除 |
+| 安全性 | 无硬编码密钥、输入校验 |
+
+> 完整检查清单参见 [代码检视指南](references/CODE_CHECK_GUIDE.md)
+
+### 3.2 问题严重程度
+
+| 级别 | 标识 | 说明 |
+|------|------|------|
+| Blocker | 🔴 | 必须修复，影响功能/安全/兼容 |
+| Major | 🟡 | 建议修复，存在风险 |
+| Minor | 🔵 | 优化建议 |
+
+---
+
+## Phase 4：影响分析
+
+综合评估：
+- **功能影响**：新功能或行为变更
+- **兼容性影响**：接口向后兼容性
+- **性能影响**：异步优化、对象创建等
+- **安全影响**：修复或引入安全问题
+
+---
+
+## Phase 5：生成报告
+
+输出文件：
+- `{outputDir}/check-report.md` — 检视报告
+- `{outputDir}/changed-files.txt` — 修改文件列表（基于范围过滤后的 diff 生成）
+- `{outputDir}/pr-diff.txt` — PR 累积差异（目标库目录范围内，检视核心依据）
+- `{outputDir}/pr-diff-raw.txt` — PR 全量累积差异（base → PR HEAD，仅供参考，不用于检视）
+- `{outputDir}/pr.patch` — 最新 commit patch（仅供 commit 元数据参考）
+- `{outputDir}/result.txt` — 合入建议分级结果
+
+> 报告模板参见 [报告模板](references/REPORT_TEMPLATE.md)
+
+### 5.1 合入建议分级标准
+
+根据代码检视结果，将合入建议分为四个等级：
+
+| 等级 | 标识 | 颜色建议 | 判断标准 | 举例场景 |
+|------|------|----------|----------|----------|
+| **建议合入** | ✅ `PASS` | 绿色 | 无或极少（≤2 Minor）修改引入问题，改动风险低，功能验证充分 | 纯文档更新、配置优化、已验证的 Bug 修复 |
+| **条件合入** | ⚠️ `CONDITIONAL` | 黄色 | 存在少量（≤3 Major）可修复问题，在特定条件下可合入 | 需补充测试用例、需调整文档说明、非核心路径兼容性问题 |
+| **修改后合入** | 🔧 `NEED_FIX` | 橙色 | 存在较多问题（≥1 Blocker 或 ≥4 Major），需修复后方可合入 | API 兼容性破坏、性能风险、内存泄漏、异步逻辑缺陷 |
+| **不允许合入** | ❌ `REJECT` | 红色 | 存在严重问题（≥2 Blocker），影响功能/安全/稳定性，不建议合入 | 安全漏洞、严重兼容性破坏、架构缺陷、未验证的重大变更 |
+
+**分级判断流程**：
+
+```
+统计问题数量：
+  - Blocker 级别问题数
+  - Major 级别问题数  
+  - Minor 级别问题数
+
+判断逻辑：
+  IF Blocker ≥ 2 → ❌ REJECT
+  IF Blocker ≥ 1 → 🔧 NEED_FIX
+  IF Major ≥ 4   → 🔧 NEED_FIX
+  IF Major ≥ 1   → ⚠️ CONDITIONAL
+  IF Minor ≤ 2   → ✅ PASS
+  ELSE           → ⚠️ CONDITIONAL
+```
+
+### 5.2 result.txt 文件格式
+
+`result.txt` 用于存储分级结果和统计信息，格式如下：
+
+```txt
+=== 合入建议分级报告 ===
+PR 地址：{prUrl}
+仓库：{owner}/{repo}
+PR 编号：#{prNumber}
+生成时间：{YYYY-MM-DD HH:mm:ss}
+
+【合入建议】：✅ 建议合入
+
+【问题统计】
+- Blocker 级别：0 个
+- Major 级别：0 个  
+- Minor 级别：2 个
+
+【分级理由】
+本次修改仅包含少量 Minor 级别优化建议，无功能性问题，改动风险低，建议直接合入。
+
+【详细分析】
+━━━ Minor 级别问题 ━━━
+1. [文件类型：代码质量] 删除了无用变量 `pairFlag`，代码更简洁
+2. [文件类型：可观测性] 错误信息从模糊描述改为包含 `e.code` 和 `e.message` 的格式
+
+━━━ 合入建议 ━━━
+建议合入：本次修改质量良好，无功能性风险。
+
+=== 分级结束 ===
+```
+
+### 5.3 结构化指标输出（必须执行）
+
+执行环境会在任务 prompt 中下发一个**结构化指标文件输出路径**（`stepId{X}_loop{L}_meta_{N}.json`）。
+检视完成后，**必须**将分级结果以下述 JSON 对象写入该路径：
+
+```json
+{
+  "mergeLevel": "PASS | CONDITIONAL | NEED_FIX | REJECT",
+  "blocker": 0,
+  "major": 0,
+  "minor": 0
+}
+```
+
+| 字段 | 类型 | 说明 |
+|------|------|------|
+| `mergeLevel` | string | 合入等级：PASS / CONDITIONAL / NEED_FIX / REJECT |
+| `blocker` | number | Blocker 级别问题数 |
+| `major` | number | Major 级别问题数 |
+| `minor` | number | Minor 级别问题数 |
+
+**说明**：该文件由执行框架自动收割入库（前端/历史列表直接读取，无需解析报告文本）；详细的统计与理由已在 `result.txt` 中完整记录。若 prompt 未下发该路径则跳过本节。
+
+---
+
+## 注意事项
+
+1. **必须克隆仓库**：用于深度检视和跨文件引用分析，不可仅凭 diff 下结论
+2. **必须使用累积 diff 进行检视**：`pr.patch`（单次 commit patch）可能仅包含部分变更，必须使用 `git diff {targetBranch}..pr{prNumber}` 生成的累积 diff。实际案例中 pr.patch 仅 1 个文件，但累积 diff 有 21 个文件
+3. **必须识别 PR 检视范围**（新增）：Monorepo 中 fork 分支的累积 diff 可能包含不属于本 PR 的其他库变更，必须根据 PR 标题/描述识别目标库目录，将 diff 限定在该范围内。实际案例：PR #3042 标题为 `eventsource: fix:`，但累积 diff 包含 113 个文件（含 ohos_rive、ohos_7zip 等），不过滤会导致误判 REJECT
+4. **克隆失败处理**：在报告中注明，继续基于 diff 完成分析
+5. **Patch 过大**：优先分析 `.ets`/`.ts` 文件，其余按改动量排序
+6. **PR 更新检测**：每次检视前重新获取 PR 元数据，对比 head.sha 是否变化；若变化，必须重新 fetch 并重新生成 pr-diff.txt 和所有报告
+7. **所有操作记录日志**：方便问题排查
+
+---
+
+## 快速参考
+
+- [信息收集详细指南](references/PHASE1_INFO_COLLECTION.md)
+- [代码检视检查清单](references/CODE_CHECK_GUIDE.md)
+- [检视报告模板](references/REPORT_TEMPLATE.md)
+- [文件类型识别指南](references/FILE_TYPE_GUIDE.md)

package/vendor/Server/Skills/arkts-code-check/references/CODE_CHECK_GUIDE.md

@@ -0,0 +1,160 @@
+# Phase 3：代码检视详细检查清单
+
+本文档包含 ArkTS 代码深度检视的完整检查项。
+
+---
+
+## 3.1 非兼容变更（Breaking Changes）
+
+**判断依据**：改动前的接口若有外部调用方，则为破坏性变更。
+
+检查项：
+- [ ] 是否删除或重命名了公开 API / 导出符号 / 接口方法
+- [ ] 是否修改了函数签名（参数数量、类型、顺序、返回类型）
+- [ ] 是否修改了数据结构的字段类型或字段名
+- [ ] 是否修改了错误码或返回值语义
+- [ ] 是否修改了配置文件格式（`oh-package.json5`、`module.json5`）
+
+---
+
+## 3.2 ArkTS 语言约束（严格模式合规性）
+
+- [ ] 无 `any` 类型使用（ArkTS 禁止 `as any`、隐式 any）
+- [ ] 无 `eval()`、`Function()` 动态代码执行
+- [ ] 无 `with` 语句
+- [ ] 无 `prototype` 动态修改
+- [ ] 无动态属性访问（`obj[dynamicKey]`）替代类型化接口
+- [ ] 接口声明使用 `interface` / `class`，非对象字面量类型构造函数
+- [ ] 枚举值使用 `enum`，非字符串字面量联合
+- [ ] 装饰器使用正确（`@Component`、`@State`、`@Prop`、`@Link`、`@Builder`、`@Observed` 等）
+- [ ] 泛型类型参数明确，避免推导歧义
+- [ ] 是否使用已废弃的 API（`@deprecated` 标注的接口）
+
+---
+
+## 3.3 OpenHarmony API 兼容性
+
+- [ ] 新增 API 使用是否超出工程 `minAPIVersion`（通常 API 12+）
+- [ ] 是否使用了 OHOS 专有 API 但未做平台判断（`deviceInfo.deviceType` 等）
+- [ ] 权限申请是否正确（`requestPermissionsFromUser`）
+- [ ] `OH_*` 系列 C API 的返回值是否有检查（Native 模块场景）
+
+---
+
+## 3.4 异步处理
+
+- [ ] 所有 `await` 调用不遗漏（BLE、网络、存储等异步 API）
+- [ ] try/catch 覆盖所有 `await` 调用，catch 块有实质性错误处理（非空 catch）
+- [ ] 嵌套 async 函数调用链中，返回的 Promise 均被正确 await
+- [ ] 未处理的 Promise rejection（`.catch()` 或 `try/catch` 必须存在）
+- [ ] 并行异步操作使用 `Promise.all`，避免不必要的顺序 await（性能）
+
+---
+
+## 3.5 事件监听器管理（on/off 对称性）
+
+### 通用检查项
+
+- [ ] 每个 `on('eventName', handler)` 有对应 `off('eventName', handler)` 或 `off('eventName')`
+- [ ] 监听器在组件/连接销毁时（`aboutToDisappear`、设备断开、`close` 前）被移除
+- [ ] 重连场景中同一事件多次调用 `on` 不会造成监听器堆积
+- [ ] 新增的事件监听类型在 `close` / `disconnect` 前有对应 `off`
+
+### BLE / 蓝牙特有检视点
+
+- [ ] `GattClientDevice` 对象不跨连接复用（重连时创建新实例）
+- [ ] 连接失败路径中所有注册的监听器均被清除
+- [ ] 多设备并发时，Map key 使用设备地址（`remoteId`）而非类成员变量
+- [ ] 状态变更回调使用正确的设备标识（`key`），而非可能过期的实例变量
+
+---
+
+## 3.6 索引变量与边界问题
+
+**索引变量误用示例**：
+```typescript
+// ❌ 错误
+for (let i = 0; i < services.length; i++) {
+  for (let j = 0; j < includeServices.length; j++) {
+    if (includeServices[i].uuid === target) { ... } // 应为 j
+  }
+}
+```
+
+检查项：
+- [ ] 嵌套循环中内层循环使用正确的索引变量
+- [ ] 查找逻辑中 null/undefined 判断方向正确（`== null` vs `!= null`）
+- [ ] 数组访问是否有越界风险（空数组判断）
+
+---
+
+## 3.7 错误处理
+
+- [ ] 错误信息包含错误码（`e.code`）和错误描述（`e.message`）
+- [ ] `result.error()` / `result.success()` 调用后有 `return`，避免后续代码继续执行
+- [ ] switch-case 中每个 case 末尾有 `break`（避免 fall-through）
+- [ ] 提前 `return` / `break` 不会跳过必要的资源清理
+
+---
+
+## 3.8 内存与资源管理
+
+- [ ] 事件监听器在适当时机 `off`（组件销毁、设备断开等）
+- [ ] 定时器（`setInterval`/`setTimeout`）有对应 `clearInterval`/`clearTimeout`
+- [ ] `ArrayBuffer` / `Uint8Array` 大数据用完后无强引用持有
+- [ ] Map / Set 数据结构在不再需要时及时 `delete` / `clear`
+
+---
+
+## 3.9 并发与线程安全
+
+- [ ] 是否在非 UI 线程访问 UI 组件（需通过 `TaskPool`/`Worker` 隔离）
+- [ ] async/await 使用正确，无遗漏 await 导致的竞态条件
+- [ ] 多设备并发连接场景下，变量为实例级而非全局/类级共享
+
+---
+
+## 3.10 性能问题
+
+- [ ] 列表渲染是否使用 `LazyForEach` + `@Reusable` 优化（大列表场景）
+- [ ] 是否有同步阻塞主线程的操作（应改用 `TaskPool`/`Worker`）
+- [ ] 是否存在不必要的全局变量或重复对象创建
+- [ ] 图片资源是否合理使用缓存，避免重复加载
+
+---
+
+## 3.11 安全性
+
+- [ ] 无硬编码的密钥、Token、密码、MAC 地址等敏感信息
+- [ ] 网络请求是否校验 HTTPS 证书（禁止忽略证书错误）
+- [ ] 用户输入是否有校验和过滤（防注入）
+- [ ] 文件路径是否有安全校验（防路径穿越）
+- [ ] 敏感数据是否在日志中输出（蓝牙配对码、账户信息等）
+
+---
+
+## 3.12 依赖与配置
+
+- [ ] `oh-package.json5` 新增依赖是否合理，来源是否可信
+- [ ] 版本号是否符合语义化版本规范（`^x.y.z`）
+- [ ] `minAPIVersion` / `targetAPIVersion` 变更是否合理
+- [ ] 是否存在不必要的依赖或版本锁定过死
+
+---
+
+## 3.13 代码规范
+
+- [ ] 命名遵循驼峰命名规则（变量/方法小驼峰，类/接口大驼峰）
+- [ ] 无冗余的 `console.log` 调试代码遗留
+- [ ] 公共 API 有完整 JSDoc 注释
+- [ ] 文件头版权声明完整
+
+---
+
+## 问题严重程度分级
+
+| 级别 | 标识 | 说明 |
+|------|------|------|
+| Blocker | 🔴 | 必须修复，会导致功能异常、崩溃、安全漏洞或破坏向后兼容性 |
+| Major | 🟡 | 强烈建议修复，存在潜在风险或明显质量问题 |
+| Minor | 🔵 | 优化建议，不影响功能，属于代码质量/可读性改进 |

package/vendor/Server/Skills/arkts-code-check/references/FILE_TYPE_GUIDE.md

@@ -0,0 +1,29 @@
+# 文件类型识别指南
+
+本文档说明如何识别和分类 PR 中修改的文件类型。
+
+---
+
+## 文件类型分类
+
+| 扩展名 | 类型 | 检视重点 |
+|--------|------|----------|
+| `.ets` | ArkTS 源文件 | 语言约束、装饰器、UI 逻辑 |
+| `.ts` | TypeScript | 类型安全、异步、事件监听 |
+| `CMakeLists.txt` / `*.cmake` | 构建系统 | Native 模块构建依赖 |
+| `build-profile.json5` | 工程配置 | API Level、签名 |
+| `oh-package.json5` | 包依赖 | 依赖版本、新增依赖合理性 |
+| `module.json5` / `app.json5` | 模块配置 | 权限申请、minAPIVersion |
+
+---
+
+## 改动性质分类
+
+| 性质 | 说明 |
+|------|------|
+| 新增功能 | 新增 API、组件、模块 |
+| 功能修复 | Bug 修复、逻辑修正 |
+| 功能优化 | 性能优化、重构 |
+| 配置更新 | 依赖、版本、权限变更 |
+| 文档更新 | 注释、README、文档 |
+| 测试补充 | 单元测试、集成测试 |