Walker baselines and diffs
Baselines and diffs compare two autonomous walks for the same application. They help separate new, persistent, and resolved findings and show where the recorded UI state changed.
A baseline is a comparison reference, not a certification. Pin it only after reviewing its target, authentication state, limits, findings, and coverage.
Recommended workflow
- Run and review a known-good walk.
- Pin it with
set_walk_baseline. - Deploy a change and run a new walk with comparable configuration.
- Call
diff_walkswith the two walk IDs. - Inspect the recursive report and every blocker/major finding.
- 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 are content-addressed from route and DOM signatures. Findings are joined with normalized deduplication keys. That makes stable comparisons possible, but dynamic content can still make one logical screen look new, and normalization can occasionally merge or split findings unexpectedly.
For a defensible comparison, keep these inputs aligned:
- application and environment;
- authenticated account and role;
- seed URL and allowed origins;
- walker mode, state/depth/action limits, and fuzz profile; and
- feature flags and test data.
If those inputs differ, document the difference instead of treating counts as a release-quality regression signal.
Available tools
| Tool | Purpose |
|---|---|
set_walk_baseline | Pin one reviewed walk per owner/app key |
get_walk_baseline / list_walk_baselines | Inspect current references |
clear_walk_baseline | Remove a pin without deleting the walk |
diff_walks | Compare states and findings across two owned walks |
walk_recursive_report | Render the recorded state tree with change annotations |
walk_findings_to_tickets | Produce tracker payloads for selected findings |
run_all_app_scenarios | Queue the saved scenarios for an app |
Ticket export returns JSON payloads for Linear, Jira, or GitHub. It does not post them. Review titles, evidence links, severity, sensitive content, project, and assignee before sending anything to an external tracker.
Release interpretation
A useful candidate signal is:
- no new blocker or major finding in comparable coverage;
- the targeted finding appears resolved;
- important saved scenarios pass in the intended environment; and
- someone reviews any removed states or reduced coverage.
Do not call a release green solely because findings_new is zero. A failed
login, early timeout, smaller frontier, or unavailable tester can also produce
fewer findings.