# 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 со ссылками, не запускалось и почему.