Regression monitoring

#What it does

After a fix is merged, Claudear watches for the error to reappear in Sentry. If the same (or a semantically similar) error surfaces above a configurable threshold, it is flagged as a regression and a new fix attempt is queued automatically.

This closes the loop: instead of assuming a merge means the problem is solved, Claudear validates the outcome in production.

#How it works

1. Monitoring window opens — when a PR merges and the issue is marked resolved, Claudear starts a timer (monitoring_duration_hours).
2. Periodic checks — every check_interval_hours, Claudear queries Sentry for new events matching the original error.
3. Similarity matching — events are compared using semantic similarity. If the similarity score exceeds similarity_threshold (default 0.75) and the event count exceeds sentry_event_threshold, it's flagged.
4. Regression created — the regression is recorded in the database and visible on the Dashboard Regressions page. A new fix attempt is queued.

#Configuration

All settings live under [regression] in your claudear.toml. See the full reference for every option.

[regression]
# Enable/disable regression monitoring (default: true)
enabled = true

# How often to check for regressions in hours (default: 1)
check_interval_hours = 1

# Monitoring window after release in hours (default: 24)
monitoring_duration_hours = 24

# Minimum Sentry event count to flag (default: 1)
sentry_event_threshold = 1

# Semantic similarity threshold (default: 0.75)
similarity_threshold = 0.75

# Repos that indicate releases are live
target_repos = []

# Optional: GitHub token override for regression search
# Falls back to scm.github.token when empty
github_token = ""

# Optional: Repos to search for similar issues
github_search_repos = []

#CLI commands

# List all regressions
claudear regressions list

# Run a regression check now
claudear regressions check

#Tips