Extensions — project one contributed surface in Altar without client-code injection

[zenithruneblade]

Define how an admitted extension or Composition becomes visible and usable in the Altar without loading extension-owned browser code.

This is a bounded child of #63. ADR 15 — Frontend keeps the Altar a static SvelteKit application and explicitly forbids extension-supplied HTML, JavaScript, Svelte, imports, arbitrary CSS and runtime routes. Extensibility therefore enters through closed, versioned projections and host-owned renderers.

First working slice

• Choose one admitted capability, backend operation or Composition revision and define the exact read/action projection its owner permits the Altar to expose.
• Serve one versioned, secret-free DTO/descriptor through a host-owned endpoint. Preserve owner, contribution identity/revision, Registrant provenance, availability and unsupported/unknown states.
• Render it inside the appropriate existing instrument using Core-owned Svelte components and the shared transport/validation boundary. The descriptor may supply typed data, semantic labels and finite presentation roles; it may not supply markup, script, imports, selectors, arbitrary assets or execution authority.
• Map every action to one named backend command with ordinary authentication, consent, stale-write and refusal semantics. A visible control never proves that a capability is authorized, ready or delivered.
• Preserve deep-link, loading/error/unknown, keyboard, screen-reader, reduced-motion and narrow-layout behavior; retain an authoritative textual/list twin for any graph or canvas lens.
• Verify that disabling or upgrading the contribution produces an explicit unavailable/revision-changed state rather than a broken route or stale action.

Separate bounded presentation contributions

Future palette and locale packages may contribute only the finite semantic map/catalogue admitted by ADR 15 and Packaging, with provenance, licence, compatibility and accessibility receipts. They do not open a CSS, component or client-code plug-in API.

Open decision

Select the first contributed projection and its owning instrument. If the desired product genuinely requires extension-owned screens or components, reopen ADR 15 explicitly with a security, lifecycle, accessibility and packaging contract; do not smuggle that capability through a descriptor.

Connections: #14 Loom inspection, #36 evidence, #56 Settings editing, #66 backend projection, #69 Composition registration.
Verification: generated-contract checks plus browser tests for enable/disable/revision, actions, accessibility and static packaging. Shared contribution rules: #52.