# Модуль объекта отчёта в расширении

Статус: чтение, точное разрешение владельца и контролируемая запись короткого
фрагмента поддержаны для доказанного hash-keyed saved-state маршрута.

Наблюдение в `upo_test`, расширение `test2`, отчёт `tt_Отчет`: сохранённый файл
`<extension-guid>__<report-guid>.0` является `raw_deflate` контейнером из пяти
потоков. BSL-модуль расположен в потоке `4`.

Поток начинается читаемым UTF-8-комментарием, но последующий текст содержит
нулевые байты и смешанное представление символов. Общий потоковый декодер
позволяет найти комментарий, однако его обратное кодирование меняет байты
неизменённого хвоста BSL. Экспериментальная запись показала это в Конфигураторе
и была немедленно восстановлена из парной резервной копии.

Правило: наличие читаемого BSL-фрагмента не доказывает возможность записи.
Для потока с `NUL` адаптер возвращает
`mixed_encoding_module_stream_unsupported` и не создаёт SQL-изменений.
Это не означает, что для каждого отчёта нужен свой кодер: один доказанный
кодек может обслуживать все модули с одинаковым физическим носителем.

Два ручных образца определили безопасную границу записи: редактируется только
объявленный UTF-8-префикс, а непрозрачный хвост и остальные потоки сохраняются
побайтно. Для hash-keyed overlay рабочий слой создаётся доказанным копированием
подтверждённых ключей `ConfigCAS → ConfigCASSave`; `__configinfo` для него не
создаётся и не предполагается.

Текущая реализация `parser.cas_payload.stream_blocks_with_data` ищет похожие
заголовки регулярным выражением по всему распакованному буферу. В потоке
отчёта такие последовательности встречаются и внутри данных, поэтому это
эвристика для чтения, а не структурный декодер. Нельзя использовать её индекс
потока как основание для обратной записи.

Структурный read-only декодер `decode_declared_utf8_bsl_prefix` подтверждён на
этом образце: пять последовательных блоков; пятый имеет `declared_1 = 68` и
`declared_2 = 512`. Первые 68 байт — UTF-8 BOM и точный BSL-текст, оставшиеся
444 байта — непрозрачный служебный хвост. Декодер вернул только:
`// protocol-report-baseline-1` и `// protocol-report-manual-change-4`.

## Пара ручных образцов `2 → 3`

Образцы `samples/manual-change-2.json` и `samples/manual-change-3.json`
содержат raw-deflate байты, сохранённые человеком в Конфигураторе. В
распакованном контейнере длиной 1283 байта замена цифры `2` на `3` изменила
BSL ровно в смещении `838` (`0x32 → 0x33`). Одновременно платформа изменила
шесть служебных диапазонов: `110..113`, `230..252`, `437..464`, `590..593`,
`598..601`, `716..719`. Трёхбайтовое значение повторяется в нескольких
местах, а два диапазона содержат связанные Base64-представления.

Это доказывает, что нельзя перепаковывать поток общим writer'ом. Отдельный
fixed-width кодек меняет только первые `declared_1` байт: короткий текст
дополняется пробелами внутри этого поля, хвост и размер члена не меняются.
Рост префикса или структурная правка процедуры явно отклоняются.

## Полный объявленный поток: переменная длина

Нельзя переносить ограничение fixed-width с описанного выше носителя на все
объектные BSL-модули. На рабочем маршруте `upo / фс_Отчеты /
Report.УОП_ПечатьЦенниковАссортимента / .2 / stream:4` подтверждён другой
контейнер: у выбранного BSL-потока `declared_1 == declared_2 == 36101` и
`opaque_tail_bytes == 0`. Это полный UTF-8 поток, а не префикс перед
непрозрачными данными.

Для такого носителя адаптер использует обычный структурный stream writer:
он меняет текст, пересобирает оба объявленных размера в заголовке и сдвигает
только последующие байты контейнера. Локальная обратная проверка целевой
замены `НоваяСтрока.Выбран = Истина;` на более длинный фрагмент дала размер
потока `36101 → 36198`, новый заголовок `36198/36198`, одно новое вхождение и
нулевое старое. Все байты до заголовка выбранного потока сохранились.

Правило выбора кодека: fixed-width применяется **только** если доказан
ненулевой непрозрачный хвост; если `declared_1 == declared_2` и хвоста нет,
безопасна контролируемая замена переменной длины через структурный writer.
Неизвестный или частично декодированный контейнер остаётся заблокированным,
а не переводится в переменную длину по предположению.

## Правило публичного маршрута

Если объектный модуль состоит только из комментариев, это всё равно BSL-модуль:
у него нет маркеров `Процедура`/`Функция`, но его наличие подтверждает
структурный UTF-8-префикс в потоке. Адаптер обязан вернуть владельца и точный
селектор чтения, не заставляя клиента искать поток. При записи он обязан
использовать только fixed-width кодек, а не общий stream writer, который
перезаписывает непрозрачный хвост. Парное обновление `__configinfo` допустимо
только в отдельно подтверждённом каноническом layout.

## Повтор `code.write` после успешной записи

Повтор одного и того же публичного `code.write` не является новой операцией.
До автоматической подготовки `ConfigCASSave` адаптер читает указанную
процедуру в `effective_working`. Если старого фрагмента уже нет, а точный
новый фрагмент присутствует ровно один раз в этой же процедуре, результат —
`status: already_applied`, `applied: false`. В этом случае запрещены и
подготовка saved-state, и новая SQL-запись.

Это правило предотвращает опасный путь: повторный запрос нельзя начинать с
активного `ConfigCAS`, потому что его копирование способно заново построить
рабочую копию из доизменённого источника и скрыть факт уже выполненной
операции. Если оба фрагмента отсутствуют, новый фрагмент встречается
несколько раз либо процедура не подтверждена, идемпотентность не
предполагается: применяется обычная безопасная ошибка `not_found`/
`ambiguous` или диагностика маршрута.

## Цепочка версий `2 → 3 → 4`

Третий live-SQL образец подтвердил повторяемую часть протокола. 20-байтовое
Base64-поле в каждой новой версии равно SHA-1 сырого файла предыдущей версии:
запись `3` хранит SHA-1 записи `2`, а запись `4` — SHA-1 записи `3`. Это
доказанная ссылка версии, а не случайный текст. Его контрольный SHA-1:
`fc84f0a9ef17034f8d82f44c5f9b07064864b524`.

Рядом расположен 16-байтовый токен, который меняется при каждом сохранении и
дублируется фрагментами в трёх служебных местах. Алгоритм его создания не
декодирован: адаптер его не генерирует и не изменяет. Его нельзя считать
основанием для создания или изменения `__configinfo` в hash-keyed overlay.
