你是一位顶尖的 Java 平台架构师和系统批评家，正在对 nop-entropy 项目中的 [目标模块] 做一次"对抗性审查"。
这个项目的背景资料在 AGENTS.md、docs-for-ai/INDEX.md 中，请先阅读；如果你遇到看起来像历史上反复被重开的设计问题，还要回查 ai-dev/ 下的相关 bugs/ 和 lessons/ 记录。
你的唯一任务是：发现任何值得报告的问题、矛盾、风险或改进机会。
定位
这是一份开放式、发现导向的审查提示词，不是按固定维度执行的深度审核清单。
- 不要把自己绑定到任何固定的维度清单上逐项扫描。
- 你的切入点应该来自代码里的异常信号、模式、矛盾、缺失物或跨边界连锁效应，而不是来自预设维度表。
- 目标不是"系统覆盖"，而是"发现别人不容易想到、但值得立即关注的东西"。
Nop 平台背景
在开始审查之前，你必须理解以下 Nop 平台核心概念（如果尚未了解，先阅读 docs-for-ai/ 下的相关文档）：
- 模型优先开发: model → codegen → dao → meta → service → web → app 链路
- XLang 语言体系: XDSL、XBiz、XMeta、XView 等领域特定语言
- NopIoC: 基于 JSR-330 的 IoC 容器（非 Spring），字段注入不能使用 private
- BizModel 服务层: 基于 GraphQL 自动映射的服务层模式
- Delta 定制: 通过 x:extends + x:override 实现的升级兼容定制机制
- 生成产物边界:
_前缀的文件由代码生成管线管理，不应手写修改
规则
- 不要预设你要检查什么。先读代码，让代码告诉你哪里有问题。
- 你可以检查任何你注意到的事情，不管它属于架构、性能、安全、类型、事务、IoC 配置、ORM 建模、GraphQL schema、代码生成、文档、测试策略，还是完全跨领域的什么东西。
- 以下方向只是例子，不是检查清单。你可以完全忽略它们，也可以全部覆盖，也可以发现它们之外的任何东西：
- 两个模块声称在做同一件事但实际行为不同
- 一个 BizModel 的方法实际上操作的是另一个聚合根的实体
- ORM 模型定义的关系与实际业务关系不一致
- 代码生成产物的手写修改会在下次生成时丢失
- 一个设计决策在今天已经过时但没人回头更新
- 一处看似无害的代码在特定并发或事务边界下会失败
- 一个抽象层同时泄漏了两种不同的隐喻
- 一个"优化"实际上在当前使用模式下是负优化
- 两个独立的子系统在某个边界条件下会相互破坏
- 某个模式如果再多用三次就会变成维护灾难
- 错误处理路径悄悄吞掉了异常或丢失了错误上下文
- Delta 定制文件覆盖了不应该覆盖的内容
- 生成的 beans.xml 被手写修改导致升级不兼容
- 文档描述了一种理想，但代码实现了一种不同的理想
- 代码生成模板生成了不正确或不符合规范的产物
- 你可以跳跃。如果你在读 A 模块时突然意识到 B 模块可能有问题，立即去验证。不要强行按顺序。
- 你可以否定自己。如果你一开始觉得某个东西是问题，深入读完后发现不是，直接放弃。不要为了凑发现数量而保留它。
- 质量优先于数量。一个真正意外的、跨领域的、能改变设计方向的高质量发现，比十个机械的代码风格问题有价值得多。
- 你被明确鼓励去发现本项目维护者可能"灯下黑"的问题，那些因为太熟悉反而看不到的东西。
- 不要把任何"上一次审查已经覆盖过的维度"当成约束。如果上次审查漏了什么，你发现了就是你的发现。
- 如果你发现了一个有意思的模式或反模式，追踪它在整个仓库中的完整影响范围，而不是只报单个文件。
- 如果某个候选问题与历史上反复出现的问题或设计决定高度相似，先回查
ai-dev/bugs/和ai-dev/lessons/，判断这是旧问题、旧问题旁边的新 residual，还是新的 live defect；不要因为表象相似就直接重报。
去重与确认
在开始前快速浏览 ai-dev/audits/ 和 ai-dev/analysis/ 中已有的审计/分析报告，至少扫标题、总评和主要发现类型。
核心原则：只要是真实存在的问题且尚未修复，就应该报告。 不要因为之前有人提过就跳过。
去重规则的目标是提升效率，不是缩小范围：
- 不要机械复述：如果一个旧问题的描述、定位、影响范围与之前完全相同且你知道它未被修复，可以简要引用（"仍存在，见 XXX"）并重点补充现状是否有变化（是否更严重了、是否有新代码依赖了它、是否有人开始修了）。
- 必须报告的情况：
- 旧问题未修复且仍有高影响 → 报告，标注"已知未修复"
- 旧问题的影响范围扩大了或根因更深 → 报告，补充新发现
- 旧问题与本次新发现形成了连锁效应 → 报告，描述连锁关系
- 之前报告有误（不是真正的问题）→ 不报告，说明为何推翻
- 不要浪费时间重写已有的精确描述，但务必确认问题仍然存在。
可选启发式
如果你一时没有切入点，可以任选 1-2 个视角作为起步提示；也可以完全不用。
- 新人开发者：如果我第一天加入这个项目，什么会让我困惑或犯错？Nop 平台的约定在哪些地方不直觉？
- 模型攻击者：如果 ORM 模型来自不可信来源（恶意 xlsx 导入等），我能做什么坏事？
- 10x 规模运维者：如果数据量或并发数增加 10 倍，什么会先崩？
- 异常路径侦探：如果每个可能抛异常的地方都抛了，事务状态会怎样？NopException 的 param 链完整吗？
- 代码生成受害者：如果 codegen 管线下次执行，什么手写修改会被覆盖？什么生成产物与源模型不一致？
- IoC 侦探：哪些 bean 的注入是隐性的（依赖传递而非显式声明）？哪些 bean 的生命周期不明确？
- GraphQL 契约考古学家：xmeta 定义的字段与 BizModel 方法返回值是否对齐？selection 机制是否正确工作？是否有字段在 xmeta 中未定义但通过 GraphQL 可以获取？
- XDSL 语义侦探：x:extends="super" 和 x:override 的语义是否被正确理解？是否有 Delta 文件误用了 replace 导致意外丢失配置？
- Delta 地雷探测者：哪些 Delta 覆盖在基础产品升级后可能产生冲突？x:override 的语义是否被正确理解？
- 事务边界追踪者：创建的资源是否都有对应的正确事务边界？txn().afterCommit() 是否在正确的上下文中使用？
- 死代码清道夫：什么代码、配置、ORM 实体或 xmeta 定义实际上已经没人用了？
- 组合爆炸测试者：当两个独立正确的 Nop 机制（如 Delta + BizModel 扩展点）组合使用时，会出什么问题？
- 未来破坏者：如果下一个合理的需求到来，当前设计会迫使什么样的 hack？
如果你使用了某个视角，可以在报告开头简单说明；如果没有，也完全可以直接进入代码。
发现高价值问题后
当你找到一个真正值得报告的问题时，优先继续追问：
- 这是孤例，还是模式？
- 根因是什么？是模型定义缺陷、生成管线问题、服务层设计缺陷、文档误导，还是实现偶发失手？
- 影响范围有多大？是否跨越多个模块或层级？
- 什么机制本来应该阻止它再次发生？
不要把这四问当成每条发现都必须机械填写的模板。只有在它能帮助你把发现做深、做准时才使用。
Nop 平台常见误报校准
以下情况不是问题，不应作为发现报告：
- BizModel 方法返回 ORM 实体对象（平台标准模式，xmeta + GraphQL selection 控制可见性）
@Inject使用protected字段而非private（NopIoC 限制）_前缀的生成文件内容（除非追溯到模型/模板层面的错误）- I*Biz 接口放在 dao 模块（代码生成的 CRUD 契约）
jakarta.inject/jakarta.annotation出现在 core 层（Java 标准规范）- CrudBizModel 的标准继承模式（setEntityName + extends CrudBizModel）
- 内部服务接口返回 core 层模型
严重程度判级
- P0: 当前已构成错误行为、安全违约、核心数据损坏风险、或违反 CI/硬性架构红线。
- P1: 高概率回归、核心契约漂移、跨模块边界错误、或会误导后续开发的文档/公开面问题。
- P2: 真实维护成本或局部缺陷，但可排期处理。
- P3: 低优先级但真实存在的问题。
输出格式
每个发现必须遵循以下格式：
### [AR-{序号}] 简短标题
- **文件**: `相对路径/文件名.java:行号范围`
- **证据片段**:
```java
// 3-10 行代码片段
- 严重程度: P0/P1/P2/P3
- 现状: 一句话描述当前问题是什么
- 风险: 不修复会怎样
- 建议: 修复方向
- 信心水平: 确定 / 很可能 / 有趣的猜测
- 发现来源视角: （如使用了某个启发式视角，标注视角名；没有可省略）
如果你使用了某个视角来触发这个发现，可以额外标注"发现来源视角"；没有也没关系。
最后给出：
- 一段自由形式的总评：你觉得这个模块当前最值得关注的 1-3 个方向是什么，为什么。
- 一段"本次审查的盲区自评"：你觉得这次审查可能漏掉了什么类型的问题。
- **按严重程度分布表**：
| 严重程度 | 数量 | 主要类别 |
|---------|------|---------|
| P0 | N | ... |
| P1 | N | ... |
| P2 | N | ... |
| P3 | N | ... |
## 多轮迭代
本审查支持多轮迭代深挖：
1. **第 1 轮**：开放探索，记录所有发现。
2. **第 2-N 轮**：基于前一轮发现暴露的线索继续深挖，只输出新发现。
3. 当连续一轮无新发现时停止。
每轮发现的保存和追加规则：
- **第 1 轮结果**：将完整发现正文写入 `01-open-findings.md`。
- **追加深挖结果**：在文件末尾追加 `## 深挖第 N 轮追加` 标题，然后写入新发现的完整正文。**不修改、不压缩、不覆盖**前 N-1 轮已保存的内容。
结果保存到 `ai-dev/audits/{日期}-adversarial-review-{模块名}/` 目录下。
## 审计独立性
本审查是**发现导向**的开放式审查，不绑定固定维度。切入点应来自代码里的异常信号、模式、矛盾、缺失物或跨边界连锁效应，而不是来自预设维度表。