1confdb-knw (confdb)

Экстрактор конфигурации 1С:Предприятие 8 в базу данных SQLite.

Назначение: распаковать бинарный файл конфигурации (.cf, .cfe, .epf) без технологической платформы 1С и разложить его содержимое в реляционную базу, пригодную для генерации кода 1С (LLM/RAG и скрипты).

Алгоритм распаковки портирован из проекта v8unpack (MIT, см. NOTICE.md) — только в одну сторону: распаковка и разбор, без обратной сборки.

Использование

:: установка в venv (один раз)
.venv\Scripts\python.exe -m pip install -e .

:: распаковка cf в базу данных (+ дерево распакованных файлов для отладки)
confdb extract file.cf --db out.db --dump _out\file

:: то же через confdb.bat
confdb.bat extract file.cf --db out.db

:: текстовый консольный интерфейс (меню с обновлением экрана:
:: извлечение, запросы, проверка СКД, запуск MCP-сервера
:: с одной базой, несколькими базами или несколькими группами баз, опции)
confdb-ui.bat

:: проверка корректности запросов СКД в готовой базе (пункт 5 в confdb-ui)
confdb check out.db

:: бенчмарк: подбор числа процессов под железо
:: (в confdb-ui — внутри пункта 3 «Опции извлечения»)
confdb bench file.cf

По умолчанию любая ошибка декодирования объекта прерывает извлечение. Флаг --skip-errors (в консольном интерфейсе — опция 6 «Пропускать ошибки объектов») пропускает сбойные объекты и продолжает разбор: каждый пропуск печатается с внутренней причиной, в конце — итоговое число. Дамп и база при этом неполные (пропущенные объекты и их подобъекты отсутствуют) — режим для больших конфигураций, где единичный сбойный объект не должен блокировать всю выгрузку.

Повторное извлечение одного и того же файла отсекается до распаковки: extract считает SHA-256 исходного .cf/.cfe/.epf (885 МБ — 1,7 с) и сравнивает его с отпечатком в таблице source целевой базы. Совпало — база уже содержит ровно эту конфигурацию, извлечение не запускается (код возврата 0), а сообщение называет отпечаток и дату сборки; --force пересобирает принудительно. Если база собрана из другого файла, печатается предупреждение о перезаписи. Сам отпечаток и размер исходника видны в configuration_info (полностью) и в db_list (первые 16 символов) — по ним две базы сравниваются на происхождение без повторной выгрузки. В консольном интерфейсе вместо --force задаётся вопрос «Пересобрать базу всё равно?».

Related MCP server: 1C MCP Server

Проверка запросов СКД

confdb check <база> (и пункт 5 консольного интерфейса) прогоняет все запросы таблицы skd_query через встроенный разборщик языка запросов 1С (src/confdb/query_lang.py):

• синтаксис: ПОМЕСТИТЬ/УНИЧТОЖИТЬ, ОБЪЕДИНИТЬ [ВСЕ], соединения (включая вложенные и перечислением), вложенные запросы, ВЫБОР/ВЫРАЗИТЬ, виртуальные таблицы с аргументами, параметры &…, необязательные области СКД {…}, ДЛЯ ИЗМЕНЕНИЯ;

• семантика по метаданным: существование таблиц (Справочник.Х, РегистрНакопления.Х.Обороты и т.п.), существование полей первого уровня (meta_attribute + стандартные поля + общие реквизиты, без учёта регистра), цепочки разыменования ссылок через attribute_ref (второй и далее уровни — мягко: составные/абстрактные типы не всегда раскрываются).

Код возврата 1 и список сообщений — если какой-то запрос не прошёл.

1confdb-knw — MCP-сервер для внешних LLM

:: сервер знаний по конфигурации 1С и BSL; stdio (JSON-RPC, read-only)
1confdb-knw.bat out.db
:: то же через CLI: confdb 1confdb-knw out.db
:: несколько баз сразу: основная конфигурация + расширения/обработки
1confdb-knw.bat main.db extension.db processor.db
:: несколько групп конфигураций одновременно — повтор флага добавляет базу
:: в ту же группу, а группы остаются раздельными (запрос к одной — group=<имя>)
1confdb-knw.bat --group УНФ=unf.db --group УНФ=unf_ext.cfe.db --group БП=bp.db

