Skip to content

Template Families

Schema

A template family has:

  • format anuva/bento-template-family;
  • schema version 1.0.0;
  • stable family ID and semantic family version;
  • exact presentation-contract and renderer versions;
  • primitive shared theme tokens; and
  • non-empty Main, Companion, and Emphasis layout packs.

The server-safe package distributes schemas/editor.schema.json and runtime validation. Contract DTOs contain no DOM, editor, or network values.

Packaged catalog

ANU-18 adds the closed catalog envelope anuva/bento-template-catalog version 1.0.0. Its families array contains the exact runtime objects returned by createAnuvaTemplateFamilies() in deterministic order; the generator does not keep a second copied fixture.

Both production editor builds emit template-catalog.json, and npm run package:editor includes it in the artifact. The package manifest records the catalog path, format/version, SHA-256, and ordered family IDs. Runtime validation rejects unknown fields, duplicate family IDs, invalid families, or a mismatched catalog version before the host offers selection.

Coordinated layout packs

Each layout declares:

  • stable ID, name, and matching surface kind;
  • independent positive viewport;
  • explicit Boolean transparency;
  • top, right, bottom, and left safe-area insets;
  • one Bento slide containing layout-owned elements; and
  • semantic slots with stable ID, role, content kind, element ID, and cardinality.

Surface kind does not imply dimensions or transparency. A family is coherent through shared tokens and semantic intent, not identical geometry.

Every layout element must fit within the declared safe area. Invalid dimensions, duplicate identities, missing surfaces, dangling slots, incompatible slot kinds, and renderer mismatches fail before selection.

Versioning

  • Family version changes when its layouts, slots, or theme semantics change.
  • schemaVersion changes only when the family DTO changes.
  • contractVersion and rendererVersion are exact compatibility gates.
  • A future or mismatched version is rejected; the editor does not guess or migrate it.
  • CMS may select and persist family identity, but this repository owns family validation and application semantics.

Application

Layout planning is pure and deterministic. The reviewed plan records mappings, retained user extras, removed layout-owned elements, warnings, and blocking issues. A layout application commits only when the complete resulting presentation validates.

Whole-family application plans and commits all three surfaces atomically. One unsafe surface rejects the complete family operation.