docs: WinRM RDP update flow and SAC 0.20.18 deployment notes

Обновлены README и руководства по fallback WinRM (git→zip→клиент), SAC_PUBLIC_URL и краткому 502 при деплое.

docs/agent-control-plane.md

@@ -166,12 +166,18 @@ sequenceDiagram
 
 ### 4.3. B2 — Fallback (SSH / WinRM)
 
-Если за **N минут** нет `agent.update.*` или статус `failed`:
+Кнопка на карточке хоста: **«Обновить через WinRM»** / **«Fallback SSH»** (`POST .../actions/agent-update-fallback`). Лог операции — модалка сразу при старте (не ждёт конца).
 
-| OS | Метод | Credentials |
-|----|--------|-------------|
-| Linux | SSH из SAC | ключ после bootstrap (§5) |
-| Windows | WinRM | encrypted login/password в БД |
+Если за **N минут** нет `agent.update.*` или статус `failed` — тот же fallback может сработать автоматически (если включён в настройках).
+
+| OS | Метод | Credentials | Как работает (SAC 0.20.18+) |
+|----|--------|-------------|------------------------------|
+| Linux | SSH | ключ после bootstrap (§5) | SAC передаёт `REPO_URL` / `GIT_BRANCH` из **Настройки → Обновления агентов** в `update_ssh_monitor.sh` (не дефолт GitHub на хосте) |
+| Windows | WinRM | encrypted login/password в БД | 1) SAC `git fetch` RDP-login-monitor на сервере → zip с UTF-8 BOM для `.ps1`<br>2) Клиент по WinRM: `Invoke-WebRequest` → `https://<SAC_PUBLIC_URL>/api/v1/agent/rdp-bundle/<token>`<br>3) Распаковка в `C:\ProgramData\RDP-login-monitor\_sac_staging`<br>4) `Deploy-LoginMonitor.ps1 -SourceShareRoot` (файлы в `ProgramData\RDP-login-monitor\`) |
+
+**Windows — требования:** domain admin в **Настройки → Управление хостами → Windows**; `rdp_git_repo_url` в **Обновления агентов**; ПК должен открывать `SAC_PUBLIC_URL` (HTTPS). **Git на клиенте не нужен.** GPO/NETLOGON по-прежнему основной путь в режиме GPO.
+
+**nginx:** для `agent-update-fallback` и SSH/WinRM-тестов — `proxy_read_timeout 960s` (см. `deploy/nginx/sac.conf.tls.example`).
 
 ---
 
@@ -285,7 +291,7 @@ Authorization: Bearer sac_xxx
 | **4** | WinRM qwinsta с сервера SAC | ✅ |
 | **5** | Settings «Обновления агентов», SSH bootstrap | частично ✅ |
 | **6** | Self-update B1 | ⏳ |
-| **7** | SSH bootstrap + WinRM fallback | ⏳ |
+| **7** | SSH bootstrap + WinRM fallback | частично ✅ (SSH/WinRM update из UI, git URL из настроек) |
 | **8** | Desired config per host | ⏳ |
 
 **Миграция:** `016_agent_commands`. Env: `SAC_RDG_FLAP_*`, `SAC_WIN_ADMIN_USER`, `SAC_WIN_ADMIN_PASSWORD`.

docs/deployment.md

@@ -113,6 +113,10 @@ curl -sS https://sac.kalinamall.ru/health
 sudo /opt/sac-deploy.sh
 ```
 
+Краткий **502 Bad Gateway** в UI (~10 с) возможен при перезапуске `sac-api` — список хостов автоматически повторяет запрос; после деплоя обновите страницу.
+
+**Важно в `sac-api.env`:** `SAC_PUBLIC_URL=https://sac.kalinamall.ru` — нужен для WinRM-обновления RDP (клиент скачивает zip с SAC). API: **2 worker** uvicorn (`deploy/systemd/sac-api.service`).
+
 Установка скрипта (один раз): `sudo cp /opt/security-alert-center/deploy/sac-deploy.sh /opt/sac-deploy.sh && sudo chmod 755 /opt/sac-deploy.sh`
 
 После **force-push** на upstream remote обычный `git pull` на сервере падает с «diverging branches». Скрипт `sac-deploy.sh` (актуальная версия) делает `fetch` и при необходимости `reset --hard` к upstream. **Один раз вручную**, если на сервере ещё старый скрипт: