feat(detmir): ship ops, dlp, 1c and mcp updates

docs/1C_AI_INVESTIGATOR_RUNTIME_RU.md

@@ -98,6 +98,7 @@ File 1C / Windows RDP host
 На `10.10.10.2:8710` уже работают human-facing страницы:
 
 - `/manager/brief`
+- `/manager/actions`
 - `/manager/changes`
 - `/manager/trends/weekly`
 - `/manager/digest/weekly`
@@ -112,6 +113,7 @@ File 1C / Windows RDP host
 Это страницы для руководителя с:
 
 - headline;
+- очередью конкретных действий по компаниям;
 - summary;
 - top risks;
 - top changes;
@@ -216,6 +218,12 @@ File 1C / Windows RDP host
 ### Grafana
 
 - `http://10.10.10.11:3000/dashboards/f/file-1c/?orgId=1`
+- management board:
+  - `http://10.10.10.11:3000/d/1c-file-mgmt/1c-file-management-board`
+- financial reporting:
+  - `http://10.10.10.11:3000/d/1c-file-finance/1c-file-financial-reporting`
+- telemetry board:
+  - `http://10.10.10.11:3000/d/1c-file-telemetry/1c-file-telemetry-board`
 - company intelligence:
   - `http://10.10.10.11:3000/d/1c-file-companies/1c-file-company-intelligence`
 
@@ -233,12 +241,20 @@ File 1C / Windows RDP host
 - `GET /api/1/analytics-1c/companies/overview`
 - `GET /api/1/analytics-1c/companies/{company}/summary`
 - `GET /api/1/analytics-1c/companies/{company}/forecast`
+- `GET /api/1/analytics-1c/companies/{company}/actions`
+- `GET /api/1/analytics-1c/manager/actions`
+- `GET /api/1/analytics-1c/manager/actions/companies`
 - `GET /api/1/analytics-1c/manager/brief/latest`
 - `GET /api/1/analytics-1c/manager/brief/delta/latest`
 - `GET /api/1/analytics-1c/manager/trends/weekly`
 - `GET /api/1/analytics-1c/manager/digest/weekly/latest`
 - `GET /api/1/analytics-1c/manager/recovery/latest`
 
+Manager action API работает в enterprise-first режиме:
+
+- `priority_model=enterprise_risk`
+- `owner_mode=secondary_operational_metadata`
+
 ## Главная граница
 
 Контур deliberately построен как `read-only`.

docs/1C_BUSINESS_EVENT_LAYER_RU.md

@@ -122,6 +122,7 @@
 - внешние реестры и справочники;
 - audit/export критичных изменений;
 - отдельные read-only файлы, формируемые рядом с 1С.
+- `1c-mcp-toolkit` REST API через `execute_query` и `get_event_log`.
 
 Не подходящие по умолчанию:
 
@@ -183,6 +184,12 @@
   - `etl/build_business_event_exports.py`
   - собирает canonical events из существующих read-only выгрузок
     `documents/postings/audit`
+- read-only extractor scaffold:
+  - `etl/extract_1c_mcp_toolkit.py`
+  - забирает `companies/documents/postings/business_events/document_changes`
+    через `execute_query`
+  - забирает `reglog` через `get_event_log`
+  - пишет в те же `landing/*`, которые уже понимает loader
 - ingest wiring:
   - normalizer запускается перед `load_1c_exports.py`
 - timeline/detection wiring:
@@ -195,9 +202,33 @@
 Это уже рабочий v1 normalizer, но ещё не конечный extractor со всей
 бухгалтерской глубиной.
 
+## Контракт `1c-mcp-toolkit` extractor
+
+На текущем шаге extractor сознательно ограничен:
+
+- только read-only endpoint'ы;
+- без `execute_code`;
+- с локальным checkpoint state;
+- с `channel` isolation для разделения `dev/prod`.
+
+Практический контракт такой:
+
+1. `execute_query` должен возвращать колонки, алиаснутые под landing-схему.
+2. Если это неудобно, используется `field_map` в `etl/config.yml`.
+3. Для query-datasets можно включать incremental-window через
+   `incremental.since_param` / `incremental.until_param`.
+4. Для `reglog` extractor хранит курсор `last_date +
+   same_second_offset`.
+5. `company_entity_key` достраивается extractor'ом по той же логике,
+   что уже используется в built-in normalizer.
+6. Перед включением live-ingest query-pack должен проходить:
+   - `--validate-config`
+   - `--dry-run`
+   - targeted `--dataset <name>` probe
+
 ## Что делать дальше
 
-1. Реализовать read-only extractor в отдельном модуле.
+1. Подключить production queries под конкретную конфигурацию 1С.
 2. Стабильно наполнять `company_entity_key`.
 3. Добавить первые SQL detections на `business_events`.
 4. Обогащать `entity_timeline` уже не только telemetry/audit, но и

docs/1C_COMPANY_INTELLIGENCE_RU.md

@@ -87,10 +87,14 @@ Endpoints:
 - `GET /api/1/analytics-1c/companies/{counterparty}/summary`
 - `GET /api/1/analytics-1c/companies/{counterparty}/forecast`
 - `GET /api/1/analytics-1c/companies/{counterparty}/timeline`
+- `GET /api/1/analytics-1c/companies/{counterparty}/actions`
+- `GET /api/1/analytics-1c/manager/actions`
+- `GET /api/1/analytics-1c/manager/actions/companies`
 - `GET /api/1/analytics-1c/manager/brief/latest`
 - `GET /api/1/analytics-1c/manager/brief/latest.md`
 - `GET /api/1/analytics-1c/manager/brief/history`
 - `GET /manager/brief`
+- `GET /manager/actions`
 
 `/manager/brief` — это human-facing browser page для руководителя:
 
@@ -101,6 +105,21 @@ Endpoints:
   действия и свежесть источников;
 - даёт быстрые ссылки на raw JSON/Markdown и в Grafana.
 
