Наш конвейер разработки на 1С

Когда в разработку под 1С начинают добавлять ИИ-агентов, первый соблазн почти всегда одинаковый: дать агенту задачу, дождаться сгенерированного кода и считать, что работа сделана.

На практике этого мало.

Для 1С-разработки важен не только текст модуля или XML внешней обработки. Нужно понять конфигурацию, подобрать версию базы, собрать артефакт, применить его в тестовом контуре, проверить результат, сохранить доказательства и не сломать соседние задачи. Иначе получается не разработка, а удачный фрагмент в редакторе.

Поэтому мы начали строить конвейер разработки на 1С как производственную линию. На входе — задача пользователя и, возможно, файлы. На выходе — проверенный артефакт, исходники, тесты, отчет о прохождении стадий и история того, кто что сделал.

Поддерживаемые CLI backend’ы сразу заложены как часть маршрута: основной backend — cursor, дополнительные — codex, claude и экспериментальный mimo. Пользователь описывает задачу, а профиль конвейера выбирает, каким CLI выполнять агентскую стадию.

Задача  -> диспетчеризация  -> исследование  -> разработка  -> сборка  -> проверка через runtime  -> UI/evidence  -> ревью  -> приемка  -> релиз артефакта

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

Почему Нужен Именно Конвейер

В обычной 1С-разработке много неявных операций:

• понять, для какой конфигурации и версии делается доработка;

• найти правильные объекты метаданных;

• учесть режим совместимости и версию платформы;

• выгрузить или собрать XML-исходники;

• собрать .epf, .erf или .cfe;

• загрузить результат в тестовую базу;

• открыть форму или сформировать печатный результат;

• проверить, что в таблице есть нужные поля, итоги и текст;

• сохранить артефакт так, чтобы его можно было отдать пользователю.

Человек часто держит эти шаги в голове. Агенту так нельзя. Если не сделать явный процесс, он будет уверенно перескакивать через стадии: “код изменен”, “проверьте сами”, “должно работать”.

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

Общая Схема Линии

Упрощенно линия выглядит так:

Public API / CLI / внутренняя задача              |              v        Orchestrator              |      +-------+--------+      |                |      v                v Research agent   PostgreSQL state      |      v Dev agent в отдельном worktree/LXC      |      v Build stage на Linux-хосте с 1С      |      v Bridge checks / render checks      |      v UI checks, если без них нельзя      |      v Review agent      |      v Promote + release artifacts

Оркестратор не пытается быть умным разработчиком. Его задача — вести изделие по цеху: создать run, выбрать базу, запустить нужные станции, дождаться результата, обработать ошибки, повторить стадию при необходимости и зафиксировать все события.

Станция 1. Приемка Задачи

На вход конвейера приходит manifest задачи. В нем важно отделить пользовательское описание от технической маршрутизации.

Минимальный смысл такой:

{  "task_type": "external_print_form",  "brief": "Сделать внешнюю печатную форму для документа Заказ покупателя. В таблице нужны товар, валюта и сумма.",  "configuration": {    "configuration_id": "unf_3_0_13_238"  },  "repo": {    "mode": "new",    "owner": "customer",    "slug": "customer-order-print-form"  },  "constraints": {    "max_attempts_per_stage": 3  }}

Здесь есть несколько важных решений.

Во-первых, пользователь выбирает конфигурацию и версию, а не внутреннюю тестовую базу. Конвейер сам сопоставляет выбранную версию с доступными песочницами.

Во-вторых, тип задачи задает маршрут. Внешняя печатная форма, внешний отчет, обработка и расширение требуют разных проверок и разных блокировок.

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

Типовая раскладка:

incoming/  sources/      исходные epf/erf/cfe или XML  support/      документы, таблицы, пояснения  screenshots/  визуальные требования и примеры  manifest.json роли файлов, имена, размеры, sha256

Это мелочь только на первый взгляд. Для агента файл без роли — просто случайный объект. Файл с ролью screenshot или source уже становится частью задачи.

Станция 2. Preflight

Preflight — это входной контроль деталей перед тем, как изделие уедет дальше по линии.

На этой стадии конвейер проверяет:

• доступен ли PostgreSQL, где хранится состояние;

• есть ли тестовая база для выбранной конфигурации;

