Ll Iteration Audit Fix

---
name: ll-iteration-audit-fix
description: 跨会话「对抗式」代码审计与修复流水线 —— 把范围拆解后，由两个子对话结成「查找者 / 对抗审查者」对子逐范围审计，主对话统筹、跟踪覆盖率并终审；审计阶段严格只读，清理阶段需用户批准。当用户要求「全库审计」「垃圾代码/slop 清理」「死代码/冗余抽象清理」「对抗式审计」「结对审计」「覆盖率审计」时使用。
---

# ll-audit-fix —— 跨会话对抗式审计与修复

**核心机制：主对话（统筹 + 终审）× 两个子对话结对（查找者 + 对抗审查者）**，可并行铺开多组对子。

## 适用场景

- 全库/大范围的「垃圾代码」审计：**无用测试、不必要的包装层、死代码、冗余抽象**
- 需要**高置信度**结论（不是"大概像死代码"，而是"追过真实调用路径、确认无人调用"）
- 需要**覆盖率可见**的审计（明确知道哪些读了、哪些没读）

---

## 阶段 A：总览与拆解（主对话亲自做）

1. **先用一个"集群"梳理整体布局**（多个子对话并行、各自负责一片目录/模块），产出一张**全局地图**：
   模块清单 / 依赖关系 / 规模 / 可疑热点；
2. **把地图切成"小范围"**（每片小到**一个对子能在有限轮次内完整通读**）；
3. **排定范围清单**（编号 + 路径 + 预估文件数 + 负责人）；
4. **写清"排除面"**（哪些范围本次不查、为什么）—— 覆盖率报告要用。

## 阶段 B：逐范围结对审计（核心，可多组并行）

**每个范围开两个子对话，角色不可混：**

### B1 查找者（Finder）
- **完整通读**该范围的**每一个文件**（不是抽样、不是搜索）；
- **逐一追踪真实调用路径**（从入口出发追到叶子，确认每个符号的调用方/被调用方）；
- 产出**候选清单**，每条必须含：`位置（file:line）+ 问题类型 + 证据（谁调用/谁不调用）+ 初步影响判断`；
- **允许并鼓励"零发现"**（该范围确实干净就写"零发现"，不要为凑数编条目）。

### B2 对抗审查者（Adversarial Reviewer，独立新对话）
- **拿到 B1 的清单，逐条"攻击"**，重点质疑三类：
  1. **真伪**：这条真的没人调用吗？（反射/插件/字符串路由/配置驱动的调用链常被漏掉）
  2. **影响面**：删了会怎样？跨模块/跨版本（老会话数据、外部集成）会不会断？
  3. **是否已废弃**：是"死代码"还是"保留的历史兼容层"（有注释/工单依据的另论）；
- **必须自己读文件验证**，不得只凭 B1 的描述判断；
- 产出**逐条裁决**：`成立 / 不成立（附反证）/ 成立但需前置条件`。

### B3 主对话终审
- **只采纳"经受住对抗"的条目**；
- 对"成立但需前置条件"的写清前置；
- 汇总为**按优先级排序的清理计划**（P0 立即清 / P1 排期 / P2 观察）。

## 阶段 C：清理与验证（可选，**必须先获用户批准**）

- 用另一个集群按清理计划**逐条实施**（每条独立提交、可回退）；
- **每清理一条就跑一次相关测试/构建**（不要攒到最后）；
- **独立验证**：由**没参与清理的**子对话复核（"清理后是否真的等价"）；
- 遗留问题由主对话自行处理，并把「为什么留」写进报告。

---

## 硬规则（不可违反）

1. **禁止 `rg` / `grep` / 自动化符号扫描作为审计手段** —— 必须**完整通读文件 + 追踪真实调用路径**（搜索只能用来定位"从哪读起"，不能用来下结论）；
2. **审计阶段严格只读**（不改代码、不删文件、不建分支）；
3. **接受"零发现"** —— 覆盖率比"发现数量"重要；
4. **跟踪覆盖率**：交付必须写明「读了哪些 / 没读哪些 / 为什么没读」，**未覆盖面要显式列出**；
5. **最大化并行**：并发槽位尽量占满；**跨对话协作是核心手段**（必要时另开独立会话做对子，而不是只靠单会话内的子代理）；
6. **不限定模型**：子对话/子代理用哪个模型按可用性与成本决定（本技能只规定**角色分工与流程**）；
7. **对子必须"独立"**：B2 不能是 B1 的同一次对话延续，**也不能复用 B1 的上下文**（避免确认偏误）。

## 交付物

| 交付 | 内容 |
|---|---|
| **清理计划** | 按优先级排序；每条 = `位置 / 问题 / 证据（调用路径）/ 建议动作 / 风险 / 是否需前置` |
| **覆盖率报告** | 读过 N/M 文件；**未覆盖面清单** + 原因 |
| **对抗记录** | 每条候选的"查找者主张 vs 对抗者裁决"（可追溯） |
| **零发现清单** | 明确列出"查过但干净"的范围（防重复劳动） |

## 与 Reasonix 具体设施的对接

- **跨对话协作**：`talk_to_session` 派单/收货（子对话按 `reasonix-for-ai` 分组）；**文件留痕**用 `docs/report/`；
- **并行度**：受本机并发限制时，分批派遣（每批 3-4 个），并监控限流；
- **派单模板**：范围 + 角色（Finder/Reviewer）+ 硬规则（禁 grep、要读全文）+ 交付格式（逐条含 file:line）+ 明确"只读"；
- **裁决留痕**：主对话的终审结论与被否条目都要落盘（后者防止下轮重复劳动）。

## 反模式（做过就知道的坑）

- ❌ **只派"查找者"不派"对抗者"** ⇒ 结论置信度低，清理时才发现误判；
- ❌ **让对抗者复用查找者的上下文** ⇒ 变成自我确认，失去对抗意义；
- ❌ **用 grep 结果当"无人调用"的证据** ⇒ 反射/配置驱动/字符串路由的调用链全漏；
- ❌ **为凑数量产条目** ⇒ 真问题被噪声淹没，用户失去信任；
- ❌ **不清点覆盖率** ⇒ 报告看着完整，实际只查了 20%。