Extension Master — all extensibility surfaces and child-issue map

[zenithruneblade]

Track every supported way LychD can grow and route each extensibility surface to one bounded child issue or an explicit closed/deferred decision. This is the parent map; it is not a second architecture source and not one implementation assignment.

Canonical law remains in ADR 05 — Extensions. Each receiving office keeps its own authority: Backend, Frontend, Configuration, Persistence, Workers, Graph/Workflow, Packaging, Evolution, Security and the relevant Extension Domain. Issues cite those decisions; ADRs do not embed the mutable backlog.

What this master means by an extension surface

An extension surface is a shaped contract through which an explicitly selected package may contribute a versioned thing to one receiving owner. It is broader than the current five-store boot context and narrower than arbitrary plug-in code.

Keep these distinct:

package/source admission
→ explicit selection
→ typed contribution registration
→ configuration of exact admitted identities
→ runtime/application activation
→ host-owned backend and Altar projection
→ packaging, restart/evolution and recovery

Configuration Master #64 primarily maps Settings, Runes, exact selectors and bounded policy after an extensibility surface exists. It does not define how Backend, Altar, Graph, Animator, Composition or Packaging become extensible.

Child-issue register

• Extensions — register and configure one local contribution #21 — first explicitly selected local package, shaped Contribution and Rune schema
• Extensions — manifest, dependency locks, migrations and safe lifecycle #65 — package manifest, dependency/system locks, migrations, install/upgrade/disable and recovery
• Extensions — admit one backend service and host-owned projection #66 — backend service/operation and host-owned HTTP projection
• Extensions — project one contributed surface in Altar without client-code injection #67 — Altar projection through closed descriptors and Core-owned rendering
• Extensions — register one Animator, Connector and capability profile end to end #68 — Animator, Connector, interface/profile/driver/activation and end-to-end capability call
• Scrolls / Workflow — register and run one revision-pinned Scroll #29 — Spell implementation, Scroll publication, immutable resolution and Graph binding
• Extensions — contribute one Composition revision and application profile #69 — Composition revision, Pattern catalogue, deployment/application profile and projections

Parallel master: #64 owns configurable/runic objects, precedence and immutable configuration generations.

Extensibility surface map

Surface that must be extendable	Admitted mechanism	Owning / bounded issues	Boundary and current status
Package source, Python/system dependencies, binaries, images and licences	Forge/candidate manifest with exact source, locks, platform inputs, legal inventory and receipts	#65, #45	Designed lifecycle; a running Vessel never installs its own trusted dependencies
Package selection and boot registration	Exact built-in/Crypt activation id and one sealed assembly pass	#21	Partial foundation exists; installed is not active and there is no scanning or live unload
Settings, Rune schemas and Rune instances	Shaped schema contribution plus immutable typed configuration generation	#1, #21, master #64	Configuration selects admitted identities; it does not import code, start runtimes or grant authority
Backend services and operations	Owner-qualified service/operation contribution adapted by the Vessel composition root	#66	Designed; no arbitrary Litestar controller, middleware or route-bundle mutation
HTTP/API projection	Host-owned versioned DTO/controller over an admitted backend contract	#66	Designed; route, auth, errors, OpenAPI and collisions remain Backend-owned
Persistent models and migrations	Explicit schema owner, manifest-pinned Alembic lineage/order, separate migration credentials and recovery policy	#47, #65	Registration never implies table or migration authority
Durable jobs, workers and service attempts	Typed job/attempt contribution using ordinary Workers recovery and settlement	#22, #66	No extension-owned scheduler, queue law or second recovery ledger
Animator and Connector providers	Separate interface, profile, dialect driver, activation, Rune and evidence contributions	#68, #42, #55	Designed general surface; provider identity, semantic compatibility and readiness remain distinct
Soulstone/local runtime and Portal/remote runtime definitions	Typed Animator definition and lifecycle-specific adapter	#5, #6, #21, #55, #68	Local lifecycle and remote custody remain different; registration starts neither
Agent and delegated-runtime adapters	Exact Agent builder or bounded delegated runtime declaration/adapter	#5, #28	Adapter receives only its declared containment; it is not a Graph or authority kernel
Spell contracts and implementations	Separate shaped contract and executable implementation stores	#29	Designed public catalogue; registration of contract, implementation and activation are separate
Scrolls, Patterns and Graph binding	Versioned restricted Scroll plus exact adapter and Resolution Lock	#29; execution #8 and advanced topology #61	Extend Graph by admitted score/adapter, not by live node/edge mutation or package scanning
Graph topology capabilities	Versioned adapter support for admitted serial, subgraph, branch and join grammar	#8, #61	Topology support is Graph-owned; an extension may publish only scores the admitted adapter can prove
Composition/application contracts	Owner-qualified immutable Composition revision with records, judgment, effects, projections, outcomes and recovery	#69	Designed runtime contribution; documentation Portfolio membership alone is not registration or delivery
Product, Suite and deployment selection	Exact revision/profile selection over already admitted Composition/Suite contracts	#69, #29, #3	Product packaging cannot manufacture missing application truth or authority
Altar visibility and interaction	Closed versioned projection/descriptor rendered by Core-owned Svelte instruments	#67, #14, #56	Designed; no extension-owned HTML, JavaScript, Svelte, arbitrary CSS, imports or runtime routes
Palette and interface locale packages	Finite semantic palette map or static message catalogue with accessibility/licence receipts	#67, #45	Explicitly deferred bounded data contribution, never a CSS/component plug-in API
Artifact and storage providers	Typed ArtifactRef/custody adapter under the owning storage contract	#23	Provider cannot infer adoption, promotion or application meaning
Domain effects and providers	Separate effect-specific contribution accepted by the receiving Domain	A2A #19, Toll #32, Scout #43/#51, Echo #48, Vision #49 and their owning issues	Capability registration grants no network, payment, crawl, media or declassification authority
Deployment service roles and host topology	Versioned deployment-service contribution compiled into an owned manifest	#3, #18, #65	Cannot inject undeclared commands, ports, mounts, networks, secrets, migrations or dependencies
CLI/operator operations	Inert typed operation metadata beneath one future host-owned namespace	#2	Root grammar and extension Click callbacks remain closed; dynamic operation catalogue is deferred
Evidence and inspection	Typed producer-attributed events/projections consumed by Oculus/Altar	#36, #67	Observation has no registration, execution, promotion or effect authority
Assimilation and promotion of foreign craft	Candidate → review/evaluation → source-bound package → Evolution	#35, #40, #45, #46, #65	Candidate material is not an active extension until every admission and recovery gate passes
Independent public extension SDK/registry	Versioned public API, conformance suite, signed publication and Forge distribution	future bounded work after coupled path	Explicitly deferred; current built-in/private coupling creates no compatibility promise

