跳到主要內容

ARC 2.0.0-beta.25

AUP on Web Device

Separate AUP static-HTML tree rendering, page-layout composition, and Web Device site responsibilities.

Web Device is a Web-facing site provider, not a layer that collapses every AUP and website concept together. It has two currently verifiable AUP paths: a supported AUP tree can render directly to static HTML, and a page-layout AUP can compose site components for reusable Web presentation. These are related paths, not permission to place arbitrary native primitives directly into a Web layout section.

ConcernAUPWeb Device
Tree, event, state, capability/degradationDefines the semantic contractUses the target renderer's support boundary
Static HTMLCan produce it from a supported treeOwns the Web renderer, page assembly, and build
Page directories, content objects, locales, SEO, and themesDoes not define themOrganizes them through pages/, content/, and .web/
Site componentsCan be referenced by a layoutLive in .web/components/ as reusable Web implementation

Choose the right path

When arranging branded components, content lists, or themed styles in a site page, start with Web Device's pages/ and .web/components/, then use an AUP layout for structure. When verifying a cross-device interactive tree, session patch, or device capability, start with an AUP app and its target renderer.

The paths share AUP semantics but require different acceptance:

  • AUP-app browser acceptance observes session, navigation, event, and patch behavior.
  • Web Device acceptance observes static pages, locales, links, SEO, and build output.
  • One green path does not replace the other. Static HTML success is not interactive-session success; an AUP app running is not proof that a content site has correct routes and SEO.

A minimal order for a site author

  1. In Web Device, create .route/web, .web/site.yaml, and pages/index/ first.
  2. Use Web components for reusable layout sections. Treat direct native-tree static rendering as its own supported-renderer path, not as a replacement for the layout component contract.
  3. Use AUP's event/state contract for interaction and Web Device's source/binding contract for content objects.
  4. Run DSL/site checks, build, and real browser acceptance separately.

Do not treat hidden UI, static rendering, or a page component as AFS authorization. Caller identity and scope remain a separate boundary. Site-building steps belong to the target-specific Web Device layer, not to this AUP board.

For a live document-surface walk of the 18 primitives, Markdown directives, and deck media host (gallery / YouTube media-fill / tweet clamp) on this site: AUP capability tour. The tour is evidence for the document target only; it does not replace device capability reports or Web Device site acceptance.