Skip to Content
TestingBaselines і diffs walker

Baselines і diffs walker

Baselines and diffs compare two autonomous walks for same application. Help separate new, persistent, resolved findings and show where recorded UI state changed.

Baseline comparison reference, not certification. Pin only after reviewing target, authentication state, limits, findings, coverage.

  1. Run and review known-good walk.
  2. Pin with set_walk_baseline.
  3. Deploy change and run new walk with comparable configuration.
  4. Call diff_walks with two walk IDs.
  5. Inspect recursive report and every blocker/major finding.
  6. Run saved scenarios for flows where deterministic coverage matters.
set_walk_baseline( walk_id="<reviewed-walk>", app_name="my-app", notes="Reviewed staging reference for revision <sha>" ) diff_walks( base_walk_id="<reviewed-walk>", new_walk_id="<candidate-walk>" )

Identity and comparison limits

States content-addressed from route and DOM signatures. Findings joined with normalized deduplication keys. Makes stable comparisons possible, but dynamic content can make one logical screen look new, normalization can occasionally merge or split findings unexpectedly.

For defensible comparison keep inputs aligned:

  • application and environment;
  • authenticated account and role;
  • seed URL and allowed origins;
  • walker mode, state/depth/action limits, fuzz profile; and
  • feature flags and test data.

If inputs differ document difference instead of treating counts as release-quality regression signal.

Available tools

ToolPurpose
set_walk_baselinePin one reviewed walk per owner/app key
get_walk_baseline / list_walk_baselinesInspect current references
clear_walk_baselineRemove pin without deleting walk
diff_walksCompare states and findings across two owned walks
walk_recursive_reportRender recorded state tree with change annotations
walk_findings_to_ticketsProduce tracker payloads for selected findings
run_all_app_scenariosQueue saved scenarios for app

Ticket export returns JSON payloads for Linear, Jira, GitHub. Does not post them. Review titles, evidence links, severity, sensitive content, project, assignee before sending to external tracker.

Release interpretation

Useful candidate signal:

  • no new blocker or major finding in comparable coverage;
  • targeted finding appears resolved;
  • important saved scenarios pass in intended environment; and
  • someone reviews removed states or reduced coverage.

Do not call release green solely because findings_new zero. Failed login, early timeout, smaller frontier, unavailable tester can also produce fewer findings.