Wizard для 1С и Cursor: настройка проекта и проверка на «Нано-УТ»

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

Для вас, дорогие Коллеги, я придумала и создала setup-wizard.ps1 - автоматический скрипт, который собирает такое рабочее место в пустой папке, чтобы коллегам не приходилось повторять эти настройки вручную. В статье разберу, как он работает и что проверяет. Затем подключим мою учебную «Нано-УТ», отделим проверку окружения от проверки прикладной логики и доведём отдельную базу до простого сценария: поступление десяти единиц, продажа трёх и остаток семь.

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

Материал подготовлен по локальным прогонам 16 октября 2026 года. Исходники, скрипты и журналы собраны в файле-компаньоне (1 SM).

Что делает wizard

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

В интерфейсе Cursor остаётся включить MCP-сервер и проверить вызов инструмента агентом. Сам мастер также умеет вызвать env_status через MCP-сервер после появления IPC-порта. Это полезная проверка транспорта, но она не доказывает, что агент редактора получил разрешение пользоваться инструментами.

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

Перед первым запуском

Локально использовались Windows, платформа 1С 8.3.27.2130, Cursor 3.25.6, Node.js 24.18.0, OneScript 2.2.1 и расширения:

• yellow-hammer.1c-platform-tools - 0.9.14;
• yellow-hammer.mcp-1c-platform-tools - 0.3.1;
• 1c-syntax.language-1c-bsl - 2.1.2.

Эти номера описывают проверенное окружение; совместимость с другими версиями не обещана. Штатные тесты wizard выполнены в Windows PowerShell 5.1 и PowerShell 7.

Первые четыре команды показывают, доступны ли необходимые программы в текущем терминале:

1
2
3
4

Get-Command cursor
Get-Command node
Get-Command git
Get-Command oscript -ErrorAction SilentlyContinue

Платформу мастер ищет в стандартных каталогах установки, в том числе в Program Files (x86). Для нестандартного расположения предусмотрен -PlatformExe.

OneScript мастер самостоятельно не устанавливает. Если он отсутствует, в отчёте будет подсказка. Если OneScript и opm доступны, а vrunner ещё нет, мастер может выполнить opm install vanessa-runner. В наших текущих прогонах инструменты и расширения уже были установлены; повторную установку отсутствующих компонентов этими прогонами мы не проверяли.

Запуск на пустой базе и на существующей «Нано-УТ»

В приложенном комплекте скрипт находится в каталоге wizard. Следующие команды выполняются из корня распакованного комплекта.

Вариант 1. Пустая папка и новая база

1
2
3

powershell -NoProfile -ExecutionPolicy Bypass `
  -File .\wizard\setup-wizard.ps1 `
  -Project C:\work\nano-ut-empty

Мастер задаст вопросы. Если базу не указать и принять предложенный вариант, он создаст новую файловую базу в build/ib внутри проекта. Для автоматического запуска используется -Yes:

1
2
3

powershell -NoProfile -ExecutionPolicy Bypass `
  -File .\wizard\setup-wizard.ps1 `
  -Project C:\work\nano-ut-empty-auto -Yes

Это уже рабочий каркас, но конфигурация в нём пустая. В локальных прогонах пустой базы doctor показал 12 OK, а синтаксический контроль завершился без ошибок. BSL-модулей было ноль, поэтому такой результат подтверждает настройку окружения, но ничего не говорит о торговой логике.

Перед реальным запуском можно посмотреть план:

1
2
3

powershell -NoProfile -ExecutionPolicy Bypass `
  -File .\wizard\setup-wizard.ps1 `
  -Project C:\work\nano-ut-plan -DryRun

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

Вариант 2. Пустая папка проекта и существующая база

Исходная «Нано-УТ» уже была зарегистрирована в списке баз:

Здесь нужно различать пустую папку проекта и пустую информационную базу. Папку мы создаём заново, а метаданные берём из существующей базы:

1
2
3
4
5

powershell -NoProfile -ExecutionPolicy Bypass `
  -File .\wizard\setup-wizard.ps1 `
  -Project C:\work\nano-ut-source `
  -IbConnection C:\bases\nano-ut `
  -Yes -SkipMcpCheck

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

-SkipMcpCheck здесь выбран явно: сначала проверяем подготовку проекта и выгрузку, а интерактивную связку с Cursor проверяем отдельно. Этот ключ пропускает шаг 10, сохраняя создание .cursor/mcp.json.

Фактический результат подключения исходной «Нано-УТ»:

• выгружены два справочника, один документ и три общих модуля;
• найдено шесть файлов BSL, включая пустые модули объектов справочников;
• синтаксических ошибок не обнаружено;
• doctor: 12 OK, предупреждений и ошибок нет;
• шаг 9 - «ВРУЧНУЮ», шаг 10 - «ПРОПУЩЕН» по переданному ключу.

Полный вывод - в журнале выгрузки существующей базы (evidence/wizard-existing-base.txt).

Что появилось в каталоге

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

nano-ut-source/
  .cursor/
    mcp.json
    rules/
  .vscode/
    settings.json
    tasks.json
  src/cf/
    Configuration.xml
    Catalogs/
    Documents/
    CommonModules/
  build/
    setup-wizard-report.txt
  autumn-properties.json
  packagedef
  doctor.ps1
  .gitignore
  .gitattributes
  .bsl-language-server.json

src/cf - выгрузка конфигурации для изучения и редактирования. Это не копия данных исходной базы: элементы справочников и документы таким способом не переносятся.

autumn-properties.json - профиль, по которому инструменты понимают, с какой базой работать. Для существующей базы wizard записал:

1
2
3
4
5
6
7
8
9
10
11
12

{
  "vrunner": {
    "ibconnection": "/FC:\\bases\\nano-ut",
    "db-user": "",
    "db-pwd": "",
    "root": ".",
    "workspace": ".",
    "v8version": "8.3.27.2130",
    "locale": "ru",
    "language": "ru"
  }
}

Для новой базы строка другая: /F./build/ib. Перед загрузкой конфигурации или изменением данных стоит открыть профиль и проверить именно эту строку: в одном случае он указывает на исходную базу, в другом - на новую учебную.

Настройки IPC находятся в .vscode/settings.json:

1
2
3
4

{
  "1c-platform-tools.ipc.enabled": true,
  "1c-platform-tools.ipc.port": 40241
}

Мастер также копирует настройки кодировок и окончаний строк для BSL. В .cursor/mcp.json он указывает установленный index.js MCP-расширения и переменные окружения канала IPC. Если в пользовательских настройках найден токен, wizard переносит его в конфигурацию MCP и добавляет этот файл в .gitignore.

packagedef описывает проект для инструментов OneScript. Само его наличие не доказывает, что все внешние зависимости установлены.

Правила .cursor/rules задают агенту порядок работы: читать метаданные перед использованием объектов, проверять изменения синтаксическим контролем и учитывать ограничения операций с базами.

Как читать итоговый отчёт

Постоянный результат мастера находится в build/setup-wizard-report.txt. Он полезнее отдельного сообщения «завершено», поскольку показывает статус каждого шага.

Код возврата 0 допускает шаги «ВРУЧНУЮ» и «ПРОПУЩЕН». Его нельзя трактовать как подтверждение всей цепочки от агента до базы.

Повторную диагностику запускают из созданного проекта:

1

powershell -NoProfile -ExecutionPolicy Bypass -File .\doctor.ps1

Doctor проверяет двенадцать точек окружения. Например, он находит файл MCP-сервера, проверяет настройки IPC, наличие XML конфигурации, Git и правил агента. Но doctor не проводит поступление или продажу и не проверяет бизнес-логику.