+Отдельно появился deterministic слой `manager/actions`:
+
+- не зависит от LLM;
+- строится из `v_company_portfolio_overview`, `business_events`,
+  `document_change_events`, `cases`, `detections`;
+- показывает очередь действий вида `компания -> почему -> что делать -> кто
+  отвечает -> насколько срочно`.
+- верхний management-срез теперь enterprise-first:
+  сначала агрегирует необходимые действия по предприятиям, а текущий
+  `owner_name` оставляет вторичным operational metadata.
+- `GET /api/1/analytics-1c/manager/actions` и
+  `GET /api/1/analytics-1c/manager/actions/companies` теперь явно отдают
+  `priority_model=enterprise_risk` и
+  `owner_mode=secondary_operational_metadata`.
+
 ### Executive brief для руководителя
 
 Файлы:

docs/DETMIR_CHANGE_REPORT_LAST_24H_2026-05-26.md

@@ -0,0 +1,299 @@
+# DetMir: Отчет по изменениям за последние 24 часа
+
+Дата фиксации: `2026-05-26 07:55 MSK`
+
+## Источники
+
+- `tmux` session `codex`, scrollback выгружен в `/tmp/codex-tmux-last24.txt`
+- текущий worktree `git status` в `/mnt/usb_hdd2/Projects/ActivityWatch-Russian`
+- live-проверки на:
+  - `10.10.10.2` Proxmox
+  - `10.10.10.11` Grafana
+  - `10.10.10.12` Loki/Alloy
+  - `10.10.10.13` aw-server
+  - `10.10.10.1` pfSense
+  - `192.168.100.18` Windows RDP host
+
+## Важная оговорка
+
+`git log --since='24 hours ago'` пустой: за последние сутки изменения не были оформлены git-коммитами.
+
+Рабочее дерево уже грязное и содержит больше изменений, чем было сделано в этом 24-часовом окне. Поэтому ниже зафиксированы только те изменения, которые явно подтверждаются `tmux`-историей и live-проверками.
+
+## Что было сделано
+
+### 1. Восстановление ActivityWatch-Russian
+
+Симптом:
+- на `10.10.10.13:5600` UI не обновлялся для `SHARKON2025`;
+- `aw-server` был жив, но stale были `aw-watcher-afk`, `aw-watcher-window`, `aw-worktime-sessions`.
+
+Действия:
+- проверен `aw-server` и свежесть bucket’ов;
+- через WinRM на `192.168.100.18` проверены процессы, tasks и recovery-скрипты;
+- запущены:
+  - `ActivityWatch Recovery`
+  - `ActivityWatch Launch [SHARKON2025_user5]`
+- отдельно перезапущен зависший `worktime-session-collector`.
+
+Итог:
+- `aw-watcher-afk`, `aw-watcher-window`, `aw-session-events`, `aw-dlp-endpoint-signals`, `aw-worktime-sessions` снова стали fresh;
+- итоговая серверная сводка: `FRESH=8 STALE=0 DEAD=0`.
+
+### 2. Дополнена авто-сигнализация и самолечение `tsj-guardian-bot`
+
+Проблема:
+- фоновый цикл бота не видел stale AW collector bucket’ы;
+- manual AW-check был отдельным путем и не участвовал в обычном incident/heal flow.
+
+Сделано:
+- в `tsj_guardian_bot.py` добавлен разбор `[FAIL] aw-rus:*`;
+- AW collector freshness включен в стандартный background check cycle;
+- добавлен Windows recovery path для:
+  - `watcher-*`
+  - `worktime-session-collector`
+- добавен server-side rebuild worktime views после Windows remediation;
+- тесты обновлены и прогнаны.
+
+Затронутые файлы:
+- [proxmox/tsj_guardian_bot.py](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/proxmox/tsj_guardian_bot.py)
+- [proxmox/test_tsj_guardian_bot.py](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/proxmox/test_tsj_guardian_bot.py)
+- [ansible/deploy_tsj_guardian_bot_proxmox.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/deploy_tsj_guardian_bot_proxmox.yml)
+- [ansible/group_vars/proxmox-bot.example.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/group_vars/proxmox-bot.example.yml)
+
+Проверка:
+- `python3 -m py_compile proxmox/tsj_guardian_bot.py proxmox/test_tsj_guardian_bot.py`
+- `python3 -m unittest proxmox.test_tsj_guardian_bot`
+- `tsj-guardian-bot.service` перезапускался и работал в `active`.
+
+### 3. Бот переведен на `igor` вместо `codex`
+
+Проблема:
+- production bot был завязан на `AI_EXEC_USER=codex`, `TMUX_USER=codex` и read-only пути под `/home/codex/infra-admin`;
+- это ломало встроенный `codex-cli` support path после перехода на `igor`.
+
+Сделано:
+- переключены:
+  - `AI_EXEC_USER=igor`
+  - `TMUX_USER=igor`
+  - `AI_CHAT_WORKDIR=/home/igor`
+- добавлены настраиваемые:
+  - `PFSENSE_ENV_PATH`
+  - `PFSENSE_INVENTORY_PATH`
+- создан `igor`-readable bundle:
+  - `/home/igor/.config/tsj-bot/pfsense.env.readonly`
+  - `/home/igor/.config/tsj-bot/inventory.md`
+
+Итог:
+- диалоговая техподдержка и AI-эскалация в боте работают от `igor`;
+- bot-side pfSense/inventory контекст больше не зависит от старого `codex`-домика.
+
+### 4. Исправлен сетевой доступ `10.10.10.2 -> 192.168.100.18`
+
+Root cause:
+- на `pfSense 10.10.10.1`, интерфейс `opt1/MGMT`:
+  - allow rule для `10.10.10.2 -> 192.168.100.18:22` был ниже `block all`;
+  - allow rule для `10.10.10.2 -> 10.10.10.1:2022` был ниже `block all`;
+  - rule для `10.10.10.2 -> 192.168.100.18:5985` отсутствовал.
+
+Сделано:
+- подняты нужные allow rules выше `block all`;
+- добавлено недостающее правило на `5985`.
+
+Итог:
+- с `10.10.10.2` подтвержден доступ на:
+  - `10.10.10.1:2022`
+  - `192.168.100.18:22`
+  - `192.168.100.18:5985`
+- SSH вход на `192.168.100.18` под `Администратор` был подтвержден.
+
+### 5. Убрано ложное сообщение “автолечение невозможно”
+
+Причина:
+- в production `.env` бота была повреждена строка `AW_RUS_WORKTIME_HEAL_CMD`;
+- бот слишком жестко реагировал на единичный таймаут worktime CSV.
+
+Сделано:
+- восстановлен `AW_RUS_WORKTIME_HEAL_CMD`;
+- добавлен retry для получения worktime CSV;
+- обновлены дефолты под `igor`.
+
+Итог:
+- `pending_incident = null`;
+- циклы снова идут как `Check OK`.
+
+### 6. Наведен порядок в Grafana folder/dashboard catalog
+
+Изменения:
+- folder `AWatch-rus` переименован в `DLP`;
+- `pfSense System Dashboard` перенесен в folder `pfSense`;
+- `LXC Containers Monitoring` перенесен в folder `LXC`;
+- `Proxmox Influx 2.0 Dashboard` перенесен в folder `LXC`.
+
+### 7. Починен `pfSense Logs Dashboard All Logs`
+
+Проблема была не в Grafana, а в цепочке `pfSense -> Alloy -> Loki`.
+
+Сделано:
+- на `10.10.10.1` поднят `syslogd`;
+- на `10.10.10.12` в Alloy для pfSense syslog включен правильный формат `rfc3164`;
+- отключен stale docker self-scrape path, забивавший `loki.write` старыми batch’ами;
+- перезапущен `alloy`.
+
+Итог:
+- появились живые `job="pfsense"` streams в Loki;
+- дашборд `pfSense Logs Dashboard All Logs` перестал быть пустым.
+
+### 8. Починен `1C File - Operations Health`
+
+Проблема:
+- не обновлялись данные в `1C File - Operations Health`.
+
+Сделано на `192.168.100.18`:
+- exporter больше не падает на недоступных `ibases.v8i`;
+- `export-upload-file-1c-telemetry.ps1` научен брать `remoteKeyPath` из `deployment-config.json`;
+- рабочий ключ закреплен как `C:\Users\USER1\.ssh\awops_ed25519`;
+- исправлены права к `file1c-telemetry-state.json`.
+
+Сделано на `10.10.10.2`:
+- прогнан ingest;
+- `proofcheck` выведен в green.
+
+Затронутые файлы:
+- [windows/export-upload-file-1c-telemetry.ps1](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/windows/export-upload-file-1c-telemetry.ps1)
+- [ansible/deploy_file_1c_windows_telemetry.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/deploy_file_1c_windows_telemetry.yml)
+
+Итог:
+- `1C File - Operations Health` снова обновляется;
+- свежесть downstream была подтверждена через ingest и proofcheck.
+
+### 9. Рабочие ключи выданы всем пользователям Windows-хоста
+
+Сделано:
+- ключ `awops_ed25519` разложен по локальным профилям:
+  - `USER1`
+  - `USER2`
+  - `USER3`
+  - `USER4`
+  - `USER5`
+  - `Администратор`
+- `remoteKeyPath` перестал быть жестко привязан только к `USER1`;
+- права на `file1c-telemetry-state.json` выданы рабочим пользователям.
+
+Итог:
+- схема больше не зависит от одного профиля;
+- scheduled upload path продолжает работать.
+
+### 10. Поднят management board по файловой 1С
+
+Сделано:
+- добавлен новый Grafana dashboard `1C File - Management Board`;
+- обновлены manager brief links и gateway route.
+
+Live-итог:
+- `uid=1c-file-mgmt`
+- `go/grafana-1c` редиректит на новый board
+
+### 11. Поднят первый financial board по файловой 1С
+
+Сделано:
+- добавлен SQL слой:
+  - [clickhouse-1c/clickhouse/init/05_financial_reporting.sql](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/clickhouse/init/05_financial_reporting.sql)
+- добавлен dashboard:
+  - [clickhouse-1c/grafana/provisioning/dashboards/files/1c-financial-reporting.json](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/grafana/provisioning/dashboards/files/1c-financial-reporting.json)
+- обновлен gateway route:
+  - `go/file1c-finance`
+
+Итог:
+- financial screen работает как честный transitional layer;
+- live readiness была `proxy_only`;
+- `postings_table_rows = 0`, то есть настоящие проводки еще не поступают.
+
+### 12. Проведено расследование production-source для `postings`
+
+Что подтверждено на `192.168.100.18`:
+- готового `toolkit`/REST/service под postings нет;
+- порт `6003` и типовые service-порты не слушаются;
+- текущий Windows upload path шлет только telemetry/snapshot, без `postings`.
+
+Что проверено:
+- наличие `1C 8.3.27` и `comcntr.dll`;
+- COMConnector в user-token path;
+- интерактивные scheduled tasks под `USER1`;
+- явные 1С-креды:
+  - `Администратор / Sergei2009@`
+  - `user / Sergei2009@`
+  - `user1 / Sergei2009@`
+
+Итог:
+- blocker остался прежним: нужен реальный пользователь 1С с read-only доступом;
+- без него production extractor проводок не собрать.
+
+### 13. Поднят отдельный `1C File - Telemetry Board`
+
+Сделано:
+- добавлен новый dashboard:
+  - [clickhouse-1c/grafana/provisioning/dashboards/files/1c-telemetry-board.json](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/grafana/provisioning/dashboards/files/1c-telemetry-board.json)
+- добавлена ссылка на него из `1C File - Management Board`;
+- добавлен gateway route:
+  - `go/file1c-telemetry`
+
+Live-итог:
+- в Grafana зарегистрирован `uid=1c-file-telemetry`;
+- все 1C dashboards лежат в folder `1C File Analytics`;
+- `https://10.10.10.2/go/file1c-telemetry` редиректит на новый board.
+
+### 14. Live-путь `1C File Analytics` в Grafana был приведен к устойчивому состоянию
+
+Выяснилось:
+- file-based provisioning на `10.10.10.11` не был основной точкой для 1C dashboards;
+- текущие `file-1c` dashboards жили в DB Grafana.
+
+Сделано:
+- на CT201 добавлен отдельный provisioning provider `1C File Analytics`;
+- в него выложены:
+  - `1c-management-board.json`
+  - `1c-telemetry-board.json`
+- `grafana-server` перезапущен;
+- через SQLite БД Grafana подтверждено наличие:
+  - `1c-file-mgmt`
+  - `1c-file-finance`
+  - `1c-file-ops`
+  - `1c-file-telemetry`
+  - folder `file-1c / 1C File Analytics`
+
+## Файлы, которые точно редактировались в этом окне по данным tmux
+
+- [proxmox/tsj_guardian_bot.py](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/proxmox/tsj_guardian_bot.py)
+- [proxmox/test_tsj_guardian_bot.py](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/proxmox/test_tsj_guardian_bot.py)
+- [ansible/deploy_tsj_guardian_bot_proxmox.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/deploy_tsj_guardian_bot_proxmox.yml)
+- [ansible/group_vars/proxmox-bot.example.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/group_vars/proxmox-bot.example.yml)
+- [windows/export-upload-file-1c-telemetry.ps1](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/windows/export-upload-file-1c-telemetry.ps1)
+- [ansible/deploy_file_1c_windows_telemetry.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/deploy_file_1c_windows_telemetry.yml)
+- [clickhouse-1c/clickhouse/init/05_financial_reporting.sql](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/clickhouse/init/05_financial_reporting.sql)
+- [ansible/deploy_proxmox_web_gateway.yml](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/ansible/deploy_proxmox_web_gateway.yml)
+
+Новые dashboard JSON, подтвержденные live-выкладкой:
+- [clickhouse-1c/grafana/provisioning/dashboards/files/1c-financial-reporting.json](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/grafana/provisioning/dashboards/files/1c-financial-reporting.json)
+- [clickhouse-1c/grafana/provisioning/dashboards/files/1c-management-board.json](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/grafana/provisioning/dashboards/files/1c-management-board.json)
+- [clickhouse-1c/grafana/provisioning/dashboards/files/1c-telemetry-board.json](/mnt/usb_hdd2/Projects/ActivityWatch-Russian/clickhouse-1c/grafana/provisioning/dashboards/files/1c-telemetry-board.json)
+
+## Проверки, которые были явно пройдены
+
+- `python3 -m py_compile proxmox/tsj_guardian_bot.py proxmox/test_tsj_guardian_bot.py`
+- `python3 -m unittest proxmox.test_tsj_guardian_bot`
+- `./check-aw-full.sh` дал `FRESH=8 STALE=0 DEAD=0`
+- gateway deploy на Proxmox прошел успешно
+- `go/file1c-telemetry` отдает `302` на Grafana
+- SQLite Grafana подтвердил наличие `1c-file-telemetry` в folder `1C File Analytics`
+
+## Незафиксированные в git риски
+
+- коммитов за последние 24 часа нет;
+- есть значительный dirty worktree за пределами этого отчета;
+- часть новых файлов все еще `??` в `git status`;
+- без отдельного git-упорядочивания следующий человек может смешать сегодняшние изменения с более старыми незакоммиченными правками.
+
+## Следующий жесткий шаг
+
+Если цель именно финансовая отчетность по проводкам, нужен отдельный read-only пользователь 1С для боевых файловых баз. Это единственный текущий внешний blocker, который не решается локальным refactor/deploy.

