用途
reproduce 是一个“浏览器优先”的复现技能，位于修复 UI 可见问题之前的环节。它的目标是用可运行的 Playwright 脚本或 spec 捕获当前的“现状”（as-is）行为，连同原始证据和可选的只读数据证明，使得后续的 /explore、/work 以及“目标态”（to-be）检查能够对照同一用户路径。
核心原则：在解释或修复用户的问题之前，先复现用户的精确问题。如果浏览器路径、账号、URL、数据行或预期/实际行为不明确，应当暴露这个缺口，而不是编造一个流程。
主要能力
该技能围绕“不记录现状复现状态就不写修复代码”的铁律展开，具体约束包括：在呈现复现计划之前不运行浏览器或不创建脚本；当工单或用户提供了确切步骤时，不使用合成的用户步骤；没有 Playwright 命令输出和产物路径就不声称通过；本技能不做数据变更，只做只读数据检查；不做生产数据变更或仅限生产环境的实验。
它能捕获的最小证据包括：控制台消息、页面错误、请求失败、相关 API 响应（脱敏）、目标操作前后的截图，以及可用的 Playwright trace/video。
使用方式
使用场景包括：用户输入 /reproduce、要求复现浏览器问题、要求设置 as-is/to-be 对比，或提供 URL/账号/截图并希望在修复前捕获当前问题。尤其适用于：仅靠 API 的 curl 不够的浏览器症状；需要对比预期行为与当前渲染行为的工单缺陷；需要真实登录、角色/账号选择、网络捕获、截图、trace、控制台日志或数据库数据确认的问题；修复前回归设置。
应跳过的场景：没有浏览器表面的纯后端 API 契约（使用 /verify）；没有实时 UI 复现需求的纯代码调查（使用 /explore）；用户仅要求对已修复流程做部署冒烟测试（使用 /qa-engineer）。
默认做法：如果项目已有 Playwright 设置，则使用现有设置；在现有 e2e 测试树下编写一个聚焦的 as-is spec，若没有更强的约定，则放到 .backend/<YYYYMM>/<slug>/e2e/specs/ 下；将持久报告和原始证据保存在 .backend/<YYYYMM>/<slug>/ 下。
执行阶段依次为：Phase 0 计划（分类问题、复述症状、确定目标环境与安全边界、选择产物路径、呈现复现计划）；Phase 1 加载问题与现有测试设施；Phase 2 编写 as-is spec；Phase 3 执行并捕获证据；Phase 4 可选的只读数据检查；Phase 5 报告。
适用场景与限制
安全边界方面：在本地/开发环境允许浏览器复现和只读数据库/API 检查，需限制样本并脱敏 PII；在预发/审计/共享测试环境允许在用户批准的账号/会话下做浏览器复现，但不得做破坏性设置，并记录目标 URL；在生产环境仅允许只读浏览器观察，不得做数据库检查、数据变更或破坏性/用户可见实验。如果目标环境不明确，运行前应先询问；生产观察需要用户明确指示，且所有操作保持只读。
状态语义包括：reproduced（浏览器证据显示所选目标上存在报告的问题）、not-reproduced（精确路径运行了，但报告的问题未出现，需记录差异且不称为已修复）、blocked-env（登录、URL、服务、浏览器、认证或下游环境阻止了运行）、blocked-data（所需账号/内容/数据库状态缺失或不明确）、inconclusive（证据冲突或问题缺乏足够特异性来判断）。对于 as-is spec，当观察到 bug 时测试通过是有效的，需将该断言明确命名为复现证明。
常见警示包括：因为工单含糊而编造点击路径；把 not-reproduced 当作修复；运行会变更数据的生产操作；在 .backend/ 中保存真实姓名、邮箱、token、cookie 或 ID；在有控制台/网络证据时仅使用截图；把通过的 as-is 复现 spec 当作已修正行为。
交叉引用：/explore 将 reproduce.md 作为具体症状证据消费；/work 可能添加 to-be spec 或将 as-is 断言转换为回归测试；/verify 在修复后证明后端 HTTP 契约；/qa-engineer 证明修复后的已部署浏览器流程。