文件
hyb-oa/.trellis/tasks/archive/2026-08/08-07-interaction-pattern-browser-regression/openclaw-test-prompt.md
T

12 KiB
原始文件 Blame 文件历史

OpenClaw 测试提词

下面整段可直接交给 OpenClaw。执行者只做只读浏览器验收和证据记录,不修改产品代码。


你正在验证 hyb-oa Trellis task 08-07-interaction-pattern-browser-regression。目标是补跑已归档任务 08-05-interaction-pattern-unification 因 Chromium 环境阻塞而暂停的浏览器回归。

权限和安全边界

  1. 只访问用户提供的 loopback HTTP 地址 <LOOPBACK_BASE_URL>;若地址不是 127.0.0.1/localhost、带真实凭据或指向公网,停止并标 PAUSED。
  2. 只使用仓库既有合成 E2E 夹具/API mock。不要索取、打印或保存密码、token、企业微信参数、真实票据、合同正文、银行资料、完整账号或原始 payload。
  3. 不编辑 client/src、server/、API、URL、数据库、权限、状态机、依赖或生产配置。发现产品缺陷只记录,不顺手修复。
  4. 截图只保存到 output/playwright/08-07-interaction-pattern-browser-regression/;不要覆盖任何历史任务截图目录。
  5. 企业微信 UA 模拟只写“UA 模拟通过”,不得写成“企业微信真机通过”。没有代表性真机时真机项保持 PAUSED。
  6. Chromium 缺失、沙箱 Operation not permitted、本地服务不可达或无法加载 mock 时,记录准确错误并标 PAUSED;不得用源码 grep、静态 DOM 文本或测试清单冒充浏览器 PASS。

开始前记录

先输出:

  • 当前提交短 SHA;
  • Node/npm/Playwright/Chromium 版本;
  • <LOOPBACK_BASE_URL>(只保留 origin,不带查询参数或凭据);
  • 是否 headless;
  • 浏览器可执行文件与启动参数(如可见);
  • 开始前 git status --short;
  • 证据目录是否为空或仅包含本 task 文件。

若你可以运行终端,先用单 worker 执行以下聚焦用例;若只能控制浏览器,则按后面的逐场景步骤完成同等断言:

cd client
E2E_MODE=local E2E_BASE_URL=<LOOPBACK_BASE_URL> npx playwright test tests/e2e/login-portal-ux.spec.ts \
  --grep 'Portal 员工视角优先显示今日动作顺序|Portal 加载失败持久显示自然中文并可重新加载|Portal 新员工只显示轻量欢迎入口' \
  --workers=1 --reporter=list
E2E_MODE=local E2E_BASE_URL=<LOOPBACK_BASE_URL> npx playwright test tests/e2e/workflow-action-confirm-ui.spec.ts \
  --grep 'PC 审批详情通过、驳回、退回都先解释动作后果' \
  --workers=1 --reporter=list
E2E_MODE=local E2E_BASE_URL=<LOOPBACK_BASE_URL> npx playwright test tests/e2e/r6-mobile-responsive-system-hotfix.spec.ts \
  --grep '关键移动页面跨视口自适应且首页宫格不挤压' \
  --workers=1 --reporter=list
E2E_MODE=local E2E_BASE_URL=<LOOPBACK_BASE_URL> npx playwright test tests/e2e/r111-invoice-reimbursement-guard.spec.ts \
  --grep '企业微信手机端保持移动布局,发票和附件能力与 PC 一致' \
  --workers=1 --reporter=list
E2E_MODE=local E2E_BASE_URL=<LOOPBACK_BASE_URL> npx playwright test tests/e2e/pc-detail-mobile-visual-wave3.spec.ts \
  --grep 'Wave3 移动关键页视觉截图|Wave3 PC 详情和通知中心视觉截图' \
  --workers=1 --reporter=list

如果既有 spec 的自定义截图 helper 会写入历史目录,不要直接运行该截图路径。使用临时运行副本或浏览器手工流程,把截图改存当前 task 目录;临时文件不得提交。

场景 1:状态徽章渲染(R1/R6)

目标:真实 Chromium 渲染实际 StatusBadge 组件,而不是只读源码。

  • 在 Vite loopback 页面使用一次性、未提交的浏览器测试 harness 渲染:
    • status="future_status",期望文字为“未知状态”,不得显示 future_status;
    • status="probation" 且业务 label 为“试用期”,期望显示“试用期”,不得显示 probation;
    • Todo 状态列表依次显示“待处理 / 进行中 / 已完成 / 已取消”,不得显示 todo / doing / done / cancelled。
  • 截图:01-status-badge-fallback-1440x960.png。
  • 如果无法在不改业务代码的条件下渲染实际组件,此场景标 PAUSED,并明确“源码合同已有证据,但浏览器渲染未补齐”。

