文件最后提交记录最后更新时间
2 个月前
2 个月前
2 个月前
2 个月前
2 个月前
2 个月前
README

codecheck — 代码检视技能集

本目录是 ability_base 仓库的代码检视工作台。当用户说"检视一下代码""帮我审一下""做一次 code review""深度扫描"时,从这里出发:先读本 README 了解三层架构,由 orchestrator 自动探测路径特征、选择 scanner 组合、并行调度、Refute 对抗性验证、合并为一份统一报告。

入口指引:仓库根 AGENTS.md 的「代码检视」章节把"检视代码"这一意图路由到本 README。ability_base 仓若暂无 AGENTS.md,直接以本 README 为检视入口。本 README 只负责导航与编排,具体方法论在各层文件中。


三层架构

核心原则:知识(Pattern)、执行(Scanner)、调度(Orchestrator)三层分离,增加对抗性验证层(Refuter)。

skills/codecheck/
│
├── README.md                              # 总入口(本文件)
├── codecheck_report_TEMPLATE.md           # 统一报告模板(门禁合约)
├── conventions.md                         # 跨模块公约
│
├── patterns/                              # 第一层:中央缺陷模式知识库
│   ├── INDEX.md                           #   全量模式索引
│   ├── memory-safety.md                   #   内存安全(MEM-001~005)
│   ├── concurrency.md                     #   并发安全(CONC-001~004)
│   ├── input-validation.md                #   输入校验与数据流(INP-001~010)
│   ├── resource-lifecycle.md              #   资源生命周期(RES-001~010)
│   ├── ipc-serialization.md               #   IPC 序列化(IPC-001~010)
│   ├── privilege-auth.md                  #   权限与鉴权(AUTH-001~008)
│   ├── error-handling.md                  #   错误处理(ERR-001~009)
│   ├── logic-correctness.md               #   逻辑正确性(LOG-001~012)
│   └── known-defect-patterns/             #   G01–G15 历史缺陷模式库
│       ├── G01_xxx.md ... G15_xxx.md       #   每模式一文件:信号特征 + grep 线索 + 历史案例 + 检查点
│       └── hotspot-modules.md             #   热区模块清单
│
├── scanners/                              # 第二层:检视扫描器(3 个薄层)
│   ├── security-scanner/SKILL.md          #   高影响缺陷 + 安全审查(合并版)
│   ├── logic-scanner/SKILL.md             #   逻辑变更分析
│   └── input-scanner/SKILL.md             #   外部输入全链路审计
│
└── orchestrator/                          # 第三层:调度与报告
    ├── SKILL.md                           #   唯一编排器(调度 + refute + 合并报告)
    └── refute-rules.md                    #   Refuter 质疑规则与判定标准

三层职责

层 职责 不包含
patterns/ 所有 scanner 共享的"已知错误模式词典"。每条目:信号特征 + grep 线索 + 触发条件 + 典型后果 + 历史案例引用 不包含执行逻辑、不定义输出格式
scanners/ 每个 scanner 的 SKILL.md 只保留三部分:执行工作流 + 输出格式定义 + Pattern 引用声明(200-400 行) 不含具体检查规则、grep 命令、代码模式(这些在 patterns/)
orchestrator/ 唯一编排器:自动探测 + 选择 scanner 组合 + 并行调度 + Refute 对抗性验证 + 合并统一报告 不执行具体扫描

Scanner 一览

Scanner 检视维度 触发场景 输出
security-scanner 高影响缺陷 + 商用前安全审查(合并版):崩溃、挂死、OOM、UAF、死锁、数据损坏、资源泄漏、状态污染、权限绕过、敏感数据泄漏、IPC 鉴权 "查高危 bug""P0/P1 风险排查""崩溃/挂死审计""安全审查""漏洞扫描""商用前 review" 按 影响×可触发性×波及面 排序的双视角(bug+security)缺陷清单 + G 类同类横扫
logic-scanner 逻辑影响:修改的波及路径、逻辑一致性、状态机转换、边界条件、错误处理 "逻辑分析""这段改动会影响什么""状态机/数据流/控制流检查" 逻辑影响范围 + 不一致/边界遗漏清单
input-scanner "外部输入 → 持久化"全链路健壮性:IPC/HTTP/CLI/配置/网络 → DB/文件/缓存/日志 "外部输入排查""输入接口审计""持久化安全检查""接口健壮性" 按 P0/P1/P2 排序的 Excel 风险清单(写入侧+读取侧双维度)

Path B 统一合约:任一 scanner 直接被调用时,除上表"输出"列的原始发现清单外,必须按 conventions.md §5–§13 额外生成符合 codecheck_report_TEMPLATE.md 的统一报告(双产出)。经 orchestrator 调度时只产原始发现清单,由 orchestrator 合并生成统一报告。


