# Domain docs

Engineering skills must consult this repository's domain documentation before
exploring code.

## Read before exploring

- Read `CONTEXT.md` at the repository root.
- If `CONTEXT-MAP.md` exists, use it to find the `CONTEXT.md` files relevant to
  the task.
- Read ADRs under `docs/adr/` that affect the area you will change. In a
  multi-context repository, also check `src/<context>/docs/adr/`.

If these files do not exist, proceed without comment. Do not suggest creating
them before the project resolves domain terms or architectural decisions. The
`/domain-modeling` skill, reached through `/grill-with-docs` and
`/improve-codebase-architecture`, creates them when needed.

## File structure

This repository uses the single-context layout:

```text
/
├── CONTEXT.md
├── docs/adr/
│   ├── 0001-event-sourced-orders.md
│   └── 0002-postgres-for-write-model.md
└── src/
```

A repository with multiple bounded contexts can use this layout:

```text
/
├── CONTEXT-MAP.md
├── docs/adr/
└── src/
    ├── ordering/
    │   ├── CONTEXT.md
    │   └── docs/adr/
    └── billing/
        ├── CONTEXT.md
        └── docs/adr/
```

## Use glossary terms

Use the terms defined in `CONTEXT.md` in issue titles, refactor proposals,
hypotheses, and test names. Do not substitute synonyms that the glossary
rejects.

If a needed concept is absent, reconsider whether the project uses that concept.
If it represents a real gap, record it for `/domain-modeling`.

## Flag ADR conflicts

Call out any proposal that conflicts with an ADR:

> _Contradicts ADR-0007 (event-sourced orders), but worth reopening because…_