Живой прогон на darwin показал: многословный -comment теряется целиком, а
однословный доходит. На POSIX аргументы уходят списком, и наши кавычки
становятся частью значения; склейка в одну строку нужна только на Windows,
там же нужны и кавычки.
Ключи вида /F"путь" и /N"имя" не трогаем: там кавычки внутри токена требует
сам разборщик 1С, и они нужны на обеих ОС.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Кейсы используют фейковую платформу в виде .cmd и потому помечены osOnly win32.
На Mac mini из двенадцати выполнялся один, то есть py-порт там почти не
проверялся — ровно та ловушка, о которой предупреждает памятка по стенду.
Добавлены двойники на fake.sh для всех кейсов, кроме уже имевшегося.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
В history.md лежала цепочка «выгрузить CF версии → создать временную базу →
загрузить → выгрузить XML → сравнить». Это один из способов, поданный как
единственный: сравнить можно и средствами конфигуратора, а по задаче #76
источником сравнения может быть прямо версия хранилища, без временной базы —
тогда рецепт станет ещё и неверным.
Работа навыка заканчивается на dump-cfg; что делать с полученным CF, решает
пользователь.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Перечитал изменённые инструкции свежим взглядом и убрал всё, что описывает
поведение навыка вместо способа им пользоваться: образец вывода отчёта (модель
увидит настоящий), фразу «навык подсказывает оба флага», объяснение, почему
длинный отчёт не печатается, и заверение, что неверная пара путь+расширение
ничего не ломает. Осталось действие: как назвать, что указать, чего ждать от
кода возврата.
Столбец «Что теряется» переименован в «Почему»: у lock -All не теряется ничего,
и строка «Ничего, но…» в таком столбце читалась криво.
Подсказка о недоступном хранилище разделена по схеме адреса: tcp ведёт к
серверу хранилища и порту, http — к веб-серверу и публикации. Прежний общий
текст советовал бы проверять сервер хранилища и порт 1542 для http-адреса, где
это неверно.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
В SKILL.md место только тому, как навык применять. Оговорка о том, что форма
адреса не описана в известной документации и проверена на стенде, — это история
работы, модели она ничего не даёт. Осталось применимое: вид адреса, порт по
умолчанию и то, что недоступный сервер отвечает тем же сообщением, что и
отсутствие реквизитов.
В справочнике проекта оговорка тоже переписана на факты: требование совпадения
версий сервера и платформы вместо рассказа о том, где мы это выясняли.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Установлен crserver 8.3.23, поднят на порту 1542 — сетевое хранилище перестало
быть непроверенным местом. Адрес tcp://<хост>[:<порт>]/<имя>, порт по умолчанию
1542; хранилище создаётся сервером по требованию. Весь цикл, файл списка
объектов и администрирование работают так же, как на файловом, и одинаково в
обоих портах. Отдельного поведения у сетевого хранилища не обнаружено.
Нашлась двусмысленность: недоступный сервер даёт «Соединение с хранилищем
конфигурации не установлено» — ровно то же сообщение, что и отсутствие
реквизитов. Прежняя подсказка «добавьте repository в реестр» в сетевом случае
уводила не туда. Теперь db-repo различает по схеме адреса и советует проверить
сервер и порт, а подсказка db-load-xml и db-load-git называет обе причины.
Документация больше не оговаривается «не проверено»: форма адреса подтверждена
на стенде.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Форма tcp://srv01/MyApp пришла из примера в ишью #77, а мы повторили её в
справочнике реестра и в db-list как факт. Прицельный поиск показал, что в
доступной документации её нет: глава 7.4.15 описывает только каталог хранилища,
а в обоих «Приложение 4» (8.3.24 и 8.3.27) не встречаются ни crserver, ни
tcp:// — совпадения по слову «хранилище» относятся к лицензированию.
Теперь сказано «каталог хранилища или адрес сервера хранилища» и добавлена
оговорка: путь передаётся платформе как есть, конкретный синтаксис в известной
нам документации не описан, на серверном хранилище навык не проверялся.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Пункт плана, остававшийся открытым: каталог исходников расширения модель
указывала руками, хотя он объявлен в записи базы. Каталог выбирает модель, а не
скрипт, поэтому это строка в инструкции — рядом с такой же про configSrc.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Печать отчёта целиком стоит модели контекста, но опаснее другое: обрезанный
отчёт по версиям читается как полный ответ. По куску легко заключить, что
объект не менялся, — в отличие от списка объектов, где неполнота очевидна.
Короткий отчёт (до ста строк) печатается целиком, длинный не печатается
совсем: называется путь к файлу и способы сузить выборку. Порог не
теоретический — даже стенд из девяти версий даёт 124 строки.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Три места, где модель делала работу за навык.
report требовал -OutputFile, хотя отчёт всё равно печатается в вывод: путь
приходилось придумывать ради файла, который никто не читает. Теперь без
параметра отчёт уходит во временный файл, а путь называется — сохранить
осознанно по-прежнему можно.
create и connect с явным путём хранилища теперь печатают готовый блок
repository для .v8-project.json. Без записи в реестре реквизиты придётся
передавать в каждом вызове, а update откажется работать вовсе — вспомнить
об этом модель не может, а подставить готовое мы можем.
Подсказка про -ForceReplaceCfg сразу называет и второй флаг: при
переподключении платформа отвергает дважды подряд, сообщая о причинах по
одной, и модель упиралась бы два раза.
Проверено, что печатаемый блок — валидный JSON: строка из вывода разбирается
парсером, путь читается обратно. В PS обратный слэш в строке замены -replace
не спецсимвол, из-за чего слэши сперва удвоились дважды.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Административные и сервисные команды собирались по документации, а вживую
гонялись сырыми вызовами платформы — сборка аргументов навыком не проверялась.
Прогон через навык показал, что работают dump-cfg (включая -Version), set-label,
add-user, clear-cache во всех областях, optimize, copy-users, create -NoBind.
Нашлись два тупика подряд при переподключении базы: платформа сначала отвергает
непустую конфигурацию, а после -ForceReplaceCfg — то, что за пользователем
хранилища уже числится эта база. Оба раза действие не называется. Добавлены
подсказки на оба сообщения, сценарий описан в references/connect.md.
Заодно постусловие update сработало на настоящей аварии: после неудачного
переподключения база осталась отключённой, и команда отказалась вместо тихой
замены конфигурации.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Файлы references/ несли сокращённую запись «... db-repo.ps1 -Command …», и
scripts/switch.py её не видел: его регулярное выражение требует полной формы
powershell.exe -NoProfile -File <path>.ps1. В python-дистрибуции каскад остался
бы с .ps1, то есть на macOS указывал бы на неисполнимый файл, а гард
переносимости этого не ловит — он следит за плейсхолдером ${CLAUDE_SKILL_DIR},
которого в сокращённой записи тоже не было.
Проверено прогоном switch_runtime_content по всем четырём файлам: до правки
переключатель находил 0 вызовов при трёх упоминаниях .ps1, после — все
конвертируются, .ps1 не остаётся.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
db-list/SKILL.md — фактическая спека .v8-project.json, которую читает модель,
и без repository она давала неполную картину: база под хранилищем не принимает
ни одной операции конфигуратора без реквизитов доступа, причём это касается не
только db-repo, но и всей группы загрузки-выгрузки.
Добавлены repository и extensions[] в пример и таблицу полей, раздел с
описанием обоих (включая то, что у расширения своё хранилище со своим путём,
а пользователь хранилища не наследуется от пользователя базы), пункт в
интерактивный сценарий добавления базы и форма ключей доступа в разделе про
строку подключения.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Операция над всей конфигурацией перечисляет тысячи объектов, и весь список
уезжал в вывод модели. Списки обрезаются на двадцати позициях, полный уходит
в файл, путь к которому назван. Сырой лог платформы при отказе показывается
хвостом в 200 строк: итог и причину платформа пишет в конце.
Тесты на фейковой платформе — 12 кейсов, разбор лога проверяется без 1С на
логах, снятых со стенда. Ключевой кейс закрывает главное правило навыка:
платформа вернула 1, часть объектов захвачена, навык возвращает 0 с поимённым
предупреждением. Обрезка списка проверена на логе из тридцати объектов —
кейс требует и строку «и ещё 10», и отсутствие двадцать первого объекта
в выводе.
Проверено негативным контролем: намеренно сломанное ожидание роняет кейс,
то есть тесты действительно сверяют вывод, а не проходят вхолостую.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Прогон всех веток вывода подряд показал, что длинный совет про перевыгрузку
вставал МЕЖДУ фактами и вердиктом: строка «захват не выполнен» терялась в
середине. Совет теперь печатается последним во всех ветках — сначала факты,
затем вердикт.
Убрана мёртвая подсказка про -Yes: флага больше нет. Снято утверждение «по
убыванию частоты» у причин отказа commit — проверить его нечем. Сняты повтор
слова «проверьте» и склонение «объект(ов)». Заголовок «Не были захвачены»
дополнен пояснением, что снимать нечего.
Примеры в шапке скрипта приведены к именованной подкоманде.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Порт .py зеркалит .ps1 по порядку функций, именам и комментариям — расхождения
только там, где их диктует рантайм. Общие функции взяты из соседних портов
дословно.
Копии зарегистрированы в check-inline-drift.mjs: db-repo присоединён к шести
платформенным семьям, четыре функции блока реквизитов хранилища заведены новыми
семьями, разбор сообщений хранилища — семьёй с эталоном db-load-xml. Гард сразу
нашёл настоящее расхождение: копии Get-RepositoryArgs в четырёх соседях остались
со старым comma-return, эталон правился позже. Ресинхронизировано.
Разбор сообщений хранилища добавлен и в db-load-git: он тоже грузит в базу
частично и получает те же три отказа платформы.
Подкоманда стала именованной (-Command): в группе скрипты принимают только
именованные параметры, слэш-форму в них переводит модель. Позиционный параметр
у пишущего навыка запрещён гардом check-positional-binding. Mandatory при этом
не ставим — обязательный параметр PowerShell запрашивает интерактивно, а в
пакетном запуске это зависание.
Все девять гардов и функциональные тесты db-* зелёные в обоих рантаймах.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Захват всей конфигурации на большой базе идёт долго и блокирует работу всей
команде, а получался он от одного забытого -Objects: «вся конфигурация» была
умолчанием. Теперь для lock, unlock и commit это отдельный флаг -All, который
нельзя совместить с -Objects. Захват корня с -WithChildren, означающий то же
самое, отсылает к нему же.
update без -Objects остаётся обычным вызовом: получение всех изменений — это
нормальный ежедневный сценарий, а не тяжёлая операция.
Флаг отдельный, а не -Force: у -Force уже есть платформенное значение, разное
по подкомандам, и третье значение сделало бы его нечитаемым.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Модель может попросить захватить реквизит, табличную часть, измерение или
ресурс. Платформа на это отвечает «Загруженный список объектов пуст» — без
имени объекта и без причины, отладить такой ответ нечем.
Навык распознаёт вложенные виды подчинённых и подменяет их объектом-владельцем,
сообщая о подмене. Это не меняет смысл запроса: владелец — минимально возможная
единица захвата для того, что просили, потому что своей сущности у части объекта
нет. Отказ стоил бы лишнего круга без пользы.
Заодно убран comma-return у двух функций: в связке с @() у вызывающего он даёт
вложенный массив, из-за чего список объектов склеивался в один fullName.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Проверка навыка субагентом на сквозном сценарии вскрыла фактическую ошибку
в инструкции: реквизиты и табличные части перечислялись наравне с формами как
захватываемые объекты. Платформа их объектами не считает — список объектов
получается пустым, причём без секции «отсутствующие в конфигурации». Правишь
реквизит, табличную часть, измерение, ресурс или модуль — захватывай владельца;
формы, макеты и команды захватываются отдельно.
Сообщение «объект не найден» имеет три разные причины: опечатка, отставание
базы от хранилища и попытка захватить то, что объектом не является. Теперь
перечислены все три.
В цикл добавлен нулевой шаг — получение актуального состояния перед началом
работы: правки должны опираться на актуальные версии в том числе тех объектов,
которые не меняются, но используются. Загрузка и обновление БД слиты в один
шаг через -UpdateDB, поэтому цикл не удлинился.
Захват корня конфигурации с -WithChildren отклоняется: это захват всей
конфигурации, а выглядит как захват корня. Для всей конфигурации есть
однозначная форма — вызов без -Objects.
Текстовый отчёт печатается, а не только сохраняется в файл.
Схема repository и extensions[] описана в docs/v8-project-guide.md,
цикл под хранилищем — в docs/db-guide.md.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Новый навык /db-repo с подкомандами: рабочий цикл (lock, unlock, commit,
update), подключение базы (connect, disconnect), история (report, dump-cfg),
администрирование (create, add-user, copy-users) и сервис (set-label,
optimize, clear-cache). Каскад инструкций в references/.
Ядро навыка — разбор вывода платформы: код возврата о фактическом результате
не говорит. Захват и помещение не атомарны (код 1 при реально захваченном
объекте), а все no-op'ы дают код 0. Вердикт строится по строкам лога и
отражает достижение запрошенного состояния, а не факт изменения.
Захват, обновление и unlock -Force молча подтягивают свежие версии в локальную
конфигурацию. Навык называет полученные объекты и печатает готовую команду
перевыгрузки: без неё частичная загрузка старых исходников молча откатывает
чужие изменения.
Соседние навыки группы получили общий блок разрешения реквизитов хранилища из
.v8-project.json — база под хранилищем не принимает без них ни одной операции
конфигуратора. db-load-xml дополнительно подсказывает действие по трём
сообщениям платформы, db-dump-xml получил -ObjectsFile для передачи списка
объектов между навыками без перепечатывания.
Порты .py следуют отдельно.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
На Windows fs.rmSync и fs.cpSync молча не делают ничего, когда не-ASCII символы
есть в самом аргументе пути (nodejs/node#61067). Для аудитории проекта это боевой
сценарий: кириллическое имя пользователя даёт кириллический %TEMP%, где раннер
создаёт воркспейсы, плюс кириллические имена объектов 1С в путях внутри кейсов.
Замерено на восьми сборках. Затронуты 22.18.0–22.23.2 (последняя LTS Jod) и
24.12.0–24.14.0; исправны 22.15.1, 24.15.0+, 25.x, 26.x. Фикс приехал в fs-слой
Node 24.15 и в ветку 22.x не бэкпортирован, поэтому «обновить Node» вопрос не
закрывает. Зависимость не монотонна по версиям (24.14 чинит rmSync, но не
cpSync) — гард по номеру версии невозможен, решает только сам путь.
Симптомы: rmSync молча ничего не удаляет; cpSync с не-ASCII приёмником молча
ничего не копирует; cpSync с не-ASCII источником валит процесс нативно
(0xC0000409) мимо try/catch. Не затронуты mkdirSync, readdirSync, lstatSync,
copyFileSync (включая перезапись), unlinkSync, rmdirSync — на них стоит обход.
Что ломалось: под кириллическим %TEMP% фикстуры не доезжали до воркспейсов
(meta-info — 15 ложных падений из 26, один кейс ложно-зелёный на пустом
воркспейсе); cfe-validate/module-state-flag-without-file был красным даже при
ASCII %TEMP% (кириллица в самом deletePath); --update-snapshots молча не сносил
старый эталон, то есть портил коммитимые артефакты.
Реализация — единый fsutil в двух побайтно одинаковых копиях (tests/common/ и
внутри автономного навыка web-test), раскатанный на все 42 точки вызова в 11
файлах: tests/skills/*, tests/web-test/*, hooks/test/run.mjs, движок web-test.
Предикат судит по resolve(p), а не по строке аргумента: относительный
ASCII-аргумент при не-ASCII cwd платформа роняет так же молча. Ретраи доживают
до ручного обхода, перезапись как у cpSync с force: true, настоящие ошибки не
глотаются, выживший после удаления путь — громкая ошибка.
Гард tests/skills/check-nonascii-fs.mjs в check-all.mjs проверяет хелпер, а не
платформу (поэтому зелёный и на исправной Node), сверяет хеши обеих копий и
печатает справкой состояние текущей сборки.
Co-Authored-By: androman.pro <5669019+andromanpro@users.noreply.github.com>
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Фикстуры childobjects-missing и childobjects-selfclosed невалидны by design: первая вовсе без
<ChildObjects>, вторая с пустым. Кейсы проверяют реакцию навыка на такую конфигурацию, а платформа
её не принимает — «читаемое свойство не соответствует ожидаемому. Текущее Configuration, ожидаемое
ChildObjects» и «Неизвестный объект метаданных - Language.Русский» соответственно.
Причина пропуска записана по факту отказа платформы, а не по предположению.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Полный прогон верификации давал шесть падений; четыре из них — дефекты самого инструмента.
Вход кейса. Файл писался только из caseData.input и только UTF-8, поэтому кейсы, задающие вход
через inputRaw (сырая строка) и inputEncoding (UTF-16, cp1251), оставляли навык без входного
файла: meta-compile/encoding-utf16-bom и interface-edit/bad-definition-file падали на «Cannot bind
argument to parameter». Хуже того, кейс, у которого нет ни input, ни preRun, ни params, отбрасывался
в discoverCases как «ничего не подающий навыку» — inputRaw там тоже не учитывался, и такие кейсы
в верификацию не попадали вовсе (meta-compile/bad-encoding-cp1251,
subsystem-compile/bad-definition-file). Теперь оба ключа поддержаны, encodeInput перенесён копией
из runner.mjs — общего модуля у раннеров нет, и README предписывает добавлять ключ в оба.
Это ровно та «тихая дыра», о которой README предупреждает: ключ, известный лишь одному раннеру,
даёт кейс, зелёный в функциональном прогоне и не доезжающий до платформы в верификации.
Версия формата. Гейт вызывался только при наличии каталога конфигурации, поэтому кейсы
epf-init/format-221 и erf-init/format-221 доходили до сборки и падали на стенде без 8.5 — красным,
хотя это свойство стенда. Ядро гейта выделено и читает версию из шапки любого MetaDataObject,
включая исходник обработки и отчёта; в EPF-ветке проверка выполняется до epf-build.
Проверено точечно: два кейса с inputRaw проходят, два format-221 честно пропускаются по версии
платформы, два ранее невидимых кейса берутся в прогон и проходят. Функциональный раннер не задет:
role-compile 26/26, meta-compile 85/85.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
configDir приходил только из скилл-уровневого setup (empty-config) и из ветки external, поэтому
у навыков с setup: none кейс на фикстуре до платформы не доезжал — и всё равно получал PASS.
Таких кейсов девять: пять support-edit, три meta-validate и один skd-decompile. В наборе по
умолчанию дефект не проявлялся: там у всех навыков setup: empty-config, и загрузка шла.
Теперь фикстура-конфигурация грузится как external-выгрузка, а путь «грузить нечего и спец-маршрут
не подошёл» вместо молчаливого PASS требует объявить skipPlatformVerify с причиной. skd-decompile
отнесён к standalone-навыкам: его выход — JSON-описание, грузить нечего.
Отдельно — видимость: «прошло» и «проверено платформой» больше не одно и то же число. В консоли и
в отчёте печатается, сколько кейсов реально обратилось к платформе, а сколько прошло мимо и почему
(external, standalone, ожидаемый отказ навыка, недоступная платформа); в таблице отчёта появилась
колонка «Платформа». Падения в эту долю не попадают: у них обращение было и не удалось.
Девяти кейсам проставлен пропуск с проверенной причиной. Для support-edit причина выяснялась
опытом: фикстуры содержат рукотворный Ext/ParentConfigurations.bin, и платформа отвечает «Ошибка
формата потока», тогда как настоящий bin из типовой грузится, а выгрузка без bin — тоже. Попытка
пересобрать фикстуры полноценными объектами вылечила XML, но не bin, и была откачена.
Документация: в README добавлена таблица маршрутов платформенной проверки и правила появления
configDir — раньше это знание жило только в коде, и «зелёный» отчёт не отличался от «проверенного».
В docs/1c-support-state-spec.md записано, что по описанной грамматике bin можно читать, но нельзя
собрать файл, который примет платформа.
Полный прогон verify-snapshots до и после правки даёт одинаковый состав: 461 passed, 6 failed,
30 skipped из 497 — новых падений нет. Тесты: 871/879, интеграционные 13/13.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
py-порт в batch-режиме запускал сам себя через subprocess на каждый объект, и на разбор в единицы
миллисекунд приходилось ~146 мс старта интерпретатора с импортом lxml. На корпусном прогоне это
давало 92 мс на объект против 40 мс у PS — при том, что обычно py быстрее в разы. Причина
асимметрии: PS вызывает себя через & в том же процессе, платя свой дорогой старт один раз на батч.
Теперь py делает то же самое: файл компилируется один раз и выполняется в свежем globals() на
каждый объект. Изоляция состояния получается той же, что у & в PowerShell (script-переменные не
переживают вызов), а старт и компиляция платятся однократно.
Прогон по acc_8.3.24 и erp_8.3.24 (33 895 объектов): 274 c против ~2900 c, вывод побайтово тот же
и совпадает с PS-портом строка в строку. Батч с битым объектом в середине по-прежнему доходит до
конца и возвращает ненулевой код, -OutFile пишет те же файлы на объект.
Заодно уточнён комментарий про кэш состава конфигурации: «порождает процесс на объект» было верно
только для py, тогда как в PS кэш не переживает объект из-за новой области видимости.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Оба исключения по IntegrationService стояли с пустой причиной, а такое гард лишь помечает как долг
и продолжает. Именно так вид метаданных и выпал незамеченным: meta-validate не знал его вовсе и
отвергал штатный объект типовой конфигурации.
Причины проставлены по смыслу своих записей: meta-compile такие объекты не создаёт, meta-validate
проверяет их структурно. Долг исключений без причины закрыт.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Прогон по acc_8.3.24 и erp_8.3.24 (33 895 объектов) давал 246 ERROR и 1662 WARN на выгрузках,
которые платформа принимает без единой ошибки, — то есть ложным был весь вывод валидатора.
Две группы при этом роняли exit=1 на типовой конфигурации: то же, из-за чего заводились #79 и #84,
только зеркально.
Разобрано платформой на стенде 8.3.24.1691, каждый случай — копия эталона с одной мутацией:
- пустой <Type/> у реквизита — это тип «Произвольный»; загрузка проходит, round-trip сохраняет
конструкцию без изменений. Было ERROR (245 раз), стало молчание;
- блока Type нет вовсе — загрузка тоже проходит, но платформа молча подставляет тип нового
реквизита, Строка(10). Замысел теряется, загрузка нет: ERROR заменён на WARN;
- IntegrationService и Bot отсутствовали в списках видов метаданных (в спеке 45 типов, навык знал
43) — штатный объект типовой давал «Unrecognized metadata type» и exit=1;
- HierarchyType платформа пишет всегда и при выключенной иерархии игнорирует: из 1254 срабатываний
1253 приходились на её собственный дефолт. Предупреждаем только о явно заданном другом типе;
- источник подписки задают и наборами типов (<v8:TypeSet>), а состав журнала — элементами
<xr:Item>; проверки искали только <v8:Type> и потому не видели ни одной такой подписки и ни
одного журнала. Зато реально пустой источник и пустой состав платформа отвергает
(«Источник событий должен быть задан», «Для журнала не заданы регистрируемые документы») —
там уровень поднят с WARN до ERROR;
- сигнатура процедуры переносится на несколько строк, и Экспорт оказывается не на строке с именем;
регулярка требовала одну строку. Модуль поставщика в двоичном виде (Module.bin) больше не даёт
предупреждения «файл не найден» — текста там нет by design;
- ExchangeDate — легаси-реквизит планов обмена, поддержан в meta-compile и meta-decompile:
добавлен как допустимый, но не обязательный.
После правки корпус даёт 0 ERROR и 1 WARN — тот самый единственный недефолтный тип иерархии.
Объём проверки не потерян: объектов провалидировано 33 895 против 33 894.
Восемь новых кейсов держат обе стороны каждой правки: валидная конструкция молчит, настоящая
ошибка по-прежнему ловится.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Таблица параметров и примеры в SKILL.md описывали слэш-нотацию (--set-default, --purpose),
а скрипт принимает -SetDefault и -Purpose. Модель, читающая таблицу, получала отказ биндинга
на первом же вызове. Документация приведена к исполняемой форме — она теперь одна.
Заодно навык принимает обиходные написания молча: назначение формы русским названием вида
формы или английским с суффиксом Form (регистр, пробелы и разделители не значимы) и флаг
основной формы с дефисом внутри имени. Допустимость назначения для вида объекта по-прежнему
проверяется — неизвестное значение отвергается со списком доступных.
Порты выровнены: PS принимает это через алиас параметра, py — через перечисление опций;
проверено девятью написаниями на обоих, результат совпадает.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Оба назывались «корректными», но объект создавался со ссылкой на CatalogRef.Валюты, которого
в конфигурации нет — платформа такую выгрузку не принимает. Пока уровень был WARN, кейсы
проходили и закрепляли неверное: «валидный» объект с висячей ссылкой.
Справочник добавлен в preRun, эталоны пересняты и проверены платформой.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Проверки 16 и 20 выбирали уровень по наличию файла, тогда как платформа судит по составу
конфигурации. Из-за этого валидатор ошибался в обе стороны: пропускал ссылку на форму
объекта, которого в конфигурации нет (WARN, exit=0 — платформа такую выгрузку не грузит),
и ложно отказывал на фрагменте частичной выгрузки, где файла формы нет намеренно.
Единое правило: ChildObjects отвечает за существование объекта, наличие файла — только за
полноту выгрузки. Нет в составе -> ERROR, в составе есть, а файла нет -> WARN. Уровень для
фрагмента остаётся мягким сознательно: один и тот же фрагмент грузится или нет в зависимости
от состояния конфигурации БД, которого валидатору не видно.
Матрица снята на платформе 8.3.24.1691 (полная и частичная загрузка, семь ситуаций).
Прогноз про загрузку убран из текста WARN — там он не гарантирован.
Состав читается поиском подстроки в границах секции ChildObjects, без разбора XML:
batch-режим порождает процесс на объект, и полная карта оплачивалась бы каждым объектом.
Корпусный прогон по acc_8.3.24 и erp_8.3.24 (33 895 объектов): расхождений до/после нет.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Значение с пробелом без кавычек разрывалось на токены, и лишние молча растекались по свободным
позиционным параметрам. На документированной форме вызова (powershell -NoProfile -File):
form-compile.ps1 -JsonPath a.json -OutputPath b.xml -Purpose Форма списка
→ Purpose=[Форма] ObjectPath=[списка], ошибки НЕТ
Навык отрабатывал успешно с усечённым значением; реальный триггер — путь с пробелом в -EmitDsl
или -ObjectPath, результат уезжал не туда молча. У навыков с парой -DefinitionFile/-Operation
осколок уезжал в -DefinitionFile, и навык жаловался на параметр, которого в команде не было.
Расхождение портов: py на том же вызове отвечает «unrecognized arguments: списка» — там все
аргументы объявлены опциями. Правка выравнивает PS по py, python не менялся.
41 навык получает [CmdletBinding(PositionalBinding=$false)] и ни одного позиционного параметра.
Без Position=0 (в отличие от read-only навыков): «главный» параметр механически не выводится —
у meta-edit первым объявлен -DefinitionFile, а путь к объекту вторым, — а ошибка выбора тестами
не ловится, раннер передаёт только именованные флаги. Позиционной формы вызова нет ни в одной из
140 строк SKILL.md, внутренние вызовы навыков друг из друга тоже именованные.
check-positional-binding.mjs расширен на пишущие навыки статической проверкой. Поведенческая
(канареечный файл) остаётся только у read-only: у web-stop и db-run все параметры
Mandatory=$false, связывание прошло бы и тело выполнилось — гард остановил бы Apache и запустил 1С.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Часть навыков проверяла путь ко входному JSON сама и отвечала внятной строкой, часть — нет и
роняла дамп: FileNotFoundError с traceback в py, MethodInvocationException с CategoryInfo в PS1.
Один и тот же промах давал разный ответ в зависимости от навыка, а у form-edit — ещё и от порта.
Проверка перенесена в тело семьи read_json_file / Read-JsonInputFile: пол одинаков везде по
построению, и новые навыки получают его вместе с функцией. Навыки со своей проверкой срабатывают
раньше и сохраняют прежний текст, поэтому существующие кейсы не двигаются.
Заодно каталог вместо файла: раньше IsADirectoryError / отказ доступа, теперь
«Expected a JSON file, got a directory».
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Этажом ниже разбора, на чтении файла, жил тот же класс дефектов в худшей форме. Файл в cp1251
с кириллицей: PS1 `Get-Content -Encoding UTF8` менял имя на 12 символов U+FFFD, JSON после этого
разбирался УСПЕШНО, и навык создавал объект с именем из «замен» — молча. Py-порт на том же файле
падал traceback-ом. Файл в UTF-16 давал ту же пару: traceback против ложного «JSON must have
'type' field».
Новая семья read_json_file / Read-JsonInputFile: кодировка берётся из BOM (UTF-8, UTF-16 LE/BE),
без BOM — строгий UTF-8, при провале сообщение называет файл и байт. Кодовую страницу не
подбираем: угаданное имя уехало бы в метаданные так же молча.
Эхо полученного значения печатается теперь только для inline-входа. Для файла оно показывало
первые 60 символов первой строки независимо от того, что ошибка на 120-й, и спорило с позицией
от парсера.
Заодно уравнен пустой вход: PS 5.1 на пустой строке отдаёт $null, а не ошибку, и навык уходил
дальше с $null, тогда как py-порт падал.
Раннеру добавлен ключ inputEncoding (utf-16le / utf-16be / cp1251) — иначе кейс про кодировку
не выразить, writeFileSync пишет только UTF-8.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Эхо полученного значения обрезалось многоточием, и обрыв читался как обрыв самих данных:
агент шёл дописывать «неполный» файл, хотя ошибка была на 57-й строке. Плюс усечение спорило
с позицией от парсера — два сигнала об одном месте, которые не сходятся.
Теперь усечение называет себя: got (first 60 chars, whitespace collapsed). Число символов
не печатаем — после схлопывания пробелов оно не сходилось со смещением из сообщения парсера.
На коротком входе, ради которого эхо и заводилось (съеденные оболочкой кавычки дают
{group:X,commands:[Y]} — 22 символа), усечения нет вовсе.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Неверный входной JSON ронял скрипты необработанным исключением: PS1 отдавал дамп
ConvertFrom-Json с CategoryInfo, py-порт — traceback с внутренностями json/decoder.py.
Имя файла в сообщении не фигурировало, а для полиморфного -Value не было видно, какую
форму ждёт операция.
Общий хелпер ConvertFrom-JsonInput / parse_json_input в 12 навыках × 2 порта (24 места),
зарегистрирован семьёй в check-inline-drift.mjs — копии держит гард. Сообщение в одну
строку: ожидаемая форма, полученное значение, текст парсера в скобках.
Эхо полученного значения нужно потому, что съеденные оболочкой кавычки дают почти тот же
JSON ({group:X} вместо {"group":"X"}), и без него агент считает свой вызов верным. PS 5.1
печатает лишь огрызок и локализованно, Python — только номер колонки.
Возврат в PS1 через Write-Output -NoEnumerate: вынос разбора в функцию добавляет второй
анруллинг, и одноэлементный JSON-массив стал бы скаляром. Импорты внутри тела py-хелпера —
skd-decompile импортирует json локально как _json, а тело семьи обязано быть одинаковым.
В раннер добавлен inputRaw (запись входного файла дословно): через case.input битый JSON
невыразим, JSON.stringify всегда даёт валидный документ.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Вид искался как первое совпадение //md:<Вид> по всему файлу и потому зависел
от порядка перебора видов. У бизнес-процесса есть свойство <Task>, и объект
определялся как задача, после чего имя не находилось вовсе: «Не удалось
определить имя объекта из Properties/Name». Прежний упорядоченный список видов
это маскировал — в нём BusinessProcess стоял раньше Task.
Теперь вид — первый элемент-потомок MetaDataObject, и неподдерживаемый вид
отвергается по имени, а не проваливается в поиск имени объекта.
Нашлось платформенной проверкой всех видов разом: собрана конфигурация с
формой каждого поддержанного вида (15 видов, 43 формы) и загружена в 1С.
Заодно покрытие назначений доведено до полного (добавились FolderChoice, Load,
Record), а мелкие кейсы на один объект объединены: несколько назначений в одном
кейсе, эталон показывает все слоты сразу.
Гард дополнен инвариантом «ровно одна основная форма на вид» и его паритетом
между портами — именно им пользуется умолчание -Purpose.
Инструкция: в таблице параметров умолчание Purpose исправлено с Object на
основную форму вида.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Пропуск по версии платформы гасит проверку: кривую фикстуру он тоже спрячет,
если её формат объявлен выше платформы стенда. Обычный прогон теперь прямо
говорит, что пропуски не проверены, а на стенде с нужными платформами
--strict не оставляет непроверенных кейсов.
Опечатка в версии формата при этом не маскируется в любом режиме: версии вне
лестницы в таблице соответствия нет, пропуск не срабатывает, и кейс доезжает
до платформы.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Пропуск кейса решался только режимом совместимости. Кейс на формате 2.21 с
совместимостью 8.3.27 на платформе 8.3.24 пропускался, а на 8.3.27 доходил до
загрузки и падал: формат 2.21 требует 8.5. На стендах с промежуточной
платформой (в том числе macOS с 8.3.27) это давало постоянный ложный красный.
Эталон соответствия «формат → платформа» — таблица «Лестница версий» из
docs/1c-configuration-spec.md, как и в check-format-versions.mjs.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Десять кейсов на то, что раньше не проверялось вовсе: журнал документов
(список и отказ для формы объекта), перечисление, план видов расчёта, наборы
записей регистров, форма группы справочника, произвольная форма, формы
хранилища настроек и отказ для константы. Дыра в покрытии и позволила дефекту
дожить: журналов и регистров среди кейсов не было.
Пять чужих кейсов (form-compile-from-object, cfe-validate) звали form-add без
-Purpose для регистров и полагались на умолчание Object — назначение им
проставлено явно. Их эталоны пересняты: слот основной формы, который раньше
молча оставался пустым, теперь заполняется. Эталоны проверены загрузкой в 1С.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Шаг preRun deletePath поддерживал только runner.mjs. В платформенной проверке
такой шаг проваливался в ветку запуска скрипта и падал на step.script.split,
то есть кейс не проверялся вовсе, а выглядел упавшим инструментом.
Шаг без script/writeFile/deletePath теперь отвергается с внятным текстом, а не
падает на undefined.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Держит три инварианта form-add: состав видов сходится со спецификацией,
свойство «основная форма» у назначения есть у этого вида по спецификации,
таблицы PS и PY совпадают между собой.
Проверено на регрессии: если вернуть журналу DefaultListForm, гард падает
дважды — по спецификации и по паритету портов.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Для журнала документов навык писал в форму битый главный реквизит —
cfg:.Журнал с пустым префиксом. Платформа такую выгрузку не принимает
(«Исключение XDTO при чтении файла»), а навык рапортовал успех.
Причина не в забытой строке: знание о видах было размазано по четырём
независимым спискам (поддерживаемые типы, объектные, обработко-подобные,
карта типов реквизита) плюс switch по свойствам DefaultForm. DocumentJournal
попал в поддерживаемые, но не в карту типов — и подстановка $null дала точку
без типа. Теперь одна плоская таблица: строка на (вид, назначение), в ней тип
главного реквизита и свойство «основная форма».
Того же корня и починено заодно:
- Purpose=Object принимался для видов, у которых формы объекта не бывает
(журнал, перечисление, регистры накопления и бухгалтерии);
- свойство «основная форма» выбиралось без учёта вида: журналу писался
DefaultListForm, которого у него нет, и слот молча не находился;
- AccumulationRegister описывался как RecordSet, хотя у регистра такого
главного реквизита не бывает, а слота под него нет вовсе;
- ChartOfCalculationTypes отвергался, хотя формы объекта у него обычные.
Новое: назначения Folder и FolderChoice (формы группы), RecordSet для всех
регистров, Save/Load для хранилища настроек и Custom — произвольная форма без
главного реквизита, самая частая в типовых после объектной. Умолчание Purpose
теперь основная форма вида, а не жёсткий Object: для регистра сведений это
форма записи, для журнала — форма списка.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Таблица «Свойства DefaultForm по типам объектов» была неполной: в ней не было
журнала документов, перечисления, регистров накопления/бухгалтерии/расчёта,
плана видов расчёта, критерия отбора, хранилища настроек и внешних объектов.
Сверять код было не с чем, и код оказался неполон ровно так же.
Добавлена вторая таблица — главный реквизит формы по назначению. Она разводит
случаи, которые легко перепутать: форма группы это форма ОБЪЕКТА группы, а
форма выбора группы — динамический список; у формы набора записей свойства,
чтобы назначить её основной, нет вовсе; форма без главного реквизита
(«произвольная») — обычное дело, а не полуфабрикат.
Источник — выгрузки типовых: слоты и типы главного реквизита сняты по
конфигурациям acc, erp, ut, unf.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
form-remove: удаление заблокировано ссылками; -Force чистит слот реквизита,
ChoiceForm внутри формы и элемент начальной страницы; регресс на матч
ссылки — удаление своей формы не трогает ссылку на чужую форму с тем же
именем.
meta-remove: общая форма, на которую смотрит Configuration.xml, — ссылка
попадает в отчёт, -Force обнуляет слот.
meta-validate: незарегистрированная форма и отсутствующий файл формы дают
ошибку, GUID в слоте — нет.
Эталоны проверены платформой: verify-snapshots поднимает базу и грузит
результат.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
verify-snapshots отбирал кейсы по правилу «нет input, preRun и params →
read-only, пропускаем». Кейс на `setup: fixture:` под него подходил, хотя
навык правит скопированную фикстуру, — и молча выпадал из проверки, ради
которой инструмент и существует. Отчёт при этом оставался зелёным.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Непустое Default*Form / Auxiliary*Form / ChoiceForm могло указывать на
форму, которой нет, а валидатор отвечал OK. Платформа такую выгрузку не
принимает: «Неизвестный объект метаданных».
Новая проверка разбирает обе формы записи. Для своего объекта проверяется
регистрация формы в ChildObjects — это работает и на одиночном файле, без
конфигурации; для общей формы и чужого объекта (форма журнала документов в
слоте документа) нужна конфигурация, и проверяется наличие файла формы.
Отдельно ловится случай, когда форма зарегистрирована, а файла нет.
Значением слота бывает GUID — такие пропускаются, как и в cf-validate.
Заимствованные объекты расширения пропускаются целиком: их формы живут в
основной конфигурации.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Файл целиком исключался из проверки ссылок как «чистится автоматически»,
хотя автоматически в нём чистится только ChildObjects. Ссылки уровня
конфигурации (DefaultReportForm и соседи) после удаления общей формы
оставались висеть и в отчёте не упоминались.
Теперь такие слоты видны в списке ссылок, а с -Force очищаются — наравне со
слотами других объектов и элементами начальной страницы. Ссылки на типы и
вызовы в .bsl по-прежнему не трогаем: чем их заменить, неизвестно.
Два полных обхода конфигурации свёрнуты в один, Get-ChildItem -Recurse
заменён на Directory.EnumerateFiles: на большой конфигурации проход занимал
180 с против 47 с, а проходов было два.
Общие паттерны ищутся в тексте без form-слотов — иначе файл со слотом
попадал в список дважды, а пропуск файла целиком спрятал бы настоящую
ссылку рядом со слотом.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Форма могла удаляться, оставляя ссылки на себя в других объектах: платформа
затем отвергала загрузку с «Неизвестный объект метаданных». Навык правил
только файл своего объекта и про остальную конфигурацию не знал.
Теперь перед удалением конфигурация сканируется на ссылки на эту форму
(слоты Default*/Auxiliary*Form и ChoiceForm, ChoiceForm и SettingsStorage
внутри форм, элементы начальной страницы). Есть ссылки — удаление
останавливается со списком мест; с -Force форма удаляется, а ссылки
очищаются: слот пустеет, элемент начальной страницы вырезается.
Заодно починен матч ссылки: сравнение шло по хвосту «Form.<Имя>» без вида и
объекта, поэтому при удалении своей ФормаСписка обнулялась и ссылка на
DocumentJournal.Ж.Form.ФормаСписка в том же файле.
Сравнение путей переведено на длинную форму: Resolve-Path отдаёт короткое имя
8.3, перечисление файлов — длинное, из-за чего собственный файл объекта не
исключался из скана.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
