Git-мост и AI-код-ревью

Управляемый мост 1С в Git превращает конфигурацию 1С в файлы в git-репозитории компании и надстраивает командные процессы: авто-PR/MR, реактивное код-ревью на локальной LLM, блокирующий гейт качества и SAST-подстраховку. Поддерживаются 7 провайдеров: GitLab, GitHub, Gitea, Bitbucket Cloud и Server, GitVerse, GitFlic.

Коммиты конфигурации

По обновлению выгрузки конфигурации (и по требованию) мост идемпотентно коммитит конфигурацию-как-файлы в git-репозиторий клиента: при пустом диффе коммит не создаётся, и повторный прогон не плодит пустых коммитов. Источник диффабельности это текстовый формат дампа (XML Конфигуратора).

Токен доступа к репозиторию хранится запечатанным в keystore и маскируется в интерфейсе. Управление мостами: /web/admin/git-bridge, доступ разграничен RBAC.

Ветки и синхронизация

Мост ведёт ветку mcp-1c/config (создаёт её идемпотентно, если ветки нет) и пушит без перезаписи: при расхождении удалённой ветки push отклоняется, удалённая история не переписывается. Обратное чтение фиксирует удалённый HEAD и состояние синхронизации; в админке бейдж статуса (в синхроне, расходится, ожидание) и кнопка синхронизации по требованию.

Аутентификация: HTTPS-токен или SSH-ключ. Ключ хранится в зашифрованном виде, форма только на запись, в интерфейсе показывается маска; проверка host-key выполняется fail-closed. Целевую ветку можно задать на каждый мост отдельно, а учётные данные вести именованным пулом на всю установку: запись пула, используемую мостом, удалить нельзя.

Авто-PR/MR

После публикации ветки мост автоматически открывает у провайдера запрос на слияние и поддерживает его актуальным: один запрос на ветку (find-or-create), повторный проход обновляет существующий и не создаёт дубликатов. Токен API передаётся только в заголовке Authorization, перенаправления на чужой хост отклоняются. В админке бейдж статуса запроса и ссылка на него.

Входящие вебхуки

Событие push или запроса на слияние от провайдера запускает синхронизацию немедленно, без ожидания опроса. Приёмник вебхуков защищён:

• подпись HMAC или общий секрет, сравнение за постоянное время; секрет берётся из конфигурации, а не из заголовка запроса;
• любой сбой (неверная подпись, неизвестный токен, отсутствие конфигурации) даёт единый ответ 404 без утечки факта существования endpoint;
• в адресе вебхука отдельный неперечислимый токен;
• повторные доставки дедуплицируются, частота ограничивается в памяти до обращения к базе данных;
• секрет вебхука хранится запечатанным, форма только на запись.

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

Провайдеры

Все провайдеры реализуют один абстрактный коннектор, специфика изолирована внутри реализации:

• GitLab, GitHub, Gitea: полный набор, включая принудительный гейт через статус коммита.
• Bitbucket Cloud и Bitbucket Server / Data Center: тот же интерфейс, включая статус коммита и вебхуки с HMAC.
• GitVerse и GitFlic: у этих платформ нет API статуса коммита, поэтому гейт качества там честно советующий (advisory): вердикт публикуется в комментарии, а ложно-зелёного статуса не бывает; на остальных провайдерах гейт остаётся принудительным.

Зеркалирование на несколько remote

Мост может зеркалить каждый push на дополнительные remote сверх основного. Основной push это источник истины: зеркала отрабатывают только после его успеха, каждое в отдельности и с ограниченным таймаутом. Сбой зеркала (недоступность, отказ аутентификации, неускоряемое обновление) записывается в поле последней ошибки и никогда не блокирует и не роняет основной push; зеркало никогда не делает force-push.

Зеркало это новый канал выхода всего репозитория конфигурации, поэтому хост каждого зеркала проверяется на принадлежность контуру (on-prem) fail-closed и при сохранении настройки, и при каждом push. Внешнее зеркало возможно только через явное разрешение на конкретное зеркало, и такое разрешение записывается в аудит событием git_bridge.mirror.external_allowed. Токен каждого зеркала хранится запечатанным. Управление: /web/admin/git-bridge/{id}/mirrors.

AI-код-ревью

По событию запроса на слияние (через входящий вебхук, без ожидания опроса) воркер ревью берёт изменённые файлы у провайдера и правила команды и прогоняет их через локальную (on-prem) LLM, а сводный комментарий с замечаниями публикует обратно в запрос.

• Исходный код уходит только на локальную LLM. Адрес модели проверяется по хосту: петля, частная сеть или список разрешённых; публичный адрес отклоняется ещё до отправки кода.
• Один комментарий на запрос. Повторный прогон обновляет тот же комментарий по подписанному маркеру; дубликаты не создаются, маркер нельзя подделать.
• Инлайн-замечания. Каждое замечание дополнительно публикуется отдельным инлайн-комментарием к файлу и строке диффа по всем провайдерам. Инлайн строго best-effort: промах позиционирования никогда не влияет на сводный комментарий и вердикт гейта; замечания без позиции сворачиваются в сводку.
• Действуют ограничения по объёму изменений и частоте запусков; функция выключена по умолчанию, строгость ревью настраивается.

Блокирующий гейт качества

Гейт превращает ревью в принудительную проверку: воркер выставляет статус-проверку провайдера (пройдено или не пройдено) на head-коммит запроса на слияние, и защита веток у клиента блокирует слияние, если есть замечания не ниже выбранного порога важности.

• Fail-closed. Статус ставится только когда ревью реально оценило изменения; иначе статус остаётся «ожидание», и слияние не проходит.
• Статус ставится на тот же коммит, который проверялся, а не на устаревший.
• Текст диффа изолируется от инструкций модели: подмена вердикта через комментарии в ревьюируемом коде (prompt-инъекция) не проходит.
• Порог важности и сам гейт настраиваются в админке; по умолчанию гейт выключен.

SAST-подстраховка

Параллельно LLM изменения проверяет детерминированный SAST-анализатор, и гейт считает объединение находок обоих: даже если prompt-инъекция принудила LLM к пустой оценке, детерминированная находка всё равно блокирует слияние.

Правила детерминированного пола:

• Выполнить / Execute / Eval и включение привилегированного режима: Critical, блокирует;
• зашитый секрет или строка подключения: Error, блокирует;
• Вычислить и пустой блок Попытка-Исключение: Warning, советующее.

Анализируются только добавленные строки диффа, с учётом кириллических границ слова и с вычищенными комментариями. Подстраховка работает всегда и не отключается.

Динамика ревью

Дашборд /web/admin/review-metrics показывает динамику гейта: пройдено и не пройдено во времени, находки по важности, атрибуция LLM против SAST (включая случаи, где слияние заблокировала именно детерминированная находка), разрез по провайдерам и советующий против принудительного режима.

Панель AI-триажа на той же странице суммаризирует тренды и кластеризует повторяющиеся типы находок через ту же локальную (on-prem) LLM; сообщения находок LLM проходят редактирование секретов перед сохранением. Выключено по умолчанию, включается переменной AI_TRIAGE_ENABLED. Плитка здоровья гейта выведена и на Control Tower.