standkit 0.3.7__tar.gz → 0.5.0__tar.gz

standkit-0.5.0/MANIFEST.in

@@ -0,0 +1,5 @@
+include projects.sample.json
+include README.md
+include LICENSE
+include SECURITY.md
+recursive-include docs *.md

{standkit-0.3.7/standkit.egg-info → standkit-0.5.0}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: standkit
-Version: 0.3.7
+Version: 0.5.0
 Summary: Свободное ядро (MIT) для управления жизненным циклом локальных и удалённых стендов BPMSoft: headless start/stop/restart, health-пробы, логи, реестр стендов. Часть экосистемы BPMkit.
 Author: standkit contributors
 License: MIT
@@ -98,6 +98,8 @@ BPMkitStand состоит из **ядра и двух оболочек**:
 Запуск стенда честный: дашборд поднимает `dotnet <stand_dll>` и держит спиннер до реального
 ответа web-хоста по HTTP, а не рапортует «запущено» по факту создания процесса.
 
+Виды хостинга (kestrel/iis/docker) — см. [docs/HOSTING.md](docs/HOSTING.md).
+
 ## Удалённые стенды
 
 Стенды на других хостах (виртуалки, серверы, контуры заказчика) управляются через **федерацию
@@ -130,7 +132,8 @@ standkit-hub
 ## Реестр стендов
 
 BPMkitStand использует тот же реестр, что и MCP BPMkit — единый `projects.json`.
-Образец формата — [`projects.sample.json`](projects.sample.json).
+Образец формата — [`projects.sample.json`](projects.sample.json). Стенд можно
+зарегистрировать прямо из дашборда (кнопка «Зарегистрировать стенд»).
 
 ## Безопасность
 

{standkit-0.3.7 → standkit-0.5.0}/README.md

@@ -73,6 +73,8 @@ BPMkitStand состоит из **ядра и двух оболочек**:
 Запуск стенда честный: дашборд поднимает `dotnet <stand_dll>` и держит спиннер до реального
 ответа web-хоста по HTTP, а не рапортует «запущено» по факту создания процесса.
 
+Виды хостинга (kestrel/iis/docker) — см. [docs/HOSTING.md](docs/HOSTING.md).
+
 ## Удалённые стенды
 
 Стенды на других хостах (виртуалки, серверы, контуры заказчика) управляются через **федерацию
@@ -105,7 +107,8 @@ standkit-hub
 ## Реестр стендов
 
 BPMkitStand использует тот же реестр, что и MCP BPMkit — единый `projects.json`.
-Образец формата — [`projects.sample.json`](projects.sample.json).
+Образец формата — [`projects.sample.json`](projects.sample.json). Стенд можно
+зарегистрировать прямо из дашборда (кнопка «Зарегистрировать стенд»).
 
 ## Безопасность
 

standkit-0.5.0/SECURITY.md

