self-review-diff

除非用户要求只进行审计、不做修改，否则请修复明确且低风险的问题。进行高风险修改或创建新提交前，请先征求同意。

检查

阅读适用的 AGENTS.md 指引，并检查：

git status --short
git branch --show-current
git diff
git diff --staged
git ls-files --others --exclude-standard

直接阅读未跟踪文件。如果存在 HEAD，请检查 git diff HEAD 和最终文件内容，确认暂存与未暂存的更改如何相互影响。保留无关修改及其暂存状态。

除非用户限制范围，否则审查所有本地更改；优先关注用户指定的内容。阅读相关代码和测试，并追踪受影响的调用方。

确定审查基线。如果请求审查的功能已经提交，请检查其所属提交或分支差异；工作树干净并不代表无需审查。审查记录请保留在回复或临时空间中，不要写入产品文档。

审计与修复

以审查者而非作者的立场进行审查。除非你无法设法使其出错，否则就假定更改存在问题。不要轻信提交说明、注释、名称、通过的测试或自己对意图的记忆；应根据代码的实际行为进行判断。针对每个更改单元，尝试构造会导致其失败的输入、状态或操作顺序。

检查：

• 正确性、边界情况、并发、错误处理和回归问题。
• 安全性、隐私、兼容性和发布安全性。
• 性能、过时代码、重复代码、可读性和过大的文件。
• 相关测试覆盖、过度（不必要的）测试覆盖、lint，以及对非显而易见不变量的文档说明。
• UI 无障碍性：标签、角色、状态、对比度、文本缩放、焦点、导航、点击目标和动效。
• AGENTS.md 中缺失的持久工作流规则或易踩问题。

跨边界追踪契约

对于有状态、异步或外部集成，沿着调用方、操作、返回结果／事件，直到最终 UI 或持久化状态，追踪发生变化的行为。确认由谁负责接受、完成、重试以及权威状态。检查发现、预检、执行和恢复是否使用了预期的身份与范围，并确保已验证的状态转换得以保留。

选择与实际情况相关的具体高风险序列，而不要只依赖通用检查清单：

• 工作在发起调用返回前就已完成；其后续逻辑不得重新激活已结束的轮次，也不得覆盖更新的状态。
• 修改已成功，但响应丢失，随后恢复读取也失败；应区分已确认接受、明确拒绝和结果未知，且不得重复副作用。
• 在 await 期间发生取消、替换、删除或选择变更；发布或修改状态前，应重新解析权威状态。
• 事件重复、延迟或乱序；应区分操作失败与会话／进程失败，并协调待处理和已解决的交互。

只使用与更改相关的场景。对于疑似 Bug，指出具体触发条件和可观察到的后果，然后尝试证伪：确认触发条件确实可达，且没有现有防护。放弃已证伪的问题，不要为了凑数而报告；无法确认或证伪的发现应标注为“未经验证”。优先通过实际入口和调用方进行确定性复现；只断言辅助函数可能会漏掉接线错误。使用现有测试接缝控制事件顺序，不要依赖定时休眠。修复某条路径后，检查语义变化影响到的同类路径和调用方。

对于有明确依据的问题，可自动修复范围内的格式问题或错别字、使用现有辅助工具编写的小型测试、明显缺失的无障碍元数据、已证实未使用的私有代码，以及解释受支持不变量的注释。

更改行为、契约、持久化逻辑、生成代码、发布逻辑、UI 交互／布局、快照、测试预期／基础设施、公开文档或 AGENTS.md 前，请先征求同意。进行大范围重构／格式化或删除动态引用的代码前，也请先征求同意。报告延后处理的问题，并注明相关文件、风险和建议的修复方案。

验证并重复检查

运行范围最小且相关的 lint、测试、类型检查或快照检查。对于范围未变且已通过的检查，可沿用结果；重新运行失败、不完整或结果不确定的检查。说明跳过的检查。验证失败后，除非用户另有要求，否则不要提交修复。

让验证证据与审查的契约相匹配。测试套件通过或测试数量很多，并不能证明未测试的顺序或组合故障已得到覆盖。对于确认的行为缺陷，在用户授权的范围内添加有针对性的回归测试；对于影响较小的修改，不要增加大量测试用例。

每轮都要刷新状态和差异，并运行 git diff --check、git diff --staged --check，以及在 HEAD 存在时运行 git diff HEAD --check。使用 git diff --no-index --check -- /dev/null "<file>" 检查未跟踪的文本文件；即使退出码为 1，只要输出为空就表示检查通过。使用常规制品检查验证二进制文件。

要求对最终更改连续两轮检查均无问题。第二轮要质疑第一轮的假设，并沿调用链检查修复对其使用方的影响；相关时还要检查其他故障顺序。重复空白检查或重读相同的正常流程，不算另一轮审查。每次修复后都重新开始检查；遇到搁置或反复出现的问题时，停止并报告。

提交

遵循用户对提交的偏好。否则，验证后修改所属提交。若没有对应的所属提交，则不要提交修复；若归属不明确，请先询问。

若要在分离的 HEAD 状态下提交、重写堆栈之外的非顶端提交或执行复杂变基，必须先获得明确指示。继续变基时使用 GIT_EDITOR=true。除非用户提出要求，否则不要推送，也不要运行 gh stack push、submit 或 sync。

对于 gh stack：

• 仅当 gh stack view --json 成功，且输出包含 branches[].name 中的当前分支时才使用它；退出码 2 表示没有受跟踪的堆栈。避免使用不带参数的交互式 view 和 modify。遇到退出码 10（存在未完成的修改会话）时，使用 gh stack modify --abort 恢复。
• 切换到所属分支，使用 git commit --amend 修改提交，然后从该分支运行 gh stack rebase --upstack，以更新后续分支。如果存在多个远程仓库且未设置 remote.pushDefault，则传入指定的 --remote <name>。
• 变基退出码为 3 时，暂存已确认的冲突解决结果，并运行 gh stack rebase --continue；--abort 会恢复所有分支。若无法有把握地解决冲突，请报告。

报告范围和基线、修复内容、剩余问题、无问题检查轮数、已运行／复用／跳过的验证，以及提交／堆栈状态。适用时请写明“审查范围内未发现问题”，并区分已验证的行为与未检查的路径或残余验证缺口；审查无问题不代表已穷尽所有可能。