The Self-Describing Lab
Status: Public design proposal and product vision. This series presents Diem CMF .NET’s intended architecture and capabilities. Proposed features remain subject to implementation and validation; existing components are identified separately.
An instance of FrenchExDev.Net.Lab should be able to describe its own composition using the capability types supplied by installed extensions. The same description can drive an administration interface and the operations used to realize that composition.
This is a proposed self-management capability. It requires a running host and implemented adapters; writing a self-referential model does not establish that the Lab already operates itself.
Three descriptions with different jobs
| Description | Purpose |
|---|---|
| Capability catalogue | Installed types, contribution contracts and supported operations |
| Desired Lab model | Versioned declaration of services, workspaces, domains and policies |
| Observed state | Actual processes, releases, routes, resources and readiness |
A GitLab integration supplies the types and operations needed to describe a GitLab service. Its Bundle renders configuration, and wrappers/adapters perform the required operations. An admin contribution makes those settings inspectable and editable within declared constraints.
The Lab can use that type to describe the GitLab which hosts a managed application's sources, including eventually its own sources.
A self-description loop
A model edit changes intent. It does not immediately prove that a service is running with that configuration. The operation result and subsequent observation establish what happened.
Break the initial dependency cycle
The first host must be runnable before the services it is meant to create. A proposed bootstrap distribution therefore contains a compatible Lab host, the initial capability contracts and enough package material/configuration to load a starting description.
Additional binaries are discovered or installed through configured adapters according to the starting environment's capabilities. Downloads cannot depend exclusively on a package service that is not yet available.
A previous known-compatible host can manage the transition to a new release. The bootstrap route remains documented for recovery; it should not rely on an undocumented personal machine state.
The older HomeLab bootstrap discussion is useful background. Its proposed one-off shell script is not adopted as a mandatory design here: the preferred product route is a packaged seed using the same reusable integration model.
Self-management does not erase lifecycle boundaries
Changes to the Lab's own service definitions may restart a component that the management interface uses. The plan must identify that boundary and record enough state to observe or resume the transition.
The public frontend's serving process has a separate lifecycle from an administrative operation. The Lab remains a required capability even when its UI is not exposed on a public address.
Changing a capability's definition, activating a new plugin and updating a service instance are also distinct. M2 contribution types describe what can be modeled; an M1 declaration selects the instance configuration; M0 observation reports what exists.
Apply it to the product instance
The Lab describes the product site's instance, public /diem binding, workspaces and extension dependencies. The Diem instance uses its own administration and composition to present the product. These are related self-use loops with different responsibilities.
The Lab lifecycle and configuration contracts provide the acceptance rules for this behavior.
Previous: Rendering, Generation and Live Development · Next: Diem CMF .NET 11: Specification · Series index · Section index