@ohos-cpf/3rdloop 0.0.2 → 0.0.3

package/vendor/Server/Skills/rn-library-issue-generalizer/assets/rule-template.md

@@ -1,25 +1,25 @@
-<!-- 规则条目模板：新建规则时复制本模板，填充所有字段后直接写入 rules/R-{XX}-{规则名}.md -->
-<!-- 状态标记：draft（泛化产出待审核）/ active（人工审核通过，检视 SKILL 消费）/ deprecated（废弃，注明原因） -->
-
-# R-{XX} {规则名，"类"结尾，≤20字，不含具体库名}
-
-- **状态**: active
-- **严重级别**: {high|medium|low}（{判定依据：high=核心功能不可用；medium=特定场景失效；low=体验问题}）
-- **适用范围**: {哪类库适用}
-  - 预筛特征: {可执行的预筛条件，如：依赖特征 / 文件特征 / API 特征，命中才进入深度检查}
-- **问题本质**: {一句话机制层描述，为什么这类问题会发生；禁止出现具体库名/API 名}
-- **检查点**:
-  1. {动词开头，读源码后可独立判定是/否/疑似}
-  2. {...}
-  3. {...}
-- **错误特征**: {源码中命中此类问题的典型形态，供模式匹配}
-- **正确特征**: {修复后的代码形态，供对照判定}
-
-## 来源案例
-
-<!-- 案例索引行：详情在 cases/ 下的独立文件（格式二），此处只放索引 -->
-<!-- 一案例挂多条规则时，各规则文件中都放索引行，案例文件只存一份 -->
-
-| 编号 | 库 | 现象 | 案例文件 |
-|------|-----|------|----------|
-| KI-{XXX} | {库名} | {现象简述} | [KI-{XXX}-{库名现象}.md](../cases/KI-{XXX}-{库名现象}.md) |
+<!-- 规则条目模板：新建规则时复制本模板，填充所有字段后直接写入 rules/R-{XX}-{规则名}.md -->
+<!-- 状态标记：draft（泛化产出待审核）/ active（人工审核通过，检视 SKILL 消费）/ deprecated（废弃，注明原因） -->
+
+# R-{XX} {规则名，"类"结尾，≤20字，不含具体库名}
+
+- **状态**: active
+- **严重级别**: {high|medium|low}（{判定依据：high=核心功能不可用；medium=特定场景失效；low=体验问题}）
+- **适用范围**: {哪类库适用}
+  - 预筛特征: {可执行的预筛条件，如：依赖特征 / 文件特征 / API 特征，命中才进入深度检查}
+- **问题本质**: {一句话机制层描述，为什么这类问题会发生；禁止出现具体库名/API 名}
+- **检查点**:
+  1. {动词开头，读源码后可独立判定是/否/疑似}
+  2. {...}
+  3. {...}
+- **错误特征**: {源码中命中此类问题的典型形态，供模式匹配}
+- **正确特征**: {修复后的代码形态，供对照判定}
+
+## 来源案例
+
+<!-- 案例索引行：详情在 cases/ 下的独立文件（格式二），此处只放索引 -->
+<!-- 一案例挂多条规则时，各规则文件中都放索引行，案例文件只存一份 -->
+
+| 编号 | 库 | 现象 | 案例文件 |
+|------|-----|------|----------|
+| KI-{XXX} | {库名} | {现象简述} | [KI-{XXX}-{库名现象}.md](../cases/KI-{XXX}-{库名现象}.md) |

package/vendor/Server/Skills/rn-library-issue-generalizer/references/PR_FETCH_GUIDE.md