docs/DETMIR_POWERSHELL_MCP_REMOTE_RU.md

@@ -0,0 +1,115 @@
+# DetMir PowerShell MCP Remote
+
+## Что это
+
+Канонический путь для интерактивной PowerShell-работы с `DetMir` Windows-хостом `192.168.100.18` из Linux/Codex.
+
+Это не замена `WinRM` в Ansible. Разделение теперь такое:
+
+- `Ansible deploy / validation` — через `WinRM` (`5985`);
+- `PowerShell MCP / operator shell / Codex` — через `SSH` (`22`) на том же хосте.
+
+## Зафиксированная целевая Windows
+
+Проверено на `2026-05-26`:
+
+- host: `192.168.100.18`
+- product: `Windows Server 2025 Datacenter Evaluation`
+- release: `24H2`
+- build: `10.0.26100.32690`
+- remote PowerShell: `5.1.26100.32684`
+- `sshd`: `Running`
+
+## Почему не WSMan
+
+На текущем Linux admin-host локальный `pwsh 7.6.1` не поднимает `New-PSSession` к этому Windows-хосту без отдельного WSMan client stack (`libpsrpclient` / `PSWSMan`).
+
+Практический вывод для DetMir:
+
+- не строить interactive MCP-путь вокруг `WSMan`;
+- считать `SSH + powershell.exe` каноническим transport для локального `powershell-windows`;
+- `WinRM` оставить для Ansible playbook-ов и коротких Windows-probes.
+
+## Файлы проекта
+
+- profile snippet: `scripts/powershell/detmir-powershell-profile.ps1`
+- local config template: `scripts/powershell/detmir-windows.psd1.example`
+- installer: `scripts/install_detmir_powershell_mcp.sh`
+
+Локальные файлы после установки:
+
+- `~/.config/powershell/Microsoft.PowerShell_profile.ps1`
+- `~/.config/powershell/detmir-windows.psd1`
+
+`detmir-windows.psd1` должен оставаться локальным секретным файлом с правами `600`.
+
+## Установка
+
+Из корня проекта:
+
+```bash
+bash scripts/install_detmir_powershell_mcp.sh
+```
+
+Installer:
+
+- прописывает loader в локальный PowerShell profile;
+- создаёт `~/.config/powershell/detmir-windows.psd1`, если его ещё нет;
+- пытается заполнить `Host/User/Password` из `ansible/inventory.ini` группы `[aw_windows]`;
+- если inventory не подходит, оставляет template со значением `CHANGE_ME`.
+
+После установки:
+
+- переоткрыть `pwsh`, либо
+- перезапустить Codex session, чтобы `powershell-windows` перечитал профиль.
+
+## Рабочие команды
+
+В локальном `pwsh` и в `powershell-windows` MCP:
+
+```powershell
+detmir-win-test
+detmir-win-ps '$PSVersionTable.PSVersion.ToString(); hostname; Get-Date -Format o'
+detmir-win-ps 'Get-Service sshd | Select-Object Status,Name'
+detmir-win-shell
+```
+
+Назначение:
+
+- `detmir-win-test` — быстрый smoke-test удалённого PowerShell;
+- `detmir-win-ps` — выполнить PowerShell-скрипт на `192.168.100.18`;
+- `detmir-win-shell` — открыть raw SSH shell на Windows-хост;
+- `detmir-win-ssh` — выполнить произвольную SSH-команду одной строкой;
+- `detmir-win-target` — показать текущий target.
+
+## Быстрая проверка
+
+Ожидаемый ответ:
+
+```powershell
+detmir-win-test
+```
+
+```text
+5.1.26100.32684
+Microsoft Windows NT 10.0.26100.0
+Windows Server 2025 Datacenter Evaluation
+```
+
+## Операторское правило
+
+Если нужен:
+
+- массовый deploy toolkit;
+- validation через playbook;
+- работа с `ansible aw_windows`;
+
+использовать `WinRM`.
+
+Если нужен:
+
+- интерактивный PowerShell из Linux;
+- запуск удалённых PowerShell-скриптов из Codex/MCP;
+- быстрая operator automation без `pywinrm`;
+
+использовать `SSH`-путь из этого документа.