维度关系图

              用户:"检视一下代码" / "深度扫描"
                           │
                           ▼
               ┌─────────────────────────┐
               │      orchestrator       │  唯一编排:自动探测 + 选择组合 + refute + 合并报告
               └────────────┬─────────────┘
                            │ 并行调度(按路径特征选)
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
        ┌────────────┐ ┌────────────┐ ┌────────────┐
        │  security  │ │   logic    │ │   input    │
        │  -scanner  │ │  -scanner  │ │  -scanner  │
        └─────┬──────┘ └─────┬──────┘ └─────┬──────┘
              │              │              │
              └──────┬───────┴──────┬───────┘
                     ▼              ▼
               patterns/      patterns/
               (memory-safety,   (logic-correctness,
                concurrency,      error-handling)
                input-validation,
                resource-lifecycle,
                ipc-serialization,
                privilege-auth,
                known-defect-patterns/G01-G15)
  • orchestrator 是唯一编排器,自动探测路径特征(IPC/序列化/持久化信号)后选择 scanner 组合,并行调度,Refute 验证,合并统一报告。通用"检视代码"/"深度扫描"的默认入口。
  • 单一维度(纯安全/纯外部输入/纯逻辑)时直接调对应 scanner,不走 orchestrator。直接调用时 scanner 也必须按 conventions.md §5–§13 生成统一报告(双产出:原始发现清单 + 统一报告)。
  • 所有 scanner 共享 patterns/ 知识库,避免重复维护检查规则。

检视流程("检视一下代码"时怎么走)

Step 1:界定范围

明确两点,缺则向用户确认:

  1. 目标路径或 Kit:如 interfaces/kits/native/want/src/、interfaces/inner_api/base/src/,或 abilityBase/want/cwant。
  2. 检视重点:通用 review / 安全 / 高危 bug / 外部输入健壮性。未指定时走"通用检视"。

Step 2:自动探测 + 选择 scanner 组合

orchestrator 自动探测路径特征:

探测信号 grep 线索
IPC 信号 rg "Parcel::Read|OnRemoteRequest|WriteRemoteObject" --type cpp
序列化/持久化信号 rg "ReadFromParcel|WriteToParcel|Marshalling|Insert\s*(|ExecuteSql|fopen|write\s*\(" --type cpp

按特征 + 用户意图决策:

条件 调用组合
用户指定单一维度 → 只调对应 scanner,跳过推断
interfaces/inner_api/base/ 或 interfaces/kits/native/want/src/want_params*.cpp(IPC/序列化密集)→ security + logic + input
通用路径无特殊信号 → security + logic
用户说"全面"/"最大覆盖" → security + logic + input

Step 3:并行调度 scanner

读对应目录的 SKILL.md,按其工作流执行。每个 scanner 加载 patterns/ 下相关 pattern 文件。保留各 scanner 原始产出(md/csv/excel),不要在中间改写。

Step 4:Refute — 对抗性验证 🔥 新增

orchestrator 对每条发现执行三层质疑:

  1. 触发路径证伪:上游有防护吗?真的可达吗?
  2. 影响夸大证伪:后果真的这么严重吗?
  3. 跨 scanner 根因去重:两条发现本质同一个根因吗?

产出 refute_log.md,记录每条发现的判定:✅ 维持 | ⬇️ 降级 | ❌ 推翻 | 🔀 合并。详见 orchestrator/refute-rules.md。

Step 5:合并为统一报告

基于 refute_log.md 过滤后的发现列表,按 codecheck_report_TEMPLATE.md 生成 codecheck_report_<scope>_<YYYYMMDD>.md。

📄 权威模板: codecheck_report_TEMPLATE.md 模板固定了章节顺序(基本信息 → 总体评价 → 问题统计 → 高优先级发现 → 分维度明细 → 待跟进 → 附录)、头部机器可读的 YAML 报告元数据块,以及文末"附录 A"的评分公式与门禁决策矩阵。所有 codecheck 报告(含 orchestrator 合并、单 scanner 直接产出)格式保持一致,便于门禁脚本解析与历史对比。

生成要求(门禁校验项):

  1. 头部 YAML 报告元数据块字段名/取值域固定,score/risk_level/gate_decision 必须按附录 A 的公式与决策矩阵计算,不得自创分值。
  2. 严重等级统一归一化为 P0–P3(各 scanner 的 critical/high/medium/low、致命/严重/一般/提示 一律映射后汇总,映射表见 conventions.md)。
  3. 跨维度去重:同一 file:line 被多个 scanner 命中时在"高优先级发现"合并为一条,标注维度来源列表。不同 file:line 但同根因由 refuter 合并。
  4. 必检维度缺失时,门禁决策为 insufficient(无法评估),需补齐扫描后重出报告。

Step 6:交付

交付统一报告路径 + Executive Summary + Top 高危项 + 各 scanner 原始产出路径 + refute_log.md 路径。


约定

跨模块公约集中管理在 conventions.md,要点:

  • 静态语言实现默认排除:frameworks/ets/ani/、frameworks/ets/ets/、frameworks/cj/ffi/、ets_*.cpp、cj_*.cpp 等 static 侧不在扫描范围,除非用户明确要求包含(ability_base 本仓无 frameworks/ 目录与 ets_*/cj_* 文件,此项默认不触发;规则保留以兼容跨仓联合检视)。
  • 证据要求:每条发现必须可追溯到 file:line + 触发路径,不收"代码气味"级别的无证据项。
  • 不动代码:检视阶段只产出报告与建议,不直接改源码;修复由用户确认后另起任务。
  • 去重规则:跨 scanner 去重以 file:line 为第一键;同位置多 scanner 命中合并为一条,标注维度来源;不同 file:line 但同根因由 refuter 合并。
  • Refute 公约:只质疑不发现,质疑必须有代码证据,被推翻发现保留在附录,P0 推翻需"确认不可达"级证据。