| name | browser-replay |
| description | Replay a recorded session trajectory against the same URL or a mutated variant; uses browser-selectors embedding similarity to recover from DOM drift |
| argument-hint | <session-id> [--url <new-url>] [--mutate <json>] [--tolerance <0..1>] |
| allowed-tools | mcp__plugin_ruflo-core_ruflo__browser_open mcp__plugin_ruflo-core_ruflo__browser_close mcp__plugin_ruflo-core_ruflo__browser_click mcp__plugin_ruflo-core_ruflo__browser_fill mcp__plugin_ruflo-core_ruflo__browser_type mcp__plugin_ruflo-core_ruflo__browser_press mcp__plugin_ruflo-core_ruflo__browser_select mcp__plugin_ruflo-core_ruflo__browser_check mcp__plugin_ruflo-core_ruflo__browser_uncheck mcp__plugin_ruflo-core_ruflo__browser_hover mcp__plugin_ruflo-core_ruflo__browser_wait mcp__plugin_ruflo-core_ruflo__browser_screenshot mcp__plugin_ruflo-core_ruflo__browser_snapshot mcp__plugin_ruflo-core_ruflo__browser_eval Bash Read |
Browser Replay
Re-drive a recorded session trajectory. Used for regression testing, deterministic re-runs, and as the verification path that browser-record plus browser-selectors actually produces something replayable.
This skill is the load-bearing assumption of the v0.2.0 architecture. ADR-0001 Verification §4 requires ≥80% replay success across 10 distinct sites of varying drift profiles before the proposal moves from Proposed → Accepted. If you find replay unreliable, capture the failure modes in findings.md and report them up the ADR.
When to use
- Regression-testing a UI flow after a deploy.
- Reproducing a bug captured in a prior session.
- Comparing two runs of the same flow for
browser-screenshot-diff.
- Forking a session (
/ruflo-browser fork) and replaying the parent before mutating.
Steps
- Locate the source session:
npx -y ruvector@0.2.25 rvf status <session-id>.rvf
- Load the trajectory:
Read .../trajectory.ndjson
Each line is {ts, action, args, selector, result}.
- Open a fresh browser via
mcp__plugin_ruflo-core_ruflo__browser_open (target URL = original or --url override).
- For each trajectory step, dispatch the matching MCP tool (
browser_click, browser_fill, browser_eval, etc.) with the recorded args.
- On selector miss, do not fail immediately — query the
browser-selectors namespace for an embedding-similar selector for the same <host>:<intent> and retry once:
npx -y @claude-flow/cli@latest memory search --namespace browser-selectors \
--query "<host> <intent>" --limit 5
- Record a new trajectory for the replay run (allocate a fresh RVF container, lineage-tracked via
rvf derive).
- Verdict: tally matched-step / total-step ratio. Default tolerance threshold is 0.85 (configurable via
--tolerance). Verdict goes into findings.md.
Caveats
- Browserbase explicitly does not offer replay (rrweb session replay was deprecated). We're betting on selector-embedding recovery; expect noise on heavily drifted sites.
- Network nondeterminism (timing, content variation) can produce false-fail verdicts. Use
--mutate to inject expected variation or pin to a fixture.
- For visual diff, chain into
browser-screenshot-diff against the parent session id.
- If selector recovery requires more than one retry per step, log it. That's the signal that the site needs a re-record, not a replay.
