Workspaces: Your Team's Domain

Think of a workspace not as a folder on your computer, but as the boundary of what your team is responsible for. In Domain-Driven Design terms, a workspace is a Bounded Context — the line inside which your team's models, language, and rules are consistent.

If you think workspace = folder	Try thinking workspace = domain
"Where are my files?"	"What does my team own?"
"Which repo did I connect?"	"What's the boundary of my domain?"
"I can point to any directory"	"I'm declaring the scope of my team's responsibility"
"It's a path on disk"	"It's a bounded context with its own language and rules"

What a workspace contains

workspace/
│
├── .dapei/              ← Runtime configuration, audit logs
│
├── docs/                ← Domain knowledge (living)
│   ├── 03-business-design.md    ← Business specs
│   ├── decisions/               ← Architecture decisions (ADRs)
│   └── feature-history/         ← Feature close summaries
│
├── repos/               ← Code within your domain boundary
│   ├── order-service/
│   └── fulfillment-api/
│
└── features/            ← Active work (short-lived)
    ├── add-rush-shipping/
    └── fix-return-flow/

Layer	What it is	Example
Runtime	Audit, config, engine state	.dapei/
Knowledge	Long-lived domain knowledge	Docs, ADRs, CDR assets, domain glossary
Code	Repos your team owns	Service repos within this bounded context
Work	Active feature worktrees	Short-lived, per-feature, isolated

Workspace as a bounded context

A workspace declares: "These things are within my team's responsibility. These are outside it."

Within scope (inside the bounded context):

• The domain language your team uses (e.g., Order, LineItem, Shipment, FulfillmentCenter)
• The business rules your team implements (e.g., "Orders over $100 get free shipping")
• The repos your team owns and maintains
• The CDR knowledge extracted from those repos

Outside scope (external dependencies):

• Other teams' bounded contexts (payment, inventory, notification)
• External services and APIs
• Upstream contexts that send events into yours
• Downstream contexts that consume events from yours

The workspace lifecycle

A workspace isn't created once and forgotten. It evolves with your team and product.

Init ──→ Grow ──→ Mature ──→ (Split or Archive)

Stage	What happens
Init	Define domain boundary, register repos, set up context, run initial CDR scan
Grow	Features close and promote knowledge back, CDR assets accumulate, domain language formalizes
Mature	Cross-workspace interactions, contract management, upstream/downstream contracts defined
Split	When the context grows too large, split into sub-workspaces with clearer boundaries

Workspace vs Feature (recap)

	Workspace (Domain)	Feature (Work unit)
Lifespan	Permanent (as long as the team exists)	Short-lived (hours to days)
Content	Shared domain knowledge, base repos	Agent worktree, feature docs, test results
Scope	"What my team owns"	"What I'm changing right now"
Persists after close?	Yes	Knowledge is promoted back, worktree is cleaned

Your workspace in the product UI

The Workspace Browser is where you see both surfaces at once:

┌─ Workspace: Order Fulfillment ─────────────────────────┐
│  Domain: fulfillment                                    │
│  Team: platform-fulfillment-team                        │
│                                                         │
│  ┌─ Assets ──────────────────┐  ┌─ Features ─────────┐  │
│  │  📁 docs/                 │  │  📂 add-rush-      │  │
│  │  📁 decisions/            │  │     shipping (Imp) │  │
│  │  📁 repos/                │  │  📂 fix-return-    │  │
│  │     ├─ order-service      │  │     flow (Design)  │  │
│  │     └─ fulfillment-api    │  │                    │  │
│  │  📁 knowledge/            │  │  [+ New Feature]   │  │
│  │     ├─ behaviors          │  │                    │  │
│  │     └─ business-rules     │  └────────────────────┘  │
│  └───────────────────────────┘                          │
└──────────────────────────────────────────────────────────┘

FAQ

Q: Our team works on multiple unrelated projects. Should they be in one workspace or multiple?
A: If the projects share domain language, business rules, and team members, one workspace. If they're independent domains (e.g., "order management" and "HR payroll"), they should be separate workspaces — each with its own bounded context.

Q: Can I rename my workspace after creation?
A: Yes. The workspace name is a label, not a path. Rename it from Workspace Settings.

Q: What happens when a team member leaves?
A: The workspace persists. It's the team's domain knowledge, not an individual's. The audit trail records all decisions.

Q: How do I know if my workspace context is well-defined?
A: A well-defined workspace has: a clear domain name and boundary, a documented ubiquitous language, known upstream/downstream dependencies, and CDR assets that reflect actual code structure.

Next steps

• Workspace Context: Defining Your Domain — set up your domain boundary
• Adding Repositories — register code within your domain
• CDR Overview — scan your codebase for domain knowledge
• Two Surfaces — workspace vs feature dimensions