• есть ли snapshot метаданных нужной версии;

• живы ли MCP-сервисы метаданных, сборочной валидации и генерации layout;

• отвечает ли Linux-хост с установленной платформой 1С;

• можно ли запускать выбранный агентский backend;

• не нарушены ли лимиты по файлам и попыткам.

Главная идея preflight: дорогие стадии не должны стартовать, если среда заведомо не готова.

Например, если для выбранной версии конфигурации нет индекса метаданных, dev-agent не должен угадывать имена документов по памяти или по другой версии. Конвейер обязан остановиться раньше и попросить подготовить snapshot.

Линия не запускает станок, если у него нет оснастки.

Станция 3. Исследование

Research-agent работает только на чтение. Это отдельная роль, и это принципиально.

Он собирает контекст:

• похожие прошлые задачи;

• подходящие примеры из локальных шаблонов;

• подсказки по метаданным;

• известные ошибки;

• риски реализации;

• рекомендуемый маршрут для dev-agent.

При этом research-agent не должен менять файлы. Его результат — не код, а карта местности.

{  "status": "ok",  "summary": "Для печатной формы подходит шаблон MXL. Целевой объект похож на Документ.ЗаказПокупателя.",  "artifacts": [],  "suggested_next": "dev-agent: создать EPF из шаблона, добавить макет, подготовить render-check"}

Отдельное правило: все запросы к метаданным идут с явной версией конфигурации. В 1С это критично. Поле, табличная часть или даже объект могут отличаться между релизами, и ошибка “почти такая же конфигурация” потом всплывет на сборке или у пользователя.

Песочницы 1С

Отдельный слой конвейера — тестовые базы. Их лучше воспринимать не как “какую-то демо-базу”, а как управляемые песочницы с понятной версией конфигурации, платформы и метаданных.

Внешний пользователь или внешняя система не выбирает конкретную внутреннюю базу. На входе достаточно выбрать семейство и версию конфигурации, например “УНФ 3.0.13.238”. Дальше оркестратор сам ищет подходящую запись в реестре test_bases.

В реестре хранятся:

• base_id — внутренний идентификатор тестовой базы;

• config_version — версия конфигурации;

• platform_version — версия платформы 1С;

• путь или параметры подключения для worker-хоста;

• признак доступности базы для конкретного типа задач;

• связь с metadata snapshot.

Это дает важное свойство: агент не угадывает, где выполнять задачу. Он получает уже разрешенную пару “конфигурация + песочница” и работает в заданных границах.

Runtime-базы находятся на отдельном Linux-контуре с платформой 1С. Для серверных сценариев используются PostgreSQL-песочницы, а операции сборки, bridge-проверок и UI-клиента выполняются на выделенном 1С-хосте. Такой контур позволяет быстро создавать или переиспользовать базы, но при этом не смешивать их с рабочими информационными базами.

В песочницах есть несколько правил:

• для каждой задачи фиксируется конкретная версия конфигурации;

• metadata MCP должен иметь snapshot именно для этой версии;

• операции, меняющие базу или расширения, берут runtime-lock;

• внешние отчеты, обработки и печатные формы по возможности проверяются без мутации базы;

• UI-сценарии сериализуются отдельно, потому что дисплей и клиент 1С обычно общий ресурс.

Песочница — это не место, где “можно ломать все подряд”. Это воспроизводимый стенд, на котором можно проверить артефакт и сохранить evidence. Если песочница не найдена, preflight должен остановить run до запуска дорогих агентских стадий.

Станция 4. Разработка

Dev-agent работает в отдельном рабочем каталоге и отдельной ветке. Для изоляции можно поднимать короткоживущий LXC-контейнер: он получает worktree, исходные файлы, контекст research-стадии и доступ к нужным инструментам.

Жизненный цикл такого контейнера похож на сменную кассету на линии:

взять свободный VMID/IP  -> клонировать шаблон  -> дождаться SSH  -> обновить инструменты  -> подготовить worktree  -> запустить agent CLI  -> получить diff  -> остановить и уничтожить контейнер

Почему так, а не один общий каталог?

Потому что агентская разработка любит оставлять следы: временные файлы, локальные проверки, неудачные попытки, промежуточные исходники. Изолированный worktree и одноразовый контейнер уменьшают риск, что один run повлияет на другой.

