应用审查发现与修复审计
在本地工作树应用已验证发现，逐条记录结果并检查新增假设。
--fix 用于会在审查后保留的本地工作树。PR 的临时 worktree 会清理，因此该参数在 PR 目标上被警告忽略。
/review --fix
/review src/auth.ts --fix有效 --fix 至少使用 medium，避免直接应用 low 的未验证发现。它不自动提升到 high；high 增加的是查找遗漏，不是已发现问题可否修改的唯一门槛。
每条发现必须有结果
| 结果 | 含义 |
|---|---|
| fixed | 修改已落入工作树 |
| skipped | 未应用，附原因，仍需处理 |
| no_change_needed | 原发现不成立或代码已处理 |
改变预期行为、需要超出审查范围的大范围改动或复查后发现误报时，流程不会盲目继续套修复。以最终记录和原因判断结果，不能只看“修复了六条”就忽略最初九条中的其余三条。
结果经 qwen review findings --outcomes 校验，缺少任意发现的结果会被拒绝。规范化列表里的 ID 是连接修复结果和后续复查的依据。
修复后检查什么
首次编辑前用 fix-delta --snapshot 记录工作树，使用一次性 index，不改用户 index 或 stash。之后用 fix-delta --since 得到实际新增修复 hunks，交给单个 fix-audit agent。
它检查每个修复新引入的边界、键、生命周期、共享资源或顺序假设，是否被测试、类型或唯一来源约束。它不重新审查原始 diff，不新增审查 findings，也不改变原 verdict；未被约束的假设写入 Fix audit 与相关 outcome note，供后续处理。
没有 fixed 且没有实际修改时跳过。记录与工作树不一致会报告；若 fixed 对应的任何位置都没被 hunk 触及，会标为未证实，但不会仅因此拒绝，因为修复可以合法落在另一文件。
修复差异的范围
审计包含 HEAD 跟踪文件及未被忽略的其他文件。子模块、嵌套仓库、HEAD 未跟踪的 ignored 文件，以及审查临时目录名称族内的文件不在范围内。
二进制只显示 Git 的差异提示，Git LFS 显示指针；改变 ignore 规则可能把此前隐藏的文件作为新增纳入。快照到比较之间有提交会报告，不能把这一结果当作每个磁盘字节都检查过。
交互式后续修复
本地审查之后提交 fix these issues 也可应用发现。PR 审查的临时树已清理，不提供同样的后续修复入口。已使用 --fix 时不会再给同一修复提示。
后续 ghost text 接受后只是填入输入框，实际提交才执行相应请求；见后续建议。审查和修复完成不等于已提交或推送代码。