Платформа рапортует об успехе (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>
Заглушечная конфигурация зашивала version="2.17" и CompatibilityMode=Version8_3_24
независимо от собираемых исходников. Ограничение платформы одностороннее — она читает
формат не новее себя, — поэтому на 8.3.20 такая заглушка не грузилась вовсе:
«Неизвестная версия формата 2.17 загружаемого файла».
Режим совместимости бил тише и потому опаснее: платформа рапортовала успешную
загрузку с кодом 0, писала в лог «Для работы с конфигурацией необходима версия
платформы не меньше, чем 8.3.24» и не создавала объекты — сборка падала уже на
«Неизвестное имя типа», уводя диагностику в сторону.
Оба значения выводятся из версии исходников. Для версии взят min(исходники, 2.17):
заглушке нужна самая низкая работающая версия, а не версия исходников, поэтому на
2.17+ поведение остаётся прежним и опускается только под 2.13–2.16. Режим — по той же
лестнице.
Проверено на живой платформе: обработка 2.13 со ссылочным реквизитом собирается на
8.3.20 обоими портами; для исходников 2.17 заглушка по-прежнему 2.17/Version8_3_24.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Валидаторы объявляли «ожидаемым» литеральный список версий и ругались на всё
остальное как на подозрительное. Но 2.13–2.16 не подозрительны — они просто не
проверялись, а form-validate вдобавок отстал на 2.21 и предупреждал о форме, которую
сам же создаёт цепочкой epf-init 2.21 → form-add (issue #63).
Теперь сравнение числовое, через общий Get-FormatRank, и исходов три: ниже 2.17 и
выше 2.21 — предупреждение «not verified on it», нечисловое значение — ошибка. Раньше
мусор вида «abc» и реальная версия 2.16 давали одно и то же предупреждение.
В *-init ValidateSet/choices сняты: версия вне диапазона больше не запрет, а
предупреждение в stderr — скаффолд выпускается. Опечатка (2,17) остаётся ошибкой.
Предупреждение печатается напрямую в stderr и после настройки кодировки консоли:
Write-Warning в PS 5.1 уходит в stdout, получает локализованный префикс и перенос по
80 символов, а до [Console]::OutputEncoding em-dash уезжал в вопросы — оба расхождения
ломали паритет с py-портом.
Отдельно в cf-init исправлен гейт TextToSpeech: свойство приезжает форматом 2.18
(8.3.25), а не 2.21. Замер: выгрузки пустой ИБ шести платформ — 37 записей
UsedMobileApplicationFunctionalities на 2.13/2.17 и 38 на 2.18–2.21. Ролики загрузки
показали, что это настоящее новое свойство, а не смена дефолта эмиссии: на 2.17 тег
роняет загрузку XDTO-ошибкой (8.3.24), значение значимо (true переживает роундтрип),
а пропуск на 2.18+ разводит роундтрип — платформа допишет тег сама. Снапшоты трёх
кейсов meta-compile обновлены: их фикстуры строятся cf-init, дельта — только вставка
тега.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
execSkillAsync отдавал только stdout, а stderr сохранялся исключительно в ветке
ошибки. Поэтому предупреждение навыка, который отработал успешно (exit 0), проверить
было нечем: кейс мог убедиться лишь в том, что навык не упал, — то есть в молчании
вместо текста.
Резолв теперь отдаёт оба потока, добавлен ключ expect.stderrContains.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Утверждение «2.17 = платформы 8.3.20–8.3.24» повторялось в 7 местах и было неверным:
точка «8.3.20» получена не замером, а из имени каталога cfsrc/acc_8.3.20, который
побайтово совпадает с acc_8.3.24 (91807/91807 файлов; обе — БП 3.0.181.31 с режимом
Version8_3_24, который 8.3.20 открыть не может). Интерполяция между двумя одинаковыми
точками и дала мнимый интервал.
Замер пустыми ИБ на шести установленных платформах (создать базу платформой X и
выгрузить ею же): 8.3.20 → 2.13, 8.3.24 → 2.17, 8.3.25 → 2.18, 8.3.26 → 2.19,
8.3.27 → 2.20, 8.5.1 → 2.21. Версия меняется каждым релизом.
Полная лестница теперь в одном месте — §7.1 1c-configuration-spec.md, с колонкой
«замерено»: 8.3.21/8.3.22 не проверялись, 2.16 подтверждена только сторонним
сообщением. Остальные спеки на неё ссылаются.
Заодно сняты два вывода, выведенных из каталога-дубля: «содержимое Form.xml идентично
между 8.3.20 и 8.3.24» и строка «8.3.20 | 2.17 | Базовая» в спецификации ролей.
Дописан 2.21 в таблицы, которые о нём не знали, и уточнён TextToSpeech: он приезжает
в 2.18, а на 2.17 роняет загрузку XDTO-ошибкой, а не отбраковывается молча.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Сквозной прогон (собрали расширение навыками → загрузили → обновили БД →
выгрузили обратно) показал: записанный нами <FoldersOnTop> из выгрузки
пропадает. Платформа его у заимствованной оболочки не хранит — принимает
молча и выбрасывает. Соседние свойства того же списка (Hierarchical,
CodeLength, DescriptionLength, CodeType, CodeAllowedLength) сохраняются,
так что дело именно в этом свойстве. Эталон Конфигуратора его тоже не
переносит.
Список propsToExtract собирался на глаз при появлении -BorrowMainAttribute;
это второе свойство из него, которое платформа не принимает (первым был
NumberPeriodicity, ронявший UpdateDBCfg).
Одноразовый прогонщик сценариев — debug/roundtrip/ (в .gitignore).
Регресс cfe-borrow 12/12 на обоих рантаймах, гарды зелёные.
Корпусный прогон (УТ/БП/ERP, 21 097 форм) после понижения Command/Action
оставлял 8 форм с ошибками. Разобраны все, дефектов оказалось два.
1. Вложенная таблица. Путь Items.<Таблица>.CurrentData.<Поле> разрешался
ОДНИМ шагом: если таблица сама привязана через Items.*, корнем
оставался литерал «Items», и типовая форма объявлялась битой
(НастройкаПравилОбработкиЗаявокСотрудников в БП и ERP). Теперь
разрешение идёт цепочкой, со страховкой от кольца ссылок.
2. AutoCommandBar с обычным id вместо -1. Это соглашение, а не требование:
21 094 формы из 21 097 используют -1, но три платформа выгружает с
обычным id и грузит их без нареканий. Понижено до предупреждения;
ошибка осталась на случай, когда id вообще не число.
Оставшиеся три формы — дубли id элементов и команд. Это НЕ ложные
срабатывания: измерение по корпусу показало ровно по одному случаю на
21 097 форм, то есть опечатки вендора, а не структурное правило (были бы
пулы id раздельными, пересечений были бы тысячи). Плюс кейс duplicate-id
прямо требует считать дубль ошибкой.
Итого по корпусу: 283 формы с ошибками → 3.
Заодно дооформлена фикстура cfe-borrow/container-types (пространство имён
веб-сервису, документ журналу и последовательности): verify-snapshots по
cfe-borrow теперь 12/12.
Проверка версии читала Configuration.xml собственной регуляркой. Отсюда два
пробела: форма автономной внешней обработки не проверялась вовсе (своего
Configuration.xml у неё нет, версию несёт корень обработки), а разбор
дублировал уже существующий эталон.
Теперь используются копии общих эталонов — detect_format_version (авторитет
form-compile) и support-guard: is_external_root (авторитет cf-edit), оба
навыка добавлены в реестр check-inline-drift.
Попутно вскрылось следствие для соседней проверки: обработка, чьи исходники
лежат внутри дерева с Configuration.xml (обычная раскладка src/cf рядом с
src/epf), считалась «конфигурационным контекстом», и Check 12 ругался на её
собственные External*-типы. Теперь климб останавливается на ближайшем
якоре — том же правиле границы автономного объекта, что в support-guard.
Плюс паритет: PS отчитывался «Data bindings: none», PY эту ветку не имел.
Кейс на EPF-контекст добавлен. Регресс 16/16 на обоих рантаймах, корпус
21 097 форм без новых срабатываний, гарды зелёные.
Обе проверки — про ошибки, которые делает не платформа, а тот, кто пишет
XML руками. Обе вскрыты на наших же фикстурах, обе платформенно-фатальны:
файл не читается вовсе, а прежний валидатор говорил OK.
Check 13 — префикс в значении типа обязан резолвиться. `cfg:CatalogRef.X`
в <v8:Type> при незадекларированном xmlns:cfg даёт «Исключение XDTO при
чтении файла». Область видимости считается по узлу, а не по корню:
локальная xmlns на элементе законна и в типовых встречается (d4p1, mxl).
Check 14 — версия формата формы против версии конфигурации. В пределах
одной выгрузки версия едина; форма из более новой выгрузки даёт
«Неизвестная версия формата N загружаемого файла».
Ложных срабатываний нет: корпус УТ/БП/ERP, 21 097 форм — те же 8 форм с
ошибками, что и до правки. Регресс 15/15 на обоих рантаймах, паритет
портов сверен построчно.
verify-snapshots считает фикстуру готовой конфигурацией и грузит её в базу,
а фикстуры form-validate состояли из одного Form.xml — поэтому по этому
навыку верификация падала целиком и по факту не выполнялась никогда.
Что вскрылось при доведении, по нарастающей:
1. Нет Configuration.xml и объекта — «Файл объекта не существует».
Дописаны cf-init + meta-compile + form-add, рукописный Form.xml сохранён.
2. Префикс `cfg:` в значении <v8:Type> при НЕобъявленном xmlns:cfg —
«Исключение XDTO произошло при чтении файла». Тот же класс, что ишью #38,
только в наших собственных тестовых данных: четыре фикстуры платформа не
читала вовсе, а кейсы на них считались зелёными.
3. Привязка Объект.Наименование у обработки — у неё нет такого стандартного
реквизита. Добавлен обычный реквизит.
4. Динамический список без источника — «Неверный путь к данным: Список.Ссылка».
Добавлен справочник-источник и MainTable.
Кейс с формой расширения помечен skipPlatformVerify: верификатор грузит
каталог кейса как конфигурацию, фрагмент расширения так не проверить. Ключ
существовал в verify-snapshots, но не был описан — добавлен в README.
form-validate: 14/14 на обоих рантаймах, платформенная верификация 13/14
(один пропуск с причиной, было 10/14 с четырьмя падениями).
Проверка объявляла ошибкой любую команду формы без <Action>. Корпусный
прогон (УТ 8.3.27, БП 8.3.27, ERP 8.3.24 — 21 097 форм) показал 406 таких
команд на 275 формах, и все они произведены самой платформой: формат это
допускает, конфигурации грузятся.
Приём типовых: действие назначается в рантайме, в ПриСозданииНаСервере —
`Команда.Действие = "Подключаемый_" + Имя + "Локализация"`. Назначать может
и чужой модуль (переопределяемый слой, подключаемые команды), поэтому по
одному Form.xml вердикт не вынести — отсюда предупреждение, а не ошибка, и
никакого подглядывания в соседний модуль.
Корпус после правки: форм с ошибками 283 → 8, новых срабатываний нет.
Оставшиеся 8 — четыре других класса, разбираются отдельно.
Кейс с фикстурой: команда без Action на кнопке → предупреждение, exit 0.
PS-порт падал с «Не удается индексировать в массив NULL»: @($null).Count в
PowerShell равен единице, поэтому ветка самозакрывающегося тега была
недостижима, и код шёл эмитить несуществующую колонку. PY на том же входе
молча писал пустую группу — портируемого поведения не было вовсе.
Разведены два случая, которые до сих пор путались:
- `"columns": []` — явно пустая группа, законная форма (платформа так
пишет таблицу без доп. колонок). Работает как работала, self-closing;
- ключа `columns` нет вовсе — недосказанность автора: «доп. колонки есть»,
а какие, не сказано. Теперь отказ с указанием, что делать.
Валидатор такое по-прежнему пропускает: в выгрузке платформы пустая группа
встречается, запрет на авторинг не равен запрету на существование.
Заодно кейс cfe-borrow/form-main-attr-columns вернулся к форме эталона
Конфигуратора — таблица без колонок описана явно пустым списком, как в
выгрузке, а не обходным манёвром вокруг падения.
На одной и той же форме PS сообщал 12 проверок, PY — 9. Расходился не
вердикт, а учёт: три проверки (ссылки команд, обработчики событий,
действия команд) в PS отчитываются строкой «none», когда проверять нечего,
а в PY эта ветка отсутствовала — и проверка не попадала в счётчик.
Добавлены недостающие ветки. Выборка из 40 форм корпуса (УТ, БП, ERP):
число строк отчёта совпадает у портов на всех сорока.
Платформа считает это свойство модификацией настроек нумерации и тогда
требует объявить ещё и <Numerator/>: /UpdateDBCfg падает с «Для
заимствованного документа, настройки нумерации которого модифицированы,
отключать контролируемость свойства "Нумератор" недопустимо». Загрузка при
этом проходит — ошибка вылезает только на обновлении конфигурации БД,
поэтому ручной E2E её не видел, а verify-snapshots поймал.
Эталон Конфигуратора переносит NumberType/NumberLength/NumberAllowedLength
и не переносит NumberPeriodicity — приводим к тому же. Свойство попало в
список ещё при появлении -BorrowMainAttribute, набор тогда был угадан, а
не выверен по эталону.
Заодно две мои фикстуры доведены до платформенной валидности:
form-choice-param-links задавала в ИСХОДНОЙ форме ссылку на несуществующий
реквизит — такая конфигурация не грузится сама, проверять на ней вырезание
висячей связи нельзя; gentypes-full не имела регистратора для регистра
бухгалтерии и задачи для бизнес-процесса.
verify-snapshots по cfe-borrow: 11 из 12 (container-types падал и раньше,
дефект его фикстуры). Регресс 12/12 на обоих рантаймах, все гарды зелёные.
В примерах имя расширения задано явно (-Name Расш1), а рядом стоял
плейсхолдер -OutputDir src\cfe\extname — связь между именем и каталогом
из такого примера не читается. Теперь каталог называется по имени, и
конвенция «подкаталог = имя расширения» видна из самих примеров.
Базовая команда дополнена -OutputDir и -ConfigPath: без них расширение
уезжает в src (тот самый неоднозначный каталог), а совместимость и UUID
языка берутся по умолчанию вместо базовой конфигурации.
В группе cfe-* примеры расходились: cfe-patch-method уже использовал
src\cfe\<расширение> и src\cf, остальные три навыка — голый src и
абсолютный C:\cfsrc\erp. Голый src особенно вреден: в репозитории с
конфигурацией и расширением он неоднозначен, и модель подставляет в
-ExtensionPath конфигурацию.
Везде одна пара: src\cfe\extname и src\cf.
Заодно по итогам появления -ConfigPath у cfe-validate: блоки «Верификация»
теперь показывают его передачу, а описание параметра в самом валидаторе
переписано с устройства проверки на повод её включить — с последствием
(расширение пройдёт валидацию и будет отвергнуто платформой) и с
алгоритмом поиска пути прямо на месте, без отсылки к соседнему навыку.
У cfe-init отмечено, что CompatibilityMode не нужен при заданном
ConfigPath, и что расширение стоит класть в отдельный подкаталог.
Три вещи, на которых платформа отвергала расширение, а валидатор молчал.
Check 9 — полнота набора GeneratedType у заимствованной оболочки: неполный
набор платформа не читает («отсутствует один или более типов объекта»).
Карта категорий взята из той же таблицы спецификации (§2.5) и заведена в
реестр check-type-maps.mjs, чтобы копия не разошлась с остальными.
Check 12 — <AdditionalColumns table="Объект.X"> при незаимствованной
табличной части. В отличие от соседних проверок блока, здесь сигнал точный
(имя из атрибута), а последствие жёсткое, поэтому ошибка, а не warning.
Check 14 — пути Объект.* заимствованных форм против конфигурации-источника,
по новому опциональному -ConfigPath. Без него проверка пропускается с явной
строкой в отчёте. Отличить живой путь от висячего иначе нельзя: Объект.Партнер
валиден и без заимствования (наследуется от базы), а Объект.Товары.Артикул не
разрешится нигде. Итоги колонок (Total<Колонка>) и стандартные реквизиты
пропускаются — иначе ложные срабатывания на типовых формах.
Проверено на пяти расширениях: наши (оба режима) и оба эталона Конфигуратора
проходят чисто, расширение с дефектом ловится. Регресс cfe-* 51/51 на обоих
рантаймах, гарды дрейфа зелёные.
Форма, которую платформа отвергала с «Неверный путь к полю - Объект.Партнер»,
проходила валидацию с вердиктом OK. Check 5 такое не видит по двум причинам:
у формы с BaseForm он пропускает базовые элементы (id < 1000000), а привязка
внутри <ChoiceParameterLinks> лежит в <xr:DataPath> и в его список тегов не
входит вовсе.
Проверка 11d: если форма не объявляет основной реквизит, любой путь с корнем
«Объект» не разрешится — ошибка. Непрозрачные формы пути (1/0:uuid), которыми
как раз и заменяет такие ссылки Конфигуратор, ошибкой не считаются.
Две фикстуры: висячая ссылка ловится, та же форма в uuid-форме проходит.
Регресс 13/13 на обоих рантаймах.
Заимствование формы без основного реквизита копировало
<ChoiceParameterLinks>/<xr:Link> как есть, с текстовым путём
«Объект.Партнер». В расширении такой путь не разрешается — платформа
отвергала загрузку: «Неверный путь к полю - Объект.Партнер». Привязка
лежит в <xr:DataPath> внутри xr:Link, и общий стриппинг её не видел.
Конфигуратор ссылку не выбрасывает, а переводит путь в непрозрачную форму
«1/0:<uuid реквизита объекта>» — связь остаётся рабочей. Делаем так же;
реквизит, которого в источнике нет, недоступен и по uuid — такую связь
вырезаем вместе с опустевшим контейнером. Путь односегментный во всём
корпусе УТ (285 из 285), глубже не бывает.
Результат совпал с эталоном Конфигуратора вплоть до uuid, E2E на UT_DEMO:
«Load completed successfully». Регресс 12/12 на обоих рантаймах.
Заимствование формы с -BorrowMainAttribute синтезировало <Attribute
name="Объект"> с нуля — Type/MainAttribute/SavedData и всё. Секции
<UseAlways> и <Columns> исходной формы терялись, а вместе с ними и
дополнительные колонки табличных частей, объявленные прямо в форме:
платформа отвергала загрузку («Неверный путь к данным: Объект.Товары.Артикул»).
Три связанных следствия:
- секции переносятся из исходной формы (helper Get-MainAttributeExtraXml
на оба порта, отступ в BaseForm — тем же приёмом, что у ChildItems);
- табличная часть, упомянутая только в <AdditionalColumns table="…">,
теперь попадает в сбор путей и заимствуется — иначе «Колонки не могут
быть добавлены к реквизиту»;
- типы колонок дозаимствуются через collect_reference_types, как это
делает Конфигуратор (DefinedTypes/Артикул в эталоне).
Попутно снят PS↔PY-дрейф: lxml включал хвостовой пробельный узел в
tostring, из-за чего .py вставлял пустые строки, которых нет у .ps1
(with_tail=False в четырёх местах).
E2E на UT_DEMO (8.3.27, формат 2.20, форма заказа поставщику): режим с
основным реквизитом грузится «Load completed successfully» без ручных
правок. Регресс 11/11 на обоих рантаймах.
Платформа отвергала заимствованный план видов характеристик: «отсутствует
один или более типов объекта ChartOfCharacteristicTypes». В карте
$script:generatedTypes не хватало категории Characteristic — а вместе с ней
ещё пяти категорий у пяти типов (планы счетов и видов расчёта, регистры
бухгалтерии и расчёта, бизнес-процессы).
Дефект был чистым дрейфом копий: карта живёт в трёх навыках, и в
meta-compile с meta-validate она верна. Чтобы расхождение больше не
копилось молча, каноническая таблица наборов GeneratedType заведена в
спецификации (§2.5), а check-type-maps.mjs получил виды gentypes/gencats и
сверяет по ней все три карты.
Регресс cfe-* 47/47 на обоих рантаймах, оба гарда дрейфа зелёные.
Верификатор читает тот же DSL, что и функциональный раннер, но своей
реализацией, и отставал на пять ключей: preRun[].cwd, inputFrom, cwd на уровне
кейса, раскрытие {workDir} в args_extra и маппинг from: outputPath. Кейсы,
опирающиеся на них, до платформы не доезжали вовсе — падали на подготовке
фикстуры, причём шаг preRun с относительным путём писал её в корень репозитория.
Незнакомый from теперь роняет кейс с внятным сообщением: молчаливый default
маскировал расхождение под дефект навыка (флаг уходил без значения).
Платформенная верификация: mxl-compile 28/36 -> 36/36, mxl-decompile 0/7 -> 7/7,
mxl-info 2/7 -> 7/7, mxl-validate 0/4 -> 4/4, skd-decompile 0/17 -> 17/17.
Оба ключа, которых не было в документации DSL, дописаны в README.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Спецификация XML — дописано то, что вскрыли контролируемые макеты и замеры
по корпусу:
- шрифт-ссылка на СИСТЕМНЫЙ шрифт: префикс sys в корне не объявлен, поэтому
объявление xmlns дописывается прямо на узел. Плюс правило вывода kind
из префикса и то, что неиспользуемый шрифт в палитру не попадает;
- новый раздел «Устройство палитр»: порядок документный и НЕ зависит от
последовательности действий автора (проверено опытом с оформлением снизу
вверх), формат по умолчанию последний, палитра дедуплицирована по содержимому;
- у текста ячейки ТРИ состояния: тега нет, тег с элементами, пустой <tl/>.
Третье — 57% макетов корпуса;
- языковые настройки: набор языков не выводится из языков текста, description
бывает самозакрывающимся, currentLanguage бывает отсутствующим и бывает
указывающим на необъявленный язык.
Спецификация DSL — из ограничений убрано объявление языков макета: оно больше
не теряется. Добавлено пояснение, почему побайтовое совпадение достижимо не на
любом макете: в долго правленных макетах остаются следы прежних состояний,
которые из итогового документа не выводятся.
В инструкции навыка отражена только форма шрифта-ссылки — остальное из этой
серии либо уже там, либо для авторинга не нужно.
Примеры из справочника скомпилированы и проверены валидатором.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Шрифт бывает не собственным описанием, а ссылкой: на элемент стиля конфигурации
(style:) или на системный шрифт (sys:). Своих атрибутов у такого шрифта нет, и мы
превращали его в пустую запись — faceName="" height="0". ps1 при сборке подставлял
туда Arial 10, то есть подменял данные молча.
В корпусе таких шрифтов 272 в 213 макетах из 10 924: StyleItem 209, WindowsFont 63.
Запись — та же, что у шрифта в описании формы: { "ref": "style:TextFont" }.
kind выводится из префикса, ключом быть не обязан.
Синтетический стенд показал деталь, которую по корпусу было не разглядеть: префикс
sys в корне документа не объявлен, поэтому платформа дописывает объявление xmlns
прямо на узел шрифта — тот же приём, что с цветами из web-палитры.
Порты после этого сошлись ПОЛНОСТЬЮ: на пилоте из 40 макетов совпадают и JSON
декомпиляторов, и собранный XML. Макет со шрифтами добавлен в побайтовую
регрессию, стенд 8 из 13.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
У текста ячейки три состояния, а выражались два: тега нет вовсе, тег с пустым
текстом на каждый язык — и третье, <tl/>, которое мы теряли. Это не редкость:
38 075 ячеек на 1200 макетов, встречается в 57% макетов корпуса.
Выражается пустым объектом: "text": {}. Не новый ключ и не новое понятие, а
вырожденный случай уже принятой записи «язык → текст» — языков нет вовсе.
В позиционной строке двусмысленности не создаёт: {} не несёт ключей ячейки,
значит по общему правилу читается как текст, а null там по-прежнему «пропустить
колонку».
В описании DSL записи нет намеренно. Для авторинга она бесполезна — визуально
это тот же пустой текст, что и "", — а документировать две пустые формы рядом
значило бы завести развилку, у которой нет правильного ответа.
Платформа пишет такой тег самозакрывающимся, поэтому эмиссия отдельной веткой.
На пилоте потери в категории row[].cell[].tl упали с 12 488 до 2, заодно
row[].cell[].fmt с 41 645 до 30 088; совпадение строк документа 17.6% → 18.5%.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Два дефекта, найденных при сведении портов.
Стиль, на который ссылалась только дополнительная колоночная раскладка,
отсекался как неиспользуемый: проверка смотрела в result, а columnSets
попадает туда ПОЗЖЕ неё. Ссылка оставалась висячей — 5 макетов пилота
из 40 указывали на стиль, которого в styles нет. Берём стили из самих
раскладок.
Именованные элементы платформа хранит отсортированными по имени ординально.
ps1 сортировал их Sort-Object -CaseSensitive, а он всё равно сравнивает по
текущей культуре — комментарий рядом сам об этом предупреждал. На кириллице
порядок расходился с py-портом (4800 строк разницы на одном макете).
Сортируем по ключу из кодов символов: в нём только 0-9A-F, культура его
переупорядочить не может.
Порты сошлись: JSON декомпиляторов совпадает на всех 40 макетах пилота
(было 26 расхождений), собранный XML — на 39 из 40 (было 20 расхождений).
Остаток — один макет, где расходятся компиляторы: ps1 подставляет
faceName="Arial" height="10" там, где py пишет пустой шрифт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Расхождение JSON между портами было 26 макетов из 40, стало 5. Расхождение
собранного XML — 20 из 40, стало 7. Причин оказалось четыре, и три из них
дефекты, а не просто разнобой.
1. ps1 грузил XML с PreserveWhitespace = $false, и текст ячейки из одних
пробелов схлопывался в пустой. Молчаливая потеря данных в каноничном
порте, 25 макетов пилота.
2. Стили обнаруживались обходом хэш-таблицы строк, а её порядок в PowerShell
НЕ определён. Платформа же кладёт записи палитры в порядке документа, так
что порядок обхода — часть верности вывода, а не деталь. Обход теперь по
возрастанию номера строки. ([ordered] тут не годится: с целочисленными
ключами он индексируется по позиции, а не по ключу.)
3. Именованные области сортировались нестабильным Sort-Object (-Stable
появился только в PowerShell 6.2), поэтому области с одинаковыми границами
получали произвольный порядок. Добавлен явный ключ исходного порядка —
в оба порта, чтобы совпадение было по построению, а не по совпадению.
4. containsValue / valueType / controlType протекали в styles сквозным
пробросом неизвестных тегов. Это свойства ЗНАЧЕНИЯ ячейки, а не оформления,
и компилятор таких ключей не знает — в DSL они были чистым шумом. Заодно
вложенный элемент больше не читается как скаляр: ps1 брал InnerText и
получал склейку поддерева, py брал .text и получал пустоту.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прежняя формулировка противопоставляла «ячейку» и «многоязычный текст», хотя
текст тоже даёт ячейку. Разница не в этом: объект либо описывает СВОЙСТВА
ячейки (среди ключей есть ключ её схемы), либо является её ЗНАЧЕНИЕМ, и тогда
ключи — идентификаторы языков.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В позиционной записи строки элемент — это значение содержимого ячейки, а значение
текста по общей конвенции бывает строкой либо объектом «язык → текст». Значит
объект {ru, en} там законен так же, как строка, и новой формы это не заводит.
Раньше ячейка с многоязычным текстом не считалась «простой», поэтому строка
двуязычного макета оставалась объектной:
{ "cells": [{ "text": { "ru": "Пусто", "en": "Empty" } }, { … }] }
[{ "ru": "Пусто", "en": "Empty" }, { … }]
Объект-элемент читается как ячейка, если несёт хоть один её ключ, и как текст
в противном случае: идентификаторы языков с ключами ячейки не пересекаются
(в корпусе это ru, en, ru1, Русский).
Попутно исправлен признак «список позиционный»: он искал элемент-строку, поэтому
строка из одних многоязычных текстов позиционной не признавалась и ключ cells
у неё оставался.
Правка не должна менять скомпилированный XML — и не меняет: пилот из 40 макетов
собрался побайтово так же, JSON при этом изменился у 13. Стенд 7 из 10.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Две правки читаемости DSL, обе замечены на живом выводе.
Ячейка получала "style": "default" — ссылку на стиль, которого в styles нет
вовсе. Условие сверялось с обнаруженным стилем пустых колонок, а он бывает
равен "default": строка такой стиль не пишет, а ячейка получала ключ на
пустое место. Теперь сверяемся со стилем, который РЕАЛЬНО раздаётся ячейкам.
Позиционная запись строки отбрасывалась, как только первая ячейка стояла не
в первой колонке. Но один-два null впереди обычно короче объектной записи
с col: строка вида { "cells": [{ "col": 2, "text": "…" }] } сворачивается
в [null, "…"]. Выбираем ту форму, которая короче.
Правка не должна менять скомпилированный XML — и не меняет: пилот из 40
макетов собрался побайтово так же, как до неё, при том что JSON изменился
у 31 макета. Стенд по-прежнему 7 из 10 байт в байт.
Попутно блок JSON-сериализатора в ps1 перенесён выше первого использования:
в PowerShell функция должна быть объявлена до вызова.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
До сих пор строгая дорожка кампании жила только в отладочных прогонах, и её
некому было защищать: снэпшот сравнивает наш вывод с нашим же прежним выводом,
поэтому дрейф от платформы он не ловит.
Семь макетов, собранных вручную в Конфигураторе, положены в фикстуры. Кейс
декомпилирует такой макет и компилирует обратно, а результат сверяется с
исходником побайтово. Проверено, что сеть кусается: подмена одного тега в
фикстуре роняет кейс.
Раннеру добавлены две ручки:
- expect.filesEqual — сравнение двух файлов побайтово. Снэпшот его не заменяет:
--update-snapshots молча принял бы расхождение с платформой;
- inputFrom — брать вход из файла в рабочем каталоге, а не из case.input.
Нужно, когда вход производит preRun: case.input пишется ПОСЛЕ preRun и затёр
бы его.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Контролируемый стенд (upload/epf/МакетТабличныйДокумент) вскрыл четыре
системных расхождения подряд. После правок 7 макетов стенда из 10 проходят
раундтрип БАЙТ В БАЙТ обоими портами — до этого ни один.
1. Объявление языков макета жёстко писалось как «только русский». Это не то же
самое, что textLanguages: почти во всех макетах ERP объявлен один ru, а текст
лежит и под ru, и под en, поэтому выводить одно из другого нельзя. Заведены
недокументированные ключи languages / currentLanguage / defaultLanguage —
автору они не нужны, нужны раундтрипу. defaultLanguage несём, а не выводим:
«всегда ru» — наблюдение на четырёх русских типовых, а не правило формата.
2. <font> писался в каждом формате. Платформа пишет его только когда шрифт
задан: треть форматов корпуса (23 003 из 69 581) обходится без него.
3. Декомпилятор считал шрифт с индексом 0 «обычным» и не писал его в стиль.
Нулевой шрифт вовсе не обязан быть обычным — в макетах стенда он курсивный
и жирный, и начертание терялось.
4. Формат, несущий ТОЛЬКО шрифт, выглядел пустым: у ячейки он получал
зарезервированное имя default и не записывался, у строки терялся целиком.
Остаток на стенде — три макета, и все три про одно: ссылка ячейки на запись
ширины, оставшуюся от прежнего состояния документа. Это не воспроизводится
принципиально, разобрано в docs/1c-spreadsheet-spec.md.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Мы всегда заводили шрифт Arial 10 по умолчанию, даже когда его никто не
использует. Платформа так не делает: у макета без оформления элемента <font>
нет вовсе. Неиспользуемые шрифты теперь отбрасываются, ссылки перенумеровываются
(индексы шрифтов позиционные).
Проверено на контролируемом стенде: после правки простейший макет расходится
с платформенным ровно одной строкой — объявлением языков в шапке.
Кейс font-fractional-size дополнен: стиль, задающий ТОЛЬКО шрифт по умолчанию,
равнозначен отсутствию оформления (ячейка получает <f>0</f>), поэтому шрифт
остаётся неиспользованным. Чтобы кейс продолжал проверять целый размер, стилю
добавлено второе свойство.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Мы регистрировали формат по умолчанию первым, из-за чего вся палитра шла
со сдвигом относительно платформенной. На корпусе он последний в 8285 макетах
из 10 863, первым — в 25.
Подтверждено контролируемым стендом: в макетах, где ширины заданы на уровне
документа, палитра идёт «ширины колонок в порядке колонок, умолчание последним».
Порядок палитры не виден в семантическом диффе (правило palette-index разрешает
ссылки и тем самым его прячет), поэтому мерялся отдельно: на пилоте совпавших
с оригиналом записей с начала палитры стало 467 из 2274 против 23, палитр,
совпавших целиком, — 4 против 2.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
За кампанию XML-уровень изучен заметно глубже, чем был описан. Внесено то,
что проверено на корпусе ERP (10 924 макета) и на контролируемом стенде:
- <i> платформа пишет только при разрыве последовательности;
- <indexTo> схлопывает только ПУСТЫЕ строки — прежняя формулировка «строки
с одинаковым содержимым» неверна: одинаковых непустых схлопнутых нет ни одной
при 98 153 несхлопнутых;
- <f>0</f> — у ячейки формата нет вовсе, это не индекс записи;
- канонический порядок тегов внутри <format> (height раньше width);
- единица ширины — 1/8 символа;
- свёртка четырёх одинаковых сторон рамки в <border>;
- цвет — значение с префиксом пространства имён, web/win объявляются прямо
на узле; в Form.xml те же цвета выглядят как web:/win:;
- формат строки несёт не только высоту, а формат колонки не только ширину;
оформление строки материализуется и в ячейки, кроме hidden;
- columnsItem с formatIndex 0 и с индексом за пределами size;
- полный список стилей линии вместо Solid/None.
Отдельно описана ловушка: width в формате ЯЧЕЙКИ — устаревшая ссылка, она не
описывает итоговое состояние документа и воспроизведению не подлежит.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
У строки есть собственный формат: платформа хранит в нём скрытие (17 423 вхождения
в корпусе), шрифт (9 216), фон, выравнивания, защиту. Мы писали туда только высоту,
всё остальное теряли.
Разбор на контролируемом стенде показал, что это два разных случая, а не один.
Оформление, применённое к строке целиком, платформа пишет И строке, И каждой
ячейке (backColor: 13 899 ячеек повторяют против 96). Скрытие — только строке
(24 026 против 62 856). Поэтому одного правила «rowStyle красит ячейки» мало.
Теперь rowStyle — стиль строки: по умолчанию ложится и на строку, и на ячейки,
как это делает платформа. Объектная форма { style, apply } задаёт исключения:
"row" — только строке, "cells" — только ячейкам. Модификатор нужен раундтрипу,
в описании DSL его нет.
Скрытие и высота — собственные свойства строки, ключами рядом: у ячейки таких
свойств не бывает, и в её оформление они не попадают.
На пилоте категория row[].formatIndex упала с 1964 до 201 потерянного факта.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ячейка без собственного оформления ссылалась на формат по умолчанию. Платформа
в этом случае пишет <f>0</f>, где ноль — не индекс записи, а «формата нет»:
на корпусе так у 170 710 ячеек против 50 635, ссылающихся на умолчание, и
<f>0</f> встречается в 71% макетов.
Подтверждено контролируемым стендом: в макете, где колонкам заданы ширины, а
ячейки ничем не оформлены, платформа пишет ячейкам ноль.
На пилоте верхняя категория row[].cell[].fmt упала с 63 900 до 55 855 фактов,
совпадение строк документа выросло с 16.7% до 17.5%.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Справочник был одним файлом на 273 строки, а полная таблица свойств стиля его
бы удвоила. Разделён по частоте обращения, как в meta-compile: в инструкции
маршрутная таблица «что нужно → какой файл».
reference/dsl-spec.md — верхний уровень, области, строки, ячейки
reference/styles.md — шрифты, стили, цвет, рамка, колонки
reference/format-properties.md — полный перечень свойств стиля
Описаны columnStyles и новая запись стиля: ключ = имя свойства как в выгрузке,
рамка пятью ключами, цвет в четырёх формах. Прежние align/valign/wrap работают
и дальше, но в описании их нет — иначе у модели появляется развилка.
Ограничения переписаны по факту: цвета, скрытие, отступ, посторонние рамки и
стили линий больше не теряются; зато честно названо то, что теряется до сих пор —
оформление строки помимо высоты.
Пример из спеки скомпилирован и проверен валидатором.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа иногда перечисляет колонку в раскладке с <formatIndex>0</formatIndex> —
колонка объявлена, формата у неё нет (4% макетов корпуса). Компилятор такие
опускал, декомпилятор их не видел, и элемент терялся целиком.
Выражается пустым значением в columnStyles. Для авторинга это бесполезно —
ни одна задача не звучит как «объяви колонку без свойств», — поэтому в описании
DSL записи нет: она нужна только чтобы раундтрип не терял байты.
На пилоте потери в категории colset[].col[].formatIndex упали с 39 до 35.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
У ячейки есть style, у строки rowStyle, у колонки не было ничего — при том что
колонка ссылается в ту же палитру <format> и несёт те же свойства. В корпусе
ERP колонки используют шрифт (3006 форматов), выравнивание, рамки, скрытие и
прочее; всё это терялось при раундтрипе.
Колонка получает такой же именованный стиль: columnStyles рядом с columnWidths,
ключи той же грамматики диапазонов ("1", "2-8", "5,7,9"), значение — имя из
styles. Внутри columnSets тот же ключ. Формат колонки собирается из ширины и
свойств стиля: запись в палитре одна.
Шрифт по умолчанию колонке не навязываем — формат колонки без оформления это
ровно <width>, как пишет платформа.
Попутно два дефекта декомпилятора: стиль колонки не учитывался при отсечении
неиспользуемых стилей и пропадал целиком, а набор из одних неприметных свойств
(отступ, защита) получал зарезервированное имя default и тоже терялся.
На пилоте потери в категории colset[].col[].formatIndex упали с 86 до 39.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Декомпилятор снимал из <format> только шрифт, четыре рамки, выравнивания,
перенос и форматную строку — остальные тридцать с лишним свойств терялись
молча. Компилятор их уже умеет, но до раундтрипа они не доезжали.
Теперь формат читается целиком по общей таблице типов — той же, что у
компилятора: рамки разворачиваются в описание линии из палитры, булевы и
целые приводятся по типу, цвет из web/win-палитры возвращается в привычную
запись (префикс узла разрешается в URI пространства имён).
Имя стиля осталось читаемой меткой по заметным свойствам: различает стили
ключ, имя лишь помогает автору ориентироваться.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Снэпшоты mxl-decompile/mxl-info/mxl-validate строятся preRun-прогоном
mxl-compile. Дрейф одного вида: четыре одинаковые стороны рамки стали
одним <border>.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Стиль описывал 7 свойств из 47, которые платформа хранит в <format>. Не было
самого частого тега корпуса — backColor (1.7 млн вхождений), а также textColor,
textPlacement, protection, hidden, indent, borderColor, textOrientation и хвоста.
Теперь ключ стиля — имя тега платформы, без исключений: помнить, какие ключи
названы по-своему, больше не нужно. Прежние align/valign/wrap продолжают
работать молча, как синонимы; там же CSS-имена (background, color,
border-bottom) и русские имена свойств. Таблицы типов значений и допустимых
значений перечислений сняты с корпуса, а не выписаны на глаз.
Рамка: пять плоских ключей (border и четыре стороны) со значением
{ style, width } либо строкой стиля; линия регистрируется в палитре <line>,
которая раньше знала только «тонкую» и «толстую» Solid. Четыре одинаковые
стороны сворачиваются в один <border> — правило проверено на корпусе:
70 265 свёрнутых форматов против 36 783 записанных по сторонам, и среди
вторых нет ни одного с четырьмя совпадающими значениями.
Цвет — нотация самой платформы: #RRGGBB, style:Имя, web:Имя, win:Имя. Первые
две пишутся дословно (префикс style объявлен в корне документа), для web и win
платформа дописывает объявление xmlns прямо на узел — делаем так же.
containsValue / valueType / controlType намеренно не заведены: это свойства
конкретной ячейки, а стиль — сущность общая, один на многие ячейки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Формат был фиксированной записью из 12 полей, выписанной руками в четырёх
местах: ключ дедупликации, набор свойств, резолв стиля и эмиссия палитры.
Добавление свойства стоило восьми правок в двух портах, а свойств у формата
в выгрузке 47.
Теперь формат — набор «тег платформы → значение», а порядок эмиссии задаёт
один канонический список тегов. Список снят с корпуса ERP: 766 960 форматов,
ни один не нарушает эту последовательность.
Вывод не меняется: пилот из 40 макетов скомпилировался побайтово так же, как
до правки, обоими портами.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Снэпшоты mxl-decompile/mxl-info/mxl-validate строятся preRun-прогоном
mxl-compile, поэтому дрейфуют вместе с ним. Дрейф ровно двух видов:
убран избыточный <i> и схлопнуты пустые строки в indexTo.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Две правки эмиссии, обе выведены из корпуса erp_8.3.24 (10924 макета,
15.2 млн ячеек) и проверены на нём же без единого контрпримера.
Номер колонки <i> платформа пишет только при разрыве последовательности:
подряд идущая ячейка его не несёт, читатель ведёт счётчик сам. Мы писали
всегда — из 1.2 млн записанных платформой номеров ни один не избыточен.
Подряд идущие одинаковые ПУСТЫЕ строки платформа хранит одним rowsItem
с indexTo; непустые не схлопывает, даже когда они совпадают (98153 таких
случая в корпусе). Мы не эмитили indexTo вовсе.
На пилоте (40 макетов) доля строк документа, совпавших с оригиналом
байт в байт, выросла с 0.3% до 16.7%; все 9 диапазонов indexTo оригинала
воспроизведены точно.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Write-Error оборачивает сообщение в ErrorRecord: приписывает имя скрипта,
добавляет хвост CategoryInfo и ломает текст по ширине окна консоли. Длинные
сообщения приезжали разорванными посреди слова, и по ним нельзя было
ни искать подстроку, ни читать их глазами.
Остальные четырнадцать мест в файле уже писали через Console.Error —
приведены оставшиеся шесть. Тексты сообщений не менялись.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
«Внутри конфигурации набор обычно одинаков» — тот же вывод из замеров, только
без числа: проверить его по месту нельзя. Совет смотреть соседние макеты толкает
на лишний обход при авторинге с нуля, а упоминание, что платформа разрешает
необъявленные языки, читается как приглашение их указывать.
Осталось свойство самого ключа: он ни на что в конфигурации не смотрит.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проценты по типовым конфигурациям модель может принять за правило, а объяснение,
почему набор языков нельзя вывести из текстов, ей для применения не нужно.
Осталось то, что помогает выбрать значение: языки текстов и языки конфигурации
совпадать не обязаны, ориентир — соседние макеты той же конфигурации.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Строка в text/template разворачивается по одному элементу на каждый язык из
документного ключа textLanguages (по умолчанию только ru). Декомпилятор собирает
набор языков по всем текстам макета и пишет строкой текст, одинаковый на всём
наборе; различающийся остаётся объектом.
Языки текстов и языки, объявленные в конфигурации, — разные вещи: типовые ERP
объявляют один ru, а тексты хранят под ru и en. Набор постоянен внутри
конфигурации, поэтому он документный, а не вычисляемый: к моменту компиляции
тексты уже свёрнуты в строки.
Заодно: эмиссия tl проверяет НАЛИЧИЕ ключа text/template, а не истинность —
пустая строка это текст, платформа такие ячейки пишет с пустым tl, а по
истинности он терялся.
Проверено на пилоте (40 макетов ERP): скомпилированный XML совпадает с прошлым
прогоном байт в байт обоими рантаймами, объём JSON −47%.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Компилятор давно принимал короткую форму, а декомпилятор всегда писал самую
развёрнутую. Теперь он выбирает самую короткую из применимых, как это делает
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>
Одно условие делает две вещи.
Сокращение: у 56% ячеек (19 737 из 35 190) стоял "style": "default", хотя компилятор
и так подставляет default, когда ключа нет и у строки нет rowStyle. Чистый шум;
объём декомпилированного JSON на пилоте упал на 7%.
Починка: при ЗАДАННОМ rowStyle ячейка со стилем default, которая его не наследует,
теряла стиль вовсе — условие содержало -not rowStyleName, — и при обратной сборке
такая ячейка наследовала rowStyle вместо своего умолчания.
Проверка на потери: из 40 макетов пилота 23 собрались байт в байт как прежде. У 17
XML изменился, и это разобрано поячеечно: во всех 181 разошедшейся ячейке НИ ОДНА
версия не совпадает с оригиналом — там backColor, фон ячейки, который DSL не
поддерживает вовсе (числится в ограничениях). То есть правка переключает между двумя
одинаково неверными отображениями неподдерживаемой конструкции, не улучшая и не
ухудшая совпадение: фактов, совпавших с оригиналом, было 8183 и осталось 8183.
Проверено: тесты 54/54 на обоих рантаймах. Дрейф снэпшота один и ожидаемый — из
back.json ушёл "style": "default".
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа хранит текст ячейки по элементу на язык. Декомпилятор брал ПЕРВЫЙ и терял
остальное, компилятор писал всегда ru захардкоженно. В корпусе ERP текст лежит и под
ru, и под en у 10 730 макетов из 10 924 — то есть терялось у 98%.
Форма взята готовая — конвенция ML-значений из docs/meta-dsl-spec.md §4.4, по которой
уже живут synonym, tooltip и title в метаданных и формах: строка означает русский
текст, объект даёт по надписи на язык в порядке ключей. Новых понятий не вводили,
ключи те же (text и template).
Документный ключ для языков НЕ заводили, и это измерение, а не экономия: блок
languageSettings мы и так эмитим байт в байт как платформа (currentLanguage ru,
defaultLanguage ru, один languageInfo). Отклонения редки — 8 макетов ERP с
currentLanguage en, 3 без него, 157 с объявленной парой ru+en, всего около 1,6%.
Заодно это снимает развилку из разбора PR #62: список языков компилятор дописывать
не должен, платформа его не дописывает.
Эффект на пилоте: категория row[].cell[].tl упала с 47 252 до 12 488 — минус 74%,
самое крупное улучшение кампании. Остаток частично классифицирован: 348 строк — ячейки
с ПУСТЫМ <tl> у оригинала, которых мы не эмитим вовсе; полностью разобрать мешает
обрезка диффа по 400 строк на объект.
Снэпшоты не дрейфанули: кейсы пишут текст строкой, и вывод для неё прежний.
Проверено: тесты 54/54 на обоих рантаймах, verify-snapshots 24/24, вывод портов
совпадает байт в байт и в компиляции, и в декомпиляции.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа держит для неоформленного макета ОДИН формат — ширину колонки, он же
defaultFormatIndex, и все ячейки указывают на него. Компилятор заводил каждой ячейке
собственный формат с <font>0</font>, где ноль означает «шрифт не задан», то есть
формат был пуст по смыслу и отличался от умолчания только своим существованием.
Теперь ячейка, у которой не задано ничего (шрифт умолчательный, нет рамок,
выравнивания, переноса, типа заполнения и формата числа), ссылается на
defaultFormatIndex. На минимальном макете палитра сократилась с двух форматов до
одного и совпала по форме с платформенной.
На корпусе правка закрывает случай неоформленной ячейки начисто: на макете
АтрибВыгрузкиXML2015Кв1 расхождения по формату исчезли полностью, блок диффа
сократился с 75 строк до 40, и всё оставшееся — многоязычный текст. В агрегате по
пилоту это 497 строк из 64 865: остальное держат макеты, где ячейки реально
оформлены, и там расходится состав самих форматов — отдельная категория.
Дрейф 18 снэпшотов разобран построчно, посторонних строк нет: 170 сменившихся
индексов <f>, 36 границ <format> (палитра стала короче), 18 удалённых <font>.
Проверено: тесты 53/53 на обоих рантаймах, verify-snapshots 23/23.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Идентификатор колоночной раскладки выводится из имени детерминированно — это
требование, а не оптимизация: случайный давал бы другой файл при каждой компиляции,
снэпшоты не совпадали бы сами с собой, а повторная сборка того же определения
порождала бы диф.
Но выводился он неправильно: сырой хэш форматировался как UUID, без битов версии и
варианта. В выдаваемом значении версия оказывалась 7, вариант 1 — таких не бывает,
то есть формально это был не UUID, а шестнадцатеричная строка нужной формы. Платформа
такое принимает (проверено сертификацией), но упереться в валидатор мы могли в любой
момент — ровно того же сорта риск, что сертификация уже ловила в этой ветке.
Теперь это штатный UUID версии 3 (имя + MD5, RFC 4122): для задачи «вывести
идентификатор из имени» существует именно он. Детерминированность сохранена, оба
порта дают одинаковое значение.
Проверено: тесты 53/53 на обоих рантаймах, verify-snapshots 23/23.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В ожиданиях column-sets стоит конкретный идентификатор раскладки, и по кейсу
не видно, откуда он взялся. Имя кейса теперь говорит, что id выводится из
имени детерминированно и что ожидаемое значение — md5 от имени раскладки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Две правки по корпусу и по 1С-сертификации.
fillType=Text платформа практически не пишет: на выборке корпуса 344 981 текстовая
ячейка из 348 023 (99,1%) ссылается на формат БЕЗ fillType — наличие <tl> и так
означает текст. Parameter и Template платформа пишет, их оставляем. Правило то же,
что и везде: эмитим то, что эмитит платформа, а не то, что верно в рантайме.
Идентификатор колоночной раскладки платформа хранит как UUID и другой не принимает —
макет с <id>узкая</id> она отвергала целиком. Имя, похожее на UUID (то есть пришедшее
декомпиляцией), проходит насквозь, иначе поехал бы раундтрип; читаемое имя автора
превращается в UUID ДЕТЕРМИНИРОВАННО, из хэша имени, чтобы повторная компиляция
давала тот же файл. Оба порта дают одинаковый хэш.
Дефект с идентификатором нашла 1С-сертификация: ни юнит-кейсы, ни раундтрип по
корпусу его не видели — там идентификаторы приходят из исходных макетов и уже
являются UUID.
Дрейф 33 снэпшотов разобран построчно, посторонних строк нет: 116 сменившихся
индексов формата, 49 удалённых fillType, 43 перестановки свойств внутри палитры,
16 границ <format> (палитра стала короче).
Проверено: тесты 53/53 на обоих рантаймах, verify-snapshots 23/23.
Замечание на будущее: на корпусе эта правка снимает лишь 170 расхождений из 64 865
в категории формата ячейки. Основная причина другая — платформа даёт неоформленной
ячейке ссылку на формат по умолчанию, а компилятор заводит ей собственный формат
с <font>. Это отдельный заход, он сдвинет снэпшоты повторно.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Раскладка адресуется именем из columnSets. Инлайновой формы в этом DSL нет ни у
чего: style у ячейки и font внутри стиля тоже только имена — именованные сущности
объявляются один раз и всюду адресуются по имени. Объектная форма стала бы второй
формой одного и создала бы асимметрию «раскладку инлайнить можно, а стиль нельзя».
Объект в columnSet и раньше не портил вывод — навык падал с «Unknown 'columnSet'»,
подставляя сериализованный объект. Но сериализация у портов разная (@{columns=5}
против {'columns': 5}), то есть сообщения расходились. Теперь это отдельная проверка
с текстом, одинаковым в обоих портах и прямо называющим правило.
Кейсы: column-sets (позитивный, ссылка и объявление доезжают до XML) и
error-columnset-inline.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Инкремент B изменил DSL, а документация осталась от предыдущей версии.
Добавлены columnSets в карту структуры и в таблицу верхнего уровня, раздел про
колоночные раскладки со ссылкой columnSet у области, оговорка что columns: 0 —
допустимая величина (все строки живут в именованных раскладках) и что позиции
колонок проверяются по ширине раскладки своей области.
Из ограничений убран пункт про несколько наборов колонок: теперь поддержаны.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Инкремент B кампании mxl-roundtrip. Табличный документ может задавать индивидуальные
ширины колонок для группы строк — в XML это несколько элементов <columns>, из которых
раскладка БЕЗ <id> является умолчанием (ровно одна в каждом макете корпуса), а остальные
адресуются GUID, на который ссылаются строки и области. Декомпилятор читал только первый
<columns>: ширины прочих раскладок терялись, а на макетах с пустым умолчанием он отдавал
columns: 0. Несколько раскладок есть у 63% макетов ERP.
DSL: документные columns/columnWidths — раскладка по умолчанию, дополнительные объявляются
в columnSets (ключ — идентификатор), область ссылается ключом columnSet. Форма повторяет
уже принятую в этом DSL пару «словарь именованных штук наверху — ссылка по имени на
потребителе», как styles/style и fonts/font.
Склейки раскладок по содержимому НЕТ, и это исправление собственной ошибки: замер, на
котором строилось прежнее решение, вырезал идентификатор через findtext('columnsID'),
тогда как у набора он называется <id> (columnsID — имя только у ссылок). Вырезание не
срабатывало, и наборы «различались» просто из-за разных GUID. Правильный замер: в 337
макетах из 517 есть наборы с полностью одинаковым содержимым, до 59 дублей в одном
макете. Содержимое раскладку не опознаёт — опознаёт идентификатор.
Попутно закрыты два дефекта, вскрытые корпусом:
- проверка обязательных полей смотрела на истинность значения, а не на наличие ключа:
columns: 0 — осмысленная величина (умолчание пустое, все строки в именованных
раскладках), и компилятор объявлял её отсутствующей. Тот же класс, что был с col;
- позиции колонок сверялись с документным columns, тогда как ширина сетки у каждой
раскладки своя. Проверки диапазона col, автопотока и короткой формы переведены на
ширину раскладки области.
На пилоте из 40 макетов ERP отказов больше нет ни одного (было 26): цикл проходят все 40
на обоих рантаймах. Скомпилированный XML портов совпадает байт в байт.
Записана находка (debug/mxl-roundtrip/WORKFLOW.md): порты mxl-decompile расходятся по
выходному JSON на 11 макетах из 12 — порядок стилей в словаре, при идентичном XML.
Не ловилось потому, что кейсы снэпшотят входной Template.xml, а не выходной JSON.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Продолжение чистки протёкшей реализации.
- «тип заполнения: param → Parameter, text → Text, template → Template» — автор DSL
ключ fillType не пишет и в выводе mxl-compile его не видит, это имена XML-перечисления.
Заменено на то, что действительно нужно: содержимое задаётся одним из ключей param /
text / template, где template — текст со вставками [Параметр]. Раньше синтаксис вставок
в инструкции не упоминался вовсе, хотя он куда полезнее перечисления. (У mxl-info
fillType остаётся: там навык объясняет свой собственный вывод.)
- «компилятор создаёт ячейки для ВСЕХ колонок строки» — механика. Оставлен наблюдаемый
контракт: стиль применяется ко всей ширине строки, оттуда сплошные рамки.
- «заданное имя компилятор разворачивает в именованную область типа строки» — то же самое.
Теперь сказано, что даёт имя автору: область доступна как ПолучитьОбласть("Имя").
- убран пункт «"|" продолжает ячейку, только если её позиция известна явно». Он ссылался
на поведение, которого в документации нет (позиция ячеек без col выводится прощающим
вводом), то есть документированное ограничение опиралось на недокументированную
механику. Случай закрыт сообщением об ошибке.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Продолжение чистки после перечитывания глазами модели, которая применяет навык.
- из раздела ограничений убраны доли по корпусу ERP. Это результат исследования, а не
то, что помогает применять навык: модель работает с конкретным макетом, а не с
популяцией, и числа стареют. Перечень того, что теряется при round-trip, остался
списком; замеры живут в материалах кампании;
- фраза про ошибки короткой формы была вырвана из контекста: шла после списка
ограничений, начиналась с символа в кавычках, и до самого конца было непонятно, что
речь про отказ. Плюс в один ряд попало разнородное — три случая про сам шорткат и
переполнение columns, которое к короткой форме не привязано. Переписано правилами:
маркеру нужно, что продолжать; объектный элемент не несёт col; элементов не больше
columns. Поведение при нарушении — одной фразой в конце;
- в SKILL.md ключевые правила шли вперемешку по уровням (страница, ячейка, строка,
ячейка, область). Пересобраны сверху вниз: документ → область → строка → ячейка;
- буллет про namedAreas сокращён: обнаружимость ключа даёт карта структуры, а из
правил там неочевидно только отсутствие ключа type.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Раздел ограничений врал в обе стороны. Он обещал потерю областей Columns и
Rectangle — они поддержаны предыдущим коммитом; и молчал про то, что теряется на
самом деле. Проверено по коду обоих навыков, доли — по корпусу ERP 8.3.24:
ячейки-поля ввода (53% макетов), несколько наборов колонок (63%), объединения вне
ячеек (16%), рисунки (2%), цвета, скрытые строки, отступ, посторонние стили линий,
группировки, колонтитулы и параметры печати. Отдельно записано, что многоязычные
надписи не поддерживаются: при разборе берётся первый вариант текста, при генерации
язык всегда ru — для двуязычных макетов остальные языки теряются.
Заодно убрано то, что описывает реализацию, а не использование:
- таблицы с точными текстами сообщений об ошибках и кодом возврата. Модель, вызвавшая
навык, видит и текст, и код прямо в выводе; документировать их незачем, а протухают
они молча — ровно как протух раздел ограничений. Правила, из-за которых ошибка
возникает, остались; сами строки зафиксированы в кейсах через expectError, где
расхождение ловится механически. В остальных пяти спеках таких таблиц и не было —
там принята одна фраза «ненулевой код выхода и сообщение в stderr»;
- фраза про порядок эмиссии именованных элементов: автор DSL на него не влияет.
Сам факт (платформа хранит их отсортированными по имени) перенесён в
docs/1c-spreadsheet-spec.md, где описывается XML-уровень, вместе с оговоркой,
что случай с «ё» не проверен.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Перечитал инструкцию глазами модели, которая приходит делать макет:
- в карте структуры отсутствовал ключ namedAreas — модель, которой нужна область
из колонок (в печатных формах это обычное дело), из инструкции не узнала бы, что
такое вообще выразимо. Карта верхнего уровня должна быть полной;
- в одном предложении соседствовали «область» и «блок». Платформа знает только
«область», второй термин появился по дороге — убран из инструкции и спеки;
- пример строк-массивов висел без подводки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Инкремент A кампании mxl-roundtrip. Блочная форма DSL не выражала больше половины
корпуса: у 34% макетов ERP есть строки вне именованных областей, у 21% нет ни одной
области типа Rows. Декомпилятор такие строки терял, а на макетах целиком из
Rectangle отдавал areas: [] — компилятор отвечал "Required field 'areas' is missing".
На пилоте из 40 макетов это 10 отказов из 26.
Что сделано:
- имя у блока стало необязательным. Блок без имени — просто кусок сетки; именованную
область он не создаёт. Отдельный «плоский режим» не нужен: макет без выразимых
блоков это один безымянный блок;
- namedAreas — именованные области координатами, для всего, что блоком не ложится
(не-Rows и пересекающиеся). Тип области НЕ указывается: он выводится из заданных
осей, ровно как в ТабличныйДокумент.Область() — только строки дают полосу строк,
только колонки полосу колонок, обе оси прямоугольник. Так нельзя написать
противоречие вроде type: Rows с колоночными координатами;
- диапазон записывается уже существующей грамматикой DSL (как ключи columnWidths):
число или "N-M". Список через запятую запрещён — область непрерывна, платформа
разрывную не хранит;
- прощающим вводом принимается платформенный адрес "R1C1:R2C2" и правило «0 значит 1»;
в документацию не вынесено;
- декомпилятор перестал пропускать области не-Rows (там стоял безусловный continue) и
режет сетку на блоки детерминированно: непересекающиеся Rows задают границы, дыры
становятся безымянными блоками, остальное уходит в namedAreas.
Отдельно: именованные элементы теперь эмитятся отсортированными по имени. Платформа
хранит их именно так — на выборке 541 макета с несколькими элементами иного порядка
нет ни разу. Сортировка ординальная и регистронезависимая; Sort-Object по умолчанию
сортирует по текущей культуре и на кириллице дал бы другой порядок. Отсюда дрейф 13
снэпшотов — чистая перестановка, диффы симметричны, число элементов не изменилось.
На пилоте отказы areas: [] закрыты полностью (10 → 0), цикл переживают 24 макета
вместо 14. Оставшиеся 16 отказов — колоночные раскладки, это инкремент B.
Правка на ps1, зазеркалена в py; вывод портов и в компиляции, и в декомпиляции
совпадает байт в байт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Размер шрифта в платформенных макетах бывает дробным (8.3, 6.8, 9.8, 11.3, 14.3).
Оба навыка приводили его к целому: py падал голым ValueError на int(), ps1 ТИХО
округлял через [int] — снова шумный отказ против тихой порчи, как было с col.
Найдено раундтрипом по корпусу ERP 8.3.24: на стратифицированной выборке из 40
макетов это давало 12 отказов декомпиляции — 30% выборки и ВСЕ отказы этого этапа.
После правки декомпиляция не падает ни на одном, цикл переживают 14 макетов
вместо 10.
Размер читается инвариантной культурой и остаётся целым, когда дробной части нет,
иначе "10" превратилось бы в "10.0". Эмиссия в XML тоже переведена на инвариантную
культуру: интерполяция строкой отдавала бы "8,3" под русской локалью.
Правка на ps1, зазеркалена в py.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Фраза «та же форма, что у макетов в /skd-compile» ничего не даёт модели, которая
про DSL СКД не знает, и подталкивает к лишнему ту, которая знает: рядом с rows
там живут widths, minHeight, пресеты стилей и параметры с drilldown, которых в
макете табличного документа нет. Совпадают только четыре соглашения внутри строки,
а «та же форма» читается как «работает так же целиком».
Правило и пример описывают форму полностью и без ссылок вовне. Происхождение
решения осталось в комментариях кода, где оно адресовано сопровождающему.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Строка, записанная массивом ("rows": [["А","Б","В"]]), молча превращалась в
пустую строку в обоих портах. Форма не выдумана: ровно так документированы
макеты в skd-compile, и привычка естественно переносится на табличный документ.
Масштаб потери был виден в самом репозитории — ПЯТЬ кейсов семейства mxl-*
написаны в этой форме и потому проверяли пустые макеты: снэпшот
lenient-key-case содержал единственную строку <empty>true</empty>. После правки
все пять снэпшотов наполнились ячейками, которые терялись.
Семантика повторяет skd-compile: позиция ячейки — индекс в массиве, ">"
продолжает ячейку слева (span), "|" — сверху (rowspan), null пропускает
колонку, "{Имя}" даёт параметр. Элемент можно записать и объектом, когда нужен
style или detail; col в нём запрещён — это смешение двух способов адресации.
Разворот идёт отдельным пред-проходом в обычные строки с явными col/span/rowspan,
поэтому остальной компилятор о короткой форме не знает.
Форма документирована — в отличие от прощающего пропуска col: модель пишет канон
соседнего навыка, и выравнивание двух табличных DSL убирает развилку. По каскаду
в SKILL.md только правило и пример, подробности и таблица ошибок — в спеке
(обе копии: docs/ и reference/ навыка).
Правка на ps1, зазеркалена в py: вывод портов совпадает байт в байт, decompile →
compile возвращает исходный XML байт в байт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Безусловная склейка OutputPath с текущим каталогом давала "C:\cwd\C:\out.json" и
роняла запись сообщением про формат пути — навык не умел писать по абсолютному
пути вообще. Py-порт этот случай обрабатывал, ps1 нет. Приведено к общей идиоме
репозитория; кейс на абсолютный путь падает без правки и проходит с ней.
Кейс заодно вскрыл, что порты пишут РАЗНЫЙ JSON: ps1 отдавал стиль ConvertTo-Json
из PS 5.1 (выравнивание ключей, \uXXXX вместо кириллицы), py — json.dumps(indent=2).
Один и тот же макет давал 4708 байт против 1744. Не всплывало потому, что ни один
кейс не снимал сам JSON — все проверяли только stdout.
mxl-decompile был единственным декомпилятором мимо общего сериализатора: у
form/meta/skd-decompile для этого свой ConvertTo-CompactJson. Перенесён вариант
skd-decompile как самый полный, py дополнительно переведён на newline='' —
как у соседей. Теперь порты совпадают байт в байт, а decompile→compile даёт
исходный XML байт в байт.
Семья заведена в check-inline-drift.mjs (4 функции, 3 варианта): раньше шесть
копий жили вообще без гарда. В form-decompile переименована локальная переменная
в string-literal — копии различались только ею.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Ячейка без col роняла py голым KeyError, а ps1 молча брал null как 0 и писал
Col = -1 — битую ячейку без единого сообщения. При этом опустить col модели
естественно: DSL устроен как HTML-таблица (rows → cells), и одиночный заголовок
или обычная строка пишутся без позиций.
Строка, в которой col нет НИ У ОДНОЙ ячейки, теперь раскладывается слева направо
с учётом span и занятых сверху rowspan-колонок. Смешанную строку не угадываем —
это опечатка; переполнение columns и явный col вне 1..columns тоже дают внятную
ошибку в stderr вместо тихой порчи.
Документация не менялась: col остаётся единственной каноничной формой, прощающий
ввод живёт только в коде — как регистронезависимость ключей DSL. Второй способ
адресации в SKILL.md превратил бы одно правило в развилку.
Правка сделана на ps1 и зазеркалена в py; вывод портов на общем примере совпадает
байт в байт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Три сообщения py-порта писали `--` там, где ps1 пишет `—`: rename-parameter
с равными именами, reorder-parameters с пустым списком и дедуп SelectedItemAuto.
Расхождение роняло кейс add-selection-auto-dedup на py-прогоне, из-за чего кейс
был ослаблен до куска строки без тире — и перестал сторожить сам текст.
Порты сведены по ps1-эталону, кейс сверяет полную строку. Сообщение про
отсутствие изменений не тронуто: оно одинаково в обоих портах, и на него
опирается отдельный кейс.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Инструкция навыка отвечает на вопрос «как вызвать правильно». Фразы вида
«опечатка в имени свойства → ошибка (правка не теряется молча)» описывают
поведение при неправильном вызове: модели, которая пишет вызов, они ничего не
дают, а сообщение об ошибке навык и так выдаст сам.
Убраны три таких места в properties-reference.md и child-operations.md.
Соседние утверждения сохранены — это настоящие ограничения: свойство можно
задать, даже если оно ещё не выставлено; допустимы имена свойств
соответствующего типа объекта; структурные свойства через Ключ=Значение не
задаются, кроме Type.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
modify-property писал значение свойства объекта в XML как есть: и "обороты", и
"turnovers", и "ЧтоУгодно". Навык печатал Modified: 1 и оставлял выгрузку,
которую платформа не примет. Расхождения портов тут не было — оба вели себя
одинаково, поэтому кампания паритета это не ловила.
Значение теперь проходит через normalize_enum_value — ту же функцию, что уже
применялась к свойствам реквизитов: алиас и регистр приводятся к канону,
неизвестное значение отвергается с перечислением допустимых ДО записи файла.
Поведение сведено к meta-compile, который так работает давно.
Словарь алиасов в meta-edit обёрнут в CIDict: без этого правка сделала бы хуже
— "обороты" строчными не нашли бы ключ "Обороты" и получили бы отказ вместо
прежней тихой записи.
check-inline-drift: заведена семья normalize_enum_value (тела в обоих портах
совпадают побайтово, эталон meta-compile). Списки значений по-прежнему держит
check-enum-drift, новых ключей не заводили.
Проверка: два кейса (синоним → канон в эталоне; мусор → expectError), 685/685
на PS и 682+3 skipped на PY, гарды 4/4. Платформенно: синтетический регистр,
правка через meta-edit, загрузка в 8.3.27 и обратная выгрузка — платформа
вернула Turnovers.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Волна закрыла ключи DSL и параметры CLI, но не значения внутри DSL: имя
операции сравнивалось точным совпадением, тогда как PS диспетчеризует через
switch, а он регистронезависим. На cf-edit "Modify-Property" PS применял, а py
писал Unknown operation; на subsystem-edit "Add-Child" py молча ничего не делал.
Имя операции теперь нормализуется в нижний регистр. skd-edit не затронут: у
него операция приходит параметром с choices, что уже закрыто ci_parse_args.
Заодно переписан кейс form-edit/lenient-key-case: он был написан в форме
operations/op, которой у навыка нет, — навык такой вход игнорирует, и кейс
проходил на обоих портах, не проверяя ничего. Теперь форма взята из
документации навыка, а в эталоне есть след эффекта. Кейсы cf-edit,
subsystem-edit и interface-edit расширены регистром значения операции.
Проверка: 683/683 (PS), 680+3 skipped (PY), гарды 4/4, 11 снэпшотов приняты
платформой, версии портов совпадают.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Дорожка DSL из кампании паритета. PowerShell читает свойства объекта из
ConvertFrom-Json без учёта регистра, Python — точным совпадением, поэтому
"Name" вместо "name" в py-порте молча не находился: навык печатал [OK], а
свойство в выход не попадало. На skd-compile это давало схему без запроса.
CIDict + ci_json (эталон — meta-compile) внесены в 10 портов, читающих
пользовательский DSL: cf-edit, form-compile, form-edit, interface-edit,
meta-edit, mxl-compile, role-compile, skd-compile, subsystem-compile,
subsystem-edit. Обёрнуты точки разбора DSL, операций и JSON, приходящего
значением параметра; реестр .v8-project.json намеренно не трогаем.
skd-edit в список не входит: он принимает операцию через -Operation с
choices, что уже закрыто ci_parse_args.
Каждому навыку добавлен кейс lenient-key-case: вход с перемешанным регистром
ключей, эталон один на оба порта — раннер гоняет обе среды, поэтому кейс сам
по себе проверяет паритет.
Проверка: 683/683 (PS), 680+3 skipped (PY), гарды 4/4, версии портов совпадают.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Дорожка CLI из кампании паритета: PowerShell не различает регистр ни в именах
параметров, ни в значениях [ValidateSet], argparse различает и в том и в
другом. Проверено на читающем навыке: cf-info -Mode BRIEF на PS отрабатывает,
на py падал.
ci_parse_args (эталон — meta-compile) вставлен в 68 py-портов, вызовы
parser.parse_args заменены. Навыков с DSL меньше трети, поэтому именно эта
правка делает паритет общим: *-info, *-validate, db-*, cfe-*, web-* тоже
принимают ввод так же, как их .ps1.
Реестр check-inline-drift дополнен списком потребителей — и сразу окупился:
поймал, что массовая замена переписала последнюю строку внутри самого
хелпера и копии стали рекурсивными.
Версии бампнуты синхронно в обоих портах всех 68 навыков.
Проверка: 673/673 (PS), 670+3 skipped (PY), гарды 4/4; паритет версий портов
проверен по заголовкам.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PowerShell не различает регистр нигде, куда попадает пользовательский ввод:
свойства объекта из ConvertFrom-Json, ключи Hashtable, -eq/-contains, имена
параметров, ValidateSet. Python различает везде, поэтому один и тот же DSL
давал разный результат на разных портах — и чаще всего молча: "CodeLength"
вместо "codeLength" в py просто не находился, навык печатал [OK], а свойство
в выход не попадало.
Пилот на meta-compile. В py-порт добавлены общие обёртки: CIDict (поиск без
учёта регистра, ключи хранятся как есть — часть из них имена объектов и
попадает в XML), ci_json (рекурсивно на разобранный DSL), ci_parse_args (имена
параметров и значения choices). Ими же обёрнуты словари синонимов видов,
алиасов enum и типов.
Попутно исправлен дефект самого канона: PS принимал "type":"catalog", но
дальше использовал значение как есть — в имени тега и в регистрации в
Configuration.xml, то есть отдавал <catalog>, которую платформа не примет.
Теперь вид приводится к канону списка в обоих портах.
check-inline-drift: extractPy научен доставать class (иначе тело CIDict
невидимо), заведены три семьи с ps1: null — в PS1 этих обёрток быть не должно.
Проверка: кейс lenient-key-case зелёный на обоих портах; полный регресс
673/673 (PS) и 670+3 skipped (PY); гарды 4/4; sweep по 400 справочникам трёх
конфигураций (декомпиляция → компиляция обоими портами) — 0 расхождений.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Компилятор эмитил ExtDimensionN/ExtDimensionTypeN только по ключам DSL,
поэтому регистр, созданный по неполному описанию, не совпадал с тем, что
материализует платформа: пары дописывались лишь при загрузке.
Теперь их число выводится из MaxExtDimensionCount плана счетов, на который
ссылается регистр, — файл читается из выгрузки, как версия формата из
Configuration.xml. ExtDimensionN получает LinkByType на Account с LinkItem
по номеру. Выведенный хвост дополняет DSL, а не заменяет: ключи из описания
остаются, недостающее добавляется.
План счетов не найден в выгрузке (ещё не создан, лежит вне каталога) — пары
не генерируются, в вывод идёт [HINT]: платформа допишет их сама при загрузке.
Проверка: матрица из трёх случаев (план с 3 субконто, план с 0, план
отсутствует) на обоих портах; синтетика загружена в 1С и выгружена обратно —
состав и порядок совпали; корпусный роундтрип 739 регистров без расхождений.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Справочник порядка StandardAttributes был неполон у трёх видов регистров, а
неизвестные имена эмитятся перед фикс-списком — платформа их вкрапляет, и
роундтрип переставал быть побайтовым.
Порядок снят с выгрузки платформы, присутствие условных реквизитов теперь
выводится из свойств объекта (periodAdjustmentLength, correspondence,
registerType), а не из наличия ключа в DSL: иначе регистр, создаваемый с нуля,
терял реквизит, который платформа обязана материализовать. Наличие ключа
осталось дополняющим условием, чтобы роундтрип не зависел от точности вывода.
- регистр расчёта: 11 реквизитов, состав безусловен (проверено матрицей
actionPeriod × basePeriod × периодичность на 8.3.27)
- регистр бухгалтерии: PeriodAdjustment при длине периода корректировки > 0,
RecordType при correspondence=false
- регистр накопления: RecordType только у регистра остатков
meta-validate: снято ложное предупреждение об «unexpected» RecordType у
бухрегистра, условные реквизиты исключены из проверки missing.
Проверка: 739 регистров по шести конфигурациям — 0 расхождений; снэпшоты
пересняты и верифицированы загрузкой в 1С.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проверка «работает ли гард во все стороны» вскрыла, что он проверяет только
заявленные карты. Попытка автообнаружения незаявленных дала 112 срабатываний,
из них большинство — ложные (накопители массивов, чей блок разбирается неверно),
поэтому сама проверка в гард не попала. Но она нашла реальное:
у cfe-patch-method карта типов не была в реестре, и порты по ней разошлись —
PS1 принимал и Catalog.X, и Catalogs.X (32 записи), PY только Catalog.X (16).
Расхождение доставшееся, не из этой ветки. PY дополнен формами множественного
числа: ввод, работавший в одном порте, теперь работает в обоих.
В реестр карт типов добавлены cfe-patch-method (TYPE_DIR_MAP, DIR_TO_TYPE),
cf-edit.RU_TYPE_MAP и cfe-borrow.SYNONYM_MAP — 28 проверяемых карт стало 36.
Для частичных карт добавлен флаг partial (полнота не требуется, каталоги
сверяются), для прощающих — keyMayBeDir (ключом принимается имя каталога).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Шесть *-info изменены переименованием is_external_root ->
_sg_is_external_root без бампа версии. Поднято в обоих портах синхронно, как
требует конвенция, хотя менялся только .py.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Разбор остатка по support-guard показал, что расхождения портов у *-info нет:
они читают тем же хелпером состояние поддержки для вывода, и фича есть в обоих
портах. Пропускал копии сам гард.
Два дефекта извлечения, оба давали ложное «OK», а не ложную тревогу:
1. PY: вложенные определения. Пять *-info объявляют is_external_root внутри
другой функции; экстрактор искал только `^def` и перескакивал через тело
внешней функции, так что вложенные для гарда не существовали.
2. PS1: однострочные функции. subsystem-info.ps1:18 — `function Out(...) { ... }`
в одну строку; поиск закрывающей `}` на отдельной строке делал «телом» Out всё
до следующей одиночной скобки, проглатывая следующую функцию.
После починки гард увидел 9 копий, которых не видел, — все совпали с эталонами.
Побочно вскрылось, что Report-OK в interface/subsystem/xdto-validate тоже был
невидим и потому не попал в прошлое сведение Report-*; теперь сведён.
Осталось расхождение имён: одно тело называлось _sg_is_external_root (17),
is_external_root (5 *-info) и _meta_is_external_root (meta-info). В PS1 имя было
единым изначально; PY сведён к _sg_is_external_root.
Реестр: 24 семьи, 319 копий (было 310), долг ноль.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Своя версия решала по правилу «файл Ext/ParentConfigurations.bin существует →
запретить». Общая разбирает заголовок bin и решает по конкретному объекту; в
частности у неё есть ветка `if k == 0: return` — если на поддержке нет ни одного
объекта, запрещать нечего.
Эксперимент на копии каталога конфигурации ERP (заголовок bin = {6,0,0,0,1,0},
K=0): meta-compile создавал объект, xdto-compile на том же каталоге отказывал.
То есть XDTO-пакет нельзя было добавить туда, где справочник добавляется
свободно. У acc_8.3.24 и ut_8.3.27 заголовок {6,1,1,...} (G=1, вся конфигурация
read-only) — там обе реализации отказывали одинаково.
Своя версия строго более ограничительна, поэтому это не дыра, а ложные отказы
плюс неинформативное сообщение. После правки ERP разрешает, acc по-прежнему
отказывает — и уже с диагнозом и шагами через support-edit.
Долг реестра inline-реализаций обнулился: 24 семьи, 310 копий, вариантов без
обоснования не осталось.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прямой ответ на вопрос ишью #60. Гард inline-реализаций держал функции, но не
словари — а именно там расхождение и накапливалось молча: тип Bot существовал в
таблице спецификации и в трёх навыках, в остальных двенадцати его не было, и
заметить это было нечем.
Эталон — таблица «Порядок типов в ChildObjects» из docs/1c-configuration-spec.md
(45 типов: имя, каталог, позиция). Берём документацию, а не отдельный JSON: тогда
спека и код не расходятся молча, что и было целью ишью.
Модель двухуровневая, как и предлагалось в обсуждении: общее ядро (имя, каталог,
порядок) обязано совпадать у всех, а навык объявляет своё подмножество —
исключение с ПРИЧИНОЙ. Проверка отличает намеренное ограничение от забытого типа.
Сейчас исключение ровно одно: Language в cfe-diff, где записи в карте были бы
недостижимы.
Вокабуляры навыков (TYPE_ALIASES, TYPE_NORM_MAP, CONTENT_TYPE_MAP, TYPE_PLURAL_MAP)
проверяются слабее: полнота не требуется, но каждое каноническое имя обязано
существовать в таблице — это ловит опечатки. Пустое извлечение карты считается
ошибкой разбора, иначе непонятый формат прошёл бы вхолостую.
Проверено негативом: убранный тип, подменённый каталог и переставленный порядок
дают ERROR и exit 1.
cfe-borrow/SKILL.md: убрано обещание про количество поддерживаемых типов — оно уже
протухло (было 44) и является обязательством, которое навык не проверяет.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
interface-edit знал CalculationRegisters и ChartsOfCalculationTypes только
по-английски: РегистрРасчёта/РегистрРасчета и ПланВидовРасчёта/ПланВидовРасчета
не принимались ни в каком написании. Добавлены также Роль, ОбщийМакет,
ЭлементСтиля, ОбщийРеквизит, ГруппаКоманд — в единственном и множественном числе.
role-compile принимал только формы без ё (Отчет, РегистрРасчета,
ПланВидовРасчета), тогда как meta-compile, form-compile и subsystem-навыки
принимают обе. Добавлены варианты с ё.
Правка аддитивная: ввод, который работал, продолжает работать.
cfe-borrow/SKILL.md: «все 44 типа» -> 45 (таблица ChildObjects включает Bot и
Language, оба подтверждены платформенной пробой).
Кейс role-compile/type-aliases-yo проверен негативным прогоном на своём порте.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформенная проба (свежий стенд 8.3.24, загрузка + обратная выгрузка) сняла
вопросы, которые ревизия #60 оставила на догадках:
Bot в ChildObjects конфигурации — принят, пережил раундтрип
Bot.X в <Content> подсистемы — принят, пережил раундтрип
Bot в ChildObjects расширения — принят, пережил раундтрип
второй Language заимствован в расш. — принят, пережил раундтрип
Порядок, выданный платформой (Language, Subsystem, Bot), совпал с таблицей
docs/1c-configuration-spec.md, где Bot стоит под № 11.
Правки:
- cfe-diff: +Style, +XDTOPackage, +WebService, +HTTPService, +WSReference, +Bot
(38 -> 44). Карта используется в трёх местах — обзор Mode A, поиск модулей и
проверка переноса Mode B, — поэтому объект неизвестного типа выпадал из всех.
- cfe-borrow: +Bot, +Language (43 -> 45), Bot в TYPE_ORDER;
- cfe-validate: +Bot (44 -> 45);
- subsystem-compile, subsystem-edit: +Bot в CONTENT_TYPE_MAP.
Language в cfe-diff НЕ добавлен: навык намеренно пропускает языки при сборе
объектов (cfe-diff.py:530), запись в карте была бы недостижима.
Прежняя оценка «отсутствие Language в cfe-borrow вероятно законно» опровергнута:
в расширении из корпуса язык помечен ObjectBelonging=Adopted, то есть заимствован,
и второй язык заимствуется штатно.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Храповик без пояснения читается как «когда-нибудь свести». Разбор показал, что
из четырёх оставшихся семей одна вообще не является общей: import_fragment имеет
разные сигнатуры и разные наборы xmlns по навыкам — одно имя на разные задачи,
сводить его нельзя. Остальные три сводятся, но каждое сведение меняет вывод и
требует решения, а не аккуратности.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
У write_xml_file в docstring прямо написано «Держать копии одинаковыми —
сознательно: разошедшиеся копии сводят на нет весь смысл», и при этом копий было
три варианта. Различие оказалось не в логике нормализации, а в имени
вспомогательной функции записи байт: write_utf8_bom (11 навыков),
write_text_with_bom (form-add, help-add, template-add), save_text_bom
(cfe-borrow) — тела всех трёх побайтово эквивалентны.
Имя сведено к write_utf8_bom, тело помощника — к общему эталону (различались
только имена переменных). PS1-порт Write-XmlFile расхождений не имел.
Обе семьи переведены из храповика в реестр с эталоном: 24 семьи, 309 копий,
разъехавшихся осталось 4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
interface-validate, subsystem-validate и xdto-validate отличались от остальных
шести валидаторов только стилем: инлайн-сигнатура вместо param-блока и
однострочный if. Приведены к эталону cf-validate.
form-validate и mxl-validate оставлены отдельным вариантом с обоснованием:
они пишут через Write-Host, а не через буферизованный Out-Line. Буферизация
нужна для -OutFile (тот же отчёт в файл), которого у этих двух навыков нет;
для модели-потребителя stdout одинаков — на успешном прогоне обе ветки дают
одну строку.
Семьи Report-OK/Error/Warn переведены из храповика в реестр с эталоном.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
format_rank в meta-validate отличался только именем параметра, _version_key в
web-publish инлайнил каталог версии вместо общего _version_dir (и знал только
Windows-раскладку .../bin/exe). Обе копии приведены к эталону db-create/
meta-compile; для Windows-навыка web-publish поведение не меняется.
В реестр добавлены семьи _version_dir и _find_project_v8path.
Экстрактор PS1 в гарде и сканере научен видеть вложенные определения: db-load-git
объявляет Find-ProjectV8Path внутри if, и поиск по `function` с нулевой позиции
считал функцию отсутствующей. Конец тела теперь ищется по закрывающей скобке на
отступе самого слова function.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
esc_xml был один на две задачи, и в атрибутном контексте применялся текстовый
вариант без ". form-compile с choiceParameters, имя которого содержит
кавычку, выдавал <app:item name="Отбор.Наименование "кавычка"">: lxml падает с
attributes construct error, то есть файл невалиден как XML. Затронуто 9 мест в
form-compile и 3 в skd-compile, одинаково в обоих портах.
Раундтрип через базу показал границу: в ТЕКСТЕ элемента платформа экранирует
только & < > (кавычка и апостроф возвращаются сырыми байт-в-байт), а в ЗНАЧЕНИИ
АТРИБУТА пишет " — внутри "..." литеральная кавычка невалидна. Поэтому две
функции с говорящими именами, а не одна с флагом:
esc_xml — значение атрибута: & < > "
esc_xml_text — текст элемента: & < >
Заодно закрыто расхождение портов в init-навыках: PY экранировал текст с ",
PS1 — через SecurityElement::Escape (ещё и '), а epf-init/erf-init в PS1 не
экранировали вовсе, из-за чего амперсанд в синониме давал невалидный XML.
Кейсы: form-compile/attr-value-escaping, skd-compile/additional-properties-escaping,
cf-init/synonym-escaping — все три проверены негативным прогоном на обоих портах
и верификацией снэпшотов на платформе.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Имя префикса для .../8.1/data/enterprise/current-config платформа выдаёт по
порядку объявления в файле: в корпусе acc_8.3.27 на этом URI встречаются d4p1,
d5p1 и d6p1. Литеральное d5p1: покрывало лишь часть случаев — тип, скопированный
из Predefined.xml, приходит с d4p1: и даёт ту же ошибку «Неизвестное имя типа».
Обобщено до ^d\d+p\d+: — так же, как это уже делает form-info. Условие «только у
ссылочных типов, с точкой» сохранено: все 11 спец-типов чужих пространств имён
(d5p1:Chart, mxl:SpreadsheetDocument, pl:Planner и др.) точки не имеют.
Регресс-кейс расширен на d4p1 и d6p1: все шесть форм ввода дают один
cfg:CatalogRef.Склады.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Шесть копий resolve_type_str разошлись на 6 вариантов в PY и 4 в PS1, а вместе
с формой разошлось и поведение: префикс ссылочного типа срезал только
form-compile.
Проверка на платформе (стенд 8.3.24.1691, cf-init → meta-compile → db-load-xml)
показала, что это не косметика. Префикс ломает поиск в словаре синонимов, из-за
чего русское имя типа остаётся непереведённым:
СправочникСсылка.Склады → cfg:CatalogRef.Склады (верно)
cfg:СправочникСсылка.Склады → cfg:СправочникСсылка.Склады (неверно)
Платформа отвечает «Неизвестное имя типа - СправочникСсылка.Склады» и
отклоняет загрузку. Именно с префиксом тип и написан в выгрузке, откуда
пользователь его копирует.
cfg: снимается всегда, d5p1: — только у ссылочных типов (с точкой): сам по себе
префикс неоднозначен, в формах d5p1:Chart, d5p1:TextDocument и ещё три типа
адресуют свои пространства имён, и там он часть канонического значения. Первая
версия правки срезала его безусловно и уронила 4 кейса form-compile.
Тело общее для всех шести навыков; словари синонимов остаются локальными, навык
объявляет на свой словарь алиас TYPE_SYNONYMS / $script:typeSynonyms.
Регресс-кейс meta-compile/type-prefix-lenient проверяет все три формы ввода.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Семья была разбита на «знает про автономную EPF/ERF» (form-*, mxl-compile,
template-add, help-add) и «не знает» (cfe-borrow, interface-edit, meta-compile,
role-compile, subsystem-compile, xdto-compile), плюс редакторски разошедшаяся
PS1-копия help-add.
Расширенный вариант корректен и для конфигурационных навыков: ветка срабатывает
только если <каталог>.xml — корень ExternalDataProcessor/ExternalReport, чего в
дереве конфигурации не бывает. Переключатель не нужен — раскопирован как есть.
Семья в реестре схлопнута до одного варианта: 11 копий, оба порта.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Оба навыка бракуют корректное значение: allowlist содержал только
[DontUse, AutoUse], тогда как meta-compile знает три значения.
Прав meta-compile: docs/meta-dsl-spec.md перечисляет DontUse / Use / AutoUse,
в выгрузке прикладной конфигурации встречаются все три (DontUse ×17,
AutoUse ×2, Use ×1).
Расхождение ловил check-enum-drift.mjs, но гард не был подключён ни к runner-у,
ни к README, поэтому не запускался. Теперь он входит в check-all.mjs.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Навыки автономны, общие утилиты копируются в каждый .ps1/.py, но нигде не было
зафиксировано, какая копия эталонная и какие расхождения законны. Ревизия по #60
показала два класса семей: одни держатся побайтово (support-guard — 16 копий,
db-обвязка — 12), другие разъехались без эталона (resolve_type_str — 6 копий и
6 вариантов, get_ml_text — 7 и 7).
check-inline-drift.mjs держит реестр семей внутри себя: вариант → эталон → копии.
Копия обязана совпадать с эталоном своего варианта; отклоняющийся вариант обязан
иметь обоснование, иначе печатается как долг. Часть расхождений законна (esc_xml
без " в form-* ради раундтрипа), поэтому модель хранит варианты, а не одно
эталонное тело. Разъехавшиеся целиком семьи стоят на храповике maxVariants.
Извлечение тел: PS1 — до строки ровно `}` (балансировка скобок даёт ложные
18 вариантов из 18 копий Assert-EditAllowed); PY — с обязательным снятием
docstring-ов (иначе одинаковый код с разным описанием читается как расхождение).
check-all.mjs — единая точка входа: check-enum-drift и check-uuid-invariant были
рабочими, но не упоминались в README и никем не запускались.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В «Как читать вывод» протекли внутренности фильтра журнала (коды сообщений
Apache, что именно отсеивается и почему) и обоснование правки. Модели,
использующей навык, нужны сигналы и действие по ним, а не устройство.
В web-publish по той же причине убрано имя атрибута дескриптора.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Статус строился только по наличию процесса httpd: при живом процессе и
не поднявшемся сервере (занятый порт, битый конфиг) навык рапортовал
«Запущен». Теперь порт из Listen проверяется TCP-коннектом на 127.0.0.1
с таймаутом 1 с — «(слушается)» / «(не отвечает)».
Сами публикации намеренно не опрашиваются: запрос к /{AppName} поднимает
сеанс веб-клиента 1С и занимает лицензию, а публикаций может быть много.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Печатались последние 5 строк журнала как есть, поэтому секция «Последние
ошибки» показывала notice старта, а на Windows ещё и штатный шум
winnt_accept — содержательные записи вытеснялись. Теперь фильтр по уровню
error/crit/alert/emerg; AH02538 отсеивается отдельно как след нашего же
рестарта Apache при публикации.
Путь к журналу печатается всегда — за отсеянными уровнями и полным
контекстом читается файл.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