В product repo используется стабильная структура:

src/           исходники XML/BSL/MXLdist/          собранные epf/erf/cfeincoming/      входящие файлы пользователяtests/pipeline/   накопительные машинные проверкиdocs/          заметки по реализации и приемкеREADME.md      краткое описание результата

Для разных типов артефактов канонические пути отличаются:

src/extensions/<Name>/Configuration.xml      -> dist/extensions/<slug>/<Name>.cfesrc/print-forms/<slug>/<slug>.xml            -> dist/print-forms/<slug>.epfsrc/reports/<slug>/<slug>.xml                -> dist/reports/<slug>.erfsrc/processors/<slug>/<slug>.xml             -> dist/processors/<slug>.epf

Если пользователь передал готовый .epf, .erf или .cfe, агент сначала разбирает его в XML-исходники, а уже потом меняет XML/BSL/MXL. Это важнее, чем кажется: бинарный артефакт плох для ревью, тестов и повторной сборки.

CLI Backend: Кто Именно Выполняет Агентскую Стадию

В конвейере агентская стадия не привязана навсегда к одному инструменту. Оркестратор выбирает CLI backend по профилю, хосту или конкретному run. Внешний пользователь этот выбор обычно не делает: это внутренняя настройка линии.

Поддерживаемая идея такая:

• cursor — основной backend по умолчанию;

• codex — дополнительный backend для тех же стадий;

• claude — backend через Claude Code CLI;

• mimo — экспериментальный backend, включается только явно.

У всех backend’ов общий контракт результата. Стадия должна вернуть JSON:

{  "status": "ok",  "summary": "Short result",  "artifacts": [],  "suggested_next": ""}

Это важнее конкретного CLI. Оркестратору не нужно знать, как именно агент внутри себя думал и какие промежуточные команды выполнял. Ему нужен понятный результат стадии: ok, failed или blocked, краткая сводка и список артефактов.

Различаются только способы запуска:

• для cursor используется CLI agent с печатным режимом, workspace и JSON-выводом;

• для codex команда строится вокруг codex exec с JSON-выводом, рабочим каталогом, sandbox-режимом и файлом последнего ответа;

• для claude используется claude --print --output-format json;

• для mimo используется mimo run --format json с передачей prompt через файл.

MCP-конфигурация тоже создается под конкретный backend: для Cursor, Codex, Claude и MiMo используются разные локальные конфиги, но набор сервисов по смыслу один и тот же — metadata, build validation и layout.

Практический плюс такого слоя — конвейер можно развивать без переписывания маршрута задач. Если одна стадия лучше работает на другом CLI, меняется профиль запуска, а не весь процесс разработки.

Станция 5. Генераторы Вместо Ручного XML

У 1С-исходников есть неприятное свойство: технически это XML, но руками писать его хрупко. Особенно если речь про СКД, MXL-макеты и управляемые формы.

Поэтому в конвейере полезны отдельные MCP-сервисы или локальные генераторы:

• metadata service — поиск и описание объектов конфигурации;

• build validation service — быстрая проверка draft-артефактов;

• layout service — генерация переносимых заготовок СКД, MXL и печатных форм.

Dev-agent в таком подходе не обязан сочинять весь XML сам. Он формирует более компактное намерение:

{  "artifact": "external_print_form",  "assignment": "Документ.ЗаказПокупателя",  "columns": ["Номенклатура", "Валюта", "Сумма"],  "totals": ["Сумма"]}

А генератор возвращает структуру исходников, которую можно собрать, проверить и ревьюить.

Это снижает количество случайных ошибок: неверных UUID, неправильных узлов формы, сломанных MXL-областей, несовместимых свойств.

Станция 6. Сборка На Хосте С 1С

Разработка может идти в контейнере, но сборка 1С-артефактов должна выполняться там, где есть платформа 1С, ibcmd, тестовые базы и настроенная среда.

В нашем варианте это отдельный Linux-хост с 1С. Он умеет:

• создавать и копировать тестовые информационные базы;

• импортировать и экспортировать XML;

• выполнять ibcmd-проверки;

• собирать .cfe, .epf, .erf;

