adversarial-phoenix-liveview

Adversarial Phoenix LiveView Gate

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

このルールが対象とするのは、ひとつの失敗パターンです。LiveView を、JS フレームワークに後付けされたページコントローラーとして書いてしまい、本来の姿である「状態を持つプロセスが、損失のあるソケット越しに変更追跡された差分を描画するもの」として扱わないことです。パッチで維持できる状態を破壊する再マウント、書き込み側がひとつしかないのに発行されるブロードキャスト、ビュー全体を停止させる外部呼び出し、変更追跡をひそかに無効化するテンプレート構造、ソケットごとのメモリを際限なく増やすコレクション、ボタンが隠されているからと信頼されるイベント、ローカルホストのレイテンシーを前提に設計されたインタラクション。いずれも問題なくコンパイルでき、デモでも申し分ありませんが、本番ではメモリ肥大化、UI の陳腐化、ビューのフリーズ、IDOR の報告として顕在化します。各ルールには違反の証拠に関する段落があり、レビュアーはアーティファクトの証拠だけから PASS／FAIL／N/A を判断できます。関連するゲートとして、adversarial-beam はメッセージ配信のセマンティクスを、adversarial-elixir はパラダイムとの適合性を判定します。規模の大きい Phoenix の作業を網羅的に確認するには、3 つすべてを実行してください。

適用する場面

• Phoenix LiveView の機能（ライブビュー、ライブコンポーネント、HEEx テンプレート、PubSub 駆動の UI 更新、プレゼンス、無限スクロールなど）をマージする前に、リアルタイム UI アーキテクチャについて客観的な PASS／FAIL 判定が必要な場合。
• エージェント（Claude、Codex）が LiveView コードを作成し、コントローラーの慣習、スコープのないトピック、上限のない assigns、未認可のイベントハンドラー、レイテンシーをゼロとする前提など、リアルタイムの正しさを装っていないか独立して確認したい場合。
• LiveView アプリを実トラフィックに対応させる準備をしており、ローカルホスト時代の前提（レイテンシーがない、ノードがひとつ、データ量が少ない、クライアントが信頼できる）を判定として明らかにする必要がある場合。
• 本番インシデント（メモリ肥大化、ビューのフリーズ、IDOR、UI の陳腐化）を特定箇所で修正し、影響範囲全体で同種の問題を探したい場合。

Phoenix 以外のコードベースでは適用しないでください（レビュアープロンプトの前提条件により、「GATE NOT APPLICABLE」で中断されます）。また、ユーザーが判定ではなく説明やリファクタリングを求めている場合にも適用しないでください。バージョンに関する注記：すべての FAIL の判定条件は LiveView 1.0 以降の API（streams、async、JS コマンド）に基づきます。:key の欠落に関する条件は LiveView 1.1 以降に限定され（colocated hooks が FAIL の判定条件になることはありません）、current_scope の表記は Phoenix 1.8 のスキャフォールディングに基づいています。1.8 より前の対象では、基盤となる構造（アクターで絞り込まれたアクセス）を基準に判定します。適用可能性の判断軸はレビュアープロンプトに記載されています。

レビュープロトコル

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

