adversarial-phoenix-liveview

对抗式 Phoenix LiveView 评审关卡

面向 Phoenix LiveView 的实时 UI 架构评审关卡——通过/不通过：由单个盲审子 Agent 对照本关卡规则，以对抗性立场评判工作；只有每条规则都为 PASS 或 N/A，工作才算通过。本技能只给出判定，绝不修复工作。

这些规则针对一种故障模式：把 LiveView 写成套在 JS 框架上的页面控制器，而不是它本来的样子——一个通过有损套接字渲染变更追踪差异的有状态进程。本可通过补丁保留状态，却因重新挂载而丢失；本应只有一个写入方发送的广播，却从别处发出；外部调用导致整个视图冻结；模板构造悄然关闭变更追踪；集合不断累积每个套接字的内存，且没有上限；事件仅因按钮被隐藏就被视为可信；交互设计时假设 localhost 延迟为零。这些问题都能顺利编译，演示效果也完美，却会在生产环境中表现为内存膨胀、UI 陈旧、视图冻结和 IDOR 报告。每条规则都附有一段违规证据，让评审者仅凭产物证据即可判定 PASS/FAIL/N/A。同类关卡：adversarial-beam 评判消息交付语义，adversarial-elixir 评判范式契合度——对重要的 Phoenix 工作，运行这三项以获得全面覆盖。

适用场景

• 一项 Phoenix LiveView 功能——live view、live component、HEEx 模板、由 PubSub 驱动的 UI 更新、presence、无限滚动——即将合并，需要对其实时 UI 架构进行客观的 PASS/FAIL 评判。
• Agent（Claude、Codex）编写了 LiveView 代码，你希望独立检查它是否伪造了实时正确性——控制器习惯、未限定范围的主题、无上限的 assigns、未授权的事件处理器、零延迟假设。
• LiveView 应用正在为实际流量做准备，需要将 localhost 时代的假设（无延迟、单节点、小数据、客户端可信）作为判定结果揭示出来。
• 一起生产事故（内存膨胀、视图冻结、IDOR、UI 陈旧）已在某处修复，你希望在受影响区域内查找同类问题。

不要将此关卡用于非 Phoenix 代码库（评审提示词的前置条件会中止并显示“GATE NOT APPLICABLE”），也不要在用户想要解释和重构而非判定时使用。版本说明：每个 FAIL 触发条件都基于 LiveView 1.0+ API（streams、async、JS commands）；缺少 :key 的情况仅适用于 LiveView 1.1+（colocated hooks 绝不会触发 FAIL）；current_scope 的写法来自 Phoenix 1.8 脚手架——对于 1.8 之前的目标版本，将根据底层模式（按 actor 过滤访问）进行评判。评审提示词包含适用性维度。

审查流程

请严格按以下步骤执行——此门禁的价值在于确保每次审查都以相同方式进行。

1. 确定目标。 明确指出审查对象（差异、一组文件或 PR），并记录引用和路径，以确保审查针对的是明确且固定的目标。记录技术栈信息（来自 mix.exs、路由器和 config/）——phoenix/phoenix_live_view 版本、scope 模块是否存在、PubSub/Presence 的使用情况、live_session 代码块及其 on_mount 钩子、全局 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. 派发一名盲审审查者。 启动一个 Task 子代理，其完整输入为编写后的提示词——不得附带对话上下文或评论。
5. 失败即关闭。 审查者的结构化输出就是最终判定——不进行合并步骤。只有当每条规则均为 PASS 或 N/A 时，总体判定才是 PASS；任意一条 FAIL 都会导致门禁失败。绝不取平均、权衡严重程度或豁免规则——即使是“轻微”的 FAIL，也仍是 FAIL。如果审查者返回“GATE NOT APPLICABLE”（目标并非 Phoenix LiveView），则停止并报告此结果，不要给出判定。
6. 生成判定报告。 填写 assets/templates/verdict.md。若判定为 FAIL，将审查者的“通过所需的修改建议”汇总到修复列表中，每项注明位置，并按类别重要性排序。最终结果为 FAIL 的每条规则都必须出现在修复列表中，且附上足以直接执行的具体修改——如果审查者的建议只是重述违规内容，请依据规则中的 Correct 示例推导出修复方案后再填写。