docs/DETMIR_UNIFIED_OPERATING_MODEL_RU.md

@@ -0,0 +1,356 @@
+# DetMir: Единая рабочая модель системы
+
+Дата фиксации: `2026-05-24`
+
+Этот файл предназначен как единая рабочая опора по `DetMir`: что именно входит в систему, где это живет, каким инструментарием проект надо планировать и сопровождать, и какой операционный контур считать промышленным.
+
+Если старые документы расходятся с этим файлом по адресам или runtime-ролям, для текущей эксплуатации приоритет у этого файла.
+
+## 1. Назначение
+
+`DetMir` в этом репозитории это не только `ActivityWatch Server`.
+Это полный production-контур:
+
+- сбор активности и DLP-сигналов с Windows/RDP;
+- сервер `AW-rus` с RU WebUI, API, health и management-отчетами;
+- операторский узел `Proxmox/DetMirAuto`;
+- сетевой контур `pfSense + OpenVPN`;
+- Telegram bot для инцидентов, auto-heal, recovery и операционных команд;
+- `Hayabusa` как DFIR enrichment слой;
+- визуализация и аналитика в `Grafana`;
+- отдельный `1C/file analytics` контур через `ClickHouse/Grafana/API`.
+
+Цель проекта:
+
+- держать рабочий production-контур без дрейфа между кодом, runtime и документацией;
+- обеспечивать управляемый deploy, health-check, auto-heal и incident response;
+- поддерживать дальнейшее развитие без разрушения текущей рабочей системы.
+
+## 2. Текущий подтвержденный runtime
+
+Ниже не историческая схема, а рабочая опорная карта.
+
+| Узел | Роль |
+|---|---|
+| `10.10.10.1` | `pfSense`, firewall, VPN, ACL, OpenVPN export target |
+| `10.10.10.2` | `Proxmox/DetMirAuto`, web gateway, Telegram bot, operator entrypoint |
+| `10.10.10.13` | основной `AW-rus` server, health, worktime/reporting, `Hayabusa` server-side processing |
+| `192.168.100.18` | `SHARKON2025`, Windows/RDP host, collectors, worktime session path, EVTX export |
+
+Практический вывод:
+
+- серверный путь `AW-rus` сейчас должен считаться `10.10.10.13`;
+- операторский и gateway-контур должен считаться `10.10.10.2`;
+- Windows production-host для `DetMir` сейчас `192.168.100.18`, а не старые упоминания `192.168.100.21`.
+
+## 3. Полный функциональный состав DetMir
+
+### 3.1 Ядро AW-rus
+
+| Функция | Где реализована |
+|---|---|
+| ActivityWatch API и WebUI | `aw-server/`, `activitywatch-server.service` |
+| RU WebUI patch | `aw-server/`, `docs/FULL_DEPLOYMENT_MANUAL_RU.md` |
+| DLP overlay в WebUI | `aw-server/`, buckets `aw-dlp-review_*`, `aw-dlp-rules_*` |
+| Health daemon | `aw-server/aw-rus-healthd.py` |
+| Расширенный health-check | `aw-server/health-check.sh`, `check-aw-full.sh`, `check-aw-data.sh` |
+| Management/worktime reports | server-side API на `:5610`, `docs/runbook.md`, `docs/worktime_aql_detmir.md` |
+
+### 3.2 Windows/RDP контур
+
+| Функция | Где реализована |
+|---|---|
+| Массовый deploy | `windows/deploy-domain-users.ps1`, `windows/deploy-ensemble.ps1` |
+| Single-user deploy | `windows/deploy-single-user.ps1` |
+| Validation | `windows/validate-deployment.ps1` |
+| Recovery/hardening | `windows/hardening-recovery.ps1` |
+| AFK/window watchers | `ActivityWatch` watchers + scheduled tasks |
+| Browser domains | `windows/browser-domains-native-collector.ps1` |
+| DLP endpoint signals | `windows/dlp-endpoint-signals-collector.ps1` |
+| Email/DLP path | `windows/email-outbound-collector.ps1` |
+| Worktime session presence | `windows/worktime-session-collector.ps1` |
+| Incident artifacts / screenshots / EVTX export | `windows/export-evtx-for-hayabusa.ps1` и related runtime scripts |
+
+### 3.3 DLP и расследование
+
+| Функция | Где реализована |
+|---|---|
+| Endpoint DLP сигналы | bucket `aw-dlp-endpoint-signals_*` |
+| DLP incidents | bucket `aw-dlp-incidents_*` |
+| Review/rules operator flow | buckets `aw-dlp-review_*`, `aw-dlp-rules_*`, WebUI overlay |
+| DLP report/scheduler | `aw-server` runtime + tests/docs |
+| Transport/self-test telemetry | `aw-health-check` и Windows transport telemetry |
+| Incident follow-up | operator path + `Hayabusa` enrichment |
+
+### 3.4 Worktime и managerial layer
+
+| Функция | Где реализована |
+|---|---|
+| Presence по RDP-сессиям | bucket `aw-worktime-sessions_*` |
+| Работа по окнам/AFK | buckets `aw-watcher-window_*`, `aw-watcher-afk_*` |
+| Web category worktime | bucket `aw-detmir-web-category_*` |
+| AQL-шаблоны | `docs/worktime_aql_detmir.md` |
+| Management report API | `:5610/reports/worktime/management` |
+| Owner/department reporting | aliases и manager-facing filters в server-side report layer |
+
+### 3.5 Proxmox / operator / bot
+
+| Функция | Где реализована |
+|---|---|
+| LXC/bootstrap/deploy | `proxmox/create-ct.sh`, `proxmox/push-aw-artifacts.sh`, `ansible/` |
+| Telegram incident bot | `proxmox/tsj_guardian_bot.py` |
+| Auto-heal и recovery path | `tsj_guardian_bot.py`, `.planning/phases/02-operator-bot-recovery/` |
+| OpenVPN config generation/export | `proxmox/pfsense_openvpn_client_export.php`, bot runtime |
+| Proxmox restore/snapshot operator flow | bot pending restore flow + playbooks/runtime |
+| Web gateway / internal entrypoint | `docs/runbook.md`, nginx/gateway rollout |
+
+### 3.6 pfSense / network / VPN
+
+| Функция | Где реализована |
+|---|---|
+| Firewall/ACL | `pfSense` ruleset |
+| OpenVPN user access | `pfSense` + bot export path |
+| pfSense telemetry в AW | `pfsense/pfsense-aw-poller.py`, `docs/pfsense.md` |
+| Buckets `aw-pfsense-*` | health/interfaces/gateways |
+| Routing between server and Windows | `pfSense` rules, не Windows-local hacks |
+
+### 3.7 Форензика Windows логов (Hayabusa)
+
+| Функция | Где реализована |
+|---|---|
+| EVTX export на Windows | `windows` runtime/export scripts |
+| Intake на сервере | `10.10.10.13`, drop/inbox flow |
+| Processing/reporting | `aw-hayabusa`, `/opt/hayabusa`, server-side services |
+| Bounded integration с AW-rus | `docs/hayabusa-aw-rus-integration-2026-05-14.md` |
+| Operator guidance | `docs/hayabusa-operator-ib-guide-2026-05-14.md`, `docs/runbook.md` |
+
+Ключевая граница:
+
+- `Hayabusa` это enrichment для incident/forensics;
+- это не замена обычного realtime health/collector/DLP runtime.
+
+### 3.8 Grafana / monitoring / 1C analytics
+
+| Контур | Когда использовать |
+|---|---|
+| `grafana/` dashboards | AW-rus runtime, RDP activity, DLP, management/security overview |
+| `grafana-1c/` | когда есть удобный SQL/read-only KPI путь из 1С |
+| `clickhouse-1c/` | когда 1С файловая и нужен audit/timeline/detections/cases слой |
+
+По `clickhouse-1c/`:
+
+- это отдельный industrial scaffold для `file-1C analytics`;
+- он не заменяет AW-rus, а добавляет audit/timeline/cases/company-intelligence контур;
+- строится вокруг `landing -> ETL -> ClickHouse -> Grafana + AI Investigator`.
+
+## 4. Главные пользовательские и операторские входы
+
+Внутренний операторский доступ должен идти через VPN/внутреннюю сеть, не через случайно открытые наружу порты.
+
+Базовые входы:
+
+- `https://10.10.10.2/` — gateway;
+- `https://10.10.10.2/go/proxmox-gui` — Proxmox GUI;
+- `https://10.10.10.2/go/file1c-brief` — management/file-1C brief;
+- `https://10.10.10.2/go/file1c-actions` — actions;
+- `http://10.10.10.13:5600/api/0/info` — AW-rus API health;
+- `http://10.10.10.13:5610/reports/worktime/management` — management reporting API.
+
+Telegram bot `DetMirAuto` обязан покрывать:
+
+- incident detection;
+- `/ack`, `/heal`, `/run check`, `/run support`, `/run fallback`, `/status`;
+- `/aw_dlp_check`, `/dlp_mode`, `/dlp_mode_toggle` для операторского DLP-контура;
+- OpenVPN config issuance/export;
+- operator-safe workflows по recovery и restore;
+- отсутствие ложных алертов при transient self-heal.
+
+Операторская семантика меню бота:
+
+- DLP-кнопка обязана показывать текущий режим и следующее действие:
+- `DLP сейчас: наблюдение | включить блокировку`
+- `DLP сейчас: блокировка | включить наблюдение`
+- `DLP сейчас: смешанный | выровнять в блокировку`
+- Кнопка `Форензика Windows логов` — человеко-понятный вход в bounded Hayabusa path для Windows EVTX / DFIR follow-up.
+- Если Telegram-клиент держит устаревшую custom-keyboard, оператор должен нажать `Статус` или `/start`: бот обязан переслать свежую клавиатуру с актуальным DLP label.
+
+## 5. Промышленный набор инструментов для планирования и сопровождения
+
+Ниже минимальный правильный стек, который стоит считать базовым для `DetMir`.
+
+### 5.1 Обязательное ядро GSD
+
+Эти компоненты нужны постоянно:
+
+- `gsd-phase`
+- `gsd-plan-phase`
+- `gsd-planner`
+- `gsd-phase-researcher`
+- `gsd-plan-checker`
+- `gsd-execute-phase`
+- `gsd-executor`
+- `gsd-verifier`
+- `gsd-verify-work`
+- `gsd-review`
+- `gsd-code-reviewer`
+- `gsd-code-fixer`
+- `gsd-debug`
+- `gsd-debugger`
+- `gsd-secure-phase`
+- `gsd-security-auditor`
+
+### 5.2 Нужные supporting-компоненты
+
+- `gsd-doc-writer`
+- `gsd-doc-synthesizer`
+- `gsd-doc-verifier`
+- `gsd-integration-checker`
+- `gsd-intel-updater`
+- `gsd-codebase-mapper`
+
+Для UI-фаз подключать только по необходимости:
+
+- `gsd-ui-phase`
+- `gsd-ui-researcher`
+- `gsd-ui-checker`
+- `gsd-ui-auditor`
+
+### 5.3 Операционные skills для живого DetMir
+
+- `aw-ops-checks`
+- `aw-russian-collectors-guard`
+- `bot`
+- `autonomous-skill` для длинных recovery/ops-циклов
+
+### 5.4 Что не нужно включать в базовый industrial-контур
+
+По умолчанию не поднимать как обязательную часть процесса:
+
+- `gsd-fast`
+- `gsd-quick`
+- `gsd-sketch`
+- большинство `gsd-ns-*`
+- `gsd-workstreams`
+
+Причина простая:
+
+- `DetMir` уже не greenfield и не playground;
+- лишняя оркестрация здесь опаснее, чем полезна;
+- нужен жесткий управляемый контур, а не разросшийся набор экспериментальных режимов.
+
+## 6. Что именно надо реанимировать из .codex
+
+Практическая схема такая:
+
+- использовать agent-описания из `/home/igor/.codex/agents/gsd-*` как действующее ядро исполнителей;
+- вернуть orchestrator-skills из `/home/igor/.codex/skills_disabled/2026-05-21-current-prune/` для верхнеуровневого workflow;
+- hooks `gsd-phase-boundary.sh`, `gsd-statusline.js`, `gsd-workflow-guard.js` держать как сервисную обвязку, а не как замену основному процессу.
+
+Минимум к восстановлению как orchestrator layer:
+
+- `gsd-phase`
+- `gsd-plan-phase`
+- `gsd-execute-phase`
+- `gsd-review`
+- `gsd-verify-work`
+- `gsd-debug`
+- `gsd-secure-phase`
+- `gsd-ui-phase`
+
+## 7. Рабочий lifecycle для DetMir
+
+### 7.1 Планирование
+
+Каждая нетривиальная работа должна идти через фазу, а не через бессистемные правки.
+
+Обязательная цепочка:
+
+1. зафиксировать изменение в `.planning/ROADMAP.md` и состоянии проекта;
+2. открыть фазу в `.planning/phases/<NN>-<slug>/`;
+3. собрать `PLAN.md` через `gsd-plan-phase`;
+4. выполнить research/check loop до defensible плана;
+5. только после этого идти в выполнение.
+
+### 7.2 Исполнение
+
+Исполнение должно идти волнами, а не одним большим неоткатываемым махом.
+
+Обязательные правила:
+
+- backup-first перед risky runtime changes;
+- server/network/windows changes не смешивать без явной причины;
+- после каждого meaningful шага оставлять проверяемый след в артефактах и сервисных логах;
+- не считать задачу завершенной без реальной проверки на живом контуре.
+
+### 7.3 Проверка и приемка
+
+После выполнения обязательно:
+
+- `gsd-verifier` на достижение целевого эффекта;
+- `gsd-review` на код/риск/регрессии;
+- `gsd-verify-work` на пользовательскую приемку;
+- `gsd-secure-phase`, если фаза трогала сеть, доступы, VPN, secrets, bot, `pfSense`, `Windows` admin path.
+
+### 7.4 Документация
+
+После фазы обновлять не “когда-нибудь”, а сразу:
+
+- runbook;
+- relevant docs;
+- phase `SUMMARY.md`;
+- если нужно, `STATE.md` и `ROADMAP.md`.
+
+Для `DetMir` это обязательно, потому что основная историческая боль проекта была не в отсутствии кода, а в расхождении между repo, runtime и реальностью.
+
+## 8. Базовый комплект артефактов
+
+Для каждой фазы и для всей системы нужны конкретные файлы, а не размытые договоренности.
+
+| Артефакт | Назначение |
+|---|---|
+| `.planning/ROADMAP.md` | очередь и границы проекта |
+| `.planning/STATE.md` | текущее состояние production-контура |
+| `.planning/phases/<NN>-<slug>/PLAN.md` | исполнимый план |
+| `.planning/phases/<NN>-<slug>/SUMMARY.md` | факт выполненного |
+| `VERIFICATION.md` | доказательство результата |
+| `REVIEW.md` | findings по code/review |
+| `SECURITY.md` | security findings по risky фазам |
+| `UAT.md` | операторская приемка |
+| `docs/runbook.md` | живая эксплуатация |
+| этот файл | единая карта системы и рабочего процесса |
+
+## 9. Операционный минимум, который нельзя терять
+
+Система считается реально сопровождаемой только если одновременно живы все эти контуры:
+
+- `AW-rus API` отвечает;
+- buckets по `afk/window/worktime/DLP` свежие;
+- `aw-rus-healthd` и `aw-health-check` не врут и не шумят ложными fail;
+- Telegram bot не генерирует ложные auto-heal incidents;
+- `pfSense` ACL соответствуют фактическому runtime;
+- есть рабочий Windows deploy/validate/recovery path;
+- есть рабочий `Hayabusa` follow-up path;
+- Grafana/importable dashboards version-controlled;
+- management/reporting path на `:5610` не сломан;
+- docs и phase-artifacts отражают реальное состояние, а не прошлую эпоху.
+
+## 10. Что считать правильным направлением развития
+
+Приоритет для `DetMir` сейчас такой:
+
+1. не расширять систему ценой потери baseline stability;
+2. сначала держать зеленым production runtime;
+3. потом усиливать regression guards и operator path;
+4. затем развивать `DLP`, `management`, `Hayabusa`, `file-1C analytics`;
+5. любой новый слой вводить только так, чтобы он не ломал существующий recovery path.
+
+## 11. Краткое правило принятия решений
+
+Если есть выбор между:
+
+- “быстро добавить еще один контур”;
+- и “сделать существующий контур проверяемым, документированным и устойчивым”,
+
+для `DetMir` правильный выбор почти всегда второй.
+
+Это и есть промышленный режим сопровождения этой системы.

