Change-Driven Coverage: Testing What Actually Changed
Coverage gaps are everywhere. The question isn't which ones exist — it's which ones matter right now. Here's how connecting SentinelFlux to your code repositories changes the answer.
Every non-trivial product has more untested KB scenarios than a QA team can address in a sprint. CoverageGap analysis is useful, but a list of 80 uncovered scenarios with no ordering is hard to act on. Where do you start?
The answer changes when you know which backend services changed since the last test run. A coverage gap in a module that hasn't been touched in six months is low risk. The same gap in a service where three functions were modified yesterday is urgent. The Service Registry makes that distinction automatic.
How it works
The Service Registry is a YAML file in your KB that maps backend service repositories to the test domains that depend on them. When SentinelFlux detects changes in a registered service, it passes the change context — changed files, changed functions, and a diff summary — into the CoverageGap agent's analysis.
The agent then weights its gap output: scenarios that map to changed services are surfaced first, tagged with the affected service name and a repo_change source field. You still see all gaps, but the ones that matter most are at the top.
Approved gap suggestions are automatically written as KB increment YAML files, which appear in the Increments tab ready to trigger a generation pipeline run. The path from "code changed" to "new tests generated" becomes a linear flow rather than a manual triage exercise.
Three ways to connect a service
Different infrastructure setups need different integration approaches. The registry supports three source modes:
Git polling (source_mode: git) — SentinelFlux diffs the service's repository against the last known commit SHA at a configurable interval. Works when SentinelFlux can reach the git remote directly. Supports PAT and SSH authentication, with credentials read from environment variables at runtime rather than stored in config.
CI webhook (source_mode: webhook) — your CI/CD pipeline POSTs a change report to SentinelFlux's coverage ingest endpoint after each push. This is the right choice when SentinelFlux is on a private network, when git credentials are restricted, or when you want real-time change detection rather than polling. A single curl call in your GitHub Actions or GitLab CI workflow is all it takes.
Manifest drop (source_mode: manifest) — CI writes a YAML or JSON file at a configured path; SentinelFlux reads and deduplicates on commit SHA. The most useful mode for fully air-gapped environments where there's no HTTP connectivity between your CI system and SentinelFlux at all.
Symbol-level precision
The simplest change report just lists changed filenames. That's enough for CoverageGap to work — it can map files to KB domains and identify relevant scenarios. But if your CI tooling can extract changed function and class names from the diff, include them in the webhook payload or manifest. The CoverageGap analysis becomes significantly more precise: it reasons about which specific functions changed and which test scenarios exercise those functions, rather than which files changed and which domain they belong to.
For Python and JavaScript codebases, most CI tools can produce this from git diff --unified=3 output. A few lines of grep or an AST diff library is usually enough.
What this changes in practice
Teams that adopt change-driven coverage reporting typically describe the same shift: they stop running full coverage audits and start running targeted gap analysis after each significant backend change instead. Instead of "we have 80 uncovered scenarios", the conversation becomes "the auth service changed today, and these three scenarios that test token refresh now need scripts".
That specificity makes coverage improvement tractable in a way that a global gap count never does. You're not trying to close 80 gaps before the next release — you're trying to close three gaps before the auth service change ships to production. That's a scoping decision your team can actually make.
Getting started
The simplest starting point is to register one service in git polling mode with no authentication (public repo or already-cloned local path), set check_interval_hours: 0 so polling is manual-only, and click Check Now once from the dashboard to verify the connection. That gives you a single working change detection loop you can extend incrementally.
Once you've seen how change context affects the CoverageGap output for one service, adding the rest of your registry is straightforward. The webhook mode adds one step to your CI pipeline config. The manifest mode adds one file write. Neither requires changes to SentinelFlux itself.