1c Config Index

---
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` - проверки, которые читают индекс