В прошлом уроке система научилась сама подключаться к 1С, Битриксу и другим программам — коннекторы пишутся за день-два. Но подключений будет больше, а среда будет обновляться: новая версия движка, новая модель, новый плейбук. Вопрос урока — переживёт ли система эти изменения, — и ответ в одном правиле: не трогать ядро.
Движок агента — например, Claude Code, на котором мы строим систему весь этот модуль, — обновляется регулярно и совершенно не спрашивает тебя, готов ли ты к обновлению. Это не недостаток, а нормальная жизнь любого активно развивающегося инструмента: разработчик добавляет функции, чинит ошибки, повышает безопасность. Проблема начинается в тот момент, когда ты решаешь «доработать» этот движок напрямую — залезть внутрь его системных файлов, переписать логику, встроить свою бизнес-специфику туда, где раньше был чужой, универсальный код.
Правило простое и не имеет исключений: ядро не трогаем никогда. Вся кастомизация — конфигурационные файлы вроде CLAUDE.md, скиллы, плейбуки, коннекторы из прошлого урока — живёт снаружи ядра, в отдельном слое, который движок читает при работе, но частью которого не является. Тогда обновление движка проходит мимо твоей системы: он становится умнее, быстрее, безопаснее, а твоя надстройка как работала, так и работает, потому что её никто не трогал.
На практике эта граница легко проверяется одним вопросом: переживёт ли этот файл переустановку движка с нуля? Системные файлы рантайма, его внутренняя логика вызова инструментов, встроенные команды — переживают обновление автоматически, потому что их обновляет поставщик. А вот CLAUDE.md, папки со скиллами, плейбуки на конкретные события, настройки коннекторов — это твоя территория, и именно она должна пережить переустановку в неизменном виде, потому что физически лежит рядом с ядром, а не внутри него. Если сомневаешься, к какой категории отнести файл, задай себе вопрос: писал ли его поставщик рантайма или писали мы сами под свою задачу. Ответ обычно очевиден.
Почти каждый предприниматель в России хоть раз сталкивался с болью, которая называется «доработанная 1С». Сценарий стандартный: программист открывает типовую конфигурацию и правит код прямо внутри неё — добавляет поле, меняет отчёт, встраивает свою логику туда, где раньше был чужой, фирменный код разработчика. Работает? Работает. Ровно до следующего обновления релиза. Выходит новая версия типовой конфигурации — и твои правки оказываются либо стёрты, либо в жёстком конфликте с новым кодом.
Дальше начинается «слияние»: программист вручную сверяет старую доработку с новым релизом, строчка за строчкой, и это может занимать дни, а иногда недели. В это время бухгалтерия либо не обновляется вовсе и живёт со…