Playwright e2e

Playwright e2e 指仓库把真实浏览器里的关键用户流程当成正式质量门禁，而不是“顺手写了几条页面脚本”。它强调的是产品行为验证：路由、认证、交互链路、浏览器 API、嵌入式控制台或多 runtime 页面组合，必须在接近真实使用路径的浏览器环境里被证明可用（projects/blog-26.md、projects/proxy-broker.md、projects/octo-rill.md、projects/paste-preset.md）。

它和 Browser automation 不同。Browser automation 把浏览器当生产执行引擎，Playwright e2e 把浏览器当质量验证面；前者关心任务是否被执行，后者关心交付给用户的页面/流程是否真的工作。它也不等于 Storybook component QA，因为这里验证的是跨页面、跨状态、跨后端接缝的完整旅程。

当仓库存在 checked-in playwright.config.*、test:e2e 脚本、e2e workflow，或者项目快照明确把浏览器端关键流程列为 release/readiness gate 时使用。若改动会影响登录、内容编辑、控制台操作、复杂表单、路由切换、预览/嵌入式 UI、浏览器能力调用、前后端协同状态，或者本地/dev preview URL 与测试入口的关系，就应该命中本 Topic。

若只是组件快照、单纯 DOM 单元测试、或若干不会阻断交付的试验性 Playwright 脚本，不应上升为 Playwright e2e。这里的判断标准不是“项目装没装 Playwright”，而是“它是否承担正式浏览器验收责任”。

• e2e 配置必须是显式、可重放、checked-in 的。固定入口 URL、browser project、web server 行为、trace/screenshot 策略和失败保留物都应能从 repo 推出来，而不是隐含在某位维护者本机里。
• 测试内容优先覆盖“单元测试证明不了，但用户一定会踩到”的旅程，例如登录后首屏、编辑保存、发布流程、嵌入式 operator console 操作、端到端表单校验、浏览器权限与本地 API 交互。不要把所有点击都塞进 e2e，也不要只测最容易通过的 happy path。
• 尽量为 e2e 准备稳定输入：mock backend、seed data、固定 preview port、受控账号或 deterministic fixture。多 runtime 项目尤其需要把 preview 地址和 data path 说清，否则测试会被环境波动拖垮（projects/blog-26.md）。
• 工具型控制台和产品 UI 都适用同一个原则：把最关键的浏览器路径拉进 gate。像 projects/proxy-broker.md、projects/octo-rill.md 这类 operator surface，单元测试再多，也代替不了“控制台真的能在浏览器里走完主操作”的证明。
• E2E 应与 release/readiness gate 对齐，而不是独立悬空。若仓库已经把 e2e.yml、ci.yml、release.yml 或 label gate 写成交付契约，Topic 回答里就要明确哪些场景必须过 e2e 才算可发。

• projects/blog-26.md：适合说明多 runtime 产品为什么仍然需要一条统一的浏览器验收链。Astro public site、admin SPA、legacy Next runtime 共存时，Playwright 能验证真正对用户可见的整条路径。
• projects/proxy-broker.md：适合说明运维控制台同样需要 e2e。这里的核心不是漂亮 UI，而是 operator web console 在真实浏览器里是否能完成关键管理动作。
• projects/octo-rill.md：代表“产品化服务 + 嵌入式控制台”的场景，说明 e2e 不只属于纯前端产品，也适用于需要长期维护的 internal/product dashboard。
• projects/paste-preset.md：代表偏前端、交互密集、带本地工作流的项目，说明 e2e 在这类工具里常常承担剪贴板/截图/图片处理等浏览器行为验证。
• projects/blog-26.md、projects/kaisoumail.md：补充说明同一 Topic 可以跨 public site、管理台和应用流程存在，但前提都是“关键用户旅程被 Playwright 当成正式 gate”，而不是仅仅装了测试框架。

• 把 Playwright 当成“能点几下页面就算覆盖”，会导致测试数量很多但真正关键流程仍然无人看守。
• 没有稳定数据和固定入口地址的 e2e，最终会退化成“偶尔本机能过”的脆弱脚本，既挡不住回归，也会拖慢团队对门禁的信任。
• 只把 e2e 放在前端子项目里，不和 release/readiness gate 对齐，常见结果是测试长期失修，但仓库依然继续发布。
• 误把 Browser automation 或 Storybook component QA 的问题塞给 Playwright e2e，会让 Topic 回答失焦：前者关心自动执行，后者关心组件层；e2e 关心的是跨层真实旅程。

• projects/paste-preset.md
• projects/octo-rill.md
• projects/proxy-broker.md
• projects/blog-26.md
• projects/kaisoumail.md
• skills/style-playbook/references/data/topics/playwright-e2e.json