Domain

The Domain tab establishes the context every other workspace tool builds on — it is where the project is described before it is drawn, which is why the workspace opens here. In requirements terms, it holds the lightweight requirements document most small projects never write down: what the product is, who it serves, what it must do, and what constrains it. Start here before generating schemas, routes, or access rules so those tools have a clear description of the product to work from.

What you can define

The tab is a set of focused panels rather than one long form:

• Description explains the product, its audience, and the problem it solves. This is the single most leveraged text in the workspace — it grounds every AI suggestion downstream.
• Features state what the product must do — the functional requirements, each a short title with room for detail. Keep them at the level of user-visible capability; where a feature sits between business and technical requirements is a decision worth making deliberately.
• Roles name who uses the product. Roles are distinct from Stakeholders: a stakeholder is anyone involved in or affected by the project, while a role is a category of user the running application must distinguish.
• Compliance captures the regulatory constraints — common standards like GDPR, SOC 2, HIPAA, and PCI DSS are offered as one-click suggestions. It sits beside Features rather than under Security on purpose: compliance constrains what the product must do, not who may do it.
• Libraries and services separate installed code from external platforms. A package is something you install and own a copy of; a service is something you call at runtime — and the questions that follow (keys, quotas, what happens when it is down) are different for each.
• Docs and notes keep reference material and open questions visible throughout planning.
• Implementation comes last because it is the handoff to code: constraints and instructions the generated project should follow, plus an option to end the exported AGENTS.md with the scaffold's suggested build order.

Each list panel has AI assistance: generate roles or features from the description, suggest additions to any list, or refine the description itself.

How the tab affects the workspace

Domain is the source of truth the rest of the plan traces back to:

• Roles become the columns of the Security tab's access matrix and are available as route guards in Structure — so an access policy is always stated against users the Domain actually names.
• Features become the rows of the Traceability matrix, where each one is mapped to the pages, entities, and endpoints that satisfy it — the forward-traceability half of requirements engineering.
• The description grounds AI generation across Data, Backend, Theme, SEO, and Accessibility, and compliance entries stay visible as standing constraints.

All of it flows into the project report, so the Domain doubles as the requirements section a stakeholder review reads.

Working iteratively

Changes save with the project automatically. Build the smallest useful Domain first — a description, a handful of features, the two or three roles you are sure of — and return as the rest of the workspace reveals missing decisions. Planning tabs are cheap to revise; this is the plan-before-code discipline applied at the scale where it costs minutes, not meetings. For running this process across a whole team, see the requirements management best practices guide.