@@ -0,0 +1,119 @@
+# SECURITY — модель безопасности standkit-агента
+
+> Аудитория: инженеры и self-hosted администраторы, разворачивающие
+> `standkit_agent` на хостах стендов. Клиентский (заказчицкий) документ по
+> модели удалённой работы готовится отдельно на основе этого файла.
+> Статус кода: прод-харденинг выполнен (v0.2 агента), см. чек-лист и
+> остаточные пункты ниже.
+
+## 1. Что защищаем (assets) и почему это критично
+
+`standkit_agent` — headless-демон на хосте стенда, который по HTTP(S) умеет
+**запускать, останавливать и перезапускать процессы стенда** и читать его
+логи. То есть агент по своей природе — **поверхность удалённого исполнения
+кода (RCE)**: тот, кто получит контроль-доступ к агенту, управляет жизненным
+циклом процессов на хосте. Поэтому к нему применяется модель угроз как к
+элементу управляющего контура (management plane), а не как к обычному
+прикладному API.
+
+Активы: (1) контроль над процессами стенда; (2) содержимое логов стенда;
+(3) сам хост (через возможность запускать процессы). Агент НЕ хранит секретов
+клиента и НЕ содержит контента платформы — только оркестрацию.
+
+## 2. Противники и границы доверия
+
+- **Сетевой злоумышленник** (тот же сегмент/периметр): перехват трафика,
+  попытка подключиться к порту агента, brute-force токена.
+- **Утечка токена** (лог, история команд, скриншот): попытка использовать
+  украденный Bearer-токен.
+- **Инсайдер с доступом к сети управления**: злоупотребление легитимным
+  доступом — здесь работает аудит.
+
+Граница доверия: агент доверяет только клиентам, прошедшим (а) TLS/mTLS-
+транспорт и (б) аутентификацию по скоупу. Всё остальное — недоверенное.
+
+## 3. Модель развёртывания (как разворачивать безопасно)
+
+Рекомендуемые топологии (в порядке предпочтения):
+
+1. **Loopback + управляющий контур.** Агент слушает `127.0.0.1`, доступ к
+   нему — только через SSH-туннель / WireGuard / VPN до хоста. Наружу порт
+   агента не публикуется вообще. Самый простой безопасный вариант — дефолт.
+2. **mTLS за firewall.** Агент слушает управляющий интерфейс с TLS +
+   обязательным клиентским сертификатом (`--tls-client-ca`). Подключиться
+   может только держатель сертификата, подписанного доверенным CA (например,
+   Companion оператора). Источники ограничены firewall-allowlist.
+
+**Категорически нельзя:** публиковать порт агента в интернет; выставлять его в
+недоверенную сеть открытым HTTP; запускать под root/LocalSystem; хранить токен
+в открытых конфигах/истории команд.
+
+## 4. Secure-defaults, действующие в коде (v0.2)
+
+- **Bind по умолчанию `127.0.0.1`** (не `0.0.0.0`).
+- **Fail-closed**: non-loopback host без TLS → агент **не стартует**
+  (`InsecureBindError`) ещё до открытия сокета. Обход — только явный
+  `--insecure` (dev/loopback) с громким предупреждением в stderr.
+- **TLS**: `PROTOCOL_TLS_SERVER`, минимум **TLS 1.2**, консервативный набор
+  AEAD/ECDHE-шифров (forward secrecy), выключено сжатие (CRIME).
+- **mTLS**: `--tls-client-ca` → `CERT_REQUIRED`; клиент без валидного
+  сертификата отсекается на TLS-хендшейке, до обработчика. CN — в аудит.
+- **AuthN**: Bearer-токен, сравнение только `hmac.compare_digest`
+  (анти-timing). **Скоупы**: `control` (start/stop/restart + чтение) и
+  `readonly` (только чтение).
+- **Lockout**: 5 неудачных аутентификаций с одного IP за 300 c → `429` до
+  конца окна (настраивается).
+- **Аудит**: append-only JSON-lines (`--audit-log`, дефолт
+  `~/.standkit/audit.log`), каждая операция (ok/denied/error) с src_ip,
+  идентичностью, действием и кодом. **Токены никогда не пишутся.**
+- **Input-hardening**: лимит тела 64 КБ (проверка до чтения), кап `n` логов
+  10000, таймаут соединения 30 c, whitelist-валидация имени стенда, `400`
+  вместо `500`/креша на некорректный ввод, `405` на PUT/DELETE/PATCH.
+- **systemd least-privilege** (`deploy/standkit-agent.service`):
+  `NoNewPrivileges`, `ProtectSystem=strict`, `ProtectHome`, `PrivateTmp`,
+  `PrivateDevices`, `CapabilityBoundingSet=` (пусто), `MemoryDenyWriteExecute`,
+  `LockPersonality`, `RestrictNamespaces`, `SystemCallFilter=@system-service`,
+  выделенный не-root `User=`/`Group=`, урезанные `ReadWritePaths`.
+
+## 5. Чек-лист развёртывания на прод
+
+- [ ] Агент слушает loopback ИЛИ настроен TLS (лучше mTLS). Порт не в интернет.
+- [ ] Отдельный сервис-аккаунт без root; systemd-hardening из unit применён.
+- [ ] Токены сгенерированы криптостойко, лежат в secret-store (env/keyring),
+      не в открытых конфигах; разные токены на control и readonly.
+- [ ] Firewall-allowlist источников (только Companion оператора / сеть
+      управления).
+- [ ] Аудит-лог пишется на защищённый носитель; настроен внешний сбор/ротация
+      (см. остаточные пункты) и мониторинг `denied`/`429`.
+- [ ] TLS-сертификаты и приватный ключ — с корректными правами (0600), выданы
+      доверенным CA; продумана ротация.
+- [ ] Проверено, что `--insecure` НЕ используется на этом хосте.
+
+## 6. Остаточные пункты (осознанные TODO следующих итераций)
+
+Не закрыты в v0.2 и требуют внимания перед массовым прод-развёртыванием:
+
+- **PKI/сертификаты**: агент только потребляет готовые PEM. Выпуск, раздача и
+  ротация серверных/клиентских сертификатов — пока забота оператора. Нужен
+  задокументированный процесс (или интеграция с внутренним CA).
+- **Ротация токенов «на лету»** без рестарта агента — не реализована.
+- **Per-stand ACL**: control-скоуп управляет всеми стендами реестра агента;
+  разбивки «токен/CN → конкретный стенд» нет.
+- **CN→scope маппинг** для mTLS: сейчас скоуп всегда определяется Bearer-
+  токеном, CN сертификата — только для аудита.
+- **Ротация/размерный кап аудита**: до-аутентификационные ответы (`404`/`405`)
+  и поток `denied` могут наливать файл; нужна ротация (logrotate/размерный
+  лимит) и защита от переполнения диска.
+- **Кап числа потоков**: `ThreadingHTTPServer` не ограничивает число
+  одновременных обработчиков — при флуде соединений возможно исчерпание
+  ресурсов. Нужен bounded thread pool / лимит соединений (плюс внешний
+  rate-limit на reverse-proxy).
+- **`Transfer-Encoding: chunked`**: лимит тела опирается на `Content-Length`;
+  chunked-запрос лимит не учитывает. Явно отклонять chunked или считать длину.
+- **Windows-служба**: обёртка через `sc.exe`/pywin32 с least-privilege — не
+  входила в объём v0.2 (есть заметки в `deploy/windows-service.md`).
+
+## 7. Сообщение об уязвимостях
+
+До публикации репозитория и политики раскрытия — сообщать о проблемах
+безопасности приватно мейнтейнеру проекта, не через публичные issue.

