# План разработки Подробные требования к собственному bootstrap, управляемой настройке Linux и Xray находятся в [ТЗ Provisioning и Xray VPN](provisioning-vpn-requirements.md). Все компоненты Server Monitor Manager разрабатываются, версионируются и выпускаются только в этом репозитории. Текущее автоматическое покрытие поддерживаемых Linux-платформ описано в [Linux platform matrix](linux-platform-matrix.md). Очерёдность работ определяется [горизонтами продукта](product-horizons.md). Этот документ отвечает на вопрос «что сделано», горизонты — на вопрос «что разрешено начинать». Этапы 14–18 ниже относятся к Горизонтам 1–3 и не начинаются до закрытия Горизонта 0. ## Этап 0 — граница и базовая архитектура - [x] переименовать проект в Server Monitor Manager; - [x] зафиксировать самостоятельность репозитория и отсутствие межрепозиторных runtime-зависимостей; - [x] выбрать звёздную архитектуру Hub/Node для первого Mesh; - [x] разделить monitoring, terminal, Agent, Operator и AI-automation identities; - [x] описать направленные Links и kill switch; - [x] выбрать Apache License 2.0; - [x] добавить CI, форматирование, тесты и release checksums. ## Этап 1 — Windows SSH MVP - [x] создать packaged WinUI 3 приложение; - [x] добавить адаптивный Overview и профили нескольких серверов; - [x] генерировать отдельный Ed25519 monitoring SSH key; - [x] защищать monitoring key и Operator certificate через DPAPI; - [x] сохранять профили локально без паролей; - [x] получать CPU/load, RAM, disk, uptime и latency; - [x] редактировать и удалять серверы; - [x] поддерживать единственный изменяемый Mesh Hub; - [x] добавить страницы Servers, Links, Sessions и Settings; - [x] собирать и запускать x64-приложение; - [ ] добавить группы, теги и избранные серверы; - [ ] добавить настраиваемые alert rules и журнал уведомлений; - [ ] добавить управляемую отдельную terminal key identity вместо зависимости только от обычных пользовательских SSH-ключей. ## Этап 2 — постоянный Control и Agent - [x] ASP.NET Core Control Hub и SQLite; - [x] self-contained Agent/Control binaries для `linux-x64` и `linux-arm64`; - [x] исходящие mTLS Agent sessions; - [x] одноразовые enrollment tokens не более чем на 10 минут; - [x] локальная генерация Agent private key и CSR; - [x] отдельные Agent, Operator и source-scoped Automation certificates; - [x] отзыв и повторная регистрация Node/Operator; - [x] подтверждение SHA-256 fingerprint Control CA; - [x] защищённый event stream для Desktop; - [x] ограниченный offline buffer Agent и downsampling; - [x] idempotency и replay protection; - [x] SQLite schema version, retention и backup/restore Control DB + CA; - [x] веб-консоль оператора на Control: список узлов, состояние агентов и выпуск кода регистрации; - [x] отдача ассетов консоли из встроенных ресурсов сборки, когда каталога `wwwroot` нет на диске; - [x] вход по логину и паролю для тестовых стендов, отключённый по умолчанию; - [ ] добавить Desktop UI управления Automation identities и токенами. ## Этап 3 — управляемые Links - [x] направленные пары source -> destination; - [x] управление Links из Windows-клиента; - [x] политики по destination `/32`, TCP/UDP и порту; - [x] TTL и фоновое автоматическое истечение; - [x] состояния Connecting, Active, Disconnecting, Partial, Disabled и Failed; - [x] версия политики и подтверждение применения helper; - [x] обязательное восстановление disabled policy после reconnect; - [x] append-only audit операций Link; - [x] интеграционные тесты kill switch, process restart и helper failure; - [x] B-2: независимая фоновая и emergency-triggered реконсиляция, агрегированное состояние недоступного Mesh firewall и Desktop banner; - [x] B-3: факт-первичная реконсиляция использует один `link-list`, удаляет orphan/дубликаты (включая `Disabled/Disabled`), разводит `Examined` / `Converged` / `Failed` (M2), ограничивает marker-prompt тремя попытками, добавляет фильтр истории и retention завершённых Links (M4), а также типизированное ожидание активации Mesh Node (M5). Physical acceptance остаётся внешним блокером; - [ ] выполнить физический acceptance Hub + source Node + два destination Node с WireGuard/nftables/reboot. - [x] управление Links из веб-консоли: создание с подтверждением направления, обязательной причиной и ключом идемпотентности; - [x] аварийное отключение Link из строки таблицы консоли; - [x] раздельное отображение желаемого и фактического состояния Link с признаком рассогласования и последней ошибкой; - [x] журнал событий Control в реальном времени в веб-консоли; ## Этап 4 — мониторинг и терминал - [x] CPU/load, RAM, swap, disk, inode, network и uptime; - [x] состояния SSH/WireGuard и latency; - [x] локальные предупреждения по ресурсам и доступности; - [x] автоматическое обновление каждые 30 секунд; - [x] локальная история до 240 точек на сервер; - [x] графики CPU, RAM и диска; - [x] экспорт redacted diagnostics; - [x] прямой SSH-терминал с явным выбором пользователя; - [x] source-scoped Automation API для AI-агента. ## Этап 5 — качество и нагрузка - [x] HTTP authorization/integration tests; - [x] Linux Agent parser tests; - [x] Windows Desktop contract tests; - [x] тест 100 Node: concurrent heartbeat, inventory и replay; - [x] проверка TTL, retention, schema и backup/restore; - [x] CI Windows/Linux и проверка форматирования; - [ ] выполнить полную физическую приёмку по `docs/three-server-acceptance.md`; - [ ] добавить долговременный soak test и измеримые performance budgets. ## Этап 6 — releases - [x] GitHub prerelease с test-signed Windows MSIX; - [x] SHA-256 для Windows package и Linux binaries; - [x] self-contained Control/Agent release artifacts; - [ ] настроить постоянную доверенную Windows code-signing identity; - [ ] синхронизировать все переводы README с текущим release status. ## Этап 7 — собственный bootstrap Server Monitor Manager - [x] добавить bootstrap source в этот репозиторий; - [x] упаковывать bootstrap, checksum и compatibility manifest в release workflow; - [x] добавить криптографическую подпись compatibility manifest для production release; - [x] проверять Ubuntu 22.04/24.04 и Debian 12/13, `amd64`/`arm64`; - [x] добавить non-interactive install/update/rollback/uninstall; - [x] добавить режим полного удаления сервера; - [x] добавить пошаговый объединённый установщик; - [x] устанавливать Control/Agent, restricted helper и systemd units; - [x] локально создавать Agent key/CSR, выполнять mTLS enrollment и не сохранять token; - [x] добавить собственную установку WireGuard Hub/Node и выдачу внутренних адресов; - [x] реализовать nftables policy helper вместо временного deny-by-default helper; - [x] добавить native Ubuntu 22.04/24.04 x64/arm64 VM CI и повторную установку; - [x] добавить Debian 12/13 x64/arm64 systemd-container restart matrix; - [ ] добавить полный reboot настоящих Debian VM; - [x] добавить локальную emergency recovery command для текущих Mesh/firewall-компонентов. ## Этап 8 — Provisioning control plane - [x] модели и SQLite migration v2 для ProvisioningJob; - [x] state machine, confirmations, cancellation, retry и rollback; - [x] создание, чтение, подтверждение и отмена через Operator API; - [ ] выполнение, retry, verification и rollback в полной state machine; - [x] безопасный частичный execution increment для `system.base-install`: timezone-only, factual verification и автоматический rollback; - [x] обязательные idempotency key, audit reason и job TTL; - [x] атомарный Agent job channel только для собственного `node_id`; - [x] начальные строгие JSON schemas v1 для `preflight` и `system.base-install`; - [ ] versioned JSON schemas для остальных action type; - [x] restricted root helper через Unix socket (`preflight`, plan и подтверждённый timezone-only execution для `system.base-install`); - [x] двухфазный `system.base-install`: сохранённый проверенный plan до Operator confirmation; - [x] короткоживущий ECDSA execution grant, привязанный к Node, job и SHA-256 подтверждённого plan; - [x] structured redacted events, bounded Operator history и progress; - [x] `NeedsReconciliation` после истечения execution TTL и неопределённого результата; - [ ] desired/factual configuration и drift (`preflight` завершён; остальные action type ещё не подключены); - [x] запрет параллельных активных заданий на одном Node (безопасный первый вариант). ## Этап 9 — базовая настройка и пользователи - [ ] preflight ОС, архитектуры, SSH, firewall, APT и capabilities; - [ ] Desktop wizard timezone/locale/packages/swap/unattended upgrades; - [x] versioned package allowlist (catalog v1 с фиксированными package groups); - [ ] root-only backups и symlink protection; - [ ] user lifecycle без sudo по умолчанию; - [ ] SSH public keys, fingerprints и permissions; - [ ] sudo/passwordless sudo с отдельным подтверждением; - [ ] block/unblock, sessions, services и безопасное удаление; - [ ] verification и rollback для каждого action. ## Этап 10 — firewall и безопасная миграция SSH - [ ] редактор managed firewall rules IPv4/IPv6/CIDR; - [ ] preflight port conflict и effective sshd config; - [ ] managed `sshd_config.d` drop-in; - [ ] `sshd -t`, `sshd -T` и firewall dry-run; - [ ] второе SSH-подключение Desktop на новом порту; - [ ] сохранение host key fingerprint; - [ ] запрет закрытия порта 22 до успешной проверки; - [ ] отдельное подтверждение закрытия старого порта; - [ ] автоматический rollback без разрыва активной сессии. ## Этап 11 — системный Xray VPN - [ ] Node-specific encryption VPN subscription secrets; - [ ] установка, update, disable и verification Xray; - [ ] routing exclusions для Mesh, Control, SSH и VPN endpoint; - [ ] automatic rollback timer; - [ ] TCP/UDP/DNS/IPv6 probes и внешний IP до/после; - [ ] system-wide kill switch с management exceptions; - [ ] emergency disable без Control Hub; - [ ] reboot/reconciliation tests. ## Этап 12 — Xray VPN для пользователя - [ ] UID/cgroup marking, fwmark, policy route и TPROXY; - [ ] один активный VPN profile на UID; - [ ] TCP, UDP, DNS и IPv6 policy; - [ ] per-user kill switch; - [ ] probes от назначенного UID; - [ ] исключение Xray, Mesh и management traffic; - [ ] отключение assignment при смене UID/удалении пользователя; - [ ] UI assignment и audit; - [ ] VM test: один пользователь через VPN, второй напрямую. ## Этап 13 — hardening и дополнительные платформы - [ ] threat-model review Provisioning и VPN; - [ ] полная VM matrix и physical alpha acceptance; - [ ] macOS и Linux Desktop после стабилизации Core/API; - [ ] Android/iOS companion clients; - [ ] push-уведомления без административных secrets у push provider. ## Этап 14 — роль Monitor и доверенная поставка (Горизонт 0) - [x] `install-monitor` в bootstrap: системный пользователь, root-owned forced command, установка публичного ключа из Desktop, идемпотентная переустановка и удаление; - [x] контрактный тест формата снимка метрик, общий для forced command и Desktop-парсера; - [x] подписанный release manifest с хэшами всех артефактов и версиями Control/Agent/helper/Desktop; - [x] публичный ключ проверки вшит в bootstrap и Desktop, проверка подписи до разбора manifest; - [x] отказ `update-control`/`update-agent` при несовместимых версиях; - [x] негативные тесты в CI: подменённый архив, подменённый хэш, manifest без подписи; - [x] пиннинг GitHub Actions по commit SHA, dependabot, SBOM; - [ ] автопродление сертификата Agent и документированная ротация Control CA; - [ ] доверенная подпись Windows MSIX. ## Этап 15 — политики подтверждения (Горизонт 1) Спецификация: [политики подтверждения](approval-policies.md). - [ ] режимы `none`, `operator`, `operator_reauth`, `owner`, `two_person`, `time_window`, `maintenance_window`, `emergency_only`, `read_only_automation`; - [ ] версионируемая политика на Control, недоступная для ослабления клиентом; - [ ] повторное доказательство владения identity, привязанное к конкретному `job_id`; - [ ] сравнение инициатора и подтверждающего по identity при `two_person`; - [ ] изменение политики как аудируемое событие, действующее только на новые задания. ## Этап 16 — alerts, уведомления и наблюдение за сервисами (Горизонт 1) - [ ] alert rules: порог, duration, severity, cooldown, дедупликация; - [ ] режим обслуживания, подтверждение, эскалация, история инцидентов, автозакрытие, тихие часы; - [ ] Telegram только на чтение: `/status`, `/servers`, `/alerts`, `/links`, `/jobs`; - [ ] наблюдение Docker: контейнеры, образы, healthcheck, счётчики рестартов, лимиты; - [ ] наблюдение systemd: units, failed units, счётчики рестартов, journald; - [ ] действия над Docker и systemd только по allowlist, с подтверждением и аудитом. ## Этап 17 — Backup Manager (Горизонт 1) - [ ] источники: каталоги, конфигурации, Docker volumes, Control DB и CA; - [ ] хранилища local и S3; - [ ] расписания, шифрование, retention, контрольные суммы; - [ ] проверка архива и тестовое восстановление; - [ ] оповещения об ошибках резервного копирования и об устаревшей копии. ## Этап 18 — интеграция с KAgent (Горизонт 3) Спецификация: [интеграция с KAgent](integration-kagent.md). Начинается только после закрытия Горизонта 1. - [ ] локальное обнаружение через Unix-сокет с проверкой `SO_PEERCRED`, таймаутами и лимитами; - [ ] идентичность `KAgentIntegration` с одноразовым token, сроком, областью Nodes и отзывом; - [ ] модель возможностей: чтение, запрос, невыдаваемые; - [ ] согласование версии протокола и фактически выданных возможностей; - [ ] чтение Nodes, метрик, здоровья и событий; - [ ] планы и запросы через обычный конвейер typed provisioning; - [ ] жизненный цикл Worker с инвариантом недоверенного исполнителя; - [ ] временные задачные Links с обязательным TTL и запретом destination = Hub или другой Worker; - [ ] аварийные средства: отзыв, остановка, карантин, режим только чтения.