用途：验证运行中的应用是否按宣称工作，方式是像用户一样驱动其真实界面（Web UI、CLI 或 TUI）。工作单元是“场景卡”——一份供智能体执行的简短 Markdown 测试，而非 Playwright/expect 脚本。卡片足够高层，小幅 UI 调整不会使其失效；又足够精确，两个智能体执行同一卡片会得到相同结论。单元测试只证明孤立接线，场景证明组装并渲染后的接线，二者捕获不同缺陷，即使单元测试通过也应写卡片。
适用时机：功能涉及用户可见界面（按钮、命令面板命令、状态指示、快捷键、渲染消息）且需要实机证明；用户要求“端到端测试”“证明 UI 可用”“跑一个场景”；改动的层（投影、能力门控、渲染器）效果只在组装后的 UI 中可见。不适用于无 UI 表面的逻辑（用单元测试），或生产门控使实机路径不可达时。
卡片格式：一个卡片一个 .md 文件，含 What this covers、Pre-state（含到达该状态的精确命令）、Steps（按意图编号，附具体命令或工具调用与真实 UI 标签，避免脆弱选择器）、Expected（每步应观察到什么及证伪条件）、Cleanup（幂等清理）、Sharp edges（坑、时序、非确定性）。
运行要点：从被测代码全新构建，最常见错误是测试陈旧二进制；隔离运行于封闭工作目录，对主机级单例（锁、固定端口、共享状态目录）用独立副本，只读输入可符号链接；驱动界面；对照权威记录（磁盘状态/日志/数据库）而非仅像素断言；捕获证据；清理自己创建的内容。
驱动 Web UI：用 Chrome/CDP 浏览器工具，认证导航后尽量通过 eval 调用应用自身 JS 入口而非合成点击；做乐观与稳定态断言（先不 await 取同步 DOM 快照，再 await 后快照）；eval 返回纯字符串；DOM 含糊时经应用单例查看内部状态。
驱动 CLI/TUI：每个场景用独立命名 tmux 会话，固定尺寸；命令示例：tmux new-session -d -s <name> -x 200 -y 50 "<cmd> 2>/tmp/<name>-stderr.log"；tmux send-keys -t <name> -l "literal text"；tmux send-keys -t <name> Enter；tmux capture-pane -t <name> -p。用户输入字符串始终加 -l；轮询 capture-pane 匹配状态字符串，按字形/词而非颜色；stderr 重定向到文件。
原则：始终证伪，每步说明失败长什么样；验证正确的表面层；存在但不可见不等于缺失，先滚动/展开；执行卡片本身也在测试卡片；警惕过度规格化陷阱（生产门控阻止的路径应在源码确认并记入卡片）；清理是测试的一部分，需幂等且限定范围。
完成：每条断言报告通过/失败及具体观察（渲染文本、磁盘值），失败时保留证据并修复或记录，不软化结论。