# Программа доказательного codec-а отчётов и макетов

## Цель

Построить для SQL-адаптера раздельные, evidence-first decoder/encoder пути
для отчёта и каждого типа его макета. Публичный API принимает только имя
расширения, отчёта и макета; физические таблицы, ключи и контейнеры остаются
внутренними деталями реализации.

## Первая live-фикстура

База: `upo_test`; расширение: `фс_Отчеты`;
отчёт: `_ПоступлениеТовара`;
GUID отчёта: `c428f629-785a-4141-b038-f2192bb4580d`.

Наблюдаемое состояние на 2026-08-14:

- extension object search подтверждает сохранённый override в `ConfigCASSave`;
- в saved слое присутствуют descriptor, `.0` и extension `__configinfo`;
- active manifest содержит только descriptor и `.0` stream;
- `metadata.object.components` подтверждает четыре формы, среди них форму
  `ОсновнаяСхемаКомпоновкиДанных`;
- `metadata.object.templates` и `scd.inspect` не подтверждают макет
  `DataCompositionSchema` для этого объекта.

Следствие: имя формы не является доказательством существования одноимённого
макета СКД. Нельзя направлять запрос или XML-кодек в `.0` stream.

## Матрица типов макетов

| Платформенный тип | Состояние codec-а | Допустимое действие до fixture proof |
| --- | --- | --- |
| Табличный документ | частичный MOXCEL decoder | read-only structure/evidence |
| Текстовый документ | типизированное текстовое исследование | read-only до round-trip fixture |
| Двоичные данные | opaque | hash/size only |
| Active document | opaque | hash/size only |
| HTML документ | частичное текстовое/HTML evidence | read-only до round-trip fixture |
| Географическая схема | opaque typed candidate | read-only |
| Графическая схема | opaque typed candidate | read-only |
| Схема компоновки данных | XML decoder + scalar byte-preserving patch | `read_and_scalar_patch_supported`; write only after public route and saved-state codec proof |
| Макет оформления компоновки данных | отдельный XML family | read-only до own fixture proof |
| Внешняя компонента | opaque archive | hash/size only |

