Explore: scaffold base code from the structured model (skill-based, evidence-gated)

Summary

Explore generating base code scaffolding (types/structs, enums, relationship-shaped fields) from the structured parts of a model. This is the most ambitious "wire code in from the model" idea — and the one with the weakest cost/benefit. Filing it to capture the design constraints, not as committed work. Gated on evidence from #5.

Hard constraints established up front

Not modelith generate --lang go in the binary. A --lang flag is an implicit promise of ts/python/java backends — each a golden-fixture suite (the example renders to one .md; this would be N language outputs), each with per-language idiom debates (pointer vs value, Optional[T] vs zero-value, how n:n materializes), each a place CI breaks. That combinatorial surface contradicts modelith's lean-binary character (~1KLOC, 4 direct deps).

The output is structurally anemic — by design of the source. From Attribute{Name, Type, Description, Derived, Derivation} and Relationship{Entity, Cardinality, Ownership, Role} you can emit little more than:

type Project struct {
    Status             ProjectStatus
    EnabledPolicyCount int       // derived — stub, derivation is prose
    Users              []*User   // n:n
    Policies           []*Policy  // 1:n, owned
}

No field is a domain type (the model is primitive-by-design because it's prose-first), no validation (invariants are prose), no behavior (actions are a {name, actor, preserves} label, not a signature). That's a struct any engineer writes in 90 seconds — and will immediately edit. Generating it richer would require adding types/signatures/grammar to the model, i.e. turning modelith into an IDL and abandoning "communication-first."

Regeneration = drift. Unlike the rendered .md (disposable, byte-compared, nobody edits it), generated code accretes hand edits the moment it exists. Owning that lifecycle imports the exact DO NOT EDIT / .gen.go / partial-file machinery that codegen tools carry — larger than modelith's current codebase.

If it's ever pursued

Do it as a skill, not a binary subcommand: the skill drops scaffolding into the user's repo and the user owns the file from birth. No regeneration contract → no drift lifecycle → no language-backend matrix baked into the CLI. Same human-in-the-loop shape as #5.

Gate

Only pursue after #5 demonstrates the skill-based, human-in-the-loop model produces artifacts engineers keep. If #5's tests are valuable but scaffolding demand never materializes, this can stay closed indefinitely — that's an acceptable outcome, not a failure.

Background

Descends from "Tier 1" of a three-tier design discussion. A skeptic pass recommended cutting it from the binary entirely; retained here as a scoped, evidence-gated exploration so the constraints aren't rediscovered later. Consider recording the decision in audits/.

🤖 Generated with Claude Code

Start by reviewing the evidence and tests from #5, since this exploration is gated on whether its skill-based artifacts are kept. If that evidence supports pursuit, define the skill-owned scaffolding boundary without adding a language backend or regeneration contract. Record the resulting decision in audits/; success means demonstrated demand and a clear ownership model.