# Codex: выпустить v0.1.0-alpha.14 и дать установку одной командой

Задание самодостаточно: истории работы по этому репозиторию у вас нет, всё нужное ниже.

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

- https://github.com/ochenstarik-ui/server-monitor-manager
- Локальный клон для этой работы: `C:\Users\Ochenstarik\projects\smm-codex`
- База: `main` @ `b0ad40c`
- Ветка: `codex/release-alpha14`

Server Monitor Manager — Windows-клиент, ASP.NET Core Control Hub, Linux-агент и WireGuard-mesh с политиками nftables. Устанавливается на серверы bash-скриптом `deploy/ochenstarik-server-monitor-manager.sh` (bootstrap), который поставляется в GitHub Release вместе с самораспаковывающимися архивами компонентов.

## Правила репозитория

- `main` защищён: PR обязателен, обязательны статусы `build-and-test` и `build`, force-push запрещён. Прямые коммиты в `main` невозможны;
- один PR — одна тема;
- описание PR заполняется **после** завершения CI, со ссылками на конкретные прогоны;
- отсутствие проверки не является дефектом отчёта; утверждение о проверке, противоречащее статусу CI, — является;
- `docs/release-policy.md` запрещает двигать опубликованные теги и заменять ассеты: исправление выпускается следующей версией;
- `.github/workflows/linux-release.yml` — единственный публикатор релизов.

## Состояние и зачем это нужно

Владелец проекта не может установить систему на свои серверы. Причина точная:

`deploy/smm-setup.sh` по умолчанию указывает на `v0.1.0-alpha.14`, которого не существует. Опубликован `v0.1.0-alpha.13`. Установка упирается в 404 на всех семи файлах релиза.

Предыстория, чтобы не повторить:

- `v0.1.0-alpha.10` и `v0.1.0-alpha.11` — теги созданы, но `Release pipeline` упал, релизы не опубликованы. Номера сожжены, переиспользовать нельзя. Оба раза причина одна: пайплайн не прогоняли перед тегированием;
- `v0.1.0-alpha.12` и `v0.1.0-alpha.13` опубликованы, но содержат `server-monitor-manager-manifest.sig` **без** `server-monitor-manager-manifest.pem`. Подпись cosign делается keyless-режимом, проверяется эфемерным сертификатом, а не постоянным ключом — без `.pem` проверить подпись невозможно. Эти релизы непроверяемы и останутся такими: политика запрещает дополнять опубликованный релиз;
- в `main` сертификат уже публикуется, `verify_archive` требует manifest, подпись и сертификат вместе. `v0.1.0-alpha.14` — первый релиз, где подпись работает целиком.

---

## Часть 1 — выпустить `v0.1.0-alpha.14`

1. **Сначала прогнать `Release pipeline` через `workflow_dispatch` на своей ветке.** Шаги публикации защищены `if: startsWith(github.ref, 'refs/tags/')` и на ветке пропускаются, но сборка, подпись и проверки выполнятся. Именно пропуск этого шага сжёг два тега подряд.
2. Создать и запушить тег `v0.1.0-alpha.14` обычным `git push` — не через `gh release create`: релиз создаёт сам workflow по событию `push: tags: v*`.
3. Сверить набор ассетов со списком в `tests/release-verification/verify-assets.sh` — он является контрактом. Обязательно должен присутствовать `server-monitor-manager-manifest.pem`.
4. Убедиться, что workflow `Release Verification` отработал **автоматически** по событию `release: published` и зелёный. Это главный результат: впервые проверка пройдёт против настоящего подписанного релиза, а не против ветки.

Если `Release Verification` найдёт дефект релиза — это успех задачи, а не провал. Зафиксировать находку отдельным разделом отчёта и не «чинить» её ослаблением проверки или флагом `SMM_ALLOW_UNSIGNED`.

**Тег не двигать ни при каких обстоятельствах.** Ошибка исправляется следующим номером.

## Часть 2 — установка одной командой

Сейчас оператор вручную скачивает семь файлов: установщик и его контрольную сумму, архив и его контрольную сумму, manifest, подпись и сертификат. Пропуск любого из трёх файлов подписи означает отказ `verify-release`. Это лишний источник ошибок в самой ответственной операции, и владелец просит одну команду.

Добавить в `deploy/smm-setup.sh`:

```
smm-setup.sh install-hub  PUBLIC_HOST [HTTPS_PORT] [WG_PORT]
smm-setup.sh install-node
```

Поведение:

- определить архитектуру (`x86_64` → `linux-x64`, `aarch64`/`arm64` → `linux-arm64`) и выбрать соответствующий архив;
- скачать в рабочий каталог архив, его `.sha256`, manifest, подпись и сертификат публичным `curl` — без `gh` и без токена: у оператора их нет;
- сверить контрольную сумму архива;
- выполнить `install-control` и `mesh-init` для роли hub, либо `install-node` для роли node;
- при отсутствии любого из трёх файлов подписи — отказ с внятным сообщением, а не тихий переход на `.sha256`.

Существующий сквозной режим (`smm-setup.sh <любая-команда-bootstrap>`) сохранить: он используется в тестах и в скрипте приёмки `tests/acceptance/three-server-mesh.sh`.

Обновить `docs/linux-bootstrap.md`: короткий путь показать основным, ручной оставить ниже.

Добавить проверку в `tests/bootstrap/test-release-contract.sh`: обе новые команды существуют, отвергают лишние и недостающие аргументы, и не проходят без файлов подписи.

## Часть 3 — зафиксировать судьбу непроверяемых релизов

В `docs/release-policy.md` записать:

- `v0.1.0-alpha.10` и `v0.1.0-alpha.11` — теги без опубликованного релиза, номера не переиспользуются;
- `v0.1.0-alpha.12` и `v0.1.0-alpha.13` — опубликованы с подписью, но без сертификата, поэтому проверке подписи не поддаются;
- `v0.1.0-alpha.14` — первый полностью проверяемый релиз.

Это нужно, чтобы через полгода никто не выяснял заново, почему подпись двух релизов не сходится.

---

## Границы

Antigravity параллельно ведёт проверку подписи на стороне Desktop. **Не трогать:** `src/ServerMonitorManager.Desktop/**`, `tests/ServerMonitorManager.Desktop.Security.Tests/**`, `.github/workflows/windows-build.yml`.

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

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

- `workflow_dispatch`-прогон `Release pipeline` выполнен **до** тегирования, ссылка в отчёте;
- `v0.1.0-alpha.14` опубликован, набор ассетов совпадает с `verify-assets.sh`;
- `Release Verification` отработал по событию публикации и зелёный, ссылка в отчёте;
- `install-hub` и `install-node` ставят систему без ручного скачивания файлов подписи;
- отсутствие manifest, подписи или сертификата даёт отказ, а не переход на `.sha256`;
- новые команды покрыты контрактным тестом;
- судьба alpha.10–alpha.13 записана в `docs/release-policy.md`;
- всё через PR, CI зелёный, PR не смержен до зелёного.

## Отчёт

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

Физическая приёмка на реальных серверах в задание не входит — её выполняет владелец после выпуска релиза.
