server-monitor-manager/agents/hermes/notes/salvage-2026-08-18/hermes-desktop-attachments/desktop-attachments/b3-measurability-wire-ci.md

Правила работы — 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. Ничего в сервисах не трогать.