Нашаманил в процессе обновления релиза КА 2.5

Как я обновлял расширения конфигурации при изменении релиза 1С:КА с 2.5.22.186 на 2.5.27.75 с помощью ИИ

Предисловие

Я — разработчик 1С, сопровождающий сильно доработанную конфигурацию «Комплексная автоматизация» редакции 2.5. Передо мной стояла задача: обновить релиз с 2.5.22.186 на 2.5.27.75, сохранив все пользовательские доработки. Конфигурация содержит основное расширение с сотнями перехваченных методов и форм.

До начала работы я зафиксировал правила обновления в файле upd.md, описывающем роли трёх версий (BASE, THEIRS, OURS) и алгоритмы слияния. Затем начал методично, модуль за модулем, проходить все изменившиеся методы.

В этой статье я расскажу, что получилось, что нет, и какую роль сыграл ИИ (Claude через opencode) на каждом этапе.

Инфраструктура

• Платформа: 1С:Предприятие 8.3.27.1719

• Конфигурация: Комплексная автоматизация 2.5

• Старый релиз: 2.5.22.186

• Новый релиз: 2.5.27.75

• Расширение: Основное расширение, обмен с БП, дополнительные расширения.

• Инструменты: CfeUpdater.epf 2.1.1.0, KDiff3, Git, opencode с Claude

Структура рабочего каталога:

text

I:\sv_ka_work\upd27\
  old-configuration\   # типовая до обновления (BASE)
  new-configuration\   # типовая после обновления (THEIRS)
  extension\           # расширение с доработками (OURS)
  after_upd\           # загруженное расширение для правки
  results\             # результаты слияния
  history.md           # журнал всех действий
  upd.md               # правила и алгоритмы

Ключевое правило: тело метода расширения с директивой &ИзменениеИКонтроль должно посимвольно совпадать с телом типового метода из NEW-конфигурации. Отличия допустимы только внутри блоков #Вставка / #КонецВставки и #Удаление / #КонецУдаления. Для проверки использовался скрипт merge-check.ps1.

Статистика проекта

• Всего сессий слияния: 69

• Уникальных модулей: 37

• Явных «0 diffs» (perfect match): 2

• Модулей с ошибками после слияния: 13

• Сессий исправлений: 17

• Полных пересборок с нуля: 1

• Runtime-ошибок, обнаруженных интерактивно: 7

• Попыток решения проблемы ПечатьЗаданияНаОтборРазмещениеТоваров: 5 подходов

• Дней активной работы: 2 (21–22 августа 2026)

Анализ: что получалось, что нет

Что ИИ делал отлично

1. Слияние простых перехватчиков (~60% модулей).

Я призываю не поручать ИИ все подряд, чем меньше тем лучше. Простое не только не выгодно, но от объема качество работы ИИ на мой взгляд сильно страдает. При чрезмерном доверии и недостатке внимания пользователя получилась дорогостоящая и бессовестная халтура, от которой руки опускаются. Так что простые вещи я делаю сам. Сложные поручаю ИИ под контролем для экономии времени.

Типовой сценарий: найти три файла (BASE, THEIRS, OURS), сопоставить метод, перенести #Вставка-блоки в NEW-тело, проверить merge-check.ps1. Для большинства модулей это занимало 2–3 итерации и давало чистый результат.

Пример: модуль ПулКодовМаркировкиСУЗ — метод СРС_ЗаписатьДанныеКодаМаркировки обновлён с новыми полями ПолныйКодМаркировки и ТоварнаяГруппа без единой ошибки.

2. Обнаружение переименований.

При загрузке расширения в конфигуратор платформа выдаёт ошибки на несовпадениях. ИИ анализировал NEW-конфигурацию и находил новые имена:

• РаспределениеЗапасов.Состояние → СостояниеЗапаса (8 вхождений)

• РаспределениеЗапасовСостояния.ОстатокНаСкладе → СостоянияЗапаса.ВНаличии

• ОсобенностиУчетаНоменклатуры.Антисептики → УдалитьАнтисептики (и ещё 5 аналогичных переименований enum-значений)

3. Глобальные замены.

Команда «замени во всех модулях X на Y» выполнялась быстро и без ошибок. Например, замена ОсобенностиУчетаНоменклатуры.* → Удалить* в 6+ модулях.

4. Посекционная сборка сложных методов.

Для метода СРС_ПараметрыФормыУказанияСерий (НоменклатураСервер) — 1752 строки, 16 блоков #Вставка — ИИ разбил NEW-тело на секции по якорным строкам и собрал результат посекционно. Итог: 0 diffs с NEW, идеальное совпадение.

