Design Review

Every plan PugBase generates is read by a second set of models that took no part in the planning interview. They explain the design back, look for what would make a build go wrong, and check each task note for whether an agent could build it without deciding anything. The result is a Design Review note at the top of the plan, and features with open gaps are not handed to agents until you say so.

What you get

A note titled Design Review, first in the Requirements folder of every new plan. When the verdict is open, the plan opens on it.

Verdict: passed, passed after one revision, or open blockers.
What a stranger understood: the plan explained back from the notes alone, feature by feature. If this reads wrong, the notes are ambiguous, whatever you meant.
Findings: each with a severity, the note it is about, a suggested fix, and the planner's answer - fixed in the revision, or contested with the sentence that disproves it.
Ready to build?: one row per task note, with the gaps an agent would have to decide alone.
Accepted trade-offs: the majors and nits left for you to decide.

How it works

Three stages run after the plan is generated. No reviewer sees the interview or the planner's reasoning; each one gets the finished notes and nothing else.

Explain it back

A naive reader gets the notes alone, not even your request, and writes what is being built, how the systems connect, and what each feature delivers. A section it cannot restate is a blocker: an agent could not follow it either.

Attack it

Three critics read the notes against your request at the same time: a design critic (dropped requirements, failure modes, races on shared data), a structural reader (notes that disagree with each other, tasks that name things no contract defines, choices left open) and a skeptical architect (complexity nobody asked for). The planner must answer every blocker - fix the notes, or contest the finding with evidence - and the critics read the revised notes once more.

Ready to build?

Each task note is checked on its own against the contract notes: could an agent holding only this note start coding without deciding anything the plan should have decided? Notes that are not ready get one repair and one re-check.

The review runs as the last stage of planning and adds about three minutes.

The hold on the board

When the verdict is open blockers, the features with gaps are held: agents calling next_action or check_ready are told which notes to wait for and why, and are asked not to build around the gaps. An open blocker on a contract note (Overview, Constraints, API Contract, Data Model, DESIGN.md) holds every feature, because every task builds to that contract.

The Status page while a plan is held: the features, the gaps per note, and the button that lifts the hold.

Fix the notes the review names, or read the gaps and accept them, then press Unblock building on the Status page. It asks once. Nothing is held in a plan whose verdict passed.

Time, cost and limits

The review adds about three minutes to planning, and its model calls count toward your AI quota like the rest of the plan.
It runs on plans created from the web and on plans created with create_plan from an agent. Adding a feature to an existing plan is not reviewed yet.
The reviewers are models, not a replacement for your own read. A contested finding means the planner disagreed with the reviewer: the call is yours.

Tips

Answer the planning questions precisely. A reviewer can only hold the plan to what the request says; a vague request gets a plan that passes for the wrong reasons.
When a finding is wrong, edit the note and press Unblock building. The review is a record of what a stranger saw, not a ruling on your decisions.
Open the task notes the readiness table marks as not ready before anything else. Those gaps are exactly where an agent would have guessed.