Skip to main content
Welcome. This site supports keyboard navigation and screen readers. Press ? at any time for keyboard shortcuts. Press [ to focus the sidebar, ] to focus the content. High-contrast themes are available via the toolbar.
serard@dev00:~/cv

Reference Scenario and Acceptance Criteria

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.

This catalogue defines observable checks for the proposed product. The scenarios are specified, not executed Diem product tests. Validating these Markdown pages establishes documentation consistency, not implementation of the framework.

Reference fixture

Acme Catalogue contains Categories, Products and Enquiries. Media is a separate extension used by Product images. Products have stable identities and a shared detail view. Enquiries use a custom application action.

The main instance exposes a public frontend and administration over one data scope. A branch named mon-essaie receives an isolated workspace and data scope on the configured production hosting environment.

The test fixture uses synthetic records. Its source/model baseline, toolchain and package versions are captured so that changes can be compared reproducibly.

Complete product journey

  1. Define Product and Category, generate conventional administration, then add custom Enquiry behavior.
  2. Install Media and compose its editor and frontend contribution into Product.
  3. Create a listing and shared Product detail view with areas, zones and nested components.
  4. Produce a Hugo/SSG catalogue and a compatible dynamic C#/Blazor view; connect enquiries through a declared application endpoint.
  5. Create the managed branch and verify its binding, workspace and isolated data scope.
  6. Edit through the selected local or web IDE. Save, inspect preview behavior and commit explicitly.
  7. Build a candidate from identified inputs and verify compatibility/readiness.
  8. Promote code with data merging disabled, then repeat a separate scenario with selected module data.
  9. Exercise the same address model beneath the planned product site's /diem prefix.
  10. Load the Lab from a seed package, inspect its self-description and apply an observable service change.

Requirement-to-evidence map

IDs Scenario Evidence an implementation must capture
DOM-01–03 Main front/admin, branch isolation, prefix routes and collisions Resolved bindings, instance/data identities and HTTP/asset checks
GEN-01–03 Model change, repeat generation, invalid input and ownership collision Input/output manifests, user-owned file hashes and diagnostics
FRONT-01–04 Inline composition, shared view scope, dual renderers, unsupported child Composition revisions, rendered pages, capability diagnostics and metadata
ADMIN-01–04 Generated relationship editor, custom action, model/content separation, policy UI/API behavior, operation results, conflicts and configuration origins
LAB-01–04 Duplicate branch event, failed/superseded build, retention and bootstrap Resource identities, candidate/active release history and retained data
DEV-01–04 Local/web workspace, explicit commit, structural edit, recreation Workspace identity, Git state, process outcomes and durable file checks
EXT-01–04 Contributions across surfaces, nested extension, incompatibility and activation Dependency resolution, contribution registry and active package selection
DATA-01–04 No merge, selected modules, conflicts and partial failure Target record comparisons, reviewed plans and recovery records
MARKET-01–04 Acquisition routes, dependencies, updates and removal Package identities, resolved graph, activation history and retained records

The detailed requirements live in domain contracts, generation, front, admin, Lab, workspaces, extensions, promotion and marketplace.

Failure scenarios that change the result

Unsupported rendering. Place a dynamic-only child component in a static composition. Validation must identify that child and preserve its editable configuration; it cannot report a successful static release.

Failed or superseded build. Introduce invalid generated input or update the branch while a build is running. The active release must remain correctly identified, and an obsolete build must not silently win activation.

Unsafe regeneration boundary. Customize the Enquiry action, regenerate twice and compare authored files. A generator attempting to write into them must receive an ownership error.

Incompatible extension. Acquire a package with a missing dependency, duplicate contribution or incompatible contract. Download may succeed; activation must not.

Data conflict. Change the same Product in development and production. Select its module for promotion. The plan must expose the conflict and reject stale target revisions at application time.

Retirement. Stop a branch instance, then remove an extension with dependent components. Both operations must apply their declared retention/dependency rules rather than deleting data implicitly.

.NET 11 qualification

At each toolchain change, record the SDK, language settings, EF/provider packages, renderers, plugin runtime and container images. Exercise representative generation, migrations, Blazor assets, DLL loading and hot-reload/restart paths.

A feature's evidence must identify the tested preview or stable release. An SDK upgrade that builds successfully does not establish that provider migrations or dynamic package activation also work.

Evidence status for publication

The public documentation must distinguish a proposed criterion, an implemented feature, a tested configuration and an actually deployed capability. When evidence becomes available, link it to the criterion and its scope. Do not replace the design banner with availability claims solely because the documentation build passes.

Previous: Content, Data and Promotion · Next: Marketplace Packaging and Extension Lifecycle · Series index · Section index

⬇ Download