23eb3f5233
Задания, отчёты и патчи, лежавшие в 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>
67 lines
5.7 KiB
Markdown
67 lines
5.7 KiB
Markdown
# 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.10–alpha.13 записана в release-policy;
|
||
- всё через PR, CI зелёный.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: локально, в CI со ссылками, не запускалось и почему.
|