1c-config-index · git:20260924.1781112 · 2026-09-24 · sha256 d86681b4bf08a369
1c-config-index git:20260924.1781112A
Immutable. This exact content never changes and is served at /api/v1/blob/d86681b4bf08a369.
---
name: 1c-config-index
description: Индекс XML-выгрузки конфигурации 1С в один JSON - какие объекты есть, их реквизиты, табличные части, измерения и ресурсы регистров, экспортные методы общих модулей. Нужен другим навыкам для проверок, где объект сверяется с остальной конфигурацией
argument-hint: <ConfigPath> [-OutFile index.json] [-Detailed] | -IndexPath <файл> (-Object <FQN> | -Find <подстрока>)
allowed-tools:
- Bash
- Read
- Glob
---
# /config-index - индекс конфигурации 1С
Один проход по выгрузке, на выходе один JSON. Индекс отвечает на вопрос "что вообще есть в этой
конфигурации и из чего оно состоит" - и тем самым дает остальным навыкам то, чего им не хватало:
возможность проверить объект не сам по себе, а против остальной конфигурации.
Работает без EDT, без платформы и без запущенной базы - читает только файлы выгрузки. Построенный
индекс отвечает на точечные вопросы без повторного обхода - см. "Точечный запрос".
## Параметры
| Параметр | Обяз. | Умолч. | Описание |
|------------|:-----:|--------|-----------------------------------------------------------------|
| ConfigPath | для сборки | - | Каталог выгрузки (где лежит `Configuration.xml`) либо путь к нему |
| OutFile | нет | - | Куда записать индекс. Без него JSON печатается в stdout |
| Detailed | нет | - | Дописать в отчет имена ненайденных объектов и время сборки |
| IndexPath | для запроса | - | Готовый индекс, по которому выполняется точечный запрос |
| Object | нет | - | FQN объекта: напечатать его запись из индекса |
| Find | нет | - | Подстрока имени: напечатать FQN подходящих объектов |
## Команда
```powershell
powershell.exe -NoProfile -File "skills/1c-config-index/scripts/config-index.ps1" -ConfigPath "src" -OutFile "index.json"
```
```bash
python skills/1c-config-index/scripts/config-index.py -ConfigPath src -OutFile index.json
```
## Точечный запрос
Готовый индекс отвечает еще на два вопроса: какая запись у одного объекта и какие объекты носят
такое имя. Отвечает без обхода выгрузки - читает только файл индекса.
```powershell
powershell.exe -NoProfile -File "skills/1c-config-index/scripts/config-index.ps1" -IndexPath "index.json" -Object "Catalog.Контрагенты"
```
```bash
python skills/1c-config-index/scripts/config-index.py -IndexPath index.json -Find "Номенкл"
```
| Запрос | Вывод | Код возврата |
|---------------------------------|--------------------------------------------------------------------|--------------|
| `-Object <FQN>` | Запись объекта в формате и порядке ключей индекса | 0; объекта нет - в stderr `Object not found: <FQN>`, код 1 |
| `-Find <подстрока>` | FQN подходящих объектов по одному в строке, по возрастанию | 0; совпадений нет - пустой вывод, код 0 |
| Запрос вместе с доводом сборки, запрос без `-IndexPath`, `-IndexPath` без запроса | Ничего | Причина в stderr, код 2 |
| Индекс пустой, из пробелов или не разбирается | Ничего | В stderr `Index file could not be read: <файл>`, код 1 |
| Индекс разобран, но объектов в нем нет (`null`, массив, пустой объект) | Ничего | В stderr `Index file has no objects: <файл>`, код 1 |
И `-Object`, и `-Find` сверяют имя без учета регистра: имена метаданных 1С регистр не различают.
Порядок задан посимвольным сравнением, а не языковым: локали у портов разные, и на кириллице они
разошлись бы.
Брать запрос вместо чтения индекса стоит всегда, когда нужен один объект или список имен. Индекс
большой конфигурации весит мегабайты, и, прочитанный целиком, он занимает контекст агента; запись
одного объекта - сотни байт. Сборка при запросе не запускается: читается уже готовый файл.
## Что попадает в индекс
| Ключ | Что там |
|-----------------|---------------------------------------------------------------------------------|
| `format` | Версия схемы индекса. Читающий навык обязан ее проверять |
| `kind` | `configuration` либо `extension` - по `ConfigurationExtensionPurpose` |
| `name`, `version`, `namePrefix` | Имя конфигурации, версия, префикс имен расширения |
| `declared` | Состав `Configuration.xml`: тип -> список имен, в порядке записи |
| `objects` | Ключ `Тип.Имя` -> разбор объекта (см. ниже) |
| `types` | Все `GeneratedType` конфигурации: `CatalogRef.Контрагенты`, `DocumentObject.Накладная` и прочие |
| `commonModules` | Общий модуль -> список ЭКСПОРТНЫХ методов его `Ext/Module.bsl` |
| `missing` | Объявлено в `Configuration.xml`, но файла на диске нет |
| `unknownKinds` | Типы из `ChildObjects`, которых нет в карте типов |
Запись объекта несет только непустое: `attributes`, `standardAttributes`, `tabularSections`,
`standardTabularSections`, `dimensions`, `resources`, `addressingAttributes`, `accountingFlags`,
`extDimensionAccountingFlags`, `enumValues`, `forms`, `templates`, `commands`, `subsystems`,
`recalculations`, `columns`, `operations`, `urlTemplates`, `valueType`, `props` и `refs`. Пустые
корзины не пишутся: на конфигурации в тысячи объектов они дали бы мегабайты фигурных скобок.
Табличная часть записана как `{"attributes": {имя: [типы]}, "standardAttributes": [имена]}` -
собственные колонки и стандартные лежат рядом, но раздельно.
Стандартные реквизиты берутся из блока `StandardAttributes` самой выгрузки, а не из своей таблицы:
таблица разошлась бы с платформой молча. Имена там внутренние, английские (`Description`, `Code`,
`Period`) - и в путях данных формы они пишутся точно так же.
У реквизита хранится список типов с отброшенным префиксом пространства имен: `CatalogRef.Контрагенты`,
`string`, `decimal`. Ссылочный тип узнается по точке в имени.
`props` держит те свойства, которые нужны последующим проверкам: `Hierarchical`, `CodeLength`,
`DescriptionLength`, `RegisterType`, `Periodicity`, `WriteMode`, `ObjectBelonging` и флаги общего
модуля. `refs` - списки ссылок на другие объекты: состав подсистемы (`Content`), движения документа
(`RegisterRecords`), владельцы, основания, регистры последовательности.
Вложенная подсистема получает ключ с полным путем: `Subsystem.Основная.Subsystem.Справочники` -
именно так подсистема адресуется во всей конфигурации.
## Чего индекс НЕ делает
Он ничего не проверяет и ни на что не ругается, кроме одного: сообщает, что объект объявлен в
`Configuration.xml`, а файла нет. Проверки строятся ПОВЕРХ индекса в других навыках.
Он не разбирает формы, макеты и схемы компоновки - только перечисляет их имена. Не читает права
ролей. Не выводит типы выражений BSL и не понимает запросы: без платформы этого получить нельзя.
## Сколько это стоит
Замер на синтетической конфигурации: 3007 объектов, 3515 файлов, 43 МБ выгрузки, индекс на выходе
2.7 МБ.
| Порт | Время |
|------------|--------|
| python | ~2.5 с |
| powershell | ~16 с |
Разрыв объясняется стоимостью обхода XML в PowerShell, а не разной работой: оба порта дают
байт-в-байт одинаковый JSON, это закреплено кейсами. На больших конфигурациях брать python-порт.
## Как этим пользуются другие навыки
Индекс строится ОДИН раз на прогон и передается проверкам файлом. Обход каталога на каждую ссылку
превратил бы валидацию большой конфигурации в неприемлемо долгую.
```bash
python skills/1c-config-index/scripts/config-index.py -ConfigPath src -OutFile .cache/config-index.json
# дальше этот файл отдается навыкам-проверкам параметром -IndexPath
```
Расширение и частичная выгрузка - нормальное состояние: объект может ссылаться на то, чего в ЭТОЙ
выгрузке нет, потому что оно в основной конфигурации. Индекс это различает полем `kind`, а
проверяющий навык обязан на него смотреть - иначе на любом расширении утонет в ложных ошибках.
## Связанные навыки
- `1c-cf-info` - краткая сводка по конфигурации для человека; индекс же машинный и полный
- `1c-meta-info` - разбор одного объекта метаданных
- `1c-meta-validate`, `1c-cf-validate`, `1c-form-validate` - проверки, которые читают индекс