docs/hayabusa-aw-rus-integration-2026-05-14.md

@@ -1,4 +1,4 @@
-# Hayabusa AW-rus Integration 2026-05-14
+# Hayabusa / "Форензика Windows логов" AW-rus Integration 2026-05-14
 
 This document defines the bounded integration between Hayabusa DFIR and the normal AW-rus operator path.
 
@@ -40,6 +40,12 @@ or from Telegram bot:
 
 Default mode is `incident`.
 
+Operator-facing note:
+
+- In Telegram menu the button is named `Форензика Windows логов`.
+- Legacy button text `Hayabusa DFIR` may still appear in stale chat keyboards, but the bot must continue to accept it.
+- This path remains bounded DFIR follow-up, not a primary runtime health/DLP control.
+
 ## What gets linked to a case
 
 Case management stores only bounded metadata:

docs/runbook.md

@@ -2,6 +2,26 @@
 
 ## Быстрый health-check
 
+### Proxmox web gateway
+
+Если на host `10.10.10.2` развёрнут `nginx` gateway, базовые проверки такие:
+
+```sh
+systemctl status nginx --no-pager
+nginx -t
+curl -I -sS -H 'Host: dm.iri1968.dpdns.org' http://127.0.0.1/
+curl -k -fsS -H 'Host: dm.iri1968.dpdns.org' https://127.0.0.1/healthz
+curl -k -I -sS -H 'Host: dm.iri1968.dpdns.org' https://127.0.0.1/go/proxmox-gui
+curl -k -H 'Host: dm.iri1968.dpdns.org' -fsS https://127.0.0.1/ | grep -F 'dm.iri1968.dpdns.org'
+```
+
+Playbook для повторного rollout:
+
+```sh
+ANSIBLE_HOST_KEY_CHECKING=False \
+ansible-playbook -i ansible/inventory.ini ansible/deploy_proxmox_web_gateway.yml
+```
+
 ### На Proxmox
 
 ```sh
@@ -59,6 +79,35 @@ grep -n 'aw-ru-patch\|aw-sw-cleanup' /opt/activitywatch/webui-ru/index.html
 ls -l /opt/activitywatch/webui-ru/js/
 ```
 
