Практикум. Codex + Unica: первая 1С-задача

Цель: увидеть на одной реальной задаче, что дают специализированные skills и типизированные инструменты 1С поверх обычного файлового поиска.

Официальные справочные страницы: Unica, каталог поддерживаемых задач и v8-runner.

Ориентир по времени: 60–90 минут. Это необязательный практикум для знакомства с инструментами Unica; его можно пропустить, если они тебе уже знакомы.

Результат

После практикума ученик:

• различает агент, плагин, skill и MCP-инструмент;
• умеет явно попросить Codex применить подходящий skill;
• проверяет, какой набор исходников выбрала Unica;
• получает логические адреса объектов 1С, а не только совпадения текста;
• понимает разделение ролей Codex, skills, MCP-инструментов и v8-runner;
• понимает, что skill направляет работу, но не принимает результат за разработчика.

Предварительные условия

• завершён первый час с Codex;
• Unica установлена по стартовому документу;
• после установки создана новая задача Codex;
• в корне проекта есть v8project.yaml с source-set demo83;
• информационная база по-прежнему не подключена к workspace.

Что добавила Unica

Без Unica Codex может читать XML и BSL обычными файловыми инструментами. Это полезная базовая способность, но агенту приходится самостоятельно восстанавливать предметный смысл из путей и текста. С Unica у него появляются:

• skills — инструкции, как решать конкретный класс 1С-задач;
• карта source-set — явное понимание, где лежит конфигурация или расширение;
• логические адреса вроде demo83:Document.РасходТовара;
• типизированное чтение и изменение метаданных;
• структурированный поиск BSL, сравнение и статическая валидация;
• отдельные контракты для форм, ролей, СКД, макетов, расширений и других структур 1С;
• доступ к справке платформы и стандартам как к именованным источникам;
• управляемый runtime-маршрут через встроенный v8-runner для последующих уроков.

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

Карта возможностей: что мы откроем по ходу курса

НАЙТИ → ПРОЧИТАТЬ → СРАВНИТЬ → СПЛАНИРОВАТЬ → ИЗМЕНИТЬ → ПРОВЕРИТЬ → ЗАПУСТИТЬ

Этап	Примеры возможностей	Когда используем
Найти	Объект по имени или синониму, метод, вызовы, строковый литерал	Уже сейчас
Прочитать	Реквизиты, табличные части, формы, модули, права, состав подсистемы	Уже сейчас
Сравнить	Два объекта или состояние до и после изменения	В контролируемом изменении
Спланировать	Preview правки без записи в файлы	Перед первым изменением
Изменить	Метаданные, BSL, формы, роли, расширения и другие структуры	Только после спецификации
Проверить	Читаемость, структура объекта, диагностика BSL, согласованность формата	После каждого изменения
Запустить	Загрузка, выгрузка, сборка, клиент и тестовые инструменты через runtime-слой	Только после safety-gate

Не нужно запоминать имена всех инструментов. Разработчик ставит задачу, Codex выбирает подходящий skill, а skill ведёт его по допустимой цепочке. Мы учимся читать план и результат этой цепочки, а не вручную изображать MCP-клиент.

Почему preview особенно важен

Предметные операции изменения в Unica разделяют preview и запись. Сначала агент вызывает ту же типизированную операцию в режиме dryRun, получает план, diff или другое описание результата без изменения файлов, затем разработчик проверяет скоуп и только после этого разрешает запись. Preview не резервирует файлы: если после него состояние проекта изменилось, план нужно построить заново. Перед записью мы проверяем Git, а после неё читаем фактический diff.

Это не заменяет git diff, но закрывает более раннюю границу:

словесное намерение
  → предметный preview Unica
  → разрешённая запись
  → фактический Git diff
  → специализированная проверка
  → человеческая приёмка

В этом практикуме мы останемся на первых двух безопасных ступенях — поиск и чтение.

Шаг 1. Проверяем установку в новой задаче

Спроси Codex:

Проверь доступность Unica в этой задаче. Ничего не изменяй.
Коротко объясни роли Codex, skills, MCP-инструментов Unica и v8-runner.
Покажи найденные source-set проекта и объясни, какой из них соответствует Demo83.
Если source-set demo83 не найден или не готов, остановись и назови точную причину.

Ожидается ровно один основной набор demo83 с путём src/configuration. Если Codex предлагает угадать другой путь, сначала исправь описание workspace, а не продолжай исследование.

Шаг 2. Явно подключаем skills

Передай задачу:

Используй skills $unica:meta-info, $unica:code-search и при необходимости
$unica:source-access.

Работай только на чтение с source-set demo83. Не изменяй файлы и не запускай
runtime-операции 1С.

Исследуй Document.Заказ и Document.РасходТовара:
1. подтверди их ключевые реквизиты и участие в вводе на основании;
2. найди обработчик заполнения РасходТовара по основанию Заказ;
3. проверь наличие типизированной ссылки РасходТовара на Заказ;
4. верни логические адреса объектов, пути и участки BSL;
5. раздели факты, выводы и вопросы.

После отчёта остановись.

Явное имя skill полезно в учебном задании: ученик видит выбранный способ работы. В обычной практике Codex может подобрать skill сам по описанию задачи, но разработчик всё равно проверяет фактические действия и доказательства.

Шаг 3. Сравниваем два исследования

Сравни два исследования по этой таблице:

Критерий	Обычный Codex	Codex + Unica
Как найден объект	По именам файлов и тексту	По source-set и логическому адресу
Как прочитаны реквизиты	Разбор XML агентом	Типизированное чтение метаданных
Как найден BSL	Текстовый поиск	Структурированный поиск с адресом объекта
Знает ли агент допустимые операции над объектом	Восстанавливает из файлов и инструкций	Получает предметный контракт и подходящий skill
Как готовится изменение	Произвольный план и файловая правка	Предметный preview, затем отдельная запись
Как перейти к платформе 1С	Самостоятельно собирать команды и их параметры	Через поддержанный runtime-маршрут и v8-runner
Можно ли проверить путь	Да	Да
Нужно ли проверять вывод человеком	Да	Да

Не требуется, чтобы второй ответ был длиннее. Он должен быть более адресным и воспроизводимым.

Шаг 4. Проверяем границу инструментов

Ответь своими словами:

1. Что доказал meta-info, а чего он не мог доказать без запуска базы?
2. Почему найденный обработчик ещё не доказывает полный runtime-сценарий?
3. Почему наличие skill не разрешает агенту менять метаданные?
4. Что произойдёт, если в v8project.yaml выбран неправильный source-set?
5. Почему v8-runner не означает, что агенту уже разрешено запускать 1С или менять базу?

Стоп-точка

В этом практикуме запрещены skills редактирования, создание расширения, загрузка в базу и runtime-команды. Мы сначала учимся осознанно применять инструменты чтения.

Условия завершения

• Unica видит source-set demo83;
• Codex применил специализированные skills в режиме чтения;
• в отчёте есть логические адреса и проверяемые пути;
• ученик сравнил обычный файловый поиск и типизированное исследование;
• Git не показывает изменений исходников;
• ученик может объяснить, зачем нужны Unica и v8-runner, почему они не заменяют приёмку и почему runtime требует отдельного допуска.

Дальше урок 2 закрепляет исследование на реальной задаче, а чек-лист Demo83 готовит базу к будущему runtime. Этот практикум не заменяет урок безопасности.