adversarial-beam

Adversarial BEAM Gate

Elixir システム向けの BEAM ランタイムアーキテクチャレビューゲートです。合否は、単一のブラインドレビュアーサブエージェントが敵対的な立場からこのゲートのルールに照らして作業を判定し、すべてのルールが PASS または N/A の場合にのみ合格となります。このスキルは判定を提示するものであり、作業を修正することはありません。

ルールが対象とするのは、ランタイムが保証していないことを前提にするコードという、ひとつの障害パターンです。再起動すればデータが復元される、メールボックスがバックプレッシャーを返す、ブロードキャストが届く、配信が厳密に一度だけかつ順番どおりに行われる、検索結果が次の挿入時点でも真である、ノード内の一意性がクラスター全体でも保たれる、壁時計が前にしか進まない、といった思い込みです。こうしたバグは問題なくコンパイルでき、単体テストにも合格し、本番環境でインシデントとして表面化します。各ルールには違反を示す証拠の段落があるため、レビュアーは成果物の証拠だけをもとに PASS／FAIL／N/A を判定できます。兄弟ゲートの adversarial-elixir はパラダイムの適合性（BEAM に持ち込まれた OO の慣習）を判定し、このゲートはランタイムのセマンティクスを判定します。全項目を網羅するには、両方を実行してください。

適用するタイミング

• プロセスを監督する、イベント／ジョブ／ストリームを消費する、PubSub 経由でブロードキャストする、または ETS／Registry 経由で状態を共有する Elixir の機能をマージする前に、ランタイムに関する前提について客観的な PASS／FAIL 判定が必要な場合。
• エージェント（Claude、Codex）が OTP 形式のコードを作成し、永続的なブロードキャスト、厳密に一度だけの配信、プロセス間メッセージの順序保証、または再起動後も維持されるインメモリ状態を前提としていないか、独立したチェックを行いたい場合。
• クラスタリングや高負荷への対応に備えてシステムを準備しており、組み込まれたシングルノード／低トラフィックの前提を判定として明らかにしたい場合。
• 配信／過負荷のバグの一例をインシデントの事後レビューで修正し、影響範囲全体から同じ種類の問題を探したい場合。

Elixir 以外のコードベースには適用しないでください（レビュアープロンプトの前提条件により「GATE NOT APPLICABLE」で中止します）。また、ユーザーが判定ではなく説明やリファクタリングを求めている場合も適用しないでください。アプリケーションがクラスター化されないことが明確な場合、dist-* カテゴリーは N/A になります。Oban／Broadway はルール内で代表的な解決策として挙げていますが、同等の特性を持つ仕組みであれば合格します。適用可能性の軸はレビュアープロンプトに記載されています。

レビュープロトコル

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

1. 対象を特定します。 レビュー対象（差分、ファイル一式、PR）を正確に特定し、レビューが曖昧さのない固定された対象に対して実行されるよう、ref／パスを記録します。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. ブラインドレビュアーを1人起動します。 作成したプロンプト全体だけを入力として、単一の Task サブエージェントを起動します。会話のコンテキストや、付随するコメントは与えません。
5. フェイルクローズで判定します。 レビュアーの構造化出力を判定結果とし、マージの手順はありません。すべてのルールが PASS または N/A の場合に限り、総合判定は PASS です。1つでも FAIL があれば、ゲートは FAIL です。重大度の平均化、比較衡量、ルールの免除は決して行いません。「軽微な」FAIL も FAIL です。レビュアーが「GATE NOT APPLICABLE」（対象が Elixir ではない場合）を返したら、判定を出さずに停止し、その旨を報告します。
6. 判定を出力します。 assets/templates/verdict.md に記入します。FAIL の場合、レビュアーの「PASS に不足しているもの」に関する提案を修正リストにまとめ、各項目に場所を記載し、カテゴリの重要度順に並べます。最終結果が FAIL のルールはすべて修正リストに含め、記載どおりに適用できる具体的な変更を示してください。レビュアーの提案が違反内容を言い換えただけの場合は、出力前にルールの Correct の例から修正方法を導き出します。

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

判定形式

レビュアーはルールごとに、PASS | FAIL | N/A、根拠（file:line または引用。PASS と FAIL の両方で必須）を返します。さらに、すべての FAIL について、適用すればルールが PASS に変わる修正（変更内容と場所を明記し、違反内容の言い換えは不可）を示します。最終レポートは 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-	ノードローカルのツールで強制される「クラスターごとに1つ」— フェンシングのない :global シングルトン、Registry／ETS の一意性がクラスター全体で保証されるという思い込み
6	ランタイムの仕組み	mech-	クロック、バイナリ、アトムの誤用 — 壁時計を使った経過時間の計算、長期間存続する状態で大きな親バイナリをピン留めするサブバイナリ、外部入力からのアトム生成

落とし穴

レビュー担当者に作業を割り当てる前に、gotchas.md を読んでください。対象範囲を守るための注意事項（fail-open ルールが1つあること、ブランドではなく形状を重視する原則、テレメトリーのアタッチとエミットの違い、壁時計をデータとして扱うこと、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	バージョンとソースの参照情報