domain-driven-design

# Domain-Driven Design ## Config Resolution The skill supports project-custom principles. Resolution: 1. Look for `.lattice/config.yaml` in the repo root. 2. If found, check `paths.ddd_principles` for a custom doc path. 3. If a custom document exists at that path, read it and check its YAML frontmatter `mode`: - **`mode: override`**: the custom doc has full precedence. Use it instead of the embedded default. It must be comprehensive -- sole reference. - **`mode: overlay`** (or no mode): read the embedded `./references/defaults.md` first, then apply the custom doc on top. A custom section replaces the matching default section (matched by heading); new sections append after the defaults. 4. If a custom path is configured but no document exists at it → tell the user which configured path is missing, then read `./references/defaults.md`. 5. If there is no config file or no `paths.ddd_principles` key → read `./references/defaults.md`. 6. **Language adaptation**: if `paths.language_idioms` is set in the config and the document exists, read its **"Type System & Object Model"** section and adapt entity, value object, and aggregate implementation patterns to language constructs (e.g., struct vs class, trait vs interface, data class vs record). Language idioms take precedence over pseudocode defaults. ## Self-Validation Checklist **STOP after generating each component.** Verify ALL checks before proceeding. If any check fails, fix before presenting. If a check...