## Спецификация

Спека отвечает на «что и почему», а не на «какими строками». Спека, дошедшая до имён
классов и номеров строк, — это код с худшим синтаксисом, и исполнителю в ней нечего
решать: он копипастит вместо того, чтобы проектировать.

### Прогоните каждое требование по восьми проверкам

Для каждого `R##` спросите себя и запишите ответ, если он неочевиден:

1. **Первый запуск** — что видит человек, открывший это впервые.
2. **Пусто** — как выглядит, когда данных ещё нет.
3. **Кривой ввод** — что происходит с мусором на входе.
4. **Отказ** — сеть легла, ключ протух, диск полон.
5. **Прерывание** — оборвалось на середине; что осталось на диске.
6. **Рост** — то же самое на тысяче записей вместо трёх.
7. **Границы** — кто ещё имеет право это дёргать.
8. **Потом** — как это чинить и обновлять через месяц.

Из ответов рождаются истории `R##.1`, `R##.2` с критерием приёмки на каждую. Критерий
формулируется как наблюдаемое поведение, а не как реализация.

### Отдельно опишите границы и швы

Где проходят интерфейсы между кусками, кто кого зовёт, какие типы ходят через границу.
Это решается здесь, а не первым таском: иначе первый исполнитель придумает шов, а
остальные семь будут его переоткрывать.

Запишите это в `interfaces.md` — его получит каждый исполнитель.

### Отметьте статусы

Каждое требование, попавшее в спеку: `chekan req status R01 --value in-spec`.

### Гейт G2 — двухчастный

Первая часть — ноль требований в статусе `open`.

Вторая часть — **независимый читатель**. Запустите субагента со свежим контекстом и дайте
ему ровно два файла: `brief.md` и `spec.md`. Манифест не давайте — иначе он проверит
вашу работу вашим же конспектом. Спросите: что заказано, но не покрыто; что покрыто
наполовину; что есть в спеке, но в брифе не заказывалось.

Его вывод положите в JSON и подайте:

```
chekan gate G2 --coverage coverage.json
```

Формат: `{"unresolved": ["пропуск, который вы не закрыли"], "notes": ["..."]}`.
Пустой `unresolved` означает, что все находки вы разобрали, а не что читатель молчал.
