adversarial-reactor

Adversarial Reactor Gate

A saga/dataflow-orchestration review gate for Elixir code built on Reactor — pass/fail: a single blind reviewer subagent judges the work against this gate's rules with an adversarial mandate, and the work passes only when every rule is PASS or N/A. This skill renders verdicts; it never fixes the work.

The rules target one failure mode: code that assumes guarantees Reactor never made — that rollback is automatic, that cleanup in compensate fires on downstream failure, that :ok absorbs an error, that steps run in the order they were written, that :retry is bounded by default, that {:halt, reason} aborts, that map steps parallelize, that process-local state follows a step into its task process. These bugs compile cleanly, pass happy-path tests, and surface as orphaned payments, infinite retry loops, and races. Each rule carries an Evidence of violation paragraph so a reviewer can decide PASS/FAIL/N/A from artifact evidence alone. The sibling gates judge different layers: adversarial-elixir paradigm fit, adversarial-beam runtime semantics — run them alongside for full coverage of OTP-shaped work.

When to Apply

• An Elixir feature that defines or modifies Reactor workflows (use Reactor modules, Reactor.Step implementations, Reactor.run call sites) is about to merge and needs an objective PASS/FAIL on its orchestration semantics.
• An agent (Claude, Codex) authored a Reactor saga and you want an independent check that it did not park cleanup in the wrong callback, leave side effects irreversible, or assume lexical step order.
• A workflow is being promoted from happy-path prototype to production (payments, provisioning, imports) and its failure/rollback/retry paths need to be surfaced as verdicts.
• An incident postmortem fixed one orphaned-side-effect or retry-storm bug and you want the same class hunted across the reactors in the affected area.

Do not apply to targets with no Reactor usage (the reviewer prompt's precondition aborts with "GATE NOT APPLICABLE"), or when the user wants explanations and refactors rather than a verdict. General OTP/BEAM concerns (supervision, PubSub, ETS) belong to adversarial-beam; Elixir paradigm fit belongs to adversarial-elixir.