+## Telegram bot: DLP режим и форензика
+
+Для оператора `DetMirAuto` каноническое поведение такое:
+
+- Кнопка DLP должна явно показывать текущий режим и целевое действие:
+- `DLP сейчас: наблюдение | включить блокировку`
+- `DLP сейчас: блокировка | включить наблюдение`
+- `DLP сейчас: смешанный | выровнять в блокировку`
+- Slash-путь для проверки без переключения: `/dlp_mode`
+- Slash-путь для переключения: `/dlp_mode_toggle`
+
+Интерпретация:
+
+- `наблюдение` = endpoint/email правила работают в monitor-поведении (`alert/log`), без жёсткого `block`;
+- `блокировка` = endpoint/email правила переведены в `block`;
+- `смешанный` = часть endpoint/email правил уже `block`, часть ещё monitor-like; нормальный следующий ход — выровнять policy.
+
+Форензика:
+
+- Кнопка в меню называется `Форензика Windows логов`;
+- Это человеко-понятный операторский вход в bounded Hayabusa path;
+- Slash-команда остаётся прежней: `/aw_dfir /path/to/package.zip HOST [CASE_ID] [MODE]`
+
+Если Telegram показывает старую клавиатуру:
+
+- Нажать `Статус` или `/start`;
+- Бот обязан прислать свежую custom-keyboard с актуальным DLP label;
+- Старая кнопка в чате может ещё приходить как текст, но бот должен её принять и после ответа вернуть свежую клавиатуру.
+
 Проверить:
 
 - есть `aw-ru-patch.js`;
