> 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/servery/graph-metadata-search/konfiguraciya.md). # Конфигурация ## Переменные окружения MCP сервера ### Обязательные | Переменная | Описание | Пример | | ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------- | ------------------- | | `LICENSE_KEY` | Лицензионный ключ | `YOUR_LICENSE_KEY` | | `NEO4J_URI` | URI подключения к Neo4j | `bolt://neo4j:7687` | | `NEO4J_USERNAME` | Пользователь Neo4j | `neo4j` | | `NEO4J_USER` | Устаревший алиас `NEO4J_USERNAME`. Если заданы обе переменные, приоритет у `NEO4J_USERNAME`, а выбор пишется в лог | — | | `NEO4J_PASSWORD` | Пароль Neo4j. Значения по умолчанию нет: в образе пароль не зашит, и запуск без этой переменной завершается ошибкой аутентификации Neo4j | Обязательно | {% hint style="info" %} Отдельный текстовый отчёт больше не обязателен. При `METADATA_SOURCE=auto` сервер сначала синтезирует отчёт из Designer XML-выгрузки в `CODE_EXPORT_PATH`, иначе читает `.mdo` проекта 1C:EDT, и только если выгрузки нет — берёт лежащий рядом `*.txt`. {% endhint %} ### Источники метаданных и кода | Переменная | Описание | По умолчанию | | ------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------- | | `METADATA_DIRECTORY` | Каталог с текстовым отчётом Конфигуратора. Может быть пустым при работе по Designer XML | `/app/metadata` | | `METADATA_SOURCE` | `auto` — синтез из Designer XML, иначе дескрипторы проекта 1C:EDT, иначе готовый `*.txt`; `report` — требовать отчёт; `xml` — только Designer-выгрузка, отчёт игнорируется, EDT-корень отклоняется; `edt` — только проект 1C:EDT, отчёт не ищется и не пишется | `auto` | | `GENERATED_REPORT_DIRECTORY` | Кэш синтезированного отчёта; не должен находиться внутри `CODE_EXPORT_PATH` | `INGESTION_STATE_DIRECTORY/generated-report` | | `METADATA_FALLBACK_DIR_1`, `METADATA_FALLBACK_DIR_2`, `METADATA_FALLBACK_DIR_3` | Дополнительные каталоги готового отчёта, проверяемые по порядку после `METADATA_DIRECTORY`; используются только если заданы явно | — | | `CODE_EXPORT_PATH` | Корень Designer XML-выгрузки или проекта 1C:EDT. Для Designer XML служит источником и BSL/форм, и синтеза отчёта | — | | `METADATA_FILES` | Каталог дополнительных детальных файлов метаданных | — | Синтез отчёта поддерживает Designer XML (каталог с `Configuration.xml`) и выполняется в фоновой стадии `metadata_ingest`. Готовый текстовый отчёт больше не нужен. При `METADATA_SOURCE=auto` сначала берётся Designer XML-выгрузка, иначе проект 1C:EDT, и только если выгрузки нет — лежащий рядом `*.txt`. Отчёт на английском `ScriptVariant` не строит реквизиты, ТЧ и формы; выгрузка это умеет. При `METADATA_SOURCE=edt` метаданные читаются прямо из `.mdo`. Не поддерживается на EDT только *синтез* отчёта: `METADATA_SOURCE=xml` на EDT-корне возвращает `unsupported_by_edt`. Формат EDT для остальных контуров по-прежнему включается через `SOURCE_FORMAT_ADAPTERS_ENABLED=true` и `SOURCE_FORMAT=edt`. {% hint style="warning" %} При `METADATA_SOURCE=auto` выгрузка старше любого `*.txt` в `METADATA_DIRECTORY`. Чтобы читать именно отчёт, задайте `METADATA_SOURCE=report`. Если каталог отчёта не используется, не монтируйте его и не занимайте под что-либо другое. {% endhint %} #### Смена источника метаданных у построенного проекта Узлы конфигурации привязаны к файлу, из которого прочитаны метаданные: `ОтчетПоКонфигурации.txt`, синтезированный `Report.txt` или `Configuration.mdo` проекта EDT. Источник проекта может смениться: отчёт переименован, рядом с ним появилась XML-выгрузка при `METADATA_SOURCE=auto`, проект переведён с отчёта на выгрузку или на EDT. Тогда при следующей загрузке метаданных сервер переносит узлы этой конфигурации на новый файл и обновляет их на месте (образы от 04.10.2026). Модули, процедуры с векторами, связи расширений и описания сохраняются, переиндексации нет. В журнале появляется строка `Configuration '<имя>' of project '<проект>' was read from '<старый файл>' before and is read from '<новый файл>' now`. {% hint style="warning" %} Образы до 04.10.2026 вместо этого создавали вторую копию каждого объекта (например, при переходе с beta, построенной из отчёта, на stable), и поиск возвращал объекты дважды. Такой проект сервер сам не исправляет: он пишет в журнал `holds configuration … more than once`. Есть два способа исправить. **Перестроить проект целиком.** Запустите контейнер **один раз** командой `python run.py web --clear` — она очищает данные проекта и строит граф заново. После этого верните команду по умолчанию, иначе каждый перезапуск будет снова очищать проект. Векторы и описания при этом считаются заново. **Удалить лишнюю копию** (при `GRAPH_SCOPE_ENFORCED=true`; без него используйте первый способ). Удалите копию, привязанную к новому файлу, и перезапустите сервер; модули, процедуры с векторами и связи расширений сохранятся. Запрос выполняется в Neo4j Browser с префиксом `:auto`. В нём `$ns` — `MCP_NAMESPACE`, `$project` — `PROJECT_NAME`, `$config` — имя конфигурации, `Report.txt` — имя нового файла из предупреждения: ```cypher MATCH (n {mcp_namespace: $ns, project_id: $project}) WHERE n.filename = 'Report.txt' AND (n.config_name = $config OR (n:Configuration AND n.name = $config)) CALL (n) { OPTIONAL MATCH (n)-[:HAS_BUSINESS_CHUNK|HAS_DESCRIPTION_CHUNK]->(c) DETACH DELETE c, n } IN TRANSACTIONS OF 5000 ROWS; MATCH (m:IndexingMarker {name: 'metadata_load', project_name: $project}) DETACH DELETE m; ``` Условие на `config_name` обязательно: без него удалятся и узлы расширений, синтезированные отчёты которых тоже называются `Report.txt`. {% endhint %} ### Управление индексацией | Переменная | Описание | По умолчанию | | -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `RESET_DATABASE` | Сбросить векторы эмбеддингов при смене модели (без него сервер с другой моделью не запускается). Граф не пересобирает: для полной пересборки см. [Полный перезапуск](https://docs.onerpa.ru/mcp-servery-1c/servery/graph-metadata-search/pages/fxDyUR26bPIaXlZ63emw#полный-перезапуск) | `false` | | `ASYNC_VECTOR_INDEXING` | Не влияет на запуск и порядок задач — его задаёт `BACKGROUND_POST_INDEXING`. Сохранена для совместимости | `true` | | `BACKGROUND_POST_INDEXING` | `true` — веб-интерфейс и MCP открываются сразу после старта, а основная индексация, генерация бизнес-описаний и векторы идут в фоне. Ход работ виден в `get_indexing_status` и `GET /status`. `false` — порт закрыт, пока не завершатся **все** фоновые задачи, включая описания и векторы. Это часы, а на крупной конфигурации — сутки, и всё это время healthcheck не проходит. С образов от 04.10.2026 в журнале при этом пишется предупреждение. Значение `false` не рекомендуется | `true` | | `GRAPH_REFRESH_INTERVAL_SEC` | Как часто работающий сервер сверяет выгрузку с прочитанной в прошлый раз (путь, размер и mtime каждого файла, без чтения содержимого) и при изменениях заново прогоняет стартовый конвейер в том же процессе — то, что раньше давал только перезапуск контейнера. BSL-модули сверяются по hash содержимого (новые, изменённые, удалённые), метаданные перечитываются, если менялись `*.xml`/`*.mdo`/отчёт, формы перечитываются только изменённые. Права ролей, подписки на события, предопределённые элементы и справка сверяются по hash документа: изменённые перечитываются, исчезнувшие из выгрузки удаляются (образы от 10.10.2026). Данные проекта не очищаются: метаданные сливаются поверх, а объекты, реквизиты, табличные части, формы, команды и макеты, которых в выгрузке больше нет, удаляются (образы от 04.10.2026; раньше они оставались до полной пересборки). Снимок выгрузки сохраняется в `INGESTION_STATE_DIRECTORY` (`source-refresh-snapshot.json`) после каждого применённого изменения. При старте, когда стартовая индексация закончится, сверка сравнивает выгрузку с ним и применяет то, что изменилось при остановленном сервере: изменённые формы перечитываются, а модули и метаданные XML-выгрузки старт применяет сам. Если сохранённого снимка нет, выгрузка принимается как есть. Состояние — `source_refresh.baseline_restored`. Пока идёт фоновая задача или административный refresh, проверка пропускается с причиной `writer_busy`, и изменения применяются следующим тиком. Если прошлый прогон оставил упавшие задачи (например, Neo4j перезапустился во время `bsl_code_graph`, и зависимые фазы не запустились), тик прогоняет конвейер заново и без изменений выгрузки, тоже с resume: завершённое не повторяется. Повтор идёт каждым тиком, пока задачи не завершатся; в `last_refresh.trigger` тогда `{"failed_tasks": [...]}` (образы от 28.09.2026). Состояние — `get_indexing_status().source_refresh` и `GET /status`. `0` — выключено, выгрузка читается только при старте (образы от 21.09.2026) | `3600` | | `GRAPH_REFRESH_APPLY` | `false` — только обнаружение: изменение выгрузки фиксируется в статусе (`drift`, `last_skip_reason: apply_disabled`) и в журнале, конвейер не запускается; упавшие задачи прошлого прогона тоже не повторяются | `true` | | `INDEX_BATCH_SIZE` | Количество объектов, обрабатываемых за один пакет при создании векторного индекса | `512` | | `GRAPH_FORM_XML_BATCH_SIZE` | Сколько управляемых форм вместе проходят bulk-поиск владельцев и проверку resume. Запись этой пачки может дополнительно делиться по `GRAPH_FORM_XML_BATCH_MAX_ROWS`. Значение `1` возвращает прежний путь «по одной форме». Допустимый диапазон `1..500`, значение вне диапазона отклоняется при старте | `50` | | `GRAPH_FORM_XML_BATCH_MAX_ROWS` | Порог сброса накопленных строк, проверяемый после добавления целой формы; это не жёсткий предел транзакции. Форма крупнее порога записывается отдельно и сама может превысить это значение. Минимум `1`, значение ниже отклоняется при старте | `20000` | | `MAX_TOKENS_PER_BATCH` | Максимальное количество токенов в одном пакете запроса к API эмбеддингов | `28000` | | `BATCH_MAX_RETRIES` | Сколько раз повторить пакет эмбеддингов (бизнес-описания, описания объектов, код, процедуры) после временной ошибки провайдера — обрыв соединения, `503` от прокси, лимит запросов. Пакеты, не прошедшие и после повторов, получают ещё один проход в конце лейна. Только если и он не помог, задача (`vector_indexing` / `routine_embedding_indexing`) помечается `failed`, а в ошибке указывается доля объектов без эмбеддингов; следующий старт дозаполняет именно их | `10` | | `BATCH_BACKOFF_BASE` | Основание экспоненциальной паузы между повторами пакета: `min(BASE^попытка, MAX)` секунд | `2.0` | | `BATCH_BACKOFF_MAX` | Максимальная пауза между повторами пакета, секунды | `60.0` | | `EMBEDDING_REQUEST_CONCURRENCY` | Количество параллельных запросов к API эмбеддингов | `6` | | `EMBEDDING_MAX_ATTEMPTS` | Сколько раз отправляется один запрос к API эмбеддингов, считая первую попытку (1–10), — при индексации и для эмбеддинга поискового запроса. Повторы делает клиент (таймаут, обрыв, `429`, `5xx`); `1` — без повторов внутри клиента, тогда повторяет только `BATCH_MAX_RETRIES`. На пакет индексации — не больше `EMBEDDING_MAX_ATTEMPTS` × (`BATCH_MAX_RETRIES` + 2) запросов (+2: первая попытка пакета и финальный проход). Индекс не перестраивается | `3` | | `EMBEDDING_MAX_TOKENS` | Максимальное количество токенов на один текст при генерации эмбеддингов. Определяется автоматически по модели, но можно переопределить | *(авто)* | | `EMBEDDING_CHUNK_TARGET_TOKENS` | Целевой размер чанка при разбивке длинных текстов | *(авто)* | | `EMBEDDING_CHUNK_OVERLAP_TOKENS` | Перекрытие чанков при разбивке длинных текстов | *(авто)* | {% hint style="warning" %} `GRAPH_FORM_XML_BATCH_SIZE` и `GRAPH_FORM_XML_BATCH_MAX_ROWS` описывают текущие исходники. Наличие этого контракта в конкретном опубликованном образе проверяйте по release notes перед изменением настроек. В актуальном исходном коде структурная транзакция ставит свойству `form_xml_structure_state` значение `pending`, а после сохранения reference evidence — `complete`. Resume пропускает только завершённые формы. Если evidence не сохранился, счётчик `left recoverable` показывает оставшиеся `pending`: следующий прогон перепишет именно их. Частичная структура при ошибке записи удаляется, чтобы следующий прогон не продолжил поверх неполных данных. {% endhint %} ### Embedding модели | Переменная | Описание | Пример | | ---------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | `OPENAI_API_BASE` | URL API для генерации и LLM | `http://host.docker.internal:1234/v1` | | `OPENAI_API_KEY` | Ключ API для генерации и LLM | `lm-studio` | | `OPENAI_MODEL` | LLM модель для генерации описаний | `gpt-5` | | `OPENAI_TEMPERATURE` | Температура генерации (0–1). Для reasoning-моделей (o1, o3, gpt-5) игнорируется | `0.1` | | `OPENAI_MAX_COMPLETION_TOKENS` | Максимальное количество токенов в ответе LLM | `2000` | | `OPENAI_MODEL_IS_REASONING` | Принудительное указание, является ли модель «рассуждающей». Если не указано — определяется автоматически по имени модели (o1\*, o3\*, gpt-5\*) | *(авто)* | | `EMBEDDING_API_BASE` | Отдельный URL для API эмбеддингов (если отличается от LLM API) | — | | `EMBEDDING_API_BASE_NO_V1` | Передавать базу API дословно, без автодобавления `/v1` (значения `1`, `true`, `yes`) — для шлюзов, отдающих OpenAI-совместимый API без суффикса `/v1`. С 10.10.2026 | `1` | | `EMBEDDING_API_KEY` | Отдельный ключ для API эмбеддингов | — | | `EMBEDDING_MODEL` | Модель для API эмбеддингов. У модели Qwen3-Embedding запрос идёт с инструкцией задачи (см. [Инструкция к запросу у Qwen3](https://docs.onerpa.ru/mcp-servery-1c/servery/graph-metadata-search/pages/zZx7MZNnC5Ejse6V9TZC#инструкция-к-запросу-у-qwen3)) | `qwen/qwen3-embedding-8b` | | `OPENAI_EMBEDDING_DIMENSIONS` | Явное указание размерности эмбеддингов, запрашиваемой у API | *(авто)* | | `VECTOR_INDEX_DIMENSION` | Ожидаемая размерность векторного индекса процедур; если не задана, сервер читает её из метаданных индекса | *(авто)* | | `LOCAL_EMBEDDING_MODEL` | Локальная CPU модель (sentence-transformers). Совместимый алиас — `OFFLINE_EMBEDDING_MODEL` | `intfloat/multilingual-e5-small` | | `EMBEDDING_ALLOW_OFFLINE_FALLBACK` | Разрешить автопереход на локальную модель при недоступности API | `true` | Старые имена `OPENAI_EMBEDDING_API_BASE`, `OPENAI_EMBEDDING_API_KEY` и `OPENAI_EMBEDDING_MODEL` остаются совместимыми алиасами. ### Шаблонный режим | Переменная | Описание | По умолчанию | | ----------------------- | ----------------------------------------------------------------------------------- | ------------ | | `TEMPLATE_MODE_ENABLED` | Включить шаблонный режим — JSON-запросы с мгновенными ответами без LLM | `true` | | `TEMPLATE_MODE_ONLY` | Только шаблонные запросы, LLM не используется. Требует `TEMPLATE_MODE_ENABLED=true` | `false` | ### Поиск по коду | Переменная | Описание | По умолчанию | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `ENABLE_CODE_SEARCH` | Включить поиск по BSL-файлам | `true` | | `CODE_SEARCH_MAX_FILE_SIZE` | Объявленный порог размера BSL-файла (байт). Индексация его не применяет: отбора и обрезки по этому порогу нет — см. врезку ниже | `50000` | {% hint style="warning" %} **`CODE_SEARCH_MAX_FILE_SIZE` не отсекает крупные файлы.** Значение объявлено в настройках сервера, но индексация его не применяет: ни отбора, ни обрезки по этому порогу нет. * **Что делает порог.** Ничего: из-за него файл крупнее `50000` байт не пропускается и не укорачивается, и сам по себе он не определяет, что попадёт в граф и в поиск. Остальные условия действуют как обычно и от него не зависят: нечитаемый или недекодируемый файл, ошибки разбора, выбранные режимы загрузки (`LOAD_BSL_SIGNATURES`, `ENABLE_ROUTINE_EMBEDDINGS`, `ENABLE_CODE_SEARCH`) и границы проекта. * **Пропуск или обрезка.** Ни того, ни другого по этому порогу: BSL-файл читается целиком, а не до первых `50000` байт. * **Токенный бюджет эмбеддингов — отдельный механизм.** Текст, который уходит на эмбеддинг процедуры, ограничен бюджетом токенов модели (`EMBEDDING_MAX_TOKENS`, по умолчанию определяется по модели): сигнатура и описание сохраняются целиком, длинное тело внутри этого текста укорачивается. Это токены на процедуру, а не байты на файл, и с `50000` никак не связано — умолчание `CODE_SEARCH_MAX_FILE_SIZE` ограничение модели эмбеддингов не отражает. * **Что видит пользователь.** Поиск по коду работает на уровне процедур и функций: полнотекстовый маршрут учитывает имя, сигнатуру, описание и тело процедуры. Сколько текста придёт в ответе, задают `detail_level` и лимиты размера ответа — это формат выдачи, а не усечение исходного файла. Если нужный фрагмент не нашёлся, смотрите на формулировку запроса и режим поиска (правила Lucene и анализатор), фильтры и `top_k`, а также на то, дошла ли индексация до этого модуля. * **Цена изменения.** Повышать значение ради полноты индекса нет смысла: оно ничего не расширяет и на расход эмбеддингов не влияет. В типовых конфигурациях фирмы «1С» встречаются модули в сотни раз крупнее `50000` байт. Раз этот порог ничего не отсекает, время индексации, объём базы Neo4j и расход эмбеддингов определяются всем объёмом выгрузки — оценивайте их замером на своих данных. {% endhint %} ### Семантический поиск | Переменная | Описание | По умолчанию | | --------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `ENABLE_BUSINESS_SEARCH` | Включить семантический поиск по бизнес-описаниям | `true` | | `CALCULATE_BUSINESS_INFO` | Использовать бизнес-описания объектов метаданных: генерировать их LLM и подтягивать `business_info.html`, написанные рядом с объектом. `false` выключает всё вместе — и генерацию, и импорт с диска, и семантический поиск по описаниям | `false` | | `BUSINESS_INFO_UPDATE_POLICY` | Когда автоматический запуск (после индексации при старте и после обновления графа) вправе вызвать LLM: `never` — только для объектов, у которых описания нет нигде; `threshold` — как `never`, плюс перегенерация описанного объекта, если доля его структурных изменений с момента описания достигла `BUSINESS_INFO_CHANGE_THRESHOLD`; `manual` — автоматически LLM не вызывается, описания создаёт только явный запуск. Импорт `business_info.html` с диска идёт при любом значении | `never` | | `BUSINESS_INFO_CHANGE_THRESHOLD` | Порог для `threshold`: расстояние Жаккара между фасетами объекта (реквизиты с типами, табличные части, измерения, ресурсы, формы, команды, макеты, экспортные процедуры модулей объекта) на момент описания и сейчас, от `0` до `1`. Переименование одного реквизита из десяти даёт `0.18` | `0.2` | | `BUSINESS_INFO_CACHE_DIRECTORY` | Куда класть `business_info.html` (и `business_info.facets.json`) объекта, у которого в выгрузке нет собственной папки — большинство констант, перечислений и регистров сведений выгрузки Конфигуратора представлены одним `<Имя>.xml`. Такие объекты описываются по своему `.xml` и записываются в Neo4j как все остальные, а файловая копия ложится сюда в той же раскладке `<Категория>/<Имя>/`; папка рядом с `.xml` в выгрузке не создаётся. Пусто — `/app/data/business_info` (том состояния контейнера) | — | | `BUSINESS_INFO_MAX_TOKENS` | Максимум токенов контекста для бизнес-описаний | `4000` | | `BUSINESS_INFO_RETRY_COUNT` | Количество повторных попыток при ошибках API | `3` | | `BUSINESS_INFO_THREADS` | Количество параллельных воркеров генерации бизнес-описаний | `10` | | `ENABLE_METADATA_DESCRIPTION_EMBEDDING` | Генерировать эмбеддинги для описательных полей метаданных (Синоним, Комментарий, Описание, справка) | `true` | {% hint style="warning" %} **Каталог исходников монтируется на запись — без `:ro`.** При `CALCULATE_BUSINESS_INFO=true` описание пишется в `business_info.html` рядом с объектом метаданных, и в Neo4j оно попадает только после успешной записи файла. Если `/app/code` смонтирован read-only, каждый объект даёт `[Errno 30] Read-only file system: /app/code/.../business_info.html`: описание не сохраняется ни на диск, ни в граф, а токены LLM тратятся впустую. Контейнер при этом остаётся `healthy`, структурный граф и векторный индекс описаний строятся как обычно — ошибку легко не заметить. Проверить правом на запись, а не глазами: `docker exec 1c_graph_metadata sh -c "touch /app/code/.rwcheck && rm /app/code/.rwcheck && echo OK"` — на корректном монтировании команда печатает `OK`, на read-only падает с `Read-only file system`. Остальные серверы (CodeMetadataSearch, SyntaxCheck, 1CCodeChecker) читают тот же каталог и монтируют его `:ro` — это нормально, требование к записи есть только у GraphMetadataSearch. При `SOURCE_FORMAT=edt` (или когда корень — проект EDT: `DT-INF`, `.project`, `src/Configuration`) генератор пишет `src/<Категория>/<Имя>/business_info.html` рядом с `<Имя>.mdo`. Пути выгрузки Конфигуратора (`Documents/<Имя>.xml` без `src/`) на EDT-дереве не используются, в том числе если в Neo4j после разбора отчёта остались такие пути. Объект, у которого в выгрузке есть только `<Категория>/<Имя>.xml` и нет папки `<Категория>/<Имя>/` (в выгрузке Конфигуратора папка создаётся только у объектов с модулями, формами, макетами или справкой), описывается по своему `.xml`: описание попадает в Neo4j как у всех, а файловая копия и слепок структуры пишутся в `BUSINESS_INFO_CACHE_DIRECTORY` (по умолчанию `/app/data/business_info/<Категория>/<Имя>/`), папка в выгрузке не создаётся. В итоговой сводке такие объекты видны строкой `Described from the descriptor alone`; `Skipped (no source)` остаётся только за объектами, у которых нет и `.xml`. {% endhint %} #### Откуда берутся бизнес-описания У объекта два источника описания, и оба ведут в одно свойство `business_info` узла в Neo4j, по которому строится векторный индекс и отвечает `business_search`: 1. **Генерация LLM** — задача `generate_business_info` после индексации, а также обогащение новых объектов после обновления графа. Что именно она вправе перегенерировать, решает `BUSINESS_INFO_UPDATE_POLICY`; сгенерированный текст сохраняется в Neo4j и в `business_info.html` рядом с объектом (плюс `business_info.facets.json` — слепок структуры, от которого `threshold` считает изменения). 2. **Файл `business_info.html` рядом с объектом**, написанный кем угодно — ИИ-агентом, разработчиком, скриптом. Для выгрузки Конфигуратора это `<Категория>/<Имя>/business_info.html` (например `Catalogs/Контрагенты/business_info.html`), для проекта EDT — `src/<Категория>/<Имя>/business_info.html`. Содержимое — HTML или простой текст, кодировка UTF-8. Для объекта без собственной папки в выгрузке (один `<Имя>.xml`) файл кладётся в `BUSINESS_INFO_CACHE_DIRECTORY` в той же раскладке — например `/app/data/business_info/Enums/ВидыНумерации/business_info.html`; папку рядом с `.xml` создавать не нужно. **Объекты расширений в режиме каталога** (`EXTENSION_CATALOG_ENABLED=true`, образы от 04.10.2026): * **Собственный объект расширения** описывается по файлам выгрузки своего расширения (`EXTENSIONS_PATH/<каталог расширения>`). Его `business_info.html` лежит рядом с объектом там же, например `<каталог расширения>/HTTPServices/Расш_Сервис/business_info.html`. * **Объект расширения без собственной папки** получает файл в `BUSINESS_INFO_CACHE_DIRECTORY/extensions/<имя расширения>/<Категория>/<Имя>/business_info.html`, чтобы одноимённые объекты разных расширений не перетирали друг друга. * **Заимствованные объекты** расширения описываются как одноимённые объекты основной конфигурации и делят с ними описание. Файлы объектов основной конфигурации лежат там же, где и раньше. Раньше собственные объекты расширения пропускались с записью `Skipping … no XML source for business_info`. При первом старте нового образа в план попадут только они, уже описанные объекты повторно не генерируются. Файлы с диска подтягивает задача `import_business_info`. Она идёт при каждом старте, когда `CALCULATE_BUSINESS_INFO=true`, при любой политике и даже без настроенного LLM-провайдера, раньше генерации и векторной индексации, и стоит один `stat` на объект. Правила: * у объекта в графе описания нет, файл есть — описание импортируется; * описание в графе есть, файл **новее** него (по `mtime` относительно `business_info_generated_at`) и текст отличается — описание заменяется файлом, старый вектор и слепок структуры удаляются, чтобы следующая векторная индексация посчитала эмбеддинг заново, а политика взяла текущую структуру за точку отсчёта; * файл не новее записи в графе (в том числе файл, который записал сам генератор) — не читается и ничего не меняет. При `EXTENSION_CATALOG_ENABLED=true` задачи `import_business_info` и `generate_business_info` начинаются после загрузки каталога расширений (`extension_catalog`), чтобы в их список попали объекты расширений (образы от 04.10.2026). Сбой загрузки отдельного расширения их не останавливает. Генерация на первом построении поэтому начинается позже — после графа кода и загрузки расширений, зато досчитывать описания расширений перезапуском больше не нужно. Векторная индексация описаний объектов (`vector_indexing`) с образов от 06.10.2026 тоже начинается после `extension_catalog` — в том числе при `CALCULATE_BUSINESS_INFO=false`. На уже построенном графе первый старт нового образа досчитывает векторы только тех объектов, у которых их нет; переиндексации нет. Тот же импорт выполняют обновление графа для новых объектов (файловый монитор и `POST /search/update-graph`) и административный эндпоинт `POST /search/reindex-only` — им можно подтянуть файлы без перезапуска контейнера; после импорта он запускает векторную индексацию. **Свои описания вместо генерации.** Чтобы описания писал агент, а LLM сервер не вызывал: ```env CALCULATE_BUSINESS_INFO=true BUSINESS_INFO_UPDATE_POLICY=manual ``` Далее агент раскладывает `business_info.html` по папкам объектов, а сервер перезапускается либо вызывается `POST /search/reindex-only`. `manual` только запрещает автоматические вызовы LLM; семантический поиск и эмбеддинги описаний работают как обычно (`ENABLE_BUSINESS_SEARCH=true`, провайдер эмбеддингов настроен). `CALCULATE_BUSINESS_INFO=false` для этой задачи не подходит: он выключает и импорт, и поиск по описаниям. **Явный запуск генерации** не зависит от политики и сначала показывает план (в контейнере команды выполняет `run.py`, в исходном дереве — `main.py`): ```bash # что изменилось бы, без вызова LLM и без записи docker exec 1c_graph_metadata python run.py generate-business-info --regenerate changed --dry-run # описать объекты без описания docker exec 1c_graph_metadata python run.py generate-business-info # перегенерировать описанные объекты, изменившиеся сильнее порога / все docker exec 1c_graph_metadata python run.py generate-business-info --regenerate changed docker exec 1c_graph_metadata python run.py generate-business-info --regenerate all ``` То же по HTTP: `POST /search/generate-business-info` с телом `{"regenerate": "none|changed|all", "dry_run": true|false}`. Административные эндпоинты (`/search/update-graph`, `/search/update-business`, `/search/reindex-only`, `/search/generate-business-info`) требуют заголовок `X-Admin-Token` со значением `ADMIN_TOKEN`; без заданного токена они отвечают `403`. ### BSL-граф (Module / Routine / CALLS) | Переменная | Описание | По умолчанию | | --------------------------- | ------------------------------------------------------------------------------------------------------------- | ------------ | | `CODE_EXPORT_PATH` | Путь к Designer XML-выгрузке или проекту 1C:EDT (тот же источник, что описан выше) | — | | `LOAD_BSL_SIGNATURES` | Загружать сигнатуры BSL-кода в граф — создавать ноды Module и Routine с графом вызовов CALLS | `true` | | `ENABLE_ROUTINE_EMBEDDINGS` | Генерировать эмбеддинги для процедур/функций. Требует `LOAD_BSL_SIGNATURES=true`. Индексация в фоновом потоке | `true` | | `BSL_READ_PREFIX_BYTES` | Сколько байт файла читается для быстрой классификации BSL | `4096` | ### Дополнительные данные из XML-выгрузки Все опции ниже требуют заполнения `CODE_EXPORT_PATH`. | Переменная | Описание | По умолчанию | | -------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `LOAD_FORMS_FROM_XML` | Загружать структуру управляемых форм из `Ext/Form.xml` (FormControl, FormEvent, FormAttribute) | `false` | | `LOAD_ORDINARY_FORMS` | Загружать структуру обычных форм (отдельная модель узлов от управляемых) | `true` | | `LOAD_EVENT_SUBSCRIPTIONS` | Загружать подписки на события из `EventSubscriptions/*.xml` | `false` | | `LOAD_PREDEFINED_VALUES` | Загружать предопределённые элементы из `*/Predefined.xml` | `false` | | `LOAD_ROLE_RIGHTS` | Загружать права ролей из `Roles/*/Ext/Rights.xml`: выданные и явно запрещённые права, условия ограничений на уровне записей (RLS) и шаблоны ограничений роли | `false` | | `LOAD_HELP_FROM_HTML` | Загружать справку объектов из `*/Help/ru.html` | `false` | | `LOAD_DCS_TEMPLATES` | Загружать схемы компоновки данных из макетов отчётов и обработок: `Templates/<Макет>/Ext/Template.xml` выгрузки Конфигуратора (схема распознаётся по содержимому файла) или `Templates/<Макет>/Template.dcs` проекта 1C:EDT. Нужен `SOURCE_FORMAT_ADAPTERS_ENABLED=true`. Если переменная включена у уже построенного графа, схемы загружаются при следующем старте, пока в графе нет узлов `DcsField`, — полная пересборка не нужна; одной `LOAD_DCS_TEMPLATES=true` без других XML-подисточников достаточно (образы с 16.10.2026; раньше фаза XML-подисточников без них не запускалась). Для каждой СКД узел макета `Layout` получает признак `dcs = true`, а под ним создаются узлы `DcsDataSet` (наборы данных и их запросы), `DcsField` (поля; связь `HAS_DCS_FIELD` и от макета, и от набора данных, который поле поставляет), `DcsParameter`, `DcsGrouping`, `DcsFilter` и `DcsTemplateArea` (области макетов) со связями `HAS_DCS_DATA_SET`, `HAS_DCS_PARAMETER`, `HAS_DCS_GROUPING`, `HAS_DCS_FILTER`, `HAS_DCS_TEMPLATE`. Каждая связь хранит XML-путь элемента, из которого прочитана. Это данные инструмента `get_report_dcs_lineage` (отчёт → СКД → наборы данных и запросы → поля/параметры/группировки/отборы/макеты). На крупной конфигурации это заметная часть графа — порядка десятка тысяч узлов | `false` | ### Поддержка расширений | Переменная | Описание | По умолчанию | | --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ------------ | | `EXTENSION_NAME` | Имя расширения. Если задано, все загружаемые объекты получают `origin="extension"` | — | | `EXTENSION_BASE_PROJECT` | Имя базового проекта (`PROJECT_NAME` базовой конфигурации) для построения связей EXTENDS/OVERRIDES | — | | `EXTENSION_BASE_PROJECT_ID` | Зарегистрированный `PROJECT_ID` базовой конфигурации. Нужен, когда идентификатор проекта отличается от отображаемого имени в `EXTENSION_BASE_PROJECT`. Разрешается только в текущем `MCP_NAMESPACE`. Если не задан, идентификатором считается само значение `EXTENSION_BASE_PROJECT` | — | | `EXTENSION_APPLY_ORDER` | Порядок применения слоя расширения при резолве эффективной сущности | `1` | {% hint style="info" %} **Сравнение расширения с базой: `compare_graph_scope(project_id=<расширение>, extension_ref=<имя слоя>)`.** База — проект из `EXTENSION_BASE_PROJECT_ID` (или `EXTENSION_BASE_PROJECT`) в том же `MCP_NAMESPACE` и той же Neo4j. Инструмент находит её по данным в базе, а не только по реестру процесса: вызов работает независимо от того, вызывались ли до него `list_graph_projects` или `get_graph_project_status`, и на холодной пересборке, когда контейнер расширения закончил индексацию раньше базового, — база подхватывается, как только её узлы появились в графе. `project_not_accessible` с `argument=extension_ref` теперь означает ровно одно из: базы с таким `project_id` в этом namespace нет, её индексация ещё не записала ни одного узла, либо она зарегистрирована в статусе, который не обслуживает чтение; ответ называет ожидаемый `project_id` и namespace. Базовая сторона сравнения — только те объекты базы, которые расширение заимствует или переопределяет (рёбра `EXTENDS`/`OVERRIDES`), и связи, выходящие из них; вся остальная база в сравнении не участвует и как «удалённое» не показывается. **В режиме каталога расширений** (`EXTENSION_CATALOG_ENABLED=true`, база и расширения — слои одного проекта) `EXTENSION_BASE_PROJECT` не нужен: `compare_graph_scope(project_id=<проект>, extension_ref=<имя слоя>)` сравнивает слой с базовым слоем того же проекта по тем же рёбрам, а сторона слоя читается только по слою (образы от 21.09.2026). Если `EXTENSION_BASE_PROJECT` указывает на сам проект, это то же сравнение. Имя, которого нет среди слоёв проекта, отклоняется с `invalid_argument` и перечнем слоёв, которые проект держит. **Связи `EXTENDS`/`OVERRIDES` строятся при каждом старте контейнера расширения** — сначала строятся новые (со штампом прогона), и только потом удаляются рёбра прошлого прогона, которых текущее сопоставление не дало. Пересоздание контейнера, упавшая или прерванная по таймауту сборка не оставляют граф без связей слоя: прежние рёбра живут, пока не записаны новые. В журнале сборки: `Extension relationships built for layer … stale edges of the previous run removed: EXTENDS=N, OVERRIDES=M`. Связи переопределяющей процедуры сопоставляются со связями переопределённой, даже если их имена различаются (`Расш1_ПередЗаписью` над `ПередЗаписью`). На общей Neo4j с базой и расширением время ответа определяют индексы scope (см. врезку про `GRAPH_SCOPE_ENFORCED`): после обновления на образ от 18.09 дайте серверу один старт, чтобы их создать. Расширение, у которого ни один объект не связан с базой, получает предупреждение — это признак того, что слой не был построен (проверьте `EXTENSION_BASE_PROJECT` на инстансе расширения и общий namespace). {% endhint %} ### Массовая загрузка расширений из каталога Один прогон с `EXTENSION_NAME` загружает **одно** расширение. В 1С:ERP к конфигурации может быть применено до 200 расширений-патчей, и настраивать 200 прогонов вручную — не рабочий процесс. Поэтому прогон можно направить на каталог массовой выгрузки (`/DumpConfigToFiles … -AllExtensions`): каждая найденная в нём выгрузка расширения становится слоем одного и того же проекта. | Переменная | Описание | По умолчанию | | --------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- | | `EXTENSION_CATALOG_ENABLED` | Распознавать выгрузки расширений внутри каталога и загружать их слоями за один прогон | `false` | | `EXTENSIONS_PATH` | Где внутри контейнера лежат выгрузки расширений. Пусто — подкаталоги каталога выгрузки (`CODE_EXPORT_PATH`, затем `METADATA_FILES`), куда их кладёт массовая выгрузка. В поставляемых compose-профилях — `/app/extensions` | *(пусто)* | | `EXTENSIONS_HOST_PATH` | Переменная compose-файла, а не сервера: каталог расширений на хосте, который монтируется только на чтение в `/app/extensions` | *(зависит от профиля)* | | `EXTENSION_ORDER_MANIFEST` | JSON со списком имён расширений в порядке применения (список или объект с полем `order`). Пусто — ищется `extensions_order.json` в каталоге | *(пусто)* | | `EXTENSION_CATALOG_SYNC` | Синхронизировать набор слоёв с каталогом: исчезнувшая выгрузка — слой удаляется, новая — добавляется, изменённая — обновляется, неизменённая — не переингестируется. Базовый слой не удаляется никогда | `true` | {% hint style="info" %} **Порядок применения в пакетном режиме определяется в два уровня.** Между группами — по назначению расширения из его собственной выгрузки (Исправление → Адаптация → Дополнение, как применяет платформа); это не настройка оператора. Внутри группы — по манифесту, а без манифеста расширения одного назначения упорядочиваются по имени, и прогон явно сообщает, что внутригрупповой порядок **предположен**. В 1C:EDT элемент `configurationExtensionPurpose` в `Configuration.mdo` не пишется, когда назначение — значение по умолчанию «Исправление» (`Patch`). Каталог всё равно принимает такой слой: проект с nature `V8ExtensionNature` или с элементом `namePrefix` считается расширением `Patch`. Соседняя база с `V8ConfigurationNature` (или без этих признаков) в каталог не попадает. В выгрузке Конфигуратора признак по-прежнему обязателен: без `ConfigurationExtensionPurpose` каталог не считает папку расширением. {% endhint %} {% hint style="warning" %} Режим выключен по умолчанию: распознавание читает каталоги, и проект, который загружает одно расширение объявленным способом, должен продолжать делать ровно это. Одиночный ручной режим (`EXTENSION_NAME` на прогон) сохраняется. {% endhint %} {% hint style="warning" %} **Имя расширения не должно совпадать с `PROJECT_NAME`.** Слой основной конфигурации называется по `PROJECT_NAME`, слой расширения — по имени расширения. Образы до 04.10.2026 при таком совпадении при каждом старте на существующих данных удаляли модули одного слоя загрузкой другого: в графе оставался код только одного из них. В журнале это видно как `BSL resume: N module(s) of layer <имя> are no longer in the export`. С образов от 04.10.2026 модули основной конфигурации и одноимённого расширения хранятся раздельно и друг друга не удаляют. Удаление такого расширения из каталога не удаляет проект основной конфигурации. Прогон каталога пишет предупреждение. Но различаются слои всё равно не везде: у них общий узел проекта, сравнение расширения с основной конфигурацией читает оба слоя, модули и права ролей привязываются к одноимённым объектам обоих слоёв. Задайте `PROJECT_NAME`, отличный от имён расширений. Смена `PROJECT_NAME` у построенного графа требует его полной пересборки (см. [Полный перезапуск](https://docs.onerpa.ru/mcp-servery-1c/servery/graph-metadata-search/pages/fxDyUR26bPIaXlZ63emw#полный-перезапуск)). {% endhint %} Расширение в 1С не применяется к другому расширению, поэтому слои по-прежнему прикрепляются только к базовому (`EXTENDS`/`OVERRIDES` ведут от расширения к базе), связей «расширение → расширение» нет. Объекты базы и расширений с одним именем (типичный случай — общий `Report.txt` у нескольких выгрузок) хранятся отдельными узлами: в ключ MERGE входит `config_name`. Уже слитые узлы при старте нового образа разводятся по слоям, эмбеддинги копируются, полная платная переиндексация не нужна. Если после пересоздания `mcp-app` граф в Neo4j уже есть, а опубликованного поколения нет, `register_graph_project` на тот же `project_id` делает проект доступным для чтения (`ready`) без выдуманного поколения. Инструменты отвечают из этих данных. {% hint style="info" %} **Прогон каталога и лейн форм работают одновременно и не мешают друг другу.** Идентичность и каталог загружаемого слоя (`PROJECT_NAME`, `EXTENSION_NAME`, `CODE_EXPORT_PATH` и т. д.) подменяются только для потока каталога; лейны `form_xml`/`ordinary_form_xml`, читающие базовую выгрузку на своих потоках, видят настройки инсталляции. До образа от 18.09 подмена была общей для процесса, и на холодной сборке (или при изменившейся выгрузке расширения) лейн форм читал выгрузку расширения вместо базы — формы базы оставались без элементов при успешном отчёте о прогоне. {% endhint %} #### Каталог расширений — отдельное монтирование В workspace 1C:EDT база и её расширения лежат соседними проектами, то есть каталог расширений — это родитель каталога базы: ``` C:/Work/edt-workspace-zup/ <- EXTENSIONS_HOST_PATH -> /app/extensions:ro ZUP/ <- CODE_EXPORT_PATH / METADATA_FILES РасширениеА/ РасширениeБ/ ... ``` Двумя разными путями одно монтирование не выражается, поэтому каталогу расширений нужен свой том: * **не указывайте `CODE_EXPORT_PATH` на родителя** — база вместе со всеми расширениями прочитается как одна конфигурация; * **не занимайте под расширения каталог отчёта `/app/metadata`** — это чужой том; расширения монтируются отдельно. Монтируется каталог на чтение: прогон читает выгрузки и пишет в Neo4j, а синтезированный отчёт каждого слоя публикуется в `GENERATED_REPORT_DIRECTORY`, а не обратно в выгрузку. Смонтированный каталог сам по себе ничего не меняет: читается он только при `EXTENSION_CATALOG_ENABLED=true`. ### Профиль инструментов и scope | Переменная | Описание | По умолчанию | | ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `MCP_TOOL_PROFILE` | Какой набор инструментов публикуется: `admin` (всё) или `read-only` (без управления проектами) | `admin` | | `MCP_NAMESPACE` | Namespace установки, в котором регистрируются графовые проекты | `default` | | `ADMIN_TOKEN` | Токен для административных HTTP-эндпоинтов веб-интерфейса | — | | `GRAPH_SCOPE_ENFORCED` | Записан ли scope в самой базе. Включать только на базе, пересобранной по новой схеме идентификаторов: данные, загруженные раньше, свойств scope не содержат. Вместе с миграционным окном задаёт строгость `project_id` — см. врезку ниже | `false` | | `GRAPH_SCOPE_MIGRATION_WINDOW` | Окно миграции: вызов без `project_id` обслуживается единственным зарегистрированным проектом namespace, ответ помечается `deprecated` | `false` | | `GRAPH_ONLY` | Режим только чтения графа — без загрузки и обогащения данных | `false` | {% hint style="info" %} **Строгость `project_id` определяется состоянием базы, а не только флагом контракта.** Пока `GRAPH_SCOPE_ENFORCED=false`, в графе нет ни одного свойства scope и ни один путь чтения им не ограничен: вызов с `project_id` и вызов без него читают одни и те же строки. Поэтому вызов без `project_id` не отклоняется, а обслуживается — единственным доступным проектом, а при пустом реестре legacy-scope из `PROJECT_NAME` (или ``, если и он не задан). Ответ помечается `deprecated`. Предупреждение об отсутствии ограничения результатов проектом возвращают `list_graph_capabilities` и `health_graph` в `installation_notices`. Отклоняется только вызов без `project_id` в namespace, где доступно несколько проектов: там выбор реальный, и его показывает `list_graph_projects`. При `GRAPH_SCOPE_ENFORCED=true` и закрытом `GRAPH_SCOPE_MIGRATION_WINDOW=false` `project_id` строго обязателен. При открытом окне единственный проект временно подставляется с `deprecated`; несколько проектов всегда требуют явного выбора. Реестр графовых проектов живёт в памяти процесса и после рестарта пуст, поэтому свежий процесс на настройках по умолчанию читает граф без `project_id`, а не отказывает в доступе к данным, которые он всё равно не изолирует. После рестарта `configuration_root` собственного проекта установки (`PROJECT_NAME`) берётся из той же выгрузки, из которой его загружает старт: `METADATA_DIRECTORY`, иначе `CODE_EXPORT_PATH` (`METADATA_FILES`). Так происходит и при `GRAPH_SCOPE_ENFORCED=true`, поэтому для `refresh_graph_project(mode=full)` этот проект повторно регистрировать не нужно. Корень другого проекта, заданный через `register_graph_project`, в хранилище не записывается и живёт до рестарта процесса. После рестарта такой проект показывается с `configuration_root = `, и перед полной пересборкой его регистрируют снова с тем же `configuration_root`. При `GRAPH_SCOPE_ENFORCED=true` и закрытом окне миграции проект установки попадает в реестр и без записи в Neo4j: при трекере загрузки по умолчанию (`INGESTION_TRACKER_BACKEND=json`) — по документу координатора в `INGESTION_STATE_DIRECTORY` (с его `active_generation`), а с выключенным координатором (`INGESTION_COORDINATOR_ENABLED=false`, по умолчанию) — по данным в его scope. До 29.09.2026 в обоих случаях `list_graph_projects` был пуст, а `get_graph_project_status` отвечал `project_not_registered`, и в загружающем процессе, и после рестарта. При `GRAPH_SCOPE_ENFORCED=true` сервер на старте создаёт по индексу `(mcp_namespace, project_id)` на каждую метку проекта (`CREATE INDEX IF NOT EXISTS`): без него чтение, ограниченное только scope — все чтения целых меток, включая `compare_graph_scope`, — шло полным сканированием метки по всей общей базе (композитные индексы Neo4j используются только при предикатах на все их свойства). Существующая инсталляция получает индексы при следующем старте; заполнение идёт в фоне и на большом графе занимает минуты. {% endhint %} ### Лимиты ответов графовых инструментов | Переменная | Описание | По умолчанию | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------ | | `GRAPH_MAX_ITEMS` | Жёсткий предел элементов в ответе (`max_items` не может его превысить) | `200` | | `GRAPH_MAX_NODES` | Предел узлов в компактном графовом ответе | `500` | | `GRAPH_MAX_EDGES` | Предел связей в компактном графовом ответе | `1000` | | `GRAPH_MAX_CHARS` | Предел размера ответа в символах | `60000` | | `GRAPH_TOOL_TIMEOUT_SECONDS` | Бюджет времени одного вызова инструмента, в секундах. По истечении сервер отвечает типизированной ошибкой `timeout`; начатая работа при этом не прерывается. Значение по умолчанию оставляет запас до типичного 30-секундного лимита MCP-клиента. Действует на все инструменты, включая административные. Долгие административные операции — `refresh_graph_project` и (образы от 04.10.2026) `refresh_extension_layers` — сразу отвечают `accepted` и выполняются на сервере, поднимать бюджет ради них не нужно. `0` — без ограничения | `25` | | `GRAPH_ENTITY_GROUP_LIMIT` | Предел размера группы связей в `explain_graph_entity` | `25` | | `GRAPH_ENTITY_MAX_CANDIDATES` | Предел кандидатов при резолве сущности | `20` | | `GRAPH_PATH_MAX_DEPTH` | Максимальная глубина поиска путей (`find_graph_path`) | `6` | | `GRAPH_PATH_MAX_PATHS` | Количество возвращаемых кратчайших путей | `3` | | `GRAPH_PATH_FANOUT_LIMIT` | Предел ветвления на шаг при поиске путей | `200` | | `GRAPH_PATH_MAX_FRONTIER` | Предел фронта обхода при поиске путей | `2000` | | `GRAPH_IMPACT_MAX_DEPTH` | Максимальная глубина `affected_subgraph` / `trace_impact` | `4` | | `GRAPH_IMPACT_MAX_PATHS` | Предел путей-обоснований в анализе влияния | `500` | | `GRAPH_IMPACT_FANOUT_LIMIT` | Предел ветвления на шаг в анализе влияния | `200` | | `GRAPH_COMPARISON_MAX_ENTITIES` | Предел сущностей при сравнении scope (`compare_graph_scope`) | `10000` | | `GRAPH_SYNOPSIS_MAX_ITEMS` | Предел элементов в кратком обзоре ответа | `5` | ### Тонкая настройка поиска и ранжирования Значения подобраны под типовые конфигурации; менять их стоит только по результатам замеров. | Переменная | Описание | По умолчанию | | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------- | | `VECTOR_RETRIEVAL_STRATEGY` | Как фильтруется векторная выборка: `auto` — предфильтрация внутри индекса, если сервер и индекс это поддерживают (Neo4j 2026.01+), иначе ограниченный overfetch; `native_prefilter` — требовать предфильтрацию (при невозможности запрос обслуживается overfetch, а понижение пишется в журнал); `bounded_overfetch` — прежнее поведение (откат). На Neo4j 2026.01 и новее индекс читается предложением Cypher 25 `SEARCH` и при overfetch (фильтр тогда применяется после выборки, как раньше), на 5.x — процедурой `db.index.vector.queryNodes`. При `bounded_overfetch` индекс читается этой процедурой на любой версии, и Neo4j начиная с 2026.04 отвечает на каждый такой запрос предупреждением `01N01` (DEPRECATION). Образы от 13.10.2026; раньше процедурой читались все запросы без предфильтрации, в том числе поиск по фрагментам описаний, и Neo4j 2026.04+ писал это предупреждение на каждый поиск | `auto` | | `VECTOR_OVERFETCH_MULTIPLIER` | Множитель выборки векторного маршрута | `4` | | `VECTOR_OVERFETCH_HARD_CAP` | Жёсткий предел векторной выборки | `1000` | | `UNFILTERED_OVERSAMPLING_MULTIPLIER` | Множитель выборки без фильтра | `3` | | `FILTERED_OVERSAMPLING_MULTIPLIER` | Множитель выборки при заданном фильтре | `10` | | `FILTERED_OVERSAMPLING_RETRY_MULTIPLIER` | Во сколько раз расширяется выборка на повторе, если фильтр отсёк слишком много | `3` | | `FILTERED_OVERSAMPLING_MAX_RETRIES` | Максимум таких повторов | `3` | | `MAX_CANDIDATE_POOL` | Предел общего пула кандидатов до ранжирования | `200` | | `RRF_K` | Константа reciprocal rank fusion | `60` | | `CODE_SEARCH_RRF_W_VEC` / `CODE_SEARCH_RRF_W_FT` | Веса векторной и полнотекстовой дорожек при поиске по коду | `0.6` / `0.4` | | `BUSINESS_SEARCH_RRF_W_VEC` / `BUSINESS_SEARCH_RRF_W_FT` | То же для поиска по бизнес-описаниям | `0.6` / `0.4` | | `ATTRIBUTE_SEARCH_RRF_WEIGHT` | Вес маршрута поиска по реквизитам | `0.3` | | `ENABLE_ATTRIBUTE_SEARCH` | Искать по реквизитам объектов | `true` | | `CODE_SEARCH_MAX_PER_MODULE` | Сколько процедур одного модуля может попасть в ответ `search_code`. `1` — каждый результат из своего модуля: больше разных модулей, но нужная процедура нередко отсекается, если выше неё в выдаче стоит соседняя процедура того же модуля. В образах до 29.09.2026 по умолчанию было `1` | `3` | | `CODE_SEARCH_DEDUP_OVERFETCH` | Запас выборки на дедупликацию по модулям | `10` | | `CHANNEL_ADMISSION_MIN_SCORE` | Минимальная средняя оценка в топ-K, при которой маршрут допускается в общий пул. `0.0` отключает отсечение | `0.1` | | `CHANNEL_ADMISSION_TOP_K_CHECK` | Сколько верхних результатов маршрута усредняется для этой проверки | `3` | | `SEMANTIC_GATING_MIN_SCORE_VECTOR` | Порог семантического маршрута до реранка | `0.3` | | `SEMANTIC_GATING_MIN_SCORE_RERANKED` | Порог после реранка | `0.5` | | `SEMANTIC_FALLBACK_MIN_RESULTS` | Сколько результатов должно остаться, чтобы не включать резервный маршрут | `3` | | `SEMANTIC_MERGE_W_DESCRIPTION` / `SEMANTIC_MERGE_W_BUSINESS` / `SEMANTIC_MERGE_W_TRANSLITERATED` | Веса описательного, бизнес- и транслитерированного представлений при слиянии | `1.0` / `1.0` / `0.7` | | `MIXED_MERGE_W_SEMANTIC` / `MIXED_MERGE_W_LEXICAL` / `MIXED_MERGE_W_STRUCTURAL` | Веса семантического, лексического и структурного маршрутов | `1.0` / `0.4` / `1.0` | | `DESCRIPTION_FT_BOOST_NAME`, `DESCRIPTION_FT_BOOST_SYNONYM`, `DESCRIPTION_FT_BOOST_COMMENT`, `DESCRIPTION_FT_BOOST_DESCRIPTION`, `DESCRIPTION_FT_BOOST_HELP` | Веса полей в полнотекстовом маршруте | `4.0` / `3.0` / `1.5` / `1.0` / `1.0` | | `CHUNK_EXCERPTS_PER_OBJECT` | Сколько фрагментов одного объекта попадает в ответ | `3` | | `CHUNK_OBJECT_DUAL_HIT_BOOST` | Прибавка к оценке, если объект найден и на уровне объекта, и на уровне фрагментов. `0.0` отключает | `0.05` | | `CHUNK_EVIDENCE_WEIGHT` | Прибавка за каждый дополнительный совпавший фрагмент объекта | `0.02` | | `MMR_LAMBDA` | Баланс релевантности и разнообразия (1.0 — только релевантность) | `0.7` | | `MMR_USE_EMBEDDINGS` | Считать разнообразие по эмбеддингам | `true` | | `POST_MERGE_RERANK_TOP_N` | Сколько верхних результатов уходит в реранк после слияния | `20` | | `RERANK_MAX_CANDIDATES` | Максимум кандидатов в одном вызове реранкера; хвост сохраняет исходный порядок | `200` | | `PROJECT_AFFINITY_BOOST` | Прибавка результатам «своего» проекта | `0.0` | | `ENABLE_GRAPH_EXPANSION` | Расширять выдачу соседями по графу | `true` | | `GRAPH_EXPANSION_TOP_N` | Сколько результатов расширяется соседями | `3` | | `GRAPH_EXPANSION_DECAY` | Затухание оценки на шаг расширения | `0.5` | ### Ответы с участием LLM (`answer_metadata_question`) | Переменная | Описание | По умолчанию | | ----------------- | ------------------------------------------- | ------------ | | `QA_MAX_OBJECTS` | Сколько объектов попадает в контекст ответа | `5` | | `QA_MAX_TOKENS` | Предел токенов ответа | `4000` | | `QA_TEMPERATURE` | Температура модели | `0.3` | | `QA_INCLUDE_CODE` | Включать код в контекст | `true` | | `SUMMARIZE` | Суммаризировать результаты поиска через LLM | `false` | ### Плагины | Переменная | Описание | По умолчанию | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------------ | | `GRAPH_PLUGINS_ENABLED` | Загружать Python-плагины из каталога плагинов | `true` | | `GRAPH_PLUGINS_DIRECTORY` | Каталог плагинов; относительный путь считается от рабочего каталога `/app` | `plugins` | | `GRAPH_PLUGIN_STRICT_BUILD` | Останавливать построение нового поколения при ошибке derived-state hook вместо пропуска проблемной единицы | `false` | | `GRAPH_PLUGIN_HOOK_TIMEOUT_SECONDS` | Бюджет времени одного hook; `0` отключает контроль | `5.0` | Для контейнера обычно монтируют каталог хоста в `/app/plugins`. `list_plugins` доступен для диагностики в обоих профилях, а изменяющий состояние `reload_plugins(operation_id)` — только в профиле `admin`. После перезагрузки call-scoped hooks действуют со следующего вызова, а derived-state hooks — со следующего построения индекса. Плагин — **один Python-файл** в каталоге плагинов. Объявлены восемь hooks: `on_startup`, `on_request`, `on_result`, `on_search_candidates` (в рамках вызова) и `on_source_unit`, `on_metadata_object`, `on_routine`, `on_embedding_document` (формируют граф, полнотекстовый и векторный маршруты) — плюс три таблицы: `ALIASES`, `TOOL_PRESETS` и `CYPHER_TEMPLATES` (дополнительные read-only Cypher-шаблоны для `run_graph_cypher_template`). Полный контракт лежит в образе: `/app/plugin_api.py`, `/app/plugins/AGENTS.md`, `/app/plugins/example.py`. ```powershell # Проверить плагин без Neo4j, метаданных, поколения и лицензии docker run --rm -v "E:/plugins/mcp_graph/10-facts.py:/tmp/my_plugin.py" ` comol/1c_graph_metadata:latest python run.py plugin-dry-run /tmp/my_plugin.py ``` {% hint style="warning" %} Без `GRAPH_PLUGINS_ENABLED=true` каталог не читается вообще, а `reload_plugins` отвечает, что подсистема отключена. {% endhint %} Правка любого derived-state hook делает сохранённое состояние проекта устаревшим и вызывает пересборку; call-scoped hooks и таблицы обходятся перезагрузкой. Подробно: [Доработка MCP: система плагинов](/mcp-servery-1c/sistema-pluginov.md) и [справочник хуков Graph Metadata Search](/mcp-servery-1c/sistema-pluginov/spravochnik-hukov.md#graph-metadata-search). ### Поколения графа и загрузка данных Модель поколений — координатор, привязка векторных лейнов к поколению, готовность лейнов в `health_graph` и `refresh_graph_project` — собирается из трёх переключателей, каждый из которых по умолчанию выключен: | Переключатель | Что появляется при `true` | Что видно при `false` | | ------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `INGESTION_COORDINATOR_ENABLED` | Записи фаз загрузки, `active_generation` / `staging_generation`, задача `ingestion_promote`, привязка `vector_lane_binding`, готовность лейнов (`readiness.lanes`) в `health_graph` и `get_graph_project_status` | Поколений нет: `active_generation = null`, `readiness.state = unknown`, лейны `null`; задача `vector_lane_binding` помечена `skipped` с причиной `INGESTION_COORDINATOR_ENABLED=false`. Поиск при этом работает — он отвечает из графа, а не из поколения | | `GRAPH_SCOPE_ENFORCED` | Scope проекта в самой базе — staging-изоляция, без которой `refresh_graph_project` с `mode=full` отвечает `data_store_unavailable`; scope нужен и манифесту исходников | Одна инсталляция — один граф; `refresh_graph_project` недоступен | | `SOURCE_UNIT_MANIFEST_ENABLED` | Инкрементальный `refresh_graph_project` (`mode=incremental`); без манифеста он отвечает `refresh_capability_unavailable` | Пересборка только полная | Граф, загруженный без координатора (или томом Neo4j, перенесённым с другой инсталляции), в `get_graph_project_status` показывается как `ingestion_state = inherited`: данные читаемы, все инструменты чтения отвечают, но записей фаз и поколения у него нет. `list_graph_projects` — облегчённый список и хранилище координатора для каждого проекта не читает; `ingestion_state` в нём берётся, по убыванию актуальности, из живого загрузчика этого процесса (для проекта, который процесс индексирует сам, — точное `running`/`idle`/`failed` без задержки), из ответа последнего `get_graph_project_status`, из записи, по которой проект был найден после рестарта, а при известном `active_generation` вместо `never_run` показывается `idle`. `never_run` в списке остаётся только у проекта без поколения, о котором процесс ничего не знает. Чтобы отличить такой проект от графа без координатора, список один раз на проект сам спрашивает хранилище координатора и запоминает ответ, поэтому `inherited` виден с первого вызова, а не после детального. Во вложенном блоке `ingestion` детального статуса `state` совпадает с `ingestion_state`. Если координатор выключен, `ingestion_state_reason` так и говорит: граф записан без координатора, поколений и записей фаз у него нет. Ни `inherited`, ни `never_run` при рабочем поиске не означают «граф пуст, переиндексируйте». | Переменная | Описание | По умолчанию | | ------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | | `INGESTION_COORDINATOR_ENABLED` | Координатор загрузки с фазами, лизом и чекпоинтами. Включать осознанно: первый прогон под координатором записывает документ состояния проекта, и фаза, записанная как завершённая, повторно не входится. Если основная задача загрузки упала, `ingestion_promote` дожидается остальных, отпускает лиз, не публикует поколение и завершается ошибкой с перечнем упавших задач и их причин (`get_indexing_status`, `GET /status`); staging-поколение сохраняется, и следующий прогон — тик `GRAPH_REFRESH_INTERVAL_SEC`, перезапуск — берёт лиз заново и продолжает его. До 07.10.2026 лиз в этом случае держался, пока жив процесс, и другие писатели проекта получали отказ | `false` | | `INGESTION_LEASE_TTL_SECONDS` | Время жизни лиза загрузчика. Живой писатель продлевает лиз heartbeat'ом каждые TTL/3, штатная остановка (SIGTERM) освобождает лиз сразу, поэтому срок платит только аварийное завершение: при большом TTL контейнер, убитый по OOM, видел после перезапуска живой лиз мёртвого писателя и помечал задачи индексации как skipped | `120` | | `INGESTION_CHECKPOINT_BATCH_SIZE` | Размер пакета между чекпоинтами | `500` | | `INGESTION_CHECKPOINT_INTERVAL_SECONDS` | Интервал записи чекпоинтов | `30` | | `EMBEDDING_CARRY_BATCH_MODULES` | Сколько изменённых модулей одновременно проходят цикл «снять эмбеддинги процедур → удалить → загрузить → восстановить» при инкрементальном обновлении. Это не чекпоинт: на время пачки вектор каждой снятой процедуры держится в памяти, поэтому значение намеренно меньше размера чекпоинта — иначе релиз, затронувший тысячи модулей, приводит к OOM | `100` | | `INGESTION_TRACKER_BACKEND` | Где хранится состояние загрузки: `json` (без БД) или `neo4j` | `json` | | `INGESTION_STATE_DIRECTORY` | Каталог для состояния при бэкенде `json` | — | | `INDEXING_STATE_PATH` | Путь к JSON-состоянию фоновых задач старта. По нему работает защита от цикла перезапусков: если три старта подряд находят задачу предыдущего прогона, оставшуюся в работе, все задачи индексации помечаются `skipped` с причиной `restart-loop protection`, а `get_indexing_status` и `/search/index-status` отдают блок `restart_loop_protection` и `warning`. Штатная остановка контейнера (`docker stop`, `docker compose up -d` после правки конфигурации — SIGTERM) записывается в это состояние как остановка по запросу и крашем не считается. Задачи, которые не начались из-за упавшей предпосылки, крашем тоже не считаются. Считаются обрывы без сигнала: SIGKILL (OOM-kill, `docker kill`), падение процесса, потеря питания. Сам процесс причину не видит, поэтому журнал её не называет; OOM-kill видно в журнале ядра (`dmesg`, строка `oom-kill`) и в `docker inspect` (`State.OOMKilled`). Сбросить счётчик — удалить файл и перезапустить | `/data/.indexing_state.json` | | `GRAPH_STAGING_VALIDATION_ENABLED` | Проверять инварианты staging-поколения перед promote | `false` | | `GRAPH_STAGING_VALIDATION_MODE` | Что делает нарушение: `blocking` (отказ в promote) или `report` (promote с отчётом) | `blocking` | | `GRAPH_STAGING_VALIDATION_SAMPLE_LIMIT` | Количество примеров нарушений в отчёте | `5` | | `GRAPH_STAGING_COVERAGE_EXPECTATIONS` | Ожидания по покрытию для валидации staging | — | | `GRAPH_DELETE_VISIBILITY_ENABLED` | Контроль видимости удалённых сущностей между поколениями | `true` | | `GRAPH_DELETE_VISIBILITY_MODE` | Режим контроля видимости удалений | `blocking` | | `GRAPH_GENERATION_FENCE_ENABLED` | Фенс поколений — защита от чтения из устаревшего поколения | `true` | | `GRAPH_GENERATION_FENCE_ATTEMPTS` | Количество повторов при срабатывании фенса | `4` | | `GRAPH_GENERATION_FENCE_WAIT_S` | Публикация поколения (`refresh_graph_project` с `mode=full`, промоушен под координатором) идёт пачками по 2000 узлов, каждая — своя транзакция, и объявляет о себе до первой пачки. Чтение, попавшее на объявленную публикацию, ждёт её окончания не дольше этого времени вместо того, чтобы вернуть проект, в котором ещё нет ни старого, ни нового поколения целиком (образы от 22.09.2026; раньше такое чтение могло вернуть пустой или частичный ответ). По истечении — ошибка `generation_fence_exhausted` с просьбой повторить вызов | `120` | | `GRAPH_GENERATION_FENCE_STALE_S` | Через сколько секунд объявленная, но не завершённая публикация (процесс погиб между пачками) считается брошенной: чтения перестают ждать и идут по данным как есть, в журнале — предупреждение | `900` | | `REFERENCE_EVIDENCE_ENABLED` | Сохранять evidence для `explain_graph_evidence` / `explain_path` | `false` | | `REFERENCE_EVIDENCE_RETENTION_DAYS` | Срок хранения evidence в днях | `90` | | `REFERENCE_EVIDENCE_RETENTION_GENERATIONS` | Сколько поколений evidence хранить | `3` | | `SOURCE_UNIT_MANIFEST_ENABLED` | Манифест единиц исходников для инкрементальной пересборки (`refresh_graph_project` с `mode=incremental`). Манифест ключует каждую единицу по scope проекта, поэтому действует только при `GRAPH_SCOPE_ENFORCED=true`; без него сервер пишет в журнал предупреждение `SOURCE_UNIT_MANIFEST_ENABLED is set but this Indexer has no project scope` и лейны обходят выгрузку сами, как раньше | `false` | | `SOURCE_UNIT_MANIFEST_DIRECTORY` | Каталог хранения манифеста | — | | `SOURCE_UNIT_IGNORE_PATTERNS` | Шаблоны исключения файлов из манифеста | — | | `SOURCE_UNIT_SCAN_PREFIX_BYTES` | Сколько байт файла читается при сканировании | `4096` | | `SOURCE_FORMAT_ADAPTERS_ENABLED` | Адаптеры форматов выгрузки (Конфигуратор / EDT) | `false` | | `SOURCE_FORMAT` | Явное указание формата выгрузки | *(авто)* | ### Дополнительные | Переменная | Описание | По умолчанию | | ----------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- | | `MCP_HOST` | Хост MCP-сервера | `0.0.0.0` | | `MCP_PORT` | Порт MCP | `8006` | | `MCP_PATH` | Совместимое поле конфигурации; текущие точки запуска его не применяют, MCP-эндпоинт фиксирован на `/mcp` | `/mcp` | | `MCP_USE_SSE` | SSE транспорт (для legacy клиентов) | `false` | | `FASTMCP_STATELESS_HTTP` | Не хранить серверную сессию в режиме `streamable-http` | `true` | | `FASTMCP_JSON_RESPONSE` | Отвечать на POST обычным JSON вместо SSE-потока; для совместимого stateful-режима задайте обе переменные `false` | `true` | | `NEO4J_DATABASE` | Имя базы Neo4j | `neo4j` | | `NEO4J_PARALLEL_WRITE_WORKERS` | Количество параллельных воркеров записи в Neo4j. Допустимый диапазон `1..16`, значение вне диапазона отклоняется при старте. Значения выше `1` приводили к взаимным блокировкам BSL-писателей на `NODE_RELATIONSHIP_GROUP_DELETE` при первой индексации — повышайте только по результатам замеров на своих данных | `1` | | `NEO4J_WRITE_BATCH_SIZE` | Размер пакета записи в Neo4j | `1000` | | `NEO4J_WRITE_RETRIES` | Количество повторов при ошибке записи | `5` | | `NEO4J_WRITE_RETRY_DELAY_S` | Пауза перед первым повтором; далее удваивается | `1.0` | | `NEO4J_WRITE_RETRY_MAX_DELAY_S` | Предел паузы между повторами | `30.0` | | `NEO4J_WRITE_TRANSACTION_TIMEOUT_S` | Предел времени одной транзакции записи при индексации (серверный таймаут). Ожидание блокировки в Neo4j само по себе не ограничено, поэтому запись, вставшая за транзакцией, которую никто не завершает, раньше ждала вечно и молча; теперь она завершается ошибкой с именем операции (`LockClientStopped` / `TransactionTimedOut`). Все записи индексации — ограниченные пакеты, очистки и проходы; полчаса не достигает ни одна из них. `0` — без предела | `1800.0` | | `NEO4J_READ_TRANSACTION_TIMEOUT_S` | Предел времени одного запроса чтения к Neo4j (серверный таймаут транзакции). Бюджет вызова инструмента (`GRAPH_TOOL_TIMEOUT_SECONDS`) обычно истекает раньше, и клиент получает ошибку `timeout`; этот предел нужен, чтобы Neo4j сам прервал брошенный тяжёлый запрос, а не держал соединение из пула. Таймаут чтения не вызывает переподключения. Действует на запросы инструментов и веб-поиска; запись, индексацию и чтения фоновых дорожек (например, выборку процедур для эмбеддингов) не затрагивает — их результата ждёт только сама дорожка. `0` — без предела | `30.0` | | `NEO4J_WRITE_STALL_WARNING_S` | Как часто в журнал пишется предупреждение о транзакции записи, которая всё ещё выполняется: `Write op=<операция> still running after N s`, с запросом `SHOW TRANSACTIONS`, который показывает, чью блокировку она ждёт. `0` — выключить | `60.0` | | `NEO4J_EXPECTED_PAGECACHE_MB` | Ожидаемый размер page cache сервера Neo4j (МиБ). При старте сравнивается с фактическим и при меньшем значении пишется предупреждение. Никогда не применяется принудительно: если настройку не удалось прочитать, проверка молча считается успешной | — | | `PROJECT_NAME` | Название проекта (для логов, интерфейса и мультипроектности) | `1C Metadata Project` | | `DEBUG` | Режим отладки — дополнительные логи | `false` | ## Переменные Docker Compose и Neo4j Эти имена читает `docker-compose.yml`; под тем же именем они не обязательно передаются приложению MCP. | Переменная | Назначение | По умолчанию в поставляемом compose-профиле | | --------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------- | | `COMPOSE_PROJECT_NAME` | Имя проекта Compose | `graph_metadata_stable` | | `IMAGE_TAG` | Тег образа Graph Metadata Search | `light` | | `NEO4J_IMAGE` | Образ Neo4j | закреплённый digest в compose-файле | | `NEO4J_CONTAINER_NAME` | Имя контейнера Neo4j | `neo4j` | | `NEO4J_HTTP_PORT` / `NEO4J_BOLT_PORT` | Порты Neo4j на хосте | `7474` / `7687` | | `NEO4J_DATA_PATH` | Каталог данных Neo4j на хосте | `./data/neo4j_data` | | `NEO4J_HEAP_INITIAL_SIZE` / `NEO4J_HEAP_SIZE` | Начальный и максимальный heap Neo4j | `512m` / `2g` | | `NEO4J_PAGECACHE_SIZE` | Page cache Neo4j | `2g` | | `NEO4J_DEFAULT_CYPHER` | Язык запросов по умолчанию | `CYPHER_25` | | `NEO4J_MEMORY_LIMIT` | Лимит памяти контейнера Neo4j | `5G` | | `NEO4J_MEMORY_OVERHEAD` | Резерв поверх heap и page cache для проверки конфигурации | `1g` | | `MCP_CONTAINER_NAME` | Имя контейнера MCP | `1c_graph_metadata` | | `MCP_HOST_PORT` | Порт MCP на хосте | `8006` | | `METADATA_HOST_PATH` | Каталог готового отчёта для compose-файлов серверного репозитория | `./data/metadata_placeholder` | | `METADATA_FILES_HOST_PATH` | Designer XML / 1C:EDT на хосте | `./data/code_placeholder` в дистрибутиве | | `EXTENSIONS_HOST_PATH` | Каталог выгрузок расширений на хосте | значение `METADATA_FILES_HOST_PATH` | | `GRAPH_STATE_PATH` | Записываемое состояние MCP на хосте | `./data/mcp_state` | | `MCP_APP_MEMORY_LIMIT` | Лимит памяти контейнера MCP. До \~250 тыс. процедур достаточно `6G`, для 500 тыс. процедур и больше — `8G` (оценка по замеру на ЗУП, образы от 06.10.2026) | `6G` | ## Монтируемые тома ### MCP сервер | Хост | Контейнер | Назначение | | ------------------------ | -------------- | --------------------------------------------- | | `E:/1C_Export/Files` | `/app/code:ro` | Designer XML или проект 1C:EDT, только чтение | | `E:/bases/mcp_graph/app` | `/app/data` | Служебное состояние Graph Metadata Search | ### Neo4j | Хост | Контейнер | Назначение | | -------------------------- | --------- | ------------ | | `E:/bases/mcp_graph/neo4j` | `/data` | Данные Neo4j | ## Полный docker-compose.yml ```yaml version: '3.8' services: neo4j: image: neo4j@sha256:7d8d70f78c0c55830a162e6ae212799649b0cfd349dbfe413aab8124f7cabf1b container_name: neo4j restart: unless-stopped ports: - "7474:7474" - "7687:7687" environment: - NEO4J_AUTH=neo4j/password123 - NEO4J_server_memory_heap_initial__size=512m - NEO4J_server_memory_heap_max__size=2g - NEO4J_server_memory_pagecache_size=2g volumes: - E:/bases/mcp_graph/neo4j:/data deploy: resources: limits: memory: 5G healthcheck: test: ["CMD-SHELL", "wget --spider localhost:7474 || exit 1"] interval: 30s timeout: 10s retries: 5 mcp-app: image: comol/1c_graph_metadata:latest container_name: 1c_graph_metadata restart: unless-stopped ports: - "8006:8006" environment: # === Обязательные === - LICENSE_KEY=YOUR_LICENSE_KEY - NEO4J_URI=bolt://neo4j:7687 - NEO4J_USERNAME=neo4j - NEO4J_PASSWORD=password123 - RESET_DATABASE=false # === Embedding / LLM === - OPENAI_API_BASE=http://host.docker.internal:1234/v1 - OPENAI_API_KEY=lm-studio - OPENAI_MODEL=gpt-5 - EMBEDDING_MODEL=Qwen3-Embedding-4B # === Шаблонный режим === - TEMPLATE_MODE_ENABLED=true # === BSL-граф === - LOAD_BSL_SIGNATURES=true - ENABLE_ROUTINE_EMBEDDINGS=true # === XML-данные (опционально) === # - LOAD_FORMS_FROM_XML=true # - LOAD_EVENT_SUBSCRIPTIONS=true # - LOAD_PREDEFINED_VALUES=true # - LOAD_ROLE_RIGHTS=true # - LOAD_HELP_FROM_HTML=true # === Поиск === - ENABLE_BUSINESS_SEARCH=true # - ENABLE_METADATA_DESCRIPTION_EMBEDDING=true # === Проект === - MCP_PORT=8006 - PROJECT_NAME=МояКонфигурация - METADATA_SOURCE=xml - CODE_EXPORT_PATH=/app/code - GENERATED_REPORT_DIRECTORY=/app/data/generated-report volumes: - E:/1C_Export/Files:/app/code:ro - E:/bases/mcp_graph/app:/app/data deploy: resources: limits: memory: 6G depends_on: neo4j: condition: service_healthy ``` ## Пример: загрузка расширения Для загрузки расширения запустите отдельный экземпляр сервера с указанием `EXTENSION_NAME` и `EXTENSION_BASE_PROJECT`: ```yaml mcp-extension: image: comol/1c_graph_metadata:latest container_name: 1c_graph_metadata_ext environment: - LICENSE_KEY=YOUR_LICENSE_KEY - NEO4J_URI=bolt://neo4j:7687 - NEO4J_USERNAME=neo4j - NEO4J_PASSWORD=password123 - RESET_DATABASE=false - EXTENSION_NAME=МоёРасширение - EXTENSION_BASE_PROJECT=МояКонфигурация - OPENAI_API_BASE=http://host.docker.internal:1234/v1 - OPENAI_API_KEY=lm-studio - EMBEDDING_MODEL=Qwen3-Embedding-4B - METADATA_SOURCE=xml - CODE_EXPORT_PATH=/app/code - LOAD_BSL_SIGNATURES=true volumes: - E:/1C_Export_Extension/Files:/app/code:ro depends_on: neo4j: condition: service_healthy ``` После загрузки расширения через основной MCP-сервер станут доступны инструменты `compare_base_and_extension` и шаблонные операции для работы с расширениями. ## Пример: массовая загрузка всех расширений Если конфигурация выгружена вместе с расширениями (`/DumpConfigToFiles … -AllExtensions`), все они загружаются одним прогоном: ```yaml mcp-extensions: image: comol/1c_graph_metadata:latest container_name: 1c_graph_metadata_ext environment: - LICENSE_KEY=YOUR_LICENSE_KEY - NEO4J_URI=bolt://neo4j:7687 - NEO4J_USERNAME=neo4j - NEO4J_PASSWORD=password123 - METADATA_SOURCE=xml - CODE_EXPORT_PATH=/app/code - EXTENSION_BASE_PROJECT=МояКонфигурация - EXTENSION_CATALOG_ENABLED=true - EXTENSION_CATALOG_SYNC=true - LOAD_BSL_SIGNATURES=true volumes: - E:/1C_Export/Files:/app/code:ro depends_on: neo4j: condition: service_healthy ``` При `EXTENSION_CATALOG_SYNC=true` повторный прогон приводит граф в соответствие с каталогом: патч, вошедший в релиз конфигурации и исчезнувший из выгрузки, исчезает и из графа — вместо того чтобы отвечать за информационную базу, в которой его больше нет. Что прогон каталога читает для каждого слоя: метаданные (синтезированный отчёт), BSL-модули, управляемые и обычные формы и — при `LOAD_ROLE_RIGHTS=true` — права ролей из `Roles/*/Ext/Rights.xml` слоя (образы от 21.09.2026): `get_access_rights` отвечает по объектам, существующим только в расширении, и по ролям слоя; роль и объект сопоставляются внутри слоя. При `LOAD_DCS_TEMPLATES=true` слой читает и схемы компоновки собственных объектов расширения: `get_report_dcs_lineage` отвечает по отчёту, который добавляет расширение. В опубликованных образах до этой правки схемы слоя ещё не читаются. Схема заимствованного отчёта остаётся схемой базовой конфигурации. Слой, загруженный до обновления, сам не перечитывается: вызовите для него `refresh_extension_layers`. Подписки на события, предопределённые элементы и справка читаются пока только для базовой конфигурации. Слой и база держат раздельное состояние resume: маркеры графа вызовов (`bsl_call_graph@<слой>`) и права ролей проверяются по слою, поэтому рестарт контейнера в режиме каталога тёплый — граф вызовов базы не перестраивается. Если на момент обновления на образ от 21.09.2026 маркер хранит штамп слоя (был холодный прогон без последующего рестарта), граф вызовов базы перестроится один раз; а лейн эмбеддингов процедур стартует только после загрузки слоёв и в конце добирает процедуры, появившиеся за время его работы. Что повторный прогон **не** делает — это перечитывает слой, который в графе уже есть: он возвращает его как `untouched`, потому что ему неоткуда узнать, какие выгрузки изменились. Перевыгрузили расширение — вызовите [`refresh_extension_layers`](https://docs.onerpa.ru/mcp-servery-1c/servery/graph-metadata-search/pages/KHMAXKAJ2jh3jA42HO4o#управление-проектами-профиль-admin) для этого слоя (или без списка слоёв, для всех). Перезапуск контейнера этого не делает и делать не должен: иначе каждый старт перечитывал бы двести патчей. Исключение — слой, загрузка которого в прошлый раз не завершилась, например построение связей `EXTENDS`/`OVERRIDES` упало по таймауту транзакции. Такой слой следующий старт обрабатывает заново: догружает недостающее и строит связи, а в журнал пишет предупреждение, что предыдущая загрузка слоя не завершилась и слой обрабатывается заново. Признак готовности слоя пишется только после построения связей (образы от 04.10.2026). Слой, упавший на образе до этой правки, так не распознаётся — для него один раз вызовите `refresh_extension_layers`. ## Конфигурация Cursor ```json { "mcpServers": { "1c-graph-metadata-mcp": { "url": "http://localhost:8006/mcp", "connection_id": "1c_graph_service_001" } } } ```