adversarial-beam

对抗式 BEAM 审查门禁

面向 Elixir 系统的 BEAM 运行时架构审查门禁——结果为通过/不通过：由一名盲审子 Agent 按照本门禁规则并以对抗性审查为职责来评判工作；只有每条规则均为 PASS 或 N/A，工作才算通过。此技能只给出评审结果，绝不会修复工作。

这些规则针对一种失败模式：代码假设运行时从未作出的保证——假设重启会恢复数据、邮箱会施加反压、广播一定送达、消息恰好送达一次且按序到达、一次查找的结果到下一次插入时仍然成立、节点本地唯一性在整个集群内成立、系统时钟只会向前。这些错误能顺利通过编译和单元测试，却会以生产事故的形式暴露出来。每条规则都附有一段违规证据，让审查者仅凭产物证据即可判定 PASS/FAIL/N/A。同类门禁 adversarial-elixir 评判范式是否适用（将 OO 习惯照搬到 BEAM 上）；本门禁评判运行时语义——要全面覆盖，请同时运行两者。

适用时机

• 即将合并一项 Elixir 功能，该功能会监督进程、消费事件/任务/流、通过 PubSub 广播，或通过 ETS/Registry 共享状态；你需要对其运行时假设做出客观的 PASS/FAIL 判定。
• Agent（Claude、Codex）编写了符合 OTP 模式的代码，而你希望独立检查它是否假设了广播持久可靠、消息恰好送达一次、跨进程消息有序，或内存状态能够在重启后保留。
• 系统正在为集群部署或更高负载做准备，需要将其中固有的单节点/低流量假设明确列为评审结果。
• 事故复盘修复了一起投递/过载错误，而你希望在受影响范围内排查同类问题。

不要将其用于非 Elixir 代码库（审查提示词的前置条件会中止并返回“GATE NOT APPLICABLE”），也不要在用户需要解释和重构而非评审结果时使用。当应用有证据表明永远不会组成集群时，dist-* 类别应判为 N/A；规则中将 Oban/Broadway 列为典型补救方案，但任何具备相同特性的机制都可通过——审查提示词中包含适用性判断维度。

审查协议

严格按以下步骤执行——门禁的价值在于确保每次审查都以相同方式进行。

1. 确定目标。 明确指出审查对象（差异、文件集或 PR），并记录引用/路径，确保审查针对明确且固定的目标进行。记录技术栈信息（来自 mix.exs 和 config/）——Elixir/OTP 要求、是否存在集群、是否使用 Ecto/Oban/Broadway/PubSub、遥测挂载点。在目标描述中包含仓库根目录——有几条规则必须在差异之外搜索同级 init 函数体、重新水合路径、持久化机制和集群配置（审查者提示词中列出了这些内容）。
2. 加载规则。 阅读 references/_sections.md 以及 references/ 中的每个规则文件（所有 sup-*.md、load-*.md、evt-*.md、state-*.md、dist-*.md、mech-*.md 文件）。
3. 编写审查者提示词。 将规则、目标和技术栈信息填入 references/reviewer-prompt.md。编写的提示词必须完整自足——审查者看不到对话历史，因此不得引用提示词之外的上下文。
4. 派发一位盲审查者。 启动一个 Task 子 Agent，其全部输入仅为编写好的提示词——不得附带对话上下文或评论。
5. 按失败即拒绝原则给出结果。 审查者的结构化输出就是裁决——不进行合并步骤。只有当每条规则的结果均为 PASS 或 N/A 时，总体裁决才为 PASS；任何一条 FAIL 都会导致门禁失败。绝不求平均、衡量严重程度或豁免规则——即使是“轻微”的 FAIL 也仍是 FAIL。如果审查者返回“GATE NOT APPLICABLE”（目标不是 Elixir），则停止并报告这一结果，不要给出裁决。
6. 输出裁决。 填写 assets/templates/verdict.md。若结果为 FAIL，将审查者提出的“通过所缺内容”建议汇总到修复清单中，每项都注明位置，并按类别重要性排序。每条最终结果为 FAIL 的规则都必须出现在修复清单中，并给出可直接照做的具体修改——如果审查者的建议只是重述违规内容，则应根据规则中的 Correct 示例推导修复方案后再输出。

如果同一条规则在未变更目标的重新审查中反复改变裁决，或者人工阅读证据后推翻裁决，这就是规则中的可判定性缺陷——应在 gotchas.md 中记录并完善规则；不得推翻门禁结果。

裁决格式

对于每条规则，审查者都应返回：PASS | FAIL | N/A、证据（file:line 或引用——PASS 和 FAIL 均必须提供证据），以及每条 FAIL 对应的修复方案，该方案应用后应能使规则通过——明确指出修改内容和位置，不得只是重述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	需要防范的错误假设
1	监督与故障设计	sup-	“监督者会重启它，所以我们能恢复”——忽略子进程依赖关系、阻塞 init、未在 terminate/2 中持久化、重启后遗忘状态，以及未等待或未受监督的任务的策略
2	背压与过载	load-	“BEAM 会处理负载”——由外部驱动的摄取使用 cast、没有需求信号的推送流水线、使用 :infinity／盲目重试来处理超时，以及按输入规模扩散的 Task.async
3	事件传递语义	evt-	“事件会按顺序到达，且只到达一次”——将 PubSub 作为业务事实的唯一载体、在创建事务之外将副作用加入队列、非幂等消费者、跨来源排序、阻塞或分离遥测处理程序，以及持久化的广播快照
4	共享状态与一致性	state-	“我刚检查过，它现在仍然成立”——在 ETS/Registry 上先查后写的竞态、让热点路径串行化的纯读取 call，以及按运行时频率调用 persistent_term.put
5	分布式现实	dist-	通过节点本地工具强制实现“每个集群一个”——没有 fencing 的 :global 单例，以及假定 Registry/ETS 的唯一性在整个集群范围内有效
6	运行时机制	mech-	误用时钟、二进制和原子——用墙上时钟计算时长、子二进制在长期状态中固定占用大型父二进制，以及根据外部输入创建原子

易错点

在分派审查者之前，请阅读 gotchas.md——其中预先记录了范围限制（唯一的 fail-open 规则、重形状而非重品牌原则、遥测 attach 与 emit 的区别、将墙上时钟视为数据，以及 cast 本身并未被禁止），以免审查者评判规则范围之外的内容。

相关技能

• adversarial-elixir — 关注范式适配的同类审查关卡：将面向对象／企业级习惯搬到 BEAM 上（分层、将进程视为对象、贫血数据、防御式流程）。使用相同协议，规则互为补充；对于重要的 OTP 工作，请同时运行两者。
• staff-level-elixir — 提供建议的同类技能：针对绿地项目提供“该用哪种工具、遵循哪种约定”的指导和判断建议，这两项内容都被这两个审查关卡有意排除在外。编写或修复代码时使用它；评判代码时使用审查关卡。
• elixir-meta-programming — 在确有必要时，介绍如何正确构建宏／DSL；完全不属于此审查关卡的范围。

参考文件

文件	描述
references/reviewer-prompt.md	供每位盲审查者使用的独立提示词模板
assets/templates/verdict.md	评审报告模板
references/_sections.md	类别定义与顺序
metadata.json	版本和来源参考