# Hermes: совместимость БД, выпуск alpha.8, роль Monitor

## Состояние

- `main` @ `df4dfd1`;
- PR #24 `fix(enrollment): repair node enrollment path` слит — блокирующий дефект регистрации Node закрыт;
- слиты шесть обновлений dependabot, включая **SQLitePCLRaw 2.1.12 → 3.0.5**;
- последний релиз — `v0.1.0-alpha.7`, в нём фикса регистрации **нет**;
- на живом Hub пользователя развёрнут alpha.7 с работающей `control.db`, созданной версией 2.1.12.

Ветка: `hermes/release-alpha8-and-monitor` (части 1–2) и `hermes/monitor-role` (часть 3) — либо одна ветка на часть, по вашему усмотрению, но части 1–2 и часть 3 разными PR.

---

## Часть 1 — совместимость существующей базы с SQLitePCLRaw 3.0.5 · сделать первым

`SQLitePCLRaw` — нативная библиотека под SQLite, на которой держится вся база Control: enrollment, identities, links, provisioning, audit. Мажорное обновление слито без проверки на **существующей** базе; CI создаёт базу с нуля и потому совместимость не проверяет в принципе.

Если совместимости нет, это проявится в момент `update-control` на живом Hub — то есть в самый неудобный момент и без пути назад.

Проверить:

1. Взять `control.db`, созданную сборкой на 2.1.12 (подойдёт база с реального Hub либо созданная из тега `v0.1.0-alpha.7`).
2. Открыть её сборкой из текущего `main`: `PRAGMA user_version` читается, значение прежнее, миграции не пытаются примениться повторно.
3. Данные читаются: агенты, identities, links, provisioning-задания, аудит.
4. `backup-create` на этой базе и `backup-restore` из полученного бэкапа проходят и дают рабочий Control.
5. Повторить на `linux-arm64` self-contained trimmed single-file: нативные библиотеки в такой сборке линкуются иначе, чем под x64.

Если хоть один пункт не проходит — **не выпускать релиз**, откатить #23 отдельным PR и написать об этом прямо.

**Обязательно добавить тест**, которого сейчас нет: открытие базы предыдущей схемы. Зафиксировать в репозитории эталонную `control.db` (или скрипт её воспроизведения) и проверять открытие при каждом прогоне. Без него следующее обновление SQLite повторит ту же историю.

---

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

Пользовательские серверы стоят: Hub развёрнут и работает, Node зарегистрировать нельзя, потому что фикс лежит только в `main`.

После части 1:

1. Тег `v0.1.0-alpha.8` на текущий `main`, push тегом через `git push` — release-workflow триггерится на `push: tags: v*`.
2. Убедиться, что оба release-workflow отработали и в релиз попали: bootstrap + `.sha256`, оба `tar.gz` + `.sha256`, manifest, MSIX, SBOM.
3. Проверить, что `permissions` на job-уровне из PR #14 действительно сработали — release-workflow **не запускаются на pull request**, и это первый настоящий их прогон после той правки. Если публикация упадёт по 403, чинить здесь же.
4. К релизу приложить `smm-setup.sh` из `server-monitor-manager-deliverables` — файл берётся как ассет релиза и должен обновиться на новый тег. В нём есть временный обход бага `validate_control_url`; **убрать его**, раз дефект исправлен в #24. Обход помечен комментарием в коде.

После выпуска сообщить: пользователь повторит регистрацию Node на своих серверах через `update-control` и новый `node-code`.

---

## Часть 3 — роль Monitor в bootstrap

Пункт Горизонта 0, который никто не начинал. Сегодня SSH-мониторинг — функция, ради которой существует Desktop, — не имеет серверной части: в bootstrap нет действия установки, forced-command скрипт не поставляется, а парсер `SshMonitorService.QueryAsync` ожидает ключи `PROTOCOL`, `CPU_COUNT`, `MEM_AVAILABLE_KB`, `DISK_INODES_TOTAL` и другие, которых в репозитории не производит никто.

Объём:

- действия `install-monitor PUBLIC_KEY` и `uninstall-monitor`;
- системный пользователь `ochenstarik-monitor`: `nologin`, без пароля, без sudo;
- `/usr/local/libexec/ochenstarik-smm-metrics`, root-owned `0755`, выдающий ровно снимок из `docs/installer-contract.md` §7 и read-only `mesh status`;
- `authorized_keys` с `command="…",restrict,no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding`;
- идемпотентность повторного запуска и корректное удаление;
- **контрактный тест формата снимка, общий для скрипта и парсера Desktop** — иначе они разъедутся снова.

Формат снимка не выдумывать: он уже зафиксирован в `docs/installer-contract.md` §7.

`SshMonitorService.cs` не менять — если парсер потребует правки, описать нужное в `REPORT.md`.

---

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

- существующая база открывается новой сборкой, backup/restore работают, есть тест на предыдущую схему;
- `v0.1.0-alpha.8` выпущен со всеми ассетами, публикация не упала по правам;
- обход `validate_control_url` из `smm-setup.sh` убран;
- чистый сервер попадает под мониторинг одной командой, README соответствует коду;
- контрактный тест формата снимка в CI;
- Control suite прогнан на Linux;
- PR созданы, CI зелёный.

## Отчёт

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