如果同一规则在针对未变更目标的多次重新审查中反复改变判定，或者人工审阅证据后推翻了判定，这说明规则存在可判定性问题——请将其记录在 gotchas.md 并细化规则；不得推翻门禁判定。

判定格式

审查者针对每条规则返回：PASS | FAIL | N/A、证据（file:line 或引文——PASS 和 FAIL 均必须提供证据）；对于每条 FAIL，还须给出应用后可使该规则通过的修复方案——注明具体修改及其位置，不能只是重述违规内容。最终报告遵循 assets/templates/verdict.md。

规则类别

#	类别	前缀	需要防范的错误假设
1	状态所有权与生命周期	state-	“LiveView 就是一个页面”——明明打补丁就够了却重新挂载、在错误的回调中加载数据、在断开连接的 mount 中执行有状态工作、重连时表单输入丢失
2	实时数据流	flow-	“实时意味着随时随地广播任何内容”——在 LiveView 中广播，而不是紧邻 context 写入处广播、全局且未限定范围的主题、手动实现 presence
3	异步与进程响应能力	async-	“LiveView 进程有空”——阻塞式外部调用、将 socket 复制到闭包中、与 UI 生命周期绑定的发后即忘工作、异步结果没有失败分支
4	渲染与线路效率	render-	“HEEx 是一种模板语言”——在模板中加载数据、使用模板变量、传递整个 assigns、对 assigns 调用 Map.put、使用未加键的 Enum.map 渲染
5	集合与流	stream-	“Assigns 不占资源”——在 socket 内存中不断增长的集合、被破坏的 stream DOM 契约、无上限的无限滚动
6	组件与 Context 边界	bound-	“LiveView 就是整个应用”——在 web 模块中使用 Repo/Ecto、把 LiveComponents 当作代码文件夹、在组件与其自身父级之间使用 PubSub、缺少 @myself 目标
7	客户端信任与事件安全	trust-	“UI 会限制用户”——未授权的 handle_event、仅凭裸 ID 查询（IDOR）、混合身份验证的 live_session、撤销访问权限后仍存活的 socket
8	交互反馈与客户端命令	ui-	“本地主机延迟就是产品体验”——纯展示也要往返服务器、没有正在处理中的反馈、未做防抖的输入、损坏的 hook/ignore 契约、缺少焦点管理的覆盖层

注意事项

在派发审查者之前，请阅读 gotchas.md——其中预先记录了范围边界（相邻规则的边界、每条规则在无法判定时都应判定为不通过、ui-* 关注机制是否存在而非表现形式、关注形态而非品牌、current_scope 的拼写说明、Repo CRUD 豁免，以及强调线路成本而非功能故障的表述），以免审查者对规则范围之外的内容作出评判。

相关技能

• adversarial-beam — 运行时语义方面的相邻规则：投递保证、背压、监督、共享状态竞态。本规则检查到 socket 与 PubSub 相接为止；该规则负责消息之后的处理。
• adversarial-elixir — 范式契合方面的相邻规则：移植到 BEAM 上的面向对象／企业开发习惯。使用相同协议，规则互为补充。
• staff-level-elixir — 建议类相邻技能：为全新项目提供“该用什么工具、遵循什么约定”的指导，以及规则有意排除的判断事项。编写或修复代码时使用它；评判代码时使用这些规则。

参考文件

文件	描述
references/reviewer-prompt.md	每位盲审查者使用的独立提示词模板
assets/templates/verdict.md	评判报告模板
references/_sections.md	类别定义与顺序
metadata.json	版本与来源引用