判断力审查——超越 lint 的纪律

上级: structure

分工： lint / 类型检查 / 测试守的是机械正确性（mechanical-guardrails）；审查指南守的是判断质量——"机械正确 ≠ 架构干净"。这是一份自我演化的文档；第一轮审查产出了发现 1–9 并触发了一次重构。

流程： (1) 先读意图再看实现（先从命名 / 签名猜行为）；(2) 走通一条真实的端到端路径——债务藏在跨模块的接缝处，而不是单元内部；(3) 反向走一遍错误路径（错误是否被吞掉？调用方能不能区分"无数据"和"崩溃"？）；(4) 按 10 个维度打分，记录 file:line + 严重度（blocker / debt / style）+ 一句话；(5) 输出一张审查表——不在原地修。

10 个维度（压缩版）：

if 密度是否匹配意图；
该响亮失败还是该沉默（合法的静默降级需要同时满足三点：预期中的业务状态 + 明确的语义 / 注释 / 测试 + 不会掩盖真实故障）；
单一事实来源（派生数据不落地存储）；
务实版 SOLID；
只在真正的边界上用模式（单方法接口 → 函数类型）；
命名等于行为（本仓库自己的例子：seo 实际指的是 landing / reader）；
状态 / 不变量 / 并发（不变量由数据约束守护，而不是靠调用顺序；flaky 测试本身就是一种设计异味）；
边界 / 泄漏（一行测试法：删掉这个具体插件——base 还能编译吗？）；
错误形态（sentinel 还是 typed）；
测试的诚实性（断言的是"正确"，不是"没崩"；抓住那些悄悄跑了 fallback 却显示绿色的假通过）。

注意这处共振： 这本身就是一道判断质量的关卡——用 harness 理论的读法，审查指南提供的是 lint 机械化不了的语义关卡评分标准（mechanical-guardrails 守的是 α≈0 那一层；这份守的是需要校准判断力的那一层）。