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

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 со ссылками, не запускалось и почему. Отдельным разделом — вывод по нестабильности теста, если она подтвердится.