Ручную n8n-ноду для API часто делают как временный костыль. Потом выясняется, что она живёт отдельно от специф

Ручную n8n-ноду для API часто делают как временный костыль. Потом выясняется, что она живёт отдельно от спецификации, документации и SDK — и начинает врать на каждом втором релизе.

В кейсе с Пачкой от ручной версии просто отказались: ноду выбросили полностью и перевели сборку на один источник правды — .tsp-файл. Дальше цепочка стала автоматической: правка в спецификации обновляет документацию, CLI, SDK и саму ноду. CI отдельно публикует артефакты в реестры, а n8n-пакет проходит проверку и получает статус verified by n8n.

Что здесь важно для GR/comms/legal: это не про «ускорились в разработке», а про снижение операционного риска. Когда API, документация и интеграция собираются из одного контура, уменьшается число расхождений, спорных трактовок и ручных исключений. Для внешних партнёров это уже не “мы потом поправим”, а воспроизводимая схема поставки. ⚙️