Plan Domains

Create or update a domain planning document that includes:

1. domain list
2. purpose and ownership of each domain
3. dependency relationships
4. recommended document set per domain
5. recommended order of domain expansion

Default output:

• specs/domains/summary.md

Workflow

Step 1: Read the global layer

Identify modules, responsibilities, extension points, and cross-domain dependencies.

Step 2: Define the domain map

Choose domain boundaries that reduce ambiguity while staying proportional to project complexity.

Step 3: Assign document needs

For each domain, specify whether it needs:

• SA.md
• layer-core.md
• layer-dao.md
• layer-biz.md
• layer-facade.md
• another project-specific document

Step 4: Order the work

Recommend which domains should be expanded first and why.

Step 5: Calibrate depth expectations

For each domain, note whether the downstream spec should stay light, balanced, or deep. Domains that directly affect runtime correctness, persistence, public contracts, or validation should default to deeper treatment.

Handoff Rules

Before finishing, verify:

1. the domain map follows from the global layer
2. domain count is justified
3. each domain has a clear next step
4. progress tracking will be updated
5. high-risk domains are marked for implementation-ready depth rather than skeletal expansion