@@ -105,6 +154,8 @@ Playbook вычисляет `durationDefault` автоматически (вкл
 curl -fsS 'http://127.0.0.1:5610/reports/worktime/today?day=today' | jq '.[:5]'
 curl -fsS 'http://127.0.0.1:5610/reports/worktime/management?day=today' | jq '.summary,.executive'
 curl -fsS 'http://127.0.0.1:5610/reports/worktime/management?format=html&day=today' | head
+curl -fsS 'http://127.0.0.1:5610/reports/worktime/management?day=today&owner=Сменный%20руководитель' | jq '.filters,.summary,.owner_rollups'
+curl -fsS 'http://127.0.0.1:5610/reports/worktime/management?day=today&department=Операторы%201С' | jq '.filters,.summary,.department_rollups'
 ```
 
 Важно:
@@ -113,6 +164,21 @@ curl -fsS 'http://127.0.0.1:5610/reports/worktime/management?format=html&day=tod
   API пересчитывает trend и source freshness;
 - повторные запросы должны быть быстрыми за счёт cache в
   `/var/lib/activitywatch/worktime-cache`;
+- по умолчанию cache живёт `300` секунд и прогревается локально через
+  `aw-worktime-autoheal.service`, чтобы manager-страницы не висели на cold-start;
+- default warm-path должен ходить в `format=json`, потому что этого достаточно
+  для наполнения cache и это заметно легче, чем cold HTML render;
+- warm timeout по умолчанию `70` секунд и задаётся через
+  `AW_WORKTIME_MANAGEMENT_WARM_TIMEOUT_SECONDS`;
+- management report поддерживает scope-фильтры `owner` и `department`; они
+  пересчитывают `summary`, `rows`, `actions` и rollups под выбранный срез, а не
+  просто прячут строки в HTML;
+- `trend` в filtered-view сейчас сознательно отключён: это удерживает latency в
+  рабочем диапазоне и не заставляет сервер заново пересчитывать исторический
+  ряд на каждый менеджерский клик;
+- alias-файл теперь может содержать не только `users`, но и `owners`;
+  блок `owners` нужен для manager-facing каталога ответственных:
+  `display_name`, `title`, `department`, `contact`, `escalation_to`, `notes`;
 - alias-файл для нормализации сотрудников по умолчанию:
   `/etc/activitywatch/worktime-manager-aliases.json`.
 
@@ -383,6 +449,34 @@ curl -fsS 'http://10.10.10.13:5600/api/0/buckets/aw-file-operations_10.10.10.13/
 Remove-NetFirewallRule -DisplayName 'AWatch WAL Test Block 5600' -ErrorAction SilentlyContinue
 ```
 
+### PowerShell MCP на DetMir Windows host
+
+Для `DetMir` Windows host `192.168.100.18` интерактивный путь из Linux/Codex закреплён через `SSH`, а не через `WSMan`.
+
+Быстрый вход:
+
+```bash
+cd /mnt/usb_hdd2/Projects/ActivityWatch-Russian
+bash scripts/install_detmir_powershell_mcp.sh
+```
+
+После переоткрытия `pwsh` или новой Codex-session:
+
+```powershell
+detmir-win-test
+detmir-win-ps 'hostname; Get-Date -Format o'
+detmir-win-shell
+```
+
+Канонический документ:
+
+- `docs/DETMIR_POWERSHELL_MCP_REMOTE_RU.md`
+
+Правило:
+
+- `WinRM` использовать для `ansible aw_windows` и playbook-ов;
+- `SSH` использовать для `powershell-windows` MCP, operator PowerShell и ad-hoc remote execution.
+
 ### У пользователей всплывает окно PowerShell
 
 Ожидаемое поведение collector-ов: запуск hidden (`-WindowStyle Hidden`).