# D14. One component model, headless behaviours (prototype)

Every block type is a component — props schema, template, stylesheet — and the native catalogue is the set of built-in components; screen layouts are screen-level components. Agents create components and fork any template-rendered one, built-ins included; authors edit instances (props form, slots, styles, duplicate, detach). Decided after a review of ten questions (5 Oct 2026):
- **No JavaScript in components.** The page holds the SCORM API and the learner's data. Behaviour comes from the player: activities (quiz, numeric, decision, results) are *headless* — the player owns scoring, saved state, SCORM interactions, focus and announcements; a fork provides the markup through hooks (`data-t-…`) checked by the validator and by axe. Generic primitives (click events, disclosure, tabs, labels) cover the rest; code that needs more is a free object.
- **Rendered at build time.** Templates are parsed with **parse5** (MIT, Node only, not shipped in packages) and rendered by the compiler: the player stays small, the output is deterministic, and the validator analyses exactly what will run.
- **Fallback to native blocks, always.** Declared or generated from the props, checked for dropped text. It is what makes components safe for exports, translation, editors that do not know them, and detach.
- **Forks remember their parent**; a fork of an activity keeps its learner-state key. Components are not scored by themselves (activities sit in their slots).
- **Pinned copies from libraries**, upgraded explicitly; local edits of a library copy are reported. **Breaking changes migrate**: `migrations.mjs` steps run on every instance, all or nothing, and `elabora.lock.json` records the version instances were written for.
*Revisit if:* agents need a behaviour the player lacks (add it as a new headless behaviour rather than opening templates to code), or build-time rendering blocks a feature that needs props changed by events (then render the same templates in the player).