• применять пакет артефактов;

• запускать runtime-проверки;

• сохранять логи и результаты сборки.

Важно разделять роли:

• dev-agent меняет исходники;

• build-stage собирает и применяет;

• review-agent проверяет diff и evidence;

• orchestrator двигает run по стадиям.

Если dev-agent сам “как-нибудь собрал у себя”, это не считается финальной проверкой. Финальная сборка должна быть воспроизводимой на выделенном хосте.

Станция 7. Runtime-Проверки Через Bridge

Самая частая ошибка автоматизации 1С — сразу идти в UI. Открывать клиент, кликать по формам, ждать окна, распознавать скриншоты. Это медленно и хрупко.

Более надежный порядок другой:

1. Сначала проверить серверное поведение через HTTP bridge.

2. Затем проверить машинно-читаемый результат: MXL, HTML, TXT, JSON.

3. Только после этого запускать UI, если без визуального доказательства нельзя.

Bridge в тестовой базе дает агенту runtime-контур:

• проверить доступность базы;

• получить список метаданных;

• описать объект;

• выполнить запрос;

• создать тестовые данные;

• прочитать объект;

• сформировать внешнюю печатную форму;

• сформировать внешний отчет;

• сохранить результат в файлы.

Для внешней печатной формы правильный evidence — не только “EPF собрался”. Нужно сформировать табличный документ и проверить его содержимое.

result.epf  -> render external print form  -> print-result.mxl  -> print-result.html  -> print-result.txt  -> print-result.assessment.json

После этого можно проверить:

• есть ли нужный заголовок;

• есть ли строки табличной части;

• не дублируются ли колонки;

• заполнены ли суммы;

• правильно ли выведены итоги;

• нет ли запрещенных или отладочных текстов;

• читается ли результат без открытия Конфигуратора.

Для агента это принципиальная разница. Он не просто “написал печатную форму”, а получил исполняемый результат и проверил его.

Станция 8. UI-Проверки Только Там, Где Они Нужны

UI-проверки остаются важными, но их лучше использовать как короткий визуальный контроль.

Например:

• открыть 1С-клиент;

• открыть нужную форму;

• убедиться, что команда появилась;

• сформировать печатную форму;

• сделать скриншот результата;

• закрыть клиент.

На Linux-хосте это можно выполнять через Xvfb, оконный менеджер и инструменты управления окнами. Но длинные бизнес-сценарии в UI лучше не кодировать, если bridge может подготовить и проверить те же данные быстрее.

Bridge - для состояния и данных.UI - для того, что действительно видно только глазами пользователя.

Такой подход уменьшает шум: меньше случайных падений из-за фокуса окна, таймингов, масштаба интерфейса и фоновых диалогов.

Станция 9. Review

Review-agent не должен верить словам dev-agent.

Он проверяет:

• diff исходников;

• собранные артефакты;

• логи build-стадии;

• результаты bridge/render-проверок;

• UI evidence, если оно есть;

• накопительные тесты в tests/pipeline;

• соответствие acceptance-критериям.

Если пользовательское поведение изменилось, а reusable test не добавлен, review должен блокировать приемку. Это жесткое правило, потому что иначе конвейер быстро превращается в набор одноразовых успешных запусков.

Хороший результат review — это не “мне кажется, норм”. Хороший результат выглядит так:

{  "status": "ok",  "summary": "EPF собран, print-result.txt содержит товар, валюту и сумму, накопительный тест добавлен.",  "artifacts": [    "dist/print-forms/customer-order.epf",    "evidence/print-result.txt",    "tests/pipeline/customer-order-print-form.json"  ],  "suggested_next": "promote"}

Станция 10. Promote И Release

После успешного review run-ветка fast-forward’ится в main product repo. Затем публикуются пользовательские артефакты.

Важный момент: run-ветки и события не нужно стирать. Они остаются как аудит:

• какой агент выполнял стадию;

• какой run породил commit;

• какие проверки были выполнены;

• какие артефакты получились;

• сколько попыток понадобилось.

Для агентских commit’ов полезны audit trailers:

Pipeline-Agent: dev-agentPipeline-Run: <run_id>Pipeline-Gitea-User: <agent_user>

Это не украшение. Когда через месяц нужно понять, почему печатная форма устроена именно так, история run’а экономит часы.