@@ -1,61 +1,61 @@
-# PR 材料获取指南
-
-> `scripts/fetch-pr-info.py` 用于获取 GitCode PR 的元数据与 diff，为根因分析提供修复前后对照材料。
-
----
-
-## 1. 调用方式
-
-```bash
-python3 scripts/fetch-pr-info.py '{"prUrl": "https://gitcode.com/owner/repo/pull/123", "outputDir": "/absolute/path", "token": "可选"}'
-```
-
-参数（JSON 字符串）：
-
-| 参数 | 必填 | 说明 |
-|------|------|------|
-| `prUrl` | ✅ | GitCode PR 地址，`https://gitcode.com/{owner}/{repo}/pull/{number}` |
-| `outputDir` | ✅ | 知识库根目录（knowledgeDir），材料写入 `{knowledgeDir}/pr-info/` |
-| `token` | ❌ | GitCode API Token，私有仓库/限流时使用 |
-
----
-
-## 2. 产出文件
-
-| 文件 | 内容 | 用途 |
-|------|------|------|
-| `pr-info/{repo}-{number}.md` | 可读摘要：标题、描述、状态、变更文件列表、逐文件 diff | Agent 根因分析的主要输入 |
-| `pr-info/{repo}-{number}.json` | API 原始响应 | 排查/二次解析用 |
-
----
-
-## 3. API 端点
-
-GitCode 兼容 GitHub API v3 风格（`https://gitcode.com/api/v5`）：
-
-| 数据 | 端点 |
-|------|------|
-| PR 元数据 | `GET /repos/{owner}/{repo}/pulls/{number}` |
-| 变更文件 | `GET /repos/{owner}/{repo}/pulls/{number}/files`（含 patch 字段） |
-
-- 无 Token 有速率限制；批量获取案例材料时建议传 `token`
-- `files` 接口分页（per_page=100，page 递增），脚本已处理
-
----
-
-## 4. 降级策略
-
-| 情况 | 处理 |
-|------|------|
-| 私有仓库 401/404 | 脚本返回失败标记；Phase 1.3 走"材料不足"分支 |
-| 速率限制 403/429 | 有 token 时自动重试（间隔递增，最多 3 次）；仍失败走降级 |
-| PR 超大（files>300 或 patch 过大） | 脚本截断 diff 并在摘要中标注"diff 已截断"，保留变更文件全列表 |
-| 网络不可达 | 脚本返回失败标记；走降级分支 |
-
-**降级分支要求**（见 SKILL.md Phase 1.3）：基于问题描述做有限泛化，草稿"审核要点"中必须标注该规则未验证修复 diff。
-
----
-
-## 5. 本地已有材料复用
-
-若 `{outputDir}/pr-info/{repo}-{number}.md` 已存在，脚本直接跳过获取（幂等）。批量重跑时不会重复请求 API。
+# PR 材料获取指南
+
+> `scripts/fetch-pr-info.py` 用于获取 GitCode PR 的元数据与 diff，为根因分析提供修复前后对照材料。
+
+---
+
+## 1. 调用方式
+
+```bash
+python3 scripts/fetch-pr-info.py '{"prUrl": "https://gitcode.com/owner/repo/pull/123", "outputDir": "/absolute/path", "token": "可选"}'
+```
+
+参数（JSON 字符串）：
+
+| 参数 | 必填 | 说明 |
+|------|------|------|
+| `prUrl` | ✅ | GitCode PR 地址，`https://gitcode.com/{owner}/{repo}/pull/{number}` |
+| `outputDir` | ✅ | 知识库根目录（knowledgeDir），材料写入 `{knowledgeDir}/pr-info/` |
+| `token` | ❌ | GitCode API Token，私有仓库/限流时使用 |
+
+---
+
+## 2. 产出文件
+
+| 文件 | 内容 | 用途 |
+|------|------|------|
+| `pr-info/{repo}-{number}.md` | 可读摘要：标题、描述、状态、变更文件列表、逐文件 diff | Agent 根因分析的主要输入 |
+| `pr-info/{repo}-{number}.json` | API 原始响应 | 排查/二次解析用 |
+
+---
+
+## 3. API 端点
+
+GitCode 兼容 GitHub API v3 风格（`https://gitcode.com/api/v5`）：
+
+| 数据 | 端点 |
+|------|------|
+| PR 元数据 | `GET /repos/{owner}/{repo}/pulls/{number}` |
+| 变更文件 | `GET /repos/{owner}/{repo}/pulls/{number}/files`（含 patch 字段） |
+
+- 无 Token 有速率限制；批量获取案例材料时建议传 `token`
+- `files` 接口分页（per_page=100，page 递增），脚本已处理
+
+---
+
+## 4. 降级策略
+
+| 情况 | 处理 |
+|------|------|
+| 私有仓库 401/404 | 脚本返回失败标记；Phase 1.3 走"材料不足"分支 |
+| 速率限制 403/429 | 有 token 时自动重试（间隔递增，最多 3 次）；仍失败走降级 |
+| PR 超大（files>300 或 patch 过大） | 脚本截断 diff 并在摘要中标注"diff 已截断"，保留变更文件全列表 |
+| 网络不可达 | 脚本返回失败标记；走降级分支 |
+
+**降级分支要求**（见 SKILL.md Phase 1.3）：基于问题描述做有限泛化，草稿"审核要点"中必须标注该规则未验证修复 diff。
+
+---
+
+## 5. 本地已有材料复用
+
+若 `{outputDir}/pr-info/{repo}-{number}.md` 已存在，脚本直接跳过获取（幂等）。批量重跑时不会重复请求 API。