Мастер не принимает непустую папку без -AllowNonEmpty. Такой повторный запуск разрешён явно, однако он не превращается в синхронизацию проекта: существующие файлы мастер сохраняет. Изменение строки подключения при повторном запуске требует отдельно проверить фактический профиль, поскольку уже существующий файл не будет автоматически заменён.

Доводим связь Cursor → MCP → платформа

В текущей версии мастера проект открывается командой:

1

cursor --classic C:\work\nano-ut-source

Мастер использует классическое окно, в котором должны запускаться расширения. После открытия нужно убедиться, что рабочая папка доверенная: установленное расширение Platform Tools в ограниченном режиме не открывает канал для агентов.

Далее:

1. Проверьте, что активен именно нужный проект и его autumn-properties.json.
2. В настройках Cursor откройте раздел MCP и включите сервер проекта из .cursor/mcp.json. В версиях интерфейса, описанных комплектом, это Customize → MCPs.
3. Проверьте появление IPC-порта:

1

   Test-NetConnection 127.0.0.1 -Port 40241

1. Попросите агента: «Вызови env_status и покажи активный профиль, файл настроек и строку подключения к базе».
2. Сопоставьте ответ с учебной базой, прежде чем просить изменить конфигурацию или данные.

Открытый порт ещё не доказывает, что он принадлежит нужному окну и проекту. Поэтому просмотр профиля в ответе env_status - отдельный шаг проверки.

В наших двух реальных прогонах пустого проекта wizard дождался окончания заданных 30 секунд, но IPC-порт не появился. Шаг 10 остался «ВРУЧНУЮ». Процессы Cursor были запущены; причина отсутствия порта по собранным журналам не установлена. В прогоне существующей «Нано-УТ» этот шаг отключался явно.

Это ограничение не помешало выгрузке конфигурации, проверке модулей и последующим операциям через платформу. Однако утверждать, что торговый сценарий был выполнен агентом Cursor через MCP, по этим результатам нельзя: он выполнен отдельным интеграционным тестом через COM-соединение.

На заключительном прогоне порт уже слушался. Мы отдельно вызвали env_status тем же клиентским кодом, который использует wizard, с MCP-конфигурацией нового проекта nano-ut-repro-final. Сервер ответил «Успех», но в поле «Проект» оказался другой каталог - local-wizard-ps51, открытый предыдущим прогоном. Журнал - mcp-env-status.txt (evidence/mcp-env-status.txt).

Позже мы повторили связку на свежем проекте. Собрали его командой build-demo.ps1 в пустой папке, открыли в Cursor 3.25.6 (--classic), дождались порта 40241 и включили сервер командой cursor-agent mcp enable mcp-1c-platform-tools. Консольный агент Cursor (cursor-agent -p --force --approve-mcps) вызвал env_status, и в поле «Проект» оказался каталог этого проекта. Затем он вызвал syntaxCheck_run: платформа проверила основную конфигурацию и расширения за 30,3 с, итог - «Ошибок не обнаружено». Полный журнал этого прогона в архив комплекта не входит. Этот прогон шёл в консольном агенте, окно чата Cursor мы не запускали, а торговый сценарий агент через MCP не проводил: он по-прежнему выполняется отдельным тестом через COM.

Первый ответ с чужим каталогом остаётся поводом проверять не только статус ответа. При нескольких окнах с одинаковым IPC-портом нужно развести порты в настройках соответствующих проектов и MCP-конфигурациях либо оставить нужный экземпляр сервера. Затем снова вызвать env_status и сверить полный каталог проекта. В исследованной версии мастер вызывает инструмент без указания projectPath, поэтому сам ответ без ошибки эту сверку не заменяет.

Что на самом деле было в исходной «Нано-УТ»

Название базы могло создать впечатление готовой маленькой торговой системы. Выгрузка показала более узкую задачу исходного демо: «Нано-УТ (демо для Analyzer 1C)», версия 1.0.0.1.

В ней были:

• справочник Контрагенты с ИНН;
• справочник Номенклатура с артикулом;
• ЗаказКлиента: контрагент и строки товаров с количеством и ценой;
• модули ПродажиСервер, СкладСервер, ЦеныСервер.

Документов поступления и продажи, а также регистра складских остатков в исходной конфигурации не было. В модуле цен содержался комментарий о намеренной кольцевой зависимости для демонстрации Analyzer:

ЗаказКлиента → ПродажиСервер → СкладСервер → ЦеныСервер
                        ↑                      |
                        ^92;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^72;^96;

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

Исходная база оставлена источником конфигурации. Для торгового примера создана новая база с её метаданными, без переноса исходных пользовательских данных.

От каркаса к первой торговой операции

В отдельную учебную конфигурацию добавлены документы ПоступлениеТовара и ПродажаТовара. В обоих есть контрагент, табличная часть Товары и итог документа. Строка содержит номенклатуру, количество, цену и сумму.

Сумма рассчитывается при записи:

1
2
3
4
5

СуммаДокумента = 0;
Для Каждого Строка Из Товары Цикл
    Строка.Сумма = Окр(Строка.Количество * Строка.Цена, 2);
    СуммаДокумента = СуммаДокумента + Строка.Сумма;
КонецЦикла;

В этой версии нет накопительного регистра. Остаток вычисляется по всем проведённым поступлениям и продажам:

Остаток товара = количество в проведённых поступлениях
              − количество в проведённых продажах

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

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

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

Заказ клиента после удаления демонстрационного цикла проверяет доступность товаров, но не меняет остатки и не создаёт резерв. В документах цены вводятся явно; автоматического прайс-листа в этом примере нет.

Как собрать пример в новой папке

В приложении находятся готовые исходники учебной версии и сборочный скрипт. Он принимает только новую пустую папку, запускает wizard, загружает конфигурацию из sources/trade, обновляет новую базу, проверяет синтаксис и выполняет торговый тест:

1
2
3
4

pwsh -NoProfile -ExecutionPolicy Bypass `
  -File .\build-demo.ps1 `
  -Project C:\work\nano-ut-trade `
  -PlatformExe "C:\Program Files (x86)\1cv8\8.3.27.2130\bin\1cv8.exe"

Укажите установленный у вас исполняемый файл платформы. Для учебной конфигурации использован режим совместимости 8.3.27. COM-тест в комплекте рассчитан на зарегистрированный 32-разрядный V83.COMConnector, соответствующий локальному стенду.

Скрипт сборки приложен к статье и в wizard не входит. Его загрузка конфигурации направлена только в созданную внутри проекта build/ib.

Для быстрого знакомства приложена также выгрузка nano-ut-demo.dt с демонстрационными данными. Её можно загрузить через Конфигуратор в отдельную новую учебную базу. Этот вариант показывает готовый результат, а сборка из исходников выше воспроизводит весь путь подготовки.

Проверяем операцию

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

В конце тест восстанавливает основной сценарий: проведённое поступление 10 и продажа 3, остаток 7.

Для знакомства через интерфейс откройте новую базу:

1
2

& "C:\Program Files (x86)\1cv8\8.3.27.2130\bin\1cv8.exe" `
  ENTERPRISE /F "C:\work\nano-ut-trade\build\ib"

Через стандартные команды «Все функции»/«Функции для технического специалиста» откройте списки ПоступлениеТовара и ПродажаТовара. Название команды зависит от интерфейса платформы. Автоматически создаваемые платформой формы используют добавленные реквизиты; отдельные прикладные формы для статьи не разрабатывались. Суммы пересчитываются при записи; при редактировании ячейки они сразу не обновляются.

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

Остаток можно проверить запросом. Параметр Товар - ссылка на созданную номенклатуру:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

ВЫБРАТЬ
    ЕСТЬNULL(СУММА(Данные.Количество), 0) КАК Остаток
