1c-rules — набор правил и инструментов разработки на 1С для ИИ-агентов

Концепт работы: Mode × Quality × Orchestration × UI

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

1. Режим работы — Mode

Режим определяется запросом и риском задачи; его можно задать словами. Он описывает результат работы:

• Документация (docs-fix) — изменить текст и проверить структуру, ссылки и согласованность.
• Спецификация (spec-authoring) — подготовить требования, сценарии и план OpenSpec, подтвердить конкретные факты 1С. Реализация начинается отдельным этапом apply.
• Аналитика — исследовать вопрос, объяснить поведение, сравнить решения или подготовить рекомендации без изменения исходников. Это сценарий работы по запросу, отдельного значения в triage пока нет.
• Быстрый фикс (quick-fix) — одна небольшая локальная правка: короткий план → изменение → применимые проверки.
• Полный цикл (full-cycle) — требования и план → реализация → проверка результата → ревью → сверка Definition of Done.

Агент повышает быстрый фикс до полного цикла при существенном риске: например, затронуты проведение, транзакции, публичные контракты или права. Название режима не отменяет эти условия. Отдельной команды /mode сейчас нет; действующий выбор описан в AGENTS.md.

2. Уровень качества — Quality

Уровень задаёт глубину проверки кода через /sdlc lite|standard|full и VERIFICATION_DEPTH:

• lite — синтаксис для быстрого фикса; синтаксис и анализ кода для полного цикла.
• standard — по умолчанию: синтаксис и анализ для быстрого фикса; дополнительно MCP-ревью кода для полного цикла.
• full — вся цепочка статических валидаторов для изменённого BSL, с увеличенным бюджетом подтверждения после исправлений.

Это глубина проверок, не effort модели и не выбор режима работы. full и full-cycle — разные настройки. Риск переводит задачу в полный цикл с бюджетом повторов full; набор валидаторов остаётся по выбранному уровню. Проверки XML, влияния изменений, результата в ИБ и финальное ревью выполняются по своим условиям. Синтаксис изменённого BSL обязателен при любом уровне; явный запрос ревью добавляет соответствующую проверку. Точная матрица — verification-policy.md.

/sdlc status показывает состояние; /litemode on|off — совместимые сокращения для lite|standard. Отдельной команды /quality сейчас нет. Ни одна из этих команд не меняет UI-политику.

3. Уровень оркестрации — Orchestration

• standard — по умолчанию: головной агент выполняет небольшие задачи сам, а крупные и независимые части делегирует по правилам.
• economy — головной агент сохраняет решения, спецификации и итоговую проверку, чаще передаёт исполнение субагентам. Самостоятельные правки документации и быстрые фиксы остаются у головного агента.

Управление: /economymode on|off|status; on задаёт ORCHESTRATION=economy, off возвращает standard. /economymode models настраивает ярусы coding / analysis / light через SUBAGENT_MODEL_*. Заданные модели применяются при делегировании в обоих режимах, если клиент поддерживает и фактически применяет этот выбор; сами настройки моделей не включают economy. При наследовании модели головного агента экономия стоимости не гарантирована. Изменение моделей требует обновить установленные определения субагентов, иногда — перезапустить клиент.

Оркестрация не меняет Quality, UI-политику или критерии готовности. Любой уровень качества сочетается с обоими режимами оркестрации.

4. UI-тесты — отдельный переключатель

/uitests управляет UI_TESTING:

• /uitests essential — по умолчанию: после доработки и обновления dev/test-базы автоматически проверять в интерфейсе только важные новые и изменённые возможности задачи; остальное — по запросу.
• /uitests on (или auto) — автоматически выполнять все применимые UI-сценарии при готовой разрешённой dev/test-среде и инструментах.
• /uitests manual — выполнять UI-тесты только по явному запросу.
• /uitests off — отключить UI-тесты.
• /uitests visible / hidden — окно тест-клиента 1С при проверках через QA MCP (MCP_QA_CLIENT_VISIBLE): видимое по умолчанию или на скрытом рабочем столе; при ошибке или просьбе показать клиент перезапускается видимым.
• /uitests status — показать состояние и источник настройки.

Основной путь UI-проверок — QA MCP (подключение 1c-qa, навык 1c-qa-testing): он управляет формами тонкого клиента через механизм тестирования платформы и читает их структуру, без скриншотов. Запуск тест-клиента, видимое или скрытое окно, скриншоты, Windows-MCP и подтверждение данных через 1c-data-mcp описаны в правиле qa-testclient. Веб-клиент через браузер — запасной путь и путь для особенностей самого веб-клиента. TOOL_QA=off отключает QA MCP, не отключая UI-проверки вообще.

Переключение само по себе не запускает тесты или deploy. Значение сохраняется в существующем .dev.env; без файла действует для сессии. /test-fix-loop — отдельный явно запрашиваемый цикл «deploy → тест → исправление → повтор», даже при auto.

Обычные тесты и проверка результата

Если 1c-data-mcp доступен и разрешён, модель выполняет целевые проверки, когда считает их необходимыми для подтверждения результата. Она задаёт входные данные и ожидаемый результат, проверяет запрос, данные или функцию в dev/test ИБ и сравнивает фактическое с ожидаемым. Это проверки внутри рабочего цикла; /uitests off, lite и economy их не отключают. Обязательные условия Gate 3a сохраняются; дополнительных прогонов «на всякий случай» не требуется.

Такие проверки по умолчанию не меняют данные. Сценарии с записью, проведением или другими побочными эффектами требуют отдельного разрешённого процесса на тестовой базе. Наличие MCP-подключения само по себе не разрешает эти операции.

Для сохраняемых автотестов есть навыки 1c-business-tests и 1c-ui-regression. Модель сама решает, полезны ли они в текущей задаче: создание тестового набора не обязательно после каждой правки. Навыки помогают создать, сопровождать и запускать тесты через проверенный фреймворк проекта; сам фреймворк, браузер или тестовое расширение в пакет не входят. Создание тестов не разрешает автоматически deploy или изменение данных; запуск UI сохраняет политику /uitests. Статические валидаторы и ревью дополняют фактические проверки. Если необходимое подтверждение недоступно, критерий остаётся непроверенным.

Пример: быстрый фикс + standard + стандартная оркестрация + UI off — локальная правка, статические проверки и при необходимости проверка через 1c-data-mcp. Полный цикл + full + economy + UI auto — план, делегированная реализация, проверки результата и интерфейса, финальное ревью и DoD.

Подробные схемы по режимам и сочетаниям — WORKFLOWS.md. Новые определения команд появляются в установленных проектах после обновления rules.

Если ты ИИ-агент и тебе нужно установить или обновить правила в проекте, перейди к AGENT-INSTALL.md и следуй инструкциям оттуда. Текущий файл — обзор для разработчика.

