Песочница для ИИ‑агента под 1С (клиент + серверная инфраструктура)

Этот репозиторий — песочница под ИИ‑агента и инфраструктура, где агент работает с платформой 1С. Зачем это нужно? - Что бы ИИ-агент по ошибке вам что нито не удалил (например, весь диск D... или C) Думаете с Вами точно такого не случится? - Я тоже так думал. А потом потерял 10 лет семейных фото и пошел делать песочницу :)

Всё разделено на две части:

Клиентская часть (Dev Container): Linux‑контейнер с установленной платформой 1С для клиента (толстый/тонкий клиент, в т.ч. Конфигуратор) + “обвязка”, чтобы инструменты 1С стабильно работали в headless‑режиме.
Серверная часть (VM в Hyper‑V): отдельная Ubuntu VM, внутри неё Docker Compose со связкой 1С сервер + Postgres + Apache (веб‑публикации).
разработано под VSC/Cursor. Совместимпость с другими IDE не гарантирована

Архитектура (схема)

                        Windows host
┌───────────────────────────────────────────────────────────────────────────┐
│  Cursor / VS Code + Dev Containers                                        │
│  Docker Desktop                                                           │
│  Hyper‑V                                                                  │
└───────────────┬───────────────────────────────┬───────────────────────────┘
                │                               │
                │ Dev Container                 │ VM (Hyper‑V)
                v                               v
┌───────────────────────────────────┐   ┌──────────────────────────────────┐
│ Клиентская песочница (container)  │   │ Серверная часть (Ubuntu VM)      │
│                                   │   │                                  │
│  agent (Linux)                    │   │  docker + docker compose         │
│   - 1С клиент + Конфигуратор      │   │   - onec-server                  │
│   - Xvfb :99 (headless display)   │   │   - postgres                     │
│                                   │   │   - onec-web (Apache)            │
│   - community-активация КЛИЕНТА   │   │                                  │
│     (если заданы DEV_* креды)     │   │  Порты наружу: 1540/1541/1545,   │
│                                   │   │  1560-1591, 5432, 8080           │
│                                   │   └──────────────────────────────────┘
│  Volumes:                         │   
│   - workspace volume              │
│   - onec-licenses volume          │
│                                   │
│  Networking:                      │
│   - (опц.) docker network "infra" │
│   - /etc/hosts: onec-infra ->     │
│     management IP VM (если задан) │
└───────────────────────────────────┘

Связь: контейнер управляет/подключается к 1С‑серверу в VM по MGMT IP или имени onec-infra.

Ограничения

Хост‑окружение, где проверено: Windows (Hyper‑V + PowerShell) как хост для серверной части.
Linux‑хосты (KVM/QEMU/VirtualBox, бриджи/iptables и т.п.) не тестировались.

Быстрый старт

1) Серверная инфраструктура (Hyper‑V VM)

Сначала подними серверную часть — без неё клиентская песочница не сможет нормально подключаться к 1С‑серверу.

Подготовь non‑secret конфиг VM:
- скопируй infra/vm/.env.example → infra/vm/.env
- в основном можно оставить параметры по-умолчанию; обрати внимание на FORCE_RECREATE_VM (принудительно Пересоздает виртуальную машину) и на размер диска виртуальной машины.
Подготовь локальные секреты:
- скопируй secrets/.env.example → secrets/.env
- заполни нужные логин/пароли
Запусти скрипт развёртки из PowerShell от администратора: scripts/tests/SmokeTest-OnecInfra.ps1 и дождись успешного завершения (PASS).
Для удобства работы с сервером 1С с хост‑системы рекомендуется добавить запись в hosts, чтобы VM резолвилась по имени:
- <MGMT_VM_IP> onec-infra
- MGMT_VM_IP — management IP VM из infra/vm/.env
- (прим.: 192.168.254.2 onec-infra)

После успешной развёртки у тебя есть VM с Ubuntu + Docker и внутри неё подняты контейнеры onec-server, postgres и onec-web (Apache для веб‑публикаций).

Веб‑публикация (web‑клиент + HTTP‑сервисы)

pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\hyperv\Publish-OnecInfobase.ps1 -Action Publish -InfobaseName demo
pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\hyperv\Publish-OnecInfobase.ps1 -Action Update  -InfobaseName demo
pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\hyperv\Publish-OnecInfobase.ps1 -Action Unpublish -InfobaseName demo

По умолчанию Apache слушает ONEC_WEB_PORT_HOST=8080 (настраивается в infra/vm/.env).

Что делает скрипт развёртки (в общих чертах)

Серверный сценарий рассчитан на Windows‑хост и делает примерно так:

Берёт значения из secrets/.env и готовит Docker‑secrets файлы (без печати значений).
Скачивает официальный Ubuntu Server ISO, патчит его под autoinstall и использует уже пропатченный ISO для установки VM.
Создаёт VM в Hyper‑V, настраивает доступ по SSH и дожидается, пока VM станет доступна.
Загружает на VM нужные файлы и поднимает Docker Compose стек: 1С сервер + Postgres + Apache (веб‑публикации).
Дожидается health‑состояния 1С‑сервера и делает базовые проверки (порты/кластер).

Как запускать серверный сценарий

Запускать PowerShell от администратора. Скрипт развертки виртуальной машины тестировался под Power Shell 7 !!! (по умолчанию на винде вроде 5.1 стоит)

2) Клиентская песочница (Cursor/VS Code)

Требования:

Docker Desktop запущен
расширение Dev Containers (ms-vscode-remote.remote-containers)

Дальше так:

Перед первым запуском создай external volumes agent-work-sandbox-1c, onescript-cache-1c и onec-licenses:

powershell -ExecutionPolicy Bypass -File .\scripts\ensure-external-volumes.ps1

Если менялся список external volumes в .devcontainer/docker-compose.yml, просто запусти этот скрипт ещё раз перед следующим Rebuild Container.
Именованный volume agent-home-1c docker compose создаст сам.
Данные в volume (agent-work-sandbox-1c, onescript-cache-1c, onec-licenses, agent-home-1c) сохраняются при rebuild/recreate контейнера. Они удалятся только если удалить volume явно.
Открываешь Cursor/VS Code
Команда Dev Containers: Open Folder in Container и выбираешь папку этого репозитория
Откроется новое окно, уже подключённое к клиентскому контейнеру
Уже в новом окне делаешь File → Open Folder… и выбираешь рабочую папку конкретного проекта, с которым будет работать агент

Что настроено

Клиентская песочница сделана так, чтобы 1С‑инструменты работали предсказуемо внутри контейнера:

Headless display: поднимается Xvfb (некоторые режимы 1С требуют X‑сервера даже без UI).
Активация community‑лицензии клиента: при старте контейнера выполняется авто‑активация клиентской community‑лицензии, если заданы креды developer.1c.ru.
Лицензии не теряются: лицензии лежат в отдельном volume и переживают пересборку контейнера.
Маппинг имени VM внутрь контейнера: при старте может обновляться /etc/hosts, чтобы имя onec-infra указывало на management‑IP VM (если этот IP задан в локальной конфигурации инфраструктуры).
Анти‑футган для git: стоит pre‑push хук, блокирующий push прямо в main/master (чтобы случайно не убить публичный репо). В принципе не обязательно для 1С проектов, т.к. код регулярно бекапится "в базу" при запуске юнит-тестов (а для версионирования достаточно локального репо), но если нужно, то агенту выделяется отдельная ветка и хук запрещает пушить мейн ветку (только через PR)
CLI‑инструменты: внутри есть базовые утилиты (git, gh, docker cli и т.п.), чтобы агент мог работать “из коробки”.
OneScript/Vanessa не качаются заново на каждом rebuild: они кэшируются в отдельном volume и переиспользуются новым контейнером.

Секреты: единый источник истины

