1
Test suite executed in CI
Each run produces standard JUnit XML alongside a small metadata sidecar (commit SHA, timestamp, runner platform). These runs accumulate into a history database that serves as the raw input.
2
Analysis by the flakehound CLI
Flakiness is scored by pass↔fail transition frequency on the exact same commit (not naive fail rates). Tests failing 100% since a specific commit are isolated as regressions. Failures are clustered by a normalized stack trace (volatile tokens like line numbers, memory addresses, and durations are stripped while identity tokens are preserved). AI layers can optionally generate root-cause hypotheses.
3
Dashboard view layer
The CLI outputs flakehound.report.json. This dashboard consumes the JSON artifact and structures the metrics, signals, clusters, and quarantine views shown above.
4
Quarantine & auto-release via flakehound quarantine
High-confidence flaky tests are tagged @flakehound-quarantined in their spec files with a surgical AST edit, and a GitHub issue is filed per test. The blocking CI lane excludes the tag while a non-blocking lane keeps running the tests — so once a test posts enough consecutive clean passes, flakehound removes the tag, closes the issue, and restores the file byte-identically. Nothing is ever skipped into oblivion.
Note: flakehound works strictly on test metadata (JUnit XML) and does not inspect your running codebase. AI hypothesis generations are interpretive additions and do not alter the core deterministic scores, clusters, or CI gate verdicts.