# Future Ecosystem Notes

This file collects exploratory notes about how Domain Context Modeling could relate to adjacent AI coding frameworks, agent workflows, and specialist review layers. These notes are for future reference, not current framework requirements.

## Domain Context And gstack

Working hypothesis: Domain Context Modeling is adjacent to Garry Tan's `gstack` for Claude Code, but it is not fully accounted for by it. It may be a genuinely useful additional layer.

Note: Garry Tan is associated with YC.

### Existing overlap

`gstack` appears to include several layers that touch product understanding:

- `/office-hours` pressure-tests the idea, customer pain, wedge, and what is worth building.
- `/plan-ceo-review` challenges product assumptions and asks what stronger product may be hiding inside the request.
- `/plan-design-review` evaluates the user-facing experience and pushes against generic AI output.
- `/plan-eng-review` reviews architecture, data flow, edge cases, test coverage, performance, and implementation risk.
- `/autoplan` chains the main review pipeline together and surfaces key decisions for approval.

In shorthand, `gstack` gives an AI coding workflow product context, UX context, and technical context.

### The gap

The missing layer appears to be domain context: the shared conceptual model of the world the product serves.

`gstack` seems optimized around this loop:

```text
idea
-> product challenge
-> design review
-> engineering review
-> code
-> QA
-> ship
-> learn
```

Domain Context Modeling asks a different upstream question:

```text
What world are we building inside, and do we all understand it the same way?
```

This is distinct from asking whether to build the product, how it should feel, or how it should be implemented.

### Possible stack placement

Do not bury this inside engineering or design review. Treat it as a distinct layer that feeds them.

One possible flow:

```text
/office-hours
-> /domain-map
-> /plan-ceo-review
-> /plan-design-review
-> /plan-eng-review
-> /qa
-> /ship
-> /learn
```

Another domain-driven framing:

```text
raw idea
-> domain context
-> product wedge
-> UX model
-> system architecture
-> implementation
```

The key requirement is that the domain layer produces artifacts downstream agents can consume.

## Candidate Domain Layer Commands

Potential `gstack`-style commands or specialist skills:

| Command | Purpose |
| --- | --- |
| `/domain-discovery` | Interview the founder or team to uncover the domain. |
| `/domain-map` | Identify entities, roles, workflows, states, events, and rules. |
| `/ubiquitous-language` | Build a shared glossary and flag overloaded terms. |
| `/bounded-context-review` | Separate parts of the domain that should not be mashed together. |
| `/domain-story` | Turn workflows into plain-language narratives. |
| `/object-model-review` | Map domain objects to product surfaces and interactions. |
| `/invariant-check` | Identify rules that must always hold true. |
| `/domain-to-ux` | Translate the domain model into navigation, screens, labels, and flows. |
| `/domain-to-schema` | Translate the domain model into data structures and API boundaries. |

The strongest opportunity may be `domain-to-ux`. Many AI coding workflows jump directly from feature idea to implementation. This layer could force the missing middle step: identifying the real objects, roles, states, and relationships users already understand.

## Artifact Hand-Offs

Before product, design, or engineering review, the domain layer could provide:

- Domain summary
- Core roles
- Core objects
- Object relationships
- Primary workflows
- Lifecycle states
- Domain events
- Key business rules
- Vocabulary and glossary
- Ambiguous or overloaded terms
- UX implications
- Architecture implications
- AI authority boundaries

Then:

- The CEO or product reviewer evaluates whether the product wedge aligns with real domain pain.
- The design reviewer evaluates whether the interface reflects the domain rather than generic CRUD.
- The engineering reviewer evaluates whether the architecture preserves domain boundaries and invariants.

## Problems This Could Prevent

A domain context layer could reduce common failures in AI-built software:

- Calling the same thing by multiple names.
- Exposing database concepts as UI concepts.
- Designing screens around CRUD instead of user intent.
- Mixing different user roles into one generic flow.
- Missing lifecycle states.
- Losing important business rules and invariants.
- Building features that technically work but do not match the real-world workflow.
- Creating products that are visually polished but conceptually incoherent.

## Positioning Notes

Possible summaries:

> A domain context layer gives AI coding agents a shared understanding of the real-world domain before they design screens, write code, or define architecture.

> `gstack` gives Claude Code a startup team. Domain Context Modeling gives that team a shared understanding of the business domain.

This suggests the framework should not compete with `gstack`. It should sit before and alongside it, producing reusable context artifacts that product, design, engineering, and QA agents can consume.

## Future Questions

- Should Domain Context Modeling define command-style workflows for agentic coding tools?
- Should `domain-to-ux` become a first-class artifact in the framework?
- Should `domain-to-schema` be treated as an engineering bridge, or kept separate from the core framework?
- What is the smallest domain artifact that improves downstream CEO, design, and engineering review?
- How should domain artifacts stay current as a product ships, learns, and changes?