adversarial-reactor

アドバーサリアル Reactor ゲート

Reactor を基盤とする Elixir コードのサガ／データフローオーケストレーションをレビューするゲートです。合否は、単一のブラインドレビュアーサブエージェントが、敵対的な審査方針のもと、このゲートのルールに照らして作業を判定します。すべてのルールが PASS または N/A の場合にのみ、作業は合格となります。このスキルは判定を出すだけで、作業を修正することはありません。

ルールが対象とするのは、Reactor が保証していない動作を前提とするコードという、ひとつの障害パターンです。たとえば、ロールバックが自動で行われる、後続ステップの失敗時にも compensate 内のクリーンアップが実行される、:ok がエラーを吸収する、ステップは記述された順序で実行される、:retry にはデフォルトで上限がある、{:halt, reason} は処理を中断する、マップ形式のステップは並列実行される、プロセスローカル状態はステップとともにそのタスクプロセスへ引き継がれる、などの前提です。こうしたバグは問題なくコンパイルされ、正常系のテストにも合格しますが、支払いの孤立、無限リトライループ、競合を引き起こします。各ルールには 違反の証拠 の段落があり、レビュアーは成果物の証拠だけから PASS／FAIL／N/A を判断できます。関連するゲートは別のレイヤーを判定します。adversarial-elixir はパラダイムへの適合性を、adversarial-beam はランタイムのセマンティクスを判定します。OTP の特性を持つ作業を網羅的に確認するには、これらも併せて実行してください。

適用する場合

• Reactor ワークフロー（use Reactor モジュール、Reactor.Step の実装、Reactor.run の呼び出し箇所）を定義または変更する Elixir の機能をマージする前に、オーケストレーションのセマンティクスについて客観的な PASS／FAIL 判定が必要な場合。
• エージェント（Claude、Codex）が Reactor のサガを作成し、クリーンアップを誤ったコールバックに配置していないか、副作用を不可逆なままにしていないか、ソース上のステップ順序を前提としていないかを独立して確認したい場合。
• ワークフローを正常系だけのプロトタイプから本番環境に昇格させる際（支払い、プロビジョニング、インポートなど）、失敗／ロールバック／リトライ経路を判定結果として明らかにする必要がある場合。
• インシデントの事後分析で、副作用の孤立またはリトライストームのバグを修正し、影響範囲内の Reactor 全体で同じ種類の問題を探したい場合。

Reactor を使用していない対象には適用しないでください（レビュアープロンプトの前提条件により「GATE NOT APPLICABLE」で中断します）。また、ユーザーが判定ではなく説明やリファクタリングを求めている場合も適用しないでください。一般的な OTP／BEAM の懸念（スーパービジョン、PubSub、ETS）は adversarial-beam の対象です。Elixir のパラダイムへの適合性は adversarial-elixir の対象です。

レビュープロトコル

以下の手順を正確に実行してください。このゲートの価値は、すべてのレビューが同じ方法で行われることにあります。

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. ブラインドレビューアーを1人起動します。 作成したプロンプト全体だけを入力として、単一のTaskサブエージェントを起動します。会話のコンテキストや、それに添えるコメントは渡しません。
5. フェイルクローズで判定します。 レビューアーの構造化された出力を判定結果とし、統合ステップはありません。すべてのルールがPASSまたはN/Aの場合に限り、全体の判定はPASSです。FAILが1つでもあればゲートは失敗です。平均を取ったり、重大度を比較したり、ルール適用を免除したりしてはいけません。「軽微」なFAILもFAILです。レビューアーが「GATE NOT APPLICABLE」（対象にReactorの使用がない）を返した場合は、そこで終了し、判定結果ではなくその旨を報告します。
6. 判定結果を出力します。 assets/templates/verdict.mdに記入します。FAILの場合、レビューアーの「PASSに必要な修正」提案を集約し、重要度の高いカテゴリ順に、場所を添えて修正リストに記載します。結果がFAILのルールはすべて修正リストに含め、記載どおりに適用できる具体的な変更を示す必要があります。レビューアーの提案が違反の言い換えにすぎない場合は、出力前にルールの正しい例を参考にして修正内容を導き出してください。

対象を変更せずに再レビューした際、同じルールの判定が変わる場合、または人間が根拠を確認して判定を覆す場合は、そのルールに判定可能性のバグがあります。gotchas.mdに記録し、ルールを明確化してください。ゲートの判定を覆してはいけません。

判定形式

レビューアーはルールごとに、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 のない複数ステップのリアクター
4	ステップの契約	step-	誤ったコールバック形式――文書化されていない run/3 の戻り値を失敗として扱うこと、エラー通知としての {:halt, reason}（これは一時停止し、ロールバックをスキップします）、where からのブール値ガード／:cont、run にインライン化されたスキップ条件、副作用を含むモック不可能なインライン関数
5	合成と反復	comp-	DSL が計画する処理を手作業で実装すること――ステップ内の Reactor.run（子リアクターが親のロールバック対象外になります）、map ステップに対する Enum ループ、switch の代わりに case で副作用を分岐すること、max_iterations のない recurse、map のソースとしてデータセットを実体化すること
6	並行性とプロセスコンテキスト	conc-	「非同期処理はそのまま動く」――map の allow_async? はデフォルトで false（逐次実行）、async?: false を指定しないサンドボックステスト、タスク境界を越えて失われるプロセスローカル状態、実行単位の max_concurrency の代わりに async? false をあちこちに指定すること
7	可観測性とミドルウェア	obs-	Reactor.Middleware.Telemetry がすべてのライフサイクルログを出力するのに、ステップ内で手作業でログを記録すること、ミドルウェアコールバックが値をそのまま返すこと、エグゼキューターのクリティカルパス上で event/3 内の I/O を行うこと

注意点

レビュアーに依頼する前に gotchas.md をお読みください。スコープのガード（形状とブランドの区別、副作用とみなすもの、差分とリポジトリの検索要件）が事前に記載されており、レビュアーがルールの範囲外を判定しないようにするためのものです。

関連スキル

• adversarial-beam — ランタイムセマンティクスに関する兄弟ゲートです。スーパービジョン、バックプレッシャー、イベント配信、共有状態、分散処理を扱います。Reactor ワークフローは OTP アプリ内で動作します。大規模な作業では両方を実行してください。
• adversarial-elixir — パラダイム適合性に関する兄弟ゲートです。OO／エンタープライズの慣習を BEAM に持ち込むことを扱います。同じプロトコルを使い、相互補完するルールを提供します。
• staff-level-elixir — アドバイザリーを担う兄弟スキルです。新規開発における「どのツールを使うか、どの規約に従うか」の指針や、ゲートが意図的に対象外としている判断を提供します。コードの作成や修正にはこちらを、判定にはゲートを使用してください。

参照ファイル

ファイル	説明
references/reviewer-prompt.md	各ブラインドレビュアー向けの自己完結型プロンプトテンプレート
assets/templates/verdict.md	判定レポートのテンプレート
references/_sections.md	カテゴリの定義と順序
metadata.json	バージョンとソースの参照情報