Подключить marketplace

Каталог — этот репозиторий. Плагин вызывает install.ps1 и не копирует content/rules в always-on правила хоста.

Cursor — Dashboard → Plugins → import https://github.com/comol/ai_rules_1c, затем плагин 1c-rules.

Claude Code

claude plugin marketplace add comol/ai_rules_1c
claude plugin install 1c-rules@1c-rules

Codex

codex plugin marketplace add comol/ai_rules_1c --ref main
codex plugin add 1c-rules@1c-rules

В приложении Codex: Plugins → Add More → https://github.com/comol/ai_rules_1c.git.

OpenCode

opencode plugin marketplace add comol/ai_rules_1c
opencode plugin marketplace install 1c-rules

Если команды plugin marketplace нет, в opencode.json: { "plugin": ["<clone>/plugins/1c-rules"] }.

Kilo CLI — тот же каталог, что у Claude Code / OpenCode. В Kilo Code (VS Code) своего marketplace add нет: Kilo CLI или install.ps1 init -Tools kilocode из корня проекта.

После подключения на 1С-проекте плагин сам ставит правила под хост (ensure). Обновление — /1c-rules:update или install.ps1 update.

1c-rules — это переносимый набор правил, ролей субагентов, on-demand инструкций и интеграций для разработки в 1С:Предприятие 8 (BSL) с помощью ИИ-агентов. Содержимое раскладывается в проект единым установщиком и адаптируется под формат каждого инструмента.

Под какие ИИ-агенты адаптированы правила