场景 2:Portal 顺序、权限和恢复(R4/R9/R11)

视口 1440x960,分别使用合成员工和合成经理 mock。

员工:

  1. 登录后进入 /portal,主业务区标题顺序必须是“今日待处理”在“常用入口”前。
  2. Tab 焦点从“我的事项”移动到“本周周报”入口,两个控件均有可见焦点。
  3. 打开首次欢迎弹窗;无审批权限时只有真实可用入口,不出现“待我审批”,也不出现无关“个人设置/通知中心”快捷入口。
  4. 模拟 Portal 区域先失败后成功:错误区持续显示自然中文;不得出现 SYS_001、/api/portal/home 或原始 payload;重试按钮可聚焦,点击后错误消失且“今日待处理”恢复。

经理:

  1. “待我审批”入口和团队卡点可见;普通员工没有的管理内容不要泄露给员工角色。

截图:

  • 02-portal-employee-1440x960.png
  • 03-portal-welcome-employee-1440x960.png
  • 04-portal-error-retry-1440x960.png
  • 05-portal-manager-1440x960.png

场景 3:PC 审批详情动作与焦点(R11)

视口先 1280x800,必要时补 1100x768。

  1. 打开合成待审批详情;页面同时解释“退回”和“驳回”的不同后果。
  2. 点击“通过”,确认框必须说明进入下一审批节点;取消后不得发生接口动作。
  3. 打开“驳回”,填写合成原因;确认框必须说明流程终止;取消后不得发生接口动作。
  4. 打开“更多 → 转审”:未选审批人时显示禁用原因;理由不足 10 字时显示“至少 10 个字”;满足后按钮启用。
  5. Tab 顺序必须从目标审批人到转审理由,再到提交按钮;焦点环清晰可见。
  6. 1100x768 下固定侧栏应隐藏、顶部菜单可见;1280x800 下固定侧栏可见,详情双栏主列 >=560px、操作列 >=280px,文档无横向溢出。

截图:

  • 06-workflow-transfer-disabled-1280x800.png
  • 07-workflow-transfer-ready-1280x800.png
  • 08-workflow-breakpoint-1100x768.png

场景 4:移动固定动作条七视口(R10/R11)

依次覆盖:

  • 320x568 iOS 企业微信 UA
  • 360x740 Android 企业微信 UA
  • 375x667 普通移动浏览器 UA
  • 390x844 iOS 企业微信 UA
  • 393x873 Android 企业微信 UA
  • 414x896 iOS 企业微信 UA
  • 430x932 普通移动浏览器 UA

每个视口检查:

  1. /mobile、/mobile/approvals、/mobile/reimbursements 和移动报销详情无可见桌面表格。
  2. document.documentElement.scrollWidth <= viewportWidth + 2。
  3. 底部导航项目可点击尺寸至少 44px,命中测试落在自身或子元素;选中态不是黑色空心样式。
  4. 进入移动报销详情后底部 Tab 隐藏,顶部返回存在。
  5. mobile-reimbursement-sticky-actions 始终可见、按钮同一横行、底部间隙 <=2px、主按钮高度 >=44px。
  6. 滚动到页面最后一段内容;最后内容必须能完整滚到动作条上方,不能被固定动作条遮挡。
  7. pending/disabled 时文字或邻近说明解释原因;不能只靠灰色。

每个视口至少保存一张移动报销详情截图,命名 09-mobile-reimbursement-<width>x<height>-<ua>.png;另保存 390x844 的移动审批动作截图。

场景 5:报销材料与返回链路(R10/R11)

PC 1440x960:

  1. 报销详情材料区可见,普通用户文案不展示内部 code/OCR 字段名。
  2. “查看发票原件”和“查看补充附件”可用键盘依次聚焦,焦点可见。
  3. 从审批详情进入报销详情后返回按钮显示“返回审批详情”,点击回到原审批详情。

移动 390x844 企业微信 UA 模拟:

  1. 材料区与固定动作条同时可用;无横溢、无底部 Tab、按钮高度达标。
  2. 打开材料/发票对话框时,不得默认聚焦搜索框导致首屏键盘弹出。

截图:

  • 16-reimbursement-materials-pc-1440x960.png
  • 17-reimbursement-materials-mobile-390x844-wecom.png

场景 6:差旅不自动选中(R14)

  1. 使用含至少两条合成差旅记录的 mock,直接打开 /travel-requests,URL 不带 id。
  2. 等待列表加载稳定;URL 仍必须是 /travel-requests,不得自动变成 ?id=<first>,详情区不得假装用户已选择记录。
  3. 用户明确点击一条记录后,既有 ?id= 行为可以继续出现;本场景不验证或扩展差旅业务能力。

截图:18-travel-list-no-auto-select-1440x960.png。

统一采集指标

每个场景都记录:

  • 场景编号和名称;
  • 状态:PASS / FAIL / PAUSED;
  • 合成角色;
  • UA 类型;
  • 视口;
  • 起始 URL 与最终 URL;
  • H1 或关键 data-testid;
  • scrollWidth、clientWidth、横向溢出差值;
  • sticky top/bottom/height、最后内容 bottom、按钮最小高度(适用时);
  • 实际焦点控件顺序;
  • console error 和 pageerror 数;
  • 截图相对路径;
  • finding(若有)及最小复现。

Codex 本地执行结果(2026-08-07)

以下结果只记录本地 Chromium 与 UA 模拟,不替代 OpenClaw 真机或公网验收:

场景 状态 角色/UA 与视口 关键结果 证据/备注
1. 状态徽章 PASS 本地 Chromium,1440x960 实际动态导入 StatusBadge;未知状态显示“未知状态”,probation 显示“试用期”,Todo 四态显示自然中文;console/pageerror=0 01-status-badge-fallback-1440x960.png
2. Portal PASS 合成员工/经理,PC 1440x960 3 个聚焦用例通过(3/3),顺序、权限过滤、中文错误与重试、焦点均有证据 任务目录内 Portal 截图
3. PC 审批 PASS 合成审批人,1280x800/1100x768 后果说明、取消不调用接口、转审 10 字门槛、焦点顺序通过(1/1) 任务目录内审批截图
4. R6 七视口 PASS(等价临时 runner) iOS/Android 企业微信 UA + 普通移动 UA;320/360/375/390/393/414/430 7/7 通过;无横溢、无桌面表格、底部导航、sticky action、安全区和按钮尺寸通过 w320–w430 系列;原始 fixture 角色缺少 leave.manage,导致 effectiveView 回落 records,历史断言失败另记为测试夹具问题
5. R111 材料区 PASS(等价临时 runner) iOS 企业微信 UA,移动 390x844 1/1 通过;材料区、sticky action、safe-area、按钮尺寸和无横溢通过 原始 spec 的同名文本 strict locator 命中两项;临时副本仅收窄 .first(),未改仓库测试
6. Wave3 详情 PASS PC/移动合成账号;1440、1280、1100 断点及移动代表视口 PC/移动截图用例 2/2 通过,详情返回链路和双栏布局通过 01-pc-reimbursement-detail.png 等
7. R14 差旅 PASS 合成管理员,PC 1440x960 两条合成记录加载后 URL 只有 tab=requests,没有 id;右侧保持未选择/新建态 18-travel-list-no-auto-select-1440x960.png

结果边界

  • 未修改 client/src、server/、仓库 E2E spec 或依赖;R6/R111 的临时副本均位于 /tmp,只用于收窄历史测试断言和重定向截图。
  • 原始 R6 失败不是产品能力下线或宿主边界限制:fixture 角色不能解析出 leave.manage,导致 effectiveView 回落到 records;mobile-leave-form 仍是有效覆盖。原始 R111 断言违反 Playwright strict locator。两项均保留当时失败分类,不伪装成原始 spec 无条件通过。
  • 代表性 iPhone/Android 企业微信 WebView、真机键盘与 safe-area,以及公网/部署验证均为 PAUSED。

最终输出格式

先给总表:

场景 状态 角色/UA 视口 关键结果 证据

然后分别列:

  1. 自动化 Chromium:passed/failed/skipped 数和命令退出码。
  2. 企业微信 UA 模拟:只说明模拟结果。
  3. 代表性真机:若未执行,明确 PAUSED。
  4. 公网/部署:本任务未执行,不得写成可线上测试。
  5. 发现项:按 P0/P1/P2/P3,包含页面、视口、步骤、预期、实际和截图。
  6. 工作区检查:结束后 git status --short;确认无业务代码改动、无历史截图目录污染。

只有场景 1–6 的适用浏览器断言全部通过且目标用例没有 failed/unexpected 时,才能写“本地 Chromium 聚焦回归通过”。即使如此,最终一句仍必须是:

本地 Chromium 与企业微信 UA 模拟已完成;尚未部署,也未完成代表性企业微信真机验证,不能据此告知用户线上或真机可测。