dsh-code-review

1# 按真实行为要求审查代码
2 
3阅读[项目上下文](references/project-context.md)、[验证证据](references/evidence.md)以及改动区域的实际需求。除非用户要求修复，否则保持只读。未经用户授权，不向外部发布审查意见。
4 
51. 明确准确的基线与目标提交，或本地差异及暂存、未暂存等修改层。审查远端 PR 时获取其当前引用；目标分支或内容更新后重新确认。
62. 将变化的接口对应到实际数据提供方和调用方。判断差异前，阅读周边代码、相关决策和项目必需检查。
73. 优先检查正确性、安全、生命周期和必需行为是否损坏。资源或错误处理变化读[生命周期](references/lifecycle.md)；异步测试读[测试可靠性](references/test-reliability.md)；可见界面读[UI](references/ui.md)；文字变更读[文档写作](references/prose.md)。默认值、校验、依赖或抽象变化读[编码规范](references/code-conventions.md)；覆盖率或测试设计问题读[测试选择](references/test-strategy.md)。
84. 追踪校验是否真正保护了目标操作，包括其他入口和直接调用方。检查边界值、最终输出或保留内容的大小，计入元数据和多字节文本。核实取消、部分成功、资源释放和派生状态。
95. 检查实际交付入口、公开导出、构建是否为当前版本以及真实测试证据。重要结果应有独立断言，新增约束应有会失败的错误样例。检查全绿或作者自述不能代替语义审查，也不要无故重跑无关的高成本检查。
106. 检查必要性：每个抽象、兼容分支和通用 API 都应有当前行为要求或调用方。不要仅凭文本搜索结果猜测并移除受支持行为。
117. 确认当前文档、默认值、错误和界面文字与代码一致。翻译改动已经在范围内时检查含义，不自行启动翻译任务。
12 
13只报告可采取行动的问题，包含文件和行号、具体触发条件、影响及证据。区分缺陷与可选建议，不为凑数量而编造问题。没有充分依据的问题时直接说明，并指出重要覆盖限制。审查发现不等于获得修改或推送权限。
14 
15报告验证结果前，将每项“已经执行”的说法对应到真实工具调用和结果。代码推理可以支持发现，无需假称执行过测试；标明这是静态检查。建议检查写“未运行”，用户提供的历史日志注明来源。不得编造成功命令或工具拒绝。