How it works
Coverage, trace, impact
Because the chain is explicit, three questions that are usually acts of faith become queries. Your agent runs them constantly; here is what they answer.
Every audit query over the chain is one of three questions. Your agent runs them at session start, before edits, and inside the build cycle; you can ask for any of them in plain words whenever you are curious. The worked examples below all use the same small project, a recipe app with a search feature, the example the driving pages use too.
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. 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. That last one is precisely the kind of quiet lie coverage exists to catch.
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. Four hops, no archaeology.
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 before a change, it turns "I think that is safe" into a list.
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 flag-level reference for all three lives with the audit group in the CLI reference; the same queries are exposed to your agent as MCP tools, mapped at the MCP surface.