0442aa015a
На 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>
Хуки: защита конфигураций на поддержке + подсказка навыков
⚠️ Экспериментально, по умолчанию выключено. Эти хуки не подключаются автоматически даже при установке плагина — их нужно включить вручную (см. «Установка» ниже). Базовая защита поддержки уже работает без хуков — встроена в сами навыки-мутаторы; хуки лишь добавляют перехват правок в обход навыков и подсказки. Фича новая, обкатывается; отзывы приветствуются.
Два хука Claude Code, которые помогают безопасно дорабатывать типовые конфигурации 1С:
- Защита от правки «на замке». Если модель пытается напрямую (инструментами
Edit/Write) изменить объект типовой конфигурации, который стоит на поддержке поставщика, редактирование блокируется — иначе оно молча сломает будущие обновления вендора. В отказе сразу даётся, что делать дальше под конкретный случай (доработать в расширении или явно разрешить редактирование). - Подсказка навыков. Когда модель работает с исходниками 1С «вручную» (читает сырой XML или правит его
напрямую), хук ненавязчиво напоминает про профильный навык — и по делу: при чтении ведёт на
*-info(понять структуру), при правке — на мутатор (meta-edit/form-edit/skd-edit/…). Не блокирует, подсказывает не чаще одного раза за сессию на группу и действие.
Это дополнительный слой поверх проверок, которые уже встроены в сами навыки: навыки-мутаторы и так не дадут испортить объект на поддержке. Хуки добавляют защиту для случаев, когда правят файлы в обход навыков.
Хуки — возможность только Claude Code. На других платформах их нет; там работают встроенные в навыки проверки.
Требования
Node.js 18+ (тот же, что нужен для /web-test). Команда node должна быть доступна в PATH.
Установка (ручная — фича экспериментальная)
Хуки сейчас не включаются автоматически ни одним способом установки (плагин их не объявляет в манифесте). Чтобы включить:
- Убедитесь, что каталог
hooks/доступен в проекте. При установке плагином он уже в составе плагина — используйте путь${CLAUDE_PLUGIN_ROOT}/hooks/.... При установке копированием навыков скопируйтеhooks/в проект, например в<проект>/.claude/hooks/, и используйте${CLAUDE_PROJECT_DIR}/.claude/hooks/.... - Добавьте в
<проект>/.claude/settings.json(пути ниже — для варианта с копированием):
{
"hooks": {
"PreToolUse": [
{ "matcher": "Edit|Write|MultiEdit",
"hooks": [{ "type": "command",
"command": "node \"${CLAUDE_PROJECT_DIR}/.claude/hooks/support-guard.mjs\"" }] }
],
"PostToolUse": [
{ "matcher": "Read|Edit|Write|MultiEdit",
"hooks": [{ "type": "command",
"command": "node \"${CLAUDE_PROJECT_DIR}/.claude/hooks/skill-suggester.mjs\"" }] }
]
}
}
Настройка (.v8-project.json)
Поведение настраивается в файле проекта .v8-project.json — глобально и/или по конкретной базе
(databases[].…, переопределяет глобальное):
| Поле | Значения | По умолчанию | Что делает |
|---|---|---|---|
editingAllowedCheck |
deny / warn / off |
deny |
Реакция защиты: блокировать правку объекта на замке / только предупреждать / выключить проверку. |
skillSuggester |
on / off |
on |
Включает/выключает подсказки навыков. |
Источник истины по состоянию поддержки — сама выгрузка конфигурации; .v8-project.json лишь настраивает
реакцию.
Что делать при отказе защиты
Текст отказа сам подсказывает варианты под конкретную ситуацию. Кратко:
- Безопаснее всего — вести доработку в расширении (навыки
cfe-borrow/cfe-patch-method): состояние поддержки менять не нужно, обновления вендора сохраняются. - Либо осознанно разрешить редактирование через навык
support-edit(включить редактирование объекта, снять его с поддержки или включить возможность изменения всей конфигурации). Готовую команду под ваш случай печатает сам отказ.
Проверка
node hooks/test/run.mjs
Прогоняет защиту и подсказку на реальных выгрузках и на временных тестовых данных (в test-tmp/, не
попадает в git; рабочие выгрузки не затрагиваются).