Limits: when not to build on Site

• A single-screen application has one node; the tree buys nothing.
• Locales are route params when they arrive; themes are preferences, not routes. Neither is built.
• A tree is one document: an address it does not hold is a full load, and a generated page of the same application is navigated to, drawn from what the browser holds. That is measured, not assumed: a Navigate Command was 1.3 to 4 times faster than the page's full load, and 3 to 6 after a hover (docs/benchmarks.md).
• No layout-spanning Surfaces, no per-node child models or route-local subscriptions — deliberately, until a real nested layout demands them.
• Status caveat: the in-repo proof is tests plus the routing example (Remote-free). Prefetch/SSR adoption in a Remote-backed app is the open slice; the framework halves are proved and waiting.

Where to read next#

• foldkit-site README — API reference.
• Site and Foldkit's Router — what the Site adds to the Router, and how it works.
• Site, Remote and SSR together — one application built with all three, every snippet compiled and run.
• Routing example — the third cut on Site placements and routing, the only app consumer so far.
• Server-derived state — Remote's ownership and policies.
• Agent contract — the same Model/Message seam agents use.