1. 対象を特定します。 レビュー対象（差分、ファイル一式、PR）を正確に絞り込み、レビューを曖昧さのない固定された対象に対して実行できるよう、ref／パスを記録します。スタックに関する情報（mix.exs、ルーター、config/から）も記録します。具体的には、phoenix／phoenix_live_viewのバージョン、scopeモジュールの有無、PubSub／Presenceの使用状況、on_mountフックを含むlive_sessionブロック、グローバルCSSの場所です。対象の説明にはリポジトリのルートを含めます。いくつかのルールでは、コンテキスト呼び出し元、ルーターの認証フック、失効フロー、ローディングクラスのスタイル、コンポーネント定義を差分の範囲外まで検索して文脈を確認する必要があります（レビュアープロンプトに記載されています）。
2. ルールを読み込みます。 references/_sections.mdと、references/内のすべてのルールファイル（すべてのstate-*.md、flow-*.md、async-*.md、render-*.md、stream-*.md、bound-*.md、trust-*.md、ui-*.mdファイル）を読みます。
3. レビュアープロンプトを作成します。 ルール、対象、スタックに関する情報を使ってreferences/reviewer-prompt.mdを埋めます。作成するプロンプトは完全に自己完結していなければなりません。レビュアーには会話履歴が見えないため、プロンプト外の文脈を参照してはなりません。
4. ブラインドレビュアーを1人だけ起動します。 入力全体が作成したプロンプトのみとなるTaskサブエージェントを1つ起動します。会話の文脈や、それに添えるコメントは一切含めません。
5. フェイルクローズで判定します。 レビュアーの構造化された出力を判定とします。統合ステップはありません。すべてのルールがPASSまたはN/Aの場合に限り、全体の判定をPASSとします。1つでもFAILがあれば、ゲート全体がFAILです。平均化、重要度の比較、ルールの免除は決して行いません。「軽微な」FAILもFAILです。レビュアーが「GATE NOT APPLICABLE」（Phoenix LiveViewの対象ではない）を返した場合は、判定を出さず、代わりにその旨を報告して終了します。
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	状態の所有権とライフサイクル	state-	「LiveView はページである」— パッチで済む場面で再マウントする、誤ったコールバックで読み込む、切断中の mount でステートフルな処理を行う、再接続時に入力が失われるフォーム
2	リアルタイムのデータフロー	flow-	「リアルタイムとは、どこからでも何でもブロードキャストすること」— コンテキストの書き込み処理の隣ではなく LiveView 内でブロードキャストする、スコープが設定されていないグローバルトピック、独自実装のプレゼンス
3	非同期処理とプロセスの応答性	async-	「LiveView のプロセスは空いている」— 外部呼び出しでブロックする、クロージャーにソケットをコピーする、UI のライフタイムに結び付いた fire-and-forget 処理、失敗分岐のない非同期結果
4	レンダリングとワイヤー効率	render-	「HEEx はテンプレート言語である」— テンプレート内でデータを読み込む、テンプレート変数を使う、assigns 全体を渡す、assigns に対して Map.put を使う、キーなしの Enum.map でレンダリングする
5	コレクションとストリーム	stream-	「assigns は無料である」— ソケットのメモリ内でコレクションを増やす、ストリームの DOM 契約を破る、無制限の無限スクロール
6	コンポーネントとコンテキストの境界	bound-	「LiveView がアプリである」— Web モジュール内で Repo/Ecto を使う、LiveComponent をコードのフォルダーとして扱う、コンポーネントとその親との間で PubSub を使う、@myself ターゲットがない
7	クライアントの信頼性とイベントのセキュリティ	trust-	「UI がユーザーの操作を制限する」— 認可されていない handle_event、ID のみを使った検索（IDOR）、認証方式が混在する live_session、失効後も存続するソケット
8	操作のフィードバックとクライアントコマンド	ui-	「ローカルホストのレイテンシが製品の一部である」— 表示だけの処理で往復通信する、処理中のフィードバックがない、入力のデバウンスがない、hook/ignore の契約が壊れている、フォーカスのないオーバーレイ

注意点

レビュアーを割り当てる前に gotchas.md を読んでください。スコープのガード（隣接するゲート間の境界、すべてのルールで fail-closed とすること、ui-* における見た目ではなく仕組みの存在、ブランドではなく形状、current_scope の表記に関する注意、Repo の CRUD に対する例外、破損ではなくワイヤーコストとして捉えること）が事前に記載されているため、レビュアーがルールの範囲外を評価せずに済みます。

関連スキル

• adversarial-beam — ランタイムセマンティクスに関する隣接ゲートです。配信保証、バックプレッシャー、スーパービジョン、共有状態の競合を扱います。このゲートはソケットと PubSub の接点までを対象とし、メッセージに何が起きるかはもう一方が担当します。
• adversarial-elixir — パラダイムへの適合に関する隣接ゲートです。OO／エンタープライズの慣習を BEAM に持ち込むことを扱います。同じプロトコルに基づく、相互補完的なルールです。
• staff-level-elixir — アドバイザリーを担う隣接スキルです。新規開発における「どのツール、どの規約を選ぶか」という指針や、ゲートが意図的に対象外としている判断を扱います。コードの作成や修正にはこちらを使い、コードの判定にはゲートを使ってください。

参照ファイル

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