server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-release-verification-2026-08-10.md

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.