standkit-0.5.0/docs/ARCHITECTURE.md

@@ -0,0 +1,111 @@
+# Архитектура standkit
+
+Этот документ — краткое зеркало архитектурных решений для контекста разработки
+в самом репозитории `standkit`. **Детальный дизайн, обоснования выбора модели
+и разбор альтернатив — в репозитории BPMkit: ADR-0019 и
+`docs/планы/companion_dispatcher_f_l2a_2026-07-23.md`.** Здесь — только то, что
+нужно держать перед глазами при правке кода этого репозитория.
+
+## Модель: ядро + две оболочки
+
+```
+standkit        — MIT, движок жизненного цикла, stdlib-only, без сети "наружу",
+                   без лицензионно-чувствительного контента BPMSoft.
+standkit_agent   — MIT, stdlib-only HTTP-обёртка вокруг ядра, кроссплатформенная
+                   (Windows/Linux), разворачивается на КАЖДОМ хосте стенда.
+standkit_hub     — MIT, stdlib-only локальный веб-дашборд (http.server) +
+                   vanilla JS/CSS фронтенд, федеративный клиент N агентов +
+                   локального ядра, ставится ТОЛЬКО на машину оператора.
+                   Опциональная нативная оболочка — pywebview (extra [desktop]).
+```
+
+Веб-дашборд (вариант A) заменил прежнюю PySide6/Qt-оболочку `standkit_gui`
+(удалена целиком): та же роль ("диспетчер на машине оператора"), но без
+тяжёлой GUI-зависимости — браузер универсален, фронтенд отдаёт сам хаб.
+
+Границы зависимостей — принципиальны и проверяются на уровне импортов:
+- `standkit/*`, `standkit_agent/*` и `standkit_hub/*` (серверная часть) —
+  STDLIB-ONLY, никаких сторонних веб-фреймворков/GUI-тулкитов.
+- `standkit_hub/__main__.py` — единственное место, где опционально
+  импортируется `pywebview` (только под `--desktop`, в try/except; при
+  отсутствии extra `[desktop]` хаб печатает понятное сообщение и падает
+  обратно в системный браузер, а не роняется исключением импорта).
+- `standkit` не тянет сторонних пакетов вообще (`dependencies = []` в
+  `pyproject.toml`) — секреты (`standkit/secrets.py`) используют `keyring`
+  только опционально, через `try/except ImportError`.
+- Фронтенд `standkit_hub/web/*` — vanilla JS/CSS, без CDN и без шага сборки
+  (работает офлайн, отдаётся тем же `http.server`, что и API).
+
+## Транспорт: `local` | `agent` (задел `ssh` / `winrm`)
+
+Поле `transport` в записи реестра (`standkit/models.py::Transport`) определяет,
+как ядро/GUI достаёт до конкретного стенда:
+
+- `local` — стенд поднимается тем же процессом, что вызывает `standkit`
+  (`standkit/lifecycle.py` поверх `standkit/platform.py`, headless-процесс
+  через `subprocess`).
+- `agent` — управление идёт по HTTP к `standkit_agent`, слушающему на
+  `agent_url`, с Bearer-токеном, разрешаемым через `agent_secret_ref`
+  (Secret-first, см. `standkit/secrets.py`).
+- `ssh` / `winrm` — **схема допускает** эти значения (см.
+  `projects.sample.json`, запись `example-future-ssh`), но логика НЕ
+  реализована: `Stand.from_dict` толерантен к неизвестным будущим значениям
+  (не роняет чтение реестра), а код, требующий конкретный транспорт
+  (`lifecycle._require_local`, `client.FederatedClient._dispatch_action`),
+  явно бросает `NotImplementedError`/`LifecycleError` для нереализованных
+  транспортов, а не тихо делает не то.
+
+## Кроссплатформенность
+
+- Все пути — `pathlib.Path`, без хардкода `C:\...`.
+- Запуск процесса стенда (`standkit/platform.py::spawn_hidden`) — раздельные
+  ветки для `sys.platform == "win32"` (скрытое консольное окно,
+  `CREATE_NO_WINDOW` + отдельная группа процессов) и POSIX
+  (`start_new_session=True`, эквивалент `setsid`).
+- `standkit_agent` — только `stdlib` (`http.server`, `subprocess`, `socket`,
+  `urllib`), потому что стенды BPMSoft на .NET штатно живут и под Linux, а
+  агент должен разворачиваться на голом хосте без сборки колёс под
+  конкретную ОС/архитектуру.
+- Деплой агента как службы ОС — раздельные шаблоны:
+  `standkit_agent/deploy/standkit-agent.service` (systemd, Linux) и
+  `standkit_agent/deploy/windows-service.md` (заметки NSSM/Task
+  Scheduler/pywin32, Windows).
+
+## Границы free (MIT) / paid
+
+`standkit` — воронка на платный продукт **BPMkit**. Разделительная линия:
+
+| В standkit (MIT, бесплатно)                        | В BPMkit (платно)                                  |
+|-----------------------------------------------------|-----------------------------------------------------|
+| start/stop/restart headless-процесса стенда          | Провижининг нового стенда "с нуля" (`provision_stand`) |
+| Health-пробы: процесс/HTTP/TCP-порт БД и Redis        | Глубокие БД-операции (`db_create/restore/backup`)     |
+| Tail/follow лог-файла                                | Деплой пакетов (WSC/UBS), кастомизация JS/C#          |
+| Реестр стендов (чтение/запись `projects.json`)        | Генерация документов, git-онбординг пакетов стенда    |
+| Secret-first доступ к секретам (обёртка над keyring)  | Административные операции над живым стендом (ESQ, роли, права) |
+
+`standkit.registry.Registry.add_existing()` — это **привязка уже
+существующего стенда** к реестру standkit, не провижининг: каталог/БД/
+дистрибутив должны существовать заранее. Полноценный провижининг —
+исключительно зона BPMkit.
+
+## Что уже реализовано в каркасе vs TODO
+
+Рабочая минимальная логика, покрытая тестами: `standkit/models.py`,
+`standkit/registry.py`, `standkit/health.py` (быстрые пробы: `tcp_open`,
+`http_ok`, `process_alive`). Скелетные модули с явными `TODO` в докстрингах:
+`standkit/lifecycle.py` (нет graceful stop с эскалацией SIGKILL/таймаутом),
+`standkit/platform.py` (нет Job Object на Windows, нет double-fork на Linux),
+`standkit/health.py::db_deep_check/redis_deep_check` (заглушки — требуют
+опциональных зависимостей `psycopg2`/`pyodbc`/`redis-py`), `standkit_hub`
+(опрос стендов — по кнопке "Обновить"/интервалу polling из фронтенда, а не
+push/SSE; live follow лога — TODO, сейчас только периодический tail).
+
+`standkit_agent` прошёл прод-харденинг (см. `standkit_agent/security.py`,
+`standkit_agent/audit.py`, README.md → раздел «Безопасность»): TLS/mTLS,
+fail-closed bind-defaults (loopback-only без явного `--insecure`), скоупы
+control/readonly с `hmac.compare_digest`, rate limiting/lockout по IP,
+структурный аудит-лог, input-hardening. Осознанно не реализовано (TODO):
+полноценная PKI/ротация сертификатов и токенов "на лету", per-stand ACL
+(сейчас скоуп бинарный на уровне всего реестра агента), CN→scope маппинг для
+mTLS. Деплой-шаблоны (`standkit_agent/deploy/`) обновлены под least privilege
+(systemd sandboxing, выделенный не-root сервисный аккаунт на Windows).

