Coverage map

Sidekit keeps a persistent per-test coverage map: for each test it has executed under the collector, which files and lines that test touched. It is what lets get_tests_for_file and get_blast_radius answer at line granularity instead of guessing from the project graph.

Where it lives

In a SQLite database inside the workspace, alongside the run history:

<workspace>/.sidekit/index.db

.sidekit/

Deleting the directory is safe and non-destructive: Sidekit rebuilds what it needs. You lose the accumulated coverage map and run history, so flake detection starts over.

Building the map

The map is built by running tests with coverage on. Nothing else populates it.

run_tests(project: "tests/Core.Tests/Core.Tests.csproj", withCoverage: true)

Each executed test is re-run once under the coverage collector and its (test → file → lines) slice is stored. That is a real cost, and Sidekit is deliberate about it:

• Scoped to the tests you actually ran — never a full per-test sweep of the suite.
• Capped at 20 collector launches per run. Filter the run first if you want a specific slice mapped.
• Only tests that could have changed are re-collected. A test whose covered files are all older than the run that mapped it costs nothing.
• Unavailability degrades honestly. If the collector cannot run, the answer says so in a diagnostic rather than failing the test run.

The answer's coverage node reports refreshed, skipped and current. current is deliberately separate from skipped: skipped means you got less than you asked for — over the cap, or the collector yielded nothing — while a test that needed no work is the opposite of that.

Staleness

The map necessarily describes the code as it was when it was built. When you edit a mapped file without re-running its tests, answers derived from it come back with stale: true.

That is not a defect to work around — it is the honest label. Sidekit would rather tell you an answer is one edit out of date than quietly present it as current. Refresh by re-running the file's tests with withCoverage.

Line queries against a file with uncommitted edits are translated through the diff back to the map's original line numbering, so your line numbers keep working between refreshes. A line inside an edited hunk degrades to file resolution rather than answering about the wrong code.

Reading the map yourself

.sidekit/index.db is an ordinary SQLite database. Nothing stops you opening it and building your own tooling on top of the stored (test → file → lines) data.