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

7.4 KiB

Raw Blame History

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 — то есть в самый неудобный момент и без пути назад.

Проверить:

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

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

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

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

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

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

Тег v0.1.0-alpha.8 на текущий main, push тегом через git push — release-workflow триггерится на push: tags: v*.
Убедиться, что оба release-workflow отработали и в релиз попали: bootstrap + .sha256, оба tar.gz + .sha256, manifest, MSIX, SBOM.
Проверить, что permissions на job-уровне из PR #14 действительно сработали — release-workflow не запускаются на pull request, и это первый настоящий их прогон после той правки. Если публикация упадёт по 403, чинить здесь же.
К релизу приложить 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 со ссылками, не запускалось и почему. Физическая приёмка на трёх серверах выполняется пользователем и в это задание не входит.

7.4 KiB Raw Blame History Unescape Escape