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

Рабочий каталог: `C:\Users\Ochenstarik\kagent\.worktrees\t_e15a6516`
Ветка: `wt/kagent-091-measurability`

## На чём остановились

Работа по этапу 0.9.1 сделана наполовину и **не закоммичена**. В рабочем каталоге:

```
?? scripts/roadmap_status.py       вычисление статуса roadmap из capabilities.json
?? scripts/drift_check.py          проверка расхождения заявленного и наблюдаемого
?? scripts/eval_suite.py           запуск набора сквозных случаев
?? docs/capabilities.json          реестр возможностей и доказательств
?? eval/                           пять случаев, baseline.json
?? docs/adr/0008-measurability-and-computed-status.md
?? docs/adr/0016-spec-drift-and-eval-integrity.md
?? tests/unit/, pyproject.toml, uv.lock, services/gateway/Cargo.lock
 M .env.example
```

Пока это не закоммичено, любая чистка каталога уничтожает работу.

Задача — привести сделанное в пригодный вид. Подключение к непрерывной интеграции и
наполнение случаев вынесено в следующую задачу.

## 1. Зафиксировать без потерь

Закоммитить три скрипта, `docs/capabilities.json`, каталог `eval/` и `tests/unit/` как есть,
одним коммитом с пометкой, что содержимое дорабатывается в этой же задаче. Дальше правки
идут поверх, чтобы работа не пропала при первой же ошибке.

`services/gateway/Cargo.lock`, `uv.lock` и правки `.env.example` в этой задаче не нужны:
gateway ведётся в другой ветке, изменения окружения к измеримости не относятся. Не
коммитить.

## 2. Номера ADR заняты

Созданы `docs/adr/0008-measurability-and-computed-status.md` и
`docs/adr/0016-spec-drift-and-eval-integrity.md`. Номера **0008 и 0016 уже заняты** другими
решениями в открытом PR #2:

- `0008-platform-evaluation-suite.md` — набор оценки платформы и метрики автономности;
- `0016-computed-stage-status.md` — вычисляемый статус этапа и обнаружение расхождения.

Два файла с одним номером нарушают правило именования из `docs/adr/README.md` и при слиянии
дадут коллизию.

Оба существующих решения описывают ровно то, что реализуют новые файлы. Поэтому:

- удалить оба новых файла ADR;
- если в их текстах есть решения, которых нет в 0008 и 0016 — вынести только эти отличия в
  один новый ADR с номером `0021` и перечислить их в отчёте;
- реализация уже принятого решения нового ADR не требует.

## 3. Статус accepted проставлен исполнителем

Оба новых файла имеют `Status: accepted`. Решения принимает владелец проекта, а не
исполнитель. Если ADR-0021 всё же появится — статус `proposed`.

## 4. Реестр возможностей закрепляет непроверенные статусы

В `docs/capabilities.json` этапы 0.1–0.8 записаны как `complete`. Это те самые галочки,
против которых написано решение: они проставлены вручную и ничем не подтверждены. Известно,
что как минимум персистентность проектов и задач не работает, а часть модулей не
импортируется ниоткуда.

Реестр, зафиксировавший ложные статусы, отменяет смысл всей задачи.

Что сделать:

- убрать поле статуса из объявления этапов. Реестр объявляет **что должно быть доказано**,
  а не **что уже готово**;
- статус вычисляется `roadmap_status.py` из наличия доказательств; при отсутствии
  доказательства — `unverified`;
- для каждой возможности в реестре доказательство должно быть проверяемым: имя job
  непрерывной интеграции, случай из набора оценки, конкретный файл артефакта. Список
  существующих файлов доказательством не является;
- прогнать `roadmap_status.py` и приложить полученный вывод к отчёту. Ожидаемо, что
  большинство возможностей окажется `unverified` — это правильный результат, а не ошибка.

## 5. Случаи оценки пустые

`eval/cases/*/base.tar.gz` весят по 64 байта — это пустые архивы. Пять случаев объявлены,
снимков репозиториев в них нет, то есть набор не может быть выполнен.

Выбрать одно и сделать честно:

- либо наполнить один случай настоящим снимком и оставить его единственным рабочим, а
  остальные удалить до наполнения;
- либо оставить каталоги как объявление структуры, но пометить случаи как `draft` в
  `contract.json` и исключить из подсчёта, чтобы пустой набор не выглядел готовым.

Второй вариант дешевле и допустим при условии, что `eval_suite.py` не засчитывает `draft`.

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

- работа закоммичена, ничего не потеряно;
- в `docs/adr/` нет двух файлов с одинаковым номером;
- ни один ADR не имеет статуса `accepted`, проставленного исполнителем;
- `python scripts/roadmap_status.py` выполняется и печатает статусы, выведенные из
  доказательств, а не из объявленного поля;
- `python scripts/drift_check.py` выполняется и печатает список расхождений;
- ни один случай оценки не выглядит рабочим, не будучи таковым.

Вывод обеих команд приложить к отчёту.

## Границы

Только перечисленные файлы. Ветку не ребейзить, в CI ничего не подключать — это следующая
задача. Ничего в gateway и control-plane не трогать.