Live examples: scope and contract

A reference page can place source and actual renderer output next to each other. The page itself remains read-only. A live example may expose only the interaction the represented node already owns. It never becomes an editor for the source, manifest, or documentation.

Do not treat every rendered object as the same kind of component. Markdown directives become an AUP tree for the document target; native AUP primitives have their own target-specific support; and a Web Device .web component belongs in a page layout, not in a generic Markdown directive. This page proves only the document-target Markdown → AUP path.

Sample contract

For every published example, record in the same place: the source that produces the node; the data or manifest boundary; the target that renders it; and the exact behavior the reader should observe, including what is deliberately absent.

A document-target text input

This example is an unbound AUP input node. It has no bind, event, action, source path, or write capability. Type in it if useful. The field changes only as a browser form control; no document, manifest, AFS record, or session setting is changed. A browser may restore a form value when it reloads a page, which is browser behavior rather than AUP persistence.

Give every field an explicit id. The content reader promotes that attribute to the node’s top-level id (arc#3321). Without it, multiple inputs on one page can share a broken DOM id.

Source:

::input{id="docs-live-name" type="text" label="Name" placeholder="Type only in this example" value="Ada"}

Rendered:

The same Web Device document renderer that reads this page renders the field. This is a real document-target result, but it is not evidence of a bound form, an AUP session patch, or persistence. Use it only as evidence for one unbound field, not as a copyable multi-field live form pattern.

Failure and limits

A document-target view with mode tabs

view is a released cross-device primitive. On the document target, mode="tabs" is static UI: radio inputs and panels, not a separate widget session. Author tabs with a generic container directive so nested panel bodies survive (arc#2598).

Source:

::::view{id="docs-live-tabs" mode="tabs" label="Package manager"}
:::view{label="pnpm"}
Install with `pnpm install`.
:::

:::view{label="npm"}
Install with `npm install`.
:::
::::

Rendered:

Switching tabs only changes which panel is visible in the browser. It does not write content, open an AUP session, or run shell commands. The outer fence needs more colons than nested containers, same as other container directives.

Failure and limits

What a list must add

An afs-list reference needs a separate contract. Its source must name the list layout and template; its data section must name a read-only fixture or a declared AFS path; and the page must identify the renderer/session that actually resolved it. A static document target can render literal child nodes, but it does not by itself prove that a source-backed list can read an arbitrary path.

The current Showcase list-basic source is useful evidence for that next slice: it binds afs-list to packaged data/items and has no write action on the list itself. Before it becomes an embedded runtime sample, use a dedicated minimal demo origin rather than the full Showcase, keep its fixture data read-only, and verify that the frame has no bridge, write, or exec path. This page does not claim a verified live afs-list sample.

Verification evidence

For the isolation boundary, read Frames, bridges, and embedded surfaces. For static Web Device versus an interactive AUP session, read AUP on Web Device.