# Reading the results > Understand the coverage report and review your agent's changes. Web page: https://supercov.com/docs/verification All Supercov pages for agents: https://supercov.com/llms.txt ยท Full text: https://supercov.com/llms-full.txt Ask your agent to show two things together: the test changes and the coverage comparison. The report tells you what was measured. The test tells you what behavior is now checked. ## What the percentages mean | Metric | What it measures | | --- | --- | | [Lines](https://supercov.com/docs/coverage-model.md) | Which source lines ran. | | [Branches](https://supercov.com/docs/coverage-model.md) | Which outcomes of decisions ran. | | [MC/DC](https://supercov.com/docs/mcdc.md) | Whether each individual condition was shown to change a decision's result independently. | | [Assertions](https://supercov.com/docs/assertions.md) | Which executed statements at least one passing test that runs them was judged by Jev to catch a change to. | These scores answer different questions. A test can run every line while never checking the value the function returns. It can exercise both outcomes of a decision while missing one of the conditions inside it. Assertion coverage needs an assessment as well as a test run: `runs latest assertions assess` asks Jev, test by test, and saves the answers. A statement that is not asserted runs in some test, but nothing the test checks depends on it. That is a place to add a check, not always a missing test. ## Gaps and measurement limits A **gap** is something Supercov measures but your tests haven't covered. Ask the agent whether it represents useful, reachable behavior before adding a test. A **measurement limit** means Supercov cannot establish the result from the available data. Examples include a process that didn't return coverage or a runner that cannot identify individual tests. More tests won't necessarily fix it. If a result is **stale**, code or tests have changed since it was recorded. Have the agent rerun the suite and assess it again; answers to questions that did not change are reused. An old run remains useful history, but it doesn't describe the current code. ## Review the change Check that the new test asserts the expected behavior, rather than merely calling the function. Look for weakened checks, deleted tests or application changes made just to increase coverage. Before-and-after results should use the same full test command. Ask the agent to show any coverage lost as well as coverage gained, and whether the final suite passed. Keep the run IDs with the summary if you want to revisit it later. ## Inspect the comparison yourself Ask your agent for the before and after run IDs. You can reopen either report and compare them without rerunning the tests: ```sh npx supercov runs npx supercov runs npx supercov diff ``` For the [MC/DC example](https://supercov.com/docs/mcdc.md), the comparison's metric-change line reads: ```text lines +0pp, branches +0pp, MC/DC +50pp ``` `pp` means percentage points. Here, the additional test covered one more condition without changing the line or branch percentage. The rest of the comparison lists coverage gained and lost by location. Read those entries too: a percentage can stay the same while the measured code changes. For assertion coverage, assess both runs and compare their assertion summaries. The comparison above covers lines, branches and MC/DC. ## What 100% doesn't mean It doesn't mean the code is bug-free, that the requirements are right, or that every possible input was tested. The score is relative to the measured source and the selected metric. Assertion mappings also involve the agent's judgment. Supercov checks their references and recorded execution; it doesn't prove that every explanation or expected result is correct. Review consequential behavior even when the report looks complete. ## Read more in the terminal ```sh npx supercov docs verification npx supercov diff --help ``` `docs` prints the installed guide. `diff` compares saved runs; it doesn't change your code or tests.