审查流程与证据

high 审查先确定范围并把 diff 保存、分块，再加载规则、并行发现、去重验证、反向查漏，最后形成规范化结果。具体 agent 数量取决于目标、规模和触发的专门检查，不能用概述中的固定数字估算所有运行费用。

小改动按检查角度分工

正确性检查分别逐 hunk 读取、追踪被删除的行为、沿调用方和新增字段读点追踪，再按语言陷阱或包装/代理类型增加专门检查。质量检查区分重复实现、修复层次与抽象、同类代码一致性。

其他检查涵盖安全、性能、测试覆盖、构建测试，以及攻击者、值班维护和长期维护视角。PR 还会核对关联 issue 的原始复现和问题归属，不能只信作者对修复的描述。

跨文件追踪不仅检查改动后的函数能否被旧调用方使用，也查新增字段是否在真实路径被填充和读取。超过十个修改符号时，调用方方向优先签名变化，新增字段的生产者方向不按该阈值缩减。

大 diff 按区域覆盖

源码改动超过 500 行，或总 diff 超过 3200 行时，改为约 400 行的区域 agent，每个对负责区域执行各维度检查。边界尽量落在 hunk，超大 hunk 只在顶层声明处分开，不在函数中间切。

每块需返回 Covered 收据，缺收据会补审；测试、文档和锁文件计入总差异，但源码阈值单独计算。改动集中在现有 300 行以上、至少 40% 为新内容的源码文件，或源码文件有 800 行以上变更时，还会针对全文件不变量做额外检查；测试和生成文件不符合该专门检查条件。

验证与反向查漏

每个 verifier 最多处理八条发现，回到真实代码追踪失败场景。否定 Critical 要提供反证；证据不足时降置信度，而不是只写“太推测”就删除。

反向审计携带累计发现清单继续找遗漏，连续两轮没有新发现才算收敛。小 diff 默认最多十轮，分块 diff 五轮；至少 3000 effective lines 的巨大 diff 在有显式 deadline 时降到三轮，只有默认时间墙时仍是五轮。

review.reverseAuditRounds 只能降低上限，不能提高。达到轮数或时间限制要披露截断，不能声称已收敛；后面找到的新发现也需验证。

PR worktree 与探测

同仓库 PR 使用 .qwen/tmp/review-pr-<number>，避免切换当前分支；可在其中安装依赖和运行构建测试。这是会执行项目命令的审查，不应理解为纯文本读取。

改变代码来验证的 mutant 或 probe 使用旁边的独立临时 worktree，避免污染其他读者的视图。review 会话有 lease，第二个会话不能拆掉正在审查的目录；结束后清理临时树，报告留在主项目目录。

审查指令类文件时，具备代码树的流程还可在一次性副本执行变化后的指令，比较执行结果与文案承诺。该检查有真实执行成本，不能从“只修改 Markdown”推断审查不会运行操作。

可复核的发现数据

规范化结果放 .qwen/tmp/qwen-review-<target>-findings.json，终端、Markdown 和发布内容都从同一文件生成。每条有唯一 id、severity、confidence、source、summary、最多六十字符的 shortSummary、failureScenario 和非空 locations。重复 ID、未知严重度、缺场景或缺位置会在写入时拒绝。

同一模式跨文件可合并为一条发现，但保留每处 location。若测试在基线已失败，test-delta 可把引用该失败文件的 Critical 降为 Suggestion 并保留测量证据；若这次确实引入不同失败原因，应同时列出两边证据重新判定。

终端渲染证据可通过独立 tmux server 捕获 .ans，装有 freeze 时再生成 PNG。报告需区分像素、终端字节或仅文本推断，不能把未生成图片的检查描述为截图验证。