用途：在宣布改动完成前验证应用。它回答三个问题：改动触及哪些功能、如何在隔离实例上操作、什么能证明其可用。
主要能力：由两部分组成——远程控制（node scripts/verify.mjs，无参数时列出所有命令）和功能地图（docs/verify/，每个区域一个文件，含四个 H2：Sub-features、How to get to it、Driving it with verify、Gotchas）。CLI 驱动运行中的实例，不是测试运行器；应组合其命令，不要为验证编写驱动脚本。产品相关部分（种子状态、doctor 监视的服务器文件夹、额外 up 标志、浏览器语言与权限、报告措辞）位于 scripts/verify-app.mjs。
使用方式：每个检出获得独立实例，端口、数据文件夹、浏览器和日志由检出路径派生并存于 .verify/<port>/。全新 worktree 或克隆：node scripts/verify.mjs setup 安装依赖与 Chromium、构建页面、up、doctor。已设置好：up 然后 doctor。结束：down；cleanup 删除本实例数据与日志。doctor 必须打印 fresh，否则会指出问题（STALE BUNDLE、STALE SERVER、WRONG INSTANCE）。流程：features 列出受影响区域并只读这些文件；check 是门禁（lint、契约、单元测试、形式化模型、类型检查+构建、bundle 密钥、端到端旅程），必须通过；setup 或 up + doctor → fresh；report <area…> 写报告；seed <state> 设置状态；mark 后像人一样驱动功能（open、click、type、upload、press、wait-settle）；收集证据（api、network-summary、console、snapshot、screenshot、trace、perf）。前端定律：a11y、viewport 375 812 再 overflow 和 screenshot、然后 viewport 1440 900。默认使用假模型，仅代理行为用 up --real。
适用场景：Web、服务器、工具、代理、任务或聊天（提示、规则或输出）改动后的验证。
限制：假模型只检查管道而非措辞；形式化模型需要 Java，否则为 NOT RUN 且门禁显示 incomplete；非 fresh 实例的证据不算证据；仓库、测试、夹具、报告或提交截图中不得有真实用户数据；不得把生产当测试床；合并、绿色 CI 或部署不能得出“已验证”。无法到达的路径需说明并给出最接近的真实路径。