Три находки, все воспроизведены:
1. Счётчик членов составного типа не видел форму с локальной xmlns:
тип из чужого пространства имён пишется как <v8:Type xmlns:mxl="…">, а
регулярка требовала '>' сразу за именем тега. В итоге на одном и том же
файле meta-compile молчал, а meta-validate предупреждал — навыки
расходились в оценке одного содержимого. Радиус: оба порта.
2. Report-OK проверки 23 печатался безусловно — то есть сразу после
собственного ERROR, и раздувал счётчик проверок в итоговой строке.
Соседние проверки (21, 22) так не делают.
3. ToString() копировал весь буфер вывода на каждый реквизит: O(n^2) на
крупном объекте. В файле уже есть ranged-перегрузка ровно для этого
(Emit-TypeContent). py-порт был изначально корректен — он режет список.
Добавлен кейс на тип с локальной xmlns: без него находка 1 вернулась бы
незамеченной, потому что обычный составной тип её не показывает.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Запрет неочевидный, а отказ платформы приходит поздно и одной строкой из
Конфигуратора. Три уровня строгости, все замерены загрузкой в базу на
8.3.24.1691, а не выведены из документации:
- ОШИБКА — множество в составе определяемого типа. Платформа отвергает файл
целиком («ОпределяемыйТип.<Имя> - Недопустимый тип»); проверено на
ОпределяемыйТип, Характеристика, ЛюбаяСсылка и голых ссылках, контрольный
вариант с обычным CatalogRef.<Имя> принят. Отсюда и ноль таких узлов в
корпусе — это запрет, а не совпадение.
- ПРЕДУПРЕЖДЕНИЕ — голый метатип в типе значения ПВХ. Загрузка проходит, но
Конфигуратор такой тип не предлагает: в дереве выбора СправочникСсылка и
ДокументСсылка — папки без флажка, а ЛюбаяСсылки там нет вовсе. Плюс AnyRef
раундтрипом возвращается как AnyIBRef, то есть молча меняется.
- ПРЕДУПРЕЖДЕНИЕ — определяемый тип одним из составного. Конфигуратор даёт
выбрать его только единственным, но отказывать нельзя: в корпусе erp+acc
6500 единственных против 1 составного, и этот один лежит в типовой ERP
(Документ.НачислениеИСписаниеБонусныхБаллов.Баллы — два определяемых типа
подряд). Навык не вправе отказаться собрать то, что поставляет 1С.
В meta-compile состав множеств берётся опросом самого эмиттера, а не второй
копией его регулярок: список видов живёт в Emit-TypeContent, и копия
разъехалась бы с ним молча.
Развёртка по 3428 объектам ERP: ровно 2 срабатывания, оба на том самом
реальном составном реквизите. Ложных нет.
Предупреждения пишутся прямо в stderr, а не через Write-Warning: в PS 5.1 тот
уходит не в тот поток (конвенция из cf-init), и до проверки они не доезжали.
Оба кейса-предупреждения проверены платформой — она эти конфигурации грузит,
что и подтверждает выбор «предупреждение, а не отказ».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Правка нарушала два наших правила сразу. Фраза «русские имена принимаются
наравне с английскими» описывала прощающий ввод — его документировать нельзя,
иначе модель получает развилку вместо одной каноничной формы. Замечание «в
выгрузке ERP так задана треть подписок» — про наше исследование, а не про
использование навыка: следов фикса в инструкции не держим.
Формы источника остаются описанными в docs/meta-dsl-spec.md, а круг
«вывод meta-info → вход meta-compile» держит check-typeset-coverage.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Семь находок ревью, все подтверждены воспроизведением:
1. Голый менеджер в источниках печатался по-английски: карта объектных видов
применялась только к форме с точкой, а meta-compile пишет «cfg:DocumentManager»
обычным v8:Type. Восемнадцать добавленных *Manager-записей были недостижимы.
Суффикс «(все)» ему не ставится — это сам тип менеджера, а не класс объектов.
2. Новые регулярки прощающего ввода расходились между портами: -replace в
PowerShell регистронезависим, re.sub — нет. «ДокументОбъект (Все)» проходил в
ps1 и падал в py. Добавлен re.IGNORECASE — это задокументированная ловушка
портирования, и она же снова сработала.
3. В шесть py-портов попал BOM (перекодировка при бампе версии), и перед
«#!/usr/bin/env python3» он ломает shebang на POSIX. Снят там, где его не было
в HEAD; в mxl-compile.py он был изначально и оставлен.
4. Правило со стрелкой из Resolve-TypeStr убрано. form-compile режет тип по [|+]
ДО резолвера, поэтому строка глоссария «A -> B | C» молча превращалась в
составной тип «A | C» вместо одного A. Половина строки, принятая за тип, —
хуже громкого отказа. Остались суффикс «(все)» и счётчик «— типов: N».
5. py-порт meta-info не переиспользовал общий климб до корня конфигурации:
правка тогда молча не применилась, и порты разошлись по структуре.
6. Found выставлялся до разбора состава определяемого типа: падение внутри
давало «состав пуст» — ложь вместо «файл типа не разобран».
7. Порог сворачивания источников считался по сумме множеств и явных типов, а
сворачивались только явные: пять множеств плюс один тип прятали этот тип, а
шесть типов без множеств давали «и ещё» после пустоты. Порог теперь по числу
явных типов, «и ещё» убрано как ложное.
Плюс формы источника подписки описаны в reference самого навыка: раньше они
были только в docs/meta-dsl-spec.md, а навык обязан быть самодостаточным.
Добавлен кейс на голого менеджера — без него находка 1 вернулась бы незамеченной.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
verify-snapshots отверг кейс: «ОпределяемыйТип.Любой - Недопустимый тип».
Спросил платформу — v8:TypeSet внутри определяемого типа запрещён вообще, и не
только AnyRef: отвергнуты также голый CatalogRef, Characteristic.X и вложенный
DefinedType.X, при том что контрольный вариант с обычным CatalogRef.X принят.
Замерено на 8.3.24.1691 загрузкой в базу. Отсюда и ноль таких узлов в корпусе —
это не совпадение, а запрет.
Комментарий в обоих портах утверждал обратное («платформа допускает») — правда
записана, факт добавлен в docs/meta-dsl-spec.md.
Сам разбор v8:TypeSet в выводе определяемого типа оставлен: meta-info читалка,
и рукотворный файл с таким узлом она обязана показать честно, а не потерять его
молча вместе с правдивым счётчиком. Кейс переведён на рукотворную фикстуру с
объявленной причиной пропуска платформенной проверки.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Покрытия не было вообще: ни одного кейса ни на подписку на событие, ни на
определяемый тип. Поэтому дефект и жил — тесты были зелёными всё время.
Добавлено девять кейсов:
- источники-множества в full/overview/brief (класс «все», определяемый тип,
явный тип) — основа взята из PR #96, эталоны под наш формат;
- определяемого типа нет в выгрузке: сказано прямо, а не молчанием;
- односоставный псевдоним в типе реквизита — главный по частоте случай в
реальных выгрузках (7575 вхождений из 8841 в ERP);
- определяемый тип выше порога: вместо состава счётчик и команда раскрытия —
этот кейс держит решение «не раскрывать», без него регрессия вернула бы
шестисотстрочный вывод;
- голый метатип в типе реквизита: суффикс «(все)» против конкретного типа;
- определяемый тип, содержащий множество: счётчик «Типы (N)» его не теряет;
- явных источников больше порога: overview сворачивает их в счётчик.
Фикстуры строятся навыками через preRun, чтобы эталоны не плавали по uuid.
Co-Authored-By: Шпаков Антон Александрович <shpakov.anton.job@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Раздел знал только ссылочные метатипы, хотя meta-compile объектные эмитит
правильно, а источники подписок на событие построены именно на них: в
erp_8.3.24 так задана треть подписок. Дописаны объектные виды, наборы записей
и ConstantValueManager, отмечено, что прочие менеджеры множеством не являются,
и зафиксирован суффикс «(все)» в выводе meta-info.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Связь «прочитал вывод → подал на вход» держалась на честном слове и рвалась
молча в обе стороны: meta-info печатал метки, которых нет в словаре
meta-compile (33 из 41), а в карте meta-info не было видов, которые
meta-compile эмитит, — и они печатались по-английски посреди русского вывода.
Снэпшоты этого не видят: кейсы читают и компилируют по отдельности, круг не
замыкая.
Инвариант строгий в одну сторону: каждая метка читалки обязана быть ключом в
typeSynonyms у meta-compile и вести ровно в тот же канон. Обратное неверно
намеренно — компилятор знает формы, которых читалка не печатает. Заодно гард
сверяет objectTypeMap и refTypeMap между портами навыка: переводы — часть
вывода, и расхождение портов дало бы разный текст на один и тот же файл.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Вывод читающего навыка модель несёт обратно в компилятор, а тот его не
понимал. Из 41 метки, которую печатает meta-info, в словаре typeSynonyms не
было 33: «ДокументОбъект.Заказ» из источников подписки meta-compile отвергал с
«Неизвестный тип», хотя сам же печатал эту форму через meta-info. Не
принимались и «ПВХСсылка.ВидыСубконто», и «Характеристика.Виды» — при том что
Characteristic.Xxx описан в спеке как штатная форма DSL.
Добавлены русские имена объектных типов, менеджеров и наборов записей.
Аббревиатуры (ПВХ/ПВР, РС/РН/РБ/РР) приняты наравне с полными именами: вывод
навыка сокращает долгие виды, чтобы в списке на сорок реквизитов не терялось
имя объекта, и раз он их печатает — обязан принимать.
В Resolve-TypeStr снимаются хвосты, которые дописывает глоссарий meta-info:
суффикс «(все)», счётчик «— типов: N» и раскрытие после стрелки. Срезаются
только эти известные формы — круглые скобки заняты параметризованными типами
вроде Число(15,2), слепой срез сломал бы их.
Функция под гардом check-inline-drift, поэтому правка синхронна во всех семи
навыках и обоих портах.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Источники подписки на событие читались только из v8:Type. Если источник задан
множеством — определяемым типом или целым классом «все документы» — строки
«Источники» не было вовсе, и подписка выглядела так, будто ни на что не
срабатывает. В erp_8.3.24 так задана треть подписок: 151 из 492 вообще без
v8:Type, в acc_8.3.24 — 126 из 443.
Тот же дефект в типах реквизитов, и там он чаще. Вхождений
v8:TypeSet>cfg:DefinedType в Catalogs/Documents/InformationRegisters/
AccumulationRegisters ERP — 8841, из них 7575 (86%) указывают на определяемый
тип ровно с одним членом. АвансовыйОтчет печатал «Сумма
ОпределяемыйТип.ДенежнаяСуммаНеотрицательная», и было не видно, что это
Число(15,2): имя выглядит как ссылочный тип. Голый метатип-категория
(«ДокументСсылка» без точки = любой документ) отличался от конкретного
«ДокументСсылка.Заказ» только наличием точки посреди длинного имени.
Правило одно на все места: имя множества стоит в строке типа, а раскрытие —
ровно одной записью на уникальное множество, глоссарием в конце вывода.
Раскрывать в строке нельзя дважды: псевдоним повторяется в объекте десятками
раз (в АвансовомОтчете — 12), а в корпусе есть определяемые типы на 596 типов —
вывод упёрся бы в постраничник и съел хвост объекта. Выше порога
composedTypeThreshold вместо состава идут счётчик и готовая команда раскрытия.
Голый метатип получает суффикс «(все)»: разница становится словом, а не
пунктуацией. Характеристика ПВХ помечена как набор, определяемый данными, —
из выгрузки её состав не берётся в принципе.
Попутно того же класса:
- объектные типы (DocumentObject.X, *RecordSet.X, *Manager.X) печатались
по-английски в выводе определяемого типа и по-русски в источниках подписки —
одно понятие двумя видами; в карту добавлены недостающие виды, включая
ConstantValueManager и ChartOfCalculationTypesObject;
- собственный вывод определяемого типа читал только v8:Type и молча терял
v8:TypeSet — счётчик «Типы (N)» врал;
- корень конфигурации ищется климбом до Configuration.xml, общим с проверкой
поддержки, а не фиксированным «на два уровня выше»;
- состав определяемого типа кэшируется по имени;
- нечитаемый файл типа назван нечитаемым, а не отсутствующим.
Проверено корпусом: 5129 прогонов по erp_8.3.24 и acc_8.3.24 в трёх режимах,
каждое расхождение с эталоном до правки классифицировано, необъяснённых нет.
Паритет портов — 5129 из 5129, 103912 строк совпали.
Проблему и замеры по подпискам сообщил автор PR #96.
Co-Authored-By: Шпаков Антон Александрович <shpakov.anton.job@gmail.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
PowerShell ищет функцию в момент вызова и видит только уже выполнившиеся
объявления. В трёх навыках блок Find-V8Project/Test-SamePath/Find-ProjectDatabase
оказался ниже строки, где отрабатывает Find-ProjectV8Path: CommandNotFoundException
уходил в stderr, результат становился $null, и выбор платформы по записи базы молча
откатывался на корневой v8path. Порты .py не задеты — Python связывает имя при
вызове, так что расхождение PS↔PY было бы тихим.
Гард check-ps-define-before-call.mjs проверяет порядок объявлений во всех .ps1,
где отрабатывает эта цепочка (15 навыков), и на прежнем состоянии даёт ровно те
три диагностики. Кейс db-repo/v8path-from-database ловит тот же дефект поведением.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В одном проекте базы могут жить на разных версиях платформы, а версию формата
XML-выгрузки задаёт та платформа, которая выгружает: без выбора платформы по базе
срабатывает автопоиск и берёт самую старшую установленную — то есть самый новый
формат, который коллега на младшей платформе уже не загрузит.
Теперь порядок такой: явный -V8Path -> v8path записи базы -> корневой v8path ->
автопоиск. Запись базы ищет сам скрипт тем же матчем, которым добывал реквизиты
хранилища (Find-ProjectDatabase): файловую по path, серверную по server + ref.
- в 9 навыков, где матча не было, скопирован блок из авторитета db-repo;
- списки потребителей трёх семей в check-inline-drift расширены; заведена семья
platform: resolve_v8path — обёртка меняла сигнатуру, а под гардом не была;
- раннер подставляет {workDir}/{fakePlatform} и в содержимое preRun.writeFile,
иначе кейс про выбор платформы нельзя написать кроссплатформенно;
- в SKILL.md платформа теперь берётся ПОСЛЕ разрешения базы, строка про
автоопределение через Program Files убрана как деталь реализации.
Живой прогон: две базы в одном проекте при корневом v8path = 8.5 дали формат
2.17 (8.3.24) и 2.20 (8.3.27), оба порта.
Closes#93
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Оба кейса не проходили проверку эталонов платформой, и по разным причинам.
region-reuse клал в расширение декоративный перехватчик &Перед("МетодА"),
чтобы навыку было куда встроиться, но МетодА в конфигурации не было — только
МетодБ. Раннер этого не видел: он сверяет выход навыка, а навык отрабатывал
верно. Платформа же расширение не принимала: «Не найден метод "МетодА",
указанный в аннотации». Метод добавлен в модуль конфигурации; выход навыка не
изменился, сдвинулся только эталон исходного модуля.
resync-conflict моделирует неразрешённый конфликт: навык намеренно паркует
блок под меткой // [РЕСИНК-КОНФЛИКТ] и оставляет его человеку, так что текст
метода заведомо расходится с оригиналом и расширение неприменимо by design.
Это штатный случай для skipPlatformVerify — объявлен с причиной.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Две находки ревью.
Приняв хвостовой комментарий у маркера, разбор запоминал только содержимое
блока, а -Actualize писал на его место голое ключевое слово: авторская пометка
вроде «#Вставка // проверка прав, ТЗ-142» молча исчезала при первой же
актуализации. Теперь строки открывающего и закрывающего маркера едут вместе с
блоком и возвращаются как были — с комментарием, отступом и своим написанием;
ключевое слово остаётся запасным вариантом. Кейс actualize-marker-tail-comment
эту потерю ловит: без правки падает.
Счётчик контролируемых методов в cfe-validate был единственным новым
сопоставлением без учёта регистра, хотя язык регистронезависим: на
&changeAndValidate он показывал ноль и расходился с cfe-patch-method -Check,
на который сам же и ссылается.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Пара And/И в таблице была, а Or/Или — нет: при снятии пар с таблицы строк
платформы односимвольные слова отсеял фильтр длины, и пропуск не бросался в
глаза. Сегодня кода, который эмитирует Или, нет (условия собираются только из
НЕ и И), так что дефекта это не давало, но таблица — единственное место
правды о языке, и дыра в ней ждала своего часа.
Заодно подписано, почему отрицание эмитируется как "НЕ": платформа пишет
"Не", язык регистронезависим, а смена регистра сдвинула бы все эталоны.
Val, Insert/EndInsert и Delete/EndDelete перепроверены на платформе, а не по
дампу бинарника: их английские написания в таблице строк не видны из-за
склейки одинаковых литералов. Оракул — проверка применимости расширения:
Val Item и Знач Item платформа считает одним списком параметров, блоки
#Delete/#EndDelete принимает, а подсунутый #Deletee отвергает
(«Ожидается оператор препроцессора»).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Шесть кейсов: дрейф и актуализация английского перехватчика, генерация
ИзменениеИКонтроль и Instead из английского источника, отчёт cfe-diff,
счётчик cfe-validate, плюс русский кейс с хвостовым комментарием у маркера.
Эталоны фиксируют главное: сгенерированный код повторяет язык источника,
а -Actualize оставляет Procedure и #Insert английскими.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Платформа принимает встроенный язык в двух написаниях, а навыки читали только
русское: в расширении на английском перехватчики и блоки правок не находились,
и отчёт выглядел чистым. -Check молчал, cfe-diff не показывал вставки,
счётчик контролируемых методов в cfe-validate давал ноль.
Пары ключевых слов сверены по таблицам строк платформы (backbas.dll, bsl.dll),
а не по памяти. Разбор стал двуязычным везде, где навык читает модуль:
аннотации, объявления и Конец*, Знач, директивы контекста, препроцессор в
цепочке обрамления, поиск региона при переиспользовании.
Маркеры правок распознаются по началу строки, а не сравнением целой строки, —
заодно перестал теряться хвостовой комментарий (#Вставка // старая логика).
Эмиссия подчиняется одному правилу: отдаём тем языком, который прочитали.
Генерация берёт язык метода-источника, -Actualize — язык переписываемого
перехватчика, чтобы актуализация не превращала чужие Procedure и #Insert в
русские. Комментарии и вывод в консоль остаются русскими.
Таблица ключевых слов и разбор аннотаций скопированы в три навыка и заведены
семьями в реестре анти-дрейфа: разъехавшаяся пара слов дала бы ровно тот же
тихий ложно-чистый отчёт.
Проверено платформой: расширение с &ChangeAndValidate принимается
(/CheckCanApplyConfigurationExtensions), после дрейфа оригинала отвергается,
после -Actualize принимается снова.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Замена ExternalReport. -> Report. шла по всему тексту XML и попадала внутрь
имени объекта, если оно оканчивается так же (ПриёмкаExternalReport). Имя берётся
из <Name> до замены и остаётся авторским везде — в имени файла, GeneratedType и
составе конфигурации, — а ссылка в скопированном XML расходилась с ним, и
заглушка не грузилась: «Неизвестный объект метаданных - Report.ПриёмкаReport…».
Заменяется только префикс вида объекта в начале квалифицированного имени.
Регрессии строят фикстуру навыками (erf-init --WithSKD, epf-init, form-add) —
так в кейс попадает и настоящая ссылка вида cfg:ExternalReportObject.<Имя>.
Соседние кейсы каталога переведены на {fakePlatform} и прямые слэши.
Closes#90
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
В py-порте QUERY_BASE_DIR инициализировался None и заполнялся только в
ветке с -JsonPath: без него os.path.join(None, ...) упал бы. Путь
недостижим — запросы приходят только из JSON, — но PS-порт в этой ветке
берёт текущий каталог, и расхождение стоит закрыть до того, как оно
станет достижимым.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
1. Резолв uuid вложенного объекта переписан со сквозной регулярки на
спуск по дереву. Поиск по всему файлу брал первый узел с подходящим
именем, а реквизит шапки и реквизит табличной части сплошь и рядом
называются одинаково — ключ сортировки был чужим и вдобавок
дублировался, из-за чего порты могли разложить узлы по-разному.
Дочерние подсистемы лежат отдельными файлами и не резолвились вовсе:
431 узел в ролях ACC. Теперь на реальной роли резолвится 90% узлов,
остальное — стандартные реквизиты, у которых uuid в выгрузке нет.
Для них предупреждение больше не печатается: это норма, а не потеря.
2. Фильтр умолчаний уносил право вместе с его ограничением RLS: условие
пропадало молча. Право с ограничением отличается от умолчания самим
ограничением и остаётся.
3. modify-property не обновлял кэш умолчаний, и следующие операции того
же вызова фильтровали по старому флагу — запись попадала в файл ровно
вопреки тому, о чём навык сам предупреждает.
4. Edit-RoleMetadata перечитывал Roles/Имя.xml на каждой операции, и в
пакете первая правка молча терялась: set-synonym + set-comment
сохранял только комментарий. В py-порте такого не было — расхождение
портов закрыто.
5. Атрибуция сообщения в PS шла подстрокой по всему списку отброшенного,
из-за чего причина приписывалась чужому объекту. Теперь префиксное
сравнение, как в py.
Три новых кейса, семьи get_rights_object_uuid и is_standard_kind
заведены в check-inline-drift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Два дефекта, найденных вычиткой перед ревью.
deny-rights создавал узел объекта и, если фильтр умолчаний отбрасывал
все запреты, оставлял его пустым — в файл он попадал, когда сохранение
инициировала соседняя операция. Платформа пустых узлов не производит
(0 на 223k узлов корпуса). Теперь созданный впустую узел убирается.
Правило удаления узла было «не осталось разрешающих прав» — наследие
решения «false это шум». Замеры показали обратное: узел с одними
запретами осмыслен, так закрывают реквизит. Узел удаляется, только если
в нём не осталось прав вообще.
Там же закрыт разворот массива: `return @(...)` из функции отдаёт
единственный элемент скаляром, у которого .Count равен $null, поэтому
узел с ОДНИМ правом считался пустым и удалялся целиком. Поймал гард
минимального дифа: снятие одного права давало -11 строк вместо -4.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Таблица «что хранится при каких умолчаниях роли» ушла из инструкции:
модель попадает в этот случай ровно в момент, когда навык уже печатает
«запрет совпадает с умолчанием роли и платформой не хранится». Вместо
описания механики сообщение дополнено подсказкой, где запрет имеет
смысл, — теперь вывод самодостаточен, а инструкция короче.
Там же сжаты формулировки, которые дублировали текст ошибок: про отказ
до записи, про право сервиса на корне, про ограничение RLS без права.
Назначение deny-rights в таблице операций названо прямо: закрыть
реквизит или ТЧ, которые иначе наследуют права объекта.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Убран раздел про русские синонимы: прощающий ввод в инструкции даёт
модели развилку там, где есть одна каноничная форма — английская.
Убран раздел про замыкание набора при выдаче: навык перечисляет
дописанное в выводе, а в инструкции это лишняя механика. Оставлено
только то, что меняет решение ДО вызова: снятие и запрет уносят больше
перечисленного.
В примере объектной формы запрет переехал с объекта верхнего уровня на
реквизит: на верхнем уровне такая запись при умолчаниях роли не
хранится, и пример учил бесполезному.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Замер на платформе (debug/role-edit/FINDINGS.md): роль хранит только то,
что отличается от её умолчаний. При setForNewObjects=false на верхнем
уровне живут разрешения, а любой запрет выбрасывается (проверены Update,
Edit, Delete; узел из одних запретов удаляется целиком); при true —
наоборот. У реквизитных вложенных ту же роль играет
setForAttributesByDefault. Конфликт решается в пользу разрешения.
Отсюда три правки, общие для обоих навыков:
1. Прямое замыкание идёт только от РАЗРЕШЁННЫХ прав. Раньше запрет тянул
зависимости как разрешения: "Catalog.X: {Edit: false}" выдавал
Read, Update и View — навык раздавал права на основании запрета.
2. Появилось обратное замыкание: запрет уносит права, которым
запрещённое нужно. Сверено с платформой — при setForNewObjects=true
она к Update=false дописывает те же десять запретов.
3. Записи, совпавшие с умолчанием роли, не пишутся: платформа их всё
равно выбросит, а файл разошёлся бы с базой. Отброшенное
перечисляется в stderr, сообщение операции объясняет причину.
Правило применяется только там, где замерено: внешние источники данных
под него не попадают. Обе функции заведены семьями в check-inline-drift.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Внутри навыка они были сгруппированы по типам, поэтому список
[remove-rights, add-rights] для одного права выполнялся наоборот: право
сначала добавлялось, потом снималось. В инструкции об этом не было ни
слова, а порядок ввода — то, чего ожидает читающий.
Заодно: условие RLS со ссылкой на шаблон, которого в роли нет, больше не
проходит молча — предупреждение в stderr (отказывать нельзя, шаблон
могут добавить следующей операцией).
Вычитка инструкций обоих навыков: сказано, что -Operation это одна
операция, а несколько разных задают списком в файле (с примером);
перечислены все три глобальных флага; про значение из файла вынесено в
свой раздел; добавлено, что права реквизитам поштучно платформа не
хранит — ограничивают их запретом. Из role-compile убрано объяснение,
зачем навык замыкает набор: инструкция про применение.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Чтение текста из файла жило тремя копиями под именем Resolve-QueryValue
и вне реестра гарда, а role-* завели четвёртое правило — только от
рабочего каталога. Теперь функция одна на пять навыков:
Resolve-TextFromFile / resolve_text_from_file, заведена семья в
check-inline-drift, эталон — skd-edit.
Правило поиска общее: абсолютный путь как есть, относительный — рядом с
DSL (у edit-навыков — рядом с редактируемым объектом), затем в текущем
каталоге, не нашли — ошибка со списком проверенных мест. Имя без "query":
в ролях из файла приходит условие RLS, а не запрос. Текст ошибки
приведён к языку остальных сообщений.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Симметрично role-edit: в значении пишется "@путь", текст приходит из
файла. Условия типовых занимают десятки строк с кавычками внутри, и в
JSON-строке это источник ошибок экранирования — теперь условие живёт
отдельным файлом рядом с описанием роли.
Работает в rls и в templates[].condition. Отсутствие файла — ошибка до
записи, как и прочие ошибки описания прав.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Было неинтуитивно и вдобавок молча портило файл: `@условие.txt` целиком
заменял -Value, поэтому в файле должен был лежать ещё и адрес, а
естественная форма "Catalog.Товары.Read: @условие.txt" записывала в
условие литерал "@условие.txt" — без единого предупреждения.
Теперь файл читается там, где стоит текст: условие RLS и тело шаблона —
после двоеточия, синоним и комментарий — как всё значение. Адрес
остаётся в команде. Пакет делится по ;; ДО чтения файла, поэтому ;;
внутри условия больше не разделитель — прежний костыль с отключением
пакета убран. Отсутствие файла — ошибка до записи.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Снапшоты фиксируют итоговый файл целиком, поэтому лишняя перестановка
узлов или переписанный соседний блок уехали бы в эталон как норма.
Гард считает diff к исходному файлу: операция обязана дать ровно свои
строки и ни одной чужой.
Измерено заодно на живой роли типовой (БазовыеПраваБП, 4357 строк,
105 узлов): add-rights нового объекта — +11/-0, права в существующий
узел — +4/-0, set-rls — +3/-0, remove-rights — +0/-4, запрет на
реквизит — +11/-0. Удалённых строк нигде, кроме снятия.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Закрывает #43. Повторный role-compile перевыпускал UUID и переписывал
Rights.xml целиком, поэтому добавить права существующей роли было нечем —
оставалась ручная правка XML.
Операции: add-rights, set-rights, remove-rights, deny-rights, set-rls,
remove-rls, add/set/remove-template, modify-property, set-synonym,
set-comment. Пакет через ;;, значение из файла через @путь, отказ до
записи со всеми причинами разом, авто-вызов role-validate.
Грамматика имён и пресетов — та же, что у role-compile: копии таблиц и
валидаторов взяты побайтово, навык дописан в 16 семей реестра
check-inline-drift.
Правка держит инвариант «меняется только то, что просили»: узел встаёт на
своё место по uuid объекта, право — по канону типа, набор замыкается по
зависимостям, снятие и запрет идут каскадом в обратную сторону. Проверено
раундтрипом через платформу — выход обоих портов совпал с выгрузкой 1С
байт в байт, включая RLS с полями и двумя строками ограничений.
22 кейса на обоих портах, 17 снэпшотов приняты платформой.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Платформа при загрузке сама доводит набор до полного: выдал Edit —
получил ещё Read, Update и View, выдал View у обработки — получил Use.
Навык писал ровно заданное, поэтому файл роли и база расходились сразу
после первой загрузки.
Таблица снята с платформы: по одной роли на каждое право, 209 + 43
роли в двух прогонах, ни одного отвергнутого (debug/role-edit).
Зависимости оказались общими для типов, исключений четыре — обработка и
отчёт держатся на Use, план счетов не тянет Read под историю данных,
регистр сведений — короче на одно звено. Права, недопустимые для типа,
отсекаются, у вложенных объектов зависимостей нет.
Права конфигурации версионные: до формата 2.19 платформа взводила весь
блок режимов окна с любым правом, с 2.19 (8.3.26) перестала. Граница
измерена на шести платформах, 8.3.20 … 8.5.1.
Дописанное перечисляется в выводе — права выдаются не молча. Проверка:
выход обоих портов после загрузки и выгрузки совпал байт в байт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Платформа нормализует и то и другое: права внутри <object> идут в
фиксированном для типа порядке, сами <object> — по uuid объекта
метаданных. Навык писал в порядке ввода, поэтому первая же выгрузка из
Конфигуратора давала диф, которого никто не делал.
Замеры (debug/role-edit/FINDINGS.md): канон прав снят с платформы и
сошёлся с топологической сортировкой по корпусу (~290k узлов <right>);
порядок узлов по uuid подтверждён на 363 ролях ACC из 363 и отдельно на
44 ролях с вложенными объектами, где ключ — uuid самого реквизита.
Порядок дерева конфигурации тут ни при чём — прямое сравнение
с ChildObjects даёт скачущие позиции. Проверка: выход обоих портов
совпал с выгрузкой 1С байт в байт.
Сортировка узлов строго ordinal: Sort-Object сравнивает по культуре и
игнорирует дефис, из-за чего порядок разошёлся бы и с платформой, и с
py-портом.
Объект, которого нет в выгрузке (uuid неизвестен), уходит в конец с
предупреждением в stderr — платформа переставит его сама.
Кейсы с несколькими объектами переведены с preRun на фикстуры: uuid,
который meta-compile генерирует заново на каждом прогоне, сделал бы
порядок узлов плавающим. Фикстуры собраны теми же навыками. Двум
фикстурам добавлен документ-регистратор: регистр расчёта без него
платформа не принимает, и verify-snapshots это поймал.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Замер: 27 объектов x 68 имён прав = 1836 ролей по одному праву, одна
загрузка и одна выгрузка. Оракул точный — неприменимое право платформа
молча выбрасывает, роль остаётся пустой и в логе ни строчки.
Лишнего в таблице не было, не хватало:
BusinessProcess (14 -> 24), Task (14 -> 24),
ChartOfCalculationTypes (15 -> 25) — InteractiveDeleteMarked и весь
блок *DataHistory*;
ChartOfAccounts (21 -> 25) — InteractiveDeleteMarked, ViewDataHistory,
EditDataHistoryVersionComment, SwitchToDataHistoryVersion;
CalculationRegister (2 -> 4) — Update, Edit.
До этого навык отвергал корректные права, а dsl-reference утверждал,
что InteractiveDeleteMarked у плана счетов не бывает.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FGkXwoXTuafcu1SXMsauFq
Ревью собственной работы против плана нашло три упущения.
1. Синоним `decimal(p,s)` был в плане, но в код не попал — после включения отказа компилятора
стандартный SQL-тип стал отвергаться. Добавлен в оба навыка и покрыт кейсом.
2. Тип Null в таблице примитивных типов не описан. Голого синонима у него нет и не будет:
в DSL он задаётся как `v8:Null`. Заодно сказано прямым текстом, что имя С префиксом проходит
как есть — так задаются типы без синонима (`v8:ValueTable`, `ent:AccountType`, `v8ui:Color`).
3. Раздел 9.1 в 1c-form-spec помечен как общий справочник типов, а не «про формы»: там самые
полные перечни v8/v8ui/dcs/ent, и они относятся к любому объекту метаданных.
Проверено: meta-compile 94/94 и meta-edit 32/32 в обоих рантаймах, 11 гардов, снэпшот
sql-type-synonyms с decimal принят платформой.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Неизвестное имя типа проходило насквозь молча: meta-compile писал его в XML дословно
(<v8:Type>varchar(150)</v8:Type>), meta-validate не смотрел на скалярные типы вовсе — проверка 16
разбирает только ссылочные с известным префиксом. Отказ приходил лишь от платформы при загрузке
всей конфигурации, без указания объекта и реквизита. Так вело себя и имя типа СУБД, и опечатка.
meta-validate, проверка 22 — два уровня, потому что «невалидно» и «нам незнакомо» разные вещи:
Уровень 1, грамматика (ERROR). Содержимое <v8:Type> всегда несёт префикс пространства имён;
голое имя платформа не примет никогда, независимо от её версии и состава конфигурации.
Сюда же неверная форма ссылочного типа.
Уровень 2, словарь по контексту владельца (WARN). У хранимого объекта набор типов у́же, чем
у обработки или отчёта, где доступны ТаблицаЗначений, ОписаниеТипов, Картинка. Замер по корпусу
подтверждает разделение: v8:ValueTable/ValueTree/StandardPeriod в объектных файлах acc и erp
встречаются только у обработок и отчётов, у хранимых — ноль.
Оставлено предупреждением намеренно: словарь — та часть, которая расширяется с версиями платформы,
и цена ложной ошибки выше пользы. Жёстко только там, где решает грамматика.
meta-compile отвергает голое неизвестное имя с перечнем допустимых форм. Имя с готовым префиксом
(v8:ValueTable, ent:AccountType, v8ui:Color) по-прежнему проходит как есть — это законный ввод,
и правильность имени судит валидатор, которому виден весь файл.
check-type-synonyms.mjs — новый гард: по общему ключу meta-edit обязан понимать то же, что
meta-compile (авторитет). Отсутствие ключа допустимо, разное значение — нет.
Проверено:
- корпус, 23430 объектов четырёх выгрузок: ноль ошибок и ноль предупреждений проверки 22;
на реальном справочнике разбирается 88 имён типов, то есть проверка работает, а не молчит;
- раундтрип A, 13788 объектов: побайтово как эталон, compile-fail 0 — отказ компилятора
не задел ни одного законного типа;
- meta-compile 94/94 и meta-validate 48/48 в обоих рантаймах, 11 гардов;
- снэпшот type-with-prefix-passthrough принят платформой 8.3.24.1691.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Модель, проектирующая внешний источник по схеме БД, естественно пишет типы так, как они названы
в information_schema. До сих пор такое имя молча уходило в XML дословно (<v8:Type>integer</v8:Type>),
валидатор ничего не замечал, и падало это только на загрузке в базу.
Добавлены однозначные соответствия, замеренные на стенде PostgreSQL — то же самое даёт
Конфигуратор при импорте структуры таблицы:
integer/int/int4 → Number(10,0) varchar(n)/character varying(n) → String(n)
bigint/int8 → Number(19,0) numeric(p,s) → Number(p,s)
smallint/int2 → Number(5,0) timestamp → DateTime · bytea → BinaryData
boolean НЕ включён намеренно: в DSL это уже Булево, а psqlODBC при импорте отдаёт Строка(5) —
молча выбрать один из двух смыслов нельзя. text/real/money/json не включены: замера нет.
Словарь типов meta-edit был беднее meta-compile на 25 записей (не было Time, BinaryData, UUID,
коллекций, ссылки на таблицу внешнего источника) — дополнен до набора авторитета. Конфликтов
значений не было ни одного.
Проверено: наборы обоих навыков зелёные в двух рантаймах, снэпшот sql-type-synonyms принят
платформой 8.3.24.1691, PS и PY дают идентичный XML.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Раундтрип B на стенде вскрыл пробел: у таблицы внешнего источника декомпилятор не снимал
DefaultObjectForm/DefaultRecordForm/DefaultListForm/DefaultChoiceForm, хотя DSL их поддерживает,
компилятор эмитит, а у прочих объектов они снимаются. Пересборка стенда молча теряла назначенную
форму списка.
Сами формы вне скоупа раундтрипа (это отдельные файлы, их делает навык form-add), поэтому
собранная из такого DSL конфигурация не загрузится — ровно как и у справочника с формой.
Договорённость одна и та же, записана в docs/meta-dsl-spec.md.
Раундтрип B после правки: из выгрузки стенда → DSL → meta-compile → загрузка в базу →
выгрузка платформой = побайтово то же, что собрал компилятор. Против исходной выгрузки стенда
остаются два известных расхождения: UnfilledParentValue (загрузкой XML не задаётся, замерено
тремя опытами) и регистрация <Form> (вне скоупа).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Get-ChildIndent брал отступ из первого пробельного узла контейнера. В контейнере с детьми это
отступ ПЕРЕД первым ребёнком — верно; в пустом (только что раскрытом) единственный пробельный
узел — отступ ЗАКРЫВАЮЩЕГО тега, то есть уровень самого контейнера. Первый добавленный реквизит,
команда или таблица получали отступ <ChildObjects>, а не на табуляцию глубже. То же во вложенном
ChildObjects табличной части.
Платформа такой файл принимает и при выгрузке нормализует, поэтому дефект косметический —
но он задевал любой объект, а сравнивать наш вывод с выгрузкой становилось неудобно.
Эталоны четырёх кейсов пересняты: git diff -w пуст, меняются только отступы. Все 23 снэпшота
meta-edit, доезжающие до платформы, приняты 8.3.24.1691.
Кейс eds-add-table-twice объявил skipPlatformVerify: он нарочно удаляет файл таблицы, оставляя
висячую регистрацию, — платформа отказывает по условию кейса, а не из-за дефекта навыка.
Радиус проверен: та же эвристика есть в cf-edit, form-edit, interface-edit и cfe-borrow (семья
get_child_indent из списка долга check-inline-drift, не сведена). У form-edit пустой контейнер
обрабатывается верно — проверено добавлением элемента в форму с <ChildItems/>; у cf-edit и
cfe-borrow ветка недостижима: в ChildObjects конфигурации всегда есть <Language>.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Вчерашняя правка исходила из того, что xs:base64Binary без BinaryDataQualifiers — вторая
форма ХранилищаЗначения. Спросили платформу: конфигурация с таким узлом загружается и
выгружается обратно как xs:base64Binary с Length 0 / AllowedLength Variable, то есть как
БЕЗЛИМИТНЫЕ двоичные данные. ХранилищеЗначения — отдельный узел v8:ValueStorage.
- meta-info: xs:base64Binary снова всегда ДвоичныеДанные (правка отменена, замер записан
в комментарий).
- meta-decompile: узел без квалификаторов теперь возвращается как BinaryData(0), а не
ValueStorage — раньше раундтрип молча менял тип реквизита. Проверено: пересборка из
полученного DSL даёт байт в байт то же, что выгрузила платформа.
- Кейс и фикстура переименованы по факту и стали полной конфигурацией: теперь кейс доезжает
до платформы в verify-snapshots (раньше падал с «конфигурации для загрузки нет»).
check-uuid-invariant: добавлен сценарий внешнего источника — правки идут в два файла, и
пересборка файла источника дала бы ему новый uuid, осиротив существующие таблицы. Проверка
не холостая: намеренная порча uuid источника гард роняет.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
child-operations.md был на 191 строку и держал в одном файле реквизиты, поля внешнего
источника, таблицы, функции, ТЧ, предопределённые и значения перечисления: модель, добавляющая
реквизит, читала заодно про функции внешнего источника. Ось резки была механизмом (add/remove/
modify), а нужна сущность — как в meta-compile.
SKILL.md: частое (команда, сводная таблица операций, быстрые примеры) плюс индекс
«что правишь → файл». Остальное — reference/: attributes, tabular-sections, predefined,
external-data-source, other-children, properties (бывший properties-reference), json-dsl.
Попутно: везде «навык form-add», а не голое имя — иначе читается как команда оболочки или
значение -Operation. Тексты предупреждений в обоих портах тоже.
scripts/switch.py собирал .md только из корня навыка, подкаталоги не видел: команды запуска
в reference/*.md молча остались бы на старом рантайме. Обход стал рекурсивным.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
form-add отказывал видом объекта 'Table', хотя платформа такие формы делает, а в DSL
таблицы есть слоты defaultObjectForm/defaultRecordForm/defaultListForm/defaultChoiceForm.
Инструкция при этом обещала обратное — строка исправлена.
Таблица — единственный вид, чьи ссылки трёхчастные: слот
ExternalDataSource.<И>.Table.<Т>.Form.<Ф>, главный реквизит ExternalDataSourceTableObject.<И>.<Т>,
MainTable динамического списка ExternalDataSource.<И>.Table.<Т>. Имя источника в файле таблицы
не хранится — берётся из пути ExternalDataSources/<И>/Tables/<Т>.xml, единственное место,
где навык смотрит на путь.
Набор назначений зависит от вида данных таблицы — замерено загрузками на 8.3.24.1691:
ObjectData даёт Object/List/Choice, NonobjectData — Record/List/Choice. Неверная пара
схемой формы не отвергается: она валит загрузку ВСЕЙ конфигурации «Исключением XDTO при
чтении файла» без указания причины, поэтому form-add проверяет её сам и объясняет, а без
-Purpose у таблицы с составным ключом основной становится форма записи.
form-validate: типы ExternalDataSourceTable* добавлены в список известных cfg-префиксов —
иначе корректная форма получала предупреждение «unrecognized cfg prefix».
Проверено: form-add и form-validate зелёные в обоих рантаймах, гарды прошли (в том числе
check-form-purposes: спека и оба порта сходятся), снэпшот eds-table-forms принят платформой,
формы всех четырёх назначений загружены в базу и выгружены обратно со ссылками без потерь.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Мелкие находки ревью, по одному кейсу на каждую:
- meta-compile: BinaryData(N[,fixed|variable]) — фиксированная длина больше не теряется;
голая форма по-прежнему 4294967292/Fixed, как её пишет платформа при импорте из СУБД.
Посторонний текст в скобках (BinaryData(abc)) отвергается, а не даёт тихий безлимит —
PS принимал его и молча подставлял дефолт, py такой тип не понимал вовсе.
- meta-decompile: сворачивает в голый BinaryData только точное совпадение с этим дефолтом.
- meta-info: xs:base64Binary без квалификаторов — вторая форма ХранилищаЗначения, а не
двоичные данные; раньше два навыка читали один и тот же узел по-разному.
- meta-remove (py): в ветке «файлов нет» корень реестра был жёстко Configuration, поэтому
осиротевшая таблица внешнего источника не находилась и навык падал, тогда как PS её
разрегистрировал. Сообщение в обоих портах теперь называет реальный реестр.
Проверено: наборы meta-compile/decompile/info/remove/edit/validate зелёные в обоих
рантаймах, гарды прошли, снэпшот eds-binary-data принят платформой 8.3.24.1691.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Навык регистрировал форму, макет и команду одинаково — узлом с uuid и <Properties>.
Платформа так пишет только команду: форма и макет регистрируются голым текстом
(<Form>Имя</Form>) и требуют собственных файлов. В корпусе acc_8.3.24 ни одного
<Form uuid и <Template uuid, при 81 голом <Template> и 46 <Command uuid.
Подменённая конфигурация валила загрузку с уходом 1cv8 в бесконечное выделение памяти.
Форму и макет добавляет form-add / template-add (они делают и файл, и запись),
удаляет form-remove / template-remove — meta-edit теперь отсылает к ним вместо
тихой порчи. Команда осталась за meta-edit: дописаны CommandParameterType,
ParameterUseMode, ModifiesData и OnMainServerUnavalableBehavior, плюс заготовка
Commands/<Имя>/Ext/CommandModule.bsl (в корпусе модуль есть у всех 97 команд).
Заодно: Table в childOrder, и пустой ChildObjects в PS схлопывается в
самозакрывающийся, как его пишет платформа (722 из 722 в корпусе) и py-порт.
Проверено платформой 8.3.24.1691: загрузка и обновление успешны, обратная
выгрузка даёт узел команды и модуль байт в байт (отличие только в отступе).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Get-AllChildNames собирал имена только из Properties/Name и пропускал детей, которые
регистрируются голым текстом: <Table>Имя</Table>, <Form>Имя</Form>, <Template>Имя</Template>.
Из-за этого проверка на дубликат была мёртвой: после удаления файла таблицы повторное
добавление отвечало «Added: 1» и клало в ChildObjects второй такой же <Table>.
Теперь имя берётся из текста узла, если у ребёнка нет Properties. Кейс воспроизводит
исходный сценарий: добавить таблицу, удалить её файл, добавить снова — второй записи
быть не должно.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AtG4qGvZocJSWLAsbHpBCQ
Скопированные из meta-compile Emit-FormRef и Emit-Characteristics тянули за собой хвост
хелперов (Normalize-FormRef, Normalize-CharFrom, Expand-CharField, Get-CharIntField), которых
в meta-edit нет. Добавление таблицы с ключом defaultListForm или characteristics давало в PS
CommandNotFoundException при коде возврата 0: навык отчитывался успехом, а файл таблицы
не создавался и в ChildObjects ничего не появлялось. В python то же место падало трейсбеком —
порты расходились ещё и потоком ошибки.
Причина не в копировании как таковом: копия обязана быть не только идентичной, но и
самодостаточной. Форма функции для этого не годилась, поэтому изменена в эталоне и
перекопирована — тем же приёмом, что уже применён в этой семье дважды: Emit-EdsTableProperties
принимает готовые блоки <Characteristics> и четырёх слотов <Default*Form>, рендерит их
вызывающий навык своим эмиттером. Зависимостей у тела не осталось.
meta-edit передаёт пустые блоки и отвергает ключи characteristics и default*Form с объяснением,
куда идти: форму назначает form-add, характеристики — meta-compile.
Попутно исправлено то, что вскрылось при разборе: короткое имя формы в defaultListForm
эмитилось как есть, а платформа отвечает «Неизвестный объект метаданных». Теперь оно
разворачивается в полный путь ExternalDataSource.И.Table.Т.Form.Ф — как и ссылки на поля.
check-inline-drift получил проверку РАЗРЕШИМОСТИ: всё, что зовёт скопированное тело, обязано
быть определено в том же навыке. Критерий «своей» функции — имя, определённое в навыке-эталоне,
поэтому список командлетов-исключений не нужен. Проверено обратным экспериментом: гард ловит
исходный дефект с прямой формулировкой «копия неразрешима».
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Раздел 18 был указателем на reference навыка — это ломало принятое разделение: спецификация
в docs описывает DSL полно (для нас), инструкция навыка — только как применять (для модели).
Указатель экономил дублирование ценой того, что полного описания не оказалось нигде.
Теперь §18 описывает источник, таблицы, поля и функции целиком: ключи, XML-теги, умолчания,
конвенции ссылок на поля, presence-aware inputByString, различение BinaryData и ValueStorage,
запрет составного типа, и границы — почему в DSL нет значения незаполненного родителя (платформа
сбрасывает его при любой загрузке XML) и почему нет кубов OLAP.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Свойства таблицы ссылаются на её же поля шестичастным путём
(ExternalDataSource.И.Table.Т.Field.П). Опечатка в имени поля даёт «Неизвестный объект
метаданных» при загрузке, а глазами в таком пути её не видно. Проверка 21 разбирает форму
пути, требует, чтобы таблица в ссылке была той же самой, и чтобы поле существовало —
в сообщении перечисляются имеющиеся поля.
Отдельно: таблица без ключевых полей даёт предупреждение, а не ошибку. Загрузку XML такой
таблицы платформа принимает молча (измерено на 8.3.24.1691), Конфигуратор интерактивно
требует ключ, а рабочие конфигурации без ключей существуют — значит это повод предупредить,
а не отвергнуть.
Закрыты последние пункты плана: раздел про внешние источники в docs/meta-dsl-spec.md
(формой и связями с общими конвенциями, без дублирования таблицы свойств — она живёт
в reference навыка) и кейсы meta-validate, включая негативный.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Декомпилятор собирает DSL источника целиком: читает файл источника, подтягивает файлы таблиц
из <Источник>/Tables/ и складывает поля, ключи, ссылки и функции обратно в тот же синтаксис,
который принимает meta-compile. Ссылки на поля возвращаются короткими именами, таблица без
собственных свойств — коротким массивом полей, функция с типом по умолчанию — одной строкой.
Это замыкает дешёвый контур проверки: XML → декомпиляция → компиляция → сравнение с исходником,
без 1С и без Docker. На нём и проверено: наша выгрузка, выгрузка платформы и четыре таблицы
внешних источников из чужого рабочего проекта возвращаются байт в байт. У выгрузки платформы
остаются два известных расхождения: значение незаполненного родителя (платформа сама сбрасывает
его при любой загрузке) и формы (декомпилятор их не захватывает — так задумано).
Побочно закрыт дефект, к внешним источникам не относящийся: xs:base64Binary разбирался как
ХранилищеЗначения, хотя это ДвоичныеДанные. Различать их можно по квалификаторам —
у ХранилищеЗначения платформа пишет v8:ValueStorage, а у двоичных данных есть
BinaryDataQualifiers. Компилятор научен типу BinaryData (и BinaryData(N)) — до этого он
принимал такое имя, но эмитил его как есть, то есть невалидный XML.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
Дыра в сценарии: добавить таблицу или функцию к уже существующему источнику было нечем.
Совет «пересоберите источник целиком через meta-compile» оказался вредным — повторная
компиляция заменяет файл источника, выдаёт объекту НОВЫЙ uuid и оставляет файлы не
упомянутых таблиц сиротами: в ChildObjects их уже нет, а на диске они остались.
meta-edit на файле источника принимает add.tables и add.functions. Таблица — единственная
операция навыка, создающая файл: <Источник>/Tables/<Имя>.xml плюс имя в ChildObjects.
Синтаксис тот же, что у meta-compile.
Формат файла таблицы обязан быть один и тот же, кем бы файл ни был создан, поэтому эмиттеры
скопированы из meta-compile механически и зарегистрированы в check-inline-drift.mjs — гард
теперь сверяет семь функций между двумя навыками. Чтобы копии не тянули за собой пол-navыка,
две из них развязаны от эмиттеров-специфик: Build-EdsTableXml принимает готовый XML полей,
Emit-EdsFunction — готовый XML типа. Каждый навык рендерит их своим эмиттером, вывод не изменился.
meta-compile теперь предупреждает о перезаписи существующего объекта — для всех видов, не только
внешних источников: молчаливая замена uuid ломает ссылки, а узнать об этом было неоткуда.
Раундтрип на платформе 8.3.24.1691: таблица, добавленная через meta-edit, возвращается из
выгрузки байт в байт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
meta-edit добавляет поля в таблицу внешнего источника: тот же парсер реквизита, свой тег <Field>,
свой контекст (без индексов и полнотекстового поиска — чужой таблицей 1С не владеет) и три своих
свойства в хвосте. Сам источник точечно не правится: и таблица (отдельный файл), и функция (узел
с полным набором свойств) требуют эмиттера, который живёт в meta-compile, — дублировать его здесь
значило бы завести вторую реализацию одного и того же.
Заодно закрыт тихий отказ, существовавший независимо от внешних источников: проверка допустимых
детей смотрела на истинность списка, а не на наличие ключа, поэтому для вида с пустым списком
трактовалась как «ограничений нет» и чужой ребёнок молча записывался в объект. Теперь add-attribute
на таблице внешнего источника отвергается с предупреждением, а не пишет <Attribute> вместо <Field>.
meta-remove понимает две формы: ExternalDataSource.PG — источник целиком, и четырёхчастную
ExternalDataSource.PG.Table.products — одну таблицу. Таблица числится в ChildObjects файла
источника, а не конфигурации, поэтому дерегистрация разведена переменной реестра; поиск ссылок
дополнен путями вида ExternalDataSource.И.Table.Т и ExternalDataSourceTableRef.И.Т.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01NBsZA5cr2WFThtgp7i5WVi
