This chapter is for the people who want to know what's underneath. Four architectural decisions shape every build; understanding them explains most behavior you'll observe.
1. Plan first, always
The builder never streams code straight from your prompt. It produces a plan — pages, features, product type — and waits for approval. That's not ceremony: the plan is where ambiguity gets resolved while resolution is still free, and it's the contract the final conformance check verifies the build against. A build isn't just "done"; it's done relative to what was promised.
2. Product type is a real decision
At plan time the build commits to a type: a plain site, an installable offline-capable app, a framework build that compiles, or a server-backed app with real state. The type decides everything downstream — how it previews, what publishing means, whether accounts and databases are possible, which native artifacts can be built. It's the one plan-time choice that's structural rather than cosmetic, which is why the plan chapter tells you to check it.
3. Builds run in isolated workspaces
Generation happens server-side in a workspace that belongs to that run — with your knowledge files and references copied in, and with untrusted build steps executed inside containers rather than on the host. You can close the tab; the run doesn't care. The isolation story continues in tenant isolation.
4. Verification is the exit, not a report
A build leaves the pipeline when separate verifier agents — code review, security, links/SEO, accessibility, conformance, an in-browser run — stop finding problems, with fixes applied and re-checked in between. The deep dive is How builds verify themselves; the architectural point is that "completed" is a verdict, not a timestamp.