# Доменная документация

Как скиллам читать доменную документацию этого репо перед работой с кодом.

## Что читать перед началом

- **`CONTEXT.md`** в корне репо, или
- **`CONTEXT-MAP.md`** в корне, если он есть: указывает на отдельный `CONTEXT.md` для каждого контекста. Читайте те, что относятся к теме.
- **`docs/adr/`**: читайте ADR, которые касаются области, с которой собираетесь работать. В мультиконтекстных репо также проверяйте `src/<context>/docs/adr/`.

Если каких-то из этих файлов нет — **работайте молча**. Не отмечайте их отсутствие и не предлагайте создать заранее. Скилл `/domain-modeling` (через `/grill-with-docs` и `/improve-codebase-architecture`) создаёт их по мере того, как термины и решения реально фиксируются.

## Структура файлов

Один контекст (этот репо и большинство других):

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

Несколько контекстов (признак — `CONTEXT-MAP.md` в корне):

```
/
├── CONTEXT-MAP.md
├── docs/adr/                          ← решения уровня системы
└── src/
    ├── ordering/
    │   ├── CONTEXT.md
    │   └── docs/adr/                  ← решения этого контекста
    └── billing/
        ├── CONTEXT.md
        └── docs/adr/
```

## Используйте словарь глоссария

Когда в выводе называете доменное понятие (в заголовке issue, предложении по рефакторингу, гипотезе, имени теста), берите термин из `CONTEXT.md`. Не съезжайте на синонимы, которых глоссарий избегает.

Если нужного понятия в глоссарии нет — это сигнал: либо вы придумываете слова, которых проект не использует (пересмотрите), либо в глоссарии пробел (отметьте для `/domain-modeling`).

## Отмечайте конфликты с ADR

Если ваш вывод противоречит существующему ADR, скажите об этом явно, а не переопределяйте молча:

> _Противоречит ADR-0007 (event-sourced orders), но стоит пересмотреть, потому что…_