ИЗ
    (ВЫБРАТЬ
        Т.Номенклатура КАК Номенклатура,
        Т.Количество КАК Количество
    ИЗ Документ.ПоступлениеТовара.Товары КАК Т
    ГДЕ Т.Ссылка.Проведен

    ОБЪЕДИНИТЬ ВСЕ

    ВЫБРАТЬ Т.Номенклатура, -Т.Количество
    ИЗ Документ.ПродажаТовара.Товары КАК Т
    ГДЕ Т.Ссылка.Проведен) КАК Данные
ГДЕ Данные.Номенклатура = &Товар

Этим независимым запросом тест сверяет результат с ответом функции прикладного модуля.

Какие проверки выполнены

В исходном прогоне штатные тесты wizard дали по 19 успешных проверок. При повторной подготовке статьи в PowerShell 5.1 и PowerShell 7 получено по 18 успешных проверок, 0 проваленных и 1 пропущенной: порт 40241 уже был занят, поэтому тест отсутствующего IPC не выполнялся. Это ограничение отражено в новых журналах. Они покрывают создание файлов, формат MCP-конфигурации, отказ на непустой папке, сохранение существующих файлов, -DryRun, выбор версии расширения и обмен с поддельным MCP-сервером.

Тесты doctor дали по 5 из 5. У этого тестового скрипта есть особенность: дочерний doctor предпочитает pwsh, если он установлен, даже когда сам тест запущен из PowerShell 5.1. Работа doctor непосредственно в 5.1 дополнительно проверялась реальным запуском мастера в этой оболочке.

Торговый тест выполняется через COM-соединение с новой учебной базой и проверяет реальные записи и запросы. Итог - 25 успешных проверок, включая отказ при нехватке, повторяющихся строках, пустом документе, отсутствии контрагента или товара, нулевом и отрицательном количестве, некорректной цене, изменении и отмене документов. Отдельная регрессия проверяет обычную запись уже проведённого документа.

Журналы позволяют проверить утверждения статьи:

• тесты wizard в 5.1 (evidence/wizard-ps51.txt) и PowerShell 7 (evidence/wizard-pwsh.txt);
• тесты doctor в 5.1 (evidence/doctor-ps51.txt) и PowerShell 7 (evidence/doctor-pwsh.txt);
• первоначальное отсутствие торгового документа (evidence/trade-red.txt);
• регрессия обычной записи проведённого документа (evidence/trade-review-red.txt);
• итоговый торговый прогон (evidence/trade-green.txt);
• синтаксический контроль (evidence/syntax-trade.log);
• сборка из приложения в новой папке (evidence/reproduction.txt).

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

Итог

Для нового проекта начинайте с -DryRun, затем запускайте wizard в пустой папке. Для существующей конфигурации передайте её базу через -IbConnection и сначала изучите полученную выгрузку. Перед изменениями проверьте профиль подключения и подготовьте отдельную учебную базу.

После настройки нужны три разных подтверждения: doctor проверяет окружение, платформа проверяет синтаксис, а прикладной сценарий проверяет данные и поведение. Wizard снимает повторяющуюся настройку и делает её результат видимым в отчёте. На примере «Нано-УТ» это позволило перейти от пустой папки к исходникам, обнаружить демонстрационную рекурсию и проверить первые торговые операции в отдельной базе.

Повторная сборка из архива в новой папке дала тот же результат: 25 успешных торговых проверок и 12 OK doctor. Журнал повторения: evidence/cms-reproduction.txt в архиве. Учебный расчёт по документам пригоден для разбора сценария; складской учёт под нагрузкой этим опытом не проверялся.

 

Нинель Адольевна Щербакова (Ninel_S)

Архитектор • SRE & DevOps инженер • HighLoad 1С

Автор 70 публикаций на Infostart. Разработчик NOPik, SRE-Suite-for-1C и мультиагентных ассистентов для экосистемы 1С:Предприятие.

Каталог статей и открытых репозиториев Ninel_S