Reference vertical: one extension across the whole body

The child issues should eventually prove one coherent author journey rather than unrelated toy registries:

1. Bind the package source, dependencies, platform and licences (Extensions — manifest, dependency locks, migrations and safe lifecycle #65/Packaging — verify a source-bound release candidate on a clean host #45).
2. Select it explicitly and register exact contributions plus Rune schemas (Extensions — register and configure one local contribution #21/Configuration Master — Settings, Runes, selectors and generation boundaries #64).
3. Add one Animator/Connector capability if needed (Extensions — register one Animator, Connector and capability profile end to end #68/Capabilities — admit one typed non-model service #42), with effects owned by its Domain.
4. Add its backend service, optional durable worker and explicitly owned persistence (Extensions — admit one backend service and host-owned projection #66/Workers & Ghouls — durable service jobs and recovery #22/Persistence — core SQL models, migrations and async transactions #47/Extensions — manifest, dependency locks, migrations and safe lifecycle #65).
5. Publish one Spell/Scroll and, where justified, one Composition/application profile (Scrolls / Workflow — register and run one revision-pinned Scroll #29/Extensions — contribute one Composition revision and application profile #69).
6. Expose a host-owned API and safe Altar projection (Extensions — admit one backend service and host-owned projection #66/Extensions — project one contributed surface in Altar without client-code injection #67).
7. Build an inactive candidate, restart into a new Vessel generation, verify, disable/upgrade and recover (Packaging — verify a source-bound release candidate on a clean host #45/Evolution — rehearse an update and its recovery path #46/Extensions — manifest, dependency locks, migrations and safe lifecycle #65).

No step implies the next. The end-to-end receipt must preserve identity and provenance across all of them.

Cross-cutting requirements

• Every Contribution declares receiving owner, kind, stable identity, immutable revision/digest, Registrant provenance and any separate concrete Provider.
• Package admission, selection, registration, configuration, activation, effect authority, application publication, projection and promotion remain separate decisions.
• Cross-store references validate as one staged generation before membership seals; runtime code cannot mutate the registry.
• Executable code, dependency, selected-package or contribution-contract changes enter through a new Vessel generation.
• Each surface states collision, compatibility, disable/retention, migration, recovery and evidence behavior.
• Extensions use ordinary backend, worker, Graph, security, persistence and frontend laws; they do not create parallel kernels or authority ledgers.
• Deliberately closed surfaces are named as closed. “Extensible” never means arbitrary callbacks, imports, routes, UI code, Graph mutation or host commands.
• Evidence distinguishes unit registration, disposable migration, clean-host packaging, process restart, named-host operation and recovery.

Completion dimensions

Treat closure as two independent proofs:

1. Map completeness: every listed surface has one canonical owner and a bounded delivered, planned, or explicitly deferred route.
2. Vertical evidence: one admitted reference extension crosses source/dependency binding, selection, typed contribution, configuration, backend/worker/persistence where applicable, Spell/Scroll or Composition binding, safe Altar/API projection, restart/upgrade/disable, and recovery.

A complete map does not prove the vertical; one successful vertical does not prove every surface is owned.

Completion condition

Close this master when every row has a canonical owner and a delivered, bounded or explicitly deferred child route; one reference extension traverses the complete admitted vertical with retained evidence; and the author guide makes clear which surfaces are open, descriptor-driven, owner-adapted or deliberately closed.

Closure means the extensibility map and decomposition are coherent. It does not mean every future surface or independent SDK has shipped.