package/vendor/Server/Skills/rn-library-issue-generalizer/references/RULE_TEMPLATE_GUIDE.md

@@ -1,165 +1,165 @@
-# 规则条目编写指南
-
-> 知识库采用"规则层 + 案例层"两层知识 + "一级索引 + 二级知识"分级存储：**规则**是检查的执行单元（数量收敛），**案例**挂在规则下作为 few-shot 参考与修复指引（持续增厚）。
-
----
-
-## 1. 知识库分级结构
-
-```
-BadCase/rn/
-├── INDEX.md              # 一级：分类 + 规则/案例索引（Agent 预筛只读此文件）
-├── rules/                # 二级：规则知识（每规则一文件）
-│   └── R-XX-{规则名}.md
-├── cases/                # 二级：案例知识（每案例一文件，格式二）
-│   └── KI-XXX-{库名现象}.md
-└── pr-info/              # 案例原始 PR diff 证据材料
-```
-
-**分级规则**：
-- **一级 INDEX.md**：只含分类、索引表（编号/名称/严重级别/文件链接），不含具体知识；规则分类按问题域划分（媒体与窗口类/资源加载类/流程健壮性类/异步与回调类/工程规范类等，可扩展）
-- **二级 rules/**：每规则一文件，含完整检查知识 + 案例索引行（不含案例详情）
-- **二级 cases/**：每案例一文件；一案例挂多条规则时只存一份，各规则文件放索引行引用
-- **pr-info/**：案例的证据材料，案例文件中链接引用
-
-**INDEX.md 结构**：
-
-```markdown
-# RN 三方库鸿蒙化已知问题知识库 — 一级索引
-
-## 一、规则分类索引
-### {分类名}
-| 编号 | 规则名 | 严重级别 | 案例数 | 规则文件 |
-
-## 二、案例索引
-| 编号 | 库 | 现象简述 | 所属规则 | 验证方式 | 案例文件 |
-
-## 三、变更记录
-| 日期 | 变更 | 说明 |
-```
-
----
-
-## 2. 规则条目字段规范
-
-| 字段 | 必填 | 约束 |
-|------|------|------|
-| `编号` | ✅ | `R-XX` 两位数字递增，不复用已删除编号 |
-| `规则名` | ✅ | "XX类"结尾的类别名，≤20 字，不含具体库名 |
-| `适用范围` | ✅ | 含**可执行的预筛特征**：依赖特征（package.json 中的依赖名模式）、文件特征（存在某类文件）、API 特征（代码中出现某类调用）。预筛目的是让检视 SKILL 快速判断该规则与当前库是否相关 |
-| `问题本质` | ✅ | 一句话机制层描述：这类问题**为什么**会发生。禁止出现具体库名/API 名 |
-| `检查点` | ✅ | 2-5 条，动词开头（识别/列出/逐项检查/验证），每条读源码后可独立给出 是/否/疑似 |
-| `错误特征` | ✅ | 源码中命中此类问题的典型形态描述（供 Agent 模式匹配） |
-| `正确特征` | ✅ | 修复后的代码形态描述（供 Agent 对照判定） |
-| `严重级别` | ✅ | high / medium / low，及判定依据。high=核心功能不可用；medium=特定场景失效；low=体验问题 |
-| `来源案例` | ✅ | ≥1 条案例（见第 3 节），冷启动时至少 1 条 |
-
----
-
-## 3. 案例条目字段规范（格式二：代码证据式）
-
-| 字段 | 必填 | 说明 |
-|------|------|------|
-| `案例编号` | ✅ | `KI-XXX` 三位数字递增，全局唯一 |
-| `元数据` | ✅ | 一行式：`rule`（所属规则编号，多条逗号分隔）· `verified`（diff / description-only）· `source`（dtse / community-issue / self-check）· `severity`（high / medium / low）· `status`（draft / active，审核后翻 active） |
-| `库与现象` | ✅ | 保留原始具体信息：库名 + 问题现象（可用原始 issue 描述） |
-| `根因` | ✅ | 该案例的机制层根因（与规则"问题本质"呼应） |
-| `错误代码` | ✅* | 修复前代码片段，从 PR diff 删除行/上下文提取，≤15 行，只保留命中判定关键行（`verified: diff` 时必填） |
-| `正确代码` | ✅* | 修复后代码片段，从 PR diff 新增行提取，≤15 行，可用 ①②③ 注释标注修复链路（`verified: diff` 时必填） |
-| `修复方式` | ✅ | 从 PR diff 提炼的修复模式（可迁移的描述，非逐行复述） |
-| `PR 链接` | ✅ | 修复 PR 完整 URL |
-| `diff 材料` | ✅ | 链接到 `pr-info/{repo}-{number}.md` |
-
-> \* `verified: description-only` 的案例（未获取到 diff）省略代码字段，审核时需重点标注。
-
-**代码证据编写要求**：
-1. **必须来自实际 diff**，禁止凭描述臆造代码——这是"不能只通过描述判断问题"约束的落地
-2. 每段 ≤15 行：只保留体现缺陷模式/修复模式的关键行，删除无关上下文
-3. 语言标注正确（`typescript`/`cpp` 等），ArkTS 代码用 `typescript` 标注
-4. 错误代码中用 `// ←` 箭头注释标出缺陷点；正确代码中用 `①②③` 标注修复步骤
-5. 修复跨多文件时（如 JS 层 + ArkTS 层），两个片段可合并展示并注明各自来源文件
-
----
-
-## 4. 泛化质量正反例
-
-### 4.1 错误特征/正确特征写法
-
-❌ **过拟合**（只防住原案例）：
-```
-错误特征: 视频全屏时未调用 setPreferredOrientation
-```
-✅ **机制层**：
-```
-错误特征: 库对外声明的能力（全屏/旋转/后台运行等）在鸿蒙侧实现中找不到对应的
-系统调用或配置项，能力声明与实现之间存在断层
-```
-
-### 4.2 检查点写法
-
-❌ **不可判定**：
-```
-检查点: 检查异常处理是否完善
-```
-✅ **可判定**：
-```
-检查点:
-1. 识别库的核心主流程（对外承诺的主功能调用链）
-2. 列出主流程中的附属操作（非核心必需的下载/统计/日志步骤）
-3. 逐项检查附属操作的异常分支：失败时是隔离降级继续，还是 reject/throw 阻断主流程
-```
-
-### 4.3 适用范围写法
-
-❌ **不可预筛**：
-```
-适用范围: 所有库
-```
-✅ **可预筛**：
-```
-适用范围: 主流程中包含网络下载、图片处理、统计上报等附属步骤的库
-（预筛特征: 代码中出现 Promise.all 包装非核心请求 / reject 路径包含附属操作错误码）
-```
-
----
-
-## 5. 首批规则参考（4 案例泛化示例）
-
-以下为 4 个种子案例的泛化结果示例，供冷启动与后续泛化对齐风格。**正式规则以人工审核后的规则库为准。**
-
-### R-01 能力声明与实现匹配类
-- **适用范围**: 对外声明媒体/窗口/系统能力（全屏、旋转、后台播放、画中画等）的库（预筛特征: README/接口文档含能力声明关键词；JS 层暴露 fullscreen/orientation 相关接口）
-- **问题本质**: 库对外声明的某项能力，在鸿蒙侧实现中缺少对应的系统调用或配置支撑，能力声明与实现之间存在断层
-- **检查点**: ①列出库对外声明的每项能力 ②逐项在鸿蒙侧实现（ArkTS/C++/配置文件）中定位支撑代码 ③无支撑的能力标记为命中
-- **来源案例**: KI-001 webview 视频无法横屏（PR#121）
-
-### R-02 非标准 URI/路径形态覆盖类
-- **适用范围**: 加载本地/网络资源的库（图片、音频、字体、bundle 资源）（预筛特征: 存在 URI 解析/路径拼接逻辑）
-- **问题本质**: 资源加载只覆盖了标准形态（http/https/固定本地路径），遗漏鸿蒙化环境特有的路径形态（热更新沙箱路径、bundle 内资源、content:// 等）
-- **检查点**: ①定位所有资源 URI 解析入口 ②枚举其处理的路径形态分支 ③比对鸿蒙运行环境实际会产生的路径形态，缺失的标记为命中
-- **来源案例**: KI-002 fastImage 热更新图片加载失败（PR#102）
-
-### R-03 附属操作失败降级类
-- **适用范围**: 主流程中包含附属步骤（缩略图、统计、日志、预加载）的库（预筛特征: 主调用链中存在非核心的网络请求或文件操作）
-- **问题本质**: 非关键路径操作的失败被传播到主流程，导致核心功能被附属操作阻断
-- **检查点**: ①识别核心主流程 ②列出主流程中的附属操作 ③逐项检查附属操作异常分支是否隔离降级
-- **来源案例**: KI-003 wechat-lib thumbImageUrl 下载失败阻断分享（PR#15）
-
-### R-04 发布产物自洽类
-- **适用范围**: 所有发布到 OHPM 的库（预筛特征: 存在 oh-package.json5）
-- **问题本质**: 包元信息（version/main/types/files）与实际发布产物不一致，或与官方接入文档不匹配，导致按文档接入直接失败
-- **检查点**: ①核对 oh-package.json5 的 main/types 指向的文件是否存在 ②核对 version 与产物内容是否对应 ③按官方文档的接入步骤走查一遍入口链路
-- **来源案例**: KI-004 geolocation 3.1.1 版本文件不对（PR#24）
-
----
-
-## 6. 知识库维护约定
-
-1. **直接写入分级目录**：泛化产出直接写入 `rules/`、`cases/` 并更新 `INDEX.md`，不生成单文件草稿快照
-2. **draft → active 状态机制**：新建/修订条目标记 `draft`；人工审核通过后规则文件改 `- **状态**: active`、案例文件元数据加 `status: active`；检视 SKILL 只消费 `active` 条目
-3. **规则只增不删**：失效规则标记 `deprecated` 并注明原因，保留编号
-4. **案例持续挂载**：新案例优先归入已有规则；归入时检查是否需要补充该规则的检查点（追加项标注日期与 draft 待审）
-5. **每次变更记录**：INDEX.md 变更记录表追加（日期 + 新建/挂载/修订摘要）
-6. **编号稳定**：规则编号、案例编号一经合入不再变更，检视报告通过编号引用
-7. **文件命名**：规则 `R-XX-{规则名}.md`、案例 `KI-XXX-{库名现象}.md`，命名与 INDEX 索引一致
-8. **一案例一文件**：复合问题案例（挂多条规则）只存一份案例文件，各规则文件放索引行
+# 规则条目编写指南
+
+> 知识库采用"规则层 + 案例层"两层知识 + "一级索引 + 二级知识"分级存储：**规则**是检查的执行单元（数量收敛），**案例**挂在规则下作为 few-shot 参考与修复指引（持续增厚）。
+
+---
+
+## 1. 知识库分级结构
+
+```
+BadCase/rn/
+├── INDEX.md              # 一级：分类 + 规则/案例索引（Agent 预筛只读此文件）
+├── rules/                # 二级：规则知识（每规则一文件）
+│   └── R-XX-{规则名}.md
+├── cases/                # 二级：案例知识（每案例一文件，格式二）
+│   └── KI-XXX-{库名现象}.md
+└── pr-info/              # 案例原始 PR diff 证据材料
+```
+
+**分级规则**：
+- **一级 INDEX.md**：只含分类、索引表（编号/名称/严重级别/文件链接），不含具体知识；规则分类按问题域划分（媒体与窗口类/资源加载类/流程健壮性类/异步与回调类/工程规范类等，可扩展）
+- **二级 rules/**：每规则一文件，含完整检查知识 + 案例索引行（不含案例详情）
+- **二级 cases/**：每案例一文件；一案例挂多条规则时只存一份，各规则文件放索引行引用
+- **pr-info/**：案例的证据材料，案例文件中链接引用
+
+**INDEX.md 结构**：
+
+```markdown
+# RN 三方库鸿蒙化已知问题知识库 — 一级索引
+
+## 一、规则分类索引
+### {分类名}
+| 编号 | 规则名 | 严重级别 | 案例数 | 规则文件 |
+
+## 二、案例索引
+| 编号 | 库 | 现象简述 | 所属规则 | 验证方式 | 案例文件 |
+
+## 三、变更记录
+| 日期 | 变更 | 说明 |
+```
+
+---
+
+## 2. 规则条目字段规范
+
+| 字段 | 必填 | 约束 |
+|------|------|------|
+| `编号` | ✅ | `R-XX` 两位数字递增，不复用已删除编号 |
+| `规则名` | ✅ | "XX类"结尾的类别名，≤20 字，不含具体库名 |
+| `适用范围` | ✅ | 含**可执行的预筛特征**：依赖特征（package.json 中的依赖名模式）、文件特征（存在某类文件）、API 特征（代码中出现某类调用）。预筛目的是让检视 SKILL 快速判断该规则与当前库是否相关 |
+| `问题本质` | ✅ | 一句话机制层描述：这类问题**为什么**会发生。禁止出现具体库名/API 名 |
+| `检查点` | ✅ | 2-5 条，动词开头（识别/列出/逐项检查/验证），每条读源码后可独立给出 是/否/疑似 |
+| `错误特征` | ✅ | 源码中命中此类问题的典型形态描述（供 Agent 模式匹配） |
+| `正确特征` | ✅ | 修复后的代码形态描述（供 Agent 对照判定） |
+| `严重级别` | ✅ | high / medium / low，及判定依据。high=核心功能不可用；medium=特定场景失效；low=体验问题 |
+| `来源案例` | ✅ | ≥1 条案例（见第 3 节），冷启动时至少 1 条 |
+
+---
+
+## 3. 案例条目字段规范（格式二：代码证据式）
+
+| 字段 | 必填 | 说明 |
+|------|------|------|
+| `案例编号` | ✅ | `KI-XXX` 三位数字递增，全局唯一 |
+| `元数据` | ✅ | 一行式：`rule`（所属规则编号，多条逗号分隔）· `verified`（diff / description-only）· `source`（dtse / community-issue / self-check）· `severity`（high / medium / low）· `status`（draft / active，审核后翻 active） |
+| `库与现象` | ✅ | 保留原始具体信息：库名 + 问题现象（可用原始 issue 描述） |
+| `根因` | ✅ | 该案例的机制层根因（与规则"问题本质"呼应） |
+| `错误代码` | ✅* | 修复前代码片段，从 PR diff 删除行/上下文提取，≤15 行，只保留命中判定关键行（`verified: diff` 时必填） |
+| `正确代码` | ✅* | 修复后代码片段，从 PR diff 新增行提取，≤15 行，可用 ①②③ 注释标注修复链路（`verified: diff` 时必填） |
+| `修复方式` | ✅ | 从 PR diff 提炼的修复模式（可迁移的描述，非逐行复述） |
+| `PR 链接` | ✅ | 修复 PR 完整 URL |
+| `diff 材料` | ✅ | 链接到 `pr-info/{repo}-{number}.md` |
+
+> \* `verified: description-only` 的案例（未获取到 diff）省略代码字段，审核时需重点标注。
+
+**代码证据编写要求**：
+1. **必须来自实际 diff**，禁止凭描述臆造代码——这是"不能只通过描述判断问题"约束的落地
+2. 每段 ≤15 行：只保留体现缺陷模式/修复模式的关键行，删除无关上下文
+3. 语言标注正确（`typescript`/`cpp` 等），ArkTS 代码用 `typescript` 标注
+4. 错误代码中用 `// ←` 箭头注释标出缺陷点；正确代码中用 `①②③` 标注修复步骤
+5. 修复跨多文件时（如 JS 层 + ArkTS 层），两个片段可合并展示并注明各自来源文件
+
+---
+
+## 4. 泛化质量正反例
+
+### 4.1 错误特征/正确特征写法
+
+❌ **过拟合**（只防住原案例）：
+```
+错误特征: 视频全屏时未调用 setPreferredOrientation
+```
+✅ **机制层**：
+```
+错误特征: 库对外声明的能力（全屏/旋转/后台运行等）在鸿蒙侧实现中找不到对应的
+系统调用或配置项，能力声明与实现之间存在断层
+```
+
+### 4.2 检查点写法
+
+❌ **不可判定**：
+```
+检查点: 检查异常处理是否完善
+```
+✅ **可判定**：
+```
+检查点:
+1. 识别库的核心主流程（对外承诺的主功能调用链）
+2. 列出主流程中的附属操作（非核心必需的下载/统计/日志步骤）
+3. 逐项检查附属操作的异常分支：失败时是隔离降级继续，还是 reject/throw 阻断主流程
+```
+
+### 4.3 适用范围写法
+
+❌ **不可预筛**：
+```
+适用范围: 所有库
+```
+✅ **可预筛**：
+```
+适用范围: 主流程中包含网络下载、图片处理、统计上报等附属步骤的库
+（预筛特征: 代码中出现 Promise.all 包装非核心请求 / reject 路径包含附属操作错误码）
+```
+
+---
+
+## 5. 首批规则参考（4 案例泛化示例）
+
+以下为 4 个种子案例的泛化结果示例，供冷启动与后续泛化对齐风格。**正式规则以人工审核后的规则库为准。**
+
+### R-01 能力声明与实现匹配类
+- **适用范围**: 对外声明媒体/窗口/系统能力（全屏、旋转、后台播放、画中画等）的库（预筛特征: README/接口文档含能力声明关键词；JS 层暴露 fullscreen/orientation 相关接口）
+- **问题本质**: 库对外声明的某项能力，在鸿蒙侧实现中缺少对应的系统调用或配置支撑，能力声明与实现之间存在断层
+- **检查点**: ①列出库对外声明的每项能力 ②逐项在鸿蒙侧实现（ArkTS/C++/配置文件）中定位支撑代码 ③无支撑的能力标记为命中
+- **来源案例**: KI-001 webview 视频无法横屏（PR#121）
+
+### R-02 非标准 URI/路径形态覆盖类
+- **适用范围**: 加载本地/网络资源的库（图片、音频、字体、bundle 资源）（预筛特征: 存在 URI 解析/路径拼接逻辑）
+- **问题本质**: 资源加载只覆盖了标准形态（http/https/固定本地路径），遗漏鸿蒙化环境特有的路径形态（热更新沙箱路径、bundle 内资源、content:// 等）
+- **检查点**: ①定位所有资源 URI 解析入口 ②枚举其处理的路径形态分支 ③比对鸿蒙运行环境实际会产生的路径形态，缺失的标记为命中
+- **来源案例**: KI-002 fastImage 热更新图片加载失败（PR#102）
+
+### R-03 附属操作失败降级类
+- **适用范围**: 主流程中包含附属步骤（缩略图、统计、日志、预加载）的库（预筛特征: 主调用链中存在非核心的网络请求或文件操作）
+- **问题本质**: 非关键路径操作的失败被传播到主流程，导致核心功能被附属操作阻断
+- **检查点**: ①识别核心主流程 ②列出主流程中的附属操作 ③逐项检查附属操作异常分支是否隔离降级
+- **来源案例**: KI-003 wechat-lib thumbImageUrl 下载失败阻断分享（PR#15）
+
+### R-04 发布产物自洽类
+- **适用范围**: 所有发布到 OHPM 的库（预筛特征: 存在 oh-package.json5）
+- **问题本质**: 包元信息（version/main/types/files）与实际发布产物不一致，或与官方接入文档不匹配，导致按文档接入直接失败
+- **检查点**: ①核对 oh-package.json5 的 main/types 指向的文件是否存在 ②核对 version 与产物内容是否对应 ③按官方文档的接入步骤走查一遍入口链路
+- **来源案例**: KI-004 geolocation 3.1.1 版本文件不对（PR#24）
+
+---
+
+## 6. 知识库维护约定
+
+1. **直接写入分级目录**：泛化产出直接写入 `rules/`、`cases/` 并更新 `INDEX.md`，不生成单文件草稿快照
+2. **draft → active 状态机制**：新建/修订条目标记 `draft`；人工审核通过后规则文件改 `- **状态**: active`、案例文件元数据加 `status: active`；检视 SKILL 只消费 `active` 条目
+3. **规则只增不删**：失效规则标记 `deprecated` 并注明原因，保留编号
+4. **案例持续挂载**：新案例优先归入已有规则；归入时检查是否需要补充该规则的检查点（追加项标注日期与 draft 待审）
+5. **每次变更记录**：INDEX.md 变更记录表追加（日期 + 新建/挂载/修订摘要）
+6. **编号稳定**：规则编号、案例编号一经合入不再变更，检视报告通过编号引用
+7. **文件命名**：规则 `R-XX-{规则名}.md`、案例 `KI-XXX-{库名现象}.md`，命名与 INDEX 索引一致
+8. **一案例一文件**：复合问题案例（挂多条规则）只存一份案例文件，各规则文件放索引行