> For the complete documentation index, see [llms.txt](https://docs.onerpa.ru/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.onerpa.ru/mcp-servery-1c/vypuski.md). # Выпуски образов С 27.09.2026 канал один: beta-образы от 27.09.2026 опубликованы под тегами `latest`, `light` и `arm64` (раздел «27.09.2026: beta-образы стали stable» ниже). Таблицы серверов — журнал выпусков: до 27.09.2026 — beta-сборки, после — выпуски под тегами без суффикса. Что вошло в beta-сборки CodeMetadataSearchServer, Graph Metadata Search, SyntaxCheckServer, HelpSearchServer, SSLSearchServer и TemplatesSearchServer, опубликованные с 9 сентября 2026 года (SSLSearchServer и TemplatesSearchServer — с 24 сентября) (сборки перечислены по дате публикации; между ними теги не двигались). Теги `latest-beta`, `light-beta` и `arm64-beta` одного выпуска собираются из одного и того же кода; отличаются они только составом зависимостей (см. [Теги и ключи образов](/mcp-servery-1c/kanaly-obrazov.md)). Сборка опознаётся по digest образа: первые 12 символов `sha256` показывает `docker images --digests`, а полный digest — `docker image inspect <образ> --format '{{index .RepoDigests 0}}'`. Правила, общие для всех выпусков ниже: * **Индексы и графы открываются как есть.** Кроме HelpSearchServer от 23.09.2026 и выпусков 24.09.2026, которые один раз пересобирают индексы с префиксом документов, а также выпусков, которые один раз перестраивают часть данных: HelpSearchServer от 25.09.2026 (поздний вечер) полностью переиндексирует справку, Graph от 25.09.2026 (вечер) пересобирает граф вызовов, Graph от 25.09.2026 (поздний вечер) перезагружает метаданные и права ролей, Graph от 26.09.2026 перечитывает права ролей, Graph от 26.09.2026 (поздний вечер) создаёт индексы слоя, Code от 26.09.2026 перестраивает структурные индексы, Code от 01.10.2026 перестраивает два индекса имён, Graph от 01.10.2026 пересобирает граф вызовов, Code от 01.10.2026 (вечер) перестраивает структурный индекс, граф зависимостей и индекс форм, Graph от 01.10.2026 (вечер) один раз перечитывает метаданные и модули с процедурами `Асинх`, SSLSearchServer от 01.10.2026 один раз перестраивает индекс (см. их строки), ни один сентябрьский выпуск не меняет формат хранилища zvec, отпечаток индекса или схему графа так, чтобы потребовалась полная переиндексация. Если сборка перечитывает что-то один раз (например, формы графа), это сказано в её строке. * **Порядок обновления серверов не важен.** Code и Graph не зависят друг от друга: у каждого свои данные и свой лицензионный ключ; обновляйте их по одному в любом порядке. * **Переменные окружения только добавляются.** Исключение — переменные префиксов эмбеддингов `EMBEDDING_QUERY_PREFIX`, `EMBEDDING_DOCUMENT_PREFIX` и `EMBEDDING_PASSAGE_PREFIX`: с 24.09.2026 они не применяются (заданная переменная выводит предупреждение в журнал). Остальные не переименованы и не удалены; новые перечислены в строке выпуска и на странице конфигурации сервера. ## 27.09.2026: beta-образы стали stable Beta-канал закрыт. Теги `light`, `latest` и `arm64` переведены на beta-образы от 27.09.2026: дайджесты совпадают с `light-beta`, `latest-beta` и `arm64-beta`, код и ключи те же. Дальше выпуски выходят только под тегами без суффикса, теги `*-beta` не поддерживаются. Образы принимают только ключ, выпущенный 27.09.2026 (`LICENSE_KEY_<СЕРВЕР>` в дистрибутиве); ключ stable, выданный раньше, отклоняется с `Invalid LICENSE_KEY`. С бывшего beta переиндексация не нужна; со stable до 27.09.2026 переходите с новыми каталогами данных, индексы строятся заново. Порядок перехода — в [Тегах и ключах образов](/mcp-servery-1c/kanaly-obrazov.md). | Сервер | light | latest | arm64 | Какая сборка | | ------------------------ | -------------- | -------------- | -------------- | ------------------------------------------------------------------------------------------------------------ | | CodeMetadataSearchServer | `dd84456b31d1` | `09f6fe5ec3c6` | `5aad3ce0630d` | Выпуск 27.09.2026 (утро) | | Graph Metadata Search | `7df42796176b` | `34373b1954b7` | `db99e7c1a81b` | Выпуск 27.09.2026 (вечер) | | SyntaxCheckServer | — | `5460f567e29a` | `baa7dbc3c407` | Выпуск 27.09.2026 (утро) | | HelpSearchServer | `84293ac3a409` | `f9dda49f0199` | `deb0555c4f83` | Выпуск 27.09.2026 (утро) | | SSLSearchServer | `b883312a8aa0` | `dcfb86e58161` | `245abe4c7d35` | Пересборка 27.09.2026 (вечер): служебные изменения сборки, код сервера и ключ те же, что у утреннего выпуска | | TemplatesSearchServer | `fd271b6815c9` | `882c8fee3706` | `a5665d8b9594` | Выпуск 27.09.2026 (утро) | | 1CCodeChecker | `122a0c8ed98e` | `f5e18bd41855` | `825387c4be44` | Beta-образ от 27.09.2026 | ## CodeMetadataSearchServer (`comol/1c_code_metadata_mcp`) | Дата | light-beta | Что изменилось | | -------------------------------- | ------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 21.10.2026 | `ca06fa8d538f` (тег `light`; latest `2636285ed0e7`, arm64 `be6abf5cb1fc`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ ПРОГОНЕ ИНДЕКСАЦИИ ПОСЛЕ ОБНОВЛЕНИЯ СЕРВЕР ОДИН РАЗ ДОПИСЫВАЕТ В КАРТОЧКИ ЗАИМСТВОВАННЫХ ОБЪЕКТОВ ЧЛЕНЫ, КОТОРЫЕ ДОБАВЛЯЕТ РАСШИРЕНИЕ. ПЕРЕЧИТЫВАЮТСЯ ТОЛЬКО ОПИСАНИЯ ЗАИМСТВОВАННЫХ ОБЪЕКТОВ В ВЫГРУЗКАХ РАСШИРЕНИЙ, ПАЧКАМИ ПО 100. ОСНОВНАЯ КОНФИГУРАЦИЯ, МОДУЛИ И ЭМБЕДДИНГИ НЕ ПЕРЕСТРАИВАЮТСЯ. БЕЗ РАСШИРЕНИЙ НИЧЕГО НЕ ДОПИСЫВАЕТСЯ.** `get_metadata_details` заимствованного объекта перечисляет реквизиты, колонки табличных частей, формы и команды, которые добавляет расширение, рядом с членами основной конфигурации. У добавленного члена `origin`: `{"origin_kind": "extension", "origin_id": "ext:<ИмяРасширения>"}`, поле остаётся и при `detail_level=outline`. Раньше эти члены в карточку не попадали. Сама карточка — синоним, тип, свойства — остаётся карточкой основной конфигурации; член, который есть и в ней, описывает она, без `origin` расширения. Секции `forms` и `commands` отдают формы и команды объекта по имени. В журнале — `Extension members: N borrowed object(s) completed from M adopted descriptor(s)`. Ключ и настройки прежние. См. [страницу сервера](/mcp-servery-1c/servery/code-metadata-search.md) | | 20.10.2026 | `beaf0fa185a4` (тег `light`; latest `eb4bf36f4287`, arm64 `e2f9805a6cdd`) | `get_metadata_details` для объекта, который заимствует расширение, отдаёт карточку основной конфигурации — синоним, `object_type` во множественном числе, «Движения», основные формы и остальные свойства — с `origin="base"` и без него. Раньше карточку строила запись заимствованного объекта из расширения: пустой синоним, `object_type` «Документ», в `properties` только «Синоним». Индекс, построенный прежними образами, исправляется при первом открытии из уже сохранённых данных (строка журнала `borrowed object(s) now served with the base configuration's card`). `effective_definition` в `search_function` и `get_method_call_hierarchy`: `&ИзменениеИКонтроль` замещает базовое определение — выполняется изменённая копия метода (`change_and_control_supersedes_base`; раньше `adopting` и `adoption_keeps_base_effective`). Вердикт выносится по модулю: обработчики разных форм объекта не конкурируют, `module_path` с путём модуля сужает вердикт до этого модуля (поле `module`), несколько модулей объекта дают `rule: module_not_specified` с вердиктом на каждый модуль. Коллизия — только если метод одного модуля меняют два и более расширения и хотя бы одно замещает его. Несколько `&Перед`/`&После` из разных расширений — не коллизия, а поле `order_note`. Счётчик коллизий в статистике считается так же. `compact_symbol` и `compact_call`: `module_path` находит и модули расширений из `EXTENSION_PATHS` — по каноническому пути из поля `module`. Раньше любой `module_path` их отсекал. Отпечаток индекса не меняется, переиндексации при обновлении нет. | | 17.10.2026 | `c430268f33fe` (тег `light`; latest `047fd87355b6`, arm64 `4bed17957f88`) | Новое поколение индекса больше не переносит из опубликованного файл `extensions.json`: пока поколение собирается, записи о расширениях в его каталоге нет, а при запечатывании пишется только его собственная. Раньше вместе с хранилищами неизменённых файлов копировалась запись предыдущего поколения (с его `generation_id` и прежним набором), и до конца сборки в каталоге нового поколения было видно старый набор расширений — например, без расширения, только что добавленного в `EXTENSION_PATHS`. Опубликованное поколение и раньше записывало набор, по которому собиралось. Переиндексации нет. | | 16.10.2026 | `633a517db236` (тег `light`; latest `4ab00dfdb3f0`, arm64 `2625cc03d632`) | `get_method_call_hierarchy` обходит граф по уровням (в ширину): исчерпанный бюджет `max_nodes`/`max_edges` обрезает самый глубокий уровень, а не прямых вызывающих — раньше первый вызывающий с одноимёнными обработчиками тысяч форм (`ПриЧтенииНаСервере`) выбирал бюджет, и при `depth=3` пропадала часть вызывающих первого уровня. `graph_dependencies`, `search_forms`, `inspect_form_layout`, `bsl_scope_members` и `get_metadata_details` отвечают из опубликованного поколения и во время сборки нового; фаза, последняя полоса которой продолжена с контрольной точки, больше не остаётся в состоянии `running` после прогона (из-за этого формы, `bsl_scope_members` и граф зависимостей отвечали «still building» при готовом индексе). `get_metadata_details`: предопределённые элементы справочников, планов видов характеристик, видов расчёта, счетов и значения перечислений (`predefined`) читаются из выгрузки (`Ext/Predefined.xml`). Директива `&НаСервереБезКонтекста` (`&НаКлиентеНаСервереБезКонтекста`) больше не сокращается до `НаСервере` (`НаКлиенте`) в `search_function`, `get_module_structure`, `compact_symbol` и метаданных фрагментов `codesearch`; там же `is_export` учитывает `Экспорт` после многострочного списка параметров. `get_role_artifact`: права на конфигурацию — на `Конфигурация.<Имя>`, входят в `rights_total`. `effective_definition`: одноимённые обработчики форм без аннотаций — `effective`, а не `intercepting`. Связи `default_object_form`/`default_list_form` живого прохода `graph_dependencies` ведут к форме, а не к объекту. `search_function` и `codesearch` при `limit` результатах возвращают `items_total: null` с `items_total_reason: candidate_cap_reached`. Отпечаток индекса не меняется, переиндексации при обновлении нет: директива и признак экспорта старых записей дочитываются из исходников при запросе. | | 14.10.2026 | `83db0ccfad3a` (тег `light`; latest `31f4edf3e753`, arm64 `0df16f5b93ef`) | Экспортный метод, у которого список параметров перенесён на несколько строк (`Процедура РассчитатьСостояние(` … `= Ложь) Экспорт`), отмечается `is_export=true` в `search_function`, `get_module_structure` (и учитывается в `stats.total_exports`), `compact_symbol` и при чтении по `item_id`: `Экспорт` ищется после скобки, закрывающей список параметров, а не только в первой строке объявления. `signature` (`include_body=false`, сжатый вид `detail_level=outline`) — всё объявление одной строкой без комментариев, а не только его первая строка; у однострочных объявлений сигнатура прежняя. Индекс не перестраивается: для методов, записанных прежней версией с `is_export=false`, признак и сигнатура читаются из сохранённого текста метода. | | 13.10.2026 (второй выпуск) | `4934e44fbfea` (тег `light`; latest `087b839fcb91`, arm64 `d7a9df3f8248`) | Общие формы попадают в индекс форм: `CommonForms/<Имя>/Ext/Form.xml` выгрузки Конфигуратора и `src/CommonForms/<Имя>/Form.form` проекта EDT хранятся как объект `ОбщиеФормы.<Имя>` с формой `<Имя>`. `inspect_form_layout` находит такую форму по `ОбщаяФорма.<Имя>`, `ОбщиеФормы.<Имя>` или краткому имени, `search_forms` тоже её видит. Раньше индекс форм хранил только формы объектов. Индекс, построенный прежними образами, при первом старте один раз собирает поколение: все файлы переносятся как есть, читаются только общие формы, эмбеддинги считаются только для их описаний (у ЗУП 239 общих форм). Прогрев векторного индекса: после старта и после переключения на новое поколение сервер в фоне делает по одному дешёвому векторному запросу на каждую включённую полосу. Первый поиск пользователя больше не платит за загрузку слитого индекса: на стенде первый запрос шёл 9,4 с против 6 с у следующих, на большом проекте мог упираться в таймаут клиента. Прогрев идёт тем же путём, что обычный поиск, готовность сервера не ждёт, полосу с неслитыми документами не трогает; выключается `VECTOR_WARMUP_ENABLED=false` (см. [конфигурацию](https://docs.onerpa.ru/mcp-servery-1c/pages/eU6qZB4IcLc6oKHqB47k#векторное-хранилище-zvec)). Проверка «намеренно пустого» структурного индекса (весь код исключён `STRUCTURAL_EXCLUDE`) на старте не могла прочитать список файлов опубликованного поколения и всегда отвечала «нет»; исправлено. Отпечаток индекса не меняется, переиндексации при обновлении нет. | | 13.10.2026 | `6889b9b1e3da` (тег `light`; latest `2135e066158a`, arm64 `f799eb465cdd`) | Периодический проход по неизменной выгрузке больше не публикует новое поколение каждый час, когда у включённой полосы нет ни одного файла (выгрузка без справки `.html` при `INDEX_HELP=true`: пустая коллекция справки считалась недостроенным индексом). Общая форма (`CommonForms/<Имя>/Ext/Form.xml`), которую индекс форм не хранит, отмечается в трекере и больше не считается новой в каждой сборке. Если в опубликованном поколении есть документы, не слитые в векторный индекс (индекс собирался с `VECTOR_OPTIMIZE_ENABLED=false`, слияние прерывалось), а слияние включено, первый прогон после старта один раз собирает поколение без обращений к эмбеддингам и сливает их — раньше слияние шло только после изменения выгрузки, и векторный и полнотекстовый поиск по таким документам шёл перебором; при `VECTOR_OPTIMIZE_ENABLED=false` старт пишет об этом предупреждение. Полнотекстовая часть поиска: `and`/`or`/`not` (в том числе `Not` из расширения запроса с «НЕ»), скобки, кавычки и двоеточие больше не ломают разбор запроса, полнотекстовые результаты по таким запросам возвращаются. Отпечаток индекса не меняется, переиндексации при обновлении нет; однократная сборка со слиянием — только там, где есть неслитые документы, на большом индексе это часы работы процессора. | | 10.10.2026 | `6425198ff17c` (тег `light`; latest `ab305e5ae1cf`, arm64 `4e8a47ab3f42`) | Восстановление полосы `code` после остановки контейнера во время слияния векторного хранилища: копия сохранённых документов в новый каталог читает старый одним потоковым проходом через снимок только для чтения, а не фильтрованными запросами по диапазонам (на 322 тыс. документов они отменялись движком досрочно — `Cancelled: Plan was cancelled early` — и роняли контейнер с SIGSEGV через 9–16 минут); во время копии фоновые слияния не запускаются, слияние одно — после неё. Поиск по коду: один модуль занимает на странице не больше `CODE_SEARCH_MAX_PER_MODULE` результатов (по умолчанию 3, `0` снимает ограничение), первый результат такого модуля несёт `module_results_withheld`. `search_function`: одноимённые процедуры разных объектов не конкурируют — при нескольких объектах `effective_definition` возвращает `rule: object_not_specified` и вердикт на каждый объект в `objects`; `module_path` с каталогом объекта даёт один вердикт. `metadatasearch(names_only=true)`: имя реквизита отвечает объектом, который его объявляет, со списком `matched_attributes`. Включает выпуски 06.10.2026. Отпечаток индекса не меняется, переиндексации при обновлении нет; полоса, ожидавшая перестройки после прерванного слияния, копируется один раз при первом старте без обращений к эмбеддингам. Новая переменная `EMBEDDING_API_BASE_NO_V1`: при значении `1`, `true` или `yes` адрес из `EMBEDDING_API_BASE` (или устаревшего `OPENAI_API_BASE`) уходит в API эмбеддингов и переранжирования как написан, без автодобавления `/v1` — для корпоративных шлюзов без этого суффикса; без переменной поведение прежнее. | | 06.10.2026 (второй выпуск) | `dda324dd8e5f` (тег `light`; latest `2aeda4d7c06d`, arm64 `df0973a67653`) | Объект выгрузки Конфигуратора, который не прочитался с первого раза, читается ещё до двух раз, а не выпадает: на томе с диска Windows под нагрузкой чтение файла иногда срывается и через мгновение проходит. Раньше такой объект пропускался с предупреждением `Lane metadata: N unit(s) skipped by the xml source` и не появлялся в листинге `compact_metadata`, пока не изменится его файл или не пройдёт полная пересборка: сведения о метаданных пишутся целиком только при первой сборке. На выгрузке ERP одно полное чтение под нагрузкой пропустило 10 отчётов, повторное — ни одного. Повтор чтения записывается в журнал (`read on attempt N of 3`). Включает выпуск 06.10.2026 (объекты расширений). Отпечаток индекса не меняется, переиндексации нет; объект, уже пропущенный в собранном индексе, вернёт `reindex(force=true)` или изменение его файла. | | 06.10.2026 | `03dd7c7064e9` (тег `light`; latest `4acc8244cdfb`, arm64 `25e315fe6f1c`) | В листинге `compact_metadata` (хранилище сведений о метаданных) появились объекты расширений тех видов, которые раньше пропускались: общие картинки, подсистемы, пакеты XDTO, а также языки, элементы стиля, общие реквизиты, группы команд и сервисы интеграции (выгрузка Конфигуратора); называются они так же, как объекты основной конфигурации (`ОбщиеКартинки.<Имя>`, `Подсистемы.<Имя>`, `ПакетыXDTO.<Имя>`). Формы и макеты собственных объектов расширения больше не попадают в листинг как отдельные объекты вида `Справочники.<ИмяФормы>`. Заимствованные объекты по-прежнему описывает основная конфигурация. Отпечаток индекса не меняется, переиндексации при обновлении нет; в уже собранном индексе недостающие объекты запишет следующая полная сборка (`reindex(force=true)` или чистый каталог данных). | | 04.10.2026 | `0858107b18a7` (тег `light`; latest `c85d3b242236`, arm64 `1034a157f206`) | Тот же код, что в выпуске 03.10.2026 (вечер); модуль лицензии побайтно тот же. Изменилась только сборка: слой с весами модели (около 1 ГБ) теперь общий у `latest` и `arm64` и не пересобирается при смене зависимостей, поэтому при этом обновлении `latest` и `arm64` один раз скачивают его заново, а дальше обновления приносят только слой приложения; `light` скачивает только слой приложения. В репозитории образа остались только теги `latest`, `light` и `arm64`. Переиндексации нет. | | 03.10.2026 (вечер) | `aff37e07a220` (тег `light`; latest `6e10b330236d`, arm64 `f3326b962f03`) | Первая сборка структурного индекса, индекса форм и сведений о метаданных идёт одной транзакцией, а не фиксацией на каждый модуль: режим массовой загрузки внешнюю транзакцию не открывал, и на томе с диска Windows каждый модуль стоил \~0,5 с фиксации (стенд ЗУП, 10 185 модулей — 80 минут; теперь \~8 минут, 150 модулей — 3,6 с вместо 105 с). Healthcheck образа даёт на запуск 30 минут (`--start-period=1800s`): однократная перестройка индексов имён при открытии хранилищ больше не делает работающий контейнер `unhealthy`, обычный старт не замедляется. `arm64` ставит PyTorch из CPU-индекса (`torch 2.13.0+cpu`) без CUDA-колёс `nvidia-*` и `triton` — у Apple Silicon, Graviton и Raspberry Pi нет NVIDIA GPU; образ `arm64` — 1,45 ГБ в сжатом виде вместо 4,16 ГБ, остальные версии библиотек те же, `latest` (amd64) по-прежнему с CUDA. Формат хранилищ не меняется, переиндексации нет. | | 03.10.2026 (ночь, второй выпуск) | `cb5f5bbe9d91` (тег `light`; latest `7e5b1e7fe20c`, arm64 `f79f8cc44e17`) | **ВНИМАНИЕ: ПЕРЕИНДЕКСАЦИЯ ОПИСАНИЙ ФОРМ — ДЛИННЫЕ ОПИСАНИЯ (БОЛЬШЕ 4 000 СИМВОЛОВ) ПРИ СЛЕДУЮЩЕЙ ИНДЕКСАЦИИ ФОРМ ВЕКТОРИЗУЮТСЯ ЗАНОВО ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ.** Описание формы длиннее 4 000 символов эмбеддится частями: текст режется по концам строк без потерь, каждая следующая часть начинается с имени формы, заголовка и номера фрагмента; `search_forms` возвращает форму один раз. Раньше описание уходило одним запросом любой длины, и у крупной формы документа (30 тыс. символов, около 8 900 токенов) модель с лимитом 8 192 токена отвечала `400 ContextWindowExceededError` — форма не эмбеддилась, поколение не публиковалось. Ответ провайдера о превышении контекста модели больше не повторяется: слишком длинный фрагмент пропускается с предупреждением и не мешает публикации. Описания короче 4 000 символов не меняются и заново не эмбеддятся; длинные формы, сохранённые раньше целиком, пересчитываются частями при следующей индексации форм. См. [Конфигурация](/mcp-servery-1c/servery/code-metadata-search/konfiguraciya.md) | | 03.10.2026 (ночь) | `8c095c14ddd0` (тег `light`; latest `23c1b669a2b7`, arm64 `60d7e87e51ce`) | ETA в строке `code progress` считается по объёму оставшихся файлов, а не по их числу: код индексируется от меньших файлов к большим, и на корпусе в 30 573 файла (1 680 МБ) последние 5 % файлов занимали 52 % объёма — строка показывала «ETA 694 min» при \~25 часах работы. Файл в работе засчитывается долей готовых чанков; строка называет остаток: `ETA 1500 min by size, 869.0 of 1680.0 MiB left`. Только строка журнала: индексы, поиск и отпечаток индекса не меняются, переиндексации нет. | | 01.10.2026 (поздний вечер) | `4daf508ab69b` (тег `light`; latest `e7e93a774aa7`, arm64 `aaf7904b7623`) | Провайдер эмбеддингов, который принял запрос и не отвечает, больше не останавливает индексацию на часы: новый `EMBEDDING_API_TIMEOUT` (по умолчанию 600 с) ограничивает один запрос, повторов внутри клиента нет (повторяет сервер по `BATCH_MAX_RETRIES`), а пакет без ответа после всех попыток не повторяется по одному чанку — прогон перестаёт обращаться к провайдеру и завершается возобновляемой ошибкой `provider_failure`, следующий старт продолжает с оставшихся файлов. Потребитель эмбеддинга, упавший на ошибке, останавливает фазу. Строки прогресса называют полный путь долгого файла и число его готовых чанков. Включает выпуск того же вечера (формы, `Асинх`); новой перестройки индекса нет — настройка не входит в отпечаток. | | 01.10.2026 (вечер) | `159007895bd4` (тег `light`; latest `e9cb2b95f43f`, arm64 `50c8b18c59d2`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ — ПЕРЕИНДЕКСАЦИЯ: ЗАНОВО СОБИРАЮТСЯ СТРУКТУРНЫЙ ИНДЕКС, ГРАФ ЗАВИСИМОСТЕЙ И ИНДЕКС ФОРМ, ВСЕ ОПИСАНИЯ ФОРМ ВЕКТОРИЗУЮТСЯ ЗАНОВО ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ.** На ЗУП (10 185 модулей, 3 506 форм) на томе с диска Windows это около полутора часов; поиск всё это время отвечает по прежнему индексу. Реквизиты и команды форм из выгрузки Конфигуратора индексируются (раньше у каждой формы Designer их было ноль); `inspect_form_layout` и `get_form_artifact` отдают реквизиты, команды и обработчики раньше дерева элементов — на первой странице большой формы они больше не пустые. Процедуры и функции с модификатором `Асинх`/`Async` видны `search_function`, `get_module_structure`, `get_method_call_hierarchy` и поиску определений. Версии разбора структуры и форм 3 → 4: при первом старте один раз перестраиваются структурный индекс, граф зависимостей и индекс форм; эмбеддинги кода, справки и метаданных не пересчитываются, описания форм векторизуются заново. | | 01.10.2026 | `cc2d9c52f8d5` (тег `light`; latest `743e8a506888`, arm64 `82be9796f742`) | Точный `search_function` и поиск вызывающих в `get_method_call_hierarchy` идут по индексу имён: индексы `idx_symbols_name` и `idx_calls_callee` объявлены `COLLATE NOCASE`, как и сравнение в запросах (раньше SQLite перебирал всю таблицу — десятки секунд на большой базе на томе с диска Windows). При первом старте сервер один раз перестраивает эти два индекса на месте (на большой базе — минуты, сервер в это время не отвечает; эмбеддинги не трогаются, переиндексация не нужна). Проверка готовности перед вызовом читает одну строку вместо подсчёта четырёх таблиц; `timeout_ms` больше не отбрасывает уже найденных вызывающих (`partial=true`). Описания форм читают обработчики и реквизиты по индексу `form_id` (раньше полный просмотр таблицы на каждую форму, около часа на 10 тыс. форм); порядок обработчиков в описании задан явно и не зависит от индексов в базе. Этап форм пишет прогресс (`forms progress: …`) и при `docker stop` останавливается на следующей форме или пачке. Расширение, достижимое и через `CODE_PATH`, и через `EXTENSION_PATHS`, обходится один раз. Процедура, записанная в одну строку (`Функция … КонецФункции`), заканчивается на этой строке: модули с такими процедурами получат новые границы при следующем изменении файла, остальные модули не перестраиваются. | | 28.09.2026 (вечер) | `1d8fc83a81f5` (тег `light`; latest `6c0dd6c9d221`, arm64 `819d6d49fccb`) | Когда очистка сессий освобождает простаивающую MCP-сессию, начатый ответ (обычно держащийся SSE-поток `GET /mcp`) завершается штатно. Раньше Uvicorn писал `ERROR: ASGI callable returned without completing response`, а клиент получал оборванный поток. Если ответ ещё не начинался, клиент получает JSON с причиной: 404 для именованной сессии, 503 для запроса без сессии. Настройки сессий не менялись, переиндексация не нужна | | 27.09.2026 (утро) | `dd84456b31d1` (latest `09f6fe5ec3c6`, arm64 `5aad3ce0630d`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_CODEMETADATA_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна | | 27.09.2026 (ночь) | `3c7990f663ad` (latest `adb5fb97033e`, arm64 `58f87123cc99`) | Во время переиндексации `codesearch`, `metadatasearch` и `helpsearch` отвечают из опубликованного поколения; в grep они уходят только до первой публикации индекса или при пустой коллекции (раньше идущая сборка переводила их на grep). `VECTOR_OPTIMIZE_EVERY=0` снова отключает промежуточные слияния (значение молча игнорировалось). Новая `VECTOR_OPTIMIZE_FINAL_MIN_DOCS` (по умолчанию `0` — как раньше): финальное слияние пропускается, пока его ждут меньше N документов. Переиндексация не нужна | | 26.09.2026 (вечер) | `e7a95e02d59d` (latest `d8c1cc0e528f`, arm64 `561391715e27`) | Описания инструментов в `tools/list` короче: из них убраны номера тикетов, история и обоснования для разработчиков; параметры, коды отказа, подсказки выбора инструмента и примеры не менялись. `stats` называет статус фазы `incomplete` (причина `lane_incomplete:`), а абзац о бюджете ответа ссылается на семантику конверта `compact_search`. Схемы, имена инструментов и параметров не изменились; переиндексация не нужна. | | 26.09.2026 | `7daf290b6e6a` (latest `4885214105af`, arm64 `100fb2974421`) | Дорожка, которую прерванное слияние оставило неслиянной (`fts_index_incompatible` / `rebuild_required`), восстанавливается следующим обычным прогоном из сохранённых в ней документов — без разбора исходников и эмбеддингов, даже на неизменной выгрузке; `reindex(force=true)` нужен, только если это не удалось. Обычный прогон больше не пересобирает повреждённую дорожку из исходников. В ту же сборку вошло всё из 25.09: бюджет ответа по умолчанию, права ролей с RLS, виртуальные таблицы и стандартные реквизиты, XDTO `Package.bin`, вызовы обработчиков по имени. | | 26.09.2026 | `7a5403b45ceb` (latest `40e22b76b0ef`, arm64 `5d06dcf65cfc`) | Ответ без `max_chars` ограничен 32768 символами (`RESPONSE_MAX_CHARS`, `0` снимает предел): большой ответ приходит первой страницей с `truncated: true` и `next_cursor`; `get_form_artifact`, `get_report_artifact` и `get_role_artifact` листаются тем же курсором (`max_chars`, `max_items`, `detail_level`, `cursor`). `get_metadata_details`: карточка справочника, документа и регистра содержит `standard_attributes` — стандартные поля, которые у объекта действительно есть, выведенные из его свойств; карточка регистра — `virtual_tables`: таблицы запроса (`Остатки`, `Обороты`, `СрезПоследних`, `ОборотыДтКт`, `База<Регистр>`…) с параметрами и именами полей (`КоличествоОстаток`, `СуммаОборотДт`, `Субконто1`); таблиц, которых у регистра нет, в ответе нет. `get_role_artifact`: право на реквизит или табличную часть сохраняет свой путь (`Справочники.X.Реквизиты.Y`, `owner_path`) и не выдаётся за право на объект; выданное право несёт `conditional` и `restriction_ref`, тексты условий RLS и шаблоны ограничений роли — \`restrictions=conditions | | 25.09.2026 | `103a439043ef` (latest `d042f8792aef`, arm64 `2c0074bbee81`) | Объекты, которые добавляет расширение (отчёты, справочники, документы; выгрузка конфигуратора и EDT), попадают в коллекцию метаданных: `metadatasearch(origin="extension")`, в том числе с `names_only=true`, их находит. Заимствованные объекты по-прежнему описывает основная конфигурация. В режиме `names_only` строка больше не теряет путь файла, из-за чего фильтр `origin` считал любое имя базовым. На следующем прогоне индексируются только новые дескрипторы расширений. | | 24.09.2026 | `cbd907ff06d9` (latest `5297d7bb2b57`, arm64 `5de9bacc0a2e`) | Текст эмбеддится без префиксов: из профилей моделей убраны `query:` /`passage:` семейства e5, `document:` у `qwen/qwen3-embedding-8b` и промпты EmbeddingGemma, `EMBEDDING_QUERY_PREFIX` и `EMBEDDING_DOCUMENT_PREFIX` не применяются. Запрос к Qwen3-Embedding по-прежнему идёт с инструкцией из карточки модели. **Индекс, документы которого записаны с префиксом** (модели e5, EmbeddingGemma, `qwen/qwen3-embedding-8b` или заданный `EMBEDDING_DOCUMENT_PREFIX`), **при первом запуске один раз пересобирается целиком** в новом поколении; прежнее отвечает до публикации нового. Остальные индексы не пересчитываются. | | 23.09.2026 (поздний вечер) | `f4a4497f2c18` (latest `4633b478dabd`, arm64 `00fd13e99ea9`) | Запросы к модели Ollama `qwen3-embedding:<размер>` (`:8b`, `:4b`, `:0.6b`, `:latest`) идут с инструкцией задачи Qwen3, как у остальных имён Qwen3-Embedding; раньше они шли без неё. Документы эмбеддятся как раньше, переиндексация не нужна. Текст инструкции остался из карточки модели: формулировки под 1С на тестовом корпусе оказались хуже (см. [конфигурацию](/mcp-servery-1c/servery/code-metadata-search/konfiguraciya.md)). | | 23.09.2026 (вечер) | `01ad979b70ce` (latest `1b337233579d`, arm64 `43e7e34b46d9`) | Смена `EMBEDDING_MODEL` (или профиля векторного хранилища) больше не останавливает сервер при запуске ошибкой `zvec store signature mismatch`. Сервер стартует, векторы старой модели в поиске не участвуют (поиск по коду в это время идёт по файлам, журнал называет каждую дорожку и отличающуюся настройку), полный индекс новой модели собирается в новом поколении и включается после публикации; `RESET_DATABASE` не нужен. Индекс, построенный той же моделью, открывается как есть, переиндексация не нужна. | | 23.09.2026 | `fcd16e372f45` (latest `246705024ebe`, arm64 `889c4a18865a`) | Описание инструмента `search_forms` называет фактический поиск — гибридный (вектор + полнотекстовый, RRF, переранжирование) по коллекции `forms` индекса zvec — вместо ChromaDB, и точное условие перехода на поиск по файлам. Поведение и индекс не менялись, переиндексация не нужна. | | 22.09.2026 | `4e2dcc1208f9` (latest `53013da95150`, arm64 `2d17730f8223`) | Запросы к Qwen3-Embedding (0.6B, 4B, 8B) идут с инструкцией задачи из карточки модели вместо `query:` ; на тестовом корпусе у 8B MRR 0,855 → 0,941. Префиксы документов прежние, переиндексация не нужна. Добавлен профиль EmbeddingGemma (`task: search result \| query:` / `title: none \| text:` ); индекс, построенный на ней раньше, пересоберите. | | 19.09.2026 | `747b60e559cf` (latest `357eabfeeaab`, arm64 `1b9e97fd6848`) | Глубина поиска HNSW `ef` ограничена пределом zvec 2048: поиск с фильтром по области, расширяющий окно кандидатов, больше не теряет векторную полосу молча (ошибка backend теперь пишется в журнал как WARNING). `build_ordinary_form` пишет записи `Form.bin` открытым текстом, что бы ни говорил флаг `deflated` (платформа 8.3.27 не открывает сжатые потоки). Индексация, формат журнала эмбеддингов и слияния не затронуты; переиндексация не нужна. | | 18.09.2026 (вечер) | `aeae0e0eaee5` (latest `24bd2d4f21aa`, arm64 `8e9956a7bb04`) | Журнал эмбеддингов (`embedding-journal/`) пишет float32 вместо float64 — вдвое меньше на запись; старые записи читаются и заменяются по мере изменения файлов. Новая переменная `EMBEDDING_JOURNAL=false` выключает журнал. Раздел «Место на диске» в документации: ориентиры по поколениям и журналу. | | 18.09.2026 | `57b5f05214e7` (latest `27f30817ce2c`, arm64 `5354fcf2c6aa`) | zvec 0.7.0 на всех платформах: запись в хранилище идёт во время фонового слияния, хвост фазы кода больше не стоит часами на последних файлах. Журнал говорит, чего ждёт фаза (`waiting for optimize`), и ведёт темп по последним минутам. Старые хранилища открываются без пересборки. | | 16.09.2026 | `6e372b5b13f1` (latest `e31f5108df36`, arm64 `1d50828023bf`) | Отпечаток `embedding_model` не зависит от прогрева процесса: перезапуск контейнера с той же удалённой моделью больше не запускает полную пересборку. XML расширений в подындексном проходе стоит одного поиска, а не сканирования хранилища. | | 11.09.2026 | `d8f4300f04ed` (latest `0a3eb69d5a35`, arm64 `14fe74abefb2`) | Полнотекстовый индекс не пересобирается после каждого XML-описания объекта расширения (отложенная сборка FTS). | | 11.09.2026 | `40853885bda9` (latest `89ecc66a9184`, arm64 `822e39833462`) | Обход SIGSEGV во втором нативном FTS-запросе zvec по одному хранилищу: гибридный поиск идёт лексикой, затем вектором, в одном потоке. Полностью причина (AVX2 в собственной сборке zvec) устранена 14.09 в следующей сборке. | | 09.09.2026 | `c46dd0e4a420` (latest `3d1359788fc2`, arm64 `5b4f50315201`) | Хенг фазы кода на 98 %: периодический flush zvec больше не вызывается во время фонового `optimize` (все потоки засыпали на блокировке записи). | | 09.09.2026 | `480e7cfb699c` (latest `6cd611301b16`, arm64 `53a2aa1a202a`) | `fts_index_incompatible` на инкрементальных прогонах: поколение копируется и публикуется только после финализации записи и FTS (с проверкой числа документов); перестраиваемый индекс не удаляется сборщиком мусора. | ## Graph Metadata Search (`comol/1c_graph_metadata`) | Дата | light-beta | Что изменилось | | -------------------------- | ------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 21.10.2026 | `fe99d9b6cfe2` (тег `light`; latest `9d606a9bb055`, arm64 `ce3e9ca9a6d8`) | **ВНИМАНИЕ: ЕСЛИ В ГРАФЕ ЕСТЬ СЛОИ РАСШИРЕНИЙ (КАТАЛОГ РАСШИРЕНИЙ ИЛИ `EXTENSION_NAME`), ПРИ ПЕРВОМ СТАРТЕ КАЖДЫЙ СЛОЙ ОДИН РАЗ ПЕРЕСТРАИВАЕТ СВЯЗИ ВЫЗОВОВ (`CALLS`) СВОИХ МОДУЛЕЙ: ВЕРСИЯ ГРАФА ВЫЗОВОВ СЛОЯ 6 → 7. ОСНОВНАЯ КОНФИГУРАЦИЯ НЕ ПЕРЕСТРАИВАЕТСЯ (ЕЁ ВЕРСИЯ ОСТАЁТСЯ 5), МЕТАДАННЫЕ, ФОРМЫ И ЭМБЕДДИНГИ НЕ ПЕРЕЧИТЫВАЮТСЯ. БЕЗ РАСШИРЕНИЙ ГРАФ ВЫЗОВОВ НЕ ПЕРЕСТРАИВАЕТСЯ.** `Новый ОписаниеОповещения("Имя", ЭтотОбъект)` и `ПодключитьОбработчикОжидания("Имя")` в модуле заимствованного объекта, если этой процедуры нет в модуле расширения, дают связь с процедурой базового модуля того же объекта: `CALLS{resolution: borrowed_object}`. Раньше обработчик искался только в файле расширения (обработчик ожидания — ещё и в глобальных модулях), и связи не было. В дереве `trace_call_chain` такой шаг помечен `[вызов через ОписаниеОповещения]` или `[вызов через ПодключитьОбработчикОжидания]`. Каталог сам находит слои с графом вызовов прежней версии; в предупреждении прохода — `Слой <имя>: граф вызовов построен прежней версией`. `refresh_extension_layers` не нужен. Одно разобранное чтение (`ACCESSES_REGISTER`, `READS_TABLE`) — одно ребро. Раньше в каталоге расширений оно записывалось между всеми копиями заимствованного объекта. Лишние копии удаляются один раз при старте, без повторного чтения модулей и без перестройки `CALLS` и основной конфигурации; если копии были, в журнале — `Removed N read edge(s) that earlier builds wrote to every copy`. Граф без расширений этот проход ничего не удаляет. `search_metadata` на смысловом и смешанном пути добавляет соседей по графу (`ENABLE_GRAPH_EXPANSION`) только в свободные места из десяти. Раньше соседи трёх лучших результатов дописывались все, и короткий ответ разрастался. JSON-шаблон соседей не добавляет. Ключ и настройки прежние. См. [страницу сервера](/mcp-servery-1c/servery/graph-metadata-search.md) | | 20.10.2026 | `1122d9fb0b1d` (тег `light`; latest `4ced3c07abbf`, arm64 `8f73969c5e36`) | **ВНИМАНИЕ: ЕСЛИ В ГРАФЕ ЕСТЬ СЛОИ РАСШИРЕНИЙ (КАТАЛОГ РАСШИРЕНИЙ ИЛИ `EXTENSION_NAME`), ПРИ ПЕРВОМ СТАРТЕ КАЖДЫЙ СЛОЙ ОДИН РАЗ ПЕРЕСТРАИВАЕТ СВЯЗИ ВЫЗОВОВ (`CALLS`) СВОИХ МОДУЛЕЙ, В КАТАЛОГЕ — ЕЩЁ И СВЯЗИ `EXTENDS`/`OVERRIDES` СЛОЯ. ОСНОВНАЯ КОНФИГУРАЦИЯ НЕ ПЕРЕСТРАИВАЕТСЯ, МЕТАДАННЫЕ, ФОРМЫ И ЭМБЕДДИНГИ НЕ ПЕРЕЧИТЫВАЮТСЯ. БЕЗ РАСШИРЕНИЙ НИЧЕГО НЕ ПЕРЕСТРАИВАЕТСЯ.** Вызов без имени модуля из модуля расширения доходит до процедуры базового модуля того же объекта (у формы — той же формы): `CALLS{resolution: borrowed_object}`. Раньше связи не было, и `trace_call_chain(direction="callers")` базовой процедуры не видел вызывающих из расширений. Каталог расширений сам находит слои с графом вызовов прежней версии и один раз обрабатывает их с продолжением, `refresh_extension_layers` не нужен. `trace_call_chain` нумерует процедуры (`total` и `returned` считают процедуры, а не строки), помечает процедуры расширений и перехваты `&Вместо` / `&ИзменениеИКонтроль`. `find_object_referrers`: одна запись на объект-источник и вид доступа с `occurrences`, первыми пятью `locations` и `layers`; `referrer_count` считает объекты (копии заимствованного объекта в слоях — один), `edge_count` — места в коде; пакетная форма даёт каждой цели до пяти источников и `targets_total`, копию объекта в слое отдельной целью не показывает. Раньше ответ брал первые 200 обращений по имени источника: у документа с 557 обращениями от 79 объектов было 38 строк, пакетная форма отвечала одной целью. `health_graph(project_id)` и `get_graph_project_status` больше не упираются в таймаут 25 с: выгрузка Конфигуратора распознаётся по `Configuration.xml` / `ConfigDumpInfo.xml` в корне, без обхода папок категорий (ЗУП через bind mount Docker Desktop: больше 90 с → 0,16 с). `get_report_dcs_lineage` читает каждую стадию для категории отчёта: схема одноимённого объекта другой категории (регистр `ТоварыКОтгрузке`) в цепочку отчёта не попадает. Текстовые ответы: `returned` совпадает с `text_returned_records` и после уменьшения страницы по `max_chars` (было `returned: 0`). `business_search` соблюдает `top_k`: соседи по графу (`ENABLE_GRAPH_EXPANSION`) только заполняют свободные места. Ключ и настройки прежние | | 17.10.2026 | `a328e8577f08` (тег `light`; latest `feb0831a4e69`, arm64 `520db706ab74`) | **ВНИМАНИЕ: ВЫПУСК ВКЛЮЧАЕТ ПРЕДЫДУЩИЙ ВЫПУСК 17.10.2026 (`eea6d9906617`). ПРИ ОБНОВЛЕНИИ С ОБРАЗА ДО НЕГО ГРАФ ИЗ XML-ВЫГРУЗКИ КОНФИГУРАТОРА ПРИ ПЕРВОМ СТАРТЕ ОДИН РАЗ ПЕРЕСИНТЕЗИРУЕТ ОТЧЁТ И ПЕРЕЧИТЫВАЕТ МЕТАДАННЫЕ, КАК ОПИСАНО В ЕГО СТРОКЕ НИЖЕ. С ОБРАЗА `eea6d9906617` ОБНОВЛЕНИЕ НИЧЕГО НЕ ПЕРЕСТРАИВАЕТ: ЭТОТ ВЫПУСК МЕНЯЕТ ТОЛЬКО ЧТЕНИЕ.** `get_object_dossier` без `project_name` находит объект, который объявлен только в слое расширения каталога (собственный общий модуль, подсистема, общая картинка): досье строится по этому слою, как с `project_name=<слой>`, и в начале об этом сказано. Раньше такой объект отвечал «не найден». Текстовый запрос `search_metadata` (и `search_metadata_by_description`): слово, оканчивающееся на `_`, ищется как префикс имени — `КПД_` находит объекты, имена которых начинаются с `КПД_`. Раньше запрос совпадал только с целым словом `кпд_` и не находил ничего. На имя слоя расширения вместо имени объекта `search_metadata` и `get_object_dossier` отвечают, что это слой, и называют вызовы для его объектов (`list_objects_by_name` с `project_name=<слой>`) — раньше текстовый поиск отдавал нерелевантные объекты по описаниям. Ключ и настройки прежние | | 17.10.2026 | `eea6d9906617` (тег `light`; latest `b74e663e6e4b`, arm64 `1465eb796d45`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ ГРАФ, ПОСТРОЕННЫЙ ИЗ XML-ВЫГРУЗКИ КОНФИГУРАТОРА, ОДИН РАЗ ЗАНОВО СИНТЕЗИРУЕТ ОТЧЁТ ПО КОНФИГУРАЦИИ И ПЕРЕЧИТЫВАЕТ ИЗ НЕГО МЕТАДАННЫЕ (ОБЪЕКТЫ, РЕКВИЗИТЫ, ТАБЛИЧНЫЕ ЧАСТИ И ДРУГИЕ УЗЛЫ ОТЧЁТА) ПОВЕРХ ГРАФА. ЗУП 3.1 (9 342 ОБЪЕКТА, 27,6 ТЫС. XML-ФАЙЛОВ) — ОКОЛО 6 МИНУТ С ЛОКАЛЬНОГО ДИСКА: СИНТЕЗ 5,2 МИНУТЫ, ЧТЕНИЕ И ЗАПИСЬ ОКОЛО МИНУТЫ. ЕСЛИ ВЫГРУЗКА СМОНТИРОВАНА В DOCKER DESKTOP С ДИСКА WINDOWS — В РАЗЫ ДОЛЬШЕ, ДЕСЯТКИ МИНУТ И БОЛЬШЕ: НА НАШЕМ СТЕНДЕ ОДИН ТОЛЬКО ОБХОД ТАКОЙ ВЫГРУЗКИ ЗАНЯЛ 35 МИНУТ. ГРАФ НЕ ОЧИЩАЕТСЯ; ЭМБЕДДИНГИ, БИЗНЕС-ОПИСАНИЯ, BSL-МОДУЛИ И ГРАФ ВЫЗОВОВ, СТРУКТУРА ФОРМ, ПРАВА РОЛЕЙ И ДРУГИЕ XML-ПОДИСТОЧНИКИ НЕ ПЕРЕСТРАИВАЮТСЯ. ГРАФЫ ИЗ ОТЧЁТА КОНФИГУРАТОРА (`.txt`) И ИЗ ПРОЕКТА 1C:EDT НЕ ПЕРЕЧИТЫВАЮТСЯ; СЛОЙ КАТАЛОГА РАСШИРЕНИЙ — ПРИ СЛЕДУЮЩЕМ ОБНОВЛЕНИИ СЛОЯ.** `find_by_guid` находит объект метаданных по `uuid` его файла `<Папка>/<Имя>.xml`: отчёт, синтезированный из XML-выгрузки, теперь несёт для каждого объекта свойство `Идентификатор` (у реквизитов, табличных частей, форм и макетов GUID по-прежнему нет). Раньше в графе из XML-выгрузки GUID объектов не было вовсе. Включает выпуск 16.10.2026. Ключ и настройки прежние | | 16.10.2026 | `3082a8e8f3be` (тег `light`; latest `7b4f73da1eb5`, arm64 `e3ec1c8927d7`) | `find_object_referrers` с `object_name` больше не отвечает `total=0` на графе без `GRAPH_SCOPE_ENFORCED` (по умолчанию он выключен): объект находился, а его рёбра искались ещё и по `project_id` и `mcp_namespace`, которых у узлов такого графа нет. Права роли на саму конфигурацию (`Configuration.<Имя>` в `Rights.xml`: режимы основного окна, клиент системы аналитики) больше не записываются как права на одноимённые объекты (константу, функциональную опцию). Такие ошибочные рёбра `GRANTS_ACCESS_TO` удаляет один запрос при старте, роли не перечитываются. Права на конфигурацию рёбрами графа не хранятся. `get_form_structure`: вся структура формы — один постраничный список `items` (`max_items`, `cursor`): элементы, затем реквизиты формы, команды, события и пункты меню, у каждого поле `section`. В `data` — форма и `counts` по разделам. Раньше при любом `max_items` в `data` целиком повторялись все элементы, реквизиты, команды и события. Клиент, читавший разделы из `data`, берёт их теперь из `items`. `find_test_artifacts` у проиндексированного проекта без манифеста источников (обычный режим сервера) берёт тестовые артефакты из модулей графа (`data.source: graph`). Раньше он обходил каталог выгрузки и через bind mount Docker Desktop не укладывался в таймаут. `find_by_guid` при «не найдено» сообщает, если у объектов метаданных графа нет GUID: в отчёте по конфигурации, выгруженном или синтезированном из XML-выгрузки, их нет. `LOAD_DCS_TEMPLATES=true` без других XML-подисточников теперь запускает их фазу (раньше она не планировалась). Схемы СКД выгрузки Конфигуратора читаются из `Templates/<Макет>/Ext/Template.xml`. Граф не перестраивается, переиндексация не нужна. Ключ и настройки прежние | | 13.10.2026 | `c5b23a7a5c91` (тег `light`; latest `5c601b80c7d3`, arm64 `9709e100bab2`) | На Neo4j 2026.01 и новее векторный поиск читает индексы предложением Cypher `SEARCH`, а не процедурой `db.index.vector.queryNodes`, которую Neo4j с 2026.04 считает устаревшей. Поэтому Neo4j больше не пишет на каждый поиск предупреждение `01N01` (DEPRECATION). Это касается всех векторных поисков: по бизнес-описаниям и описаниям, по их фрагментам, по процедурам и по коду. Выдача не изменилась: те же top-k, оценки сходства и фильтры по проекту, категории и конфигурации. Совпадение проверено на Neo4j 2026.04.0 и 2026.09.0. На Neo4j 5.x индекс по-прежнему читается процедурой. С `VECTOR_RETRIEVAL_STRATEGY=bounded_overfetch` (откат) процедура используется на любой версии. Версия Neo4j определяется при подключении и заново после переподключения. В режиме запуска по умолчанию `POST /mcp` больше не получает `307 Temporary Redirect` на `/mcp/`: `/mcp` и `/mcp/` обслуживаются напрямую, и клиент, который не следует перенаправлениям, подключается по адресу из `mcp.json` (`http://localhost:8006/mcp`). Граф и индексы не перестраиваются, переиндексация не нужна. Ключ и настройки прежние | | 12.10.2026 | `0d67741ed4b2` (тег `light`; latest `9eaf027fb5bf`, arm64 `0b274c9bc1d8`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ МЕТАДАННЫЕ ОДИН РАЗ ПЕРЕЧИТЫВАЮТСЯ (ОТЧЁТ, ВЫГРУЗКА ИЛИ `.mdo` ПРОЕКТА EDT) И СВЯЗИ `USED_IN` И `DO_MOVEMENTS_IN` СТРОЯТСЯ ЗАНОВО: ЗУП 3 ИЗ EDT — 42 С С ЛОКАЛЬНОГО ДИСКА, ОКОЛО 11,5 МИНУТЫ, ЕСЛИ ПРОЕКТ СМОНТИРОВАН В DOCKER DESKTOP С ДИСКА WINDOWS; ГРАФ НЕ ОЧИЩАЕТСЯ, МОДУЛИ, ФОРМЫ И ВЕКТОРЫ НЕ ПЕРЕСОБИРАЮТСЯ.** В проекте 1C:EDT появились связи «документ делает движения по регистру» (`DO_MOVEMENTS_IN`, из `registerRecords` в `.mdo`) и «объект используется в реквизите» (`USED_IN`, из типов `CatalogRef.…`, `DocumentRef.…` и других в написании дескриптора; составной тип даёт связь с каждым объектом). Раньше этих связей не было вовсе, поэтому `find_register_movement_docs`, `get_register_writers`, `trace_impact`, `find_objects_using_object` и `find_usages_of_object` отвечали пусто или неполно. ЗУП 3 (EDT): 1928 связей движений и 15 159 `USED_IN`, было 0 и 0. Во всех проектах, в том числе построенных из отчёта, обе связи теперь ведут только к объекту нужной категории. Раньше связь цеплялась ещё к одноимённой подсистеме, общему модулю или отчёту (в графе ЗУП из отчёта — 1906 ложных `USED_IN` от общих модулей). Версии пакетов Python в образах закреплены и совпадают с выпуском 10.10 (у arm64 восемь пакетов поднялись до версий amd64, например openai 3.22.1 → 3.24.0). | | 10.10.2026 | `9ce2b7c4b76c` (тег `light`; latest `a2350d168d95`, arm64 `05efc94726d1`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ ПРАВА ВСЕХ РОЛЕЙ, ПОДПИСКИ НА СОБЫТИЯ, ПРЕДОПРЕДЕЛЁННЫЕ ЭЛЕМЕНТЫ И СПРАВКА ОДИН РАЗ ПЕРЕЧИТЫВАЮТСЯ ЦЕЛИКОМ** (включённые `LOAD_ROLE_RIGHTS`, `LOAD_EVENT_SUBSCRIPTIONS`, `LOAD_PREDEFINED_VALUES`, `LOAD_HELP_FROM_HTML`; граф не очищается, остальные этапы идут с resume). Дальше эти подисточники сверяются с выгрузкой по hash документа при каждом старте и плановом обновлении: изменённые права роли перечитываются (старые права снимаются), новые подписки загружаются, удалённые роли, подписки, предопределённые элементы и справка удаляются из графа; нечитаемый документ за удалённый не принимается, пустой результат по виду документов ничего не удаляет. Каталог расширений: объект, присутствующий в нескольких слоях, в инструментах связей (`get_event_subscriptions`, `get_access_rights`, `find_predefined_values`, `get_register_writers`, `get_data_links`, `get_report_dcs_lineage`) разрешается в базовый слой с перечислением копий в `notes` вместо ответа `ambiguous`; `find_usages_of_object` не повторяет реквизит по слоям; `resolve_effective_entity` отдаёт `order_source` каждого слоя и предупреждает, если порядок слоёв взят из имён выгрузок (манифеста порядка нет). `search_code`: полнотекстовый канал требует все слова запроса (`РеализацияТоваровУслуг.Склад` — оба слова), слово с `*` на конце ищется как префикс (`Kaspi*`), операторы Lucene — обычный текст. Ответы структурных инструментов при `GRAPH_ONLY=true` (и вообще без векторной дорожки) больше не помечаются `degraded: true`: флаг означает неполный ответ самого инструмента, режим установки виден в `list_graph_capabilities`, `health_graph` и `get_indexing_status().service_mode`. База OpenAI-совместимого API без суффикса `/v1` при `EMBEDDING_API_BASE_NO_V1=1` передаётся дословно (см. [переменные окружения](/mcp-servery-1c/prilozhenia/peremennye-okruzheniya.md)). | | 07.10.2026 | `2afb2f6e403a` (тег `light`; latest `ef1c134c5888`, arm64 `bc72cbfb549e`) | Под координатором загрузки (`INGESTION_COORDINATOR_ENABLED=true`) прогон, в котором упала основная задача (например, `bsl_code_graph`), отпускает лиз: `ingestion_promote` дожидается всех основных задач, не публикует поколение и завершается ошибкой с перечнем упавших задач и их причин, staging-поколение сохраняется, следующий прогон берёт лиз и продолжает его. Раньше `ingestion_promote` в таком прогоне не запускался, и heartbeat продлевал лиз, пока жив процесс: встроенная сверка `GRAPH_REFRESH_INTERVAL_SEC` повторяла прогон своим же лизом, а остальные писатели проекта получали отказ до перезапуска. Перечисление каталогов выгрузки при сканировании BSL повторяется до трёх раз при `EAGAIN`/`EINTR` (`BlockingIOError: [Errno 11]`), в журнале — `listing it again, attempt N of 3`. Включает выпуск 06.10.2026 (переиндексация `CALLS` при первом старте — см. строку ниже). Сверх выпуска 06.10.2026 переиндексации нет | | 06.10.2026 | `8b0e3a4983e8` (тег `light`; latest `3b925d79da24`, arm64 `053cecd3b745`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ НОВЫЕ МОДУЛИ ДОЧИТЫВАЮТСЯ, А СВЯЗИ ВЫЗОВОВ (`CALLS`) И ПРЯМЫЕ ОБРАЩЕНИЯ К РЕГИСТРАМ ОДИН РАЗ ПЕРЕСОБИРАЮТСЯ ПО ВСЕМ МОДУЛЯМ ОСНОВНОЙ КОНФИГУРАЦИИ (НА ЗУП — 11 МИНУТ НА ВЕСЬ ЭТАП КОДА); МЕТАДАННЫЕ, ФОРМЫ И EMBEDDINGS НЕ ПЕРЕСТРАИВАЮТСЯ. ПРОЕКТЫ ИЗ `register_graph_project` ПОЛУЧАТ ЭТИ ИЗМЕНЕНИЯ ПРИ СЛЕДУЮЩЕМ `refresh_graph_project` (`mode=full`).** Модули приложения, сеанса, внешнего соединения, сервисов интеграции и менеджеров критериев отбора загружаются в граф. Подписка на событие связана с процедурой своего общего модуля из `handler`, ошибочные связи старого графа исправляются при старте. `explain_graph_evidence` находит узел по ключу (регистр `filename` не важен, неполный ключ — `ambiguous`, нет узла — `not_found`). `USED_IN` и `find_usages_of_object` — только собственные реквизиты, измерения и ресурсы владельца, без строк ролей. Индексы `Attribute` под запись обоснований; обоснования вызовов пишутся порциями (на ЗУП пик памяти 2,15 ГБ вместо 4,6 ГБ); фрагменты описаний находятся по `chunk_id` после аварийной остановки; первая сборка векторов процедур строит индекс после записи векторов. При `GRAPH_SCOPE_ENFORCED=true` JSON-операции `search_metadata`, `get_object_dossier` и `resolve_qualified_name` находят объекты проекта по `project_id`, без `project_name`; `project_name`, равный `project_id`, больше не опустошает текстовый поиск. `total` текстового ответа не считает строки пояснения («No results found» — `total: 0`). Векторы описаний объектов строятся после загрузки каталога расширений; недостающие досчитываются при первом старте. Проекты из `register_graph_project` при выключенном координаторе переживают перезапуск, `delete_graph_project` удаляет и данные проекта, заново зарегистрированного поверх своих данных; проекты прежних образов — один раз `register_graph_project` после обновления, без пересборки. Ключ и настройки прежние | | 04.10.2026 (вечер) | `0438e3728917` (тег `light`; latest `8a38a98b0901`, arm64 `76fe46991655`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ, ЕСЛИ XML-ВЫГРУЗКА МЕНЯЛАСЬ ПОСЛЕ ПОСЛЕДНЕГО ЧТЕНИЯ МЕТАДАННЫХ, МЕТАДАННЫЕ БАЗЫ ОДИН РАЗ ПЕРЕЧИТЫВАЮТСЯ (НА ЗУП ОКОЛО 3 МИНУТ), А ОБЪЕКТЫ, УДАЛЁННЫЕ ИЗ ВЫГРУЗКИ, УДАЛЯЮТСЯ ИЗ ГРАФА. ВЕКТОРЫ, БИЗНЕС-ОПИСАНИЯ И ГРАФ BSL НЕ ПЕРЕСЧИТЫВАЮТСЯ.** Изменения метаданных XML-выгрузки применяются при перезапуске и сверкой `GRAPH_REFRESH_INTERVAL_SEC`: метаданные перечитываются и сливаются поверх, объекты, реквизиты, табличные части, формы, команды и макеты, которых в выгрузке больше нет, удаляются. Формы, изменённые при остановленном сервере, перечитываются после старта по сохранённому снимку выгрузки; первый старт образа снимок только сохраняет и формы не перечитывает. Каждый тёплый старт дополнительно сверяет время изменения `*.xml` выгрузки (на ЗУП 10–20 с). Каталог расширений: слой с незавершённой прошлой загрузкой (например, связи упали по таймауту транзакции) при следующем старте обрабатывается заново, раньше он считался актуальным и оставался без связей. Связи слоя с основной конфигурацией строятся за время, зависящее от размера слоя: на модели ЗУП 75 с → сотые доли секунды. `refresh_extension_layers` отвечает `accepted` сразу и выполняется на сервере, а также удаляет из графа то, чего нет в выгрузке слоя. Новых индексов нет. Ключ и настройки прежние, при обновлении скачивается только слой приложения | | 04.10.2026 | `1c96e12e3bbc` (тег `light`; latest `4854d23f1305`, arm64 `6f2bf815b48e`) | Каталог расширений: если имя расширения совпадало с `PROJECT_NAME`, при старте на существующих данных код основной конфигурации и расширения удалял модули друг друга. Теперь модуль принадлежит слою по имени и виду слоя. Удаление такого расширения из каталога не удаляет проект основной конфигурации, при совпадении имён пишется предупреждение. Импорт и генерация бизнес-описаний при `EXTENSION_CATALOG_ENABLED=true` начинаются после загрузки расширений. Собственные объекты расширений описываются по выгрузке своего расширения, раньше они пропускались с `no XML source`. Сгенерированное описание записывается в граф и без словаря токенизатора: раньше без доступа к его загрузке каждое описание терялось после вызова LLM. Если у построенного проекта сменился файл-источник метаданных (переход с отчёта на выгрузку, переименование отчёта), узлы переносятся на новый файл, а не дублируются. При `BACKGROUND_POST_INDEXING=false` в журнал пишется предупреждение, что порт откроется после всех фоновых задач. Лейн процедур заканчивается строкой `Routine embedding finished: …`. Граф и индексы не перестраиваются. При первом старте в план описаний попадут только ещё не описанные собственные объекты расширений — это вызовы LLM. Слой зависимостей пересобран: при обновлении `latest` скачивается заново около 430 МБ, `light` — около 70 МБ. Ключ и настройки прежние | | 03.10.2026 | `987526a912f1` (тег `light`; latest `2472f9802cd5`, arm64 `f88ebb50537f`) | Поведение не изменилось: тот же код, что в выпуске ниже, собран заново по новой схеме сборки. Скомпилированные модули в `latest`, `light` и `arm64` побайтно те же, что в выпуске ниже. Слои базы и зависимостей не изменились, поэтому при обновлении скачивается только слой приложения. Граф и индексы не перестраиваются. Ключ и настройки прежние | | 01.10.2026 (поздний вечер) | `bf5bc28bb0fc` (тег `light`; latest `354620f0a887`, arm64 `d3d157ae08e6`) | Число попыток одного запроса к API эмбеддингов задаётся переменной `EMBEDDING_MAX_ATTEMPTS` (1–10, по умолчанию 3 — как раньше) для индексации и для эмбеддинга поискового запроса; раньше клиент сам повторял каждый запрос дважды без настройки. Пакет индексации отправляет к провайдеру не больше `EMBEDDING_MAX_ATTEMPTS` × (`BATCH_MAX_RETRIES` + 2) запросов. Индекс не перестраивается. | | 01.10.2026 (вечер) | `59ba62fd51e7` (тег `light`; latest `cfab205249bf`, arm64 `8d0d95a628c0`) | Процедуры и функции с модификатором `Асинх`/`Async` загружаются в граф (раньше не распознавались); при первом старте один раз перезагружаются только модули с такими процедурами, эмбеддинги считаются только для новых. `REFERENCE_EVIDENCE_ENABLED=true`: обоснования читаются по индексам `ReferenceEvidence(subject_ref)` и `(source_unit_id)`, которые создаются при старте — `explain_graph_evidence` и `explain_graph_entity` больше не упираются в таймаут на больших графах; проход вызовов больше не закрывает обоснования `declared` тех же файлов (полный набор — после сборки графа заново). `list_graph_indexes` считает покрытие по выборке до 20 000 узлов на метку (`data.coverage_sample`). Методы HTTP-сервисов (`UrlMethod`) снова записываются: с 10.09 они не писались, а ремонт дублей утреннего выпуска 01.10 удалял оставшиеся от старых сборок; при первом старте метаданные один раз перечитываются, удалённые методы возвращаются. | | 01.10.2026 | `285cea102212` (тег `light`; latest `4c172d96c522`, arm64 `0b537cbefc65`) | `explain_graph_entity` и `fetch_graph_nodes` принимают `node_id` процедуры из `resolve_graph_entity` (раньше `not_found`/`missing`). У процедур-перехватчиков расширения в `attributes` есть `extension_mode` и `extension_target`; шаблоны `extension_interceptor_counts` и `extension_interceptors` дают инвентаризацию аннотаций по слоям. Модули общих форм, общих команд и планов видов расчёта загружаются в граф (раньше пропускались и в конфигурации, и в расширениях): при первом старте граф вызовов один раз пересобирается, embeddings строятся только для новых процедур; слой расширения, загруженный раньше, обновляется вызовом `refresh_extension_layers`. `.bsl` рядом с `Form.bin` в папке формы — модуль обычной формы. `REFERENCE_EVIDENCE_ENABLED=true` больше не роняет `bsl_code_graph` («Expected list, got tuple» в собранном образе). Векторизация процедур не останавливается из-за одной нечитаемой записи в Neo4j: запасное чтение идёт пакетами, нечитаемое свойство восстанавливается из исходного файла. Модуль, записанный в граф без хэша содержимого, перезагружается как изменённый — сдвиг строк больше не даёт дублей процедур. | | 30.09.2026 | `044896f5aa42` (тег `light`; latest `085fd1452d77`, arm64 `21011f7e56c2`) | Обновление образа поверх графа, построенного образами по 09.09.2026, больше не удваивает вложенные элементы: реквизиты, табличные части, формы с их структурой, команды, макеты и др. Раньше образы с 10.09 не узнавали такие элементы (у них не было имени конфигурации) и при перезагрузке метаданных писали вторую копию. **Первый старт** проставляет старым элементам имя конфигурации их объекта. В уже удвоенном графе он удаляет старые копии пачками, а их права на поля переносит на оставшиеся. Пересоздавать Neo4j не нужно. `get_object_dossier` в проекте каталога расширений: `project_name` фильтрует слой во всех секциях. Без него собственные элементы расширения помечены слоем, заимствованные показаны один раз, у перехватчиков в секции `code` указана аннотация. `compare_base_and_extension` группирует переопределения по аннотации (`&Вместо`, `&ИзменениеИКонтроль`, `&Перед`, `&После`) и называет базовую процедуру. Перехваченная базовая процедура больше не попадает в «Из базы без изменений». Если провайдер эмбеддингов недоступен, а локальной модели в образе нет (light), дорожки эмбеддингов завершаются ошибкой с этой причиной, а не «No module named 'sentence\_transformers'». Выгрузка, смонтированная и в `/app/code`, и в `/app/extensions` (compose дистрибутива при пустом `PATH_EXTENSIONS`), больше не считается расширением самой себя, а проверка изменений обходит её один раз (`source_refresh.baseline_files` больше не удваивается). Ключ тот же, что у выпуска 27.09.2026, переиндексация не нужна | | 29.09.2026 (день) | `25aac3207039` (тег `light`; latest `ca34696ce6a6`, arm64 `c355f51aeb71`) | При `GRAPH_SCOPE_ENFORCED=true` и закрытом окне миграции проект установки (`PROJECT_NAME`) виден в `list_graph_projects` и `get_graph_project_status` и при трекере загрузки по умолчанию: с включённым координатором — по его документу в `INGESTION_STATE_DIRECTORY` (с `active_generation`), с выключенным — по данным в своём scope, с `configuration_root` выгрузки. Раньше в обоих случаях список был пуст, а статус отвечал `project_not_registered` — и в загружающем процессе, и после рестарта. Переиндексация не нужна | | 29.09.2026 | `5944be4f3310` (тег `light`; latest `6b4bce882d61`, arm64 `deb3a1248ea8`) | `search_code` берёт из одного модуля до трёх процедур вместо одной: `CODE_SEARCH_MAX_PER_MODULE` по умолчанию теперь `3`. Раньше дедупликация оставляла от модуля одну процедуру, и нужная процедура найденного модуля иногда отсекалась, если выше неё стояла соседняя. На тестовом наборе из 42 вопросов нужная процедура попала в первую пятёрку в 41 случае вместо 36. Прежнее поведение возвращает `CODE_SEARCH_MAX_PER_MODULE=1`. Переиндексация не нужна | | 28.09.2026 (вечер) | `97ba24e19e40` (тег `light`; latest `6095b118de89`, arm64 `0ea37029a267`) | При `GRAPH_SCOPE_ENFORCED=true` проект установки (`PROJECT_NAME`) после рестарта сохраняет `configuration_root` выгрузки, из которой его загружает старт (`METADATA_DIRECTORY`, иначе `CODE_EXPORT_PATH`). Раньше при закрытом окне миграции он восстанавливался из записей загрузки с `configuration_root = ` и `configuration_root_valid = false`, а `register_graph_project` помогал только до следующего пересоздания контейнера. Корень другого проекта, заданный через `register_graph_project`, по-прежнему живёт до рестарта. Ключ тот же, что у выпуска 27.09.2026, переиндексация не нужна | | 28.09.2026 (утро) | `0ff5708582e7` (тег `light`; latest `d619eb2e5dc3`, arm64 `0c84ae65b0de`) | `trace_call_chain` строит цепочку от одной процедуры. `object_name` сравнивается с полным именем объекта, префикс типа задаёт категорию (`Документ.Отпуск`); часть имени используется, только если объекта с таким именем нет и под неё подходит одна процедура. Раньше сравнение шло по подстроке, и цепочки одноимённых процедур нескольких объектов сливались под одним заголовком. Если процедур несколько, ответ `ambiguous` перечисляет их в `data.candidates` с `node_id`; новый параметр `node_id` выбирает одну. В режиме каталога слой расширения читает схемы компоновки своих отчётов (при `LOAD_DCS_TEMPLATES=true`): `get_report_dcs_lineage` отвечает по отчёту, который добавляет расширение; схема заимствованного отчёта остаётся базовой. Уже загруженный слой перечитывается вызовом `refresh_extension_layers`. Ключ тот же, что у выпуска 27.09.2026, переиндексация не нужна | | 28.09.2026 | `878c2d93825d` (тег `light`; latest `3204b0f9f460`, arm64 `1978575d18e8`) | Упавшие фазы индексации повторяются без перезапуска. Если прошлый прогон оставил их `failed` (например, Neo4j перезапустился во время `bsl_code_graph`, и зависимые фазы не запустились), очередная проверка `GRAPH_REFRESH_INTERVAL_SEC` запускает прогон заново, даже когда выгрузка не менялась. Прогон с resume: завершённое не повторяется. Защита от цикла перезапусков больше не считает крашем фазы, которые не начались из-за упавшей предпосылки. Раньше такой прогон на следующем старте или повторе записывался как OOM и увеличивал счётчик. Запись о прерванном прогоне не утверждает OOM: она перечисляет возможные причины и подсказывает, где видно OOM-kill. Ключ тот же, что у выпуска 27.09.2026, переиндексация не нужна | | 27.09.2026 (вечер) | `7df42796176b` (latest `34373b1954b7`, arm64 `db99e7c1a81b`) | `compare_graph_scope(extension_ref=…)` отправляет в Neo4j в несколько раз меньше запросов. Связи одного вида узлов читаются двумя запросами: сначала число связей каждого типа, затем все типы сразу. Раньше на каждый тип связи шёл отдельный запрос. Узлы слоя расширения читаются только тех видов, которые в слое есть. Каждый новый текст запроса Neo4j после старта компилирует заново, и на пустом кэше планов эта компиляция занимала большую часть вызова. На копии графа ЗУП со слоем из 257 объектов, сразу после старта: с `node_kinds=["MetadataObject"]` 26 → 7 запросов и 4,6 → 2,6 с, без `node_kinds` 80 → 23 запроса и 9,6 → 5,5 с. Стабильные идентификаторы строятся быстрее. Результат сравнения не изменился. Ключ тот же, что у выпуска 27.09.2026 (утро), переиндексация не нужна | | 27.09.2026 (утро) | `68df7c648a7e` (latest `115be4a200b1`, arm64 `baf79322fadd`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_GRAPH_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна | | 26.09.2026 (поздний вечер) | `01c72f1c71cb` (latest `5036d754e2c2`, arm64 `a997708fe1e6`) | Роль, у которой часть строк прав не записалась (например, из-за `NEO4J_WRITE_TRANSACTION_TIMEOUT_S`) или прогон которой прервался, больше не считается загруженной: объектные права роли пишутся последними, а у роли с неудавшимися строками сбрасывается отметка загрузки, и следующий старт перечитывает её. Роли перечисляются в журнале (WARNING). Очистка «осиротевших» элементов управляемых форм (остатки сборок 10–16.09) удаляет найденное порциями по 1000 в отдельных транзакциях: раньше всё удалялось одной транзакцией и на большой базе падало с `MemoryPoolOutOfMemoryError`. `compare_graph_scope(extension_ref=…)` читает сущности слоя по индексам `layer_name` и `extension_name`, а не перебором всех узлов вида: на проекте масштаба ЗУП чтения слоя обходятся примерно в 200 раз дешевле для Neo4j. **Первый старт после обновления** создаёт эти индексы (по два на вид узлов); Neo4j заполняет их в фоне, данные не пересобираются. | | 26.09.2026 (вечер) | `dbc70a107389` (latest `cb2c5190ded7`, arm64 `171507d5b9bf`) | Описания трёх инструментов исправлены по коду: `refresh_graph_project` — отказ из-за эмбеддингов снимается настройкой провайдера эмбеддингов или `GRAPH_ONLY`, а не `mode=full`, названы отказы `ingestion_busy` и `refresh_in_progress`; `refresh_extension_layers` — второй проход при резервации писателя получает `ingestion_busy`; `get_indexing_status` — `extension_catalog` выполняется вместо `extension_relationships`, названы поля `any_running`, `service_mode`, `metadata_source` и признак защиты от цикла рестартов. Код и схемы не менялись; переиндексация не нужна. | | 26.09.2026 | `354841988880` (latest `87a3411527b1`, arm64 `05ef35814862`) | Права ролей на реквизиты (`LOAD_ROLE_RIGHTS=true`) снова загружаются за секунды. Реквизит ищется от объекта-владельца, а не среди всех реквизитов проекта. На выпуске 25.09.2026 (поздний вечер) явные запреты увеличили число таких строк примерно до 8 600 на ЗУП, батчи упирались в `NEO4J_WRITE_TRANSACTION_TIMEOUT_S`, и первичная индексация не завершалась. **Первый старт после обновления один раз** перечитывает права всех ролей: на ЗУП это секунды. Остальные данные не пересобираются. `compare_graph_scope(extension_ref=…)`: концы связей передаются списком значений, поэтому ответ Neo4j вдвое меньше; каждый конец связи разбирается один раз за вызов. На проекте масштаба ЗУП процессорное время вызова меньше на 40–50%. Каждый вызов `compare_graph_scope` пишет в журнал строку INFO с временем по этапам (`read`, `evidence`, `pairs`, `base`, `compare`, `rest`) и числом запросов к Neo4j, строк и секунд чтения. Описания инструментов в `tools/list` сокращены (≈21,5 тыс. → 20,3 тыс. токенов); сигнатуры не менялись. | | 25.09.2026 (поздний вечер) | `3ce5b127e6fd` (latest `807d3cf970ec`, arm64 `868d6251296f`) | `get_object_dossier`: стандартные реквизиты, которые у объекта действительно есть (выводятся из его свойств: `Код`/`Наименование` по длине, `Владелец` по владельцам, `Период` только у периодического регистра сведений и т. д.), и виртуальные таблицы регистров (`.Остатки`, `.Обороты`, `.СрезПоследних`, `ОборотыДтКт`, `ДанныеГрафика`, `База…`) с параметрами; поля таблиц с производными именами (`КоличествоОстаток`, `СуммаОборотДт`, `Субконто1`) — `sections=["virtual_tables"]`. Имена по справке платформы 8.3.27.2130; таблиц, которых у регистра нет, в ответе нет, причина названа. `get_access_rights` отвечает объявленными правами ролей: `rights` — выдано, `denied_rights` — явно запрещено (раньше блок одних запретов терялся), `conditional_rights` — выдано с ограничением RLS (`restriction_ref`); тексты условий и шаблоны ограничений роли — \`restrictions='conditions' | | 25.09.2026 (вечер) | `47ccc4324204` (latest `f01c810bd0b2`, arm64 `a2b202f9b227`) | `compare_graph_scope(extension_ref=…)` в режиме каталога: связи читаются с квотой на каждый тип связи, а не на все связи метки сразу, и неполным считается обрезанный тип связи — раньше заимствованные объекты с более чем 10 000 связей выбрасывали из сравнения все узлы MetadataObject (`incomplete_kinds=["MetadataObject"]`); концы связей передаются только ключами, именем и слоем — на проекте масштаба ЗУП сравнение без `node_kinds` около 10 с вместо 35–41. Обработчики, названные строкой (`ОписаниеОповещения("Имя", …)`, `ПодключитьОбработчикОжидания("Имя")`), дают рёбра `CALLS`; версия лейна `bsl_call_graph` 4→5, поэтому первый старт после обновления один раз пересобирает граф вызовов (на ЗУП около 20–25 мин). Остальные данные не пересобираются. | | 25.09.2026 | `a9cee2a57e5c` (latest `61f7499d1da6`, arm64 `79e3ad948643`) | Статусы не выдают заполненный граф за пустой. `get_graph_stats`, `get_graph_schema` и `list_graph_indexes` больше не ставят `degraded` и не несут предупреждение о `GRAPH_SCOPE_ENFORCED` (факт установки остаётся в `installation_notices` у `list_graph_capabilities` и `health_graph`, текст переписан: это штатное хранение, а не остатки данных); `get_graph_stats` отвечает полями `data.scope_confined` и `data.evidence_recorded` (нулевые evidence при `REFERENCE_EVIDENCE_ENABLED=false` — норма). `list_graph_projects` показывает `inherited` с первого вызова, а не после детального; вложенный `ingestion.state` совпадает с `ingestion_state`; без координатора причина так и названа. В режиме graph-only `degraded` по-прежнему ставится на любой ответ. Данные и индексы открываются как есть. | | 24.09.2026 (вечер) | `3f71e8391a89` (latest `52549a70e707`, arm64 `80d4690d25f7`) | Формы и модули одноимённых объектов разных видов больше не сливаются. Ключ формы и всех её элементов (у управляемых и обычных форм) включает вид владельца, а модуль привязывается (`HAS_MODULE`) только к объекту вида своей папки выгрузки. `find_form_links` и `get_form_structure` понимают вид в `object_name` (`Документ.РеестрДокументов`); на голое имя, которое носят объекты разных видов с этой формой, они отвечают `ambiguous` со списком `candidates`. `compare_base_and_extension` принимает вид и называет сравниваемый вид в заголовке. Первый старт на существующих данных дольше обычного: конфигурация перечитывается один раз, склеенные формы разделяются, структура всех форм перезаписывается (`FORM_XML_IDENTITY_VERSION=6`), лишние `HAS_MODULE` удаляются. Пересобирать базу не нужно. `NEO4J_READ_TRANSACTION_TIMEOUT_S` теперь ограничивает только запросы инструментов и веб-поиска, а фоновые дорожки читают без предела: на графе из \~200 тыс. процедур выборка для эмбеддингов обрывалась через 30 с. `refresh_graph_project(mode=full)` без манифеста исходных единиц отвечает `accepted` со `staging_generation` и продолжает пересборку на сервере. Ход и итог показывает `get_graph_project_status(operation_id=...)`, неудачу — `ingestion_state=failed` с `last_error`. | | 24.09.2026 (день) | `45be453fbe4b` (latest `efc5352ddd87`, arm64 `71e9f0e5c9c6`) | Готовность векторной полосы в `/readyz`, `get_graph_project_status` и `health_graph` считается по индексам тех семантических полос, которые включены: бизнес-поиск — `business_info_vector_index` или `business_chunk_vector_index`, поиск по коду — `routine_vector_index` или `code_vector_index`, описания метаданных — `description_vector_index` или `description_chunk_vector_index`, эмбеддинги процедур — `routine_vector_index`. Раньше проверялся только `business_info_vector_index`, поэтому установка с выключенным бизнес-поиском оставалась в `ready_structural` (`vector=false`, `hybrid=false`) при готовом `routine_vector_index`. Если не включена ни одна семантическая полоса, `vector=false`. Индекс, которого не было при первой проверке, больше не считается отсутствующим до перезапуска: `/readyz` и поиск видят его, как только индексация его построила. Индексы и граф открываются как есть, переиндексация не нужна. | | 24.09.2026 (утро) | `7bf3681fd371` (latest `54d4b4b27a93`, arm64 `69fd9a007e61`) | Только сборка: скомпилированные модули те же, что в выпуске 23.09 (вечер). Из образов убраны оставшиеся от компиляции пакеты Debian, из light — пакет Cython; в latest обновились незакреплённые зависимости (`openai` 3.19.2, `cyclopts` 5.0.0 и др.). Поведение сервера не менялось. | | 23.09.2026 (вечер) | `524f0b4adc27` (latest `ea786061ae98`, arm64 `7d391975b8b0`) | Запрос к модели Qwen3-Embedding (`qwen/qwen3-embedding-8b` по умолчанию, `qwen3-embedding:8b` в Ollama) идёт с инструкцией задачи, сформулированной под объекты метаданных и код 1С (см. [Инструкция к запросу у Qwen3](https://docs.onerpa.ru/mcp-servery-1c/pages/zZx7MZNnC5Ejse6V9TZC#инструкция-к-запросу-у-qwen3)); у других моделей запрос не меняется. Узлы графа эмбеддятся как раньше: отпечатки и версии лейнов не меняются, переэмбеддинга нет. | | 23.09.2026 | `06cfffd5cc9f` (latest `015b749e811c`, arm64 `0707c4e57a64`) | Чтение из Neo4j ограничено `NEO4J_READ_TRANSACTION_TIMEOUT_S` (новая переменная, 30 с): брошенный после таймаута инструмента запрос прерывается сервером Neo4j и не держит соединение. Переподключение к Neo4j выполняется под блокировкой и один раз на сбой, по типу ошибки (`ServiceUnavailable`/`SessionExpired`), а не по тексту. Префикс категории в `object_name`/`register_name` (`Справочник.X`, `Catalog.X`, `РегистрНакопления.X`) у `find_objects_using_object`, `find_usages_of_object`, `find_register_movement_docs` и `trace_impact` фильтрует по категории — одноимённые объекты разных категорий больше не смешиваются. `find_by_guid` ищет по индексам GUID вместо сканирования всех узлов и не выводит эмбеддинги. `find_usages_of_object` и `find_objects_using_object` пагинируются только контрактными `max_items`/`cursor` (чтение ограничено 25 × `GRAPH_MAX_ITEMS`, обрезка — в `warnings`); `limit`/`offset` у `find_usages_of_object` приняты, но не применяются и помечены в `deprecated`. `compare_graph_scope(extension_ref)` в режиме каталога больше не упирается в таймаут: связи базы читаются по узлам пар, а не сканированием метки на каждый ключ (40 с → \~4 с на 197 тыс. процедур). Новые связи BSL-кода (запись движений, `READS_TABLE`, вызовы глобальных модулей, динамические вызовы, `EXECUTES` регламентных заданий, `read_status = protected`) — см. [страницу сервера](/mcp-servery-1c/servery/graph-metadata-search.md), раздел «Связи BSL-кода»; при первом старте лейны `bsl_call_graph` (3 → 4) и `bsl_register_access` (1 → 2) один раз пересобираются на месте, узлы и эмбеддинги не трогаются, переиндексация не нужна. | | 22.09.2026 | `df01dc527859` (latest `053f042e8d0e`, arm64 `08812242f2ce`) | Чтение во время публикации поколения (`refresh_graph_project(mode=full)`, промоушен под координатором): публикация идёт пачками, и раньше чтение в этом окне могло вернуть пустой или частичный проект как достоверный; теперь публикация объявляет о себе, чтение ждёт её окончания (`GRAPH_GENERATION_FENCE_WAIT_S`, 120 с) или отвечает `generation_fence_exhausted`; брошенная публикация старше `GRAPH_GENERATION_FENCE_STALE_S` (900 с) читается как есть. Проект, у которого вручную удалили строки трекера индексации, снова берёт лизу (раньше — «Another ingestion writer keeps taking the lease» на каждом старте). Переиндексация не нужна. | | 21.09.2026 | `fda12ebf500b` (latest `79fbff279338`, arm64 `99c800b0d4e1`) | Режим каталога расширений: лейн эмбеддингов процедур стартует после загрузки слоёв и добирает появившееся за время работы; маркеры resume графа вызовов — на слой (первый рестарт после холодного прогона больше не перестраивает граф вызовов базы; если маркер на момент обновления хранит штамп слоя — перестроится один раз); ремонт старого ключа объектов не срабатывает на одноимённых объектах двух слоёв; `find_form_links` отдаёт обработчики команд и ищет обработчики событий только в модуле своей формы (`FORM_XML_IDENTITY_VERSION=5`, формы перечитываются один раз на первом старте); прогон каталога читает права ролей слоя; `compare_graph_scope(extension_ref=…)` сравнивает слой с базой того же проекта без `EXTENSION_BASE_PROJECT`. Граф следует за выгрузкой без перезапуска: `GRAPH_REFRESH_INTERVAL_SEC` (3600; `0` выключает) / `GRAPH_REFRESH_APPLY`; статус в `get_indexing_status().source_refresh`. | | 19.09.2026 | `ba1a7ac29ac6` (latest `dfe3cad3e79b`, arm64 `db13733704ac`) | `build_ordinary_form` пишет записи `Form.bin` открытым текстом (тот же кодек, что в Code). Граф не затронут. | | 18.09.2026 (вечер) | `3b0894511039` (latest `d93d25c8e85e`, arm64 `c2345fcf2598`) | При `GRAPH_SCOPE_ENFORCED=true` создаются индексы `(mcp_namespace, project_id)` на каждую метку проекта — чтения, ограниченные только scope (в том числе `compare_graph_scope`), перестают сканировать всю базу; команда управляемой формы ключуется формой и её владельцем (`FORM_XML_IDENTITY_VERSION=4`, формы перечитываются один раз); настройки загружаемого слоя каталога — окно потока каталога, лейн форм базы читает базовую выгрузку. | | 18.09.2026 | `d1fb1a9b2b65` (latest `6c0a6d04993e`, arm64 `8a853f60c7a5`) | Связи `EXTENDS`/`OVERRIDES` строятся до удаления рёбер прошлого прогона — пересоздание контейнера не оставляет граф без связей слоя; каждая транзакция записи ограничена `NEO4J_WRITE_TRANSACTION_TIMEOUT_S` (1800 с), затянувшаяся запись видна в журнале (`NEO4J_WRITE_STALL_WARNING_S`). | | 17.09.2026 (вечер) | `4eadac271dce` (latest `125f4a15a8e7`, arm64 `0c2f188f4fc0`) | `list_graph_projects` показывает тот же `ingestion_state`, что и `get_graph_project_status` (`running`/`idle`/`failed` живого загрузчика; `idle` вместо `never_run` при известном поколении). | | 17.09.2026 | `84e7006c2570` (latest `cff3fdfdbd42`, arm64 `098c3cf0b2c3`) | `compare_graph_scope(extension_ref=…)` находит базу по данным в Neo4j, а не только по реестру процесса, и читает с базовой стороны только объекты, связанные с расширением рёбрами `EXTENDS`/`OVERRIDES`. Бизнес-описания строятся и для объектов, у которых в выгрузке нет собственной папки (один `<Имя>.xml`). | | 16.09.2026 (вечер) | `3a0d876e4bb1` (latest `51a04a029ede`, arm64 `762ac706af21`) | Структура управляемых форм ключуется конфигурацией-владельцем: реквизиты, команды и события форм снова создаются в scoped-режиме; формы перечитываются один раз. | | 16.09.2026 | `4eb8a89ec158` (latest `97d4f0591426`, arm64 `c751a06b9708`) | `generate_business_info` начинает работу за секунды, а не часы (формат выгрузки определяется один раз за прогон) и не блокирует `vector_indexing`; временные ошибки провайдера эмбеддингов повторяются с нарастающей паузой; ход перечисления виден в журнале. | | 11.09.2026 | `7c77133e7267` (latest `83116c57d1da`, arm64 `5fd04281f267`) | Одновременный `CREATE CONSTRAINT IngestionLease` базы и расширения на пустой Neo4j: транзиентный `DeadlockDetected` повторяется с той же паузой, что и остальные записи, а не роняет первичную индексацию. | | 09.09.2026 | `49eff4b0b762` (latest `db3eaebcc726`, arm64 `01a7fd10302d`) | Объекты базы и расширений с одинаковым именем (`Report.txt`) больше не сливаются в один узел: ключ объектов и их детей включает `config_name`. | | 09.09.2026 | `b04395335d41` (latest `174be4b87723`, arm64 `2a1e9c08772a`) | `CALCULATE_BUSINESS_INFO` работает на выгрузках 1C:EDT (пути Designer XML больше не обязательны). | ## SyntaxCheckServer (`comol/1c_syntaxcheck_mcp`) | Дата | latest-beta | Что изменилось | | ----------------- | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 20.10.2026 | `4ceb43ffbf03` (arm64 `d063cff04343`) | Теги `latest` и `arm64`, версия 1.1.22-20261020. Лимит одновременных сессий (`MCP_SESSION_MAX_CONCURRENT`, по умолчанию 64) больше не заполняется запросами, которые сессию не открыли. Раньше любой запрос к `/mcp` без заголовка `Mcp-Session-Id` (`GET`, уведомление, `DELETE`, вызов до `initialize`) получал отказ `400`/`406`, но занимал место на весь срок простоя (1800 с), и при 64 таких местах новые клиенты получали `503`, а запросы без заголовка считались в `cap_refused`. Теперь место занимает только сессия, открытая успешным `initialize`; сессия, закрытая клиентом через `DELETE`, освобождает место сразу, а `initialize` при заполненном лимите сначала освобождает сессии, уже вышедшие за срок простоя или срок жизни. Действующие сессии ради новых по-прежнему не закрываются. Healthcheck мест не занимал и не занимает. Значения по умолчанию прежние; как клиенту переиспользовать и закрывать сессию и когда менять лимиты — [Границы Streamable HTTP-сессий](https://docs.onerpa.ru/mcp-servery-1c/pages/Yq5pUjiRhJbZcpTFBxlW#границы-streamable-http-сессий). Индекс открывается как есть, переиндексация не нужна | | 17.10.2026 | `5141561815c3` (arm64 `02328d8dc45b`) | Теги `latest` и `arm64`, версия 1.1.21-20261017. Основная конфигурация и её расширения индексируются вместе в режиме `FULLINDEX`, если лежат под `FILES_DIR` как `src/cf/` + `src/cfe/<Имя>/` (или `cf/` + `cfe/<Имя>/`) либо перечислены в `bsl-analyzer.toml` в корне `FILES_DIR` (`[source] root`, `extensions`): файлы расширения проверяются в контексте основной конфигурации. `syntaxcheck_file` отдаёт из индекса проверки перехватчиков `WeavingAnnotationNotApplicable` и `WeavingSignatureMismatch`. Новое поле `provenance.cross_module_checks` (`ran`, `not_in_index`, `not_run`) говорит, ответил ли индекс по файлу: раньше файл вне индекса и неответивший индекс выглядели как `provenance.index: ready` без межмодульных находок. Аргументы индексного процесса не менялись, готовый индекс открывается как есть, переиндексация не нужна. [Конфигурация и её расширения](https://docs.onerpa.ru/mcp-servery-1c/pages/Yq5pUjiRhJbZcpTFBxlW#конфигурация-и-её-расширения) | | 14.10.2026 | `49c6a14144bd` (arm64 `7aab5d337f66`) | Теги `latest` и `arm64`, версия 1.1.20-20261014. Простаивающий контейнер нагружает процессор заметно меньше. Готовый индекс в режиме `FULLINDEX` переспрашивается раз в шесть часов вместо раза в час: `FULLINDEX_REINDEX_INTERVAL_SEC` по умолчанию `21600`, каждый опрос стоил анализатору около 11 с процессорного времени на конфигурации 1.7 ГБ. Прежний ритм: `-e FULLINDEX_REINDEX_INTERVAL_SEC=3600`. Healthcheck образа больше не запускает Python и не импортирует сервер (около 12 мс на проверку вместо 200 мс) и выполняется раз в минуту вместо раза в 30 с; при старте проверка идёт каждые 2 с, так что `healthy` появляется через несколько секунд (Docker Engine 25 и новее; более старый движок игнорирует стартовый интервал, и `healthy` появляется после первой проверки через 60 с). Индекс открывается как есть, переиндексация не нужна | | 13.10.2026 | `5dea3ba11bfd` (arm64 `98cd8e781ff3`) | Теги `latest` и `arm64`, версия 1.1.19-20261013. Запрос с `Mcp-Session-Id` закрытой сессии (простой, время жизни, перезапуск контейнера) получает `404` с обычным телом `Session not found`, как у остальных серверов; раньше к нему добавлялась диагностика `unknown_path` «Nothing is bound at '/mcp'», хотя адрес верный. Клиенту нужно заново выполнить `initialize`, см. [Сессии MCP и ответ 404](https://docs.onerpa.ru/mcp-servery-1c/pages/chxsFEmf5ukyw3on78yX#сессии-mcp-и-ответ-404-на-долгой-работе). Переменные сессий описаны в README образа; значения по умолчанию прежние. Индекс открывается как есть | | 06.10.2026 | `4e0f25d66721` (arm64 `70ace1ffc52e`) | Теги `latest` и `arm64`, версия 1.1.18-20261006. `syntaxcheck` и `syntaxcheck_file` принимают необязательный `min_severity` (`Error` — только ошибки, `Warning` — ещё `Major` и `Warning`): в ответе остаются диагностики не ниже порога, а `summary.by_severity` и событие `severity_filter` считают по важности всё найденное. Без параметра ответ прежний. Если каталог индекса недоступен для записи (каталог хоста или том с `nocopy` с владельцем root), запись о старте называет владельца, права и пользователя сервера (uid 1000) — каталог нужно отдать `chown 1000:1000`, см. [Хранение индекса](https://docs.onerpa.ru/mcp-servery-1c/pages/Yq5pUjiRhJbZcpTFBxlW#хранение-индекса). Индекс открывается как есть, переиндексация не нужна | | 04.10.2026 | `ad03a31a4307` (arm64 `9df0fe5c3d99`) | Теги `latest` и `arm64`, версия 1.1.17-20261004. Поведение не изменилось: код проверки синтаксиса и ключ те же, переиндексация не нужна. Новая схема сборки: базовые образы закреплены по digest, слои идут от зависимостей к анализатору и приложению, файлы в `/app` принадлежат `mcpuser` с момента копирования (владельцы и права те же, что раньше). Следующее обновление кода скачивает только слои приложения — раньше каждый выпуск заново приносил слой зависимостей и слой `/app` около 90 МБ. В `arm64` трансляция Cython идёт без эмуляции, модуль скомпилирован с `-O1 -g0` вместо `-O3` | | 27.09.2026 (утро) | `5460f567e29a` (arm64 `baa7dbc3c407`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_SYNTAX_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна. Версия 1.1.16-beta.20260927 | | 25.09.2026 | `a109f82dae79` (arm64 `81be2b17d168`) | Проверка имён платформы. Раньше без индекса конфигурации проходили без замечаний `Массив.ДобавитьЭлемент()`, `Структура.Ключи()`, `ВидДвиженияНакопления.Поступление` и `Новый НесуществующийТип`. Теперь сервер читает модель платформы у своего же анализатора (в фоне при старте, около 10 с; под эмуляцией arm64 — до 2 мин) и сообщает `UnknownPlatformMethod`, `UnknownPlatformProperty`, `UnknownSystemEnumValue` и `UnknownPlatformType` (`Critical`). Для `syntaxcheck` добавлен ещё `PlatformApiUnavailableOnClient` (`Major`): серверный тип или функция в методе `&НаКлиенте`. Готовность модели показывает `provenance.platform_names`. Вызовы без объекта (`КонецТранзакции()`) не проверяются. Размер ответа `syntaxcheck` / `syntaxcheck_file` ограничен `RESPONSE_MAX_CHARS` (по умолчанию 32768 байт, `0` снимает предел). Если находки не помещаются, остаются самые серьёзные, а `summary.truncated` равен `true`. Индекс открывается как есть. | | 22.09.2026 | `286625bee89b` (arm64 `a8fd3aabe478`) | `syntaxcheck_file` в режиме FULLINDEX ждёт индекс не дольше 20 секунд: при зависшем построении графа (например, выгрузка на bind-mount с диска Windows) проверка отвечает без межмодульных находок вместо ожидания до отмены клиентом. Состояния индекса `failed`/`disabled` больше не считаются готовым индексом. Самообновление анализатора сверяет загрузку с размером и SHA-256 релиза и переустанавливает повреждённый бинарник. | ## HelpSearchServer (`comol/1c_help_mcp`) | Дата | light-beta | Что изменилось | | -------------------------- | ------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 21.10.2026 | `43a78420fb9f` (тег `light`; latest `399265f4193c`, arm64 `cdbdd709dd46`) | Переиндексации нет: корпус и индекс те же, что у выпуска 14.10.2026. Эмбеддинг поискового запроса, пришедший от провайдера уже после ответа `unavailable` по дедлайну вызова (30 с), больше не выбрасывается: сервер хранит эмбеддинги последних 256 запросов в памяти, и повтор того же запроса отвечает без нового обращения к провайдеру; одинаковые запросы, пришедшие одновременно, ждут одного обращения. Повтор запроса к провайдеру после `429` или `500`/`502`/`503` для поискового запроса не делается, если не успевает начаться до дедлайна вызова, — брошенный вызов не оплачивается и не занимает место чтения индекса; индексация повторяет как раньше. Текст `message` ответа `unavailable` называет причину: провайдер эмбеддингов не ответил вовремя, нет свободного места для чтения индекса, чтение индекса не уложилось в срок, индекс перестраивается или не открылся; `error.type` и форма ответа прежние (см. [страницу сервера](/mcp-servery-1c/servery/help-search-server.md)). Ключ и настройки прежние | | 14.10.2026 | `2bfa68d71491` (тег `light`; latest `842be0cc318a`, arm64 `d48679200219`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ — ПОЛНАЯ ПЕРЕИНДЕКСАЦИЯ СПРАВКИ ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ** (около 45,7 тыс. фрагментов — столько же запросов к API эмбеддингов, сколько при первой установке): изменились тексты встроенных стандартов, а индекс перестраивается целиком при любой правке встроенного документа. Поиск всё это время отвечает по прежнему индексу, новые тексты стандартов выдаются после её завершения. Стандарты `logging-strategy`, `locks-and-transactions`, `dcs-design`, `dev-standards-architecture`, `systematic-debugging` (`standards`): `ЗаписьЖурналаРегистрации` в примерах получала структуру шестым параметром (это `РежимТранзакции`), а `logging-strategy` требовал структуру в параметре `Данные`, который принимает только ссылку или примитивное значение. Теперь в `Данные` — ссылка, контекст события — в `Комментарий` строками `Имя=значение`, `РежимТранзакции` по умолчанию. Запрет `ЗаписьЖурналаРегистрации` без явной задачи (`dev-standards-code-style`) и шаблон транзакции больше не расходятся: обязательны `ОтменитьТранзакцию()` и `ВызватьИсключение`, запись в журнал добавляется, только когда задача просит логирование. Заголовки разделов не менялись, набор правил обновлять не нужно. Поведение сервера и ключ не менялись | | 10.10.2026 | `0d8d37108d05` (тег `light`; latest `5726d62cda8b`, arm64 `3e2cb04f000d`) | Новая переменная `EMBEDDING_API_BASE_NO_V1`: при значении `1`, `true` или `yes` адрес из `EMBEDDING_API_BASE` (или устаревшего `OPENAI_API_BASE`) уходит в API эмбеддингов как написан, без автодобавления `/v1` — для корпоративных шлюзов, отдающих OpenAI-совместимый API без этого суффикса. Без переменной поведение прежнее. Корпус справки и индекс не менялись: с выпуска 08.10.2026 переиндексация не нужна (с более ранних — см. строку 08.10.2026). | | 08.10.2026 | `e56c2815640a` (тег `light`; latest `0a3ece50a186`, arm64 `532e727f6aa7`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ — ПОЛНАЯ ПЕРЕИНДЕКСАЦИЯ СПРАВКИ ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ** (около 45,7 тыс. фрагментов): изменился встроенный корпус спецификаций форматов, а версия корпуса меняется при любой правке документа. Поиск всё это время отвечает по прежнему индексу. Спецификации `1c-erf-spec` и `1c-epf-spec` (`formatspec`): внешний отчёт и внешняя обработка могут ссылаться на общие формы конфигурации — `DefaultForm`, `DefaultSettingsForm`, `DefaultVariantForm` = `CommonForm.<Имя>` (для отчётов на БСП — `CommonForm.ФормаОтчета`, `ФормаНастроекОтчета`, `ФормаВариантаОтчета`); ссылка хранится по имени, поэтому собирать такой отчёт нужно в базе, где эти общие формы есть. Раньше спецификация утверждала, что у внешнего отчёта формы только собственные. Код сервера и ключ не менялись | | 03.10.2026 (вечер) | `ded4afbbf8bc` (тег `light`; latest `32c02fb4660a`, arm64 `276409080536`) | `/ready` отвечает `200` и `ready`, пока запросы обслуживает полное поколение индекса, — в том числе во время пересборки и после её сбоя; что делает пересборка (`indexing` с прогрессом или `degraded` с причиной), показывает поле `rebuild`. Healthcheck больше не помечает такой контейнер `unhealthy`; `503` остаётся, когда отвечать нечем или поколение потеряло документы. При обновлении с образов 26–27.09 индекс справки больше не перестраивается из-за переводов строк. Образы собраны по новой схеме: слои базы, зависимостей, модели и корпуса лежат ниже приложения, поэтому со следующего выпуска при обновлении скачивается только слой приложения (около 3 МБ); в этом выпуске слой зависимостей скачивается один раз заново. Скомпилированные модули amd64 собираются как раньше, arm64 — с `-O1`. Ключ тот же, переиндексация не нужна | | 03.10.2026 | `eb4ad257e61c` (тег `light`; latest `7736a78a2d74`, arm64 `36f5e241ee67`) | **ВНИМАНИЕ: ПРИ ОБНОВЛЕНИИ С ОБРАЗА ОТ 27.09 (ИЛИ 26.09) — ПОЛНАЯ ПЕРЕИНДЕКСАЦИЯ СПРАВКИ ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ** (та же причина, что в выпуске 30.09; с 30.09 переиндексации нет). Число запросов к API эмбеддингов настраивается: `EMBEDDING_MAX_ATTEMPTS` — попытки одного запроса (по умолчанию 6), `BATCH_MAX_RETRIES` — попытки пакета индексации (по умолчанию 5). Клиент OpenAI больше не повторяет запросы сам, поэтому пакет отправляет к провайдеру не больше их произведения (раньше — до 90 запросов без настройки). Для провайдера с оплатой за запрос уменьшите оба значения, например `EMBEDDING_MAX_ATTEMPTS=1` и `BATCH_MAX_RETRIES=2`. Индекс не перестраивается. | | 30.09.2026 | `61e91cbf69fa` (тег `light`; latest `ef91b98eadf6`, arm64 `17bd8c2f5b38`) | **ВНИМАНИЕ: ПРИ ОБНОВЛЕНИИ С ОБРАЗА ОТ 27.09 (ИЛИ 26.09) — ПОЛНАЯ ПЕРЕИНДЕКСАЦИЯ СПРАВКИ ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ** (около 25 тыс. документов): встроенные материалы в тех образах были собраны с переводами строк CRLF, и сервер принимал их за другой корпус. Поиск всё это время отвечает по прежнему индексу. Если плагин в `on_request` изменил `query` у `docsearch`, в эмбеддинг уходит ровно текст хука: сервер больше не вырезает из него пунктуацию, поэтому префикс модели сохраняет двоеточие и `\|`; `on_query` получает этот текст в `normalized`. Хук получает запрос таким, каким его прислал клиент; запрос, который хук не менял, обрабатывается как раньше. Если том смонтирован в старый путь `/app/chroma_db`, а `/app/index` не смонтирован (установка по инструкции до 27.09.2026), сервер пишет при старте WARNING: индекс в этом случае строится внутри контейнера и пропадает при его пересоздании; монтируйте каталог индекса в `/app/index`. `start-docker.sh` монтирует том в `/app/index`. Переиндексация не нужна | | 28.09.2026 | `539806da281a` (тег `light`; latest `e6463013d8a3`, arm64 `ce5d93465805`) | Из меток образа убрана `org.opencontainers.image.version=beta`, описание образа больше не называет его beta-сборкой. Код сервера не менялся. Ключ тот же, что у выпуска 27.09.2026, переиндексация не нужна | | 27.09.2026 (утро) | `84293ac3a409` (latest `f9dda49f0199`, arm64 `deb0555c4f83`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_HELP_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна | | 27.09.2026 (ночь) | `75112442f3b0` (latest `061f73d355d6`, arm64 `b7f26b328fcd`) | Если `EMBEDDING_API_BASE` задан, а API не отвечает при старте, сервер не переходит на встроенную модель, а ждёт API (5 с, удваивая до 60 с); ошибки 400/401/403/404 переводят его в `degraded`, индекс не трогается. Переход разрешает `EMBEDDING_ALLOW_OFFLINE_FALLBACK=true`; без заданного API поведение прежнее. `/ready` показывает активный бэкенд, модель и размерность (поле `embedding`). Переиндексация не нужна | | 26.09.2026 | `292fdff0624a` (latest `c051979b4973`, arm64 `b51e4c0b8d71`) | Описания инструментов в `tools/list` короче (около 2,5 → 1,9 тыс. токенов): у параметров, которые полностью описаны в схеме, убран дубль в тексте описания, сокращены пояснения к сериализации ответа; правило склейки сниппетов, семантика `outcome`, курсора, `fallback`, `since`/`availability` и выбор между инструментами сохранены. Схемы, имена инструментов и параметров не изменились; переиндексация не нужна. | | 25.09.2026 (поздний вечер) | `5b1c11fbee26` (latest `d89f20b0cec5`, arm64 `4984a7e67cbf`) | В корпус синтакс-помощника вошёл раздел таблиц языка запросов (`tables/` архива), который отсекал фильтр путей: терялась 721 страница из 725. 59 таблиц (`Остатки`, `Обороты`, `ОстаткиИОбороты`, `СрезПервых`, `СрезПоследних`, `ДвиженияССубконто`, таблицы `Изменения` и др.) индексируются по одному документу с разделами «Поля» и «Параметры»: `docsearch("РегистрНакопления Остатки")` находит страницу таблицы. Цитата страницы синтакс-помощника несёт `since` (версия из «Использование в версии») и `availability` (окружения из «Доступность») в `compact` и `detailed`; контракт ответа `schema_version: "4.1"`, ключи только добавлены. `docinfo` с неоднозначным именем в режиме `compact` больше не падает с внутренней ошибкой. В стандартах `anti-patterns`, `registers-design`, `async-methods` дополнены разделы о параметре условия виртуальной таблицы, виртуальных таблицах по видам регистров и условном требовании асинхронных файловых вызовов. **Первый старт на существующем индексе один раз полностью переиндексирует справку** в staging-поколении; до конца сборки отвечает прежнее поколение. | | 24.09.2026 | `17df95a1d6af` (latest `09dcd79ce4e6`, arm64 `fe63b129d853`) | Запрос к модели Qwen3-Embedding идёт с инструкцией задачи, сформулированной под справку 1С (см. [Инструкция к запросу у Qwen3](https://docs.onerpa.ru/mcp-servery-1c/pages/zZx7MZNnC5Ejse6V9TZC#инструкция-к-запросу-у-qwen3)); у других моделей запрос не меняется. Из таблицы моделей убраны префиксы, которые сервер и раньше не применял, а только печатал в журнал при старте. Индекс не меняется, переиндексация не нужна. | | 23.09.2026 (вечер) | `a976aff97dab` (latest `2fc57143e24e`, arm64 `dfb92b7e182d`) | Новая переменная `EMBEDDING_API_TIMEOUT` — сколько секунд один запрос к embedding API ждёт ответа (по умолчанию `600`, как раньше). Раньше предел был зашит в клиенте OpenAI, и модель на CPU, которая считает `INDEXING_WORKERS` батчей по очереди, не укладывалась в него: батч падал после трёх попыток по 600 с. Индекс не меняется, переиндексация не нужна; кто обновляется со сборки раньше 23.09 (утро), получит однократную переиндексацию из строки ниже. | | 23.09.2026 | `77bf1efeb754` (latest `84d71392304c`, arm64 `ba16e68df231`) | В корпус синтакс-помощника вернулись около 626 страниц, которые отсекал фильтр служебных файлов архива (ОписаниеТипов, ЦветаСтиля, ШрифтыСтиля, WebЦвета.Серебряный, МенеджерПолученияЛицензии и др.): 23 897 → 24 523 страниц. **При первом старте на существующем индексе справка один раз полностью переиндексируется** в staging-поколении; до конца сборки отвечает прежнее поколение. Если embedding-модель не загрузилась (нет доступного API в light, нет модели в `HF_HOME`), сборка индекса завершается штатным отказом — `/ready` отвечает `degraded` с причиной в `failure` — вместо бесконечного `starting`; контейнер при этом не останавливается. | ## SSLSearchServer (`comol/mcp_ssl_server`) | Дата | light-beta | Что изменилось | | ----------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 14.10.2026 | `83ac0385f67c` (тег `light`; latest `b471f183c2dd`, arm64 `255ff66210df`) | Если после сборки в индексе нет ни одного документа (например, провайдер эмбеддингов отклонил все пакеты и они ушли в карантин), сервер больше не объявляет готовность: процесс завершается с сообщением `FATAL: The index of … holds no documents after the build`, манифест индекса не пишется, следующий старт повторяет записи из карантина. Раньше `/ready` в этом случае отвечал 200. При частичном карантине сервер работает без недостающих записей, пишет предупреждение, а `/ready` отвечает `{"state": "ready", "quarantined": N}`. `ssl_search` возвращает как ошибку инструмента (`isError: true`, текст прежний) поиск, не уложившийся в `EMBEDDING_SEARCH_DEADLINE`, отменённый поиск и сбои с кодом и Reference; `not_found` остаётся обычным ответом. Для внешнего API через агрегатор рекомендуемое значение `EMBEDDING_SEARCH_DEADLINE` — 30 секунд. Индекс при обновлении не перестраивается. | | 10.10.2026 | `546b16752988` (тег `light`; latest `870fb58f9d6c`, arm64 `9dd929a1fb31`) | Новая переменная `EMBEDDING_API_BASE_NO_V1`: при значении `1`, `true` или `yes` адрес из `EMBEDDING_API_BASE` (или устаревшего `OPENAI_API_BASE`) уходит в API эмбеддингов как написан, без автодобавления `/v1` — для корпоративных шлюзов, отдающих OpenAI-совместимый API без этого суффикса. Без переменной поведение прежнее. Индекс не менялся, переиндексация не нужна. | | 03.10.2026 | `c3b7571d7eca` (тег `light`; latest `8ae884e3e161`, arm64 `9d5296c3b524`) | Поведение не изменилось: тот же код, что в выпуске ниже, собран заново по новой схеме сборки. Скомпилированный модуль, файлы сервера и поставляемые базы в `light` побайтно те же, что в выпуске ниже. Переиндексация не нужна. Образы теперь меняются слоями: при обновлении на следующие выпуски скачиваются только слои приложения, а не зависимости | | 02.10.2026 | `b404e9873020` (тег `light`; latest `d137c5a325d7`, arm64 `176232acf9bd`) | Число попыток одного пакета индексации задаётся переменной `EMBEDDING_BATCH_MAX_ATTEMPTS` (1–10, по умолчанию 5 — как раньше): пакет отправляет к провайдеру эмбеддингов не больше `EMBEDDING_BATCH_MAX_ATTEMPTS` × `EMBEDDING_MAX_ATTEMPTS` запросов и укладывается в `EMBEDDING_BATCH_DEADLINE`. Чтобы на пакет уходил один оплачиваемый запрос, задайте обе переменные равными `1`. Индекс не перестраивается. | | 01.10.2026 | `f4987079a92c` (тег `light`; latest `aeec5dc75234`, arm64 `27bcbe59ba2d`) | **ВНИМАНИЕ: ПРИ ПЕРВОМ СТАРТЕ — ПОЛНАЯ ПЕРЕИНДЕКСАЦИЯ SSL ЧЕРЕЗ ПРОВАЙДЕРА ЭМБЕДДИНГОВ; НА ВРЕМЯ ПЕРЕСТРОЕНИЯ ПОИСК НЕДОСТУПЕН** (2 596 записей БСП — около минуты с внешним API). Точный поиск по имени метода (`lane=exact`) работает на поставляемых базах БСП: каноническое имя (`ОбщегоНазначения.ЗначениеРеквизитаОбъекта`) читается из строки объявления под заголовком-путём записи — раньше правило не извлекало ни одного имени из реальных записей, и запросы по имени уходили в гибридный поиск. Имя метода без модуля находит его в любом модуле; если модулей несколько — ответ `ambiguous_name` со списком кандидатов. Карточка точного поиска называет раздел библиотеки вместо `unknown`. При первом запуске индекс один раз перестраивается автоматически (сменился отпечаток правила извлечения); на время перестроения поиск недоступен. | | 30.09.2026 | `5d28b48c167c` (тег `light`; latest `2411fc503652`, arm64 `1fc64f7dadc5`) | Если плагин в `on_request` изменил `query` у `ssl_search`, в эмбеддинг уходит ровно текст хука: сервер больше не нормализует его, поэтому префикс модели сохраняет двоеточие и `\|` (`QUERY_ALIASES` применяются по-прежнему). Хук получает запрос таким, каким его прислал клиент; запрос, который хук не менял, обрабатывается как раньше. Переиндексация не нужна | | 27.09.2026 (утро) | `9af69d45adca` (latest `6c1e6d147f67`, arm64 `3ab4ed7c18f4`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_SSL_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна | | 27.09.2026 (ночь) | `4bb75944594b` (latest `d886a93875c0`, arm64 `438b8ac4970d`) | Полные варианты (`latest`, `arm64`) при заданном `EMBEDDING_API_BASE` больше не переходят на локальную модель, если API не отвечает на старте, а ждут его (5 с, удваивая до 60 с), как облегчённый; при 401/403/404 старт завершается. `EMBEDDING_ALLOW_OFFLINE_FALLBACK=true` разрешает переход, но коллекцию, построенную через API, он не удаляет и не пересобирает — даже при `FORCE_REINDEX_ON_DIMENSION_MISMATCH=true`. Инструмент `embedding_state` показывает активную модель, размерность и произошёл ли переход (блок `active`). Переиндексация не нужна | | 26.09.2026 | `c6658f07cff0` (latest `08bf8bc265c7`, arm64 `98c1e65d4af0`) | Облегчённый вариант больше не завершается, если провайдер эмбеддингов временно недоступен при старте (сеть или DNS, ответ 5xx, 429): он повторяет проверку с паузой от 5 до 60 секунд, пока слушатель отвечает `startup`, а остановка во время ожидания завершает процесс с кодом 0. Отказ, который ожиданием не исправить (401/403, неизвестная модель), по-прежнему останавливает старт с трассировкой. Раньше 13-минутный сбой DNS давал 57 перезапусков контейнера подряд. Переиндексация не нужна. | | 24.09.2026 | `2dbfa8e8a1d1` (latest `6edd8aa0ed82`, arm64 `6a2777ea0a2d`) | Текст эмбеддится без префиксов: локальная модель больше не получает `query:` /`passage:` (e5), `search_query:` /`search_document:` (nomic), инструкции bge/mxbai и встроенные prompts модели. Запрос к Qwen3-Embedding идёт с инструкцией задачи под БСП (см. [Инструкция к запросу у Qwen3](https://docs.onerpa.ru/mcp-servery-1c/pages/zZx7MZNnC5Ejse6V9TZC#инструкция-к-запросу-у-qwen3)); `EMBEDDING_INPUT_TYPE_ENABLED=false` её выключает. **Коллекция, построенная локальной моделью e5** (модель полного образа по умолчанию), **nomic или моделью со встроенным prompt документа, при первом старте один раз пересобирается.** Коллекции API-режима и остальных моделей не пересчитываются. | ## TemplatesSearchServer (`comol/template-search-mcp`) | Дата | light-beta | Что изменилось | | ------------------ | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 10.10.2026 | `8699da805616` (тег `light`; latest `89cc4e65e7dc`, arm64 `2cdf6ecd014b`) | Новая переменная `EMBEDDING_API_BASE_NO_V1`: при значении `1`, `true` или `yes` адрес из `EMBEDDING_API_BASE` (или устаревшего `OPENAI_API_BASE`) уходит в API эмбеддингов как написан, без автодобавления `/v1` — для корпоративных шлюзов, отдающих OpenAI-совместимый API без этого суффикса. Без переменной поведение прежнее. Индекс не менялся, переиндексация не нужна. | | 04.10.2026 | `ccf8e82cc61a` (тег `light`; latest `0b422a9b9d68`, arm64 `3e3494a092c3`) | Код сервера не менялся. Образ `arm64` ставит PyTorch из CPU-индекса PyTorch (`torch 2.14.1+cpu`) вместо пакета PyPI с колёсами CUDA и triton, которые на arm64 не используются: сжатый образ `arm64` — 479 МБ вместо 3,49 ГБ. Ни в одном образе больше нет пакета Cython: он нужен только при сборке. Остальные зависимости тех же версий, что в выпуске ниже. Слой зависимостей собран заново, поэтому при обновлении он скачивается целиком: `light` — около 120 МБ, `latest` — около 475 МБ, `arm64` — около 430 МБ. Переиндексация не нужна. | | 03.10.2026 (вечер) | `d3b5b5d60a04` (тег `light`; latest `321405876ec3`, arm64 `744f3f3a05c2`) | Поведение не изменилось: тот же код, что в выпуске ниже, собран заново по новой схеме сборки. Файлы приложения, включая скомпилированные модули, в `latest`, `light` и `arm64` побайтно те же, что в выпуске ниже. Слои базы и зависимостей не изменились, поэтому при обновлении скачивается только слой приложения (около 10 МБ). Переиндексация не нужна | | 03.10.2026 | `c0a97188405a` (тег `light`; latest `0796199aba84`, arm64 `dca74a23c512`) | Число запросов к API эмбеддингов на один вызов задаётся переменной `EMBEDDING_MAX_ATTEMPTS` (по умолчанию `3` — столько же, сколько клиент отправлял и раньше; `1` — без повторов). Раньше повторы задавал SDK, и изменить их было нельзя. Каждая попытка ограничена `EMBEDDING_API_TIMEOUT`. Индекс не перестраивается. | | 28.09.2026 (вечер) | `57d5bd089151` (тег `light`; latest `2b3ff4328fed`, arm64 `ded0fbb342fa`) | Если плагин в `on_request` изменил `query` у `templatesearch` или `recall`, в эмбеддинг уходит ровно текст хука: сервер больше не вырезает из него пунктуацию, поэтому префикс модели сохраняет двоеточие (`QUERY_ALIASES` применяются по-прежнему). Хук получает запрос таким, каким его прислал клиент; запрос, который хук не менял, обрабатывается как раньше. Переиндексация не нужна | | 27.09.2026 (утро) | `fd271b6815c9` (latest `882c8fee3706`, arm64 `a5665d8b9594`) | Сменился лицензионный ключ beta-канала: образ принимает только новый `LICENSE_KEY_TEMPLATES_BETA` из дистрибутива от 27.09.2026, прежний отклоняется (`Invalid LICENSE_KEY`). Код сервера не менялся, переиндексация не нужна | | 27.09.2026 (ночь) | `fbe4dd87cf4d` (latest `0869f7b5fa6c`, arm64 `6f2d436daf39`) | Если `EMBEDDING_API_BASE` задан, а API не отвечает при старте, сервер не переходит на локальную модель: стадия повторяется (5, 15, 30 с), затем процесс завершается с кодом 70 до перезапуска контейнера; индекс не трогается. `EMBEDDING_ALLOW_OFFLINE_FALLBACK=true` разрешает локальную модель, но и тогда она не заменяет непустой индекс, построенный через API. `/ready` показывает признак `fallback`. Переиндексация не нужна | | 24.09.2026 | `f754a0de6eec` (latest `b6e7436ce58e`, arm64 `c4ca2beb29fb`) | `EMBEDDING_QUERY_PREFIX` и `EMBEDDING_PASSAGE_PREFIX` больше не читаются: текст эмбеддится как есть. Запрос к Qwen3-Embedding идёт с инструкцией задачи: для `templatesearch` — под шаблоны кода, для `recall` — под заметки проекта. **Поколение индекса, построенное при заданном префиксе, один раз пересобирается**, прежнее отвечает до его публикации; если префиксы не задавались, индекс не меняется. | ## 1CCodeChecker (`comol/1c-code-checker`) | Дата | light | Что изменилось | | -------------------------- | ------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | 21.10.2026 | `7f081809ff2d` (тег `light`; latest `f8498a392774`, arm64 `432f5a2be8fa`) | Молчание потока 1С.ai. Если поток ответа молчит дольше `ONEC_AI_STREAM_STALL_TIMEOUT` (по умолчанию 120 с), запрос прерывается как транспортный сбой и повторяется на свежей дискуссии в пределах `ONEC_AI_TRANSPORT_RETRIES` и бюджета вызова; в журнале у `upstream_stream` исход `stalled`. `review_1c_code` без законченного ответа (бюджет, молчание без оставшихся попыток, предел раундов) возвращает уже написанный 1С.ai текст под заголовком «ответ 1C.ai не завершён» и остаётся ошибкой с прежним кодом. Раунды инструментов review ограничены `ONEC_AI_REVIEW_TOOL_ROUNDS` (по умолчанию 10): следующий вызов инструмента отклоняется, кроме `TodoWrite` и `TaskResult`, и модель отвечает по уже найденному. Если вызовы продолжаются ещё 5 раундов после лимита, review обрывается. При `ONEC_AI_TRANSPORT_RETRIES=0` прямой вызов, упавший по транспорту, в запасной промпт не уходит. Индекса нет, ключ прежний. См. [Конфигурация](https://docs.onerpa.ru/mcp-servery-1c/pages/3QBF0285guRFq3Hl1Fw4#бюджет-времени-и-прогресс) | | 20.10.2026 | `4121f6121dde` (тег `light`; latest `b43c3829b1e7`, arm64 `10819bbdbac8`) | Журнал вызова. Сервер пишет в журнал контейнера строки уровня `INFO` со временем, и у всех строк одного вызова инструмента одна метка `call=`. Вызов заканчивается строкой `tool_call tool=… <исход> seconds=…`, каждый запрос к 1С.ai — строкой `upstream_stream` с идентификатором дискуссии 1С.ai, временем первого и последнего события ответа и числом событий. Раньше эти строки не выводились, а `review_1c_code` с истёкшим бюджетом не оставлял в журнале ничего. Текст ошибки `operation_timeout` теперь говорит, сколько событий прислал 1С.ai и как давно пришло последнее: так видно, что 1С.ai начал ответ и замолчал. Ответы инструментов в остальном не изменились. Ключ и настройки прежние, индекса у сервера нет. См. [Конфигурация](https://docs.onerpa.ru/mcp-servery-1c/pages/3QBF0285guRFq3Hl1Fw4#журнал-вызова-и-отмена) | | 14.10.2026 | `cecc678e34e2` (тег `light`; latest `0aec56209902`, arm64 `8f6f4f3fe5ee`) | Запись журнала `Direct call condition` пишется уровнем `WARNING` вместо `ERROR`. Её оставляет вызов, который модель 1С.ai повторила с изменёнными аргументами: сервер его не подтверждает, ответ даёт запасной промпт с `fallback_reason`, сервер при этом не сбоит. Для изменённого `code` в записи появилась строка `code_difference`: длины отправленного и полученного кода, место первого расхождения (символ и строка) и его характер — только пробелы и переводы строк, только регистр букв или больше. Сам код в журнал не пишется. Ответы инструментов не изменились. Ключ и настройки прежние, индекса у сервера нет. См. [Конфигурация](https://docs.onerpa.ru/mcp-servery-1c/pages/3QBF0285guRFq3Hl1Fw4#большие-модули-в-direct-режиме) | | 08.10.2026 | `ecb85bc5f9db` (тег `light`; latest `b5e5535833fd`, arm64 `894e53ad7bf9`) | Код длиннее `ONEC_AI_INPUT_MAX_LENGTH` в `check_1c_code` и `review_1c_code` обрезается после последнего целого метода (или целой строки); модели сообщается, что передана часть модуля, а первая строка ответа говорит, какие строки проверены. Если полезного ответа нет (истёк бюджет, сбой транспорта, пустой ответ 1С.ai), результат приходит с `isError: true` и кодом в новом поле `error` (`operation_timeout`, `transport_failure`, `upstream_empty_answer`, `upstream_error`, `no_result`); ответ запасного промпта остаётся успешным с `fallback_reason`. `ONEC_AI_OPERATION_TIMEOUT` ограничивает весь вызов: запасной промпт получает остаток бюджета и не стартует, если остатка мало. При переданном `progressToken` сервер каждые 10 секунд шлёт `notifications/progress`. Ключ и настройки прежние, индекса у сервера нет | | 03.10.2026 (второй выпуск) | `3a19e0c71c36` (тег `light`; latest `217d2cf8dcfe`, arm64 `be001ec73b85`) | Поведение не изменилось: тот же код, что в выпуске ниже, собран заново. Файлы приложения в `latest` и `light`, включая скомпилированные модули, побайтно те же, что в выпуске ниже. `latest` и `light` теперь один и тот же образ (у тегов различаются только аттестации сборки), поэтому второй тег скачивается без новых слоёв. Файлы приложения больше не повторяются отдельным слоем смены владельца: сжатый образ amd64 — 78,3 МБ вместо 81,1. В arm64 модули собраны с `-O1` без отладочной информации (раньше `-O3 -g`): 76,6 МБ вместо 81,5. Ключ и настройки прежние | | 03.10.2026 | `efc051dce0cf` (тег `light`; latest `2be087544a27`, arm64 `7cf880a93aca`) | Если инструмент документации 1С.ai отработал, но не вернул ни одного документа (02.10.2026 так отвечала версия `v8.3.27`, так же отвечает несуществующая версия), `search_1c_documentation`, `onec_help` и `diff_1c_documentation_versions` возвращают `fallback_reason` с `kind: upstream_returned_no_usable_result`. Раньше `fallback_reason` был `null`, хотя текст ответа модель 1С.ai писала без данных документации. Текст по-прежнему возвращается, повторного запроса нет. Успешный поиск и сравнение версий причины не несут. См. [Инструменты](/mcp-servery-1c/servery/code-checker/instrumenty.md) | | 01.10.2026 (поздний вечер) | `eb923d399c95` (тег `light`; latest `3343be817a96`, arm64 `b879875ce022`) | Если при старте список инструментов 1С.ai получить не удалось — сервис был недоступен или отвечал дольше `ONEC_AI_TIMEOUT` (на медленном канале загрузка занимала 31 с при пределе 30), — сервер повторяет попытку в фоне через 30, 60 и 120 секунд, затем каждые 300 секунд, каждая в пределах `ONEC_AI_OPERATION_TIMEOUT`. Раньше возможности оставались `degraded`, а прямые вызовы не работали до перезапуска контейнера; теперь они становятся `available` сами. Стартовая попытка по-прежнему ограничена `ONEC_AI_TIMEOUT`, новых настроек нет. Ключ и настройки прежние | | 01.10.2026 (вечер) | `87a7515bf942` (тег `light`; latest `b5749183ba22`, arm64 `5d8f32a167a0`) | Прямые вызовы (`check_1c_code`, поиск по документации и ИТС, `fetch_its`, `diff_1c_documentation_versions`) реже уходят на промпт-путь: модель upstream чаще всего писала вызов инструмента текстом (`fallback_reason` «Upstream не вернул tool\_calls…»), теперь её просят вызвать инструмент сразу и не писать вызов текстом. `check_1c_code` передаёт анализатору `extended: false`: модель upstream сама добавляла этот необязательный аргумент, и сервер не подтверждал изменённый вызов; с `false` анализатор находит то же, что без аргумента. На живом upstream `check_1c_code` дошёл до анализатора в 16 вызовах из 16 (утренняя сборка — в 10). Плагин в `on_upstream_call` видит в direct-пути только поля вызывающего; `extended` добавляется после хука. Если модель upstream при пересказе исказит код (бывает на длинных фрагментах), вызов по-прежнему не подтверждается и ответ приходит промпт-путём. Ключ и настройки прежние | | 01.10.2026 | `8e53a99b0292` (тег `light`; latest `a055b4171f27`, arm64 `16c205a3e732`) | `check_1c_code` в режиме `direct` доходит до анализатора и для кода с переводами строк Windows (CRLF), с переводом строки в конце или с BOM — например, для кода из `files`. Раньше upstream возвращал вызов анализатора с таким кодом в другом виде (LF, без завершающего перевода строки и BOM), сервер не подтверждал изменённый вызов, и ответ приходил промпт-путём с `fallback_reason` «расходятся: code». Теперь код уходит на проверку уже в этом виде; номера строк и синтаксис не меняются. Если upstream отвечает текстом вместо вызова инструмента, ответ по-прежнему приходит промпт-путём с `fallback_reason`. Ключ тот же, что у выпуска 27.09.2026, настройки не менялись | ## MCP QA (`comol/qa_mcp`) | Дата | latest | Что изменилось | | ---------- | -------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 04.10.2026 | `915fa654ec6c` | Версия 0.7.16. `ui_input`, `ui_set` и `ui_table(action="input_cell")` больше не очищают поле перед вводом: введённый текст заменяет прежний, пустой текст с `clear=True` очищает поле. Раньше поле, не принимающее ввод текста (например, стандартный период в настройках отчёта), после ошибки оставалось пустым. Теперь значение сохраняется, а ответ подсказывает ввод через форму выбора. Действие над скрытой таблицей (свёрнутая панель настроек) отвечает «Таблица … сейчас скрыта», `content` — `hidden: true`. При обрыве связи сервер проверяет порт тест-клиента. Если клиент не отвечает, ответ говорит, что процесс, вероятно, завершился и его нужно перезапустить и вызвать `qa_start`. В ответе и в `qa_command_status` есть причина обрыва (`cause`) и `test_client.listening`. Ответ «already connected to another manager» объясняет, что делать без второго менеджера. Зависимости собраны заново: при обновлении скачиваются слой зависимостей и слой приложения | | 03.10.2026 | `d1299e9d1c01` | Версия 0.7.15. Поведение не изменилось: код тот же, что в 0.7.14, скомпилированные модули побайтно те же, новый только номер версии. Образ собран по новой схеме: зависимости и приложение лежат отдельными слоями. При переходе на 0.7.15 слой зависимостей (около 31 МБ) скачивается ещё один раз, в следующих выпусках при обновлении скачивается только слой приложения (около 3 МБ). Ключ тот же | | 01.10.2026 | `ab7d89d1f2fc` | Версия 0.7.14. Ошибка «Отсутствует подходящий клиент тестирования» (ответ платформы на команду подключения, исключение NO\_APROPRIATE\_CLIENT) теперь сопровождается обеими причинами: тест-клиент ещё не вошёл в базу (окно входа, лицензии или другой стартовый диалог; `/N`, `/P`, `/DisableStartupDialogs`) или не совпал идентификатор клиента (`MCP_QA_TESTCLIENT_ID`, `TestClientID` веб-клиента); текст платформы сохраняется. Ключ, порт 8020 и том `/data` прежние. | | 01.10.2026 | `cc10d8d65b46` | Версия 0.7.13. `qa_start(testclient="хост:порт")` подключает сеанс к указанному тест-клиенту вместо `MCP_QA_TESTCLIENT` (формат тот же, IPv6 в скобках; `port` по-прежнему заменяет порт); без параметра — как раньше. Адрес остаётся за сеансом (`qa_reconnect`), ключ `testclient` допускается в профиле. Только для режима `native`. Сценарий «один удалённый MCP QA — несколько ПК с тест-клиентами» описан на странице сервера; адрес вызывающего компьютера сервер не подставляет сам (за NAT Docker Desktop виден адрес шлюза). Ключ, порт 8020 и том `/data` прежние. | | 01.10.2026 | `48504ef5f34c` | Версия 0.7.12. Тест-клиент под Linux: если на билет вступления клиент отвечает самим билетом, подключение больше не обрывается — сервер продолжает проверку подлинности, клиента, принявшего соединение сразу, берёт без неё; при неудаче ошибка содержит ответ клиента целиком. Повтор по версии не возвращается к уже испробованной сборке. Описано, какой адрес указывать для веб-клиента (`TestClientID`): порт веб-сервера публикации, по умолчанию 1538. | | 01.10.2026 | `6fbec522698f` | Версия 0.7.11 по повторным прогонам ЗУП. Таблица в `lite` — список видимых колонок `columns` вместо узлов (форма начисления зарплаты: 62 → 22 тысячи символов); `command_bar` находит панели внутри групп формы, остальные — в `more_groups`; `ui_click` по заголовку нажимает кнопку, а не одноимённое подменю; `ui_dialog(optional=True)` без нужной кнопки — `clicked: false`. | | 01.10.2026 | `469bc7fef441` | Версия 0.7.10. Тест-клиент на другой машине, Docker Engine на Linux и WSL2 без Docker Desktop: сервер выполняет обмен ключом удалённого менеджера и подключается без моста. Старые платформы (8.3.13): методы новее сборки клиента не вызываются (раньше падал `ui_inspect`), поиск работает, даже если клиент не применяет фильтр. `ui_assert(checked)` проверяет поле-флажок; `end_edit` после `input_cell` без ошибки; `menu_choice` без меню подсказывает `dropdown_select`; снимок `platform` восстанавливает развёрнутое окно 8.5 на время снимка. | | 01.10.2026 | `f4248b7f1dde` | Версия 0.7.9. Версию платформы тест-клиента указывать не нужно: клиент другой сборки (8.3.25, 8.3.27.2214, 8.5) называет её в отказе, и сервер подключается с ней (`platform_version` в `qa_status`); раньше без `platform_version` был отказ «expected a text message». Пустой ответ на вступление (Docker Engine на Linux, WSL2 без Docker Desktop, QA на другом хосте — по сообщению пользователя) теперь виден как «answered the intro with an empty message…». `ui_table`: `select`/`edit`/`delete`/`copy` с `row` переходят к строке, `edit` отвечает реальным `editing`, `select`/`edit` называют открывшуюся форму в `window_after`, чтение строк возвращает курсор и отдаёт `current_row`. `ui_open`: русские имена `kind` и полное имя в `metadata_name`. Описания `qa_start`/`qa_stop`/`qa_status` — про контейнер, `desktop` из статуса убран. По прогонам агентов на ЗУП: `ui_window_tree` по умолчанию `lite`, в `lite` только видимые элементы (форма документа ЗУП была 65–100 тысяч символов), `observe` и `ui_window_changes` без полного дерева; `ui_open` сразу сообщает окно ошибки с текстом и несовпавший `target_title`, подменённая форма — за \~3 с вместо 30; `ui_errors` читает `ErrorWindow`; `ui_dialog(click)` требует кнопку; `select`/`select_row` выбирают на колонке из `row`, колонки из групп колонок видны, поиск сначала в активном окне; `ui_set` сообщает `dropdown_open`, `ui_get_text` — причину вместо `{}`, пустой отчёт — `state`; `command_bar` на формах ЗУП. | | 30.09.2026 | `1593bd60ab0a` | Версия 0.7.7 по разбору сеансов агента. `ui_close_form(on_prompt=…)` считает вопросом о сохранении только окно, появившееся при закрытии: форма, закрывшаяся без вопроса, больше не даёт ошибку «кнопка не нажата»; нажатая кнопка — в `prompt_answered`, `closed` показывает, закрылась ли форма на самом деле, заголовок оставшегося вопроса — в `blocked_by`. `ui_open` открывает основную форму списка сразу навигационной ссылкой, без расширения MCPQAClient; отказ `ОткрытьФорму`, после которого форма открыта по ссылке, не показывается в `client_hook_log_tail`. Если элемент найден не в активном окне, ответ инструмента содержит `found_in` (окно элемента и активное окно). | | 30.09.2026 | `f1ec050f6fe3` | Версия 0.7.6. `qa_status` не ждёт в очереди за работающим инструментом: через 5 с отвечает `busy: true` и называет операцию; `qa_stop` в нативном режиме в этой ситуации сначала закрывает связь, чтобы зависшее ожидание завершилось (`aborted`). Объём одного обхода ограничен: `max_nodes` ≤ 5000, `max_depth` ≤ 20, `max_rows`/`max_table_rows` ≤ 1000, `max_columns` ≤ 200, ячеек ≤ 20000, номер строки ≤ 10000. Исключение RPC тест-клиента («Ошибка формата потока») закрывает связь с ответом «not executed» вместо «клиент не готов». Канал расширения принимает ответ только на выданную по `poll` команду, статус до 64 КБ, строка журнала до 2000 символов, тело до 4 МБ; команда без ответа остаётся барьером до получения исходного ответа. `MCP_QA_COMMAND_TIMEOUT` действует и в нативном режиме, `qa_reconnect` сохраняет версию платформы, некорректный `MCP_QA_TESTCLIENT` отклоняется до остановки сеанса. Строки длиннее 65 535 символов тест-клиент принимает (проверено до миллиона). Образ без `pillow`, `psutil`, исходников 1С и PowerShell-скриптов; `HEALTHCHECK` берёт порт из `MCP_QA_HTTP_PORT`. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.5, `1c3fcf627195`) доступен по тегу `0.7.5` | | 30.09.2026 | `1c3fcf627195` | Версия 0.7.5 по итогам ревью. Таймаут инструмента (`timeout`, `timeout_seconds`; без него `MCP_QA_COMMAND_TIMEOUT`) стал сроком ожидания каждого ответа тест-клиента в операции (не более часа), раньше в нативном режиме он не доходил до соединения; `ui_wait` принимает `timeout` до 900 с. Ошибка в аргументе (число вне диапазона протокола) не закрывает соединение как потерянное; ожидание формы и диалога прекращается сразу после потери связи, а не по истечении таймаута; после `qa_stop` барьер «исход неизвестен» снимается; недействительные `startup_timeout`/`port`/`connect_timeout` отклоняются до остановки текущего сеанса. `qa_doctor` в нативном режиме проверяет порт тест-клиента из `MCP_QA_TESTCLIENT` и подсказывает запуск клиента вместо `qa_setup`; `qa_start` называет проигнорированные `user`, `password`, `client_kind` в `ignored_arguments`; `qa_run_script` и `ui_screenshot` отвечают `executor_capability` сразу; `qa_run_scenario` в нативном режиме не пытается снимать экран. Таймаут рукопожатия и ошибки разбора ответа получили понятные тексты. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.4, `895102794a92`) доступен по тегу `0.7.4` | | 29.09.2026 | `895102794a92` | Версия 0.7.4: `ui_open` по `kind`+`metadata_name` при работающем расширении `MCPQAClient` открывает форму навигационной ссылкой, если `ОткрытьФорму` не знает вычисленного имени формы («Неизвестное имя формы»; ЗУП подменяет список `Справочник.Сотрудники`), текст отказа — в `hook_refused`; прочие отказы и потерянный ответ расширения навигацию по-прежнему не повторяют. Описание нативного режима в `qa_playbook` больше не называет сторонние продукты. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.3, `b7fd15bc3e68`) доступен по тегу `0.7.3` | | 29.09.2026 | `b7fd15bc3e68` | Версия 0.7.3: сервер, как и менеджер 1С, шлёт тест-клиенту сигнал простоя раз в 5 с — тест-клиент 8.3.27 разрывает соединение, молчащее 200 с, и на 0.7.2 связь терялась после паузы дольше трёх минут; потерянную связь `qa_status` показывает полем `link`. Действия, меняющие значение (`ui_input`, `ui_set`, `ui_select`, `ui_field`, `ui_table` с `input_cell`), возвращают `value_before`/`value_after`, `verified` (числа сравниваются как числа), `applied`, новые сообщения формы и открывшееся окно (`window_after`: вопрос, ошибка или форма); отказ дополняется сообщениями формы (`Form messages: …`). `ui_messages` отвечает `panel_shown: false`, если у окна нет панели сообщений. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.2, `0cb662af2a4d`) доступен по тегу `0.7.2` | | 29.09.2026 | `0cb662af2a4d` | Версия 0.7.2: при открытии формы через расширение `MCPQAClient` 0.6.1 `ui_open` по `kind`+`metadata_name` ждёт форму, которую фактически открыл `ОткрытьФорму`, и отмечает подмену (`substituted_for`); расширение 0.6.0 работает как прежде. `qa_playbook` в нативном режиме: запуск тест-клиента, в том числе скрытый, снимки экрана и установку расширения агент делает по правилам проекта; данные базы — через 1c-data-mcp вместо `ui_eval`. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.1, `f41a7c4648a1`) доступен по тегу `0.7.1` | | 29.09.2026 | `f41a7c4648a1` | Версия 0.7.1: учётная запись Windows больше не нужна — тест-клиент 8.3.27 принимает проверку подлинности канала от любой учётной записи, контейнер без `MCP_QA_TESTCLIENT_USER` входит сам (проверено из Linux-контейнера). `ui_open` по `kind`+`metadata_name` распознаёт основную форму, заданную в конфигурации, и форму, которой конфигурация её подменяет (`substituted_for`; ЗУП: список сотрудников); ошибка открытия называет открывшиеся формы. `ui_close_form` не закрывает главное окно и ничего не закрывает, если форма не найдена. Обрыв связи с тест-клиентом во время действия — неизвестный исход: новые команды ждут `qa_command_status`, затем `qa_reconnect(force=True)`. `qa_setup` и `qa_install_client` отвечают `executor_capability`; `qa_playbook` описывает нативный режим. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.7.0, `0a10b5d42bc9`) доступен по тегу `0.7.0` | | 29.09.2026 | `0a10b5d42bc9` | Версия 0.7.0: нативный менеджер выполняет все операции инструментов `qa_*`/`ui_*` — таблицы и списки (поиск, состояние просмотра, стандартная настройка списка), поля всех видов, выбор ссылки, календарь, табличный документ, HTML и форматированный документ, диалоги, проверки, журнал действий, показатели; `ui_eval` и `qa_run_script` отвечают `executor_capability`. Расширение `MCPQAClient` 0.6.0 работает с контейнером по сети: `/client-bus/v1`, токен сеанса в указателе, `MCP_QA_CLIENT_BUS_URL`. Выгрузка табличного документа пишет файл на машине тест-клиента. Вход из Linux-контейнера по-прежнему требует учётной записи Windows. Ключ, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.6.0, `37e093e0fcdd`) доступен по тегу `0.6.0` | | 29.09.2026 | `37e093e0fcdd` | Версия 0.6.0: контейнер сам работает менеджером тестирования (`MCP_QA_EXECUTOR=native`) и подключается к тест-клиенту, который запустил человек (`MCP_QA_TESTCLIENT`, по умолчанию `host.docker.internal:1538`); отдельный 1С-процесс `/TestManager` не нужен. Проверка подлинности канала — NTLM через `pyspnego`, учётная запись Windows в `MCP_QA_TESTCLIENT_USER`/`_PASSWORD`/`_DOMAIN`. Инструменты прежние (`qa_*`/`ui_*`, 62); неперенесённые операции, снимок экрана и скрытый рабочий стол отвечают `executor_capability`. Вход из Linux-контейнера пока не проверен. Ключ `LICENSE_KEY_QA` прежний, порт 8020 и том `/data` прежние. Предыдущий `latest` (0.5.0, сквозной прокси к Windows-серверу, `de8228f9d1c3`) доступен по тегу `0.5.0` | | 27.09.2026 | `db1a89815fa9` | Версия 0.4.4, только Linux/amd64. Прикладные модули скомпилированы Cython. Сервер требует ключ `LICENSE_KEY_QA` из дистрибутива (контейнеру передаётся как `LICENSE_KEY`): пустой или неверный ключ завершает запуск с `Invalid LICENSE_KEY`. Образ `0.4.3` ключ не проверял и остаётся доступен по своему тегу; порт 8020 и том `/data` прежние. | ## Конвертация данных 2.0 (`comol/1c_conversion_data_mcp`) | Дата | latest | Что изменилось | | ------------------ | ------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 21.10.2026 | `885951f7822b` (arm64 `7ef7cb665e88`) | Версия 0.5.0. Две базы обмена задаются в самом сервере: `set_base` — где база находится (каталог файловой базы, кластер и имя базы на сервере 1С или веб-публикация), пользователь и пароль, платформа, сервер данных базы (`data_server_url`) и признак копии (`sandbox=true`); `set_exchange` связывает две базы в обмен «источник → приёмник» с технологией `КД2` или `КД3` и планами обмена сторон; `describe_exchanges` возвращает и `шаги` — вызовы KD20 для этого обмена; `describe_bases`, `delete_base`, `delete_exchange`. `base_launch_string` даёт строку запуска (Предприятие или Конфигуратор) и строку соединения, пароль — маской, настоящий только с `include_password=true`; базы сервер не запускает. `check_base_in_1c` через сервер данных базы, только чтением, сверяет с профилем конфигурацию и её версию, платформу, БСП, расположение базы и планы обмена. Проверки в 1С (`check_rules_in_1c`, `dump_rules_from_1c`, `exchange_plans_in_1c`, `check_registration_in_1c`) принимают `base` вместо адреса; с записью в отменяемой транзакции — только в базе с `sandbox=true`. Профили баз с паролями хранятся в томе данных (`/data/bases`) открытым текстом и в ответы не попадают. 71 инструмент, ключ и переменные окружения те же | | 21.10.2026 | `42ab31a5b772` (arm64 `8e25f2af982f`) | Версия 0.4.0. Обмен через универсальный формат (EnterpriseData, «Конвертация данных» 3), только чтение: 11 инструментов `ed_*` открывают модуль менеджера обмена из выгрузки конфигурации и схему формата из пакета XDTO, `ed_validate` проверяет связность модуля и соответствие правил схеме формата и конфигурации; справка — `kd20_format_reference(section="кд3_грабли")`. Через сервер данных копии базы (`KD20_SANDBOX_DATA_URL` или параметр `data_server_url`), необязательно: `dump_rules_from_1c` снимает правила, которые действуют в базе, `exchange_plans_in_1c` показывает планы обмена, узлы и источник правил, `check_registration_in_1c` показывает, на какие узлы регистрируется объект, — запись идёт в транзакции, которая всегда отменяется. `pack_rules_zip` собирает ZIP комплекта правил для ручной загрузки в БСП, `handler_queries` разбирает запросы в обработчиках. Новые проверки: `validate_ruleset` — E025, W020–W030, I005, I006; `validate_registration_rules` — R010–R017; `build_registration_rules` принимает отборы по свойствам плана и объекта. `draft_ruleset` по умолчанию ведёт себя как КД 2.1: синхронизация по идентификатору, черновик без полей поиска; для первой синхронизации баз, где данные уже есть, — `sync_by_id=false`. `trace_object` — глубина и лимит, `search_ruleset_code` — постраничный вывод и фильтры, `diff_rulesets` — подробнее по ПКЗ, обработчикам и регистрации, `suggest_object_mappings` подбирает и по составу реквизитов. ВСТРОЕННЫЕ СПРАВОЧНИКИ В ПОИСКОВОМ ИНДЕКСЕ ОБНОВЛЯЮТСЯ ПРИ КАЖДОМ ЗАПУСКЕ (ТЕПЕРЬ ПЯТЬ ФАЙЛОВ, ДОЛИ СЕКУНДЫ); ПРОИНДЕКСИРОВАННОЕ ЧЕРЕЗ `index_kd20_path` НЕ ТРОГАЕТСЯ. 63 инструмента, ключ тот же | | 16.10.2026 | `a273a83fcf46` (arm64 `d6e481fb245d`) | Версия 0.3.0. `validate_ruleset` проверяет, как правила исполняет обмен через план обмена БСП: второй ПВД на тот же тип не выполняется (W013); способ отбора «произвольный алгоритм», `ВыборкаДанных` и `Отказ = Истина` в «ПередОбработкойПравила» не исполняются (W014); формы поиска, которые дают дубли или сливают объекты (W015–W018); `Объект.Записать()` в «ПослеЗагрузки» (W019); объект уходит только ссылкой (I004, новый необязательный параметр `registration_name` учитывает режим выгрузки «при необходимости»). ПКС с «Обязательное» считается свойством поиска; код отключённых ПВД, ПОД и ПКС не проверяется; ошибки в алгоритме, который ничем не вызывается, — предупреждения; W004 учитывает, что по типу значения работает последнее ПКО источника; два алгоритма с одним именем в одном режиме — E002. Исправлено в `validate_registration_rules`: правила внутри отключённой группы проверяются, как их и загружает БСП; R007 — объект ПВД вне состава плана, новые R008 (нет правила регистрации — БСП регистрирует объект на всех узлах) и R009 (разрешена авторегистрация — отборы не действуют). `trace_object` показывает ПВД, вместо которого работает другой, реквизит режима выгрузки и попадание объекта в очередь узла. Исправлено в справке о граблях: обработчики загрузки исполняются из копии правил в приёмнике, объект по ссылке по умолчанию уходит только ссылкой. ВСТРОЕННЫЕ СПРАВОЧНИКИ В ПОИСКОВОМ ИНДЕКСЕ ОБНОВЛЯЮТСЯ ПРИ КАЖДОМ ЗАПУСКЕ (ЧЕТЫРЕ ФАЙЛА, ДОЛИ СЕКУНДЫ); ПРОИНДЕКСИРОВАННОЕ ЧЕРЕЗ `index_kd20_path` НЕ ТРОГАЕТСЯ. 47 инструментов, ключ тот же | | 03.10.2026 | `a8e382fc7890` (arm64 `b995391b2812`) | Версия 0.2.2. Поведение не изменилось: код тот же, что в 0.2.1, собран по новой схеме сборки. Скомпилированные модули `latest` побайтно те же, что в 0.2.1; в `arm64` тот же набор модулей скомпилирован с `-O1` вместо `-O2`. Слои базы и зависимостей не изменились, поэтому при обновлении скачивается только слой приложения (около 1,6 МБ). Ключ тот же | | 01.10.2026 (вечер) | `e350c4699ab6` (arm64 `3e6179f495f0`) | Версия 0.2.1. Новый инструмент `check_rules_in_1c` (47 инструментов): правила обмена, корреспондента и регистрации загружаются штатным методом БСП `ПравилаДляОбменаДанными.ЗагрузитьПравила` в копии базы через её сервер данных (1c-data-mcp, `KD20_SANDBOX_DATA_URL`) — в запись в памяти, в транзакции с откатом; ответ называет причину отказа из сообщений БСП и журнала регистрации. Проверено на копии ЗУП КОРП 3.1.26: типовые правила `ОбменЗарплата3Бухгалтерия3` после записи сервером и черновик с нуля загружаются. `draft_ruleset` создаёт выключенными ПКС, значение которых исполнитель не перенесёт (ссылка без ПКО в черновике, примитив в объектную ссылку), и перечисляет их с причиной в `выключенные_ПКС`. Ключ тот же, что у 0.2.0 | | 01.10.2026 | `e8e5a0930026` (arm64 `b3376adca370`) | Первый выпуск, версия 0.2.0: правила обмена «Конвертации данных» 2.0/2.1 — подбор соответствий, черновик и правка правил, проверка по метаданным обеих конфигураций и по поведению исполнителя БСП, импорт макетов без потерь и запись в стиле КД 2.1, правила регистрации, черновик правил корреспондента, смысловой дифф, навигация по коду правил, выгрузка обработчиков для SyntaxCheckServer; 46 инструментов. Нужен ключ `LICENSE_KEY_KD20` из дистрибутива от 01.10.2026. Модули сервера скомпилированы Cython. [Страница сервера](/mcp-servery-1c/servery/kd20.md) |