Правила и команды собираются под конкретный инструмент адаптерами из adapters/*.yaml. Поддерживаются:

• Cursor (.cursor/rules/, .cursor/agents/, .cursor/commands/, .cursor/skills/)
• Claude Code (.claude/rules-1c/, .claude/agents/, .claude/commands/)
• OpenAI Codex (.codex/rules/, .codex/agents/, .codex/skills/, .codex/config.toml; slash-команды ставятся в пользовательский ~/.codex/prompts/)
• OpenCode (.opencode/command/)
• Kilo Code (.kilo/rules-1c/ for on-demand rules referenced by AGENTS.md, .kilo/commands/, .kilo/agents/, .kilo/skills/)
• Kimi Code CLI (.kimi-code/rules-1c/, .kimi-code/agents/, .kimi-code/skills/, .kimi-code/mcp.json; slash-команды доступны через Skills/Plugins Kimi)
• Qwen Code (.qwen/rules-1c/, .qwen/agents/, .qwen/commands/, .qwen/skills/; MCP в .qwen/settings.json под mcpServers с httpUrl; entry stub QWEN.md → AGENTS.md)
• Command Code (.commandcode/rules-1c/, .commandcode/agents/, .commandcode/commands/, .commandcode/skills/; MCP в корневом .mcp.json, общий с Claude Code)
• Cline (.cline/rules-1c/, .cline/agents/, .cline/skills/; MCP только глобальный — установщик проектный MCP не пишет; не кладёт on-demand правила в .clinerules/, чтобы не раздувать контекст)
• ZCode (zcode; .zcode/rules-1c/, .zcode/agents/, .zcode/commands/, .zcode/skills/; MCP — .zcode/config.json, ключ mcp.servers; проверено по исходникам ZCode v3.14.3)
• MiMo Code (mimocode; .mimocode/rules-1c/, .mimocode/agents/, .mimocode/commands/, .mimocode/skills/; MCP — корневой , ключ )

Один и тот же исходный набор правил из content/ раскладывается во все активные инструменты одновременно, поэтому AGENTS.md, on-demand правила и описания субагентов остаются согласованными независимо от того, в каком клиенте вы работаете.

Например, установка для пяти клиентов (из каталога целевого проекта):

& C:\path\to\ai_rules_1c\install.ps1 init -Tools zcode,mimocode,cline,command-code,kimi -NonInteractive

Адаптер kimi рассчитан на новый Kimi Code, использующий .kimi-code/. Его формат субагентов игнорирует model, поэтому модели по ярусам для него не назначаются. В Command Code адаптер явно задаёт tools: "*" и ограничения для ролей только на чтение: отсутствие tools означает отсутствие инструментов. Для ZCode и MiMo Code установщик сохраняет прочие настройки и сторонние MCP-серверы, включая совпавшие имена; при удалении убирает только свои серверы. mimocode.jsonc, если он есть, продолжает переопределять mimocode.json по правилам клиента.

Как попросить агента поставить правила

Установка спроектирована как протокол, который выполняет сам ИИ-агент. Откройте проект в любимом ИИ-агенте (Cursor / Claude Code / Codex / OpenCode / Kilo Code / Kimi / Qwen / Command Code / Cline / Pi) и отправьте сообщение:

Установи правила из https://github.com/comol/ai_rules_1c по AGENT-INSTALL.md.

Всё. Остальное — клонирование репозитория, определение активных инструментов, миграция существующих AGENTS.md / CLAUDE.md, запросы перед разрушительными действиями — описано в AGENT-INSTALL.md, который агент прочитает сам.

Через marketplace — команды в начале файла, раздел Подключить marketplace.

Если при первой установке в .dev.env уже указана информационная база, а исходников 1С в проекте ещё нет, установщик предложит выгрузить их. Можно выбрать «Пропустить»: правила останутся установленными, а выгрузку позже можно запустить командой /loadfrom1cbase full. В режиме PowerShell без диалога выгрузка автоматически пропускается; при установке через агента он предложит выбор в чате.

Для регулярного обновления файлов, которые индексирует MCP, выполните /installfilesupdatescript. Команда создаёт скрипт выгрузки из базы, указанной в .dev.env, и устанавливает его в планировщик Windows: по умолчанию каждые 30 минут, пока текущий пользователь вошёл в систему. Например, /installfilesupdatescript 60 задаёт часовой интервал. Каталог выгрузки определяется по подключённому источнику MCP и должен быть отделён от редактируемых исходников; журнал и скрипт хранятся в .1c-files-update/. Поддерживается Designer XML для основной конфигурации или EXTENSION_NAME; legacy-отчёт метаданных и дерево EDT требуют отдельной настройки источника MCP.

Fallback: PowerShell-установщик

Если агент не справляется (ограниченная среда, нет FS-доступа, нужен детерминированный CI-запуск) — тот же протокол реализован как PowerShell-скрипт install.ps1:

git clone https://github.com/comol/ai_rules_1c.git $env:TEMP\1c-rules
& $env:TEMP\1c-rules\install.ps1 init -Source $env:TEMP\1c-rules

Имя локальной папки произвольное: в примерах используется 1c-rules, но установленный или рабочий каталог может называться иначе.

Параметр -Source также принимает URL напрямую — в этом случае установщик сам делает shallow-clone в кэш под $env:TEMP (ключ кэша — хэш URL) и переиспользует его при повторных запусках; требует git в PATH:

.\install.ps1 init -Source https://github.com/comol/ai_rules_1c

Команды: init / update / add <tool> / remove [<tool>] / doctor / eject.

Совместимость с мультипроектной установкой MCP (INSTALL.md, режим 3)

Если MCP-серверы уже установлены дистрибутивом MCP по его INSTALL.md в мультипроектном режиме (каталог GLOBAL_ROOT, projects.registry.json, динамические порты по проектам), установщик правил это автоматически обнаруживает (переменная окружения BASESAI_MCP_GLOBAL_ROOT либо MCP_GLOBAL_ROOT в .dev.env + файл install.manifest.json) и не трогает mcp.json — ни проектный, ни глобальный. Вместо этого он записывает в USER-RULES.md секцию mcp:install_forme с фактическими серверами, url и портами из артефактов установки. Правильный порядок: сначала MCP по INSTALL.md, затем правила — повторные init / update правил рабочую MCP-схему не ломают. Принудительное поведение — флаг -McpMode auto|managed|external (по умолчанию auto). Подробности — в AGENT-INSTALL.md → External MCP installation.

Варианты SDLC-цикла

Четыре настройки и команды описаны в начале README. Наглядные схемы режимов, сочетания Quality с economymode и границы ответственности — WORKFLOWS.md. Канонические условия выбора режима и проверок — AGENTS.md и verification-policy.md.

Что внутри

• Корневой свод правил — AGENTS.md: исходный always-on контекст для ИИ-агента: принципы и процедура разработки с триажем задач, жёсткий гейт загрузки mcp-policy.md с пронумерованным индексом MCP-обязательств, гейты метаданных / ИБ / хранилища, маршрутизация on-demand правил. Подробности живут в on-demand правилах: файл входит в каждый запрос и в старт каждого субагента, поэтому его размер ограничен валидатором. В этом репозитории он хранится в корне для удобного просмотра и поддерживается как читаемый документ без обязательных плейсхолдеров путей.
• Пользовательские правила — USER-RULES.md: пустой по умолчанию файл для команды/проекта. Установщик его не перезаписывает.
• Память проекта — memory.md: строгий долговременный слой для глобальных критичных правил проекта. Для остальных заметок запись идёт в подключённый Cognee, при его отсутствии — в OpenViking, затем в память templates MCP. Поиск охватывает все подключённые инструменты памяти, включая templates MCP. Маршрутизация и обработка сбоев описаны в content/rules/project-memory.md; memory.md — не общий блокнот.
• Самоулучшаемые правила — LLM-RULES.md: слой правил поведения агента, накопленных из наблюдаемого «трения» (корректировки пользователя, избыточные шаги, конфликтующие правила). Пишется только командой /evolve с поштучным одобрением пользователя; агент в обычных задачах лишь фиксирует сигналы (remember с префиксом rule-friction:) и рекомендует запустить /evolve. Приоритет при конфликте: выше AGENTS.md и on-demand правил, ниже USER-RULES.md и memory.md. Установщик не перезаписывает.
• Адаптация под модель — AGENT_MODEL в .dev.env + профили content/rules/model-opus5.md / model-sonnet5.md / model-fable5.md / model-gpt56.md / model-gpt6.md (роутер — model-adaptation.md). Базовый свод модель-нейтрален; профиль — тонкая надстройка под задокументированное поведение конкретной модели (Claude Opus 5 / Sonnet 5 / Fable 5 / GPT-5.6 / GPT-6 Astra): длина ответов и отчётов, объём нарратива, глубина планирования, охота к делегированию, лишние самопроверки, рекомендации по effort / verbosity, форма контекста, который агент пишет для других (брифы субагентам, заметки памяти, handoff: описанный интерфейс вместо примеров, ссылки на код вместо пересказа). Общие принципы промптинга, справедливые для всех моделей, живут в базовых правилах и профилем не переопределяются; хард-гейты (метаданные через , операции с ИБ, MCP-first, цепочка валидаторов и её бюджет, / , , обязательный отчёт) профиль ослабить не может. Включается командой (название — в любом написании, нормализует сама; — определить текущую модель, — выключить); при первой установке модель предлагается выбрать. Источники специфики: гайды Anthropic (промптинг конкретных моделей, контекст-инжиниринг для поколения Claude 5) и OpenAI по промптингу конкретных моделей.

Структура репозитория

.
├── AGENTS.md                # шаблон основного свода правил (always-on контекст после установки)
├── AGENT-INSTALL.md         # инструкция установки для ИИ-агентов
├── USER-RULES.md            # пользовательские правила (не трогается установщиком)
├── memory.md                # память проекта
├── LLM-RULES.md             # самоулучшаемые правила агента (пишет только /evolve, с одобрения пользователя)
├── install.ps1              # PowerShell-установщик
├── .cursor-plugin/          # git-каталог Cursor (marketplace.json)
├── .claude-plugin/          # git-каталог Claude Code / OpenCode / Kilo CLI
├── .agents/plugins/         # git-каталог Codex (читает и OpenCode)
├── plugins/1c-rules/        # тонкий marketplace-плагин: skills/hooks + вызов install.ps1
├── .dev.env.example         # шаблон параметров проекта
├── adapters/                # адаптеры под инструменты (cursor, claude-code, codex, opencode, kilocode, kimi, qwen, command-code, cline, zcode, mimocode, pi, other)
├── content/
│   ├── rules/               # on-demand правила, подключаемые по задаче
│   ├── agents/              # описания 13 специализированных субагентов
│   ├── commands/            # слэш-команды (doctor, deploy-and-test, initproject, restore-testbase, test-fix-loop, build-release, economymode, sdlc, litemode, previewmode, caveman, rulesmodel, evolve, getconfigfiles, loadfrom1cbase, update1cbase, checkmcp, setupmcp, installtools, installmcp, install-cognee, install-openviking, install-edt-mcp, install-atlassian-mcp, updatemcp, updaterules, checkupdates, support, supportstatus, check-uuid, install-agent-browser, install-windows-mcp, install-rtk, install-officecli)
│   ├── skills/              # SKILL-пакеты (1c-metadata-manage, mermaid-diagrams и др.)
│   ├── openspec-bundle/     # снапшот вывода `openspec init` для каждого инструмента
│   └── mcp-servers.json     # каталог MCP-серверов экосистемы 1С
├── openspec/                # OpenSpec-воркспейс (specs/, changes/, project.md)
└── tools/                   # вспомогательные скрипты (refresh-openspec-bundle.ps1)

Что появится в проекте после установки

Независимо от канала установки (агент или install.ps1) на диске будет:

• AGENTS.md, USER-RULES.md, memory.md, LLM-RULES.md — в корне проекта. Это требование инструментов: Cursor, Claude Code, Codex, OpenCode, Kilo, Kimi, Qwen, Command Code, Cline и Pi читают AGENTS.md именно из корня; перенос в .cursor//.claude/ отключит загрузку. Для Qwen дополнительно пишется stub QWEN.md → AGENTS.md.
• директории активных инструментов (.cursor/, .claude/, .codex/, .opencode/, .kilo/, .kimi-code/, .qwen/, .commandcode/, .cline/, .zcode/, .mimocode/, .pi/, .ai-agent/) — для каждого детектированного. On-demand правила лежат в каталоге rules / rules-1c адаптера, не дублируются в отдельный «общий» каталог. Особенности MCP: Kilo — .kilo/kilo.json (mcp); Qwen — merge mcpServers в .qwen/settings.json (httpUrl); Command Code / Claude Code — общий .mcp.json; Cline и Pi — проектный MCP не пишется.
• openspec/ — OpenSpec-воркспейс (если ещё не было).
• .ai-rules.json — манифест с перечнем размещённых файлов, активных инструментов, выбранным каноническим каталогом on-demand правил и версией.

AGENTS.md ссылается на on-demand правила по пути одного канонического каталога (приоритет cursor → claude-code → kilocode → kimi → qwen → command-code → cline → zcode → mimocode → opencode → codex → pi → other; other становится каноном только когда выбран без «реального» инструмента). При установке только под один инструмент в проекте появится ровно одна тулзовая директория плюс AGENTS.md/USER-RULES.md/memory.md/LLM-RULES.md в корне — без дополнительных общих папок.

Если активен ровно один инструмент, агент-установщик не задаёт уточняющих вопросов. PowerShell-fallback дополнительно поддерживает флаги -Tools cursor,claude-code, -NonInteractive, -AssumeYes. Полный протокол и описание манифеста — в AGENT-INSTALL.md.

Свод on-demand правил (content/rules/)

Подгружаются ИИ-агентом по задаче, когда сценарий совпадает с описанием правила. Входные точки перечислены в AGENTS.md → Additional rules; компаньонов и доменные стандарты подключают роутеры (forms.md, coding-standards.md), профили моделей — AGENTS.md → Active model adaptation. Список ниже — обзор по группам.

• coding-standards.md — краткий индекс стандартов кода и ссылок на детальные правила.
• dev-standards-env.md — параметры .dev.env, операции с ИБ, UI-тесты, модели субагентов, оркестрация и параметры процесса.
• dev-standards-code-style.md — стиль BSL, метрики качества, запрещённые конструкции, документация API, типографика, комментарии и внутреннее ревью.
• dev-standards-change-markers.md — маркеры изменения типового кода, нейминг метаданных и выбор типа объекта.
• dev-standards-architecture.md — архитектурные паттерны, расширения, стандарты платформы, code smells.
• module-structure.md — канонические шаблоны регионов для общих модулей, модулей объектов и менеджеров, модулей форм; директивы препроцессора; обязательные регионы.
• forms.md — единая точка входа для задач по управляемым формам; выбирает нужные companion-правила для Form.xml, Form.Module.bsl, событий, async, reserved names и XML-валидации.
• form-patterns.md — паттерны раскладки управляемых форм: архетипы (документ / обработка / список / элемент справочника / мастер), нейминг (ГруппаШапка, Отбор[Поле] + Использование), принципы layout и advanced ERP-паттерны.
• forms-add.md — генерация и доработка форм, включая правила представления (программная модификация типовых форм, размещение элементов, проверка заполнения, команды формы).
• form-module.md — работа с модулем формы: подключение обработчиков событий в Form.xml, зарезервированные имена свойств (запрет на локальные переменные ПараметрыВыбора, СвязиПараметровВыбора, СписокВыбора, ПараметрыОтбора, ОтборСтрок), данные формы.
• async-methods.md — практическое руководство по Асинх / Ждать / Обещание (платформа 8.3.18+) с типичными паттернами и ловушками (тихая потеря исключений без Ждать, Асинх в обработчиках событий формы, HTTP-async).
• extension-patterns.md — паттерны расширений (CFE): типы перехватчиков, правила ПродолжитьВызов, маркеры #Вставка / #Удаление, ограничения заимствованных объектов, антипаттерны.
• dcs-design.md — правила проектирования отчётов на СКД: выбор типа наборов данных, вычисляемые поля vs ресурсы, параметры и пользовательские настройки, варианты, программный override компоновки, взаимодействие с RLS, чек-лист производительности.

Специализированные субагенты (content/agents/)

Тринадцать ролей под конкретные задачи: 1c-explorer, 1c-analytic, 1c-planner, 1c-architect, 1c-arch-reviewer, 1c-developer, 1c-metadata-manager, 1c-refactoring, 1c-performance-optimizer, 1c-error-fixer, 1c-tester, 1c-code-reviewer, 1c-doc-writer. Когда какой использовать — описано в content/rules/subagents.md (точка входа из AGENTS.md → Skills and Subagents).

Ревьюеры 1c-code-reviewer и 1c-arch-reviewer отключены, пока модель не задана явно в SUBAGENT_MODEL_ANALYSIS или пользователем для конкретного запуска. Наследование модели клиента и подстановка SUBAGENT_MODEL_CODING их не включают. При отключённом ревьюере запрошенное пользователем ревью выполняет головной агент; MCP-проверка review_1c_code сохраняется. Подробности — content/rules/subagents.md → Reviewer model gate.

SKILL-пакеты (content/skills/)

Скиллы — это самодостаточные подключаемые модули с собственной документацией и (опционально) скриптами/инструментами. Активный инструмент подхватывает их из своего skills/-каталога. В поставке:

1c-metadata-manage — управление структурой метаданных 1С

Главный скилл для работы с метаданными конфигурации: создание, редактирование, валидация, удаление объектов, форм, отчётов, макетов, ролей, расширений, баз. Скилл — диспетчер: по ключевым словам задачи он направляет агента в нужный домен и при сложных мутирующих сценариях делегирует работу субагенту 1c-metadata-manager. Все XML-операции выполняются через скрипты в tools/, которые корректно обрабатывают BOM, кодировки, UUID, порядок ChildObjects и кросс-ссылки — то, что легко сломать ручной правкой.

Покрываемые домены:

• Объекты метаданных (meta-manage.md) — справочники, документы, регистры (сведений, накопления, бухгалтерии, расчёта), перечисления, константы, общие модули, реквизиты, табличные части.
• Целостность UUID (uuid-check.md) — поиск объектов с одинаковым идентификатором в XML-выгрузке (атрибуты uuid, элементы xr:TypeId / xr:ValueId), с опциональной перегенерацией. Запускать после массовой генерации метаданных, ручной правки XML и слияния веток; слэш-команда /check-uuid.
• Управляемые формы (form-manage.md) — создание, редактирование, анализ, валидация Form.xml, элементов, команд, событий.
• Схемы компоновки данных, СКД (skd-manage.md) — отчёты, наборы данных, запросы СКД.
• Табличные документы, MXL (mxl-manage.md) — макеты, печатные формы, декомпиляция MXL.
• Роли и права (role-manage.md) — права, RLS, разграничение доступа.
• Внешние обработки и отчёты (epf-manage.md) — каркас, сборка, дамп EPF/ERF.
• Конфигурации и расширения (cf-manage.md, cfe-manage.md) — создание, диффы, патчи, регистрация в БСП (bsp-manage.md).
• Состояние поддержки (support-manage.md) — типовые «на замке», снятие с поддержки, включение возможности изменения. Мутирующие скрипты скилла сами отказываются править заблокированный объект поставщика и ведут сюда либо в расширение.
• Пакеты XDTO (xdto-manage.md) — анализ пакета и типов, сборка из XSD, выгрузка схемы, точечная правка, валидация. Для обменов, интеграций и веб-сервисов.
• Базы данных (db-manage.md) — реестр, создание, запуск, загрузка/выгрузка ИБ, DT-бэкапы.
• Подсистемы и командный интерфейс (subsystem-manage.md, interface-manage.md).
• Макеты и шаблоны, справка (template-manage.md, help-manage.md); паттерны БСП — в стандарте dev-standards-architecture (§4) и в mcp-1c-tools/docs/1c-ssl-mcp.md.
• Запросы — написание новых (query-writing.md) и оптимизация (query-optimization.md).
• Веб-публикация () — публикация/снятие, статус, smoke-тесты для Apache/IIS. Для четырёх Apache-операций есть Python-варианты: publish, info, stop, unpublish. Они используют отдельно установленный совместимый Apache и веб-расширение 1С, работают с локальной публикацией и управляют только собственным подтверждённым процессом.

Реестр операций: что скилл умеет менять

Мутации метаданных не «пишутся агентом в XML», а выполняются закрытым набором типизированных операций. Ниже — то, что реально объявлено в скриптах, а не список намерений.

Что считаем	Сколько
Инструментов (каталоги tools/1c-*)	38
Скриптов PowerShell / точек входа Python	71 / 6
Типизированных операций -Operation	111
Видов метаданных в логической адресации	48 (99 псевдонимов: русские и английские имена)
Доменных документов docs/*.md	24
Регрессионных сценариев приёмки	37 (PowerShell) + 53 (паритет PowerShell ↔ Python)

Распределение типизированных операций по инструментам: meta-edit — 47 (реквизиты, табличные части, измерения, ресурсы, значения перечислений, формы, макеты, команды, владельцы, движения, предопределённые элементы), skd-edit — 34 (наборы данных, поля, параметры, настройки, варианты), xdto-edit — 11, cf-edit — 8, interface-edit — 6, subsystem-edit — 5.

Каждая операция валидируется до записи, а после записи meta-edit сам запускает meta-validate — отключить это можно только явным -NoValidate. Мутирующие инструменты отказываются править объект типовой конфигурации «на замке» и ведут в расширение (support-manage.md). По умолчанию инструменты пишут сразу, а _common/Invoke-1CEdit.ps1 -Preview (unified diff и откат) включается только в рискованных кейсах — режим METADATA_PREVIEW=auto, команда /previewmode, разовый показ /previewmode once (docs/edit-preview.md).

Сопутствующие скиллы

• 1c-repository-manage — работа с хранилищем конфигурации 1С: отчёт о состоянии, история версий, сравнение, захват / получение / помещение / отмена захвата точных списков объектов, выгрузка версии в CF/CFE. Активируется явным признаком REPOSITORY_PATH в .dev.env и распространяет на весь процесс разработки дисциплину «захват до правки, помещение после проверки» (docs/repo-sdlc.md). Пока режим хранилища включён, отключать конфигурацию от хранилища запрещено (/ConfigurationRepositoryUnbindCfg и любой эквивалент) — отказ корректный исход, обход через опустошение REPOSITORY_PATH тоже запрещён. Все операции — через PowerShell-скрипт repo-ops.ps1, который сам строит XML списка объектов, читает кодировки /Out, ловит ошибки за нулевым кодом возврата и требует двойного подтверждения для -force; ad-hoc строки /ConfigurationRepository* — дефект.
• mcp-1c-tools — роутер MCP-серверов экосистемы 1С: таблица «потребность → скилл операции» и fallback-цепочка (graph → code-metadata → нативные Grep / Glob / Read после ограниченного промаха). Каталог серверов вынесен в docs/server-catalog.md и нужен только для незнакомого сервера или дополнительной интеграции. Работа только с памятью использует прямой вход project-memory.md.
• Скиллы операций (по одному на типовую операцию, каждый с точными именами аргументов своих инструментов, примерами вызовов в JSON и allowed-tools): 1c-code-search — поиск BSL-кода, структуры модуля, членов контекста; 1c-meta-info — факты об объекте метаданных (паспорт, реквизиты, колонки табличных частей, поиск по категории и описанию); 1c-impact — использования, цепочки вызовов, влияние изменений, слои расширений; 1c-form-inspect — чтение форм, артефактов, XSD и спецификаций форматов; 1c-validate — цепочка валидаторов syntaxcheck_file → check_1c_code → review_1c_code и verify_xml в бюджете политики; 1c-platform-help — справка платформы, проверка платформенной возможности, БСП, стандарты, ИТС; 1c-templates-memory — шаблоны как база и память проекта; 1c-live-ib — запросы и фрагменты в живой ИБ, последняя ошибка журнала. Как сервер отвечает — так агент действует: таблица «ответ сервера → действие» в content/rules/mcp-policy.md.

MCP-серверы экосистемы 1С

Если серверы уже установлены, запустите /setupmcp в новом репозитории. Команда запросит адреса MCP и имеющейся памяти (Cognee, OpenViking или templates MCP), настроит подключения текущего клиента для этого проекта и проверит область индексов и памяти. Существующие серверы переустанавливать не нужно. Для первой установки — /installmcp, для проверки подключений — /checkmcp.

Обычный вариант — локальные MCP. Для коллективной разработки дополнительно можно выбрать общий сервер Debian/Ubuntu с Docker Engine и Compose: локальные Docker Desktop и WSL на компьютерах разработчиков не требуются. Установка предлагает DNS/IP сервера вместо 127.0.0.1; агент сам проверяет свободные порты на сервере, выбирает их для новых сервисов и сохраняет в параметрах запуска и подключениях клиентов. Готовые подключения и последующие обновления сохраняют выбранные адреса и порты. Общие правила размещения — mcp-deployment.

Правила рассчитаны на работу совместно с пакетом MCP-серверов от vibecoding1c.ru/mcp_server (Docker-контейнеры с HTTP-подключением). Все серверы опциональны: правила содержат graceful fallback, если конкретный MCP не поднят. Каталог идентификаторов и примерных локальных адресов — в content/mcp-servers.json; фактические адреса берутся из настроенных подключений. Маршрутизация — роутер mcp-1c-tools (content/skills/mcp-1c-tools/SKILL.md), точные аргументы и примеры вызовов — скиллы операций 1c-* (см. выше), редкие режимы — docs/<server>.md; плейбуки под типовые задачи — в content/rules/tooling-playbooks.md.

1c-graph-metadata-mcp — граф метаданных (Neo4j/Cypher)

Основной инструмент для глубокого анализа конфигурации. Метаданные индексируются как граф связей, что даёт многоуровневый impact-анализ и понимание архитектуры в терминах бизнес-сущностей.

• get_object_dossier — полное «досье» объекта одним вызовом: реквизиты, табличные части, измерения/ресурсы, формы, подписки, роли, зависимости (USED_IN, движения регистров), модули с сигнатурами процедур, бизнес-описание.
• trace_impact — рекурсивный impact-анализ глубиной 1–10 по USED_IN / DO_MOVEMENTS_IN / CALLS. «Если изменю X — что ещё затронет?» Используется перед рефакторингом.
• trace_call_chain — рекурсивный обход графа вызовов BSL (callees / callers, глубина 1–10), с дизамбигуацией одноимённых процедур по объекту-владельцу.
• search_code — поиск по коду конфигурации: fulltext (Lucene), semantic (по смыслу), hybrid. Уровни детализации L0–L3 (от полного кода процедуры до минимальных карточек) для управления токенами.
• search_metadata — JSON-шаблоны Cypher-запросов (детерминированные) или NL → Cypher: списки атрибутов, объектов категории, форм, значений перечислений, измерений и т.д.
• search_metadata_by_description — Lucene-fulltext + опционально вектор по Синоним / Комментарий / Описание / Справка.
• business_search / answer_metadata_question — семантический поиск по бизнес-описаниям и Q&A на естественном языке.
• find_objects_using_object / find_usages_of_object / find_register_movement_docs / resolve_qualified_name / find_by_guid / compare_base_and_extension — точечные обходы графа.

1c-code-metadata-mcp — поиск кода/метаданных, формы, XSD

Базовый «индекс» конфигурации (используется как fallback к графовому MCP).

• Метаданные: metadatasearch (FTS/семантика, режим names_only для компактных списков), get_metadata_details (полная структура объекта по имени).
• Код: codesearch (гибридный поиск), search_function (структурный FTS-индекс по процедурам/функциям с экзакт+fuzzy), get_module_structure (содержимое модуля), get_method_call_hierarchy (плоский call-граф), graph_dependencies (плоские зависимости forward/reverse), bsl_scope_members (доступные методы/свойства/события для BSL-контекста).
• Формы: search_forms (поиск форм по элементам, реквизитам, командам), inspect_form_layout (полное дерево формы — иерархия элементов, привязки, обработчики).
• XSD и валидация: get_xsd_schema (XSD под Справочник, Документ, РегистрСведений и пр., в т.ч. подобъекты Форма / СКД / Макет) и verify_xml (валидация XML-строки против XSD).
• Справка: helpsearch (поиск по HTML-справке).
• Администрирование: reindex, stats.

1c-syntax-checker-mcp — синтаксис BSL

Проверка кода через BSL Language Server. По умолчанию используется syntaxcheck_file — проверка сохранённого файла по пути (при необходимости с фильтром по строкам): она стоит пути вместо целого тела модуля и не требует читать модуль в контекст. syntaxcheck с текстом кода остаётся для случаев, когда файловый инструмент не подключён (нужен смонтированный каталог исходников) или у кода ещё нет файла — только что сгенерированный фрагмент.

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

Три межмодульные проверки (UnresolvedMethodCall, UnresolvedField, QueryToMissingMetadata) по умолчанию выключены: одиночный модуль не видит остальную конфигурацию. В образе есть необязательный режим полной проверки (FULLINDEX=true при смонтированном каталоге исходников): контейнер индексирует конфигурацию и дополнительно отвечает на эти три из индекса — но только в syntaxcheck_file. Без индекса сервер работает штатно: это обычная конфигурация, а не ущербная — просто трёх межмодульных проверок не будет. Индексация реальной конфигурации идёт часами, и всё это время контейнер отвечает на вызовы, так что ждать её не нужно. Состояние индекса приходит в каждом ответе как provenance.index (absent / building / ready / failed), и правила требуют читать его прежде, чем считать чистый отчёт доказательством разрешимости межмодульных ссылок.

1c-templates-mcp — шаблоны и долговременная память проекта

• templatesearch — гибридный поиск (вектор + fulltext) по библиотеке из 2000+ шаблонов и архитектурных паттернов 1С. Вызывается до написания кода.
• remember — сохранение проектного факта/корректировки/нетривиального решения в векторную память (одна самодостаточная заметка на запись, на английском, с сохранением оригинальных имён объектов/модулей 1С).
• recall — векторный поиск по сохранённым заметкам. Используется в начале нетривиальной задачи с ключевыми терминами (имя объекта, подсистема, текст ошибки).

Поиск в этой памяти выполняется и при подключённых Cognee / OpenViking. Новые заметки записываются сюда, когда оба основных провайдера недоступны для записи. Маршрутизация — content/rules/project-memory.md.

Cognee и OpenViking — память агента (опционально)

Установка доступна через /installtools, отдельно — /install-cognee и /install-openviking. Среди разрешённых провайдеров записи получает Cognee, затем OpenViking, затем templates MCP. Полный цикл ищет по всем доступным хранилищам, quick-fix — сначала по первому доступному для чтения. Одной успешной записи достаточно; при отсутствии записи заметка временно сохраняется в memory.md.

Если ни один MCP внешней памяти не настроен, агент один раз за сессию напоминает об установке и рекомендует Cognee через /install-cognee. Напоминание учитывает TOOL_*=off, не запускает установку и не прерывает независимую работу. Сбой уже настроенного сервера обрабатывается как проблема подключения.

В .dev.env для памяти, MCP 1С, EDT и браузеров добавлены настройки TOOL_*: auto — использовать доступный инструмент с предусмотренным fallback; off — не использовать и не предлагать установку; required — отсутствие нужной возможности блокирует зависимый этап. Например, TOOL_COGNEE=off исключает Cognee, а TOOL_SYNTAX=required требует доступного синтаксического валидатора. Флаг задаёт политику агента, а не техническую блокировку MCP: наличие инструментов в сессии, права и актуальность контекста проверяются отдельно. Пропущенные проверки не становятся успешными. При обновлении установщик добавляет отсутствующие ключи со значением auto, сохраняя прежние настройки. Полный перечень — Tool policy.

Инструкции: Cognee, OpenViking; инструменты и параметры — content/skills/mcp-1c-tools/docs/memory-providers.md.

Atlassian MCP — Jira и Confluence (опционально)

Команда /install-atlassian-mcp настраивает mcp-atlassian для Jira, Confluence или обоих сервисов. Доступна также пунктом 8 в /installtools. Поддерживаются Cloud и Server/Data Center; по умолчанию используется uvx, при выборе пользователя — Docker.

Токены хранятся в отдельном локальном .env вне репозитория. Новое подключение по умолчанию работает только на чтение; операции записи включаются по запросу. Команда сохраняет остальные MCP-подключения и проверяет доступ чтением данных после перезапуска клиента.

1c-ssl-mcp — Библиотека Стандартных Подсистем (БСП)

ssl_search — поиск стандартных функций БСП (любой версии) по точному имени и по семантике. Перед написанием новой служебной процедуры агент проверяет, нет ли готовой в БСП, чтобы «не изобретать велосипед».

1C-docs-mcp — справка платформы 1С, стандарты разработки и спецификации форматов

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

• docinfo — точечный поиск по известному имени объекта/метода (ТаблицаЗначений, Массив.Найти, Запрос).
• docsearch — гибридный (вектор + BM25) поиск по описанию, когда точное имя неизвестно.
• standards — детальные стандарты разработки этого набора правил (коллекция 1c-standards): standards(name="anti-patterns") вернёт правило целиком, standards(query="…") ищет по стандартам, standards() отдаёт каталог.
• formatspec — спецификации файловых форматов конфигурации (формы, роли, СКД, MXL, расширения) — тем же способом.

Куда уехали детальные стандарты

Четырнадцать правил в content/rules/ (anti-patterns, dev-standards-architecture, dev-standards-code-style, platform-solutions, locks-and-transactions, systematic-debugging и др.) хранят только заголовки; их нормативный текст лежит в коллекции 1c-standards и достаётся инструментом standards. Заголовки сохранены целиком, поэтому все ссылки вида <файл>.md §N → "Раздел" продолжают резолвиться.

Практика:

• Коллекция входит в образ comol/1c_help_mcp — отдельно монтировать или индексировать её не нужно. Если в схеме сессии нет инструмента standards, образ устарел: обновите его (/checkmcp).
• Тела стандартов редактируются в репозитории MCP-сервера (data/corpora/1c-standards/content/standards/<имя>.md), а не здесь: в этом репозитории от каждого стандарта остался только роутер с деревом заголовков. Совпадение деревьев проверяет tools\validate-rules.ps1 -StandardsDir <путь>.
• Обращаться к стандартам через docsearch / docinfo нельзя — они видят только справку платформы; параметра corpus нет ни у одного инструмента сервера.
• Сервер необязательный. Если он не поднят, агент один раз сообщает об этом, работает по тем правилам, что остались встроенными, и пишет строку в раздел Риски итогового отчёта. Жёсткие гейты проверки (verification-gates.md) при этом работают по своим собственным правилам деградации.
• Контракт получения целиком — content/rules/help-corpus-retrieval.md.

Кроме проверки сигнатур, сервер закрывает проверку платформенных механизмов: перед самописной реализацией специализированной возможности (криптография, СЛАУ и численные методы, анализ данных, система взаимодействия и боты, шина/очереди сообщений, полнотекстовый поиск, регулярные выражения и т.п.) агент обязан спросить справку — есть ли готовый механизм в платформе (docsearch по описанию → docinfo по найденным именам, плюс ssl_search для БСП). Память модели не считается доказательством отсутствия механизма (канон — AGENTS.md → MCP Tool Calling → A.7).

1c-code-check-mcp — 1С:Напарник и ИТС

Доступ к коммерческому сервису 1С:Напарник в роли субагента + поиск по ИТС.

• Анализ кода: check_1c_code (синтаксис, логика, производительность), review_1c_code (стиль, стандарты ИТС, нейминг, структура), rewrite_1c_code / modify_1c_code (переписывание/целевые правки), ask_1c_ai (свободный диалог с сохранением контекста).
• Документация и база знаний: search_1c_documentation (документация под конкретную версию платформы), onec_help (актуальная справка), its_help → fetch_its (поиск по ИТС-стандартам с обязательным дочитыванием полной статьи), diff_1c_documentation_versions (диффы между версиями платформы), config_help (документация по конкретным конфигурациям — ERP, БП, ЗУП, УТ).

Бюджет check_1c_code / review_1c_code такой же: 1 вызов каждого валидатора на цикл по умолчанию, до 3 только после содержательного дефекта. Output AI-инструментов всегда перепроверяется через syntaxcheck + check_1c_code + review_1c_code перед сдачей кода.

edt-mcp — живое рабочее пространство 1C:EDT (опционально)

Не входит в комплект MCP выше и ставится внутрь самой EDT: плагин DitriXNew/EDT-MCP, команда установки — /install-edt-mcp (или пункт EDT-MCP в /installtools). Появляется только в проектах, которые ведутся в EDT (USE_EDT=true в .dev.env), при запущенной EDT с открытым рабочим пространством.

• Что даёт: текущее состояние проверок EDT (revalidate_objects, get_project_errors, get_problem_summary, apply_quick_fix), точные ссылки и переходы (find_references, go_to_definition, get_content_assist), работа с метаданными и модулями в EDT-формате (create_metadata, modify_metadata, write_module_source, adopt_metadata_object), снимки форм, обновление ИБ (update_database), отладка и профилирование, git с привязкой «ветка ↔ ИБ».
• Чего не заменяет: индексный поиск, impact-анализ, справку платформы, БСП, ИТС, шаблоны, память проекта и BSL-валидаторы — это по-прежнему комплект MCP выше.
• Правила работы — content/rules/edt-workflow.md, каталог инструментов и маршрутизация — content/skills/mcp-1c-tools/docs/edt-mcp.md. Деструктивные операции (delete_metadata, rename_metadata_object, delete_project, delete_infobase, update_database, смена типа через modify_metadata) по умолчанию требуют подтверждения — правила запрещают отключать это за пользователя.

OfficeCLI — работа с офисными документами (опционально)

OfficeCLI создаёт, читает и редактирует .docx, .xlsx и .pptx без Microsoft Office. Установка для Windows, macOS и Linux — через /install-officecli или пункт 9 в /installtools. Команда /install-officecli status только проверяет наличие и версию. Нативный установщик также добавляет навык OfficeCLI для обнаруженных AI-клиентов; подключение MCP для работы через CLI не требуется.

Сценарии гейтов: правило утверждает только то, что проверяет

Жёсткие гейты AGENTS.md зарегистрированы в tools/tests/gate-scenarios.json вместе с приёмочными сценариями, которые их проверяют: задача по-русски, ожидаемая цепочка MCP-вызовов с аргументами, запрещённые вызовы, порядок «MCP раньше нативного инструмента», класс ответа (ok / refused) и критерий оценки. tools/validate-rules.ps1 проверяет реестр против AGENTS.md и корпуса: заголовок гейта должен существовать в AGENTS.md, у каждого гейта должен быть хотя бы один сценарий, каждый сценарий должен ссылаться на известный гейт, а каждый инструмент из цепочки должен быть описан в каком-нибудь скилле. Гейт без сценария — ошибка валидации: либо добавляется сценарий, либо гейт снимается.

tools/render-gate-evals.ps1 превращает корпус в самодостаточный eval-плагин Claude Code (по умолчанию в tools/tests/evals). claude plugin eval запускает каждый кейс в пустой песочнице, где не загружаются ни CLAUDE.md / AGENTS.md, ни .mcp.json проекта. Поэтому рендерер ставит свод правил через install.ps1 в workspace/, копирует его в песочницу скриптом scaffold.sh, передаёт AGENTS.md через append_system_prompt и объявляет MCP-серверы в самом плагине: их инструменты называются mcp__plugin_gates_<сервер>__<инструмент>. Установленные агенты, skills и команды свода тоже становятся компонентами плагина, иначе прогон их не увидит. Граф, индекс кода, синтаксис, Напарник и память заменены агентными заглушками из tools/tests/eval-mocks/ — сохранённый tools/list настоящего сервера плюс инструкция, изображающая типовую УТ 11.5. Это делает прогон повторяемым и не пишет в настоящую память проекта. Исходники для сценариев правки кода лежат в tools/tests/eval-fixtures/: common/ попадает в каждый кейс, <ID сценария>/ накладывается поверх для одного кейса; все заглушки описывают одну и ту же конфигурацию (ERP 2.5 с этими модулями) через tools/tests/eval-mocks/_world.md, поэтому граф, индекс кода и файлы не противоречат друг другу. Справка платформы и БСП идут в живые серверы. Провайдеры памяти из opt_in_servers доступны только кейсам, которые их называют. Поле сценария mocks сужает инструменты сервера (tools), превращает вызов в отказ (errors) или в фиксированный ответ (answers); env записывает в .dev.env значения из условия задачи; fixtures добавляет наборы файлов из tools/tests/eval-fixtures/sets/. Команда запуска печатается после рендера: claude plugin eval tools/tests/evals --eval-dir cases --scaffold --allow-real-servers --trust-plugin --allow-tools Write Edit "mcp__plugin_gates_1C-docs-mcp__*" "mcp__plugin_gates_1c-ssl-mcp__*". На Windows песочницы для shell нет, поэтому набор не выдаёт Bash / PowerShell, и сценарии, которым нужен shell, честнее гонять под WSL2. Корпус — единственный источник правды; сгенерированные кейсы не редактируются вручную. Сценарий может задать max_turns, шаг цепочки — max (сколько раз вызов допустим); LLM-судья оценивает финальный ответ, а какие инструменты вызывались и в каком порядке, проверяют структурные грейдеры; грейдер порядка не считает нативным поиском чтение правил и .dev.env. Ограничения стенда: фикстуры — частичная выгрузка без XML метаданных, поэтому сценарии мутации метаданных упираются в отсутствие файлов; встроенного браузера и shell в прогоне нет; падает, если нативный инструмент не вызывался вовсе; оценка LLM-судьи — ориентир, спорные случаи сверяются по трассе (). CI рендерит корпус на каждом push, чтобы корпус и рендерер не разошлись; сами кейсы гоняются вручную перед релизом (полный прогон 46 кейсов — около $20).

tools/validate-rules.ps1 также держит бюджеты загрузки: AGENTS.md — не больше 11 КиБ, одно правило — не больше 40 КиБ, типовой набор full-cycle задачи на BSL — не больше 124 КиБ, стартовый контекст субагента (AGENTS.md + subagent-core.md + его промпт) — не больше 28 КиБ. Описания во frontmatter тоже попадают в каждую сессию (хосты перечисляют skills и агентов, Cursor — ещё и правила), поэтому они ограничены: skill — 300 байт, агент и правило — 250 байт. Рост любого из бюджетов — осознанное решение, а не дрейф. Служебные команды (установка, обновление, переключатели режимов) помечены userOnly: true: в Claude Code адаптер превращает это в disable-model-invocation, их описания не занимают контекст модели, и вызываются они только вручную через /. Наблюдения, из которых выросли отдельные правила, лежат в tools/rules-rationale.md и в контекст агента не попадают.

OpenSpec

Установщик безусловно разворачивает OpenSpec-воркспейс (openspec/) с режимом «не перезаписывать существующее». Слэш-команды /opsx:propose, /opsx:apply, /opsx:archive, /opsx:explore, /opsx:sync, /opsx:update разворачиваются автоматически для каждого активного инструмента из набора cursor, claude-code, codex, opencode, kilocode (бандлы — в content/openspec-bundle/<tool>/). Особенность Codex: его бандл содержит только SKILL-пакеты OpenSpec (.codex/skills/openspec-*), без слэш-команд — workflow вызывается через скиллы напрямую. Для kimi, qwen, command-code, cline, zcode, mimocode, pi и other тулз-специфичного OpenSpec-бандла нет — работайте напрямую с openspec/specs/ и openspec/changes/ (или через установленные OpenSpec skills, где они есть). Подробности — в openspec/README.md.

Ссылки

• vibecoding1c.ru — портал по вайбкодингу для 1С: курсы, бенчмарк моделей, статьи, продукты для разработки 1С с ИИ.
• vibecoding1c.ru/mcp_server — пакет MCP-серверов для 1С, под который заточены правила и плейбуки этого репозитория.
• Telegram-канал «IT Does Matter» — обсуждение вайбкодинга для 1С, MCP, ИИ-агентов, практик и обновлений.

Лицензия

Никакой лицензии, берите и используйте как хотите