用途：在明确的改动范围内找出缺陷和代价高的设计退化。评审结论不等于允许合并、发布或对外通知他人。
模式：改动审查，审查指定的 diff、PR 或 commit；未指定时检查本地已暂存与未暂存改动及相关新文件，并说明基线和范围。可维护性，检查指定文件或函数的代码坏味道，读取 references/maintainability.md 及相关语言示例指引，保持行为不变。审查并修复，用户要求修复时，在诊断后实现范围内的明确修复并验证；仅要求审计时保持只读。
流程：先读仓库说明、预期行为、diff 及相关规格与契约，记录实际审查过的文件和路径，保留无关改动。再读测试及其断言，把改动行为追踪到调用方、状态、错误路径、持久化和外部影响；通过的测试只代表其覆盖范围内有效。按轴审查：正确性看预期行为、边界情况、失败处理、状态转换及相关并发与幂等；安全看真实信任与权限边界及不可信数据流；可维护性看职责与词汇清晰度、多余分支与抽象、重复权威、项目约定优先于任意风格规则；架构看归属、依赖方向、契约变更以及复杂度是被降低还是仅被转移；性能需有证据说明无界工作、查询增长、分配或渲染压力，缺少测量时不要编造延迟估计。
对每个候选问题验证触发场景与改动代码，区分回归、既有问题和未经验证的怀疑，引用真实 file:line 证据，按用户影响和改动成本排序；除被要求外省略外观偏好，不要仅因行数、实现数量或缺少抽象而否定一处自洽改动。
修复：请求修复时应用最小完整修复并运行相应检查；行为变更可用 hai-tdd 制造真实 RED，结构性工作使用编译器、现有测试和针对性检查，不要把无关重构混进缺陷修复。
输出与边界：读取 references/output-template.md，给出发现、实际验证和限定范围的结论；未发现问题仅表示在所审范围内未发现，不代表完美。可审查代码并在有用时运行非变更性检查；未执行就不要声称测试通过，或明确标注为作者或历史证据。代码检查不能证明已部署工作流通过，逐条验收属于 write-technical-acceptance-report。无法解释的运行时失败转 hai-debug，结构性决策或深入 React 分析转 hai-architecture，局部命名决策转 hai-naming，交接时复用已收集证据。