adversarial-elixir

Adversarial Elixir Gate

一个 Elixir/OTP/Ecto/Phoenix 审查关卡——通过/不通过：由一个盲审子 Agent 按照此关卡的规则，以对抗性审查要求评判工作；只有每条规则都判定为 PASS 或 N/A，工作才算通过。此技能只给出判定，绝不修复工作。

这些规则针对一种失败模式：将错误的思维模型带到了 BEAM 上的代码——面向对象/企业级分层、将进程视为对象、贫血数据、防御式控制流、照搬循环，以及不必要的元编程。规则以官方 Elixir 反模式目录为依据，每条都附有一段违规证据，让审查者仅凭产物证据即可判定 PASS/FAIL/N/A。需要权衡判断的重构建议留给配套的建议技能 staff-level-elixir。

适用场景

• Elixir 差异、功能或 PR 即将合并，需要客观的 PASS/FAIL 结果，而非建议性反馈。
• 代码由 Agent（Claude、Codex）编写，你希望进行独立检查，确认它没有复现面向对象习惯——在 Ecto 外包装仓储、*Service/*Manager 层级、每个实体一个 GenServer、仅有单一实现却引入依赖注入行为模块、把 raise/rescue 当作 if 使用。
• 由 Java/Ruby/Python 移植的代码（或由不熟悉 BEAM 的开发者编写的代码）需要在固化前审查其范式契合度。
• 某项重构声称“已改得符合惯用写法”，你希望核实这一说法，而非想当然地接受。

不要将其用于非 Elixir 代码库（审查者提示词的前置条件会中止并返回“GATE NOT APPLICABLE”），也不要在用户需要解释和重构而非判定时使用——这是 staff-level-elixir 的职责。目标没有 Ecto 时，arch-delete-repository-over-ecto 判定为 N/A；目标没有外部输入路径时，flow-normalize-at-boundary 判定为 N/A。项目 Elixir 版本中尚不可用的改进方案，将按照最接近的可用方案进行评判——审查者提示词附带了版本门槛表。

Review Protocol

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

1. 确定目标。 精确确定审查对象（差异、一组文件或 PR），并记录引用和路径，确保审查针对明确且固定的目标。记录 Elixir 版本和关键依赖项（来自 mix.exs——elixir: 要求，以及是否使用 Phoenix/Ecto）。在目标描述中包含仓库根目录——arch-drop-di-behaviour-single-impl、type-protocol-over-type-dispatch、proc-consolidate-interface 和 meta-use-is-not-import 要求在差异之外搜索实现模块、重复的分派位置、回调所属模块以及 __using__ 函数体。
2. 加载规则。 阅读 references/_sections.md 和 references/ 中的每个规则文件（所有 arch-*.md、proc-*.md、type-*.md、flow-*.md、iter-*.md、meta-*.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 提供应用后可使规则转为 PASS 的修复方案——注明具体修改及其位置，不能只是重述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	所针对的异类模型
1	企业仪式与分层	arch-	基于 Ecto 的仓库/DAO 包装器、按实体划分的 *Service/*Manager 模块、只有一个实现的 DI 行为、在有副作用的回调中计算领域决策
2	将进程视为对象	proc-	按实体创建 GenServer 并映射数据库行、将 Agent 用作可变变量、消息元组泄漏到所属模块之外、在可分区状态上使用全局命名的单例管理器
3	贫血数据建模	type-	将固定形状的裸映射作为实体传递、多布尔值和字符串化状态、在多个模块中重复按类型标签分派、结构体达到 32 个字段的运行时上限
4	防御式控制流	flow-	使用 raise/rescue 将预期结果转换为分支、静默吞掉必需值的 nil 防护、在核心中再次检查原始外部输入
5	命令式迭代	iter-	使用 reduce/递归重新实现可命名的 Enum 组合器——FAIL 必须指出具体要替换成什么
6	不必要的元编程与耦合	meta-	用于编码普通数据的一方宏 DSL、仅执行导入操作的 __using__ 函数体、在编译时调用其他模块的模块属性

注意事项

在分派评审者之前，请先阅读 gotchas.md——其中预先记录了范围限制（评审者试图引入的风格惯例、两条必须指出替代方案的规则、数字型巨型结构体的界限），以免评审者评判规则范围之外的内容。

相关技能

• staff-level-elixir — 提供建议的配套技能：针对绿地项目提供“选择什么工具、遵循什么约定”的指导，以及本门禁有意排除的判断事项。编写或修复代码时使用它；裁定代码时使用本门禁。
• elixir-meta-programming — 当确实需要宏/DSL 时，介绍如何正确构建（与本门禁的 meta- 规则互为补充）。
• adversarial-swift / adversarial-rust / adversarial-zod / adversarial-ts-patterns / adversarial-tanstack — 面向其他技术栈的配套门禁；协议相同，规则不同。

参考文件

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