12 · 评审

dsh-code-review：阻断项与人工检查

关键文件.agents/skills/dsh-code-review/SKILL.mddocs/cookbook/maintaining-dsh-code-review.md.github/review-ownership/

评审 skill 开宗明义："Read the requirements before judging the diff." 先把改动路径对应到相关的规则页，读完要求再看 diff。凭记忆中的规则审 diff，就是违规通过评审的方式。它还强调优先级：正确性、生命周期、安全和必需行为优先于风格；一条有根据的阻断意见胜过一串小毛病。

六条阻断要求

1. 新文字要做语义审查。每段新增或修改的 Markdown、JSDoc、注释、prompt、描述、诊断和可见字符串，都用 dsh-prose-standard 审查覆盖度、准确性、位置和质量。自动检查无法证明这些。
2. 文档与代码一致。配置、默认值、错误、协议字段、事件和公共行为的变化，要在同一 diff 里更新 README 和 JSDoc。
3. 核心类型文档一致。改动主干或 seam 的类型，要更新对应的 subsystems 页和 type-equiv 条目。
4. Cordis 所有权与清理。应用 cordis-styling-nitpicking 的三条 P0，并确认每个注册表贡献都有销毁测试。
5. 必需的证据存在。作者跑过与改动相关的本地检查，CI 覆盖穷尽的矩阵；评审补上两者都发现不了的语义缺口。
6. UI 文案归 locale。拒绝嵌在 JSX、模板、辅助函数返回值、无障碍属性或组件默认值里的产品文字。

人工检查（节选）

检查	要问的问题
范围与必要性	每个抽象、状态机、选项、防御性拷贝和兼容路径，对应哪个当前契约和生产消费者？有没有无关功能和投机性的通用化？
配置与公共选择	每个默认值、公共操作集、格式或引入的外部概念，有什么消费者证据或先例支撑？
模型视角	模型在各模式下实际收到什么 prompt、schema、结果和诊断？有没有任务之外的概念？
强制执行	沿每条拒绝路径追到真正执行的操作；绕过 schema、prompt、外观层的调用者能否绕过它？
测试强度	断言会因预期的回归而失败吗？验证的是外部状态、日志、事件、销毁，还是只复述实现、相信 agent 的自述？
负向对照	每条修改过的验收规则，是否有一个故意非法的用例通过真实运行器失败？
已实现的 Note	PR 实现了一个提案，有没有在同一 diff 里把 Note 移到 implemented/ 并改写成现状？

报告与回应

每条意见写明缺陷、位置、影响和证据，区分阻断项和建议，省略已经被绿色门禁强制的问题。收到评审时逐条核实，在技术上修复或反驳，不做表演式的同意。