# 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 со ссылками на прогоны, что не проверялось и почему. Физическая приёмка на реальных серверах в задание не входит — её выполняет владелец после выпуска релиза.