# Antigravity: проверка опубликованного релиза установкой

## Состояние

`main` @ `61471f0`. Открытых PR нет. Очередь B подписанной поставки слита (#35), все замечания по ней закрыты.

Задание относится к завершению Горизонта 0 — это проверка того, что уже сделано, а не новая функциональность. Гейт горизонта не нарушается.

Ветка: `antigravity/release-verification`.

---

## Часть 1 — установка из опубликованного релиза как проверка в CI

### Зачем

Вся цепочка поставки собрана: manifest v2, подпись cosign, проверка в bootstrap и в Desktop, воспроизводимые сборки. Но **ни один автоматический тест не устанавливает систему из фактически опубликованного релиза.**

Цена этого пробела уже известна. При первой живой установке нашлись подряд:

- `alpha.8` был опубликован вообще без Linux-архивов — единственной поддерживаемой серверной платформы;
- `verify_archive` искал в manifest ключ `ServerMonitorManager-linux-x64.tar.gz`, тогда как ассет называется `server-monitor-manager-linux-x64.tar.gz`, и захардкоженную архитектуру — то есть проверка подписи ломала штатную установку;
- release-workflow трижды падали на CycloneDX и путях артефактов.

Ни одно из этого не ловилось зелёным CI, потому что CI проверяет **сборку из дерева**, а не **релиз как продукт**. Тесты работают с локально собранным архивом; настоящие имена ассетов, настоящий manifest и настоящая подпись в них не участвуют.

### Что сделать

Новый workflow, запускаемый после публикации релиза и вручную через `workflow_dispatch` с параметром тега.

На чистом runner'е, без доступа к дереву исходников кроме самого скрипта установки:

1. Скачать `smm-setup.sh` из релиза по тегу и проверить его контрольную сумму по опубликованному `.sha256`.
2. Запустить `smm-setup.sh hub <локальный-хост>` — то есть пройти ровно тот путь, которым пользуется владелец: загрузка bootstrap и архива из релиза, проверка контрольных сумм, проверка подписи manifest, `preflight`, `verify-release`, установка Control, `mesh-init`.
3. Проверить, что Control активен и `/healthz` отвечает.
4. Выпустить код Node через `node-code`, установить Node на той же машине, дождаться активного `ochenstarik-smm-agent.service` и выданного сертификата.
5. Проверить `install-monitor`: пользователь создан, forced command выдаёт снимок, поля совпадают с `tests/contracts/monitor-snapshot-v1.txt`.
6. Снять всё через `uninstall-*` и убедиться, что следов не осталось.

Требования:

- скрипт установки берётся **из релиза**, а не из рабочего дерева — иначе проверяется не то, что получит пользователь;
- проверка подписи не обходится: `SMM_ALLOW_UNSIGNED` в этом прогоне не используется;
- прогон падает, если в релизе отсутствует любой ожидаемый ассет.

### Негативные проверки

Отдельными шагами, каждый обязан завершиться отказом установки:

- архив с изменённым байтом;
- manifest с подменённым хэшем без переподписи;
- manifest без файла подписи;
- подпись, сделанная другой identity.

Первые три уже покрыты юнит-тестами против синтетических данных; здесь они проверяются на настоящем релизе и настоящем cosign.

---

## Часть 2 — проверка того, что релиз полон

Отдельный шаг того же workflow: сверить набор ассетов релиза с ожидаемым списком и упасть при расхождении.

```
ochenstarik-server-monitor-manager.sh(+.sha256)
server-monitor-manager-linux-x64.tar.gz(+.sha256)
server-monitor-manager-linux-arm64.tar.gz(+.sha256)
server-monitor-manager-linux-x64-sbom.json
server-monitor-manager-linux-arm64-sbom.json
server-monitor-manager-win-x64-sbom.json
ServerMonitorManager-win-x64.msix
ServerMonitorManager-test-signing.cer
SHA256SUMS
smm-setup.sh(+.sha256)
server-monitor-manager-manifest.json
server-monitor-manager-manifest.sig
```

Ровно этой проверки не хватало, когда `alpha.8` вышел без Linux-архивов и это заметил человек, а не CI.

---

## Границы

Hermes параллельно выпускает `v0.1.0-alpha.10`, правит `deploy/smm-setup.sh` (значение `DEFAULT_RELEASE_TAG`), roadmap, переводы README и удаляет слитые ветки. Может также добавить Debian VM в матрицу.

**Не трогать:** `deploy/**`, `docs/roadmap.md`, `docs/i18n/**`, `docs/linux-platform-matrix.md`.

Ваша область — новый workflow и вспомогательные скрипты проверки под `tests/`. Если для задачи потребуется изменить существующий workflow, согласовать: релизный пайплайн ведёт Hermes, и три починки подряд за день случились именно из-за правок с двух сторон.

## Чего опасаться

Новый workflow по определению не запускается на pull request — он привязан к публикации релиза. Зелёный PR про него ничего не докажет, ровно как было с `permissions` и `locked-mode`.

Поэтому обязательно: `actionlint` на новом файле с выводом в отчёт и прогон через `workflow_dispatch` на своей ветке против уже существующего тега `v0.1.0-alpha.9`. Это заодно ответит на главный вопрос — прошла бы проверка на реальном релизе или нет.

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

- новый workflow выполняет полный цикл установки из опубликованного релиза и снимает её;
- четыре негативные проверки отвергают установку;
- отсутствие любого ожидаемого ассета роняет прогон;
- `SMM_ALLOW_UNSIGNED` в основном прогоне не используется;
- `actionlint` чист, вывод приложен;
- выполнен `workflow_dispatch`-прогон против `v0.1.0-alpha.9`, ссылка в отчёте;
- `git diff --name-only main` не содержит файлов из списка границ;
- PR не смержен.

## Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему. Описание PR заполнять после завершения CI.