← RCF Lite docs

Driving

Reviewing the tree

Your agent has elicited a chain and stopped to walk you through it. This review is where your judgement of the product happens. Take it seriously.

After elicitation, before the first build, the agent stops and offers you a review of the documents. This is the docs-review gate, and it is a named ritual of the method, not an afterthought: the tool has already proved the tree is well formed, and this gate is where you prove it is right. It is the cheapest moment in the whole project to catch a wrong assumption. After the first build it costs code to fix.

Open the viewer

Ask for it, or run it yourself; this one is genuinely worth knowing either way:

Open the requirements viewer for me.

Starts 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.

The viewer opens in your browser on 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? Missing is the failure you expect; invented is the one that slips through.
  • 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 sitting in tier three, 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. Push back until reading the acceptance criteria feels like reading your own intent in someone else's handwriting. That is the standard.

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, and the review stage of every cycle repeats this same judgement in miniature, against the running app instead of the documents.

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.