server-monitor-manager/agents/hermes/inbox/from-smm-deliverables/Старые задачи/smm-hermes-task-alpha10-and-docs-2026-08-10.md
Ochenstarik 23eb3f5233 chore(agents): разбор рабочих папок с диска на 2026-08-18
Задания, отчёты и патчи, лежавшие в C:\Users\Ochenstarik\projects и в
домашней папке, перенесены в agents/. Разложено по агентам там, где имя
файла позволяло определить автора; остальное — в _salvage-2026-08-18/
и разбирается вручную.

Патчи в notes/salvage-2026-08-18/ — незакоммиченная работа из брошенных
рабочих копий: она существовала только на диске.

Тяжёлое (релизные архивы, инсталляторы, наборы данных) в репозиторий не
попало: оно лежит рядом, в Agent_projects/_archive и Agent_projects/_data.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-18 14:19:54 +07:00

83 lines
7 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Hermes: выпуск alpha.10, синхронизация документации, уборка веток
## Состояние
`main` @ `61471f0`. Открытых PR нет. Все известные дефекты закрыты, включая семантическое сравнение версий (#36).
Горизонт 0 закрыт кодом полностью. Единственный незакрытый пункт — физическая приёмка на реальной топологии, её выполняет владелец. Задание ниже относится к завершению Горизонта 0, а не к Горизонту 1; новых функций не добавляется.
Ветка: `hermes/release-alpha10`.
---
## Часть 1 — выпустить `v0.1.0-alpha.10`
Причина выпускать именно сейчас: в `main` появилась запись установленной версии и семантическое сравнение (#36). Пока Hub владельца стоит на alpha.7, где записи версии нет, защита от отката и проверка совместимости работать не могут — им не с чем сравнивать. Обновление на alpha.10 создаёт эту запись и включает обе проверки с чистого листа.
1. Тег `v0.1.0-alpha.10` на текущий `main`, push через `git push`.
2. Дождаться `Release pipeline` и убедиться, что в релизе присутствуют: bootstrap и его `.sha256`, оба `tar.gz` и их `.sha256`, три SBOM, MSIX, `smm-setup.sh` и `smm-setup.sh.sha256`, `server-monitor-manager-manifest.json` и `server-monitor-manager-manifest.sig`.
3. Проверить, что `DEFAULT_RELEASE_TAG` в `deploy/smm-setup.sh` соответствует выпускаемому тегу — этого требует `docs/release-policy.md`. Сейчас там `v0.1.0-alpha.9`.
4. Тег **не двигать** ни при каких обстоятельствах. Ошибка в сборке исправляется следующим тегом — правило записано в `docs/release-policy.md`.
## Часть 2 — привести документацию в соответствие с кодом
В roadmap несколько пунктов отмечены открытыми, хотя реализованы. Проект держится на правиле «документация не описывает несуществующее»; обратная ошибка не менее вредна, потому что скрывает готовность.
Проверить и, где подтвердится, отметить выполненными:
- Этап 7, «добавить криптографическую подпись compatibility manifest для production release» — в `linux-release.yml` cosign используется, manifest подписывается, `.sig` публикуется;
- Этап 3, физический acceptance — **оставить открытым**, он действительно не выполнялся;
- пройти по остальным пунктам Этапов 28 и сверить с фактическим состоянием; отмечать только то, что подтверждается кодом или тестом, а не намерением.
Отдельным пунктом: **синхронизировать переводы README** (Этап 6). Одиннадцать переводов содержат устаревший релиз-статус. Достаточно привести раздел статуса и номер версии; переводить новые разделы целиком не требуется, но расхождение по версии недопустимо.
## Часть 3 — убрать слитые ветки с remote
Полностью слиты в `main` и подлежат удалению:
```
antigravity/cert-lifecycle
antigravity/repo-hygiene
antigravity/reproducible-builds
docs/product-horizons-and-integration
feat/monitor-role
hermes/monitor-snapshot-contract
hermes/release-single-writer
```
**Не трогать** — не слиты, требуют отдельного решения:
```
antigravity/repo-hygiene-updates закрытый PR #34, оставить как след
antigravity/signed-delivery-queue-a проверить, вошло ли всё в main
hermes/monitor-contract-red-proof проверить назначение
hermes/release-alpha.6 историческая
hermes/release-artifact-path-fix проверить, вошло ли в main
hermes/sprint1-desktop-security историческая
hermes/sprint1-server-security историческая
hermes/task2-b-link-reconciliation историческая
```
По четырём «проверить» — либо убедиться, что содержимое в `main`, и удалить, либо объяснить в отчёте, почему ветка нужна.
## Часть 4 — полный reboot настоящих Debian VM
Открытый пункт Этапа 7. Сейчас Debian проверяется в privileged systemd-контейнерах: они перезапускаются, но собственного ядра не имеют, поэтому reboot как таковой не проверен. `docs/linux-platform-matrix.md` честно называет это незакрытым критерием.
Добавить в матрицу настоящую Debian VM с полным reboot и проверкой, что после загрузки поднимаются Control, WireGuard, firewall-таблица и Agent. Если на GitHub-hosted runner это недостижимо, зафиксировать в `docs/linux-platform-matrix.md` конкретную причину и то, чем это компенсируется, — вместо бессрочно открытого пункта.
---
## Критерий приёмки
- `v0.1.0-alpha.10` выпущен с полным набором ассетов, тег не двигался;
- `DEFAULT_RELEASE_TAG` совпадает с тегом;
- roadmap отражает фактическое состояние, физический acceptance остаётся открытым;
- переводы README не противоречат текущей версии;
- слитые ветки удалены, по неслитым дано решение;
- по Debian VM либо появилась проверка, либо в документации записана причина и компенсация;
- CI зелёный.
## Отчёт
Раздельно: локально, в CI со ссылками, не запускалось и почему.