Story: Codegen infrastructure
Table of Contents
This page documents a story in Sprint 10. It captures the goal, current status, acceptance criteria, and the tasks that compose it.
Goal
Stand up a simple in-tree code generator and use it on the two highest-leverage workloads: domain-types SQL, and the ER diagram (which had been drifting against the schema).
Status
| Field | Value |
|---|---|
| State | DONE |
| Parent sprint | Sprint 10 |
| Now | Completed 2026-01-24. |
| Waiting on | None. |
| Next | None. |
| Last touched | 2026-01-24 |
Acceptance
- Simple codegen infrastructure in place; templates + runner pattern.
- Domain-types SQL emitted from codegen.
- ER diagram generated from the SQL schema with convention validation.
Tasks
| Task | State | Start | End | Description |
|---|---|---|---|---|
| Create a simple code generator | DONE | 2026-05-19 | 2026-01-21 | Stand up basic codegen infrastructure to save Claude Code tokens; generate scaffolds locally and use Claude only to fix issues. |
| Add code generation support for domain types SQL | DONE | 2026-05-19 | 2026-01-22 | Generate the SQL for domain types from the central model rather than hand-writing them. |
| Code-generate ER diagram from SQL | DONE | 2026-05-19 | 2026-01-24 | Python SQL parser produces PlantUML ER diagrams; convention-validation engine; Mustache template; orchestration script. |
Decisions
- Codegen pays back tokens
- the immediate motivator was the Claude Code token ceiling; the long-run motivator is that generated artefacts can't drift.
- ER diagram as derived artefact
- a Python parser + Mustache template + validation engine is cheap insurance against schema drift; the validator caught real issues immediately.
Out of scope
- C++ domain-types codegen — covered in a later sprint.
See also
- ores.codegen — the component this story extends.