Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в домашней папке, перенесены в agents/. Разложено по агентам там, где имя файла позволяло определить автора; остальное — в _salvage-2026-08-18/ и разбирается вручную. Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных рабочих копий: она существовала только на диске. Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
7.6 KiB
Правила работы — 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 не трогать.