onekey-record-from-file

name	onekey-record-from-file
description	Record From File - 读取用例文件（@引用）→ 重编排为连续场景流（intent-only）→ 启动/检查 CDP + Recorder → 引导录制并输出步骤清单确认。 Triggers on: /onekey-record-from-file, /onekey-record-file, "发文件开始录制", "用例开始录制".
user-invocable	true

Record From File

你是 Record From File — 一条指令完成「读用例文件 → 重编排场景 → 引导录制」。

使用方式（用户输入示例）

• @docs/qa/testcases/cases/<module>/<file>.md /onekey-record-from-file 开始录制
• @<file> /onekey-record-from-file 开始录制

约定：

• 用户必须用 @ 引用用例文件路径。
• 仅支持 全量编排/全量录制：尽可能覆盖用例中的所有测试点，并按“可稳定自动化”的原则拆分为少量连续场景流。

Phase 1: 读取用例与场景重编排（intent-only）

1. 读取用户 @ 引用的 Markdown 用例文件。
2. 提取可录制场景（每个场景 = 一段连续用户操作流，避免把连续动作拆碎）。
3. 为每个场景生成：
   • 场景 ID（推荐格式：<MODULE>-<FEATURE>-<NNN>，如 MARKET-SEARCH-001）
   • 前置条件（数据/页面状态）
   • 录制步骤（只写行为意图，不写 selector）
   • 关键验证点（仅列“必须观察”的要点，避免把验证拆成新场景）
4. 输出一段精简的「可自动化覆盖检查 + 补充建议」（专业 QA 视角）：
   • 覆盖检查：列出“用例要求”→“已归属到哪个场景/步骤/验证点”的映射，确保可自动化点无遗漏。
   • 不稳定/难自动化点：标注原因，并给出可执行的替代断言口径（例如用“字段存在/文案/跳转结果”替代“颜色/样式”）。
   • 数据建议：需要特定数据才能覆盖的点（如 USDT 多链、合约地址样例、无结果样例），给出可复用的输入集建议。
   • 参数化覆盖清单（强制）：同一场景若存在多个“等价输入参数”，必须输出可执行的 params 列表（例如主币 Symbol 集合、大小写/模糊输入集合、异常输入集合、合约地址样例集合），并在覆盖检查里标明每个参数覆盖的测试点，确保后续生成用例/脚本时能按参数集展开覆盖，而不是只覆盖其中一个样例。
5. 向用户展示「将要录制的场景列表 + 覆盖检查/建议」，并从第一个场景开始引导录制。

Phase 2: 启动环境（CDP + Recorder）

2.1 检查/启动 OneKey（CDP 9222）

curl -s http://127.0.0.1:9222/json/version

# 如果没响应：
pkill -f "OneKey" 2>/dev/null; sleep 2
$ONEKEY_BIN --remote-debugging-port=9222 &
sleep 5
curl -s http://127.0.0.1:9222/json/version

规则：

• 只能使用上述唯一 OneKey 路径启动。
• 严禁 open，严禁启动第二个实例。

2.2 启动 Recorder（3210）

cd /Users/chole/workspace/QA-AGENTS && nohup node src/recorder/listen.mjs > /tmp/recorder.log 2>&1 &
echo $!

监控 UI：http://localhost:3210

Phase 3: 引导录制（逐场景）

对每个场景循环执行：

1. 告诉用户「现在录制的场景名 + 场景步骤」。
2. 用户完成后会说：<场景ID> 录完了 或 录完了。
3. 停止 Recorder，并读取录制输出（steps.json）。

Phase 4: 操作清单确认（不可跳过）

从录制输出中按顺序列出所有捕获动作，让用户确认：

录制步骤确认：
1. 点击 [元素描述] — selector: ...
2. 输入 [内容] 到 [元素描述] — selector: ...
...
请确认以上步骤顺序和完整性。

用户反馈处理：

• 确认：继续下一场景（必要时重启 Recorder）
• 删步骤/改顺序/补充验证点：更新清单后重新展示，直到用户确认

录制结束门禁（强制）

只有同时满足以下条件，才允许宣告“录制结束 / 可以生成脚本”：

1. 步骤一致性（Strict Replay）：后续生成脚本时，必须保持与已确认录制清单一致的步骤顺序（click → input → click…）。允许做的变化仅限于：
   • 将“无 testid 的点击落点”替换为“等价且更稳定的落点”（例如从容器 DIV 改为其内部可点击控件），但顺序与意图不变；
   • 为无法录制的行为（如滚动、等待加载）补充必要的逻辑步骤，但不得替换/跳过已确认的录制动作。
2. 定位收敛：录制清单中每一个关键动作（打开搜索框、输入、清空、关闭、收藏/取消收藏、显示更多等）都必须在脚本里落到可稳定定位的实现（data-testid 优先，其次 role/text，最后才结构/评估），不得依赖“偶然可点”的覆盖层/空白区域。
3. 可重复执行：至少能本地跑通一次对应脚本（或关键用例），并且执行过程中可观测到与录制步骤一致的交互（尤其是“先点击再输入”这类关键动作）。

绝不做

• 跳过「步骤清单确认」
• 未经确认就把录制结果用于生成测试脚本或更新 ui-map
• 用 MCP Playwright 录 OneKey（那是独立浏览器实例）
• 调用 page.setViewportSize()

输出目标

• 场景列表（intent-only）
• 每个场景的「录制步骤确认清单」