Driving
Reviewing the tree
After elicitation, the agent stops for document review. Check that the requirements and acceptance criteria describe the product you want before approving the first build.
After elicitation and before the first build, the agent stops for document review. The tool has already checked the tree's structure. At this docs-review gate, you check whether the documents capture the product you want. Correcting an assumption here avoids changing code after a build.
Open the viewer
Ask the agent to open the viewer, or run the command yourself:
Open the requirements viewer for me.rcf audit viewStarts the local tree viewer at http://127.0.0.1:4373/, tabs for overview, requirements, architecture and build sequence. 127.0.0.1 only, no auth.
When stdout is a TTY, CI is unset, --no-open is absent, and your platform has a supported opener, the CLI attempts to open the viewer in your browser. Otherwise, open the URL printed by the CLI. The viewer has a tabbed review surface: overview, requirements, architecture, build sequence. Edits to the tree stream to the open tab live, so leave it running while you review and discuss. The server binds 127.0.0.1 only and has no auth; it is for you, on your machine, not for tunnelling anywhere. If the port is busy, the CLI takes --port <n>.
What to read, in order
- The requirements, against what you asked for. Is everything you said in elicitation actually here? Is anything here that you never said? Check for both missing and invented requirements.
- The acceptance criteria, against what done means to you. Each one is a sentence someone could check. Read them as promises: if every one of these held, would you accept the product? The gaps you find are almost always edge cases: the empty state, the duplicate, the thing that fails halfway.
- The build-sequence order, against your urgency. The queue is what the agent will build, in that order. If the thing you care about most is later in the build order, say so now, not after two builds you did not need.
What good push-back sounds like
Specific, anchored to what you read, stating what you actually want. You do not need the method's names for any of it; say the behaviour, and the agent writes it into the right documents. Not "the search section feels thin" but:
The search story only promises results for exact matches. I want a search for "tomato" to find "cherry tomatoes" too. Add a check for partial matches, and one for what an empty result should show.Push-back at the review, in plain intent. The agent turns it into the right document edits, re-validates, and the viewer updates in front of you.
The agent takes that, edits the tree through the tooling, re-validates, and the viewer updates in front of you. Continue requesting changes until the acceptance criteria accurately describe your intended behaviour.
Unblocking the first build
When the tree says what you mean, say so plainly:
The docs say what I mean. Start the build.Unblocks the first build after the review. The agent takes the first actionable item from the queue and drives the build cycle from there.
From here your involvement drops to reviewing what each build item delivers. In the review stage of every cycle, the agent validates the tree and re-reads the diff against every in-scope acceptance criterion. Driving the running app against its acceptance criteria happens in the periodic fresh-context self-review and in the Test stage, where a separate verifier hand checks the reviewed head before it merges.
For what the layers of the chain are and why they exist, see The chain. For the viewer's flags, see the CLI reference. And the exact rules the agent follows at this gate are published in the harness block.