When it goes wrong

You do not need to learn the method's failure modes, and you do not need to tell the agent which check to run. The rules the agent carries make its own work its own problem: it checks the project's documents before acting on them, it catches the method's known failure modes itself, and when it finds something it talks to you about the product, never the paperwork. This page is what that looks like from your seat.

The agent checks before it builds

Whenever your agent is about to draw up a build plan, run one, or change the project's documents, it first checks the whole document chain, without being asked. The same check runs at the start of every session. If the chain has a problem, the agent stops and raises it with you before touching code, because everything it builds assumes those documents are sound.

You never have to prompt this. If you ever feel like checking anyway, ask in plain words:

AIGive the plans a quick health check and tell me what you find.

Terminalrcf define validate
rcf audit coverage

What it may come back with

Findings reach you as plain statements about the product, with a decision attached. The document ids and method vocabulary stay in the files where they belong. Expect shapes like these:

• A gap. "The plan for search does not say what should happen when nothing matches. Want me to add a check for that?"
• A missing failure path. "Sign-up does not describe what happens when someone uses an expired link. What should they see?"
• A contradiction. "Two parts of the plan disagree about whether deleting a recipe needs a confirmation step. Which do you want?"

None of these need a technical answer. They need your intent: yes, add the check; show them a message that says the link expired; yes to the confirmation step. "I do not know yet" is also an answer, and the agent knows what to do with it: the question is recorded and parked, visibly, not forgotten.

If you want to see the detail behind a finding, ask. The agent can point you at the exact document, or open the tree viewer so you can read what it read.

When you spot something yourself

Sometimes you will see the problem first, in the running app. You do not need to work out which document let it through. Say what you see:

AIThat is not what I meant by search. It should find close matches, not just exact ones.

The agent's rule for a reported bug is to treat it as a gap in the plans first: find the promise that should have ruled the bug out and the test that should have caught it, strengthen both, then fix the code against the corrected plan. That whole route is its job. Yours was the one sentence.

The safety net behind this

The failure modes this method exists to guard against, a skipped layer of planning, a test bent into passing instead of the code being fixed, work declared finished before it really was, are the agent's own checklist, walked before each stage of work is allowed to end. By its own rules, a problem you had to point out is a check it failed to run, not a duty you failed to perform.

So if the same kind of problem keeps reaching you, say that too, plainly: "this is the third time search has come back wrong". Recurring problems are a finding about the process, and dealing with the pattern rather than the instance is in the agent's playbook.

The rules themselves are no secret. The harness block publishes every one of them, in the exact words the agent was given. Read them if you are curious; you will never need to quote them.