rpiv-loop-code-audit

对指定目录、文件、模块或 skill 进行全量代码审计。 ## 参数解析 从 `$ARGUMENTS` 中解析： - **第一个参数**（必填）：目标，可以是目录路径、单个文件路径、模块路径或已安装 skill 名称。 - 已存在的相对/绝对路径：直接解析为目标路径。 - 已安装 skill 名称（如 `rpiv-loop:code-audit`）：先在当前运行面的 skills 根目录中按 `<name-with-colon-replaced-by-hyphen>/` 解析；若不存在，再扫描该 skills 根目录下 `SKILL.md` 的 frontmatter `name` 精确匹配。若当前运行面没有可发现的 skills 根目录，停止审计并要求用户提供明确路径。 - `self` / `自身`：当正在执行本 skill 且能发现当前 skill 目录时，解析为当前 skill 目录；否则要求用户提供明确路径。 - 若目标无法解析，停止审计并给出候选路径，不要猜测到无关插件源目录。 - **第二个参数**（可选）：审查维度，支持中英文，以下等价： - `logic` | `逻辑` — 逻辑正确性 - `security` | `安全` — 安全漏洞 - `performance` | `性能` — 性能问题 - `architecture` | `架构` — 架构与设计 - `integration` | `集成` — 集成与环境兼容性 - `portability` | `migration` | `可迁移性` | `迁移` | `环境中立` — skills/代码的跨运行面、跨工具、跨机器迁移能力 - `necessity` | `必要性` | `价值` — 内容必要性与过度设计（该做不该做，区别于其余维度的做得对不对） - 逗号分隔组合：`logic,security` 或 `逻辑,安全`（中英文可混用） - 不提供时默认全量审查（7 个维度全部执行） - 当目标是 skill 目录或 `SKILL.md` 时，可迁移性维度必须执行；如果用户指定的维度不包含 `portability`，自动追加并在报告中说明原因。 - 无论目标是什么类型、用户是否指定维度，`necessity` 维度一律执行；如果用户指定的维度不包含 `necessity`，自动追加并在报告中说明原因。自动追加时执行基础检查项，仅当用户显式指定 `necessity` 时才进入深度模式。与 `portability` 的追加叠加时（目标是 skill 且用户只指定了其他维度），两条追加原因在报告中分别说明。 **示例：** ``` /code-audit neuromem/services/ # 全量审查 /code-audit rpiv-loop:code-audit # 审计已安装 skill /code-audit self architecture # 审计当前 skill 的架构 /code-audit rpiv-loop:code-audit portability # 仅审计 skill 可迁移性 /code-audit neuromem/services/ architecture # 仅架构深度审查 /code-audit neuromem/services/ 架构 # 同上（中文） /code-audit backend/app/api/ logic,security # 逻辑+安全深度审查 /code-audit backend/app/api/ 逻辑,安全 # 同上（中文） /code-audit rpiv-loop:code-audit necessity # 必要性深度模式（找过度设计） ``` ## 执行流程 ### Phase 0：上下文收集 1. 读取项目根目录的 `CLAUDE.md`、`README.md`（如果存在）。若目标位于当前运行面的全局 skills 目录，同时读取该运行面的全局规则文件和目标 `SKILL.md`。 2. 读取目标目录下的 `CLAUDE.md`（如果存在）。 3. 扫描 `docs/` 目录中的编码规范文件（如果存在）。若目标 skill 明确引用共享资源目录，只读取与本次审计相关的共享引用文件，避免把整个插件树误当目标。 4. 记录项目使用的语言、框架、编码规范。 5. **运行环境识别**：从 `CLAUDE.md` 和项目配置（pyproject.toml、package.json、Dockerfile 等）中识别目标运行环境（Windows/macOS/Linux/跨平台），标记为 `cross_platform` 如果代码需在多平台运行。 6. **Git 配置检查**：检查 `.gitattributes` 是否存在、是否配置了行尾符规则（`* text=auto` 等），记录对文件内容的潜在影响；如果目标不在 git 仓库中，记录为 `not_git_repo`，不要把 git 命令失败当成审计失败。 7. **迁移目标识别**：如果目标是 skill 或 workflow，识别其预期运行面（如 Claude Code、Codex、公司 CodeAgent、普通 shell）。未知时默认按多运行面可迁移目标审查。 8. 如果 `cross_platform = true`，在 Phase 2 的逻辑审查、集成审查和可迁移性审查中自动激活跨平台兼容性检查项。 ### Phase 1：文件发现 1. 扫描目标，列出所有待审计文件。目标可以是目录，也可以是单个文件；如果目标是文件，文件清单只包含该文件。 2. 排除 `.venv/`、`node_modules/`、`__pycache__/`、`.git/`、`dist/`、`build/`、`*.pyc` 等依赖、缓存和构建产物。 3. 语言代码文件包括 `.py`、`.ts`、`.js`、`.tsx`、`.jsx`、`.sh`、`.ps1` 等；配置/规范文件包括 `.toml`、`.yaml`、`.yml`、`.json`。 4. 审计 skills 时，`SKILL.md`、相关 `.md` / `.mdx` 文件和被 `SKILL.md` 直接引用的脚本也属于主审计对象，不能因为不是传统源代码而跳过。 5. 按文件类型统计并输出文件清单，供后续并行审查员或主执行者顺序审查使用。 ### Phase 2：审查执行 根据参数决定执行模式： #### 全量模式（无第二参数） 如果当前会话明确允许启动并行审查员，启动 **7 个并行审查员**，每个审查员接收完整文件清单和项目上下文（含 Phase 0 的环境信息），各自独立完整阅读每个文件后审查。若当前会话未允许或工具不可用，主执行者必须按同样 7 个维度顺序执行审查，不能因为没有并行审查员而跳过维度。 **维度 1 — 逻辑审查（基础）：** - 边界条件错误（差一、空集合、零值） - 竞争条件和并发问题 - 错误处理缺失或不当（吞异常、裸 except） - 空值/None 处理不当 - 条件判断逻辑错误 - **隐式假设挑战**： - 字节/字符串比较操作：两端数据是否可能有不同的编码或行尾符（CRLF vs LF）？是否需要归一化后再比较？ - 文件 I/O 选择：`read_bytes()` vs `read_text()` 是否匹配使用场景？跨平台（Windows CRLF / Unix LF / Git autocrlf）是否影响结果？ - 时间戳比较：mtime 在 git clone/pull 后是否可靠？不同文件系统的精度差异是否影响判断？ - **数据流对称性**： - 当两个数据源的输出用于比较（`==`、`!=`、diff）时，追溯两端的完整变换链，检查是否经过了相同的预处理管道（过滤、剥离、归一化、编码转换） - 特别关注：一端经过 parse/split/transform 处理，另一端直接 read 的模式——极易产生不对称 **维度 2 — 安全审查（基础）：** - SQL 注入、命令注入 - XSS 漏洞 - 硬编码密钥、API Key、密码 - 权限检查缺失 - 用户输入未验证/未转义 **维度 3 — 性能审查（基础）：** - N+1 查询模式 - 内存泄漏（未关闭资源、无界数据结构） - 热路径上的阻塞操作 - 不必要的重复计算或 I/O - 可并行但串行执行的操作 **维度 4 — 架构审查（基础）：** - SOLID 原则违反（特别是单一职责和依赖倒置） - 层级穿透（跨层直接访问） - 循环依赖 - 过度耦合（God Object、超长参数列表） - 抽象泄漏 **维度 5 — 集成与环境审查（基础）：** - **跨平台兼容性**：文件路径分隔符、行尾符（CRLF/LF）、编码、大小写敏感性在目标平台上是否一致 - **外部数据假设**：代码对外部输入（文件内容、API 返回、环境变量）的格式假设是否在所有运行环境中成立 - **配置/列表完备性**：硬编码的排除列表、白名单、映射表是否覆盖了项目中已知的所有实体。**必须用 Glob/ls 实际扫描目标目录，对比列表中的条目和实际存在的目录/文件，报告"列表中有但目录中没有"和"目录中有但列表中没有"的差异** - **组件间契约**：函数 A 的输出被函数 B 消费时，A 的输出格式是否与 B 的输入预期一致（关注编码、分隔符、是否含 metadata/标记行） - **环境依赖**：代码是否依赖特定的 git 配置（autocrlf）、文件系统特性（大小写）、shell 环境（PATH）、运行时版本 **维度 6 — 可迁移性审查（skills/runtime-portability，基础）：** - **运行面中立性**：skill 是否把核心流程绑定到 Claude Code、Codex、CodeAgent 或某个公司内部自动化运行面的专属工具名、命令名、hook 名、frontmatter 字段或交互模型。 - **单一事实源**：是否存在为不同运行面维护多套互相分叉的 instructions；迁移适配是否保持为薄层，而不是复制并改写核心流程。 - **路径与安装位置中立**：是否硬编码个人绝对路径、特定 home 目录、插件源码目录、workspace 名称或机器用户名；是否优先使用 `<skill-root>`、`<plugin-root>`、环境变量、相对路径或可发现路径。 - **工具能力抽象**：是否把 `Read/Edit/Write/Bash/Glob/Grep`、`apply_patch`、`AskUserQuestion` 等平台工具当成唯一实现；是否提供等价意图或 fallback。 - **Shell/OS 中立性**：是否默认绑定 PowerShell、Bash、Windows 路径分隔符、可执行文件后缀、换行符或大小写规则；必要绑定是否明确标注适用环境和替代方案。 - **前置依赖可发现性**：外部 CLI、脚本、共享资源和凭据是否有发现规则、缺失处理和降级路径，而不是依赖某台机器的隐式安装状态。 - **同步友好性**：frontmatter、metadata 和共享资源引用是否能在多环境同步时安全裁剪或保留；是否避免把环境专属适配写进核心 workflow 导致长期分叉。 **维度 7 — 必要性审查（necessity，基础）：** - **需求对照**：与 PRD、`rpiv/archive/` 归档记录、守卫测试对照——该功能/章节/配置项是否有需求支撑或设计意图记录。 - **使用证据**：**必须用 Grep 在项目范围内实际扫描引用**（不是凭印象判断"看起来没用"），并查 git log 该内容的引入 commit 及其 message。零引用、永不可达的死分支、从未生效的配置为确凿证据。 - **复杂度收益比（YAGNI）**：为"将来可能"预留的推测性抽象、只有一个实现的接口、只有单一调用方的封装层、防御从不发生的异常、维护成本明显大于收益的机制。 - **重复冗余**：功能已被别的 skill/hook/工具覆盖、同一逻辑多处实现、可用现成能力替代的自造轮子。**必须能指名具体的重复对象**（文件路径、skill 名或函数名），指不出具体重复方就不算重复冗余。 - **四步前置查证义务**：判定任何内容"可疑"之前必须逐步完成——① 扫守卫测试（`tests/` 等目录编码了刻意的设计意图，非对称写法往往是有意为之）；② 查 PRD 与 `rpiv/archive/` 归档记录；③ 查 git log 的引入 commit 及 message；④ 从上下文推断用途。**跳步得出的发现禁止写入报告。** - **证据源降级**：四步中不存在的证据源记为 `not_available`（普通代码仓库没有 `rpiv/`、没有守卫测试属正常），依赖其余证据源得出结论；**不得因证据源缺失而跳过本维度**。git 不可用时沿用 Phase 0 的 `not_git_repo`，第 ③ 步记 `not_available`。 - **确凿型与存疑型分开标记**：确凿型（零引用、死分支、能指名具体重复对象）按实际影响正常定级；存疑型（四步查证全空、无法自证价值）severity **上限 medium**，issue 中注明"存疑型"，suggestion **必须包含关闭路径**——"若存在未记录的设计意图，请补录到 PRD 或守卫测试后关闭本条"。 - **查证结果并入 detail**：necessity 的问题条目写入报告时，必须把四步查证结果（各证据源 found / none / not_available）摘要成一行并入 `detail` 字段，使下方 `evidence_check` 的记录不因通用报告模板不含该字段而丢失。 - **三级审计粒度**：① 功能点/章节级（某个 Phase、配置项、fallback、参数、异常分支、抽象层、封装）；② 文件/脚本级（整个 reference 文件、工具脚本、模板该不该存在）；③ 目标整体级（该 skill/模块本身是否该存在、是否该合并到别处）——**第 ③ 级结论写入报告的"整体存在性评估"节，不混入逐条问题列表**。 - **简化方案必须功能等价**：suggestion 要写清删哪段（章节名或行号）、合并成什么、替代写法是什么。不得以删减功能充当简化，也不得为减少行数牺牲可读性或删掉真正有组织价值的抽象。 necessity 的问题条目在通用字段之外额外记录： ```yaml necessity_type: confirmed|suspected # 确凿型 | 存疑型 evidence_check: guard_tests: found|none|not_available prd_archive: found|none|not_available git_log: found|none|not_available context_inference: found|none ``` 上述 `necessity_type` 与 `evidence_check` 是 necessity 专属的附加记录，不取代下面的通用返回格式——necessity 的问题条目同时包含通用字段与这两个附加字段。 每个并行审查员或主执行者的单维度审查返回格式： ```yaml issues: - id: CA-001 severity: critical|high|medium|low confidence: 0-100 file: "path/to/file.py" line: 42 issue: "一行描述" detail: "为什么这是问题" suggestion: "如何修复（含具体代码建议）" ``` #### 单项模式（指定维度） 如果当前会话明确允许启动并行审查员，启动 **1 个审查员**，执行指定维度的**深度审查**；否则由主执行者直接执行该维度深度审查。无论指定哪个维度，`necessity` 都会作为额外的基础检查项同时执行（见参数解析中的无条件追加规则），不占用深度审查名额。深度模式在基础检查项之上，额外增加专项深度检查： **logic 深度模式（基础 + 额外）：** - + 状态机遗漏转换 - + 异常路径完整性（每个 try 的所有 except 分支是否合理） - + 资源泄漏（文件句柄、数据库连接、锁未释放） - + 幂等性和重入安全 - + 并发原语误用（死锁、活锁、饥饿风险） - + **比较操作审计**：对代码中所有 `==`、`!=`、diff、compare 操作，追溯两端数据的完整变换链，验证变换链的对称性 - + **输入域枚举**：对关键输入（文件内容、API 响应），列举其在不同运行环境中可能的变体（编码、格式、行尾符），评估代码是否处理了所有变体 **security 深度模式（基础 + 额外）：** - + 认证/授权绕过路径（是否存在未保护的端点或逻辑分支） - + 序列化/反序列化风险（pickle、yaml.load、JSON 注入） - + 时序攻击（密码比较、token 验证）和 TOCTOU - + 日志中的敏感信息泄露（密码、token、PII 写入日志） - + 依赖链中的已知漏洞模式 **performance 深度模式（基础 + 额外）：** - + 缓存策略合理性（缓存命中率、过期策略、缓存击穿） - + 并发/异步优化机会（可 await gather 但逐个 await 的场景） - + 各层数据序列化开销（频繁 JSON encode/decode、大对象深拷贝） - + 连接池和资源复用（是否每次新建连接/session） - + 批量 vs 逐条操作模式（循环内单条 INSERT、逐条 API 调用） **architecture 深度模式（基础 + 额外）：** - + 模块职责边界清晰度（单个模块是否承担过多职责） - + API 设计一致性（命名风格、参数风格、返回值结构是否统一） - + 依赖方向合理性（高层是否依赖低层，是否存在逆向依赖） - + 抽象层次是否恰当（过度抽象或抽象不足） - + 关注点分离程度（业务逻辑是否混入基础设施代码） - + 可测试性评估（是否有难以 mock 的全局状态或紧耦合） **integration 深度模式（基础 + 额外）：** - + **端到端数据流追踪**：选择 2-3 个核心数据流，从输入到输出完整追踪，在每个变换节点检查格式/编码是否保持一致 - + **排除/包含列表全量扫描**：对所有硬编码列表（排除目录、文件类型、映射表），用 Glob 扫描实际文件系统，生成覆盖率报告 - + **Git/文件系统交互审计**：检查所有 git 命令调用和文件系统操作对 autocrlf、core.eol、case sensitivity 的依赖 - + **隐式契约文档化**：识别代码中未明确文档化的隐式假设（如"输入文件一定是 UTF-8""远端和本地行尾符一致"），标记为 medium 风险 **portability 深度模式（基础 + 额外，审计 skills 时重点执行）：** - + **跨运行面矩阵**：逐项列出 Claude Code、Codex、CodeAgent、普通 shell 对该 skill 的要求，标出核心流程、适配层和不可迁移部分。 - + **平台专属 token 扫描**：扫描 `Claude`、`Codex`、`CodeAgent`、`AskUserQuestion`、`Read`、`Edit`、`Write`、`Bash`、`apply_patch`、绝对路径、home 目录、plugin 源路径等，判断是必要适配还是不必要绑定。 - + **迁移降级路径审计**：对每个专属工具或外部依赖，确认是否存在等价动作描述、替代命令、缺失时停止条件或人工确认路径。 - + **同步分叉风险审计**：检查是否把同一核心 workflow 复制到多个环境目录后分别修改；如果存在，建议抽出共享说明、生成脚本或明确的 adapter 区。 - + **可迁移性修复建议**：优先给出“保留单一核心流程 + 环境适配薄层”的修改方案，而不是建议维护多个独立版本。 **necessity 深度模式（基础 + 额外，仅在用户显式指定 `necessity` 时进入；自动追加时只执行基础检查项）：** - + **全量引用矩阵**：对目标内每个可引用实体（函数、类、配置项、章节标题、参数名）用 Grep 统计项目内引用计数，输出零引用清单。 - + **推测性抽象清单**：列出所有只有单一实现的接口、只有单一调用方的封装层，逐条给出“保留”或“内联”的结论及理由。 - + **重复对象排查**：对疑似重复的功能，**必须定位到具体的重复方**（文件路径、skill 名或函数名）才产出条目；定位不到具体重复方的“感觉像重复”不写入报告。 - + **整体存在性评估强制输出**：给出完整对比论证——该目标的核心职责是什么、项目内是否已有承担同一职责的机制、合并或废弃的收益与代价分别是什么。 组合模式（如 `logic,security`）：当前会话明确允许启动并行审查员时启动对应数量的并行审查员，每个执行对应维度的深度模式；否则由主执行者逐一执行指定维度。若目标是 skill 且组合中未包含 `portability`，自动追加 `portability`。`necessity` 的追加不设条件：无论目标类型与组合内容，一律追加并执行基础检查项，追加原因与 `portability` 分别说明。 ### Phase 3：汇总与过滤 1. 收集所有维度的发现。 2. 去重：同一 file:line 被多个维度报告的，合并为最高严重度。 3. **置信度过滤**：仅保留 `confidence >= 75` 的问题进入正式报告，低于 75 的归入"低置信度附录"。 - necessity 的"存疑型"问题不因存疑而降低 confidence——其 confidence 表示"四步查证已完整执行且全部落空"这一事实的确定度（通常 ≥75），据此正常进入正式报告；"该内容是否确实无用"的不确定性由 severity 上限 medium 与"存疑型"标记承担，不通过压低 confidence 表达。 4. **稳定 ID**：为正式报告和低置信度附录中的每个问题分配稳定 ID（如 `CA-001`），后续 deferred/todo 和 code-review-fix 都引用该 ID。 5. **爆炸半径评估**：对 `severity = critical 或 high` 的问题，使用 Grep 搜索该函数/类/方法在项目中的所有引用方，记录到 `blast_radius` 字段；若目标是 Markdown/skill 规范且没有函数符号，则搜索相关 heading、frontmatter `name` 或关键短语。 6. 按严重度排序：critical → high → medium → low。 ### Phase 4：健康度评分 根据审查发现计算健康度评分： - 每个维度独立评分 0-100： - 起始 100 分 - 每个 critical 扣 20 分 - 每个 high 扣 10 分 - 每个 medium 扣 5 分 - 每个 low 扣 2 分 - 最低 0 分 - 总分 = 各维度评分的加权平均（全量模式 7 维度均等权重；单项模式为该维度加自动追加的维度；skill 目标自动追加 `portability` 时纳入平均；`necessity` 无条件追加，任何模式下均纳入平均） - 等级：A(90-100) B(75-89) C(60-74) D(40-59) F(0-39) ## 输出格式 保存到 `rpiv/validation/code-audit-{kebab-case-target-name}.md` - 如果 `rpiv/validation/` 目录不存在则创建。 - 默认报告目录是当前工作目录的 `rpiv/validation/`。当目标位于全局 skill 安装目录或其他全局配置目录时，不要把过程报告写回全局 skill 目录，除非用户明确要求。 - `{kebab-case-target-name}` 从目标路径、文件名或 skill 名称生成（如 `neuromem-services`、`backend-app-api`、`rpiv-loop-code-audit`） ```markdown --- description: "代码审计: {target}" status: pending created_at: {YYYY-MM-DDTHH:MM:SS} updated_at: {YYYY-MM-DDTHH:MM:SS} archived_at: null --- # 代码审计: {target} ## 健康度: {等级} ({总分}/100) | 维度 | 评分 | 说明 | |------|------|------| | 逻辑正确性 | {分数} | {一句话总结} | | 安全性 | {分数} | {一句话总结} | | 性能 | {分数} | {一句话总结} | | 架构 | {分数} | {一句话总结} | | 集成与环境 | {分数} | {一句话总结} | | 可迁移性 | {分数} | {一句话总结} | | 必要性 | {分数} | {一句话总结} | **统计：** - 扫描文件数：{N} - 发现问题数：{N}（critical: {n}, high: {n}, medium: {n}, low: {n}） - 过滤低置信度：{N} 个 ## 整体存在性评估 **结论**：{保留 | 简化保留 | 建议合并到 X | 建议废弃}（四选一） **理由**：{该目标的核心职责；项目内是否已有承担同一职责的机制；合并或废弃的收益与代价} > 当结论为"建议合并到 X"或"建议废弃"时，除本节叙述外，还必须在"发现的问题"列表中产出一条对应的 necessity 问题条目（带稳定 ID 与 `status: open`），并在本节标注该 ID，使该结论能进入 `code-review-fix` 闭环。结论为"保留"或"简化保留"时本节不产出问题条目——简化点已由逐条问题承载。 ## 发现的问题 ### Critical id: {ID} severity: critical confidence: {0-100} status: open file: {path/to/file.py} line: {行号} issue: {一行描述} detail: {为什么这是问题} suggestion: | {如何修复，含具体代码建议} blast_radius: | 被 {N} 处调用： - {caller_file}:{line} - {caller_file}:{line} ### High {同上格式} ### Medium {同上格式} ### Low {同上格式} ## 低置信度附录 以下问题置信度 < 75，可能是误报，供参考： {同上格式，但标注 confidence 分数} ``` 如果未发现任何问题： ```markdown ## 健康度: A (100/100) 代码审计通过。未检测到技术问题。 ## 整体存在性评估 **结论**：保留 **理由**：{一句话说明该目标的核心职责及其不可替代性} ``` ## 重要提示 - 每个并行审查员或主执行者的每个审查维度都必须**完整阅读**目标文件，不能只读片段。 - 并行审查员是加速手段，不是正确性前提；不可用时必须由主执行者顺序执行同等审查。 - 审计 skill 时，可迁移性是重点维度；优先发现会导致 Claude Code、Codex、CodeAgent 或普通 shell 之间产生长期分叉的绑定。 - necessity 是唯一在所有模式下无条件执行的维度：未指定维度时随全量执行，指定任意其他维度时自动追加（只跑基础检查项），用户显式指定 `necessity` 时进入深度模式。追加原因需在报告中说明，与 portability 的追加原因分别陈述。 - necessity 的判定必须先完成四步前置查证；查证未完成即断言"没有价值"的发现不得写入报告。存疑型问题的 suggestion 必须给出关闭路径，使误报能转化为设计意图的补录。 - 专注真正的 bug 和风险，不是风格偏好。 - 每个问题必须有稳定 ID、具体行号和可操作的修复建议；文件级问题使用最相关的行号，确实无法定位时使用 `line: 1` 并说明原因。 - 安全问题（密钥泄露、注入）标记为 CRITICAL。 - 置信度评分标准： - 90-100：确定是真实问题，有明确证据 - 75-89：高度可能是问题，上下文支持判断 - 50-74：可能是问题，但也可能有合理理由 - 0-49：不确定，可能是误报 - necessity 存疑型问题：按"四步查证已完整执行且全部落空"的确定度打分，不按"该内容确实无用"的推断确定度打分 - 输出报告兼容 `code-review-fix` 流程（`status: open` 字段），修复时使用 `/rpiv-loop:code-review-fix` ## Deferred 问题跟踪文件 当审计报告中的 critical/high 问题被标记为 deferred 时，必须在 `rpiv/todo/` 中创建对应的跟踪文件。文件格式**必须遵循 `record` 技能的标准模板**： ```markdown --- title: "{问题标题}（审计 {ID}）" type: issue status: open priority: high|medium source: rpiv/validation/{audit-report-name}.md#{ID} created_at: {YYYY-MM-DDTHH:MM:SS} updated_at: {YYYY-MM-DDTHH:MM:SS} --- # {问题标题} ## 问题现象 {从审计报告中提取的问题描述} ## 根本原因 {如果审计已分析出原因则填写，否则写"待分析"} ## 影响范围 {受影响的文件和模块} ## 已知 Workaround {如果有临时解决方案则填写，否则写"无"} ## 已尝试的方案 无 ## 参考 - 审计报告：{source 路径} ``` **关键要求**： - 必须使用 `title`（不是 `description`） - 必须包含 `type: issue` - 必须引用审计报告中的稳定 `id` - 文件名格式：`rpiv/todo/fix-{kebab-case-name}.md`