# Antigravity: сузить PR #37 до своей области и довести до зелёного

## Что получилось

Главное требование выполнено: **`Release Verification` зелёный против `v0.1.0-alpha.9`**. Замена `gh` на `curl` устранила конфликт с изоляцией каталога — теперь проверка идёт тем же путём, которым идёт живой пользователь: публичный `curl`, `sha256sum`, `cosign`, без токена и без клона репозитория.

Коммит `19bface` сделан ровно в границах:

```
.github/workflows/release-verification.yml
tests/release-verification/run-negative-tests.sh
tests/release-verification/run-positive-installation.sh
```

Это тот случай, ради которого workflow и создавался, и он отвечает на главный вопрос: поставка проверку проходит.

Ветка: продолжать `antigravity/release-verification-fix`.

---

## 1. Убрать коммит `45b1ad3` из PR целиком

Второй коммит выходит за границы задания полностью — ни один его файл не относится к вашей области:

```
README.md
docs/i18n/*.md                                   (12 переводов)
deploy/smm-setup.sh
tests/bootstrap/test-manifest-verification.sh    (−17 строк)
tests/bootstrap/test-release-contract.sh
```

`deploy/**`, переводы и `tests/bootstrap/**` принадлежат Hermes; он же владеет версией релиза. Сейчас версию бампят двое одновременно — в `main` его `Bump version to v0.1.0-alpha.11`, в вашем коммите бамп до alpha.12. Два сожжённых тега подряд получились в том числе из-за этого.

Удаление `tests/bootstrap/test-manifest-verification.sh` разберу отдельно, потому что вывод неочевидный.

## 2. Про удалённый тест — направление верное, обоснование нет

Тест «Real alpha.8 manifest fallback matching» действительно ронял релизный пайплайн и действительно подлежит замене. Но не по той причине, по которой он удалён.

Я проверил напрямую: в релизе `v0.1.0-alpha.8` **файла `server-monitor-manager-manifest.json` не существует**, есть только осиротевший `.sig` на 96 байт. Manifest v2 впервые появился в alpha.9. Тест проверяет совместимость с артефактом, которого в том релизе никогда не было — недействительна посылка, а не код.

Разница существенная. Удаление «чтобы разблокировать релиз» — тот же образ действий, что и попытка снять аналайзеры ради зелёного CI. Удаление «потому что проверяем несуществующее» — обоснованное решение, и оно требует замены, а не просто изъятия: сценарий обновления Hub со старого формата на подписанный релиз реален, у владельца сейчас стоит `alpha.7`.

Замену делает Hermes — синтетической фикстурой формата v1 вместо скачивания живого релиза по сети. Вам этот файл не трогать.

## 3. Разобраться с красным `build-and-test`

PR #37 красный: падает `ControlStoreTests.LinkServiceAppliesPersistedStatesAndPublishesEvents`, 119 из 120 проходят. Исключение возникает в `ControlStore.CreateLinkMutationAsync` через `LinkService.CreateAsync`.

На `main` при том же коммите `5349533` этот тест проходит. Значит либо ветка что-то задела, либо тест нестабилен.

Определить, что именно:

- если после удаления `45b1ad3` тест зеленеет — причина была в нём, зафиксировать в отчёте, что именно ломало;
- если падает и без него — тест нестабилен, и это отдельная находка. Прогнать несколько раз, определить условие, описать в `REPORT.md`. Нестабильный тест в control plane — не мелочь: он маскирует настоящие регрессии.

Не «перезапустить до зелёного» и не пометить `Skip`.

---

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

- в PR остаётся один коммит `19bface`; `git diff --name-only main` содержит ровно три файла области;
- `build-and-test` зелёный, причина прежнего падения названа в отчёте;
- `Release Verification` по-прежнему зелёный против `v0.1.0-alpha.9`, ссылка на прогон;
- негативные проверки отвергают все четыре случая: изменённый архив, подменённый хэш, отсутствующая подпись, чужая identity;
- `actionlint` чист;
- PR не смержен до зелёного CI; защита ветки теперь этого и не позволит.

## Отчёт

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