standkit-0.5.0/docs/HOSTING.md

@@ -0,0 +1,165 @@
+# Виды хостинга стенда (`host_kind`)
+
+Как стенд BPMSoft **хостится** на своей машине — отдельное измерение от того,
+**где** им управлять (`transport`: `local`/`agent`). Полный дизайн — см.
+[ADR-0001](adr/0001-hosting-backends.md).
+
+| `transport` | *где* управлять стендом | local — процессом самого standkit; agent — через удалённый `standkit_agent` |
+|---|---|---|
+| `host_kind` | *как* стенд хостится | kestrel / iis / docker / k8s |
+
+Оба поля независимы: например, `transport=agent` + `host_kind=docker` — это
+удалённый контейнер, которым управляет агент на своём хосте.
+
+## `host_kind` и связанные поля
+
+По умолчанию `host_kind = "kestrel"` (текущее поведение standkit — headless
+`dotnet <stand_dll>` + pidfile). Неизвестное/будущее значение `host_kind` в
+реестре не роняет чтение — откатывается на `kestrel`.
+
+| `host_kind` | Поле | Обязательность | Назначение |
+|---|---|---|---|
+| `iis` | `iis_site` | одно из двух (`iis_site` и/или `iis_app_pool`) | имя IIS-сайта |
+| `iis` | `iis_app_pool` | одно из двух | имя Application Pool (приоритетно для recycle/state) |
+| `iis` | `iis_stdout_log_dir` | опционально | папка stdout-логов ASP.NET Core (иначе `<stand_dir>\logs`) |
+| `docker` | `docker_container` | контейнер ИЛИ compose-пара | имя/ID контейнера (одиночный режим) |
+| `docker` | `docker_compose_file` | вместе с `docker_compose_service` | путь к compose-файлу |
+| `docker` | `docker_compose_service` | вместе с `docker_compose_file` | имя сервиса в compose |
+| `k8s` | `k8s_deployment` | обязательно | имя Kubernetes Deployment |
+| `k8s` | `k8s_namespace` | опционально (пусто → `default`) | namespace кластера |
+| `k8s` | `k8s_context` | опционально (пусто → текущий контекст kubeconfig) | контекст kubectl |
+| `k8s` | `k8s_container` | опционально | имя контейнера в поде (для `read_logs` при нескольких контейнерах) |
+| `k8s` | `k8s_replicas` | опционально, по умолчанию `1` | число реплик при `start` |
+
+`Stand.validate()` проверяет обязательность этих полей для `iis`/`docker`/`k8s`.
+
+## Примеры реестра
+
+### IIS
+
+```json
+{
+  "example-iis": {
+    "transport": "local",
+    "host_kind": "iis",
+    "iis_site": "BPMSoft-example-iis",
+    "iis_app_pool": "BPMSoft-example-iis-pool",
+    "iis_stdout_log_dir": "C:\\inetpub\\wwwroot\\example-iis\\logs",
+    "stand_dir": "C:\\inetpub\\wwwroot\\example-iis",
+    "stand_host": "127.0.0.1",
+    "stand_port": 5000
+  }
+}
+```
+
+### Docker (одиночный контейнер)
+
+```json
+{
+  "example-docker": {
+    "transport": "local",
+    "host_kind": "docker",
+    "docker_container": "bpmsoft-example-docker",
+    "stand_dir": "/opt/bpmsoft/example-docker",
+    "stand_host": "127.0.0.1",
+    "stand_port": 5000
+  }
+}
+```
+
+### Docker (compose-сервис)
+
+```json
+{
+  "example-docker-compose": {
+    "transport": "local",
+    "host_kind": "docker",
+    "docker_compose_file": "/opt/bpmsoft/example/docker-compose.yml",
+    "docker_compose_service": "webhost",
+    "stand_dir": "/opt/bpmsoft/example",
+    "stand_host": "127.0.0.1",
+    "stand_port": 5000
+  }
+}
+```
+
+### Kubernetes (k8s)
+
+```json
+{
+  "example-k8s": {
+    "transport": "local",
+    "host_kind": "k8s",
+    "k8s_namespace": "bpmsoft",
+    "k8s_deployment": "bpmsoft-example-k8s",
+    "k8s_context": "example-cluster",
+    "k8s_container": "webhost",
+    "k8s_replicas": 1,
+    "stand_dir": "/opt/bpmsoft/example-k8s",
+    "stand_host": "127.0.0.1",
+    "stand_port": 5000
+  }
+}
+```
+
+Полный образец схемы — [`projects.sample.json`](../projects.sample.json)
+(записи `example-iis`, `example-docker`, `example-k8s`).
+
+## Что делается «под капотом»
+
+Диспетчеризация — `standkit.lifecycle` (start/stop/restart/is_running) и
+`standkit.hosting.get_backend(stand)`:
+
+- **kestrel** — без изменений: `dotnet <stand_dll>` + pidfile
+  (`standkit.lifecycle`/`standkit.platform`).
+- **iis** — через `appcmd.exe`
+  (`%windir%\system32\inetsrv\appcmd.exe`):
+  - старт: `start apppool /apppool.name:<pool>` и/или `start site /site.name:<site>`;
+  - стоп: `stop apppool` / `stop site`;
+  - рестарт: `recycle apppool /apppool.name:<pool>` (graceful) либо stop+start сайта;
+  - проверка «жив»: `list apppool <pool> /text:state` → `Started`; иначе по сайту;
+    фолбэк — открытый TCP-порт стенда.
+- **docker** — через CLI `docker` / `docker compose`:
+  - одиночный контейнер: `docker start|stop|restart <container>`,
+    `docker inspect -f "{{.State.Running}}" <container>`,
+    `docker logs --tail N <container>`;
+  - compose-сервис: `docker compose -f <file> up -d|stop|restart <service>`,
+    состояние — парсинг `docker compose -f <file> ps`,
+    логи — `docker compose -f <file> logs --tail N <service>`.
+- **k8s** — через CLI `kubectl` (базовые аргументы — `kubectl [--context
+  <k8s_context>] -n <k8s_namespace|default>`):
+  - старт: `... scale deployment/<deployment> --replicas=<k8s_replicas|1>`;
+  - стоп: `... scale deployment/<deployment> --replicas=0` (в Kubernetes нет
+    отдельной команды "остановить" — общепринятый эквивалент "стопа");
+  - рестарт: `... rollout restart deployment/<deployment>`;
+  - проверка «жив»: `... get deployment <deployment> -o
+    jsonpath={.status.readyReplicas}` → число > 0; фолбэк — открытый TCP-порт
+    стенда;
+  - логи: `... logs deployment/<deployment> --tail N [-c <k8s_container>]`.
+
+Health-проба «процесс» (`standkit.health.check_stand`) для `iis`/`docker`/`k8s`
+консультируется с соответствующим бэкендом, с сохранением фолбэка на TCP-порт
+стенда (если бэкенд не подтвердил «жив», но порт открыт — стенд считается
+живым: он может быть поднят и вручную).
+
+## Требования
+
+- **IIS**: платформа — только Windows; агент/служба standkit должна иметь
+  права на управление IIS (обычно — членство в группе `IIS_IUSRS` недостаточно,
+  нужны права на `appcmd.exe`/WAS, см. документацию IIS по правам на удалённое
+  администрирование). Живая приёмка — на стенде с реальным IIS.
+- **Docker**: установленный Docker Engine (`docker` в PATH процесса
+  standkit); для compose-режима — плагин `docker compose` (Compose V2).
+- **Kubernetes**: установленный `kubectl` в PATH процесса standkit и
+  доступный kubeconfig/контекст (переменная `KUBECONFIG` либо
+  `~/.kube/config`) с правами на `get`/`scale`/`rollout`/`logs` над
+  Deployment в указанном namespace.
+
+## Ограничения
+
+- UI-индикатор `host_kind` в дашборде `standkit_hub` — вне зоны ADR-0001
+  (бэклог).
+
+См. также: [ADR-0001](adr/0001-hosting-backends.md),
+[REMOTE_STANDS.md](REMOTE_STANDS.md) (транспорт `agent`, ортогонален
+`host_kind`).