Правила работы — `AGENTS.md` в корне репозитория, копия в
`C:\Users\Ochenstarik\kagent-tasks\AGENTS.md`.

Рабочий каталог: `C:\Users\Ochenstarik\kagent\.worktrees\t_e15a6516`
Ветка: `wt/kagent-091-measurability`
Выполняется после задачи `b2-measurability-sanitize.md`.

## Предусловие

Ветка отпочкована от старого `main`, в ней нет работы этапа 0.9.0: нет `pnpm-lock.yaml`, нет
job `python`, нет исправлений gateway и control-plane. Пока PR #3 не влит в `main`, сборка
этой ветки будет красной по чужим причинам.

**Начинать только после того, как PR #3 смержен.** Первым действием — `git fetch origin` и
rebase ветки на `origin/main`. Верификация на устаревшей базе не даёт права на слияние.

Если PR #3 ещё не влит — останови работу и сообщи. Не обходить, не копировать чужие правки
в свою ветку.

## Проблема

Три скрипта — `roadmap_status.py`, `drift_check.py`, `eval_suite.py` — написаны, но не
вызываются ниоткуда. Это ровно тот дефект, который `drift_check.py` создан обнаруживать:
код присутствует в дереве и недостижим ни из одной точки входа.

Пока они не в непрерывной интеграции, вычисляемый статус остаётся декларацией.

## 1. Подключить к непрерывной интеграции

Добавить в `.github/workflows/ci.yml`:

- шаг `python scripts/drift_check.py` в существующий job `python`. Сборка падает при
  обнаружении расхождения. Список проверок — из спецификации, раздел 41.5: заявленная
  возможность без проходящего доказательства; модуль в дереве, недостижимый ни из одной
  точки входа; задокументированный endpoint, отсутствующий в таблице маршрутов;
  задокументированная переменная окружения, которая нигде не читается; пользовательское
  изменение без записи в `CHANGELOG.md`; архитектурное изменение без ADR;
- отдельный job `measurability`: выполняет `roadmap_status.py`, публикует полученный
  `ROADMAP.md` как артефакт сборки и падает, если сгенерированный файл отличается от
  закоммиченного. Это и есть механизм, запрещающий ручную правку статусов;
- `eval_suite.py` запускать в режиме, не требующем поставщика моделей. Пока набор состоит из
  черновых случаев, job проверяет только разбор контрактов и целостность набора, а не
  прохождение случаев.

## 2. Первый прогон будет красным

Ожидаемо и правильно: `drift_check.py` на текущем дереве обязан найти как минимум четыре
недостижимых модуля —

```
services/nats/src/events.py
services/auth/src/totp.py
services/control-plane/src/db.ts
packages/contracts/src/reasoning.ts
```

Ни один из них не импортируется ниоткуда.

**Не чинить эти модули в этой задаче и не ослаблять проверку, чтобы сборка позеленела.**
Правильное действие: убедиться, что проверка их находит, зафиксировать список в отчёте и
завести отдельную задачу на решение по каждому — подключить или удалить.

Чтобы ветку можно было влить, добавь в `drift_check.py` файл известных расхождений
(`docs/known-drift.json`) с ограниченным сроком: запись содержит путь, причину, дату и
задачу, в которой расхождение снимается. Запись без задачи или с истёкшим сроком роняет
сборку. Список должен только сокращаться.

## 3. Что не входит

- наполнение случаев оценки настоящими снимками репозиториев;
- метрики автономности и гейт релиза по ним;
- исправление найденных расхождений.

## Критерий приёмки

- ветка перебазирована на `main`, содержащий работу 0.9.0;
- `drift_check.py` вызывается из CI и находит все четыре недостижимых модуля — список
  привести в отчёте;
- `roadmap_status.py` вызывается из CI, расхождение сгенерированного и закоммиченного
  `ROADMAP.md` роняет сборку;
- проверено, что ручная правка статуса в `ROADMAP.md` действительно роняет сборку: сделать
  правку, показать красный прогон, откатить;
- прогон непрерывной интеграции зелёный при пустом списке известных расхождений сверх
  четырёх зафиксированных;
- ссылка на прогон приложена.

## Границы

`.github/workflows/ci.yml`, `scripts/*`, `docs/capabilities.json`, `docs/known-drift.json`,
`ROADMAP.md`. Ничего в сервисах не трогать.