Что мы собираем в библиотечном корпусе LEM для разработки 1С

Агент может найти нужный файл в проекте 1С и всё равно выбрать метод не той версии БСП, пропустить правило команды или начать менять форму, не разобравшись с данными. Ему нужны не только исходники, но и полезные материалы рядом с ними: документация, опыт команды, принятые правила и понятный порядок работы. Тогда он знает, где искать ответ, как применить найденное и чем проверить результат.

Каждая команда собирает в библиотечном корпусе LEM свой набор знаний под свои проекты: нужные версии платформы и библиотек, стандарты, спецификации, инструкции и наработки. Ниже покажем набор, который мы подготовили для своей работы с 1С и используем на практике. Это пример наполнения, а не готовый комплект библиотек в поставке LEM. Агент обращается к корпусу через MCP — интерфейс вызова инструментов. Поэтому один и тот же набор можно использовать при работе в EDT, другом редакторе или иной агентной среде с поддержкой MCP.

Подготовленный материал, а не выгрузка всего подряд

Полезным источником может быть открытое руководство, стандарт разработки, описание БСП или другого API, схема интеграции, внутренний регламент или собственный опыт команды. Мы готовим такие материалы для внутренней работы: сохраняем источник и его версию в отдельном Git-репозитории, а для поиска собираем компактные карточки в Markdown. История подготовки и служебные файлы остаются в репозитории, а не засоряют поисковый пакет. В самих карточках убираем повторы и навигационный шум, уточняем заголовки, поисковые слова, область применения, ссылки и версии. Важные правила и примеры сверяем с первоисточником.

Это не разовая ручная подготовка каждой страницы. Мы сделали инструменты, которые собирают материалы в нужный формат, помогают обновлять их при изменении источника и готовить отдельный выпуск для новой версии библиотеки или решения. После сборки карточки всё равно проходят редакторскую проверку. Сейчас, например, мы дорабатываем подготовку большой справки платформы: определяем, какие повторяющиеся заголовки и служебные ссылки убрать из краткой выдачи, сохранив полный исходный материал. Эта редакция ещё проходит проверку; работа по очистке корпуса продолжается.

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

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

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

Что загружено в наш рабочий набор

Это библиотеки, которые нашли применение в нашей работе над проектами 1С. Набор подбирался под наши задачи и показал себя полезным на практике. Он не предустановлен у каждого пользователя LEM: другая команда может собрать свой состав под свои конфигурации, правила и инструменты.

