Extensions — contribute one Composition revision and application profile

[zenithruneblade]

Define and prove how a package contributes one versioned Composition/application contract without confusing documentation, package presence, workflow registration, deployment or Product packaging.

This is a bounded child of #63. Canonical application and workflow law remains in ADR 28 — Workflow; extension admission remains in ADR 05.

First working slice

• Choose one existing accepted Composition owner or keep the candidate inert until its records, judgment, terminal outcomes, authority and recovery boundaries are accepted.
• Register one exact Composition revision with stable identity, owner, immutable contract digest, owned record/request/result families, judgment and policy boundaries, effects, projections, terminal outcomes and recovery law.
• Register its Pattern catalogue references separately. Use Scrolls / Workflow — register and run one revision-pinned Scroll #29 for Spell implementations, Scroll publication, immutable resolution and Run pinning; package or Composition registration must not invent Graph nodes or edges.
• Bind one owner-qualified backend projection through Extensions — admit one backend service and host-owned projection #66 and one optional Altar projection through Extensions — project one contributed surface in Altar without client-code injection #67. Presentation does not become application authority.
• If the application needs host services, register an exact deployment profile/role set under Containers and Configuration; package presence cannot inject commands, ports, mounts, networks, secrets, migrations or dependencies.
• Keep Portfolio documentation, runtime registration, Product revision, Deployment selection and delivery evidence distinct. A Product may select the Composition but cannot supply missing domain truth or effects.
• Verify two Composition revisions can coexist where declared, new admission pins one exact revision, existing Runs do not drift, and retirement/disable produces explicit refusal or retained-closure behavior.

Boundary

A Composition is a reusable application owner, not a theme, route bundle, generic agent, package name or market label. Suite coordination, Product packaging and deployment remain separate identities and contracts.

Open decision

Select the first accepted Composition and decide the minimal runtime registry/projection representation. Do not turn every useful workflow into a Composition merely to satisfy this issue.

Connections: #29 Scroll/Pattern contribution, #40 Creation candidate flow, #66 backend projection, #67 Altar projection, #65 lifecycle.
Verification: registration/duplicate/revision fixtures, PostgreSQL pinning across restart, and projection/deployment refusal tests. Shared contribution rules: #52.