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>
95 lines
6.2 KiB
Markdown
95 lines
6.2 KiB
Markdown
# Hermes: выпустить alpha.11, починить bootstrap-job релиза, включить защиту ветки
|
||
|
||
## Состояние
|
||
|
||
- `main` @ `5349533` «Bump version to v0.1.0-alpha.11»;
|
||
- открытых PR нет;
|
||
- последний **опубликованный** релиз — `v0.1.0-alpha.9`;
|
||
- тег `v0.1.0-alpha.10` создан на `e8f771b`, но **релиз не опубликован**: `Release pipeline` упал в job `bootstrap`;
|
||
- Antigravity параллельно доделывает свою часть.
|
||
|
||
Ветка: `hermes/release-alpha11`.
|
||
|
||
---
|
||
|
||
## Часть 1 — починить job `bootstrap` в `Release pipeline` · блокирующее
|
||
|
||
Прогон по тегу `v0.1.0-alpha.10` (`31420461877`):
|
||
|
||
```
|
||
bootstrap: failure
|
||
publish-linux (linux-x64): success
|
||
publish-linux (linux-arm64): success
|
||
package-windows: success
|
||
manifest: skipped
|
||
```
|
||
|
||
В логе видно `PASS: Missing signature rejected`, затем `Process completed with exit code 1`. То есть негативные проверки подписи отработали частично, после чего шаг упал без внятного сообщения.
|
||
|
||
Следствие: `manifest` пропущен, релиз не создан, тег остался пустым.
|
||
|
||
Сделать:
|
||
|
||
1. Найти и исправить причину падения. Молчаливый `exit 1` без диагностики — сам по себе дефект: каждая проверка обязана печатать, что именно не сошлось.
|
||
2. Прогнать `Release pipeline` через `workflow_dispatch` на своей ветке до тегирования, чтобы убедиться, что job `bootstrap` проходит.
|
||
|
||
## Часть 2 — выпустить `v0.1.0-alpha.11`
|
||
|
||
Тег `v0.1.0-alpha.10` использовать повторно нельзя: `docs/release-policy.md` запрещает переиспользование и пересоздание опубликованных тегов, а тег создан и виден. Версия в исходниках уже поднята до alpha.11 — это правильный выход.
|
||
|
||
1. После части 1 создать `v0.1.0-alpha.11` и запушить тегом.
|
||
2. Убедиться, что в релизе присутствует полный набор: bootstrap и `.sha256`, оба `tar.gz` и `.sha256`, три SBOM, MSIX, `smm-setup.sh` и `.sha256`, `server-monitor-manager-manifest.json` и `.sig`.
|
||
3. В `docs/release-policy.md` добавить строку о судьбе `v0.1.0-alpha.10`: тег существует, релиз по нему не публиковался, номер не переиспользуется. Пустой тег без объяснения — источник будущей путаницы.
|
||
|
||
## Часть 3 — включить защиту ветки `main` · системная причина
|
||
|
||
`main` не защищён: `GET /branches/main/protection` возвращает 404.
|
||
|
||
С 10 августа шесть коммитов легли в `main` **напрямую, минуя PR**:
|
||
|
||
```
|
||
5349533 Bump version to v0.1.0-alpha.11
|
||
48d096a fix(ci): update release contract, remove backward compat test
|
||
e04037a docs: add Debian VM reboot constraint section
|
||
bb672a2 docs: sync translations and roadmap
|
||
e8f771b Merge branch 'hermes/release-alpha10'
|
||
7b322a6 Add release-verification workflow to main
|
||
```
|
||
|
||
До этого всё шло через PR — #32, #33, #35, #36. Результат отхода от правила: два коммита оставили `main` красным на сутки (падал `tests/bootstrap/test-release-contract.sh`), и это заметил не CI-гейт, а внешняя проверка.
|
||
|
||
Включить на `main`:
|
||
|
||
- обязательный pull request перед слиянием;
|
||
- обязательные проверки статуса: `build-and-test` (Linux) и `build` (Windows) как минимум;
|
||
- запрет force-push и удаления ветки;
|
||
- обязательная актуальность ветки относительно `main` перед слиянием.
|
||
|
||
Правило «один PR — одна тема, слияние после зелёного CI» существует с самого начала, но держалось на дисциплине. Оно должно держаться на настройке.
|
||
|
||
Записать это в `docs/release-policy.md` рядом с правилом неизменяемости тега.
|
||
|
||
## Часть 4 — проверка предыдущих частей задания
|
||
|
||
Из прошлого задания подтвердить в отчёте:
|
||
|
||
- roadmap: подпись manifest отмечена выполненной, физический acceptance остаётся открытым — **проверено, сделано**;
|
||
- Debian VM reboot: ограничение записано в документации — **проверено, сделано**;
|
||
- слитые ветки удалены — **проверено, осталось 7 из 15, все неслитые**;
|
||
- переводы README: в чём именно выражена синхронизация, какие файлы изменены.
|
||
|
||
---
|
||
|
||
## Критерий приёмки
|
||
|
||
- job `bootstrap` в `Release pipeline` проходит; каждая проверка при отказе печатает причину;
|
||
- `v0.1.0-alpha.11` опубликован с полным набором ассетов;
|
||
- судьба `v0.1.0-alpha.10` зафиксирована в `docs/release-policy.md`;
|
||
- `main` защищён: PR обязателен, статусы обязательны, force-push запрещён;
|
||
- правило записано в документации;
|
||
- `main` зелёный;
|
||
- всё, кроме настройки защиты ветки, проходит через PR.
|
||
|
||
## Отчёт
|
||
|
||
Раздельно: локально, в CI со ссылками, не запускалось и почему. Для части 3 приложить вывод `gh api repos/.../branches/main/protection` после включения.
|