adversarial-reactor

对抗式 Reactor Gate

这是一个用于审查基于 Reactor 构建的 Elixir 代码的 saga／数据流编排门禁：结果为通过或失败——由一个盲审子 Agent 按本门禁规则进行对抗式审查，只有所有规则均为 PASS 或 N/A 时，工作才算通过。此技能只给出判定，绝不修复工作。

这些规则针对一种故障模式：代码假设了 Reactor 从未保证的行为——认为回滚会自动进行，认为下游失败时 compensate 中的清理会触发，认为 :ok 会吸收错误，认为步骤按编写顺序运行，认为 :retry 默认有次数上限，认为 {:halt, reason} 会中止执行，认为 map 步骤会并行执行，认为进程本地状态会随步骤进入其任务进程。这类 Bug 可以顺利编译、通过正常路径测试，却会导致支付款项无人处理、无限重试循环和竞态。每条规则都附有一段违规证据，审查者可仅凭产物证据判定 PASS／FAIL／N/A。相关门禁审查的是不同层面：adversarial-elixir 关注范式适配，adversarial-beam 关注运行时语义——对 OTP 风格的工作，可同时运行这些门禁以获得完整覆盖。

适用时机

• 即将合并的 Elixir 功能定义或修改了 Reactor 工作流（use Reactor 模块、Reactor.Step 实现、Reactor.run 调用点），需要对其编排语义做出客观的 PASS／FAIL 判定。
• Agent（Claude、Codex）编写了 Reactor saga，你希望进行独立检查，确认它没有把清理逻辑放在错误的回调中、没有让副作用无法撤销，也没有假设步骤按代码顺序执行。
• 工作流正从正常路径原型升级为生产版本（支付、资源配置、导入），需要明确判定其失败、回滚和重试路径。
• 事故复盘修复了一个副作用未处理或重试风暴 Bug，你希望在受影响区域的其他 Reactor 中排查同类问题。

目标中没有使用 Reactor 时，不要应用此门禁（审查提示词的前置条件会中止，并显示“GATE NOT APPLICABLE”）；如果用户想要的是解释和重构，而非判定，也不要应用。常规 OTP／BEAM 问题（监督、PubSub、ETS）应由 adversarial-beam 处理；Elixir 范式适配应由 adversarial-elixir 处理。

Review Protocol

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

1. 确定目标。 明确要审查的内容（差异、一组文件或 PR），并记录引用和路径，确保审查针对明确且固定的目标。记录技术栈信息（来自 mix.exs、mix.lock、test_helper.exs）——Reactor 版本、是否存在 Ecto/sandbox、模拟库、遥测使用方。在目标描述中包含仓库根目录——有几条规则要求在差异之外搜索已挂载步骤模块的回调、Reactor.run 调用位置和中间件模块（审查者提示词中列出了这些内容）。
2. 加载规则。 阅读 references/_sections.md 和 references/ 中的每个规则文件（所有 saga-*.md、retry-*.md、dep-*.md、step-*.md、comp-*.md、conc-*.md、obs-*.md 文件）。
3. 编写审查者提示词。 使用规则、目标和技术栈信息填写 references/reviewer-prompt.md。组合后的提示词必须完全自包含——审查者看不到任何对话历史，因此不得引用提示词之外的上下文。
4. 派发一名盲审审查者。 启动一个 Task 子 Agent，其全部输入必须是组合后的提示词——不得附带对话上下文或评论。
5. 以失败关闭方式呈现结果。 审查者的结构化输出就是判定结果——不进行合并。只有当每条规则均为 PASS 或 N/A 时，总体判定才为 PASS；任何一条 FAIL 都会导致门禁失败。绝不取平均、权衡严重程度或豁免规则——“轻微”的 FAIL 仍是 FAIL。如果审查者返回“GATE NOT APPLICABLE”（目标中未使用 Reactor），则停止并报告该结果，而不是给出判定。
6. 呈现判定结果。 填写 assets/templates/verdict.md。若结果为 FAIL，则将审查者给出的“通过所需的缺失项”建议汇总到修复清单中，并为每项注明位置，按类别重要性排序。每条结果为 FAIL 的规则都必须出现在修复清单中，并且给出的修改必须具体到可以直接照做——如果审查者的建议只是重述违规内容，则在呈现前依据规则中的正确示例推导出修复方法。

如果同一规则在针对未更改目标的多次重新审查中判定结果发生变化，或人工阅读证据后推翻判定结果，则说明该规则存在可判定性缺陷——请在 gotchas.md 中记录并细化该规则；不得推翻门禁结果。

Verdict Format

审查者必须针对每条规则返回：PASS | FAIL | N/A、证据（file:line 或引文——PASS 和 FAIL 都必须提供），并针对每条 FAIL，提供应用后可使该规则转为 PASS 的修复方法——注明具体修改及其位置，切勿仅重述违规内容。最终报告应遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	需要防范的错误假设
1	Saga 补偿与撤销	saga-	“回滚会自动执行”——存在未使用 undo/4 撤销的副作用、在 compensate 中清理（它会在步骤自身失败时触发，并接收错误）、误以为 :ok 会吸收错误（只有 {:continue, value} 会），以及重新执行时会出问题的撤销逻辑
2	重试规范	retry-	“:retry 是安全的”——在 DSL 默认值 max_retries :infinity 下进行全捕获重试、重试确定性的业务失败，以及没有 backoff/4 的即时重试热循环
3	依赖与数据流	dep-	“步骤会按我编写的顺序运行”——存在没有 argument/wait_for 边的有序副作用、通过 context 偷渡步骤间数据（没有依赖边，会产生竞态）、虚假的未使用参数，以及没有 return 的多步骤 Reactor
4	步骤契约	step-	回调形状错误——将文档未列出的 run/3 返回值视为失败、将 {:halt, reason} 当作错误信号（它会暂停并跳过回滚）、where 中的布尔守卫或 :cont、内联在 run 中的跳过条件，以及无法模拟的内联函数中的副作用
5	组合与迭代	comp-	手动实现 DSL 已能规划的操作——在步骤内调用 Reactor.run（子流程会脱离父流程回滚）、对 map 步骤使用 Enum 循环、用 case 处理副作用分支而不使用 switch、使用没有 max_iterations 的 recurse，以及将物化数据集用作 map 的数据源
6	并发与进程上下文	conc-	“异步会自动正常工作”——map 的 allow_async? 默认值为 false（串行运行）、未设置 async?: false 的 sandbox 测试、跨越任务边界后丢失进程本地状态，以及分散设置 async? false 而不是在运行级别设置 max_concurrency
7	可观测性与中间件	obs-	在步骤中手动实现生命周期日志，而 Reactor.Middleware.Telemetry 已能将其全部发出；中间件回调返回裸值；在执行器的关键路径上于 event/3 中执行 I/O

易错点

在派发审查者之前，请阅读 gotchas.md——其中预先记录了范围限制（形状而非品牌、哪些算作副作用，以及差异与仓库搜索的义务），避免审查者评判规则范围之外的内容。

相关技能

• adversarial-beam — 运行时语义方面的同类审查：监督、背压、事件传递、共享状态、分布。Reactor 工作流运行在 OTP 应用中；处理重要工作时请同时运行两者。
• adversarial-elixir — 范式适配方面的同类审查：移植到 BEAM 上的面向对象／企业习惯。使用相同协议，规则互为补充。
• staff-level-elixir — 提供建议的同类技能：用于全新项目的“选什么工具、遵循什么约定”指导，以及审查门禁有意排除的判断事项。用它来编写或修复代码；用审查门禁来评定代码。

参考文件

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