Generation plans

The Modeller.Generation module creates an immutable generation plan. Planning does not render templates, inspect the filesystem, or write files. Generated artifacts remain projections of canonical meaning and never become semantic authority.

Interface

GenerationPlanResult GenerationPlanner.Plan(
    GenerationPlanningRequest request,
    CancellationToken cancellationToken = default)

The request contains a resolved generation snapshot, validated configuration, and the concrete descriptors expanded from a validated template pack. The snapshot combines the exact federation snapshot lock with a stable-ID-to-semantic-digest index. Pack orchestration, not workspace configuration, expands reusable recipes across matching canonical definitions. Each resulting descriptor names the semantic input it consumes; a template cannot discover or reinterpret additional domain meaning.

Plan schema and ordering

A successful plan records:

• schema version and logical output root;
• proposed artifacts ordered by ordinal path and artifact ID;
• explicit owner, pack ID and version, and template ID;
• the stable IDs and semantic digests consumed by each artifact;
• template and artifact-input digests; and
• one deterministic digest for the complete plan.

Ordering uses ordinal string comparison and does not depend on source order, host locale, filesystem enumeration, or parallel scheduling. The same inputs therefore produce the same plan and digest.

Safety and failure

Logical roots and artifact paths must be relative and cannot contain traversal segments. No two artifacts may claim the same path, including case-only path differences. Missing semantic inputs, incompatible configuration and pack contract versions, unresolved owning contexts, duplicate semantic inputs, excessive artifact counts, and cancellation return structured diagnostics and no partial plan.

These checks occur before rendering. Rendering consumes only a successful plan; safe application separately decides whether a rendered artifact may be written.

Child Care example

The executable Child Care scenario applies the C# Domain Project pack to the complete context. It proposes project-level outputs and one artifact for every supported Entity, Enumeration, Rule, and Behaviour. Adding another Entity therefore expands another entity artifact without editing the pack.

Legacy disposition

The legacy generator combined iteration, path substitution, rendering, and writing. The current pipeline separates that orchestration: validated pack descriptors make iteration and inputs explicit, the generation plan calculates paths and ownership without side effects, and later modules render and apply it. Accepted legacy path examples remain compatibility evidence; legacy templates and generated code do not define canonical semantics.

See Architecture 101 for the planning, rendering, and application flow.

Plans are rendered through the template-rendering reference and exposed without writes by the modeller plan workflow.