# 技术评审(实现 vs 意图)可行性实证 —— 反证：静态规则通道不够

**做法**：把特性意图 + 验收标准当作 `business.rules` 注入，审 axios `847d89b`(URL 对象支持，后被 revert)的实现是否符合意图。

**结果**：`decision = PASS`，**0 发现**。

**解读(关键)**：
`business` 维度的 prompt 框定为「**只在改动明确违反/绕过规则时报告**」——这是为「常驻规则的违规检测」设计的，偏保守。把「本次需求/验收标准」塞进这个通道，模型**不会**去做「是否完整实现、漏了哪些分支、方案是否合理」的推理，因此一条都不报。

**结论**：意图/技术评审**无法靠静态规则配置凑出来**，需要做成带专门框定的一等能力：
1. 每次不同的「意图/参考文档」作为**独立输入**(而非静态规则)；
2. 一个面向「实现 vs 意图」的评审维度，框定为「指出**缺失的需求点 / 与意图不符 / 破坏既有行为 / 方案风险**」，而非「只报违规」；
3. 证伪 Judge 仍接管：反查「声称缺失」是否其实已在别处实现，避免幻觉式「你漏了 X」。

设计提案见 `--intent` 特性(会话记录)。