Design a Domain Change

Use the read capability first. For a changed owner, invariant, boundary, event, contract, consistency rule, regulated rule, or irreversible behavior, follow the seven-step workflow.

1. Start with business behavior and observable acceptance criteria.
2. Identify the owning Context and existing collaboration.
3. Choose the narrowest collaboration surface that preserves consistency, authorization, idempotency, failure, and observability behavior.
4. Derive the tactical design from the invariant and consistency boundary. First decide whether a tactical pattern is needed; then record the domain forces, smallest chosen approach, rejected alternatives, and proof obligations, prescribing no language-specific class or package layout. See tactical design reasoning.
5. Define the proof and counterfactual check with pattern verification. Create and validate the Requirement, Proposal, Test Obligations, Evidence Bundle, and Draft PR. The proposal's implementation_design is the implementation handoff for the coding Agent.

Do not turn an absent Registry record into an invented fact. A proposal records uncertainty and requires the configured review before implementation may rely on it.