Generated data editors: let a code generator consume a DataSource

[matt-edmondson]

Split out of #120, item 3, now that items 1 and 2 (path resolution, and loading/validating bound data) have landed.

Problem

A DataSource binds a data file to a SchemaClass, and as of #120 that data can be resolved and validated against its class. Nothing yet produces anything from that binding.

Scope

Extend the code generation architecture from #119 so a generator can take a DataSource — the class plus the file binding — and emit a typed editor for that data.

This depends on #119 landing first: there is no generator abstraction to extend until it exists.

Notes

• The conformance rules a generated editor must enforce are already implemented in SchemaDataValidator, and the data-file conventions (root shape, per-type JSON representation, required members, map key agreement) are documented in docs/schema-format.md. A generated editor should not invent a second, divergent set.
• Schema.SourceDirectory and DataSource.TryResolveFile give the generator the anchor it needs to find the data.

Acceptance criteria

• A code generator can be configured to target a data source.
• It emits an editor for data conforming to the bound class.
• The generated editor accepts exactly the data SchemaDataValidator accepts.

[matt-edmondson]

Triage

Priority: Medium Effort: Large

What needs to be done: Extend the code-generation architecture (from #119, now merged via PR #125) so a generator can consume a DataSource (class + bound data file) and emit a typed editor for that data, conforming to the same rules SchemaDataValidator already enforces.

Suggested next steps / acceptance criteria:

• Define the generator's target shape (what "editor" means here — likely UI code) before writing it, reusing docs/schema-format.md's data-file conventions rather than re-deriving them.
• Reuse Schema.SourceDirectory / DataSource.TryResolveFile as the file-resolution anchor, per the issue notes.
• Round-trip test: generated editor accepts exactly what SchemaDataValidator accepts.

Blockers / dependencies: #119 is closed/merged, so this is now unblocked on the generator abstraction. Soft (non-blocking) relationship to #128: that issue's headless ImGui test harness may be a reusable pattern if the generated editor is ImGui-based, but the generated editor is a distinct codebase from SchemaEditor itself, so #128 is not a hard prerequisite here.

---

Generated by Claude Code