domain-model

For wiki-forge-managed projects, the domain-model phase is wiki-native:

• Canonical decisions belong in the wiki vault, usually projects/<project>/decisions.md, not repo-local docs/adr/.
• Canonical glossary/context artifacts also belong in the wiki layer, for example projects/<project>/architecture/domain-language.md, not repo-root CONTEXT.md.
• wiki remains the second-brain layer; forge decides when domain-modeling is part of a software-delivery workflow.

Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time, waiting for feedback on each question before continuing.

If a question can be answered by exploring the codebase, explore the codebase instead.

Pre-PRD Outputs

Produce these artifacts before write-a-prd:

• Decision log: append durable, hard-to-reverse decisions to projects/<project>/decisions.md.
• Domain language page: keep glossary, relationships, and flagged ambiguities in projects/<project>/architecture/domain-language.md.
• Open ambiguities: leave unresolved questions visible so write-a-prd can consume them explicitly instead of rediscovering the same uncertainty.