1c-config-index · git:20260819.286b4b8 · 2026-08-19 · sha256 84d197e1e18f5b52
1c-config-index git:20260819.286b4b8A
Immutable. This exact content is served forever at /api/v1/blob/84d197e1e18f5b52.
---
name: 1c-config-index
description: Индекс XML-выгрузки конфигурации 1С в один JSON - какие объекты есть, их реквизиты, табличные части, измерения и ресурсы регистров, экспортные методы общих модулей. Нужен другим навыкам для проверок, где объект сверяется с остальной конфигурацией
argument-hint: <ConfigPath> [-OutFile index.json] [-Detailed]
allowed-tools:
- Bash
- Read
- Glob
---
# /config-index - индекс конфигурации 1С
Один проход по выгрузке, на выходе один JSON. Индекс отвечает на вопрос "что вообще есть в этой
конфигурации и из чего оно состоит" - и тем самым дает остальным навыкам то, чего им не хватало:
возможность проверить объект не сам по себе, а против остальной конфигурации.
Работает без EDT, без платформы и без запущенной базы - читает только файлы выгрузки.
## Параметры
| Параметр | Обяз. | Умолч. | Описание |
|------------|:-----:|--------|-----------------------------------------------------------------|
| ConfigPath | да | - | Каталог выгрузки (где лежит `Configuration.xml`) либо путь к нему |
| OutFile | нет | - | Куда записать индекс. Без него JSON печатается в stdout |
| Detailed | нет | - | Дописать в отчет имена ненайденных объектов и время сборки |
## Команда
```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
```
## Что попадает в индекс
| Ключ | Что там |
|-----------------|---------------------------------------------------------------------------------|
| `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` - проверки, которые читают индекс