Diem Presenting and Developing Itself
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.
The proposed product site is a Diem instance at www.frenchexdev.net/diem. It will explain the framework while using its own modeling, composition and delivery capabilities.
This is a planned first-party application. These pages do not claim that the site has already migrated to Diem or that a marketplace is already operating there.
Give the product a real application
The instance can model documentation pages, product features, release notes and extension listings. Its public frontend presents those records through reusable views. Its administration modules manage the same content and publication state.
An extension listing may include supported contribution families and compatibility information. The marketplace capability can expose that catalogue and connect downloads to configured package feeds. The product site itself can install only the capabilities it needs.
This provides a concrete path beyond the smaller Acme Catalogue example: Diem's own public explanation becomes an application whose behavior can be inspected.
A prefix is part of the address
The instance lives under /diem, rather than owning every path on the hostname. Its navigation, canonical URLs, assets, client routing and sitemap entries must respect that prefix.
A generated asset should resolve beneath the configured prefix or an explicitly declared asset origin. An admin or Lab route uses its own binding and access policy; it is not made public because the product frontend is public.
The domain contract includes prefix-aware route resolution and collision checks.
Develop the product using the product
A developer creates a managed branch to change the documentation experience or add a new extension type. The Lab prepares its workspace and address. The developer edits through a local or web IDE and inspects the running preview.
Saving changes the workspace. Committing records the chosen changes. A candidate release identifies its inputs and installed packages. Promotion determines whether selected editorial content should move with the new definition and code.
A change to the public documentation model should not import development enquiry records or replace production content by accident.
Three stages of self-use
| Stage | What can be demonstrated |
|---|---|
| Described | A public design explains the proposed model and acceptance criteria |
| Implemented and tested | The relevant generation, rendering or Lab behavior runs with recorded evidence |
| Used for the product site | The actual product instance uses that capability in its delivery workflow |
The same distinction applies to the Lab. Its model can describe its services before it is capable of administering them. Actual self-management requires an installed host, operational adapters and successful lifecycle checks.
A prebuilt initial host can load packaged definitions and tools before the GitLab or package service it will manage is available. Once running, the Lab can describe its own configuration through the same type system used for managed applications.
What this instance should prove
The first-party instance should demonstrate public routes beneath a prefix, generated administration, reusable extensions, branch previews and explicit release/content promotion. Each capability needs a link to implementation evidence when available.
The self-describing Lab architecture explains the bootstrap boundary. The acceptance catalogue defines checks for the planned instance without claiming they already pass.
Previous: Extensions and Marketplace · Next: Diem CMF .NET 11: Architecture · Series index · Section index