Библиотека или группа	Что в ней ищет агент	Зачем она нужна в задаче
Входная инструкция Guide и onec-workflow	Guide направляет агента к стартовому сценарию 00-search-route. В библиотеке лежат маршруты постановки требований, доработки, поиска ошибки, полного и разностного ревью, работы с расширением и передачи результата.	Агент узнаёт, какую библиотеку открыть следующей и когда переходить к фактическому коду. Guide подключается к инструкции агента в проекте; это не отдельный libraryId и не встроенная справка инструментов LEM.
onec-structure и onec-forms-reports	Устройство XML метаданных; формы, обработки, отчёты, СКД и макеты.	Помогают выбрать нужный объект и порядок правки, прежде чем менять исходники. Карточки адаптированы из закреплённого открытого набора 1C AI Development Kit с редакционной проверкой применимости.
onec-operations	Пакетный запуск, сборка CF/EPF, загрузка тестовой базы, обработка частичного результата и нейтральный цикл «исходник → сборка → тест → отчёт».	Агент получает проверяемую последовательность, а параметры среды команда задаёт сама. Использованы открытые материалы и документация 1С о пакетном режиме.
onec-quality	Уровни проверки, диагностика BSL/XML, ревью diff, покрытие изменённых строк и описание результата.	Агент заранее выбирает доступные проверки и отдельно пишет, какие не выполнял. Часть карточек подготовлена по открытым BSL Language Server, Coverage41C и v8-code-style; наличие карточки не означает, что эти программы установлены в проекте.
onec-bsp-recipes	Прикладные рецепты работы с БСП из закреплённого открытого 1c-ssl-skills.	Даёт кандидата на стандартное решение. Сигнатуру и наличие подсистемы всё равно нужно проверить в фактической поставке БСП проекта.
onec-smoke-tool	Инструкции к нашей небольшой тестовой обработке и выборочным smoke-проверкам.	Агент знает, когда годится короткий прогон и где взять шаблон. Сама EPF хранится в отдельном исходном проекте, а не внутри текстовой библиотеки.
onec-vanessa-add и onec-vanessa-runner	Первая библиотека объясняет, как писать и поддерживать тесты с Vanessa-ADD. Вторая описывает команды Vanessa Runner для сборки и запуска проверок.	Агент выбирает материал под нужный шаг: подготовить тест ADD или запустить проверку через Runner. Сами программы должны быть установлены в рабочей среде; библиотека с инструкцией их не устанавливает.
v8std	Стандарты разработки 1С и правила оформления решений.	Помогает проверить, соответствует ли предложенная реализация принятому стандарту, и сослаться на конкретное правило.
1c-platform	Справка платформы 1С в определённой версии: объекты, методы, свойства и условия их применения.	Агент сверяет вызов с документацией именно той версии платформы, на которой работает проект.
1c-platform-reference	Отдельная редакция справки платформы в карточках Markdown.	Помогает быстро найти нужный раздел, но у неё своя версия и источник; её нельзя молча смешивать с выдачей 1c-platform, даже если темы совпадают.
bsp-standard	Исходный код модулей БСП, процедуры, функции и их параметры.	Можно найти реальный метод и посмотреть его реализацию в выбранном выпуске БСП, а не полагаться на похожее название.
bsp-standard-full	Отдельная сохранённая редакция исходников БСП.	Даёт ещё один доступный корпус кода БСП. Агент указывает, по какой именно библиотеке и версии нашёл метод, и сверяет её с поставкой проекта.
bsp-docs-full	Документация БСП: назначение подсистем и правила использования.	Объясняет, когда и зачем применять механизм, найденный в коде; пример из справки проверяют на версии проекта.
bsp-errata	Известные исправления и уточнения к материалам БСП.	Помогает не повторить уже описанную ошибку и понять, действует ли уточнение для выбранного выпуска.

Отдельно у нас есть библиотеки с контрактами интеграций и схемами XSD. Они используются только внутри нашей организации как рабочий инструмент и не передаются третьим лицам.

Практики открытого OpenSpec мы адаптировали под задачи 1С и включили в onec-workflow. Например, агент использует шаблон требований к доработке: описывает цель, текущее и ожидаемое поведение, затрагиваемые объекты, ограничения и критерии приёмки.

Особое место занимает onec-workflow: это пошаговые маршруты для агента, а не справочник команд. Там есть шаблон требований и сценарии доработки, поиска дефекта, сборки, тестирования, ревью, работы с расширением и передачи результата. Стартовая инструкция Guide помогает распознать задачу и выбрать маршрут. Дальше карточка говорит, что уточнить у разработчика, какие библиотеки и версии открыть, какие факты и файлы собрать из проекта, каким инструментом воспользоваться, как проверить результат и что делать, если часть сведений недоступна.

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

Для небольших проверок у нас есть собственная шаблонная внешняя обработка среди проектов 1С. Библиотека onec-smoke-tool описывает её, а рабочий сценарий указывает, когда воспользоваться ею и как интерпретировать результат. Код обработки и инструкция — разные части набора. Там, где нужен более развитый пользовательский сценарий, команда выбирает подходящий инструмент и тестовую базу, например Vanessa Automation.

Как мы превращаем источник в полезную карточку

Работа с материалом проходит несколько шагов. Для сценарной карточки у нас есть редакционный шаблон: цель, применимость и версии, входные данные, последовательность, конкретные инструменты и параметры, поведение при частичном результате и критерий готовности. Ключевые слова помогают найти карточку, а ссылка и сведения о происхождении позволяют проверить её основание.

