<objective>
Produce complete and consistent DomainSpec documentation for one feature before implementation starts.
</objective>
<context>
Source references:
- domainspec/CHANGELOG.md
- domainspec/TAXONOMY.md
- domainspec/RELATIONSHIPS.md
- domainspec/templates/*.md
Target location:
- docs/features/{feature-name}/
</context>
<process>
1. Read domainspec/CHANGELOG.md and extract current-framework constraints.
2. Identify feature capabilities first (what users/systems can do), then map each capability to operations/queries/interfaces/states/events.
3. Create or update SPEC.md as a capability-driven index containing: What This Module Owns, Module Map, Capabilities, Domain Concepts, Concept Registry, Aspect Docs, Cross-Feature Dependencies, Produces For, Stories link, and References.
4. Keep Concept Registry compact with 3 columns only: Concept, ID, Type.
5. Generate relevant aspect files from templates and add backlink headers listing which capabilities use each aspect file.
6. Apply governance thresholds:
- SPEC < 120 lines: keep capability details inline.
- SPEC 120-200 lines: keep capability summary in SPEC and move stories to STORIES.md.
- SPEC > 300 lines or heavy capability sections: create capabilities/{capability-name}.md and keep summary links in SPEC.
7. Ensure STORIES.md exists when stories are present; keep stories capability-scoped with classic + BDD formats and acceptance checks.
8. Validate cross-links, referenced field-name links, story-to-concept links, capability backlinks, and concept ID naming.
9. Run `domainspec-sync-user-stories` when SPEC, STORIES, or aspect docs change.
10. Summarize what is ready and what remains undefined.
</process>