mirror of
https://github.com/Nikolay-Shirokov/cc-1c-skills.git
synced 2026-08-13 15:03:20 +03:00
Nick ShirokovandClaude Opus 5
4cceb03269
Компилятор давно принимал короткую форму, а декомпилятор всегда писал самую развёрнутую. Теперь он выбирает самую короткую из применимых, как это делает skd-decompile. Короткая запись стала свойством СПИСКА ЯЧЕЕК, а не строки: cells принимает позиционный список, поэтому строка с height или rowStyle тоже может им пользоваться. Раньше наличие свойств строки лишало её короткой записи — искусственная связка. Если же своих свойств у строки нет, она пишется просто массивом, без ключа cells. Позиционный список опознаётся по наличию элемента-строки или null; список из одних объектов читается как обычный — для простой строки обе трактовки дают один результат. Три дефекта, вскрытых проверкой на потери (каждый раз XML переставал совпадать с прежним, и это приводило к причине): - компилятор двигал позицию на единицу за элемент, поэтому объектный элемент со span: 3 занимал одну позицию вместо трёх и всё правее него уезжало влево. У маркеров ">" этого не было — каждый съедает свою позицию; - проход «удалить неиспользуемые стили» не заглядывал в строки-массивы: у массива нет свойства cells, и стиль, использованный только внутри такой строки, вырезался как неиспользуемый; - в py тот же проход падал на позиционном списке — "style" in c для None бросает TypeError, а для строки делает подстрочный поиск. Плюс ловушка PowerShell: += разворачивает вложенный массив, и строка-массив расплющивалась в список строк — нужна запятая. Проверено: XML на всех 40 макетах пилота совпал с прежним БАЙТ В БАЙТ, то есть сокращение без потерь. Объём декомпилированного JSON меньше на 11%. Тесты 54/54 на обоих рантаймах, гарды зелёные. В WORKFLOW уточнена находка про паритет портов: декомпиляторы расходятся по JSON на 33 макетах из 40, а компиляторы на одном и том же входе — всего на 2. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>