server-monitor-manager/agents/hermes/inbox/from-smm-deliverables/Старые задачи/smm-hermes-task-alpha14-and-oneshot-2026-08-13.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

5.7 KiB
Raw Permalink Blame History

Hermes: выпустить alpha.14 и дать установку одной командой

Состояние

  • main @ b0ad40c, открытых PR нет, на remote одна ветка, CI зелёный;
  • deploy/smm-setup.sh по умолчанию указывает на v0.1.0-alpha.14, которого не существует — опубликован alpha.13. Установка по документации сейчас упирается в 404;
  • alpha.12 и alpha.13 содержат подпись без сертификата и потому непроверяемы; по политике неизменяемости дополнить их нельзя.

Ветка: hermes/release-alpha14-publish.


Часть 1 — выпустить v0.1.0-alpha.14 · блокирует владельца

Это первый релиз, где подпись проверяема целиком: manifest.json, manifest.sig и manifest.pem публикуются вместе, verify_archive требует все три.

  1. Сначала workflow_dispatch-прогон Release pipeline на своей ветке, до тегирования. Два сожжённых тега подряд, alpha.10 и alpha.11, получились ровно потому, что этот шаг пропускали.
  2. Создать и запушить тег v0.1.0-alpha.14.
  3. Проверить набор ассетов — семнадцать позиций, включая server-monitor-manager-manifest.pem. Список зафиксирован в tests/release-verification/verify-assets.sh, сверяться с ним.
  4. Убедиться, что Release Verification отработал автоматически по событию release: published и зелёный. Это главный результат: впервые проверка пройдёт против настоящего подписанного релиза, а не против ветки.

Если Release Verification покажет дефект релиза — это успех задачи. Зафиксировать находку и не «чинить» её ослаблением проверки или флагом SMM_ALLOW_UNSIGNED.

Часть 2 — установка одной командой

Сейчас оператор вручную скачивает семь файлов: установщик и его контрольную сумму, архив и его контрольную сумму, manifest, подпись и сертификат. Пропустить любой из трёх файлов подписи — значит получить отказ verify-release. Это лишний источник ошибок в самой ответственной операции.

Добавить в deploy/smm-setup.sh команду, которая делает это сама:

smm-setup.sh install-hub  PUBLIC_HOST [HTTPS_PORT] [WG_PORT]
smm-setup.sh install-node

Поведение:

  • определить архитектуру и выбрать соответствующий tar.gz;
  • скачать в рабочий каталог архив, его .sha256, manifest, подпись и сертификат;
  • сверить контрольную сумму архива;
  • выполнить install-control и mesh-init либо install-node;
  • при отсутствии любого из трёх файлов подписи — отказ с внятным сообщением, а не тихий переход на .sha256.

Существующий сквозной режим (smm-setup.sh <любая-команда-bootstrap>) сохранить: он используется в тестах и в приёмке.

После этого обновить docs/linux-bootstrap.md: показать короткий путь как основной, длинный оставить как ручной.

Часть 3 — зафиксировать судьбу непроверяемых релизов

В docs/release-policy.md записать: v0.1.0-alpha.10 и v0.1.0-alpha.11 — теги без опубликованного релиза, номера не переиспользуются; v0.1.0-alpha.12 и v0.1.0-alpha.13 опубликованы с подписью, но без сертификата и потому проверке не поддаются; первым полностью проверяемым релизом является v0.1.0-alpha.14.

Это нужно не для порядка, а чтобы через полгода никто не пытался объяснить, почему подпись двух релизов не сходится.


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

  • workflow_dispatch-прогон выполнен до тегирования, ссылка в отчёте;
  • v0.1.0-alpha.14 опубликован, набор ассетов совпадает с verify-assets.sh;
  • Release Verification отработал по событию публикации и зелёный, ссылка в отчёте;
  • install-hub и install-node ставят систему без ручного скачивания файлов подписи;
  • отсутствие manifest, подписи или сертификата даёт отказ, а не переход на .sha256;
  • судьба alpha.10alpha.13 записана в release-policy;
  • всё через PR, CI зелёный.

Отчёт

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