查看当前宿主实际提供的浏览器工具及文档，遵循其初始化、标签页和读取/操作规则。已安装且适用的 computer-use、web-gui-tester 或 control-browser 可以辅助，不硬依赖某个技能名或不存在的 Skill 工具。
有浏览器能力就按实际工具执行。确实不可用时标明页面验证受阻，可继续已授权的其他检查；API、脚本、构建不能冒充浏览器测试。浏览器中涉及业务数据的创建、修改、删除仍遵循本次授权和受控数据范围。
按分析阶段的场景清单执行必要 P0 与变更验收，不用页面能打开、toast 成功替代结果判断。模块知识不存在或入口失效时先按调用链现场探索，记录可重复的步骤和数据前提；确认有效后更新模块，探索过程本身满足验收时不机械重跑整套流程。
证据与要证明的行为对应：
| 验证目标 | 需要观察的结果 |
|---|---|
| 页面入口/P0 | 目标页面、关键控件与主流程响应；不能扩展为数据或保存正确 |
| 文案、布局与视觉状态 | 实际查看页面或截图，核对目标文字、可见性、遮挡和布局；DOM 属性或截图文件存在不代表已完成视觉核验 |
| 配置、查询、计算 | 独立预期与实际数据/数量/字段；如生成 JSON、SQL 等，还需核对内容和参数绑定。记录基线已有差异与新增差异 |
| 请求与接口契约 | 本次操作实际发出的请求内容、响应及契约要求；HTTP 200 或成功提示不能证明请求字段正确 |
| 保存与持久化 | 保存后重新读取或关闭重开，核对内容、状态和受影响对象；只看提示或仍留在内存的表单不够 |
| 失败、取消、兼容 | 错误出现的时点、应阻止的动作、取消前后/旧数据前后是否改变 |
按验收目标选择足够的证据，不将截图、接口、数据库排成通用等级，也不要求所有场景都做三方核对。JSON、SQL、请求体或数据比较可记录预期、实际值及差异，规范化比较不得忽略有业务意义的差别；这些比较不替代视觉核验。
页面场景保留关键截图，并记录是否实际查看；当前能力无法查看时明确标注，视觉验收保留未核实，其他行为按已有证据判断。截图不能替代不可见的数据断言，日志也不能替代页面操作。沿项目现有 artifact 目录保存，run 使用可解析的路径/链接，避免把敏感数据复制进报告。
每条场景结论关联预期来源、观察结果和证据；区分直接观察、推断及尚未验证的原因。只有相应验收点获得足够证据才记通过，不能把局部证据扩展为整条链路正确。
历史补录只引用已有证据，区分原始文件、当时记录和本次复验。截图或原始输出缺失就写“未留存/未核实”，不能用后来截图假冒历史现场。
先保存异常现场，再暂按应用、环境、工具、测试脚本或未知分类，注明依据及待排除因素；分类可以更新，不代表根因已证实。单次超时或空事件日志不足以认定页面或浏览器运行时有缺陷。
使用诊断结果前，核对目标页面/上下文是否正确、操作分支是否真的执行、采集是否在操作前启动，以及过滤、切片、截断或刷新是否使证据丢失。记录器没有收到事件只支持该观察，不能据此推定键盘、鼠标等所有通道均失败。
重试要针对已发现的问题或明确的待验证假设，并保留首次失败及各次条件变化。写入是否到达服务端不明确时，先核对当前状态和已有请求证据，不能盲目重复创建、保存或删除。后来成功不抹去先前失败；不再影响最终验收时也应说明依据。
先保留触发条件、预期、实际结果和版本。会话已授权修复时使用可用的 dev-workflow 衔接开发，完成相关检查并重测原失败场景及受影响兼容场景后，按项目规则提交；记录修复前后版本。复验受阻时保留未验证状态，不把其他测试通过当作原失败已修复。未授权或超出范围时记录问题，继续不依赖它的验证，不自动扩大修改。其他场景的仍有效证据可以复用。
每次运行写入 runs/<时间>-<主题>.md，至少包含以下信息；短任务可以合并栏目：
# 验证记录：<主题>
- scope/depth: <改动范围、业务目标、P0/变更验收、排除项>
- 版本: <各仓库路径、base、target 完整 hash、相关 dirty 与实际运行版本>
- 环境操作: <复用/启动的服务、实际目标、数据范围及授权限制>
- 交互就绪: <操作与前后状态，或已覆盖的 P0 场景 ID>
| 验收维度 | 是否适用 | 场景 ID / 不适用原因 |
|----------|----------|-----------------------|
| <逐项填写：正常、失败、取消、排除对象、向后兼容、数据正确性> | <是/否> | <适用但未覆盖时仍保留 ID> |
| 场景 ID | 独立预期及来源 | 实际观察 | 证据与限制 | 状态 |
|---------|----------------|----------|------------|------|
| <ID> | <可核对结果及依据> | <实际操作和结果> | <链接；截图是否查看、数据比较差异等> | <通过/失败/未覆盖/受阻> |
- 失败与修复: <复现、修复版本、重测证据，或无>
- 诊断与重试: <初步分类和依据、推断/待验证原因、重试条件及前后结果，或无>
- 未覆盖/降级: <场景和原因；其他检查能证明与不能证明的内容>
- 沉淀: <新增经验、失效知识修正、公共流程复用中实际发生的更新及文件/场景链接；证据缺口或待核实事项；无变化可写“已检查，无需更新”>
- 基线: <推进或不推进、限定覆盖及理由>modules/*.md 按 TEMPLATE.md 维护稳定入口、调用链、场景和判断依据；发现知识失效先核对原因，不直接假定页面改版。更新经验证的部分并链接 run，不把整次日志堆入模块文件。last-verified 只代表标明的场景与版本范围。
每次运行收尾时检查以下三项，失败或受阻的运行也适用。只在 run 的“沉淀”中记录实际更新或待核实事项；三项均无变化时写一句“已检查，无需更新”，不另建反思报告。
| 检查 | 处理 |
|---|---|
| 新增经验 | 将已核实、能减少下次探索的方法更新到对应模块；启动和环境知识更新到 env.md。注明适用条件并链接本次证据，单次结果仍留在 run |
| 失效知识 | 核对旧步骤或结论与新证据的差异，合并或替换失效表述，保留历史 run 及修正依据；证据不足时标记待核实，不把新猜测覆盖成确定结论 |
| 公共复用 | 先查已有场景。确有跨模块复用价值时，将已验证的共同步骤和验收标准集中维护在对应 modules 文件，调用模块通过文件链接与稳定场景 ID 引用，只记录使用条件、参数及差异 |
公共流程沿用现有模块模板和目录，收尾检查本身不要求封装脚本。登录可作为公共前置，新增菜单等写入场景仅在本次确有需要且已获授权时执行；知识中的历史成功或授权不代表本次允许写入。未验证的原因和临时诊断留在 run，不能因复盘被提升为通用操作规则。完成知识更新也不增加本次测试覆盖。
最终报告简述范围、版本、各场景结果、关键证据、环境操作及剩余缺口，并链接 run。
- 只有本次范围内必要验收场景全部通过且运行版本明确，才能声明“本次范围验收完成”并推进对应完整基线。
- P0 通过仅记录 P0 覆盖；有失败、受阻、未覆盖或仅降级证据时，完整验收基线不推进。已通过的局部场景可以记为有范围的证据，供后续按 analysis.md 核对复用，不能跳过余下场景。
- 用户接受已知问题或调整范围时保留原结果与原因，不把失败改成通过，不把缩小范围的完成表述成整批验收通过。
- 测的是含相关 dirty 的工作区时如实记录该状态；即使后来提交，未核实内容一致前不能把结果直接转成纯提交基线。