Build a page with AUP

In Web Device, AUP has two related but distinct paths. The static renderer can render a supported native AUP tree directly to HTML. A page layout.aup, by contrast, uses the Web layout and component contract; its reusable presentation belongs in site or theme components, which own richer browser HTML, CSS, and interaction. The current Web renderer defines both support boundaries; an AUP primitive existing does not mean it is a valid layout section or that it must render on the Web.

How a page gets a layout

For pages/<name>/, the current runtime looks for a layout in this order:

The locale-specific layout.<locale>.aup, then layout.aup.
The locale-specific layout.<locale>.json, then layout.json.
A compatibility convention layout inferred from the page directory and site component names.
The default page layout.

The first two are explicit author-provided layouts. Prefer layout.aup for a new page; layout.json is compatible input, not the default form for a new tutorial. A missing layout does not prove that a page renders as you intended; it only makes the runtime attempt the next fallback. Local acceptance must therefore include the rendered page, not just the directory.

Components and native nodes in a Web layout

The Web renderer validates page layouts against the Web component-and-props contract. Its separate static-tree renderer can render supported native AUP trees, but that does not make arbitrary native primitives valid .web layout sections. A page can reference a component in .web/components/ or one supplied by the selected theme. Components are the stable site layer for reusable Web HTML, styling, slots, and page data.

Conceptually, a page should look like this:

pages/index/layout.aup
        │
        ▼
.web/components/site-home/
        │
        ▼
HTML, CSS, theme tokens, and content bindings

This does not mean that all UI belongs in one component. It preserves a stable boundary: the page arranges the semantic structure, and site components provide reusable Web presentation.

Start with the page directory

Create pages/index/ or another explicit pages/<name>/ directory.
Add layout.aup, using Web components that actually exist in the site or selected theme. Use the direct static-tree path only when that separate renderer and its node support have been verified for the target.
If the page needs content data, declare it in the page's source/binding layer; do not copy article body text into a layout. See Bind content to a page.
Use arc dsl validate . for DSL, then arc blocklet build . and a browser check for the final presentation.

A page can have locale variants, but a locale file is not a second page model. Keep the same page and component structure first, then add layout.<locale>.aup or locale-specific content. Split the layout only when the structure itself needs to differ.

Common misunderstandings

Misunderstanding	Current boundary
“Any native AUP node can be a section in `layout.aup`.”	No. Static-tree rendering is a separate path; Web layouts use actual Web components and their props.
“`layout.json` is the recommended format for new projects.”	It is compatible input; new pages should prefer DSL source.
“No layout means the page must fail.”	The runtime has convention and default fallbacks; neither verifies product intent.
“A content object should carry every page's UI.”	An object can have content or an inline-layout boundary; keep shared presentation in pages and components.

Read Compose pages and layouts next. The general AUP language contract is intentionally outside this Web Device board.