Gitea Как Производственная Поверхность

В конвейере Gitea используется не просто как “место, куда положили файл”. Это внешняя поверхность для исходников, истории задач, audit trail и релизов.

Каждая пользовательская работа живет в product repository. В нем остаются:

• исходники в src/;

• собранные артефакты в dist/;

• входящие файлы в incoming/;

• накопительные тесты в tests/pipeline/;

• заметки и evidence в docs/;

• краткое описание задачи в README.md.

Dev-agent работает в run-ветке и после изменений пушит ее в Gitea. Review-agent анализирует уже подготовленный diff, артефакты и доказательства проверок. Если review успешен, оркестратор fast-forward’ит принятую ветку в main.

Release stage публикует пользовательский результат как Gitea release. Для внешней печатной формы это может быть .epf, для отчета — .erf, для расширения — .cfe. Вместе с артефактом можно сохранить evidence: текстовый render, HTML/MXL, скриншот 1С-клиента, assessment JSON.

Отдельная деталь — идентичности агентов. У ролей могут быть отдельные Gitea-пользователи и SSH-ключи. Коммиты получают audit trailers:

Pipeline-Agent: dev-agentPipeline-Run: <run_id>Pipeline-Gitea-User: cursor-dev-1

Так история разработки перестает быть анонимной. Видно, какая роль внесла изменение, в рамках какого run’а и каким техническим пользователем.

Почему не складывать все в S3 или локальную папку? Потому что для 1С-доработок важны не только бинарные файлы. Нужны исходники, тесты, история review, связь с задачей и возможность повторить сборку. Gitea закрывает эту часть как обычный Git-контур с релизами.

PostgreSQL Как Табло Линии

Файловый state.json удобен в прототипе, но быстро становится вторым источником правды. В конвейере состояние лучше хранить централизованно.

Основные таблицы:

• pipeline_runs — run, статус, стадия, база, версия, repo;

• pipeline_events — timeline всех стадий;

• pipeline_reports — финальные JSON/Markdown отчеты;

• pipeline_artifacts — внутренние и пользовательские артефакты;

• pipeline_incoming_artifacts — входящие файлы;

• pipeline_usage — токены, стоимость, модель, стадия;

• pipeline_locks — runtime-блокировки;

• agent_containers — постоянные и временные LXC;

• test_bases — реестр тестовых баз;

• pipeline_configs — профили, хосты, секреты, task types.

Отдельно нужен heartbeat. Если стадия идет долго, оркестратор периодически пишет:

{  "pid": 88911,  "host": "agent-orchestrator",  "stage": "dev",  "updated_at": "2026-05-27T10:56:00+03:00",  "interval_seconds": 120}

Если heartbeat протух, watchdog может перевести run в FAILED_STALE. Это неприятно, но честно. Зависшая стадия хуже явной ошибки: она занимает ресурсы и обманывает внешний статус.

Блокировки: Где Можно Параллелить, А Где Нельзя

Не все стадии одинаково опасны.

Разработка и ревью могут идти параллельно в отдельных worktree. Внешние печатные формы, отчеты и обработки часто можно собирать без блокировки всей базы. А вот операции, которые меняют расширения или состояние тестовой базы, должны сериализоваться.

Типовые lock’и:

base-mutating-linux-1c-vm117-<base_id>-<config_version>ui-display-linux-1c-vm117ephemeral-lxc-pool

Первый защищает базу от одновременной мутации. Второй не дает двум UI-сценариям драться за один дисплей. Третий не позволяет двум run’ам получить один и тот же VMID или IP.

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

Retry: Повторять Нужно Не Все

Retry кажется простой функцией: если стадия упала, запустить еще раз. Но в конвейере разработки это опасное упрощение.

Ошибки бывают разные:

• агент написал неправильный код;

• metadata service недоступен;

• не хватило лицензии 1С;

• занята UI-сессия;

• пользователь указал несуществующий объект;

• build упал из-за реальной ошибки XML;

• webhook не дошел до внешней системы.

Не каждая ошибка должна возвращать задачу на dev-agent.