Источник taxonomy: [1C:Enterprise Template wizard](https://kb.1ci.com/1C_Enterprise_Platform/Guides/Developer_Guides/1C_Enterprise_8.3.23_Developer_Guide/Chapter_31._Development_tools/31.14._Template_wizard/).

## Protocol gates

1. Создать либо выбрать отдельную live fixture для одного вида макета.
2. Снять SQL before snapshot всех связанных payload-ов и их SHA-1.
3. Выполнить ровно одно контролируемое изменение через Configurator.
4. Снять after snapshot и доказать точное соответствие object → manifest →
   payload → saved-state overlay.
5. Реализовать lossless decoder и обратный encoder только для изменённого
   участка; неизвестные байты сохраняются дословно.
6. Выполнить `apply_and_rollback` в `upo_test`, проверить SQL readback и
   очистку adapter-created rows.
7. Отдельно получить человеческое подтверждение видимости в Configurator.

Для СКД XML-семантика включает datasets, links, calculated fields, resources,
parameters, layouts, nested schemas и settings. Макет оформления — другой XML
контракт: регионы, шрифты, цвета, границы и правила оформления; его нельзя
обрабатывать методом `scd.patch`.

## Долгосрочный план и критерии готовности

| Этап | Результат | Критерий перехода |
| --- | --- | --- |
| 1. Инвентарь | Реестр `Report → Template` с identity, container, SHA-1 и состоянием active/saved | У каждого fixture есть подтверждённая цепочка owner → template → payload, без имени формы в качестве подстановки. |
| 2. СКД read | Lossless контейнерный decoder с XML-путями для datasets, links, calculated fields, resources, parameters, layouts, nested schemas и settings | XML корректно читается на нескольких живых схемах; неизвестные XML узлы сохраняются в raw-carrier и не теряются. |
| 3. СКД write | Минимальный scalar writer (`dataset.query`, expression) и resolver `Report + Template` | `plan`, точная проверка SHA-1 и `apply_and_rollback` проходят на выделенной fixture; активность подтверждает человек в Configurator. |
| 4. Оформление СКД | Отдельный decoder/encoder XML оформления: regions, style rules, fonts, colors, borders, indents | Не используется путь `scd.patch`; один контролируемый before/after fixture доказывает carrier и round-trip. |
| 5. Прочие типы | Отдельная карточка codec-а на каждый из десяти platform types | Для Spreadsheet/Text/HTML/Geo/Graphical доказан собственный round-trip или выставлен explicit `unsupported`; Binary/Active/AddIn остаются opaque до отдельного доказательства. |
| 6. Report aggregate | API `report.inspect` возвращает identity, modules/forms/templates, main-SCD relation, overlay state и capability по каждому компоненту | Отчёт без подтверждённой СКД возвращает `unresolved`, а не выбирает форму или первый поток. |
| 7. Регрессия и выпуск | Fixture manifest, hash-baselines, unit tests, live SQL smoke и документация публичного контракта | Каждый write codec проходит план → rollback → SQL readback; ни один результат не заявляет применение в Configurator без ручного подтверждения. |

Работа выполняется последовательно по этому реестру: новый тип не получает
write endpoint до собственной fixture и доказанного обратного carrier codec-а.

## Live XML evidence: базовая СКД

14.08.2026 read-only diagnostic read подтвердил carrier для
`Report.ФинансовыйРезультат / ОсновнаяСхемаКомпоновкиДанных`:

- Template GUID: `e3140fc8-1688-4640-a68a-e0f7675c68e9`; payload: `.0`;
- контейнер: 3 391 байт raw-deflate, после распаковки 23 097 байт;
- XML envelope: `SchemaFile`, 12 941 символ до закрывающего тега;
- прямые дочерние секции `dataCompositionSchema`: `dataSource` (1),
  `dataSet` (1), `parameter` (4), `settingsVariant` (1), `totalField` (4);
- `dataSource` имеет доказанные прямые поля `name=ИсточникДанных1` и
  `dataSourceType=Local`.

На этом доказательстве в decoder добавлена секция `data_sources` и
`schema_outline` с точными XML тегами, путями и количеством. Наличие
`dataSetLink`, layouts или nested schema в другой СКД не предполагается: они
будут добавлены после отдельной live fixture с соответствующим тегом.

## Live fixtures остальных типов

Read-only diagnostic inventory `CommonTemplate` в `upo_test` уже дал три
отдельных carrier fixture. Имена нужны только для повторного поиска; тип
подтверждён содержимым `.0`, а не именем.

| Fixture | Template GUID | Доказательство типа | Разрешённое действие |
| --- | --- | --- | --- |
| `ОформлениеОтчетовБежевый` | `f49709d3-13ea-4d67-9934-9d93f8ba1c21` | XML root `AppearanceTemplate`, DCS appearance namespace | read-only, отдельный appearance decoder pending |
| `ШаблонHTMLПредставленияTXTФайла` | `e3eb9ae8-7381-400b-a933-861b1f4efcff` | UTF-8 XML/HTML root `html` | existing safe text/HTML export only |
| `КомпонентаXMLDSIG` | `db062a63-2759-409a-b78b-132fe226f6f1` | carrier `{#base64:...}` with ZIP signature `PK` after decoding; metadata part has no `ExternalComponent` declaration | opaque archive candidate, hash/size only |

Из этого следует, что `AppearanceTemplate` нельзя относить к spreadsheet
только из-за вложенного упоминания `SpreadsheetDocument` в XML. Для него
нужен собственный root-aware classifier и отдельный XML decoder; обратная
запись по-прежнему запрещена до controlled before/after fixture.

Reader реализован в `plugins/1c/parser/appearance_payload.py`: он возвращает
контейнер, все верхнеуровневые правила `item(parameter, value)` и точный
outline XML-тегов. Он не разбирает строковое значение style как произвольный
формат и всегда сообщает `unsupported_until_reverse_codec_fixture` для write.

ZIP carrier сам по себе не доказывает platform type `ExternalComponent`:
fixture выше нельзя использовать для утверждения этого типа или для encoder-а.
Для внешней компоненты нужен отдельный metadata declaration либо controlled
Configurator fixture.

## Ближайшая реализация

Первый кодовый результат — resolver, который умеет различать форму и макет,
а затем находит `MainDataCompositionSchema` по подтверждённой template identity
в extension active/saved layer. При отсутствии доказанного template payload он
возвращает `unresolved`, а не fallback на форму или stream `.0`.

## Среда Configurator и текущий блокер fixture-изменений

На рабочей станции подтверждены локальные исполняемые файлы Configurator:
`C:\\Program Files\\1cv8\\8.3.24.1548\\bin\\1cv8.exe` и
`C:\\Program Files\\1cv8\\8.5.1.1236\\bin\\1cv8.exe`. В списке информационных
баз зарегистрирован `upo_test` с соединением `Srvr="wsr";Ref="upo_test"`.

14.08.2026 выполнена только read-only попытка
`DESIGNER /DumpConfigToFiles` в отдельный каталог отчётов. Сервер вернул
`Пользователь ИБ не идентифицирован`; выгрузка не началась и база не
изменялась. Поэтому автоматизированные before/after изменения в
Configurator пока не запускаются: требуется штатная учётная запись ИБ или
интерактивный вход человека. Это не ослабляет SQL-only правило runtime
адаптера и не является разрешением подбирать либо сохранять пароли.