Что ИИ делал с трудом

1. Трёхстороннее слияние без BASE.

Модуль УправлениеОтгрузкой не имел полного BASE для трёхстороннего сравнения. ИИ пытался восстанавливать логику по двум версиям — с ошибками, потребовалась ручная корректировка.

2. Специфичные знания платформы 1С.

ИИ не всегда знал ограничения синтаксиса:

• СГРУППИРОВАТЬ ПО с ПОМЕСТИТЬ в определённых контекстах вызывает ошибку

• ПЕРВЫЕ 1 работает нестабильно с временными таблицами

• #Удаление + #Вставка нельзя разбивать — иначе vendor-код между блоками не совпадает с NEW

Эти нюансы выяснялись экспериментально, ценой лишних итераций.

3. PowerShell.

Несколько раз команды падали из-за того, что PowerShell резолвил .Replace() во внешнюю утилиту replace.exe вместо метода .NET. Также были ошибки с кодировкой и экранированием спецсимволов.

КЛЮЧЕВОЕ ПРАВИЛО: #Удаление НЕЛЬЗЯ РАЗБИВАТЬ

Это правило оказалось самым критичным и неочевидным из всех, что были выявлены в ходе проекта.

В чём проблема

В расширении блок #Удаление помечает vendor-код, который должен быть удалён из NEW при наложении расширения. Платформа сравнивает vendor-код расширения (вне #Вставка и #Удаление) с NEW, из которого предварительно вычтено содержимое #Удаление.

Если в расширении был единый блок #Вставка / #Удаление, его нельзя разбивать при адаптации под новую конфигурацию. В противном случае появляется vendor-код между блоками, который не совпадает с NEW после вычитания.

Пример ошибки

В расширении (правильно):

text

#Вставка
    Если ... Тогда ... Иначе vendor_call КонецЕсли;
#КонецВставки
#Удаление
    vendor_call   # удаляет дубликат из NEW
#КонецУдаления

