⌘K
DocsGuides

Checkpoints and design review

How larger builds land in reviewable stages, and how design quality is enforced.

Why checkpoints

Larger projects don't build as one long opaque run — the plan splits into checkpoints, each a coherent slice of the product. Every finished checkpoint is merged and ready to look at, so you see and steer the work in progress instead of waiting for a single big reveal.

Continuous by default

The build doesn't wait for you: when a checkpoint finishes, the agent rolls straight into the next one, and review happens on your schedule. Each landed checkpoint sits ready in the roadmap while the build keeps moving. Want the build to hold for your sign-off instead? Pause it from the roadmap and resume when you've looked things over.

Reviewing a checkpoint

The workspace chat carries the setup roadmap with each checkpoint's status — pending, building, awaiting review, and accepted. When one lands, pull it into your own sandbox, look through the built pages in your live preview, ask the agent for any changes in chat, and mark it reviewed when you're happy.

Design review

Every build is checked against your brief: agents capture evidence of the built pages and verify each promised feature works. By default there is no separate design judge — the agent ships its first honest build. Turning on strict design review (below) adds the judge and rework cycles.

Strict design review

When you've attached page designs, the Plan step offers a strict design review switch (off by default). With it on, the agent keeps reworking each checkpoint until the built pages match the designs you agreed on — the judge re-scores after every pass.

Strict review means agents iterate until the build matches the design — expect additional build time and cost at every checkpoint.