Задания, отчёты и патчи, лежавшие в 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>
5.7 KiB
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 требует все три.
- Сначала
workflow_dispatch-прогонRelease pipelineна своей ветке, до тегирования. Два сожжённых тега подряд, alpha.10 и alpha.11, получились ровно потому, что этот шаг пропускали. - Создать и запушить тег
v0.1.0-alpha.14. - Проверить набор ассетов — семнадцать позиций, включая
server-monitor-manager-manifest.pem. Список зафиксирован вtests/release-verification/verify-assets.sh, сверяться с ним. - Убедиться, что
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.10–alpha.13 записана в release-policy;
- всё через PR, CI зелёный.
Отчёт
Раздельно: локально, в CI со ссылками, не запускалось и почему.