Таблица из пяти записей читалась как меню возможностей и звала писать
apply руками — ровно та развилка, которой мы избегаем в прощающем вводе.
Осталась одна мысль, ради которой это вообще упомянуто: незнакомый ключ
в разобранном макете нельзя удалять «для чистоты» — он несёт состояние
исходного файла.
Перечитал каскад как модель, идущая от задачи, и нашёл три места, где задача
упиралась в пустоту:
- ключ pictureParameter стоял в схеме DSL, но не был описан нигде, а задача
«картинка в ячейке» из индекса вела в drawings.md, где её не было. Добавлен
раздел: picIndex считается с единицы по порядку объявления в pictures,
выравнивания и положение текста — ключи стиля, pictureParameter — ключ ячейки;
- объектная форма rowStyle с модификатором apply нигде не описана, хотя её
пишет декомпилятор: модель, разобравшая чужой макет, встречала непонятный
ключ. Такие формы собраны в mxl-decompile отдельной таблицей — вместе с
controlType "none", пустым valueType, пустой привязкой к раскладке и записью
палитры без картинки;
- область печати и повторение шапки при печати DSL не выражает — теперь это
сказано прямо в print.md, а не выясняется опытным путём.
Индекс задач дополнен колонкой ключей: модель, увидевшая незнакомый ключ
в схеме, сразу находит нужный файл.
Прогнал каждый json-блок инструкций и спецификации через компилятор
и валидатор, фрагменты достраивая до минимального макета. Нашлось:
- пример колоночных раскладок показывал области с "rows": [] — макет
с именованными областями поверх нуля строк, валидатор на нём ругается;
- шапка таблицы в примере SKILL.md была записана пятью объектами с col
там, где хватает позиционного списка строк.
Оба поправлены; раундтрип примера подтверждает, что форма каноническая —
декомпилятор возвращает её же.
Утверждение «короткой формой не задать height и rowStyle» неверно: проверено
компилятором, позиционный список кладётся в cells и уживается со свойствами
строки, включая маркеры > и |. Это форма записи ЯЧЕЕК, а не строки — так
и сформулировано теперь в инструкции и спецификации.
Строка итога в примере переписана короче, заодно показывает эту форму.
Каскад повторял спецификацию: reference/dsl-spec.md был её копией, а styles
и format-properties — копиями двух других файлов документации. Модель, чтобы
что-то сделать, читала спеку целиком.
Теперь в SKILL.md лежит то, что нужно почти всегда: компактный пример
печатной формы, структура DSL, области, строки, ячейки с короткой формой,
rowStyle и оформление из десяти частых ключей. Остальное — по файлу на
задачу: layout, print, drawings, input-cells, groups, notes,
style-properties, каждый 26-81 строка; читать нужно только свой.
Состав ядра выбран по частоте в обычных макетах (корпус без регламентированной
отчётности, которая перекашивала статистику): шрифт 93%, выравнивание 88/87%,
размещение текста 86%, рамки 57-72%, формат 52%; поля ввода и группы, наоборот,
оказались редкими — 7%.
В mxl-decompile переехало то, что относится к чтению чужого макета, а не
к авторингу: пересборка — полная перегенерация, побайтового совпадения ждать
не всегда стоит, и перечень конструкций, которые цикл не переживают.
Оформление и полный перечень свойств стиля жили отдельными файлами, хотя
описывают тот же DSL. Теперь docs/mxl-dsl-spec.md — единственная полная
документация формата, как у остальных семейств навыков: структура,
оформление, колоночные раскладки, перечень свойств.
Ссылки в README и указателе спецификаций сведены к одной строке.
Пустой текст платформа хранит только самозакрывающимся тегом: в корпусе ERP
таких 1 224 460, а из 780 934 непустых блоков нет ни одного, где пусты все
языки. Компилятор же на `text: ""` писал блок с пустым элементом языка —
запись, которой в выгрузках не существует. Теперь любая пустая форма
(строка, пустой объект, все языки пустыми) даёт один и тот же тег, а
декомпилятор возвращает её канонической пустой строкой.
Отсюда же росло расхождение портов. Свёртка текста на пустой карте языков
возвращала null, если ДРУГОГО текста в макете нет вовсе: набор языков
документа при этом пуст. Дальше py писал пропуск колонки, а ps1 наступал
на разворачивание одноэлементного массива — список из одного $null
превращался в $null, и строка целиком уходила в пустые.
Проверено на 12 корпусных макетах: 1411 пустых текстов из 1411 вернулись
на место, JSON портов совпадает.
Ячейка получила третий параметр — pictureParameter, имя параметра, которым
подставляют картинку. Сама картинка задаётся оформлением (picIndex), а этот
тег живёт у ячейки, последним из её параметров, и уживается с текстом.
В корпусе таких ячеек 21 в 9 макетах; теперь все 21 возвращаются обратно.
Прозрачность картинки сведена к одному ключу transparent: false — фона нет,
{ x, y } — прозрачен цвет пикселя с этими координатами. Два способа записи
у платформы исключают друг друга (t принимает только false, включённую
прозрачность выражают tx/ty), так что двум ключам DSL соответствовал один
флажок диалога.
Заодно выровнен порядок ключей в проверке «объект описывает ячейку»: в
py-порте не хватало note.
Одна и та же запись `ref="v8ui:Имя"` стоит и за предопределённой картинкой
платформы, и за общей картинкой конфигурации — по макету источник не
определить. Загрузку это не ломает: платформа ссылку при загрузке не
проверяет, макет со ссылкой на отсутствующую общую картинку принимается.
Заодно снят прежний вывод «tx/ty с ref не встречаются»: на стенде такая
запись есть, координаты идут перед ссылкой. Раундтрип на ней сходится.
Атрибут прозрачности живёт не только у картинки с данными: платформа пишет
<picture t="false" ref="v8ui:Имя"/>, причём t перед ref. Компилятор в этой
ветке его терял, декомпилятор не читал — в «Бухгалтерии предприятия» на
8.3.27 таких записей 67.
Заодно уточнена картина по конфигурациям: t="false" стоит у 11 135 картинок
БП, значения true не бывает нигде — включённую прозрачность платформа
выражает координатами пикселя, и вместе с t они не встречаются.
Одна и та же картинка 25×30 вставлена в стенд дважды: без флажка
«прозрачный фон» платформа пишет t="false", с флажком — tx="24" ty="29",
то есть координату правого нижнего пикселя. Два способа записи исключают
друг друга. Стенд с обоими случаями положен в фикстуры.
Рисунок поверх сетки — картинка, фигура, надпись — теперь описывается в DSL
и возвращается из макета: два якоря «ячейка + смещение», тип, ссылка на
картинку, надпись, расшифровка, имя, порядок перекрытия.
Оформление рисунка разложено надвое: общее (заливка, шрифт, выравнивание)
берётся из именованного стиля, а линия и её стороны — собственные ключи
рисунка. У ячейки таких свойств не бывает: все 2 135 записей палитры с ними
принадлежат рисункам.
Палитра картинок: ссылка на библиотеку платформы, данные base64, пустая
запись «картинка не задана» (151 в корпусе) и координата пикселя прозрачного
цвета (tx/ty — проверено, это не размеры картинки).
Заодно: висячий пустой колонтитул в ps1-порте (пустой словарь в PowerShell
истинен, порты расходились на 3 макетах из 40) и проверка индекса формата
рисунка в mxl-validate.
Стенды Рисунки, Рисунки2, КартинкаВЯчейке проходят раундтрип байт в байт
в обоих портах; на 35 корпусных макетах с рисунками расхождение сократилось
у всех 35.
Оба списка снимались с корпуса ERP и потому отвергали законные значения.
Узоров платформа знает семнадцать («Узор 1» … «Узор 17»), а в корпусе
встречаются только шесть номеров — Pattern4 компилятор отклонял.
Со стилями линии тоньше: палитра одна на документ, но Конфигуратор
предлагает разные наборы в разных местах. У рамки ячейки семь значений
(корпус их покрывал), у линии рисунка — шесть других, и трёх из них
(Dashed, DashDotted, DashDottedDotted) в корпусе нет ни одной. Домен —
объединение обоих наборов.
Обе поправки сняты с диалогов Конфигуратора, а не додуманы по образцу.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Именованная область ссылается на дополнительный набор колонок тегом
columnsID, и эта ссылка терялась целиком: на пилоте кампании она давала
3572 расхождения из 3572 в своей категории, на корпусе таких областей
913 483 прямоугольных, 20 063 полосы строк и 743 полосы колонок.
Ключ namedAreas[].columnSet имеет три состояния: ключа нет — привязка
выводится из накрытых строк (совпадает у 1 021 570 областей корпуса из
1 044 339), "" — привязки нет вовсе, имя набора — явная привязка.
Переопределение обязательно: у областей типа Rows 13 623 повторяют
раскладку строк, а 8 179 её не несут при тех же строках.
Декомпилятор пишет ключ, только когда он не выводится, а область, чья
привязка расходится с раскладкой её строк, уводит из блочной формы в
namedAreas — иначе блоком её не выразить.
Пустая строка тоже попадает в карту «строка → раскладка»: без этого
привязка области, накрывающей пустые строки, не выводилась.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключи header и footer описывают колонтитул: три слота (left, center,
right), общий шрифт и вертикальное выравнивание, признак вывода и
страница, с которой печатать. Ключ printSettings — плоский набор
параметров печати с именами тегов платформы; порядок компилятор
выставляет сам, незнакомый ключ отвергает.
Слот устроен как ячейка: ссылка на формат плюс текст. Текст бывает двух
видов, и это не текст против шаблона, а обычная строка против
форматированной: у форматированной разметка живёт прямо в содержимом
(<b>жирный</>, <fontsize 12>, <colorstyle -16>), поэтому она возится как
есть. Признак вывода и стартовая страница лежат в формате как <height>
и <width>, но читаются только у записи с <height>: палитра
дедуплицирована, и колонтитул без своих настроек ссылается на чужую
запись, где <width> — ширина колонки (637 таких ссылок против 153 своих).
Перенос строки внутри текста колонтитула платформа хранит голым LF при
CRLF во всём остальном файле — единственное такое место в документе,
поэтому содержимое пишется одной строкой вывода.
Формат колонтитула регистрируется до отсева неиспользуемых шрифтов:
иначе шрифт, на который ссылается только колонтитул, выбрасывался бы
из палитры.
Стенд Колонтитулы собирается байт в байт обоими портами и добавлен
в платформенные фикстуры.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Документные ключи rowGroups и columnGroups описывают сворачиваемые
группы: диапазон, имя, признак свёрнутости и расположение заголовка.
Форма плоская, как в формате: вложенность выражена вхождением одного
диапазона в другой. Дерево было бы читаемее, но платформа хранит плоско,
и для правки чужого макета дерево дороже — чтобы добавить группу внутрь
существующей, пришлось бы искать родителя. Частичных пересечений
платформа не порождает (корпус: 40 620 886 пар непересекающихся,
599 958 вложенных, ни одного частичного), поэтому компилятор их
отвергает.
Число уровней вложенности не задаётся: оно совпало с <vgLevels> у всех
1797 макетов корпуса. Порядок записи компилятор приводит к
платформенному — родитель раньше вложенных, по возрастанию начала
(совпало у 1798 макетов из 1798).
Имя группы вывести нельзя, хотя 143 455 имён корпуса выглядят как
автоматические R<номер строки>: 16 666 из них протухли после вставки
строк, а 10 287 групп имени не имеют вовсе. Расположение заголовка взяло
ключ titleLocation — то же свойство и то же имя, что в DSL форм.
mxl-validate: проверка 14 — перевёрнутый диапазон, частичное пересечение,
начало группы за пределами документа.
Стенд Группировки собирается байт в байт обоими портами и добавлен
в платформенные фикстуры.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключ ячейки note описывает всплывающую подсказку: строкой, объектом
языков или полной формой с оформлением, признаком авторазмера и
геометрией окошка.
Из четырнадцати тегов, которые платформа пишет в примечание, настоящей
информации несут пять. drawingType, pictureSize и id — константы на всём
корпусе. Якорь конца это координаты самой ячейки (1087 примечаний из
1087), якорь начала — 1/1 (1085 из 1087, три исключения в одном макете
берёт раундтрип-ключ anchor). Остаётся текст, стиль, autoSize и четыре
смещения, причём autoSize описывает не наличие геометрии, а пересчёт
размера: при true координаты всё равно записаны и осмысленны.
Стиль примечания — обычная запись палитры; без своего стиля пишем тот,
что даёт Конфигуратор (926 примечаний корпуса из 1087). Формат
примечания добавлен в сбор именованных стилей декомпилятора и в перечень
владельцев формата: иначе стиль подсказки вырезался как неиспользуемый и
ссылка оставалась висячей.
mxl-validate: индекс формата примечания проверяется наравне с ячейкой,
строкой и колонкой.
Стенд СПримечанием собирается байт в байт обоими портами и добавлен в
платформенные фикстуры.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В перечне свойств стиля осталось прежнее имя ключа: свойства значения
задаются через valueType и controlType, а не control.
Каскад навыка почищен от того, что нужно раундтрипу, а не автору: ключ
настроек элемента управления и значение "none" остались только в
спецификации, мотивировка «почему значение не приводится к объявленному
типу» заменена самим правилом. Из SKILL.md убрано число свойств стиля —
оно разъезжается с перечнем при каждом пополнении.
Зеркало reference/dsl-spec.md с этого момента не копия docs/: в
спецификации подробности, в инструкции навыка — применение.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключ control возился дословно, но проверялся только косвенно — через
платформенную фикстуру стенда. Теперь у него свои кейсы на обе стороны
(сборка блоба из DSL и раундтрип), строка в описании ячейки с пометкой
«раундтрип, не для ручного авторинга» и проверка в валидаторе: значение
и настройки элемента управления бывают только у ячейки-поля ввода —
на корпусе ни одного вхождения в обычной ячейке.
Проверки ячеек со значением заодно перестали зависеть от наличия таких
форматов в макете: раньше блок целиком пропускался, когда ни одного
формата с признаком значения нет, — то есть ровно в том случае, который
эта проверка и ловит.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключ ячейки value несёт значение, набранное в поле ввода, ключ control —
сериализованные настройки самого элемента управления. Оба живут у ячейки,
а не в палитре формата: у двух ячеек с одинаковым оформлением значения
разные.
Тип значения выражается литералом JSON и приведения к объявленному типу
НЕ делается. Так пишет платформа: ссылочный и составной тип она хранит
строкой, а при смене типа ячейки прежнее значение не переписывает — на
корпусе 560 ячеек объявлены числом, но несут строку. Приведение здесь
означало бы переписывать данные при пересборке. Дата литералом JSON не
выражается, поэтому едет строкой и читается как дата только у ячейки,
объявленной датой.
Настройки элемента управления возим дословно: 26 370 вхождений корпуса
дают всего 163 различных блоба, разбирать структуру незачем. Переводы
строк внутри блоба приводим к LF на чтении — XML-парсеры двух портов
нормализуют их по-разному, и без этого порты давали разный JSON на одном
файле.
Стенд СЗначениями снова собирается байт в байт обоими портами: фикстура
обновлена до версии со значениями, флажком и блобом настроек.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ключ detail описывал ячейку только вместе с param, а платформа ставит
расшифровку самостоятельно: на корпусе ERP 20 404 ячейки несут её БЕЗ
параметра (12 653 пустых, 5 949 с текстом, 1 802 поля ввода) против
8 582 с параметром. Компилятор такую расшифровку молча выбрасывал,
декомпилятор молча не читал, а ячейку, где кроме расшифровки ничего нет,
считал заполнителем строки и терял целиком.
Заодно выправлен порядок тегов ячейки: расшифровка идёт ПОСЛЕ текста,
а не перед ним (корпус: f · parameter · tl|v · detailParameter).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Конфигуратор предлагает флажок только для Булево и Числа, но ограничение
интерфейсное: макет с флажком у строки и у даты платформа принимает и
возвращает GUID дословно — проверено сборкой EPF и обратной выгрузкой
через базу. Поэтому предупреждение, а не ошибка компиляции: собрать
такую ячейку вручную нельзя, и почти наверняка это описка автора.
На корпусе ERP предупреждение не срабатывает ни разу: все семь флажков
стоят у булева.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Тег ячейки <control> и тег формата <controlType> в выгрузке — разные
вещи: первый несёт сериализованные настройки элемента управления, второй
GUID его вида. Ключ DSL описывал второй, а назывался как первый, и при
поддержке настроек отображение стало бы перекрёстным.
Свести их в один ключ нельзя: <controlType> живёт в палитре и разделяется
ячейками с одинаковым оформлением, а настройки принадлежат конкретной
ячейке. Синоним не заводим — он занял бы ровно то имя, которое
освобождается.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Тип значения ячейки и элемент управления переживают цикл компиляции и
декомпиляции. Макет стенда с полями ввода собирается из своего же JSON
байт в байт.
DSL: два ключа ячейки — valueType (грамматика типа семьи: примитивы с
квалификаторами, ссылочные типы, категории целиком, составной через " + ")
и control (input/checkbox, синонимы, GUID для неизвестных элементов, none
для формата вовсе без тега). containsValue отдельным ключом не выражается:
он выводится из наличия типа. Текст и шаблон в такой ячейке запрещены,
параметр и расшифровка допустимы.
Умолчания голых типов взяты платформенные (строка без длины безлимитна,
число без параметров без ограничения разрядности), поэтому эмиттер типа
свой, а не копия meta-compile; resolve_type_str скопирован из эталона
семьи и объявлен в реестре дрейфа. Канон типа в ключе дедупликации
палитры развёрнут: иначе разные написания одного типа дали бы две
одинаковые записи формата и сдвинули бы все ссылки ячеек.
mxl-validate: проверка согласованности таких форматов — тип без признака
значения, ячейка с текстом и значением одновременно, посторонний тег
внутри типа, формат значения у строки или колонки, неизвестный GUID
элемента управления.
Попутно сведены два расхождения портов mxl-validate: py молчал там, где
ps1 писал строку об отсутствии шрифтов, и шапка подробного вывода
печаталась в разной форме.
Версии сведены: mxl-compile 1.41 в обоих портах (было 1.40/1.39).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Сплошной прогон по типам объектов (11 минимальных объектных форм УТ, каждая
заимствована и загружена в UT_DEMO) дал три падения из одиннадцати. Все три —
один класс: в оболочке не хватает того, от чего зависит существование
стандартного поля, и платформа отвергает загрузку «Неверный путь к данным».
1. Справочник с владельцем: «Объект.Owner» не разрешается без <Owners>.
Свойство — список <xr:Item>, а не скаляр, поэтому переносится фрагментом,
как __TypeXml у DefinedType. Одного переноса мало: ссылка должна вести на
объект, который в расширении есть, иначе платформа падает с access violation
вместо сообщения. Добавлен общий проход, заимствующий владельцев (и владельцев
владельцев) — Конфигуратор поступает так же, эталон Issue66Example7_1.
2. Регистр сведений: «Запись.Period» не разрешается без
InformationRegisterPeriodicity. Вместе с ним переносится WriteMode, от
которого зависит «Запись.Recorder» — Конфигуратор несёт оба, 6 эталонов из 6.
3. Задача: «Объект.Исполнитель» — это реквизит адресации, отдельный вид
дочернего объекта. AddressingAttribute добавлен к видам, которые
заимствуются поимённо, рядом с Dimension и Resource.
Правка сделана в Read-SourceObject и Build-BorrowedObjectXml — там, где оболочка
рождается: механизм $extraProps работает только в потоке -BorrowMainAttribute и
обычное заимствование оболочки не покрывает.
Проверено: те же 11 форм грузятся 11 из 11; ПВХ с путём «Объект.ValueType»
грузился и раньше — Конфигуратор Type и CharacteristicExtValues тоже не
переносит (эталон Issue66Example8), правило «свойство, включающее поле»
подтверждается с обеих сторон.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Эталоны Issue66Example7 и 7_1 (три формы, оба режима) показали, что прошлая
правка была неполной в двух местах.
1. Путь на СТАНДАРТНОЕ поле объекта («Объект.Owner», «Объект.Date», «Объект.Ref»)
текстом не разрешается даже при заимствованном основном реквизите: платформа
отвергает загрузку «Неверный путь к данным». Мы такой путь оставляли текстом.
Конфигуратор оставляет ссылку на сам реквизит — «1». Теперь так же: реквизит
объекта (есть в ChildObjects) остаётся читаемым текстом, стандартное поле
сводится к id основного реквизита. Проверено загрузкой: было падение, стало
успешно; выход совпал с эталоном 7_1 дословно.
2. Пути «Items.<Элемент>.CurrentData.<Поле>» при заимствованном основном
реквизите разрешаются текстом — элементы формы на месте, а их данные доступны
через основной реквизит. Конфигуратор их и не трогает. Прошлая правка вырезала
их в обоих режимах, то есть теряла рабочие связи. Теперь вырезаются только без
заимствования основного реквизита, где они действительно не разрешаются.
Уточнение по кодировке для будущей работы: без заимствования Конфигуратор
кодирует стандартное поле как «1/-N» (Owner у справочника и Ref у документа
дали -5, Date у документа -3), а Items-путь — как
«<id элемента>:02023637-7868-4a5f-8576-835a76e0c9ba/0:<uuid поля>». Таблицу
отрицательных индексов по трём точкам не построить, поэтому в скелетном режиме
обе разновидности по-прежнему вырезаются с предупреждением.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прогон verify-snapshots вскрыл, что два новых кейса опирались на вход, который
платформа не принимает — падала конфигурация-источник, а не расширение.
form-choice-link-items: путь «Items.Ячейка.CurrentData.Склад» был невалиден,
потому что Ячейка — поле ввода, а не таблица. Кейс пересобран на настоящей
табличной части: путь корректен, связь по-прежнему вырезается, фикстура
грузится. Кейс продолжает падать на коде до правки.
form-choice-link-dangling: вход намеренно содержит путь на несуществующий
реквизит объекта — в валидной конфигурации такой формы не бывает, а проверяется
именно поведение навыка на таком пути. Помечен skipPlatformVerify с причиной.
После правок verify-snapshots --skill cfe-borrow: 21 прошло, 0 упало,
1 пропущен по объявленной причине. cfe-validate — 7 из 7.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Третий и последний класс дефектов из ишьи #66, единственный, который валит
загрузку. Rewrite-ChoiceParameterLinks переписывал только пути от «Объект.»;
ссылка с корнем-реквизитом ФОРМЫ проходила текстом, а реквизиты формы не
заимствуются никогда — путь не разрешался:
Неверный путь к полю - Помещение
Неверный путь к полю - Склад
Неверный путь к полю - ОтборСклад
Связь с постскриптумом репортёра прямая: в эталоне JR2976 ссылка
«ИспользоватьСоглашенияСКлиентами» — то самое имя из его сообщения —
закодирована как «51». В корпусе УТ таких форм 103, путей 424 из 1015.
Правило подтверждено на шести расширениях от Конфигуратора (Issue66Example4/5/6,
JR2433, JR2976, JR49904): подставляется id реквизита ИСХОДНОЙ формы. Именно
исходной — Issue66Example6 показывает, что даже с заимствованными реквизитами
формы (id 1000002/1000003) ссылки продолжают указывать на 4 и 5, то есть в
нумерацию базовой формы. Переписывать нужно в обоих режимах: реквизиты формы не
заимствуются ни при Form, ни при All, поэтому гейт «только без основного
реквизита» снят.
Путь «Объект.X» при заимствованном основном реквизите оставлен текстом:
он разрешается (проверено загрузкой и UpdateDBCfg) и читается. Конфигуратор
нормализует и его, но копировать обфускацию там, где она не нужна, незачем.
Зашитая единица в «1/0:<uuid>» заменена на реальный id основного реквизита
исходной формы.
Путь, который не сводится ни к одному известному виду, теперь вырезается с
предупреждением, а не остаётся текстом. Сюда попадают
«Items.<Элемент>.CurrentData.<Поле>» (303 в УТ): их кодировка непрозрачна и по
имеющимся эталонам не воспроизводима. Проверено — с таким путём форма не
грузилась вовсе; без связи заимствуется и работает. Связь параметров выбора —
удобство подбора, а не данные.
Проверено на UT_DEMO: расширение с обеими формами грузится и применяется к БД,
значения ссылок совпадают с эталонами (4, 5, 2) в обоих режимах и обоих портах.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Расшивание корня путей (8366dd49) включило проверку 14 на формах списка, и она
дала ложные ошибки на реальных формах: 'Список.DefaultPicture' и
'Список.ПредставлениеСостояния' объявлены висячими, хотя форма валидна.
У динамического списка набор полей — результат его запроса, а не состав
объекта: туда входят и стандартные поля списка, и псевдонимы запроса. Сверять
такие пути с ChildObjects нельзя в принципе. Корпусная проверка: на 1094 формах
списка УТ таких сегментов 3383 — DefaultPicture (1009), Ref (551), Date (341),
Number (331), Description (311) и псевдонимы вроде ПредставлениеСостояния.
Проверка 14 теперь пропускает формы, у которых основной реквизит —
динамический список. Проверка 12 и тексты сообщений параметризацию сохраняют:
там корень берётся из атрибута table=, и он совпадает с основным реквизитом в
339 случаях из 389, а в остальных не совпадал и до правки.
Кейс на висячий путь формы списка снят — его посылка была неверной; вместо него
кейс на отсутствие ложных ошибок, он падает при снятии гарда.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проверки 12 (<AdditionalColumns table="...">) и 14 (пути против конфигурации-
источника) искали пути регуляркой, зашитой на корень «Объект». Он такой только
у формы объекта: у формы списка «Список», у формы записи регистра «Запись».
На таких формах регулярка не совпадала, и обе проверки молча не срабатывали —
валидатор рапортовал «чисто» на форме с висячим путём.
Корень теперь берётся из основного реквизита: сначала из <Attributes> самой
формы, затем из <BaseForm>. Нет его нигде — путей с корнем не бывает, проверка
пропускается. Имя подставляется и в регулярки, и в тексты сообщений: раньше в
сообщении стояло «Объект.X» независимо от формы, что дезинформировало.
Вместе с этим набор имён-кандидатов проверки 14 расширен с Attribute/
TabularSection до Dimension/Resource. Без этого замена корня превратила бы
тихий пропуск в ложные ошибки на форме записи регистра, где дочерние объекты —
измерения и ресурсы; отдельный кейс это фиксирует.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проверка 11d искала висячие пути регуляркой, зашитой на корень «Объект».
Он такой только у формы объекта: у формы списка корень «Список», у формы
записи регистра «Запись». На таких формах регулярка не совпадала, и проверка
молча не срабатывала — валидатор рапортовал «чисто» на форме, которую
платформа отвергает с «Неверный путь к полю».
Узел основного реквизита BaseForm проверка уже доставала строкой выше, но
использовала только как булев признак. Теперь из него берётся имя — и для
регулярки, и для текста сообщения. Если основного реквизита нет и в BaseForm,
корень неизвестен и поведение остаётся прежним.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Заимствование дочерних объектов в оболочку шло по трём источникам имён:
*DataPath, <Field> и <AdditionalColumns table=...>. У формы списка с ручным
запросом реквизиты упомянуты ещё и в тексте запроса, и они не заимствовались:
на эталоне Issue66Example2 навык брал 5 реквизитов и 0 табличных частей,
Конфигуратор — 17 и 4.
Правило выведено по эталонам и совпадает с ними в обе стороны: Конфигуратор
переносит то, на что ссылается форма, а у динамического списка с ручным
запросом текст запроса — такое же место ссылки, как DataPath. Имена, которые
встречаются в <QueryText> целым словом, — это 21 из 27 дочерних объектов, и
множество совпадает со взятым Конфигуратором точно.
Разбирать язык запросов не нужно: имена-кандидаты и так фильтруются по
реальному составу объекта, поэтому лишние слова из запроса безвредны.
Состав оболочки теперь совпадает с эталонами на всех четырёх случаях:
форма документа 47 реквизитов и 2 ТЧ, список с запросом 17 и 4, список без
запроса 3 и 0 (Issue66Example3 — там правило «только видимое на форме», и
поведение не меняется), форма записи регистра 3 измерения и 1 ресурс.
По корпусу (13796 форм УТ + ERP) списков с запросом 2584, без него 2411.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Кейсов на эти сценарии не было ни одного, поэтому оба дефекта жили молча.
Фикстура main-attr-kinds: документ с табличной частью и тремя формами
(документа, списка с динамическим списком и <Settings>) плюс регистр
сведений с измерением и ресурсом и его форма записи.
Три кейса:
- форма списка с -BorrowMainAttribute: реквизит «Список» типа DynamicList
переносится вместе с <Settings>, пути «Список.*» не вырезаны, «Объект» и
придуманного <SavedData> в выходе нет;
- форма записи регистра: реквизит «Запись» нужного типа, а в оболочке
<Dimension>/<Resource>, а не <Attribute>;
- повторное заимствование по объекту с табличной частью: второй заход
добавляет недостающий реквизит, ТЧ не вложены друг в друга.
Все три падают на коде до правок и проходят после.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Реквизит синтезировался с зашитыми name="Объект", типом <Тип>Object и
SavedData=true, а сверху доклеивались «довески» исходной формы. Для формы
списка это давало реквизит «Объект» объектного типа с настройками
динамического списка внутри, и платформа отвергала файл: «Исключение XDTO
произошло при чтении файла». Навык при этом отрабатывал молча, exit 0.
По корпусу (8675 форм с основным реквизитом, УТ + ERP) объектных только 4074:
динамический список — 3847, менеджер записи — 546, xs:string — 108, набор
констант — 97. <Settings xsi:type="DynamicList"> встречается ровно у
динамических списков, 3847 из 3847.
Эталоны Конфигуратора дают единое правило для всех видов: реквизит копируется
из исходной формы дословно, меняется только id. Теперь так и делается, а
вычисление типа из таблицы GeneratedType уходит вместе с тихим сбоем
«нет категории Object → cfg:.Имя» для перечислений, констант и регистров.
Следом расшиты ещё три места, зашитые на литерал «Объект»:
- вырезание путей к данным — корень берётся из имени основного реквизита,
иначе у формы списка вырезало бы все пути «Список.*»; путь ровно на сам
реквизит («Список» у таблицы формы) тоже сохраняется;
- сбор путей для заимствования дочерних объектов — на необъектных формах не
находил ничего, и в оболочку не попадало ни одного реквизита;
- вид дочернего объекта: измерения и ресурсы регистра переносятся как
<Dimension>/<Resource>, а не все как <Attribute>.
Проверено на трёх эталонах (форма документа, форма списка, форма записи
регистра): основной реквизит, корни путей к данным и виды дочерних объектов
оболочки совпадают. Расширение с формой списка и формой записи грузится в
UT_DEMO и применяется к БД — до правки загрузка падала.
Снапшоты: <Type> у основного реквизита теперь многострочный, как у
Конфигуратора; синтез писал его в одну строку.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Заимствованное содержимое вставлялось текстом по ВСЕМ вхождениям
<ChildObjects>, а у объекта с табличными частями свой контейнер один, но
вхождений столько же, сколько ТЧ. При повторном заимствовании по тому же
объекту ps1 выдавал невалидный XML («mismatched tag»), py — валидный, но с
табличными частями внутри табличной части и дублем ТЧ.
Отдельно ветка «Replace empty ChildObjects» в ps1 переписывала КАЖДЫЙ блок
содержимым первого — теряла данные.
Свой <ChildObjects> закрывается в файле последним: объект в файле один,
вложенные ТЧ закрываются раньше. Правило вынесено в общую функцию каждого
порта, на неё переведены все места вставки.
Дедуп при повторном заимствовании брал имена регуляркой «первый
<ChildObjects> до первого </ChildObjects>» — у объекта с ТЧ этот отрезок
обрывается на закрытии первой ТЧ: захватывает имена её колонок и теряет всё,
что идёт после. Заменён разбором прямых детей своего контейнера. В py дедуп
дополнительно сканировал все <Name> во всём файле, включая имя самого объекта.
Проверено: два заимствования подряд по одному документу дают в обоих портах
валидный XML, 5 табличных частей на верхнем уровне, вложенности и дублей нет;
выходы портов отличаются только свежими uuid.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PS вставлял лишнюю строку с табуляцией перед первым <Attribute>, когда
дозаписывал реквизиты в заимствованную оболочку с самозакрытым
<ChildObjects/>: элемент раскрывался пробельным узлом в DOM, а последующая
текстовая вставка добавляла отступ ещё раз. У Конфигуратора в таких файлах
пустых строк нет ни одной, py-порт делал правильно.
PS сведён к тому же текстовому раскрытию, что и py. Расхождение портов на
Document.ВнутреннееПотребление (-BorrowMainAttribute Form) закрыто: выходы
отличаются только свежесгенерированными uuid.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В фикстурах cfe-borrow CommandSet не встречался ни разу, поэтому потеря
свойств не ловилась. Добавлена фикстура doc-form-commandset — форма документа
с реальным порядком секций (CommandSet, затем AutoTime/UsePostingMode/
RepostOnWrite), вложенным CommandSet у таблицы, RowPictureDataPath от Объект.
и CommandInterface. Форма собрана файлом, а не form-compile: тот выдаёт
свойства ДО CommandSet, то есть как раз не тот порядок, который нужен.
Два кейса над ней — заимствование без основного реквизита и с ним. Оба падают
на коде до правки и проходят после.
README: задокументированы ключи expect fileContains/fileNotContains/filesEqual,
которые раннер понимает, но в таблице их не было. Плюс предупреждение, что
подстрока сверяется буквально: ожидание "<CommandSet></CommandSet>" не
срабатывает на переводе строки внутри и потому не проверяет ничего.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Свойства уровня формы собирались до первой «визуальной» секции. В этот
список входил CommandSet, который в реальных формах стоит В СЕРЕДИНЕ блока
свойств: у всех 794 форм документов ERP с CommandSet он предшествует
AutoCommandBar, а AutoTime/UsePostingMode/RepostOnWrite идут после него.
Отсечка теряла весь хвост — в одном ERP это 2062 формы.
Отказа загрузки это не давало: платформа принимает форму и молча подставляет
дефолты. На Document.ЧекККМ.ФормаДокумента (УТ) AutoTime DontUse становился
CurrentOrLast, UsePostingMode Regular — Auto; исключённые стандартные команды
(Провести, Записать, Отменить проведение) возвращались в панель.
Граница теперь — AutoCommandBar: он есть в 100% из 30223 форм корпуса, и ни
одно свойство никогда не стоит после него. Отбрасываются явным списком
Events/Attributes/Commands/Parameters/CommandInterface и свойства, значение
которых — имя реквизита формы (ReportResult, DetailsData, VariantAppearance,
GroupList): реквизиты не заимствуются, ссылка повисла бы.
Заодно разобран конфаунд коммита 7abe26af, менявшего три вещи разом с одной
атрибуцией ошибки. По эталонам Конфигуратора («Добавить в расширение»):
- корневой CommandSet переносится дословно — вырезание было ошибкой;
- вложенный CommandSet выбрасывается ЦЕЛИКОМ, а не опустошается до пустого
контейнера, как делалось;
- RowPictureDataPath — путь к данным, а не индекс картинки: сохраняется при
заимствовании основного реквизита (Объект.Товары.РасхождениеЗаказ) и
вырезается без него (Список.DefaultPicture). Переехал в formBindingDataTags.
Спецификация форм утверждала, что свойства идут до CommandSet/AutoCommandBar —
именно это заблуждение и было закодировано. Заменено фактическим порядком
секций, выведенным из корпуса (0 нарушений на 30223 формах). Там же поправлены
значения перечислений AutoTime/UsePostingMode/ReportFormType, которых в корпусе
нет ни одного.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Фикстуры roundtrip-кейсов объявляли формат 2.17 (это 8.3.24) и при этом режим
совместимости Version8_3_27. Из-за этого verify-snapshots на автодетекте платформы
(8.3.24) не мог загрузить их вообще: «Для работы с конфигурацией необходима версия
платформы не меньше, чем 8.3.27». Падение выглядело регрессией навыка, а было
свойством фикстуры, и платформенная верификация девяти кейсов молча не работала.
Режим приведён к формату (Version8_3_24) во всех девяти фикстурах — они дублируются
по навыкам и обязаны оставаться копиями. Эталоны пересняты точечно: дифф —
ровно две строки на файл.
verify-snapshots без --v8path: role-compile 13/0, cf-edit 14/0, meta-edit 20/0,
meta-compile 79/0, subsystem-edit 9/0, xdto-compile 12/0.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прогон verify-snapshots вскрыл, что три новых кейса не доезжают до платформы:
роль ссылается на объекты, которых нет в фикстуре и которые не создаёт ни один
навык (веб-сервис, внешний источник данных, перерасчёт), а фикстуры валидатора —
это только каталог Roles/ без Configuration.xml. Объявлены skipPlatformVerify
с причиной, чтобы пропуск был видимым, а не молчаливым.
expect.filesAbsent внесён в таблицу ключей README: недокументированный ключ,
который понимает только один раннер, даёт тихую дыру.
Проверено: verify-snapshots на 8.3.27 — role-compile 13/0/1, role-validate 5/0/2;
число пропусков сверено с expected-skips на обеих ОС и обоих портах.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Неизвестный тип объекта обрабатывался веткой «warning» и всё равно попадал в
Rights.xml: и генератор, и валидатор рапортовали успех. Блок прав на тип, который
прав не имеет, платформа не отвергает — конфигурация с правами на перечисление не
загружается в информационную базу, конфигуратор зависает без сообщений.
Белый список — дерево редактора ролей: 27 типов (добавлен ExternalDataSource,
которого не было ни в одной таблице) плюс таблица видов вложенности с наборами прав
и привязкой вида к типу-родителю. Значения сняты с корпуса (acc/erp/ut/unf, ~2750
ролей) и с выгрузок роли со всеми проставленными правами — для внешнего источника
данных и перерасчёта регистра расчёта, которых в корпусе нет.
- role-compile: отказ ДО записи файлов, все причины разом, exit 1; ни файлов роли,
ни записи в Configuration.xml. Русские алиасы для типов без прав — ради внятного
отказа, а не ради генерации.
- role-validate: те же случаи — ошибка вместо предупреждения.
- Побочно снято 424 ложных предупреждения на корпусе: права Use у операций
веб-сервисов и методов HTTP-сервисов считались недопустимыми для вложенных объектов.
- Проверка имён прав и вложенных путей больше не пропускает мусор: неизвестное право
и путь вида Enum.Х.Attribute.Y раньше не проверялись вовсе.
- docs/1c-role-spec.md: ExternalDataSource ошибочно числился типом без прав.
- dsl-reference.md переписан под «что можно написать» (тип → права, виды
вложенности) вместо таблиц прощающего ввода.
Тесты: expect.filesAbsent в раннере; новые кейсы на отказ и на вложенные объекты.
Починены кейсы, которые ничего не проверяли: три задавали права одной строкой
"Read View" (навык писал в эталон несуществующее право), valid-role собирал роль
неизвестным ключом и валидировал пустую, bad-root проходил на «файл не найден».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа 8.3.23 доустановлена, замер тем же способом (пустая ИБ создаётся и выгружается
одной платформой) дал 2.16 — сообщение из issue #63 подтверждено собственным измерением,
пометка «по issue #63» из таблицы снята.
Незамеренными остались только 8.3.21/8.3.22, и пробел зажат с обеих сторон: 2.13 на 8.3.20
и 2.16 на 8.3.23 — ровно +3 версии на 3 релиза, то есть равномерный шаг подтверждается
арифметически.
Заодно расщепилась дельта пустой конфигурации ниже 2.17, которая раньше была снята одной
точкой: AllowedIncomingShareRequestTypes приезжает ровно в 2.17, DatabaseTablespacesUseMode
и DefaultReportAppearanceTemplate — где-то в 2.14–2.16. Гейт по версии ни одному из них не
нужен: это свойства корня конфигурации (реестр meta-validate — про объекты), а внутри
проверенного диапазона все три существуют всегда.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
«Не использовать» в Конфигураторе хранится как версия ТЕКУЩЕЙ платформы: свежая база
получает Version8_3_<своя> (замерено на 8.3.20/8.3.24/8.3.25/8.3.27/8.5.1), и ни одна из
пяти типовых в корпусе DontUse не содержит. Само значение легально — платформа принимает
его без ошибок, — но не выживает: на 8.3.25 и на 8.3.27 выгрузка возвращает Version8_3_8.
Контроль: тот же шаблон cf-init с явным Version8_3_25 роундтрипится без изменений.
Отсюда предупреждение, а не запрет: запрещать значение, которое платформа принимает, —
то же самое, от чего мы только что ушли в -FormatVersion. Канал тот же (stderr, exit 0),
что и у предупреждения о версии формата.
Абзац про DontUse убран из SKILL.md: инструкция читается всегда, а ловушка актуальна почти
никогда, и текст сам ЗНАКОМИЛ модель со значением, которое выбирать не следует.
Сравнение регистронезависимо явно в обоих портах: в PS -eq таков по умолчанию, в py — нет,
и молчаливое расхождение портов началось бы прямо здесь.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Счётчик был один: несобранное окружение давало «1 НАРУШЕНИЙ инварианта uuid» и
отправляло искать баг там, где его нет. Счётчики разведены, exit по-прежнему 1
в обоих случаях — непрогнанный порт это не «зелено».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Гард запускает навыки в обоих портах и зашивал `powershell.exe` и `python`. Вне Windows
он падал с «spawnSync powershell.exe ENOENT» и красил весь check-all, хотя PowerShell на
маке не исполняется в принципе — это природа платформы, а не пробел в покрытии.
PowerShell отсеивается по ОС с явной строкой о пропуске; интерпретатор python на *nix —
python3. Если запрошен только powershell и ОС не Windows, выходим с 1: молча зеленеть,
ничего не проверив, хуже, чем упасть.
Гард запускает НАВЫКИ, а им нужен интерпретатор с lxml — системный python3 на маке его не
имеет. На ошибке импорта печатается подсказка про PYTHON=<venv>, иначе окружение читается
как нарушение инварианта.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
«skipped» — норма, а не падение, но само число ни о чём не говорит, пока не с чем сверить,
а запоминать его нельзя: оно растёт с набором кейсов. Прежняя сверка жила в личной памятке
как grep по 'external:|runtimeOnly|osOnly' и уже сломалась — она считает скипом ЛЮБОЙ osOnly,
а posix-кейсы фейка платформы на маке как раз выполняются (grep давал 67 против 59 реальных).
Скрипт повторяет правила гейтинга раннера и живёт рядом с ним, поэтому расходиться им негде.
--list печатает пропуски поимённо с причиной. Сверено: win32/powershell 8, win32/python 11,
darwin/python 59 — совпало с прогонами.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Значение /Out несёт кавычки внутри токена — это соглашение 1С (run_v8 передаёт
File="путь" так же). В batch их снимает %~2, поэтому win32-фейк работал; в sh
их надо снять явно, иначе cp целится в имя файла с кавычками и лог не появляется.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Кейсы детектора были написаны на batch-фейке и потому гейтились osOnly: win32. На маке
py-порт единственный, то есть ровно там, где проверять важнее всего, детектор оставался
без автоматического покрытия.
Добавлен sh-фейк и восемь зеркальных кейсов (osOnly: darwin/linux, runtimeOnly: python).
Для этого потребовались два расширения DSL:
- `writeFile.executable` — на *nix навык запускает платформу через exec, и файл без бита
исполнения не стартует вовсе; Node пишет файлы без +x. На Windows chmod — no-op.
Реализовано во всех трёх местах разбора шага (оба в runner.mjs и в verify-snapshots.mjs):
ключ, который понимает только один раннер, даёт тихую дыру.
- `osOnly` принимает массив, а не только строку. Иначе darwin и linux требовали бы двух
копий одного кейса.
Оба ключа описаны в tests/skills/README.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа рапортует об успехе (exit 0) и одновременно пишет в /Out-лог, что часть
метаданных отброшена. Детектор этого был только в db-load-xml, хотя db-load-git гоняет
тот же /LoadConfigFromFiles (и дописывает /UpdateDBCfg в тот же вызов), а db-update —
вторую половину той же цепочки. Оба лог печатали, но не разбирали.
Детектор извлечён в Find-SilentRejections / find_silent_rejections и внесён в реестр
семей check-inline-drift: инлайн-код гард сверять не умеет, а именно расхождение копий
и было бы главным риском такого дублирования.
Добавлен восьмой паттерн — «Для работы с конфигурацией необходима версия платформы не
меньше». Замерено при работе над issue #63: конфигурация с режимом совместимости выше
платформы грузится с кодом 0, db-update тоже отвечает 0, объекты в базу не попадают, а
отказ приходит только в рантайме. Строка обрезана до инвариантной части — конкретная
версия в сообщении меняется.
Текст предупреждения переписан. Убрана подсказка «pass -StrictLog to treat as error»:
ключ предназначен для регрессов (его передаёт verify-snapshots), а совет бессмысленный —
операция уже выполнена, и повторять её ради того же текста незачем. Формулировка больше
не утверждает «dropped properties/refs»: класс проблемы разный, а строки лога печатаются
следом и говорят за себя.
Две правки по дороге:
- `return ,$found` в паре с `@()` у вызывающего давал массив из одного пустого массива,
то есть предупреждение «1 problem(s)» на чистом логе. Возврат без запятой-обёртки.
- py-порт писал предупреждение в stderr, PS1 — в stdout. В самом py-порте stderr занят
исключительно фатальными «Error:» перед exit 1, так что не-фатальное предупреждение там
было единственным исключением. Приведено к stdout — и к соглашению своего же файла, и к
поведению PS1; verify-snapshots на падении читает `stderr || stdout`, поэтому диагностика
не теряется.
Тесты: фейковая платформа .cmd, которая вычитывает путь из /Out и кладёт туда готовый лог,
— по четыре кейса на db-load-xml и db-update (отбраковка, она же под -StrictLog, новый
паттерн, чистый лог без предупреждения). Раньше детектор не был покрыт вообще.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Допустимый список версий был независимым литералом в десяти файлах, и сверять его
было не с чем. Именно так волна 2.21 прошла по четырём валидаторам и молча обошла
пятый — form-validate остался на 2.17–2.20 (issue #63).
check-format-versions.mjs держит три инварианта: границы диапазона одинаковы во всех
навыках и на обоих портах; дефолт -FormatVersion у *-init лежит внутри диапазона;
верхняя граница совпадает с последней ЗАМЕРЕННОЙ ступенью таблицы §7.1 из
1c-configuration-spec.md — так расхождение спеки и кода падает здесь, а не на чужой
выгрузке. Отдельно ловится возврат ValidateSet/choices в *-init.
Get-FormatRank разъехался бы по восьми новым копиям — они внесены в реестр семьи
format_rank в check-inline-drift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