Ошибочная адаптация (разбиение на два #Вставка):

text

#Вставка
    Если ... Тогда ... Иначе
#КонецВставки
vendor_call         # vendor-код между блоками — ПЛАТФОРМА НЕ ПРИМЕТ!
#Вставка
    КонецЕсли;
#КонецВставки
#Удаление
    vendor_call
#КонецУдаления

При разбиении vendor-код между #КонецВставки и #Вставка остаётся, а #Удаление вычитает его из NEW — получается расхождение: расширение имеет vendor-код, а NEW после вычитания — пусто.

Правильная адаптация

Скопировать EXT-структуру один-в-один (один #Вставка → один #Удаление), заменив OLD vendor-код внутри #Вставка и внутри #Удаление на NEW-формат — включая точное совпадение отступов (табуляция должна быть как в NEW, а не как в EXT).

Как проверять

Обычный merge-check.ps1 (удаление обоих #Вставка и #Удаление) даёт 0 diffs даже при ошибочной структуре. Дополнительно обязательно проверять:

1. Содержимое #Удаление посимвольно совпадает с соответствующим vendor-кодом NEW

2. Между #КонецВставки и #Удаление того же логического блока нет vendor-кода (должны идти подряд)

3. После #КонецУдаления vendor-код продолжается со следующей строки NEW (без дубликатов и пропусков)

Итог: Это правило было выведено экспериментально на модуле СчетФактура и сэкономило несколько часов отладки runtime-ошибок в других модулях.

Что не получалось совсем

1. Экспорт встроенных обработок в EPF.

Команда ibcmd недоступна в этой версии платформы. Параметр /DumpExternalDataProcessorOrReport не экспортирует встроенные обработки. LoadExternalDataProcessorOrReportFromFiles ожидает формат <ExternalDataProcessor>, а XML-дамп даёт <MetaDataObject><DataProcessor>. Приходилось экспортировать EPF вручную из конфигуратора.

2. Первая попытка нормализации дубликатов в ПечатьЗаданияНаОтборРазмещениеТоваров.

4 подхода подряд не сработали — и только на 5-м был найден верный.

Кейс: ПечатьЗаданияНаОтборРазмещениеТоваров

Самый сложный модуль проекта. Ниже — хронология всех попыток.

Контекст

Печатная форма «Задание на сбор» из РасходногоОрдераНаТовары показывает список товаров с ячейками отбора. В новой версии запрос начал возвращать 4 строки вместо 1 для каждого товара — потому что один товар размещён в 4 ячейках, а LEFT JOIN по Номенклатуре умножает строки.

Попытка 1: МИНИМУМ + СГРУППИРОВАТЬ ПО

В подзапросах ЯчейкиОстаток и ЯчейкиИнформация (4 варианта) добавлены агрегатные функции МИНИМУМ() и СГРУППИРОВАТЬ ПО Номенклатура.

Результат: ОШИБКА — синтаксическая ошибка платформы: СГРУППИРОВАТЬ несовместимо с ЛЕВОЕ СОЕДИНЕНИЕ + ПОМЕСТИТЬ в данном контексте.

Попытка 2: ПЕРВЫЕ 1 + УПОРЯДОЧИТЬ ПО

Группировка откачена, вместо неё в каждый из подзапросов добавлены ПЕРВЫЕ 1 и УПОРЯДОЧИТЬ ПО Ячейка.Наименование.

Результат: ОШИБКА — ПЕРВЫЕ 1 без СГРУППИРОВАТЬ ПО ограничивает ВЕСЬ запрос одной строкой, а не одной строкой на товар. Если в заказе 5 товаров, ячейка будет получена только для первого.

Дополнительная ошибка: PowerShell-скрипт замены создал двойной префикс. Потребовалась дополнительная правка.

Ещё ошибка: скрипт отката GROUP BY использовал паттерн, который совпал во ВСЕХ подзапросах пакета. Все GROUP BY пришлось удалять и добавлять заново точечно.

Попытка 3: РАЗЛИЧНЫЕ в финальном SELECT

Все ПЕРВЫЕ убраны, вместо них в 4 финальных SELECT добавлено РАЗЛИЧНЫЕ.

Результат: НЕ ПОМОГАЕТ — РАЗЛИЧНЫЕ не помогает, потому что строки отличаются значением поля Ячейка — для одного товара в 4 разных ячейках возвращаются 4 разные строки, и РАЗЛИЧНЫЕ считает их уникальными.

Попытка 4: убрать Ячейка из Свернуть

Поля Ячейка и ЯчейкаСправочно убраны из метода Свернуть(), а код заполнения Размещения заменён на пустую строку.

Результат: ЧАСТИЧНО — 1 строка на товар, правильные количества. Но информация о ячейке потеряна — в печатной форме колонка «Размещение» пустая. Неприемлемо для пользователей.

Попытка 5 (финальная): нормализация в коде ДО Свернуть

Архитектура решения:

1. Запросы пакета НЕ трогаем — они остаются как в типовой конфигурации

2. После лЗапрос.ВыполнитьПакет() получаем ТаблицаЗначений с размноженными строками

3. Первый проход: для каждого ключа (Номенклатура + Характеристика) находим лучшую ячейку по MAX(Остаток)

4. Второй проход: всем дублям проставляем одинаковую ячейку; Остаток обнуляем у дублей (оставляем только у первой строки)

5. После нормализации вызываем Свернуть() с полным набором полей, включая Ячейка и ЯчейкаСправочно

6. Код заполнения Размещение восстановлен из лВыборка.Ячейка

Результат: УСПЕХ — 1 строка на товар, правильный остаток, ячейка сохранена.

Итог по модулю

Хронология: день 1 (21 августа 2026)

Первый день — потоковая обработка модулей. 21 модуль за одну сессию. Большинство — простые перехватчики, где нужно перенести 1–3 блока #Вставка в NEW-тело.

Ключевые события дня:

• ЗаказКлиента — дублированное присваивание настройки РазрешитьОтгрузкуСверхЗаказа. Исправлено удалением лишней строки.

• ВзаиморасчетыСервер — сложный случай: типовой модуль был разделён на 2 (основной + локализация). Пользовательский код потребовал переноса в новую структуру.

• ПроверкаИПодборПродукцииИС — спецсхема: BASE = старая обработка ИСМП, THEIRS = новая обработка ИС (без МП). Адаптация под новую архитектуру без ВидПродукции.

• ФормированиеФискальныхЧековКлиент — вызов удалённой клиентской функции из расширения. Исправлено переносом вызова в серверный контекст.

• ИнтеграцияИСМПУТ — обнаружены буквальные \t в тексте запросов (результат предыдущей автоматической обработки). Исправлено заменой на реальные табуляции.

Хронология: день 2 (22 августа 2026)

Второй день — работа над сложными модулями и исправление ошибок, обнаруженных при загрузке расширения.

Пересборка НоменклатураСервер

Метод СРС_ПараметрыФормыУказанияСерий (1752 строки) перестроен с нуля посекционным подходом. NEW-тело разделено на секции по якорным строкам, между ними вставлены 16 блоков #Вставка из расширения. Итог: 0 diffs с NEW.

СкладыСервер

Метод СРС_ПолучитьОбъектОрдер — NEW-запрос полностью переписан поставщиком. Пользовательские блоки перенесены в новый запрос. 153 строки, 0 diffs.

СчетФактура: ошибка разбиения #Удаление/#Вставка

Критическое правило, выведенное экспериментально: блоки #Вставка и #Удаление нельзя разбивать. Если EXT содержит единый блок:

text

#Вставка
    Если ... Тогда ... Иначе vendor_call КонецЕсли;
#КонецВставки
#Удаление
    vendor_call
#КонецУдаления

— его нельзя разбивать на два #Вставка с vendor-кодом между ними. Платформа сравнивает vendor-код расширения (вне #Вставка) с NEW, из которого вычтено содержимое #Удаление — и при разбиении получается расхождение.

ПечатьЗаданияНаОтборРазмещениеТоваров

Полная хронология — в разделе выше. 9 итераций, 5 подходов.

Артефакты проекта

Правила слияния (upd.md)

Файл на 314 строк, содержащий:

• Структуру рабочего каталога и роли версий

• 10 правил слияния (основа — NEW, пользовательские блоки переносятся, сигнатуры из NEW)

• Правило точного соответствия тела &ИзменениеИКонтроль с NEW (0 diffs)

• Правило обработки #Удаление — код внутри должен посимвольно совпадать с NEW

• Правило бэкапа перед изменениями

• Правило сохранности модуля расширения

• Инструменты: merge-check.ps1, merge_nomenk_v6.ps1

• Специфику модулей группы 3 (обработки) и ИСМП

Журнал действий (history.md)

Файл на 817 строк с детальным описанием каждой сессии:

• Дата и название модуля

• Описание выполненного изменения

• Перечень изменённых и созданных файлов

• Результаты статических проверок

• Ограничения и риски

Всего 69 записей за 2 дня.

Скрипты

• merge-check.ps1 — Посимвольное сравнение тела метода с NEW (проверка 0 diffs)

• merge_nomenk_v6.ps1 — Шаблон посекционной сборки метода

Результаты слияния (results/)

38 подкаталогов с результатами для каждого модуля: after_upd и backup_* файлы.

Ключевые выводы

1. Правила важнее интуиции

Файл upd.md с жёсткими правилами (0 diffs, не разбивать #Вставка/#Удаление, бэкап перед каждой правкой) сэкономил десятки часов отладки. Без него многие ошибки проявлялись бы только в runtime.

2. Проверка merge-check.ps1 обязательна

Посимвольное сравнение с NEW после каждой правки — единственный надёжный способ убедиться, что vendor-код не повреждён. 0 diffs ≠ отсутствие ошибок (есть ещё #Удаление), но не-0 diffs = гарантированная ошибка.

3. ИИ полезен, но не заменяет знание платформы

ИИ отлично справляется с рутинными слияниями (60% модулей), поиском переименований, глобальными заменами. Но специфичные ограничения платформы 1С (СГРУППИРОВАТЬ + ПОМЕСТИТЬ, ПЕРВЫЕ 1 в пакетах, структура #Вставка/#Удаление) приходилось выяснять экспериментально.

4. Инфраструктура — половина успеха

Чёткая структура каталогов (old-configuration, new-configuration, extension, after_upd, results), скрипты проверки, правила бэкапа — всё это сделало процесс воспроизводимым и позволило быстро откатывать неудачные попытки.

5. Самый сложный модуль — не тот, где много кода

НоменклатураСервер (1752 строки, 16 блоков #Вставка) был пересобран с первой попытки благодаря посекционному подходу. А ПечатьЗаданияНаОтборРазмещениеТоваров с простым запросом потребовал 9 итераций — потому что проблема была не в слиянии, а в логике (дубликаты из-за множественных ячеек).

После завершения всех слияний:

1. Проверка применимости расширения в конфигураторе

2. Выгрузка расширения в production

Результаты

Эксперимент показал, что AI-assisted upgrade типовой конфигурации 1С — это не фантастика, а рабочий инструмент уже сегодня. Да, с нюансами. Да, с ограничениями. Но 37 модулей за 2 дня с документированным процессом и воспроизводимыми результатами — это уровень.

Проект выполнен с использованием:

• 1С:Предприятие 8.3.27.1719

• Claude (Anthropic) через opencode — для анализа, слияния и генерации кода

• CfeUpdater.epf 2.1.1.0 — для анализа CFE-расширений

• PowerShell + Git — для автоматизации и версионирования

• KDiff3 — для ручного просмотра сложных конфликтов