How it works
Coverage, trace, impact
Coverage checks which acceptance criteria have resolving test references. Trace follows document relationships. Impact identifies the documents and work affected by a change.
Coverage, trace and impact answer three questions about the chain. At session start, your agent validates the chain. It runs coverage, trace or impact before an operation when that operation calls for the specific check. You can request any of them in plain language. The examples use the same recipe app and search feature as the driving pages.
Is it covered?
Coverage walks the whole spine, from the product statement down through requirements, stories and checks, to the tests. A check counts as covered only when a test case points at it and that pointer resolves to a real, named test. There is a deliberate third state between covered and uncovered: covered-unresolved, the test row whose pointer leads nowhere, a stub or a stale pointer. It fails the gate exactly as a missing test does. In strict mode, a requirement is covered when every check under it is.
Worked example: you ask whether search is actually tested. The answer comes back per check: exact-ingredient search, covered; partial matches, covered; the empty-result state, a test row exists but its pointer does not resolve, so not covered. Coverage identifies that unresolved pointer so it cannot count as a verified test reference.
Is everything we agreed actually tested? Show me any gaps.rcf audit coverageRolls coverage up across the chain, counting a test case only when its pointer resolves to a real test file.
What does it trace to?
Trace walks the chain from any document: forward to everything beneath it, back to everything above it, or both ways from the middle. It also works from code: give it a source file, and the query resolves it through the code bridge to the checks that file implements, then onward through the chain. "Why does this function exist?" has a literal answer.
Worked example: months in, someone asks why the app has a synonyms table. Trace back from that source file: it implements the partial-match check, which belongs to the search story, which serves the requirement "find recipes by ingredient", which the product statement asked for. The four links record the reason for the table.
What asked for the search feature? Show me everything connected to it.rcf audit trace <id>Walks the chain from any document: the requirement that asked for it, the stories and checks under it, and the tests that prove it.
What breaks if it changes?
Impact is trace with a verdict attached. It fans out from one document to every ancestor and descendant a change would touch, and labels each one with the action it needs: this test needs re-running, this piece of work needs re-verifying, this plan needs its scope reviewed. Run it before a change to list the affected work.
Worked example: you decide search should match across ingredients and recipe titles. Impact from the search requirement lists the stories under it, the checks that mention ingredients only, the tests asserting those checks, and the finished build items whose verified status the change would invalidate. Nothing about the change is forbidden; everything it touches is named before it happens.
If we change how search works, what else is affected?rcf audit impact <id>Fans out from one document to everything a change would touch, with a suggested action against each affected document and test.
Where you will meet them
Mostly in translated form: these queries are behind the plain-language findings your agent brings you, and behind the answers it gives when you ask whether something is actually done. The audit group is listed in the CLI reference. For the flag-level references, run rcf help audit coverage, rcf help audit trace and rcf help audit impact. The same queries are exposed to your agent as MCP tools, mapped at the MCP surface.