ADR-0004: Use Existing Scaffolders
Date: 2026-06-10
Context
Producing the initial code skeleton of an application is a well-solved problem with mature tools: JHipster (Java enterprise), Spring Initializr (Spring Boot starters), create-t3-app (modern TS), Yeoman (long tail), and many domain-specific generators. These tools encode years of pattern refinement and remain actively maintained by their communities.
Building a parallel code-generation engine would duplicate effort, introduce maintenance burden, and produce inferior output for some time.
Decision
The Composer invokes existing scaffolders rather than implementing scaffolding logic itself. The Composer’s job is to choose which scaffolders to invoke, translate the resolved Spec into each scaffolder’s input language, and post-process their output.
Rationale
- Scaffolders already encode mature patterns; reusing them is faster and higher quality than reinventing.
- The platform team’s time is better spent on the Component and Module Libraries, the Composer’s orchestration logic, and the Stitcher prompting strategy.
- Scaffolder upstream maintenance is shared with the community.
- New scaffolders can be added as the platform expands into new archetype categories.
Consequences
- The platform inherits scaffolder assumptions and constraints. Customization within scaffolder output is the Stitcher’s job.
- Scaffolder version upgrades may require Composer-side changes; this is part of normal maintenance.
- The platform’s value is in composition, not in raw code generation. Marketing positions accordingly.
- The Composer needs a “Scaffolder Runner” subcomponent abstracting scaffolder invocation.
Open Considerations
- Almathal may eventually contribute Manifests or improvements upstream to scaffolders. Not committed for v1.
- Some scaffolders have license complications worth checking per-scaffolder.