server-monitor-manager/agents/antigravity/inbox/from-smm-deliverables/Старые задачи/smm-antigravity-task-pr37-narrow-2026-08-11.md
Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18
Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в
домашней папке, перенесены в agents/. Разложено по агентам там, где имя
файла позволяло определить автора; остальное — в _salvage-2026-08-18/
и разбирается вручную.

Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных
рабочих копий: она существовала только на диске.

Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не
попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 14:19:54 +07:00

73 lines
6.1 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

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