server-monitor-manager/agents/hermes/inbox/from-smm-deliverables/Старые задачи/smm-hermes-task-alpha10-and-docs-2026-08-10.md
Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18
Задания, отчёты и патчи, лежавшие в 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>
2026-08-18 14:19:54 +07:00

7 KiB
Raw Permalink Blame History

Hermes: выпуск alpha.10, синхронизация документации, уборка веток

Состояние

main @ 61471f0. Открытых PR нет. Все известные дефекты закрыты, включая семантическое сравнение версий (#36).

Горизонт 0 закрыт кодом полностью. Единственный незакрытый пункт — физическая приёмка на реальной топологии, её выполняет владелец. Задание ниже относится к завершению Горизонта 0, а не к Горизонту 1; новых функций не добавляется.

Ветка: hermes/release-alpha10.


Часть 1 — выпустить v0.1.0-alpha.10

Причина выпускать именно сейчас: в main появилась запись установленной версии и семантическое сравнение (#36). Пока Hub владельца стоит на alpha.7, где записи версии нет, защита от отката и проверка совместимости работать не могут — им не с чем сравнивать. Обновление на alpha.10 создаёт эту запись и включает обе проверки с чистого листа.

  1. Тег v0.1.0-alpha.10 на текущий main, push через git push.
  2. Дождаться Release pipeline и убедиться, что в релизе присутствуют: bootstrap и его .sha256, оба tar.gz и их .sha256, три SBOM, MSIX, smm-setup.sh и smm-setup.sh.sha256, server-monitor-manager-manifest.json и server-monitor-manager-manifest.sig.
  3. Проверить, что DEFAULT_RELEASE_TAG в deploy/smm-setup.sh соответствует выпускаемому тегу — этого требует docs/release-policy.md. Сейчас там v0.1.0-alpha.9.
  4. Тег не двигать ни при каких обстоятельствах. Ошибка в сборке исправляется следующим тегом — правило записано в docs/release-policy.md.

Часть 2 — привести документацию в соответствие с кодом

В roadmap несколько пунктов отмечены открытыми, хотя реализованы. Проект держится на правиле «документация не описывает несуществующее»; обратная ошибка не менее вредна, потому что скрывает готовность.

Проверить и, где подтвердится, отметить выполненными:

  • Этап 7, «добавить криптографическую подпись compatibility manifest для production release» — в linux-release.yml cosign используется, manifest подписывается, .sig публикуется;
  • Этап 3, физический acceptance — оставить открытым, он действительно не выполнялся;
  • пройти по остальным пунктам Этапов 28 и сверить с фактическим состоянием; отмечать только то, что подтверждается кодом или тестом, а не намерением.

Отдельным пунктом: синхронизировать переводы README (Этап 6). Одиннадцать переводов содержат устаревший релиз-статус. Достаточно привести раздел статуса и номер версии; переводить новые разделы целиком не требуется, но расхождение по версии недопустимо.

Часть 3 — убрать слитые ветки с remote

Полностью слиты в main и подлежат удалению:

antigravity/cert-lifecycle
antigravity/repo-hygiene
antigravity/reproducible-builds
docs/product-horizons-and-integration
feat/monitor-role
hermes/monitor-snapshot-contract
hermes/release-single-writer

Не трогать — не слиты, требуют отдельного решения:

antigravity/repo-hygiene-updates      закрытый PR #34, оставить как след
antigravity/signed-delivery-queue-a   проверить, вошло ли всё в main
hermes/monitor-contract-red-proof     проверить назначение
hermes/release-alpha.6                историческая
hermes/release-artifact-path-fix      проверить, вошло ли в main
hermes/sprint1-desktop-security       историческая
hermes/sprint1-server-security        историческая
hermes/task2-b-link-reconciliation    историческая

По четырём «проверить» — либо убедиться, что содержимое в main, и удалить, либо объяснить в отчёте, почему ветка нужна.

Часть 4 — полный reboot настоящих Debian VM

Открытый пункт Этапа 7. Сейчас Debian проверяется в privileged systemd-контейнерах: они перезапускаются, но собственного ядра не имеют, поэтому reboot как таковой не проверен. docs/linux-platform-matrix.md честно называет это незакрытым критерием.

Добавить в матрицу настоящую Debian VM с полным reboot и проверкой, что после загрузки поднимаются Control, WireGuard, firewall-таблица и Agent. Если на GitHub-hosted runner это недостижимо, зафиксировать в docs/linux-platform-matrix.md конкретную причину и то, чем это компенсируется, — вместо бессрочно открытого пункта.


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

  • v0.1.0-alpha.10 выпущен с полным набором ассетов, тег не двигался;
  • DEFAULT_RELEASE_TAG совпадает с тегом;
  • roadmap отражает фактическое состояние, физический acceptance остаётся открытым;
  • переводы README не противоречат текущей версии;
  • слитые ветки удалены, по неслитым дано решение;
  • по Debian VM либо появилась проверка, либо в документации записана причина и компенсация;
  • CI зелёный.

Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему.