Tour: Verify
Verify is the wheel’s stage for judging the result — is your code actually doing what you meant? Code that compiles isn’t code that works. Tests are intent made executable, and only you hold the acceptance criteria. Verify reads the coverage report your test run already produces and turns it into one dispatchable question: what should I test first? Press4
to jump here.
Test gaps — risky ∩ untested
Plenty of files have no tests; most don’t matter. Verify surfaces the ones that do: files that are risky — complex, churning often, or understood by only one person — and have little or no coverage. That intersection is the “test these first” list, ranked, each row a click from the file itself. It reads whatever your tests already emit — LCOV, Jest, Cobertura, JaCoCo, Go cover — and matches it against the complexity, churn, and ownership Reikon already computes. No new tooling, no separate run.Honest about missing data
No coverage report configured? Verify says so and stops — it never fabricates a gap from absent data. Run your tests with coverage, re-analyze, and the list appears. Every risky file already covered? It tells you that, too.A dispatchable finding
The test-gap list is built to hand straight to an agent. Your agent reads it over MCP (get_test_gaps), writes the missing tests in its own environment, and the diff returns to
Review for you to judge — you hold the acceptance criteria, the agent does the
typing. (Failing-test → fix is a deliberate gap: Reikon reads coverage reports, not test
runs, so it has no failing-test signal to act on.)