Adversarial Phoenix LiveView Gate

A realtime-UI architecture review gate for Phoenix LiveView — 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: LiveView written as a page-controller bolted to a JS framework, instead of what it is — a stateful process rendering change-tracked diffs over a lossy socket. Remounts that destroy state a patch would keep, broadcasts emitted where only one writer fires them, external calls that freeze the whole view, template constructs that silently disable change tracking, collections that grow per-socket memory without bound, events trusted because the button was hidden, and interactions designed against localhost latency. These all compile cleanly and demo perfectly; they surface as memory bloat, stale UIs, frozen views, and IDOR reports in production. Each rule carries an Evidence of violation paragraph so a reviewer can decide PASS/FAIL/N/A from artifact evidence alone. Sibling gates: adversarial-beam judges message-delivery semantics, adversarial-elixir judges paradigm fit — run all three for full coverage of substantial Phoenix work.

When to Apply

• A Phoenix LiveView feature — live views, live components, HEEx templates, PubSub-driven UI updates, presence, infinite scroll — is about to merge and needs an objective PASS/FAIL on its realtime-UI architecture.
• An agent (Claude, Codex) authored LiveView code and you want an independent check that it did not fake realtime correctness — controller habits, unscoped topics, unbounded assigns, unauthorized event handlers, zero-latency assumptions.
• A LiveView app is being prepared for real traffic and the localhost-era assumptions (no latency, one node, small data, trusted clients) need to be surfaced as verdicts.
• A production incident (memory bloat, frozen view, IDOR, stale UI) was fixed at one site and you want the same class hunted across the affected area.

Do not apply to non-Phoenix codebases (the reviewer prompt's precondition aborts with "GATE NOT APPLICABLE"), or when the user wants explanations and refactors rather than a verdict. Version note: every FAIL trigger rests on LiveView 1.0+ APIs (streams, async, JS commands); the missing-:key leg is version-gated to LiveView 1.1+ (colocated hooks never trigger a FAIL), and current_scope spellings are Phoenix 1.8 scaffolding — pre-1.8 targets are judged on the underlying shape (actor-filtered access). The reviewer prompt carries the applicability axes.

Review Protocol

Follow these steps exactly — the gate's value is that every review runs the same way.