Если сборка заблокирована лицензией 1С, новый код не поможет. Если пользователь попросил печатную форму для объекта, которого нет в выбранной конфигурации, нужно уточнение, а не третья попытка разработки. Если bridge недоступен, это инфраструктурная проблема.

Поэтому retry policy должен учитывать стадию и тип ошибки:

dev.failed          -> повторить dev с историей ошибкиbuild.failed        -> иногда вернуть в dev, если ошибка в исходникахbuild.blocked       -> остановить как инфраструктурный блокерresearch.blocked    -> запросить уточнение пользователяwebhook.failed      -> повторять доставку через outbox

История последних ошибок должна попадать в контекст следующей попытки. Иначе агент будет наступать на те же грабли, только увереннее.

Пример: Внешняя Печатная Форма

Разберем маршрут на типовой задаче.

Пользователь просит:

Сделать внешнюю печатную форму для документа Заказ покупателя.В табличной части нужны товар, валюта и сумма.

Маршрут:

1. Конвейер принимает задачу и выбранную версию конфигурации.

2. Preflight проверяет базу, metadata snapshot, 1С-хост и сервисы.

3. Research-agent ищет объект документа и подходящие примеры.

4. Dev-agent создает исходники EPF в src/print-forms/....

5. Layout/generator помогает собрать MXL-макет.

6. Dev-agent добавляет накопительный тест в tests/pipeline.

7. Build-stage собирает dist/print-forms/...epf.

8. Bridge-stage формирует табличный документ на тестовых данных.

9. Проверяется print-result.txt и assessment JSON.

10. UI-stage делает короткий скриншот, если нужен визуальный evidence.

11. Review-agent проверяет diff, тесты и evidence.

12. Promote переносит принятую ветку в main.

13. Release сохраняет EPF и evidence как пользовательские артефакты.

В результате пользователь получает не просто файл. Он получает файл, который прошел маршрут:

исходники -> сборка -> runtime render -> проверка содержимого -> review -> release

Для 1С это особенно важно, потому что многие ошибки проявляются только после сборки и запуска в конкретной базе.

Что Оказалось Самым Важным

Первое: агенту нужен не только prompt, но и инфраструктура. Без базы, метаданных, сборки и runtime-проверок он остается текстовым помощником.

Второе: стадии должны быть маленькими. Research не пишет код. Dev не делает финальное ревью. Build не принимает архитектурные решения. Review не исправляет молча исходники. Чем яснее границы, тем проще искать ошибки.

Третье: evidence важнее красивого статуса. “Готово” ничего не стоит без MXL/HTML/TXT результата, скриншота, лога сборки или JSON-отчета.

Четвертое: UI-тесты нужно беречь. Если можно проверить через bridge, лучше проверить через bridge. UI оставлять для визуального слоя.

Пятое: продуктовый репозиторий должен хранить не только исходники, но и накопительные тесты. Иначе каждая задача начинается с нуля.

Ограничения И Острые Углы

Такой конвейер не бесплатен по сложности.

Нужно поддерживать:

• тестовые базы по версиям конфигураций;

• индекс метаданных;

• Linux-хост с 1С;

• MCP-сервисы и worker tools;

• шаблоны артефактов;

• политики retry;

• очистку временных контейнеров;

• блокировки ресурсов;

• хранение usage и событий;

• безопасную работу с входящими файлами.

Кроме того, агентская разработка не отменяет инженерную дисциплину. Если acceptance-критерии размыты, агент будет делать приблизительно. Если нет тестовых данных, проверка будет слабой. Если metadata snapshot устарел, хорошего результата ждать странно.

Конвейер не делает разработку магической. Он делает ее наблюдаемой.

Итог

Наш конвейер разработки на 1С устроен как производственная линия: задача проходит через станции, каждая станция выполняет свою работу, а на выходе остается проверяемый след.

Главная мысль простая: ИИ-агент может быть полезным участником разработки, но не должен быть единственной точкой доверия. Доверять нужно процессу:

• явному manifest’у;

• актуальным метаданным;

• изолированной разработке;

• воспроизводимой сборке;

• runtime-проверкам;

• evidence;

• ревью;

• накопительным тестам.

Когда все это есть, фраза “агент сделал доработку 1С” начинает означать не “он написал кусок кода”, а “задача прошла инженерный маршрут и оставила проверяемый результат”.