Источник истины — secrets/.env (локально, не коммитится).
Из него автоматически генерируются файлы secrets/*, которые уже используются как Docker secrets (/run/secrets/*).

Версия платформы 1С: один источник истины

Единый источник истины — infra/vm/.env (переменная ONEC_VERSION).
Серверная часть фиксируется на конкретной версии платформы, а клиентская песочница и прочие компоненты подхватывают ту же версию.

Обновление платформы 1С без пересоздания песочницы

Обновление платформы в этом репозитории делается не через развёртывание всего с нуля, а через пересборку контейнеров с новой версией платформы:

клиентский devcontainer пересобирается локально;
серверные контейнеры onec-server и onec-web пересобираются внутри уже существующей VM;
сама VM, её ОС, Docker volumes Postgres/1С и лицензии при штатном обновлении не пересоздаются.

Важно

Для сценария обновления существующей VM параметр FORCE_RECREATE_VM в infra/vm/.env должен быть строго false.
Если поставить FORCE_RECREATE_VM=true, вместо обновления платформы можно получить пересоздание виртуальной машины с нуля.
Для обновления платформы не использовать ResetOnecData и ResetPgData: эти режимы предназначены для сброса данных, а не для обычного апгрейда.

Подготовка

Положи дистрибутив новой версии платформы в .devcontainer/distr/: setup-full-<ONEC_VERSION>-x86_64.run
Измени ONEC_VERSION в infra/vm/.env.
Проверь, что в infra/vm/.env задано: FORCE_RECREATE_VM=false
Перед апгрейдом сделай backup/снимок:
- checkpoint/backup VM;
- backup баз Postgres;
- при необходимости backup docker volumes vm_pgdata, vm_onec-data, vm_onec-licenses.

Порядок обновления

Останови активные сеансы и фоновые работы, которые используют сервер 1С.
Обнови серверную часть в уже существующей VM:

pwsh -NoProfile -ExecutionPolicy Bypass -File .\scripts\hyperv\Deploy-OnecInfra.ps1 -VmIp <MGMT_VM_IP> -SshIdentityFile .\.cache\hyperv\_ssh\onec-infra\id_ed25519

Этот сценарий копирует актуальные файлы в существующую VM и запускает infra/vm/up.sh, который выполняет docker compose up -d --build. При штатном запуске это означает пересборку контейнеров onec-server / onec-web на новой платформе без пересоздания VM и без удаления volumes.

Если VM была создана штатными Hyper-V скриптами этого репозитория, для воспроизводимого запуска лучше явно передавать -SshIdentityFile и использовать repo-managed ключ:

.\.cache\hyperv\_ssh\onec-infra\id_ed25519

Без явного ключа PowerShell/SSH может попытаться использовать другой профиль/ключ пользователя и Deploy-OnecInfra.ps1 завершится на preflight-проверках подключения к VM.

Проверь сервер после обновления:
- контейнер onec-server в состоянии healthy;
- rac cluster list отрабатывает;
- базы открываются;
- web-публикации отвечают, если используются.
После успешной проверки сервера пересобери клиентский devcontainer:
- в VS Code / Cursor: Dev Containers: Rebuild Container.
Проверь клиент:
- платформа открывается;
- подключение к серверу работает;
- Конфигуратор / толстый клиент / пакетные вызовы стартуют на новой версии.

Что при этом сохраняется

VM в Hyper-V;
Ubuntu внутри VM;
Docker volumes серверной части (pgdata, onec-data, onec-logs, onec-licenses, onec-web-data);
Docker volumes клиентской части (agent-work-sandbox-1c, onescript-cache-1c, onec-licenses, agent-home-1c).

Что не нужно делать для обычного апгрейда

не пересоздавать VM вручную;
не включать FORCE_RECREATE_VM=true;
не запускать сценарии с очисткой volumes;
не удалять volumes Docker клиентской и серверной части.

Что обычно лежит в secrets/.env:

releases.1c.ru (ONEC_USERNAME, ONEC_PASSWORD) — нужно только если сборка должна скачать дистрибутив платформы (когда локального установщика нет).
developer.1c.ru (DEV_LOGIN, DEV_PASSWORD) — включает авто‑активацию community‑лицензии (и в клиентской песочнице, и на сервере, если ты это включаешь).
Postgres (PG_PASSWORD) — опционально. Если не задан, пароль генерируется один раз и сохраняется, чтобы деплой был воспроизводимым.

Шаблоны репозиториев

В templates/ лежат “seed”‑шаблоны, чтобы быстро стартовать новый репозиторий под проект/агента на базе этой песочницы.

AI-инструменты

Claude Code — `cc` / `сс`

Запускается через wrapper ~/bin/claude-safe.sh. Настройки берутся из .devcontainer/.env и секрета cc_api_key.

Настройка 9Router для Claude Code

Claude Code обращается к моделям по фиксированным именам: opus, sonnet, haiku. В 9Router нужно создать Combo с точно таким именем, и прописать в него один или несколько реальных бэкендов. Через файл конфига можно принудительно переопределить имена моделей, но на мой взгляд работа через Комбо удобнее.

Combo name	Что подставить
`opus`	В идеале модели Opusa из разных доступных вам подписок. На крайний случай любую "топовую")
`sonnet`	Аналогично. Собираем сюда Соннетов из всех подписок
`haiku`	Любые быстрые дешевые модели приемлимого качества

В Combo можно указать любой провайдер, однако наиболее стабильное поведение достигается с оригинальными моделями Anthropic — Claude изначально обучен управлять инструментами и форматировать вывод в своём нативном формате.

Codex CLI — `cx` / `сч`

Запускается через wrapper ~/bin/codex-safe.sh. При старте контейнера скрипт codex-bootstrap.sh генерирует ~/.codex/config.toml с профилями моделей.

Алиасы cc/сс и cx/сч — латиница и кириллица соответственно, оба варианта работают.

Настройка Codex для работы с 9Router

Codex использует кастомный список моделей, который bootstrap собирает из двух источников:

1. codex-model-map.json — маппинг на официальные модели Codex

Сопоставляет имена в 9Router (cx/*) с оригинальными slug-ами из официального репозитория Codex. Благодаря этому bootstrap заполняет метаданные модели (контекстное окно, описание, возможности) так же, как в оригинале.

{
  "cx/gpt-5.3-codex": "codex-1",
  "cx/gpt-5.1-codex-mini": "codex-mini-latest"
}

2. codex-model-overrides.json — ручные описания для моделей без upstream

Для моделей, которых нет в официальном списке (например ag/gemini-3.1-pro-high), поля задаются вручную. Описание всех полей: docs/codex-model-catalog-fields.md

Системный промт для Gemini

Для моделей, в имени которых содержится gemini, bootstrap при старте контейнера скачивает системный промт напрямую из официального репозитория Codex:

codex-rs/core/prompt_with_apply_patch_instructions.md

Настройка Codex для работы с 9Router

Gemini CLI поддерживает работу с фиксированным набором моделей (только свои). Через настройки в .devcontainer\.env их можно переопределить на любые нужные (наприм. ag/gemini-3.1-pro-high), а можно создать Комбо и переопределить на их названия.

Переменные окружения `.devcontainer/.env`

Переменная	Назначение
`OPENAI_BASE_URL`	URL 9Router (или другого прокси)
`CODEX_MODEL`	Модель по умолчанию для Codex
`CODEX_MODELS`	Список моделей → генерирует профили в `config.toml`
`CODEX_MODEL_PROVIDER_ID/NAME`	Имя провайдера в Codex UI
`CODEX_MODEL_MAP_FILE`	JSON с маппингом `cx/*` → upstream slug
`CODEX_MODEL_OVERRIDES_FILE`	JSON с ручными описаниями моделей (`ag/*` и др.)
`CODEX_GEMINI_PROMPT_FILE`	Системный промт для моделей Gemini

Улучшения

криво работает очистка папки кеш. не всегда удаляет старые образы после создания нового (или вообще не удаляет?)
протестить сборку на линукс окружении (не тестировалось, разрабатывалось под windows)

Name		Name	Last commit message	Last commit date
Latest commit History 43 Commits
.cursor/rules		.cursor/rules
.devcontainer		.devcontainer
infra/vm		infra/vm
onec-client		onec-client
scripts		scripts
secrets		secrets
templates/repo-seed		templates/repo-seed
.dockerignore		.dockerignore
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Repository files navigation

Песочница для ИИ‑агента под 1С (клиент + серверная инфраструктура)

Архитектура (схема)

Ограничения

Быстрый старт

1) Серверная инфраструктура (Hyper‑V VM)

Веб‑публикация (web‑клиент + HTTP‑сервисы)

Что делает скрипт развёртки (в общих чертах)

Как запускать серверный сценарий

2) Клиентская песочница (Cursor/VS Code)

Что настроено

Секреты: единый источник истины

Версия платформы 1С: один источник истины

Обновление платформы 1С без пересоздания песочницы

Важно

Подготовка

Порядок обновления

Что при этом сохраняется

Что не нужно делать для обычного апгрейда

Шаблоны репозиториев

AI-инструменты

Claude Code — `cc` / `сс`

Codex CLI — `cx` / `сч`

Переменные окружения `.devcontainer/.env`

Улучшения

About

Uh oh!

Releases

Packages

Uh oh!

Contributors

Uh oh!

Languages

Folders and files

Latest commit

History

Repository files navigation

Песочница для ИИ‑агента под 1С (клиент + серверная инфраструктура)

Архитектура (схема)

Ограничения

Быстрый старт

1) Серверная инфраструктура (Hyper‑V VM)

Веб‑публикация (web‑клиент + HTTP‑сервисы)

Что делает скрипт развёртки (в общих чертах)

Как запускать серверный сценарий

2) Клиентская песочница (Cursor/VS Code)

Что настроено

Секреты: единый источник истины

Версия платформы 1С: один источник истины

Обновление платформы 1С без пересоздания песочницы

Важно

Подготовка

Порядок обновления

Что при этом сохраняется

Что не нужно делать для обычного апгрейда

Шаблоны репозиториев

AI-инструменты

Claude Code — cc / сс

Codex CLI — cx / сч

Переменные окружения .devcontainer/.env

Улучшения

About

Resources

License

Uh oh!

Stars

Watchers

Forks

Releases

Packages 0

Uh oh!

Contributors

Uh oh!

Languages

Claude Code — `cc` / `сс`

Codex CLI — `cx` / `сч`

Переменные окружения `.devcontainer/.env`

Packages