manual sync

decisions/2026-06-08-swarmclaw-lxc135-deploy.md

@@ -119,6 +119,11 @@ Device SwarmClaw (10.0.0.135) спарен на openclaw с `operator.admin` (ap
 ## Грабля: урезка tools сломала создание агентов (2026-06-12)
 После урезки Дирижёра 24→9 tools (ради контекста) он **перестал создавать агентов** — был убран **`manage_platform`** (именно он управляет агентами: create/assign; «не та ветка» = путаница агента про параллельные `branches` суб-агентов в `subagent.ts`, не git). **Фикс:** вернул Дирижёру `manage_platform` + `spawn_subagent` (он оркестратор роя) → tools=11, создание агентов работает (проверено: создал TestBot99). **Урок:** при урезке tools у агента-оркестратора НЕ убирать `manage_platform`/`spawn_subagent`/`delegate_to_agent` — это его рабочие инструменты. Рядовым агентам (7 tools) они не нужны.
 
+## Обновление версии образа (2026-06-14: 1.9.38 → 1.9.39)
+Процедура на LXC 135 (через `pct exec 135`): бэкап БД `cp /opt/swarmclaw/data/swarmclaw.db{,.bak-preXXXX}` → `cd /opt/swarmclaw && docker compose pull && docker compose up -d` → **`bash repatch-ctxwin.sh` ОБЯЗАТЕЛЬНО** (патч `omniroute:2e5`=200K живёт в `/app/.next/server/chunks` контейнера, слетает при recreate; без него `getContextWindowSize` fallback = 8192 → агенты на Opus режутся до 8K). Проверка: `docker exec swarmclaw-swarmclaw-1 grep version /app/package.json`, `auth HTTP=200` ключом из `.env.local` (`OL260380eg`, **не** первичный `4613e7d0…`), `/api/agents` отдаёт список.
+- 1.9.39 — packaging-релиз (npm publish pending, Docker готов, macOS desktop zip/нотаризация); функциональных изменений для сервера нет. На ghcr `:latest` == `:v1.9.39`.
+- Откат: старый образ 1.9.38 (`sha256:d1d102a4…`) остаётся локально; восстановить из `.bak-pre1939` + запустить прежний образ.
+
 ## Схема API (для будущих правок headless)
 - `POST /api/providers` → `{id,name,baseUrl,models[],requiresApiKey,isEnabled}` (type всегда `custom`), хранит JSON в таблице `provider_configs`.
 - `POST /api/agents` → zod `AgentCreateSchema`; обяз. `name`,`provider`; `ollamaMode` только `local|cloud|null` (не `off`).

decisions/2026-06-20-german-hermes-out-of-usage.md

@@ -74,5 +74,91 @@ systemctl restart omniroute   # сбросить кэш ключей
 - Память: [[../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_omniroute_update]], [[../../.claude/projects/-Users-ai-knowledge-base/memory/project_german_hermes]].
 - Деплой German: [[2026-06-18-german-hermes-agent-deploy]].
 
+## Продолжение 2026-06-20 (вечер) — e8a70f39 МЁРТВ, изоляция невозможна
+Олег выбрал «реанимировать e8a70f39» → **не сработало по жёсткой причине**:
+- Флипнул `is_active=1` (priority 1). При первом master-вызове OmniRoute попытался обновить протухший токен (expired 06-16) и получил `Refresh token consumed (unrecoverable_refresh)` → **авто-выключил аккаунт обратно** (`is_active=0`), вызов свалился на batlaew (200). Это и есть причина, почему e8a70f39 был выключен 06-16: его OAuth refresh-токен сожжён безвозвратно. **Поднять без свежего OAuth-логина нельзя.** БД вернулась в исходное сама (бэкап `storage.sqlite.bak-reactivate-e8a70f39`).
+- **Вывод: рабочий Claude-аккаунт в OmniRoute РОВНО ОДИН — batlaew.** Двух-пуловая изоляция (фикс #1) больше неактуальна — изолировать не на что. Привязка ключей к batlaew стала бессмысленной (он и так единственный), но не вредит.
+
+### Профиль «почему то работает, то нет» (опровергает «весь день без ошибок»)
+German-ключи (claw/test-key) сегодня по часам: 09 `18×200/3×400/14×429`, 13 `2×200/**18×400**`, 14 `8×200/6×400`, **15 `24×200` (чисто)**, 16 `1×200/6×400`. То есть весь день **интермиттирующие burst-провалы**, худший в 13:00; в 15:00 — идеально. Олег тестировал в 16:xx → попал в burst. Спайки 1-в-1 со спайками `out of extra usage` у batlaew (09:5, 12:9, 13:21, 14:7, 16:7).
+**«Лимитов нет» объясняется так:** дашборд **Plan usage** (5h 53%) — сглаженное среднее и burst не показывает. Блок `out of extra usage` — это потолок **Extra usage** (pay-as-you-go overflow), который стоит на **$0**. В момент пика суммарный спрос на batlaew (German + SwarmClaw + code-server, все сошлись на нём после смерти e8a70f39 06-16) превышает включённый в план объём, а раз overflow $0 — Anthropic жёстко режет вместо очереди.
+
+### Сделано в этом проходе
+- German default-модель `cc/claude-opus-4-7` → **`cc/claude-opus-4-8`** (запрос Олега). Бэкап `config.yaml.bak-opus48`. Проверено: German-ключ → opus-4-8 → 200. *Внимание: opus-4-8 НЕ снижает out-of-usage — тот же аккаунт/пул.*
+
+### Реальные варианты (e8a70f39 вычеркнут) — ВЫБОР ОЛЕГА
+1. **Extra usage ON на batlaew** (`claude.ai/settings/usage` → Extra usage, не Plan) — единственное, что убирает out-of-usage насовсем при одном аккаунте. Платно, биллинг Олега. **Рекомендация #1.**
+2. **Разгрузить burst-пожирателей** — SwarmClaw (8 агентов) + code-server с `cc/opus-4-8` на Sonnet/меньше агентов → суммарный пик влезает в план batlaew.
+3. **Свежий OAuth второго Max-аккаунта** в OmniRoute (заново залогинить — хоть тот же, что был e8a70f39, хоть новый) → восстановить двух-пуловую изоляцию. Требует интерактивного OAuth (Олег).
+4. Реальный backoff ретраев German (сейчас 5 ретраев летят за <1с — бесполезно против burst в секунды-минуту). Пережидать пик ценой задержки ответа.
+
+## Продолжение 2026-06-20 (вечер-2) — СМЕНА СТРАТЕГИИ: почему Антошка работает, а German нет
+Олег ткнул верно: **openclaw (Антошка) на том же OmniRoute/Opus 4.8 работает стабильно** → теория «account-level cap» неполна. Сравнил два бота эмпирически (call_logs) — **3 реальные разницы:**
+1. **Объём.** Антошка (ключ `claw`) сегодня = 2 вызова; German (`test-key`) = 114 (+ master/SwarmClaw+codeserver 130). German — половина нагрузки batlaew и worst fail-rate (39/114=34%). Антошка «работает» во многом потому что лёгкий → редко попадает в burst.
+2. **Фоллбэк-цепочка.** У German была `cc/claude-haiku → claude/claude-haiku` (ОБА Max → бьются в тот же `out of extra usage`, что и opus — проверено: sonnet-4-6 тоже ловит этот 400). У Антошки последний фоллбэк = **`kr/claude-sonnet-4.5`** (Kiro, FREE, не-Max) → когда Max в пике, Антошка уезжает на не-Max и продолжает отвечать.
+3. **Пин ключа (КОРЕНЬ).** Фикс #1 (`allowed_connections=['883152e1'/batlaew]`) делался против перегруженного e8a70f39 — но тот **мёртв**. Пин же **запер German на единственном перегруженном batlaew**: эскейп-маршруты `kr/`/`cx/` ключом German отдавали **400** (connection-not-allowed). Пин из «защиты» превратился в «ловушку». [[../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_root_cause_recurring]]: лечил симптом, корень — в своём же конфиге.
+
+### Сделано (привёл German к схеме Антошки, всё в рамках моих прав, без биллинга)
+1. **Снят пин** с `test-key` и `claw`: `UPDATE api_keys SET allowed_connections=NULL WHERE name IN ('test-key','claw')`. Теперь opus-4-8 всё равно → batlaew (других Max-аккаунтов нет), а kr//cx/ доходят до своих провайдеров. Проверено: до — kr/cx=400, после — opus-4-8=200, kr/cx доходят (402/timeout = флап free-пулов, но маршрут открыт).
+2. **Фоллбэк-цепочка** German переписана как у Антошки: `cc/claude-sonnet-4-6 → kr/claude-sonnet-4.5 → cx/gpt-5.5` (выкинул мёртвый haiku→haiku). Бэкап `config.yaml.bak-fallback-*`.
+3. Primary = `cc/claude-opus-4-8`. German стабилен (`NRestarts=0`), opus-4-8 → 200.
+
+### Честный остаток (Олегу знать)
+Это **не делает German неуязвимым** — free-эскейпы (Kiro/Codex/GLM) сейчас сами полудохлые (Kiro: «reached the limit» 402 / «fetch failed» 502 / 429; Codex throttled; GLM баланс 0). В ГЛУБОКИЙ burst, когда и batlaew capped, и free-пулы лежат — German всё ещё может блипнуть (как блипнул бы и Антошка под такой нагрузкой). German теперь **архитектурно равен** рабочему боту, а не сломан. Для полной неуязвимости при тяжёлой нагрузке всё равно нужно одно из: **Extra usage ON** на batlaew / **разгрузка master-пути** (SwarmClaw 8 агентов + code-server = вторая половина нагрузки batlaew) / **свежий 2-й Max-аккаунт** (OAuth). Возможный твик при рецидиве: снизить `api_max_retries` 5→3 (сейчас burst → шторм 5×4 тира вызовов, сам прогревает cap).
+
+## Продолжение 2026-06-20 (вечер-3) — ДОКАЗАНО: это всё-таки account-level cap, протокол ни при чём
+Олег давил: «дело не в лимитах, почему Антошка работает». Проверил гипотезу «формат запроса»:
+- **Эндпоинт-разница реальна:** Антошка (`claw`) шлёт нативный Anthropic `/v1/messages` (`source_format=claude`), German (`test-key`) — OpenAI-формат `/v1/chat/completions`+`/v1/responses`. История: claw 448×200 / **0×400**; `/v1/messages` суммарно 355×200 / **0 out-of-usage**, а ВСЕ **396** `out of extra usage` — на `/v1/chat/completions`. Выглядело как корень.
+- **Перевёл German primary на `provider: anthropic` + `/v1/messages`** (+ `ANTHROPIC_API_KEY` в .env). Подтвердил: трафик пошёл `path=/v1/messages source_format=claude`. **И всё равно поймал `out of extra usage` 400** (17:11/17:12 на opus-4-8 через /v1/messages; в 17:04 был 200 — т.е. интермиттентно).
+- **РЕШАЮЩИЙ ТЕСТ:** бил `/v1/messages` opus-4-8 **обоими ключами** (claw Антошки + test-key German) залпами. В пик — оба 400, вне пика — оба 200×5. **Ключ Антошки ловит ту же ошибку.** Значит «0×400 у claw» в истории = следствие МАЛОГО ОБЪЁМА (claw сегодня 2 вызова против 114 у German), а не иммунитета протокола.
+- **Вывод:** `out of extra usage` — **account-level cap на batlaew, интермиттентный (burst)**, бьёт по ЛЮБОМУ пути (/v1/messages и /chat/completions) и ЛЮБОЙ модели (opus/sonnet/haiku — всё проверено). Антошка «работает» только потому что лёгкий. Дашборд Олега = **Plan usage** (5h-среднее, 53%), а режет потолок **Extra usage** (overflow) = $0. Это и есть лимит, просто не тот, что на дашборде.
+- **Откат:** протокол-правку вернул к проверенному `provider: custom`+`/v1` (anthropic-режим не помог и не проверен на tool-нагрузке German — спекулятивная правка). `ANTHROPIC_API_KEY` убран. Бэкап отката `config.yaml.bak-anthropic-170948`.
+
+### Итоговое состояние German (что осталось включённым)
+- primary `cc/claude-opus-4-8` (custom/openai-compat, проверенный путь), фоллбэк `cc/sonnet-4-6 → kr/sonnet-4.5 → cx/gpt-5.5`, ключ **распинён** (NULL). active, opus-4-8→200.
+
+### Финал (без иллюзий): убрать `out of extra usage` можно только так
+1. **Extra usage ON на batlaew** — `claude.ai/settings/usage` → секция **Extra usage** (не Plan). Это буквально то, что просит текст ошибки. Снимает cap для всех.
+2. **Срезать конкурентную burst-нагрузку на batlaew:** SwarmClaw (8 агентов) + code-server (cc/opus-4-8) = вторая половина трафика, льют параллельно → создают пики. Throttle/Sonnet/меньше агентов.
+3. German усиливает пики своим retry-штормом (5 ретраев × 4 тира мгновенно). Снизить `api_max_retries` 5→3 — меньше шторм, меньше вклад в cap.
+4. Свежий 2-й Max-аккаунт (OAuth) — изоляция German на отдельный пул.
+
+## Продолжение 2026-06-20 (вечер-4) — SwarmClaw НЕ ест лимит + фикс «работает» через overloaded-backoff
+Олег: «SwarmClaw 3 дня не юзаю, как он ест лимит?» — прав, проверил:
+- **Master-путь на batlaew (opus) по дням: 06-17=268, 06-18=591, 06-19=82, 06-20=74.** Тяжёлый поток был 3 дня назад, сошёл на нет. SwarmClaw сейчас лимит НЕ ест — прежняя атрибуция неверна для текущего момента.
+- **Крупнейший потребитель СЕЙЧАС — сам German:** opus-токены batlaew сегодня — test-key(German) **916K** fresh in / 877K cache; (master) 394K; claw(Антошка) 83K. German грузит большой KB-контекст в каждый ход × tool-loop → ест в 2.3× больше master и 11× больше Антошки. Антошка лёгкий → не упирается.
+
+### Почему backoff раньше «не работал» (казалось мгновенным)
+В логе 16:17 5 ретраев были на timestamp 16:17:10 — иллюзия от буферизации (`_buffer_vprint` флашится разом). Реально backoff ЕСТЬ: `conversation_loop.py:3439` `jittered_backoff(base_delay=2.0, max_delay=60.0)` + respects Retry-After. НО для `rate_limit` есть **eager-failover** (2764): при наличии фоллбэк-цепочки Hermes сразу прыгает на следующую модель, минуя ожидание opus — и каскадит через дохлые free-пулы (kr 400/cx 429) → быстро сдаётся.
+
+### Фикс «чтобы работал» (выбор Олега делегирован мне)
+1. **out-of-usage классифицирован как `FailoverReason.overloaded`** (было `rate_limit`) в `error_classifier.py:674`. overloaded НЕ триггерит eager-failover (2764 ловит только rate_limit/billing) → German **пережидает burst на самом opus-4-8 с backoff** (2с→60с jittered), а не каскадит на мёртвые фоллбэки. Проверено `classify_api_error`: out-of-usage→overloaded/retryable=True; обычная 400→model_not_found/non-retryable (узкий паттерн). Бэкап `error_classifier.py.bak-overloaded-*`, переналожатель `/root/hermes-patch-outofusage.py` обновлён (rate_limit→overloaded).
+2. **`api_max_retries` 5→6** — окно пережидания ~1-2 мин (jittered 2с..60с × 6).
+3. Сохранены: opus-4-8 primary, распин ключа, цепочка фоллбэков (теперь — последний резерв ПОСЛЕ ожидания opus).
+
+**Механика:** batlaew кратко капается → German ждёт (2с,4с,8с…до 60с) и повторяет opus, ловя восстановление за ~1-2 мин, вместо мгновенной ошибки. Цена — в пик ответ на десятки секунд позже (но ОТВЕЧАЕТ). Это не победит длинный (>2 мин) аккаунт-аутаж, но такие редки; обычный burst — секунды. Полностью убирает out-of-usage всё равно только Extra usage ON / урезание контекста German (RAG вместо полного KB).
+
+## Продолжение 2026-06-20 (вечер-5) — НАСТОЯЩЕЕ различие German vs Антошка: агентный burst
+Олег: «какие ещё идеи, почему German не работает, а Антошка да». Проверил оставшиеся гипотезы на уровне запроса:
+- **Per-key лимиты** (test-key vs claw): у обоих пусто — исключено.
+- **Холодный кэш** (идея: German простаивает → cache_ttl 5m протухает → дорогой re-create): ОПРОВЕРГНУТО. German кэшируется нормально (3 дня: cache_read **1.5M** vs cache_creation 450K). Антошка кэш вообще не читает (read=0), но ему и не надо.
+- **Тела запросов** (max_tokens/thinking): артефакты OmniRoute хранятся усечённо (~572 симв) → ненадёжно.
+- **★ НАЙДЕНО — агентный burst вызовов:**
+  | | Антошка (claw) | German (test-key) |
+  |---|---|---|
+  | макс. opus-вызовов/мин | **1** | **8** (стабильно 6-7) |
+  | вызовов за 3 дня | 13 | 158 |
+  
+  German — агентный (tool-loop): 1 сообщение Олега → каскад **6-8 Opus-вызовов/мин**, каждый тащит ~45K-контекст → ~360K Opus-токенов залпом в минуту. Антошка — разговорный, **1 вызов** на обращение. 5h-лимит Max **взвешенный** (Opus ~5× Sonnet), и минутный burst German пробивает мгновенную взвешенную планку Opus → `out of extra usage`. Дашборд (53%) = 5h-среднее, не минутный пик. **Это и есть «почему German, а не Антошка» — частота Opus-вызовов на сообщение (агентность vs разговорность), не формат/ключ/кэш/KB.**
+
+### Сделано
+- **`agent.max_turns` 80 → 25** (`goals.max_turns` 20 не трогал) — ограничивает размер burst: одна сложная задача больше не выстрелит до 80 Opus-вызовов подряд. Бэкап `config.yaml.bak-maxturns-*`. German active, opus-4-8→200.
+
+### Полный набор активных мер для German (итог всей цепочки)
+1. primary `cc/claude-opus-4-8`; ключ распинён (NULL); фоллбэк `cc/sonnet-4-6 → kr/sonnet-4.5 → cx/gpt-5.5` (резерв).
+2. out-of-usage → `overloaded` (backoff-пережидание burst на opus, не каскад на дохлые фоллбэки) + `api_max_retries` 6.
+3. `max_turns` 25 (меньше burst).
+Остаточный полный фикс (если рецидив): **Sonnet 4.6 как primary** (в ~5× легче по весу Max, «Sonnet 0%» — почти без лимита) ИЛИ **Extra usage ON**.
+
 ## Урок (мне на будущее)
 Я трижды выдал неверный диагноз (баг версии → реальный лимит → перегрузка пула), прежде чем дошёл до `call_logs` по `account`. **При `out of usage` на cc/* — СНАЧАЛА `call_logs` GROUP BY account,status, потом гипотезы.** См. [[../../.claude/projects/-Users-ai-knowledge-base/memory/feedback_root_cause_recurring]].

decisions/2026-06-21-buzharovo-mcp-1c-deploy.md

@@ -0,0 +1,48 @@
+---
+date: 2026-06-21
+type: decision
+tags: [buzharovo, 1c, mcp, mcp-1c, iis, claude-code]
+---
+
+# MCP-сервер mcp-1c к базе 1С Бужарово (RitmUl / Розница)
+
+Развёрнут [feenlace/mcp-1c](https://github.com/feenlace/mcp-1c) — Claude Code читает метаданные и
+выполняет SELECT-запросы к боевой базе **RitmUl** (1С:Розница 2.3.23.27) на [[projects/buzharovo/server1c]].
+
+## Итоговая схема (работает end-to-end)
+
+```
+Mac (mcp-1c stdio, ~/.local/bin/mcp-1c v1.8.0)
+  → NetBird → http://100.70.75.103:8080/mcp/hs/mcp-1c   (Basic-Auth, юзер 1С)
+  → IIS (app /mcp, пул 1CMCP «No Managed Code») → wsisapi.dll
+  → кластер 1С Server1C:1541 → база RitmUl → расширение MCP_HTTPService
+```
+
+- **Клиент (Mac):** `~/.local/bin/mcp-1c` (darwin-amd64 v1.8.0). Зарегистрирован: `claude mcp add 1c --scope user -e MCP_1C_BASE_URL=http://100.70.75.103:8080/mcp/hs/mcp-1c -e MCP_1C_USER=… -e MCP_1C_PASSWORD=… -- ~/.local/bin/mcp-1c`. `claude mcp list → ✓ Connected`. Конфиг `~/.claude.json` chmod 600.
+- **Расширение:** `MCP_HTTPService` (HTTP-сервис `MCPService`, RootURL `mcp-1c`) поставлено `mcp-1c.exe --install "Server1C\RitmUl" --server --db-user <админ ИБ> --db-password …`. Несёт свою роль `MCP_ОсновнаяРоль` (только `Use` на сервис, без привилег. режима).
+- **Публикация:** IIS, приложение `/mcp` → `C:\inetpub\mcp` (`default.vrd` + `web.config`). Бинарь сервера: `C:\mcp-1c\mcp-1c.exe` (Windows).
+- **Безопасность:** 8080 — firewall-правило `mcp-1c HTTP (NetBird only)` только из `100.64.0.0/10`; публичное IIS-правило для :80 отключено; Basic-Auth = пользователь 1С.
+
+## Грабли (в порядке появления — все реальные)
+
+1. **NetBird на server1c лежал** не из-за NetBird: DNS сервера указывал только на роутер `192.168.1.1`, у которого сдох резолвинг (даже `google.com`=0). `api.netbird.io` не резолвился → меш не вставал. Фикс: `netsh interface ipv4 set dnsservers Ethernet static 1.1.1.1 primary` + `8.8.8.8` (статикой, иначе DHCP перетирает). От админ-PowerShell (интерактивная не-админ сессия падала на CIM permission).
+2. **WinRM с Мака** к server1c (5985, NetBird): pywinrm `transport='basic'` (NTLM отклоняется). Креды `dttb/1qaz!QAZ`, по сети — админ-токен.
+3. **`/HTTPPort` не работает** в сборке 8.3.27.1606: ни headless (толстый клиент = GUI, дохнет в session 0), ни интерактивно (база открывается, порт не поднимается). Вариант self-host отвергнут.
+4. **Веб-сервера и веб-модулей 1С не было** (платформа ставилась «только сервер»). Дистрибутив нашёлся локально по реестру `InstallSource` = `E:\Distr\Update\windows64full_8_3_27_1606\`. Доустановка модуля: `msiexec /i "…\1CEnterprise 8 (x86-64).msi" ADDLOCAL=WebServices,WebServices_RU /qn /norestart` → появились `wsisapi.dll`/`wsap24.dll`/`webinst.exe`. Затем `Install-WindowsFeature Web-Server,Web-CGI,Web-ISAPI-Ext,Web-ISAPI-Filter -IncludeManagementTools`.
+5. **★ w3wp падал `0xc0000005`** (Application Error, faulting module «unknown»; VS JIT-отладчик ловил краш и вешал воркер — отключил `AeDebug Auto=0`). Причина — нативный ISAPI-модуль 1С в `DefaultAppPool`, куда грузится .NET CLR. **Фикс: отдельный пул «No Managed Code»** (`appcmd add apppool /name:1CMCP`; `set apppool /managedRuntimeVersion:"" /enable32BitAppOnWin64:false /processModel.loadUserProfile:true`; приложение `/mcp` → этот пул). VC++ redist не при чём (уже стоял). **Конфигуратор при републикации сбрасывает пул на DefaultAppPool — каждый раз возвращать 1CMCP.**
+6. **rmngr-loop** на server1c был активен (2 ядра в idle) → новые веб-сессии висли (w3wp idle, ждёт кластер). Лечится известным рецептом: `Restart-Service '1C:Enterprise 8.3 Server Agent (x86-64)' -Force` (при 0 сессий). См. [[decisions/2026-05-07-buzharovo-1c-rmngr-loop-after-crash]].
+7. **★ vrd: HTTP-сервис расширения** не публикуется `publishByDefault`. Нужно `publishExtensionsByDefault="true"` — в Конфигураторе это галочка **«Публиковать HTTP сервисы расширений по умолчанию»** (вкладка «HTTP сервисы»). `webinst` так не умеет; правильный vrd сгенерил только Конфигуратор. Элемент сервиса — `<service name=… rootUrl=… enable="true">`.
+
+## Не доделано
+- **mcp_ro** (RO-юзер вместо интерим-`ПальмановаНВ`). Розница 2.x — сотни гранулярных ролей, единой «read-all» нет; обработчик без привилег. режима → нужны и роль сервиса `MCP_ОсновнаяРоль`, и право чтения данных. Прагматика: dedicated `mcp_ro` = `MCP_ОсновнаяРоль` + `ПолныеПрава` (через mcp-1c всё равно только SELECT). После создания: `claude mcp remove 1c` + re-add с `MCP_1C_USER=mcp_ro`.
+
+## Запись/управление 1С (отложено — вернуться при необходимости)
+
+Открытая (наша) версия — только чтение. **Единственный пишущий инструмент = `code_execute` (action="code")** в **Расширенной** версии mcp-1c (1 990 ₽/мес, 14 дней триал, регистрация feenlace.ru) — исполняет произвольный BSL в базе (создание/проведение документов, изменение справочников/регистров, обработки) со встроенной песочницей + подтверждением + аудитом. Pro-инструменты (4 990) — это анализ кода (семантический поиск, граф зависимостей, аудит безопасности), не запись.
+
+Чтобы включить запись нужно: (1) Расширенная версия mcp-1c; (2) пользователь 1С с **правами на запись** (не RO); (3) переустановить расширение версией Расширенной.
+
+**Риск:** боевая money-база + произвольный BSL от LLM = максимум риска. План безопасного PoC: тест-копия (restore `RitmUl_pre-mcp_*.bak` → SQL `RitmUl_test` → тест-ИБ `Server1C\RitmUl_test`), отладка записи там, на боевую RitmUl — только после. **2026-06-21 Олег решил отложить.**
+
+## Безопасность лицензии
+Лицензия 1С на server1c **неофициальная** — ничего, что её активирует/переактивирует, не трогать. Рестарт кластера и веб-сессии её не задевают (это просто сессии на чтение).