Self-healing & auto-issues

Two features make Tripwire more than "an agent that clicks buttons": it heals when the UI changes, and it files root-caused issues — correlated to your backend — when something is genuinely broken.

Self-healing

A traditional test fails the moment its locator goes stale. Tripwire doesn't carry stale locators at all — there's nothing to go stale. Every step is re-grounded against the live DOM on every run.

When you write do: "Click 'Create account'", you're describing intent. So when a redesign moves that button, renames its class, or wraps it in a new component, the agent simply finds it again:

• Read the DOM. Before acting, Claude reads the page's title, URL, visible text, and a numbered list of interactive elements (read_dom). It then acts on an element by its reference (click_element, set_field), resolving the live selector at that instant.
• Adjudicate against what's actually rendered. When an assertion has no deterministic check, the model adjudicates against the page's visible text and a screenshot — so it judges what a user would see, not a brittle locator.

The result: cosmetic and structural UI churn that would turn a conventional suite red just… keeps passing. You only get a failure when the behavior is actually wrong.

See Self-heal & root-cause for the mechanics inside a run.

Auto-filed, root-caused issues

When an assertion genuinely fails, Tripwire doesn't just paint a step red. It does the triage work:

1. Captures the UI failure — the failing assertion, expected vs. observed, and the network errors recorded during the case (including any trace_id).
2. Correlates to the backend. If the failing request carries a trace_id and you've connected a server-log backend (Loki, Datadog, Elastic, a custom endpoint, or a file), Tripwire fetches the matching log lines and asks Claude for the backend error, suspected cause, and a suggested fix.
3. Builds a deduplicated issue. Every failure carries a stable fingerprint — tw:<suite_id>:<case_id>:<assertion_id>:<failure_class>.
4. Files it where you want. To the built-in "File to Tripwire" tracker, and/or to GitHub, GitLab, or Jira — whatever you configure.
5. Never duplicates. A re-run of the same failure comments on the existing issue ("↻ Reproduced again") instead of opening a fresh one. Your tracker stays clean.

This is the difference between a CI run that says "3 tests failed" and a workflow that hands you three well-described, deduped tickets — each pointing at the actual backend problem and a suggested fix.

Configuration, destinations, and the dedup fingerprint are covered in Filing issues and Connecting server logs.

Put together

A nightly run against staging will:

• Pass through harmless UI changes by self-healing.
• Fail loudly and usefully when behavior regresses.
• Hand you a triaged ticket — deduped against prior runs, and (where logs are wired up) carrying the backend error that caused the symptom.

Ready to try it? Head to Getting Started.