# 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` после включения.