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

## Состояние

`release-verification.yml` находится в `main`. Структура задания выполнена: триггеры `release: published` и `workflow_dispatch` с входным тегом, шаги проверки набора ассетов, изоляции рабочего каталога, положительной установки и негативных проверок, три отдельных скрипта под `tests/release-verification/`, `permissions: contents: read`.

Но **оба выполненных прогона `workflow_dispatch` против `v0.1.0-alpha.9` завершились отказом**, и workflow при этом оказался в `main`.

Ветка: `antigravity/release-verification-fix`, от текущего `main`.

---

## 1. Почему падает

Прогон `31419452912`, шаг `Run Positive Installation`:

```
rm -rf * .git
...
Running positive installation test for v0.1.0-alpha.9...
failed to run git: fatal: not a git repository (or any of the parent directories): .git
##[error]Process completed with exit code 1.
```

Замысел верен: рабочий каталог стирается вместе с `.git`, чтобы установка шла из релиза, а не из дерева исходников. Именно это и требовалось.

Ошибка в средстве. `run-positive-installation.sh` вызывает `gh release download`, а `gh` без явного `--repo` определяет репозиторий по git-контексту, который только что удалён. Инструмент конфликтует с изоляцией, ради которой всё и делается.

## 2. Как чинить — и почему именно так

Формально хватило бы передать `--repo ochenstarik-ui/server-monitor-manager` во все вызовы `gh`. Но правильнее убрать `gh` из проверки совсем.

Реальный пользователь на чистом сервере не имеет ни `gh`, ни `GH_TOKEN`, ни клона репозитория. Он выполняет ровно то, что описано в `docs/linux-bootstrap.md`: `curl` по публичному адресу релиза, `sha256sum`, затем `cosign` для подписи. Проверка, использующая `gh` с токеном, тестирует путь, которым никто не пользуется, и не заметит поломки публичной загрузки.

Требование: **в положительном сценарии использовать только те средства, которые есть у пользователя** — `curl`, `sha256sum`, `cosign`. Токен не использовать. Если какой-то ассет недоступен анонимным `curl`, это дефект релиза, и проверка обязана его показать.

Шаг `Verify Assets List` может продолжать пользоваться `gh` — он выполняется до изоляции и решает другую задачу.

## 3. Что вернуть в изолированный каталог

Сейчас после очистки копируется `tests/contracts/monitor-snapshot-v1.txt`. Это правильно: контракт задаёт ожидаемые значения, а не участвует в установке.

Зафиксировать это явным правилом в комментарии скрипта: из репозитория возвращаются **только ожидания** — контракты, списки, эталонные значения. Ничто исполняемое: ни установщик, ни bootstrap, ни архивы. Иначе изоляция перестаёт что-либо доказывать, а понять это по диффу будет уже нельзя.

## 4. Обязательное доказательство

Задание считается выполненным только при **зелёном прогоне `workflow_dispatch` против `v0.1.0-alpha.9`**, ссылка на прогон в отчёте.

Это тот самый случай, ради которого workflow и создавался: прогон против настоящего опубликованного релиза отвечает на вопрос, прошла бы поставка проверку или нет. Прогон против alpha.9 ценен ещё и тем, что этот релиз собран до всех недавних правок пайплайна.

Если прогон покажет дефект **релиза**, а не проверки — это успех задачи, а не провал. Зафиксировать находку отдельно и не «чинить» её ослаблением проверки.

## 5. Процесс

Изменения провести **через pull request**, не прямым коммитом в `main`.

Красный workflow попал в `main` потому, что за последние сутки шесть коммитов легли туда напрямую, минуя PR и гейт CI. Hermes параллельно включает защиту ветки: обязательный PR, обязательные статусы, запрет force-push. После этого прямой путь просто закроется.

Ветку сделать от текущего `main` — она сейчас отстаёт, в `main` вошли синхронизация переводов и правки release contract.

## Границы

Hermes ведёт `deploy/**`, `linux-release.yml`, `docs/release-policy.md`, roadmap и переводы; он же выпускает `v0.1.0-alpha.11` и чинит job `bootstrap` в релизном пайплайне.

Ваша область: `.github/workflows/release-verification.yml` и `tests/release-verification/**`. Остального не касаться; если потребуется — описать в `REPORT.md`.

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

- положительный сценарий использует только `curl`, `sha256sum` и `cosign`, без `gh` и без токена;
- в изолированный каталог возвращаются только файлы ожиданий, правило записано в скрипте;
- **зелёный прогон `workflow_dispatch` против `v0.1.0-alpha.9`**, ссылка в отчёте;
- негативные проверки по-прежнему отвергают: изменённый архив, подменённый хэш в manifest, отсутствующую подпись, подпись другой identity;
- отсутствие любого ожидаемого ассета роняет прогон;
- `actionlint` чист, вывод приложен;
- изменения внесены через PR, не прямым коммитом;
- `git diff --name-only main` не выходит за границы.

## Отчёт

Раздельно: локально, в CI со ссылками, не запускалось и почему. Описание PR заполнять после завершения CI. Если прогон против alpha.9 обнаружит дефект релиза — вынести отдельным разделом.