1. Выбираем источник и границы прав. Фиксируем автора, ссылку, версию и то, что разрешено хранить и показывать команде.
2. Выделяем применимую часть. Разделяем правило, пример, исключение и ссылку на первоисточник. Убираем навигационный шум, но не удаляем условие, меняющее смысл.
3. Редактируем и связываем. Даём понятный заголовок, теги, ссылки на смежные карточки, версию платформы или библиотеки и область применения.
4. Перепроверяем. Разработчик сверяет важные утверждения и ссылки с источником, проверяет терминологию и смотрит, не конфликтует ли карточка с уже принятым стандартом. Перед импортом проверяем структуру, ссылки, дубли, кодировку и целостность пакета; после него — выдачу на контрольных вопросах. Это контроль конкретного выпуска, а не пожизненный сертификат качества всех карточек.
5. Публикуем в нужной версии. LEM хранит координаты библиотеки, источника и версии; разные выпуски не должны превращаться в один безымянный результат. Редакция пакета и версия продукта, который она описывает, — разные вещи. Доступ к библиотеке и связь с проектом задаются отдельно.

Корпус может содержать подготовленный Markdown, код BSL, структурированные схемы и справку платформы. Для разных материалов в LEM предусмотрены разные способы импорта и индексации. Сам импорт ещё не доказывает, что инструкция верна для конкретной конфигурации: агент обязан проверить вызов и версию в проектном коде.

Как агент проходит задачу

Представим запрос: «Добавь учёт компетенций специалистов и отбор по ним в отчёте». Маршрут агента выглядит так:

1. Выбрать сценарий и уточнить задачу. Агент начинает с Guide и открывает сценарий доработки в библиотечном корпусе. Он выясняет, что в этой базе называют специалистом, кто ведёт компетенции, какие нужны права и какие отчёты затронуты. Для требований и критериев приёмки использует адаптированный шаблон из onec-workflow.
2. Изучить проект. По проектному корпусу LEM агент находит карточку физического лица, связанные формы и отчёты, существующие данные о компетенциях, расширения и связи конкретного снимка конфигурации. Затем открывает найденные исходные файлы и уточняет область изменения.
3. Выбрать решение и подготовить правку. Агент возвращается к библиотекам за применимыми стандартами, БСП и инструкциями, а к проектному корпусу — за фактическими местами изменения. Затем предлагает модель данных и область правки разработчику, уточняет решение и меняет код и метаданные.
4. Проверить изменение до выполнения. Агент показывает diff, проверяет доступные статические замечания, синтаксис, типы и затронутые связи. В отчёте разделяет выполненные проверки и то, что ещё требует запуска 1С.
5. Испытать поведение. Для отдельной функции может подойти небольшой тест с нашей шаблонной обработкой; для связки объектов — тесты Vanessa-ADD и запуск средствами Vanessa Runner, если они приняты и доступны в проекте. Для формы и отчёта нужен прогон в тестовой базе; при необходимости команда применяет сценарий проверки интерфейса, например с Vanessa Automation. Для важной логики можно посмотреть покрытие изменённых строк. Агент фиксирует фактические результаты, а не перечисляет тесты, которые только предложил.

Развёрнутый разбор этого примера готовим как отдельный материал.

Зачем нам детерминированный маршрут

Главная польза сценария — предсказуемый порядок работы. Для типовой задачи заранее известны входные вопросы, источники, шаги и проверки. Это мы и называем детерминированностью процесса: модель может предложить разные варианты кода, но не должна без объяснения пропустить выбор версии, обследование проекта или проверку результата. Такой маршрут особенно важен для локальных моделей и полезен сильным облачным агентам. Он сокращает блуждание и оставляет разработчику понятную цепочку: задача → источник и версия → место в проекте → правка → реально выполненные проверки.

Где заканчивается библиотека

Подготовленный корпус полезен и одиночному разработчику, и большой команде: у них различаются объём знаний и число пользователей, но вопрос «какой источник применим?» возникает в любой задаче. При этом библиотечный поиск не открывает за агента форму в EDT, не исполняет код 1С и не делает непроверенное изменение безопасным. Для ответственной доработки нужны ещё проектный контекст, рабочий инструмент разработчика и проверка результата.

Такой набор команда собирает для себя. LEM позволяет поддерживать его как версионированную и доступную по правам часть процесса, а не как папку ссылок, которую агент каждый раз читает заново.