Путь к базе можно не указывать: 1confdb-knw.bat без аргумента берёт last_db из ~/.confdb/config.json, а при его отсутствии сам ищет *.db/*.sqlite — в текущем каталоге, db/ и _out/ (и в корне установки при запуске из venv). Одна база — запускается; несколько — сервер печатает список и просит указать путь явно. С флагом --group автопоиск не срабатывает: нужные базы названы в группах. Несуществующий путь — сразу «Файл базы не найден» (код 2), без падения на первом запросе. Свежая установка с базой, привезённой с другого компьютера, работает без ручной правки конфига: достаточно положить файл в db/ рядом с 1confdb-knw.bat.

32 инструмента: find_objects, object_card (паспорт объекта: реквизиты, табличные части, модули, формы и команды, ссылки; у регистров — измерения, ресурсы и реквизиты отдельными группами плюс периодичность и режим записи), object_tree, find_field, refs_of, role_rights (явные права одной роли: по строке на цель — объект, его реквизит/поле табличной части или его табличная часть, — с текстом ограничения доступа на уровне записей и шаблонами RLS роли; право показывается первыми знаками своего uuid, потому что имён прав в конфигурации нет), object_rights (какие роли несут явные права на объект, включая права на его реквизиты и табличные части; параметр role сужает ответ до одной роли), module_outline, get_method, find_method_context (окно строк вокруг нужного вызова с номерами строк модуля и маркерами точки вставки), method_dependencies (что использует метод: общие модули и их экспортные методы, метаданные, таблицы и поля запросов, параметры; если рядом открыта основная конфигурация, её объекты и общие модули находятся там, а не объявляются отсутствующими), method_result_schema (из чего состоит возвращаемая методом таблица значений/структура — эвристика по тексту), find_methods (поиск по имени, сигнатуре и описанию, а параметр text — по текстам тел методов: все места обращения к объекту с номером строки модуля, без полнотекстового sql), skd_of, find_skd, xdto_of (состав пакета XDTO: целевое пространство имён, импорты, типы с базовым типом, ограничениями и значениями перечислений, свойства с обязательностью, признаком списка и формой — атрибут или элемент, вложенные анонимные типы; параметр type показывает один тип), find_xdto (поиск имён типов и свойств по всем пакетам XDTO базы), check_query (валидатор запроса 1С), sql (только SELECT), compare_object (различия одного объекта в двух базах), extension_diff (что делает расширение относительно основной конфигурации), configuration_info (тип загруженного файла — конфигурация .cf, расширение .cfe, внешняя обработка .epf, внешний отчёт .erf; имя и версия, режим совместимости, источник и дата выгрузки) и управление базами db_list / db_open / db_use / db_close плюс управление группами конфигураций group_create / group_add_db / group_remove_db / group_list / group_use / group_close. Инструкции протокола (initialize.instructions) и описания инструментов содержат справочник по схеме базы, глоссарий 1С и рекомендуемый рабочий процесс — любая модель пользуется сервером без контекста этого проекта.

Пагинация поиска. find_objects, find_field, find_methods, find_skd, find_xdto и refs_of отдают одну страницу совпадений: limit задаёт её размер (1..200), offset — сколько совпадений того же поиска пропустить. Последняя строка ответа сообщает итог и продолжение — … всего найдено 317; показано 1–20; есть ещё 297 — следующий вызов с offset=20 (когда страница последняя — «это все результаты»). Порядок совпадений строгий, поэтому страницы не пересекаются и не теряют строки. У find_xdto типы и свойства считаются одним списком (сначала типы, потом свойства), у refs_of свой итог у каждой из двух секций, а offset у них общий.

Синтаксис текстов модулей этот сервер не проверяет: полный разбор BSL (блок-конструкции, препроцессор, типы, область видимости) делает BSL Language Server, который поднимает вариант 1confdb-knw-lsp. Ошибки инструментов возвращаются с кодом категории — BAD_ARGS, BAD_REQUEST, DB_LOCKED, DB_SCHEMA, DB_ERROR, IO_ERROR, INTERNAL; при занятой базе (SQLITE_BUSY) вызов повторяется автоматически.

Несколько баз одновременно (расширения и обработки)

Сервер держит несколько баз сразу: перечислите их при запуске либо открывайте на ходу инструментом db_open (без перезапуска сервера). Каждая база получает алиас (по умолчанию — имя файла без расширения; при совпадении — с суффиксом _2, _3…). Все инструменты по умолчанию работают с активной базой (при запуске — первая указанная); чтобы запросить другую базу без переключения, передайте её алиас параметром db (есть у всех инструментов). Переключение активной базы — db_use, список открытых баз со статистикой — db_list, закрытие — db_close.

Типовой сценарий: извлечь основную конфигурацию, расширение и обработку в отдельные базы и запустить сервер со всеми тремя —

confdb extract main.cf --db main.db
confdb extract ext.cfe --db ext.db
confdb extract proc.epf --db proc.db
1confdb-knw.bat main.db ext.db proc.db

— после чего LLM видит метаданные и код всех трёх и может, например, искать методы расширения (find_methods с db='ext') поверх основной конфигурации. Специальное значение db='*' выполняет инструмент сразу по всем открытым базам (ответ приходит секциями по базам) — один вызов, чтобы сравнить основную конфигурацию с расширениями. Если база пересобрана (повторный extract), её достаточно закрыть и открыть заново: db_close + db_open.

Идентификатор базы в ответах: каждый ответ инструмента данных начинается с заголовка === база <алиас> (<путь>) ===, идентифицирующего источник данных. Если база входит в группу, заголовок называет и её — === группа <имя> / база <алиас> (<путь>) ===, а при вхождении в несколько групп — === группы A, B / база …. Это позволяет LLM сравнивать конфигурации (типовая vs доработанная, основная vs расширение) и понимать, в какой базе находится метод или объект. Например:

=== база основная (C:\path\main.db) ===
Справочник.Контрагенты: 150 объектов

=== база расширение (C:\path\ext.db) ===
Справочник.Контрагенты: 155 объектов

Инструменты управления базами (db_list, db_open, db_use, db_close) не содержат заголовок — они сами управляют базами.

Группы конфигураций: несколько наборов баз одновременно

Группа объединяет связанные базы (основная конфигурация + расширения + обработки) под одним именем. Групп может быть открыто несколько одновременно — например две разные конфигурации или две версии одной, — и деление при этом сохраняется: сервер знает, какая база в какой группе, и печатает это в db_list, в group_list и в заголовке каждого ответа.

• запуск с группами: 1confdb-knw.bat --group УНФ=unf.db --group УНФ=unf_ext.db --group БП=bp.db — повтор флага добавляет базу в ту же группу, несколько путей можно перечислить через ;. Первая группа становится активной, а её первая база — активной базой;

• запрос к ОДНОЙ группе: параметр group='БП' у инструмента данных — он выполнится по всем базам группы и вернёт ответ секциями === группа БП / база <алиас> (<путь>) ===;

• запрос сразу ко всем группам: group='*' — секции по группам, каждая со своими базами (в отличие от db='*', который смешивает все открытые базы);

• без group выполняется только активная база, а не вся активная группа: при нескольких открытых группах группу нужно называть явно. group_use переключает активную группу и делает её первую базу активной;

• отказ одной базы не рвёт групповой вызов (group=<имя>, group='*', db='*'): её секция несёт ошибка [КАТЕГОРИЯ]: … (DB_LOCKED — транзитная, тот же вызов может пройти повторно), остальные базы отвечают штатно, а ответ заканчивается строкой баз с ошибкой N из M: <алиасы>, чтобы частичный ответ не читался как полный. isError вызов получает только когда отказали все базы — их секции при этом остаются видны;

• на ходу: group_create, group_add_db, group_remove_db, group_list, group_use, group_close (удаление группы базы не закрывает).

compare_object и extension_diff групп не знают: они принимают явные алиасы баз (db_left/db_right, extension_db/base_db), которые берутся из db_list или group_list.

В консольном интерфейсе наборы баз сохраняются в именованные группы (пункт 6 главного меню): одна база может входить в несколько групп. Пункт 1 запускает сервер с несколькими группами сразу — номер отмечает или снимает группу, *N делает N-ю выбранной первой (её база станет активной), m добавляет отдельные базы вне групп. В сетевом режиме панель после запуска позволяет подключать/закрывать базы и работать с группами из конфига без перезапуска сервера: добавить группу (остальные группы и базы останутся открытыми), заменить весь набор одной группой, убрать группу (её базы закроются, если не нужны другим группам) и сделать группу активной.

Пример конфигурации MCP-клиента, в т.ч. через SSH:

{
  "mcpServers": {
    "1confdb-knw": {
      "command": "ssh",
      "args": ["user@host", "python", "-m", "confdb.mcp_server", "/path/out.db"]
    }
  }
}

Сетевой режим (когда stdio не подходит)

Сервер слушает порт и отдаёт MCP по HTTP (Streamable HTTP: POST /mcp; legacy SSE для старых клиентов: GET /sse + POST /messages):

1confdb-knw.bat out.db --port 8765

С другой машины подключение — через SSH-туннель:

ssh -L 8765:127.0.0.1:8765 user@host

{
  "mcpServers": {
    "1confdb-knw": { "url": "http://127.0.0.1:8765/mcp" }
  }
}

По умолчанию слушает 127.0.0.1 (без аутентификации, база read-only); --host 0.0.0.0 открывает порт наружу — используйте только в доверенной сети. В консольном интерфейсе — пункт 1 → «Сеть (HTTP-порт)».

Запросы выполняются по одному за раз: соединения баз и приставных шардов FTS на сервер общие, поэтому вызовы инструмента сериализованы — в stdio, в HTTP и когда консольный интерфейс обращается к работающему серверу. Долгий запрос (sql по большой таблице, поиск по телам в базе без индекса) задерживает остальных клиентов; параллельные подключения работу не ускоряют.

Опции extract:

• --db FILE — записать результат в SQLite;

• --dump DIR — сохранить распакованное дерево файлов (нужен хотя бы один из --db/--dump);

• --temp-dir DIR, --keep-temp — рабочий каталог стадий 0–1 и его сохранение. Без --temp-dir он создаётся рядом с базой (--db) или дампом (--dump), а не в %TEMP%: на системном томе удаление ~125 тысяч файлов рабочего каталога стоит ~30 с и почти не распараллеливается, на несистемном — ~10 с, и прогон УНФ целиком занимает 70 с вместо 97 с. Если каталог результата недоступен — откат на %TEMP%;

• --prefix STR — снять префикс с имён объектов;

• --store-blobs — хранить бинарные файлы (картинки, макеты) в БД как BLOB;

• --workers N — число процессов стадии 3 и записи БД (по умолчанию — результат confdb bench или 1; на многоядерной машине несколько процессов ускоряют разбор в несколько раз). В консольном интерфейсе — меню «Опции извлечения». При вызове extract() из собственного скрипта на Windows с workers > 1 вызов должен быть обёрнут в if __name__ == '__main__': (требование multiprocessing spawn).

• --no-fts — не строить FTS-индекс по телам методов. Индекс — приставные файлы <база>.fts\0.db…, по одному на процесс (на УНФ 7.5 с в 8 шардов, ~1.1 ГБ); сама база остаётся одним файлом и без индекса работоспособна — поиск по телам идёт полным проходом (~0.3 с на запрос). Достраивается позже командой confdb fts <база> [--workers N], каталог .fts можно удалить в любой момент.

• --dump-indent — писать JSON дампа с отступами, как это делает v8unpack. Нужно только для побайтового сравнения дампов при проверке эквивалентности декодера: по умолчанию вывод компактный, с ним стадия 3 быстрее (28.0 с против 30.8 с на УНФ), а дерево дампа примерно втрое меньше. На содержимое базы флаг не влияет.

• --force — пересобрать базу, даже если она уже собрана из этого же файла. Без флага extract сравнивает SHA-256 исходника с source.file_sha256 целевой базы и при совпадении не запускает распаковку вовсе (~70 с на УНФ против 1,7 с на отпечаток).

Бенчмарк и автонастройка

confdb bench <file> один раз прогоняет стадии 0/1, затем нелинейный сэмпл объектов верхнего уровня (шаг по всему списку + покрытие всех типов объектов, чтобы задеть и лёгкие справочники, и тяжёлые формы/отчёты) через стадию 3 и запись БД при 1/2/4/8/CPU процессах. Лучшее число процессов сохраняется в ~/.confdb/config.json и подставляется по умолчанию в extract и в консольный интерфейс; --workers N переопределяет вручную.

Стадии конвейера (повторяют v8unpack, только распаковка):

1. чтение внешних V8-контейнеров (32/64-бит) в файлы как есть;

2. inflate (raw deflate) + рекурсивные вложенные контейнеры;

3. декодирование метаданных: скобкофайлы {} → JSON, тексты модулей → .bsl.

Схема базы данных

Ревизия схемы штампуется в сам файл базы: PRAGMA user_version = writer.SCHEMA_VERSION (с 2026-10-08). MCP-сервер отвечает только на базы своей ревизии, а на устаревшую возвращает просьбу пересобрать её (confdb extract <файл> --db <база> --force) — вместо ошибки схемы посреди запроса. Совместимого режима чтения старых схем нет: новые колонки (например role_right.target_flags) заполняются только из исходника, миграции не существует. У баз, собранных до появления штампа, user_version = 0 — они считаются устаревшими. Ревизию открытых баз показывают db_list, db_open и список баз в TUI.

• source — исходный файл: путь, дата, тип/имя/uuid корневого объекта;

• meta_object — объект метаданных: path (например Catalog/Контрагенты/CatalogForm/ФормаЭлемента), type (Catalog, Document, CommonModule, …), type_ru (русское имя «как в конфигураторе»: Справочник, Документ, Общий модуль, …), name, uuid, comment, obj_version, header_json (полный разобранный заголовок), parent_id + ord (иерархия и порядок братьев — как в дереве конфигуратора);

• meta_attribute — реквизиты объекта: ord, name, type_str в порядке объявления. Примитивы — Строка(50)/Число/Дата/Булево; ссылки — Ссылка: <путь> (таблица ссылочных uuid из потока .10 корневого объекта, коллизии имён дизамбигуируются по типу объекта); определяемые типы — ОпределяемыйТип: <путь> (<состав>) (состав раскрывается); составные типы — члены через |; обобщённые типы платформы («ЛюбаяСсылка» и т.п.), чей uuid не соответствует ни одному объекту конфигурации, — Ссылка (это не ошибка извлечения, у такого типа нет конкретной цели); Ссылка: <имя> (объект не найден в базе) — имя цели известно из таблицы .10, но самого объекта в этой базе нет (типично для ссылки из расширения на объект основной конфигурации); NULL — в заголовке объекта описание типа этого реквизита отсутствует; uuid — собственный идентификатор поля в метаданных: по нему цель права роли (role_right.target_uuid) разрешается в конкретный реквизит, NULL, когда в заголовке поля uuid нет;

• attribute_ref — связи реквизитов с объектами метаданных: uuid (ссылочный uuid из дескриптора типа, для составных/определяемых типов — по строке на член) и object_id — объект, на который ведёт ссылка (NULL для абстрактных типов); зависимость «реквизит ↔ объекты» строится join'ом без разбора строк type_str;

• enum_value — значения перечислений (ord, name) в порядке объявления;

• predefined — предопределённые элементы из «Предустановленные данные.bin»: ord (номер в обходе в глубину), parent_ord (ord родителя; NULL только у корневого узла «Счета»/«Элементы», который элементом не является), uuid элемента, name, code, display;

• predefined_subconto — виды субконто предопределённого счёта плана счетов: predefined_id, ord, uuid вида субконто, kind_id — предопределённый элемент плана видов характеристик, которым он разрешается, flags — включённые флаги через «;» («Суммовой», «Валютный», «Количественный»);

• common_target — привязка общих реквизитов к объектам метаданных;

• meta_tabular — табличные части объекта (ord, name, uuid) в порядке объявления; поля табличных частей лежат в meta_attribute с заполненной колонкой tabular (имя секции) — цепочки вида Т.Товары.Наименование в запросах проверяются по этим данным; uuid секции разрешает право роли, заданное на табличной части.

• module — паспорт модуля: code_name (obj, mgr, mod, con, app …) и для общих модулей context (Сервер/Клиент/Вызов сервера/…), плюс body — текст модуля как есть без кода методов: комментарии, препроцессор #Если…, #Область…, директивы и сигнатуры вида Процедура Имя(п1, п2) Экспорт сохранены; подстановка method.body вместо каждой сигнатуры восстанавливает исходный модуль;

• method — только процедуры/функции: вид, имя, сигнатура, is_export, directives (строка &НаКлиенте, &НаСервере без скобок), description (блок комментариев непосредственно над методом, как есть с //), line_start/line_end, body — строго с Процедура/Функция по КонецПроцедуры/КонецФункции; #… и комментарии вне тела в метод не попадают;

• subsystem_content — состав подсистем (ссылки на объекты в порядке объявления) — для обхода дерева подсистем, как в конфигураторе;

• skd_query — запросы, извлечённые из макетов СКД объекта (ord, query), — для проверки корректности запросов 1С;

• role_right — объектные права ролей из файла Role/<имя>/Role.0.c1brace. Хранятся только ЯВНЫЕ записи (sparse): отсутствие строки означает «право не задано», а не «запрещено». Цель права — объект, его реквизит/поле табличной части или его табличная часть: target_object_id — объект-владелец (заполнен и для подобъекта, поэтому все права, затрагивающие объект, выбираются одним условием), target_attr_id/target_tabular_id — сам подобъект, target_uuid — uuid цели как он записан в роли (подобъект, которого проект не извлекает, остаётся только с ним); right_uuid — идентификатор права платформы (русского имени права в конфигурации нет, словарь «uuid → имя» из неё не извлекается), value — значение права, sub_index/collection_uuid — адресация «подобъект №-K внутри коллекции», target_flags — флаги записи цели дословно, без толкования (их смысл не подтверждён; без них две цели с одним uuid слились бы в одну), rls_text — ограничение доступа на уровне записей для этой цели и права;

• role_rls_template — именованные шаблоны RLS роли (name, text);

• role_rights_state — состояние извлечения прав каждой роли: parsed=0 — данные недоступны (файла прав нет или формат не распознан, причина в error), parsed=1 при rights=0 — права роли действительно не заданы;

• xdto_type, xdto_property, xdto_import — содержимое пакетов XDTO (файл XDTOPackage.bin — это открытый XML, реверс бинарного формата не потребовался): типы objectType/valueType/typeDef с базовым типом, ограничениями и значениями перечислений, их свойства (обязательность, признак списка, форма — атрибут или элемент, вложенные анонимные типы) и импортируемые пространства имён; type_id IS NULL означает свойство, объявленное самим пакетом вне типов; целевое пространство имён пакета берётся из его header_json. Инструменты xdto_of и find_xdto;

• file — прочие файлы дампа (help.html, инфо-JSON, картинки): путь, тип, размер, содержимое для текстовых (BLOB — только при --store-blobs).

Пример запроса:

-- реквизиты справочника с типами
SELECT a.name, a.type_str
FROM meta_attribute a JOIN meta_object o ON o.id = a.object_id
WHERE o.path = 'Catalog/Контрагенты' ORDER BY a.ord;

-- краткое представление модуля (текст без кода методов)
SELECT m.body FROM module m JOIN meta_object o ON o.id = m.object_id
WHERE o.path = 'Catalog/Контрагенты' AND m.code_name = 'obj';

-- тело конкретного метода
SELECT mt.body FROM method mt JOIN module m ON m.id = mt.module_id
JOIN meta_object o ON o.id = m.object_id
WHERE o.path = 'Document/Заказ' AND m.code_name = 'obj'
  AND mt.name = 'ПриПроведении';

Состав

• src/confdb/v8 — ядро распаковки (контейнеры 1С, inflate, скобкофайлы, метаданные);

• src/confdb/extract.py — конвейер стадий 0/1/3 (контейнеры → inflate → разбор). Рабочий каталог по умолчанию создаётся на томе результата (make_temp_dir), а не в %TEMP%, и удаляется параллельно (remove_tree): удаление ~125 тыс. файлов стоит ~30 с на системном томе против ~10 с на другом. Здесь же отпечаток источника — file_sha256 (1.7 с для 885 МБ) пишется в source.file_sha256, а check_same_source(src, db, force) позволяет CLI и TUI не распаковывать тот же файл повторно; в старых базах отпечатка нет, и это читается как «неизвестно», а не как «файл другой»;

• src/confdb/__main__.py — CLI: extract, check, fts, bench, 1confdb-knw;

• src/confdb/db/writer.py — схема SQLite и запись результата: пакетные вставки, разбор BSL в несколько процессов (workers); права ролей пишутся после объектов и разрешаются по uuid объектов, реквизитов и табличных частей (_write_role_rights, _right_targets); ревизия схемы (SCHEMA_VERSION) штампуется в файл базы (PRAGMA user_version);

• src/confdb/query_lang.py — разбор и семантический контроль языка запросов 1С (подкоманда confdb check);

• src/confdb/mcp_server.py — MCP-сервер 1confdb-knw <база…>: read-only инструменты, самомописываемый (схема, глоссарий и порядок работы отдаются в initialize.instructions). Несколько баз (алиас на базу, необязательный параметр db, db='*' — по всем сразу) и ГРУППЫ конфигураций: --group ИМЯ=ПУТЬ (повторяемый) открывает несколько групп, group=<имя> опрашивает одну, group='*' — все, а без group работает только активная база (group_use переключает активную). Шесть поисковых инструментов страничные (limit 1..200 и offset, последняя строка ответа называет общее число совпадений и следующий offset); кросс-базовые инструменты принимают явные алиасы (compare_object, extension_diff); ошибки категоризованы (error_text), SQLITE_BUSY повторяется (call_with_retry). Транспорт — stdio, --port N включает HTTP/SSE; вызовы инструментов сериализованы общей блокировкой (_synchronized): соединения баз и приставных шардов FTS на сервер общие, а потоков несколько — HTTP-обработчик создаётся на запрос, панель работающего сервера в TUI дёргает тот же объект;

• src/confdb/tui.py — консольный интерфейс (выбор пользователя: консоль, а не GUI). В списках файлов и баз число выбирает элемент, а любой другой текст читается как введённый путь. Запуск MCP выбирает несколько групп баз сразу (в сервер они попадают как --group в stdio-режиме и как McpServer(groups=…) в сетевом), а панель работающего сервера добавляет, заменяет все, удаляет и активирует группу без перезапуска;

• src/confdb/bsl_parser.py — разбиение модулей BSL на процедуры и функции;

• src/confdb/bsl_analyzer.py — лексический анализ BSL для method_dependencies и method_result_schema: маскирование строк и комментариев с пониманием многострочных литералов 1С с |, извлечение и проверка запросов через query_lang, разрешение общих модулей и метаданных, клиентский и серверный контекст. Синтаксис модулей он намеренно не проверяет — это делает BSL Language Server, который есть только в варианте 1confdb-knw-lsp;

• src/confdb/header_props.py — читает meta_object.header_json без повторной распаковки: версию конфигурации, синоним, режим совместимости и префикс расширения; коллекции измерений, ресурсов и реквизитов регистра с периодичностью и флагами режима записи; целевое пространство имён XDTO-пакета; вид загруженного файла — по расширению source.file, а не по типу корневого объекта (.erf и .epf раскрываются в ExternalDataProcessor);

• src/confdb/xdto.py — разбор XDTOPackage.bin (обычный UTF-8 XML с BOM) в таблицы xdto_*; проверено на всех 334 пакетах тестовой конфигурации;

• src/confdb/compare.py — снимки объектов и сравнение двух баз (compare_object, extension_diff); тела методов и модулей сравниваются по sha1;

• src/confdb/rights.py — разбор файла прав роли Role/<имя>/Role.0.c1brace (объектные права, RLS по объектам, шаблоны RLS) для записи в базу; нераспознанный формат бросает ValueError, поэтому одна «чужая» роль не останавливает запись;

• src/confdb/bench.py — бенчмарк железа, сохраняет лучшее число workers в ~/.confdb/config.json (src/confdb/config.py — общий конфиг пользователя, его же читает TUI);

• tests — тесты на малых фикстурах (test.bat); _tmp — одноразовые пробники (игнорируются git).

Требования

• Python 3.9+, только стандартная библиотека.