# Codex: выпустить v0.1.0-alpha.20 и закрыть дыру в проверке выпуска

## Репозиторий

- https://github.com/ochenstarik-ui/server-monitor-manager
- База: `main` @ `7c43977`
- Ветка: `codex/release-alpha20`
- `main` защищён: PR обязателен, обязательны статусы `build-and-test` и `build`, force-push запрещён
- один PR — одна тема; описание PR заполняется **после** завершения CI

## Что произошло

Тег `v0.1.0-alpha.19` создан на `7c43977`, `Release pipeline` упал, релиз не опубликован. Номер сожжён и не переиспользуется — так же, как `alpha.10` и `alpha.11`.

Причина в шаге `Package bootstrap` workflow `linux-release.yml`:

```bash
if [[ "${GITHUB_REF}" == refs/tags/* ]]; then
  sed -i "s/^PROGRAM_VERSION=.*$/PROGRAM_VERSION=\"${GITHUB_REF_NAME}\"/" "$DIST_DIR/ochenstarik-server-monitor-manager.sh"
  grep -Fq "readonly DEFAULT_RELEASE_TAG=\"${GITHUB_REF_NAME}\"" "$DIST_DIR/smm-setup.sh"
fi
```

Проверка требует, чтобы `DEFAULT_RELEASE_TAG` в `deploy/smm-setup.sh` совпадал с выпускаемым тегом. В `main` там `v0.1.0-alpha.18`. Проверка сама по себе правильная: она не даёт выпустить установщик, который по умолчанию тянет ассеты чужого релиза.

**Дыра в другом.** Весь блок закрыт условием `refs/tags/*`, поэтому пробный прогон через `workflow_dispatch` идёт по `refs/heads/main` и эту проверку пропускает. Репетиция перед тегированием, введённая как раз для того, чтобы не сжигать номера, не покрывает единственный шаг, который на теге и ломается. Пока это так, каждый выпуск остаётся лотереей.

---

## Часть 1 — сделать репетицию честной

Дать `linux-release.yml` вход `workflow_dispatch` с необязательным параметром `tag` и выполнять при пробном прогоне те же проверки согласованности версий, что и на настоящем теге: подстановку `PROGRAM_VERSION` и сверку `DEFAULT_RELEASE_TAG`. Публикация при этом по-прежнему не выполняется — она остаётся привязанной к `refs/tags/*`.

Смысл: прогон `workflow_dispatch` с `tag=v0.1.0-alpha.20` должен падать ровно там же, где упал бы настоящий тег, и по той же причине.

Если сочтёте, что вход-параметр — плохое решение, допустима альтернатива: вынести сверку согласованности версий в обычный тест, исполняемый на каждом PR, который сравнивает `DEFAULT_RELEASE_TAG` с последним тегом в `docs/release-policy.md`. Обоснуйте выбор в отчёте.

## Часть 2 — привести версии в согласие

Обновить до `v0.1.0-alpha.20` все места, где номер зашит. На момент написания их пять:

- `deploy/smm-setup.sh:6` — `readonly DEFAULT_RELEASE_TAG`;
- `deploy/smm-setup.sh:37` — текст справки `SMM_TAG  Release tag (default: ...)`;
- `docs/linux-bootstrap.md:9,12,13` — команды скачивания;
- `.github/workflows/windows-build.yml:43` — `SMM_TEST_RELEASE_TAG` для шага live-release.

Перечень проверьте сами: `git grep -n 'alpha\.18'` по `deploy/`, `docs/`, `.github/`. Если после обновления где-то останется старый номер, это дефект.

Заведите проверку, которая не даёт им разъехаться впредь: все зашитые упоминания версии релиза должны сверяться автоматически, а не глазами при следующем выпуске.

## Часть 3 — записать судьбу alpha.19

В `docs/release-policy.md`: `v0.1.0-alpha.19` — тег создан, `Release pipeline` упал на сверке `DEFAULT_RELEASE_TAG`, релиз не опубликован, номер не переиспользуется.

## Часть 4 — выпустить

1. Прогнать `Release pipeline` через `workflow_dispatch` с `tag=v0.1.0-alpha.20` на своей ветке и получить зелёный — теперь это осмысленная репетиция, а не формальность.
2. Создать и запушить тег обычным `git push`.
3. Убедиться, что релиз опубликован и что `Release Verification` запустился сам по `workflow_run` и зелёный.
4. Тег не двигать ни при каких обстоятельствах.

## Границы

Antigravity ведёт Control и веб-консоль. **Не трогать:** `src/**`.

Ваша область: `deploy/**`, `.github/workflows/linux-release.yml`, `.github/workflows/windows-build.yml` в части `SMM_TEST_RELEASE_TAG`, `tests/bootstrap/**`, `docs/linux-bootstrap.md`, `docs/release-policy.md`.

## Критерий приёмки

- пробный прогон с параметром `tag` выполняет сверку версий и падает на несогласованности;
- все зашитые упоминания версии обновлены до `v0.1.0-alpha.20`, расхождение ловится автоматически;
- судьба `alpha.19` записана в `docs/release-policy.md`;
- `v0.1.0-alpha.20` опубликован, набор ассетов совпадает с `tests/release-verification/verify-assets.sh`;
- `Release Verification` отработал по событию и зелёный, ссылка на прогон в отчёте;
- всё через PR, CI зелёный, PR не смержен до зелёного.

## Отчёт

В описании PR, раздельно: что проверено локально, что в CI со ссылками на прогоны, что не проверялось и почему.