server-monitor-manager/agents/codex/inbox/from-smm-deliverables/Старые задачи/smm-codex-task-alpha14-2026-08-15.md

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 со ссылками на прогоны, что не проверялось и почему.

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