23eb3f5233
Задания, отчёты и патчи, лежавшие в 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>
78 lines
6.9 KiB
Markdown
78 lines
6.9 KiB
Markdown
# Hermes: починить тест совместимости, выпустить alpha.12, закрепить владение релизом
|
||
|
||
## Состояние
|
||
|
||
- `main` @ `5349533`; защита ветки включена — обязательный PR, обязательные статусы `build-and-test` и `build`, force-push запрещён. Это сделано, дальше всё идёт через PR;
|
||
- опубликован по-прежнему только `v0.1.0-alpha.9`;
|
||
- теги `v0.1.0-alpha.10` и `v0.1.0-alpha.11` созданы, но релизы по ним **не опубликованы** — `Release pipeline` оба раза упал в job `bootstrap`.
|
||
|
||
Ветка: `hermes/alpha8-compat-fixture`.
|
||
|
||
---
|
||
|
||
## Часть 1 — тест совместимости с alpha.8 · блокирует все релизы
|
||
|
||
### Диагноз готов, повторять не нужно
|
||
|
||
`Release pipeline` на теге `v0.1.0-alpha.11`, job `bootstrap`, шаг `Validate bootstrap`:
|
||
|
||
```
|
||
Test 1..4: PASS
|
||
Test 5: Real alpha.8 manifest fallback matching (REQUIRES_NETWORK)
|
||
FAIL: Alpha.8 real release verification failed
|
||
```
|
||
|
||
Я скачал ассеты `v0.1.0-alpha.8` напрямую. **Файла `server-monitor-manager-manifest.json` в этом релизе нет.** Присутствует только `server-monitor-manager-manifest.sig` размером 96 байт — подпись без подписываемого файла. В alpha.8 лежал `server-monitor-manager-bootstrap-manifest.json`, то есть формат v1; manifest v2 впервые появился в alpha.9.
|
||
|
||
Значит тест проверяет обратную совместимость с артефактом, которого в том релизе никогда не существовало. **Дефекта в коде нет — недействительна посылка теста.**
|
||
|
||
### Что сделать
|
||
|
||
1. Убрать сетевую зависимость из релизного пайплайна. Тест, скачивающий чужой релиз по сети, роняет выпуск версии при любом сетевом сбое или изменении набора ассетов в прошлом. Релизный job не должен зависеть от внешнего состояния.
|
||
|
||
2. Заменить его **синтетической фикстурой формата v1**: локально сгенерированный набор в том виде, в каком его выпускали до alpha.9 — `server-monitor-manager-bootstrap-manifest.json`, `.sha256` рядом с архивом, без manifest v2 и без подписи. Проверять на ней, что установка проходит по пути `SMM_ALLOW_UNSIGNED=1` и отвергается без него.
|
||
|
||
Сценарий реальный и его нельзя терять: Hub владельца стоит на `alpha.7`, и обновляться он будет именно со старого формата на подписанный.
|
||
|
||
3. Фикстуру положить рядом с `tests/fixtures/control-v0.1.0-alpha.7.db` — там уже принят такой подход для схемы БД.
|
||
|
||
**Не удалять проверку целиком.** Antigravity в PR #37 уже сделал коммит с её удалением; я потребовал этот коммит из PR убрать. Владение `tests/bootstrap/**` и релизным пайплайном остаётся за вами.
|
||
|
||
### Заметка, менять ничего не нужно
|
||
|
||
В релизе alpha.8 лежит осиротевший `manifest.sig` без `manifest.json`. По `docs/release-policy.md` ассеты опубликованного релиза неизменяемы, поэтому трогать нельзя. Стоит одной строкой упомянуть это в release-policy как известную аномалию, чтобы следующий человек не искал причину.
|
||
|
||
---
|
||
|
||
## Часть 2 — выпустить `v0.1.0-alpha.12`
|
||
|
||
`alpha.10` и `alpha.11` сожжены: теги существуют, релизов по ним нет, переиспользовать по собственной политике нельзя.
|
||
|
||
1. После части 1 прогнать `Release pipeline` через `workflow_dispatch` на своей ветке — убедиться, что job `bootstrap` проходит **до** тегирования. Два сожжённых тега подряд получились именно потому, что этого шага не делали.
|
||
2. Создать `v0.1.0-alpha.12`, запушить тегом.
|
||
3. Проверить полноту набора: bootstrap и `.sha256`, оба `tar.gz` и `.sha256`, три SBOM, MSIX, `smm-setup.sh` и `.sha256`, `server-monitor-manager-manifest.json` и `.sig`.
|
||
4. В `docs/release-policy.md` зафиксировать судьбу `alpha.10` и `alpha.11`: теги существуют, релизы не публиковались, номера не переиспользуются. Пустые теги без объяснения — источник будущей путаницы.
|
||
|
||
---
|
||
|
||
## Часть 3 — единоличное владение версией и релизными файлами
|
||
|
||
Сейчас версию бампят двое. `main` содержит ваш `Bump version to v0.1.0-alpha.11`, а в PR #37 Antigravity бампит до alpha.12 и правит `deploy/smm-setup.sh`, README и все 12 переводов. Два сожжённых тега — прямое следствие.
|
||
|
||
Закрепить в `docs/release-policy.md`: версию в исходниках, `deploy/**`, релизные workflow и переводы README меняет только владелец релиза. Остальным — через запрос в отчёте.
|
||
|
||
---
|
||
|
||
## Критерий приёмки
|
||
|
||
- job `bootstrap` проходит; сетевых зависимостей в релизном пайплайне нет;
|
||
- совместимость со старым форматом покрыта синтетической фикстурой, сценарий `SMM_ALLOW_UNSIGNED` проверяется в обе стороны;
|
||
- `workflow_dispatch`-прогон выполнен **до** тегирования, ссылка в отчёте;
|
||
- `v0.1.0-alpha.12` опубликован с полным набором ассетов;
|
||
- судьба alpha.10, alpha.11 и аномалия alpha.8 записаны в release-policy;
|
||
- владение релизными файлами закреплено документально;
|
||
- всё через PR.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: локально, в CI со ссылками, не запускалось и почему.
|