ai-rules-1c

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 — корневой mimocode.json, ключ mcp)
• Pi (.pi/rules-1c/, .pi/prompts/ для команд, .pi/skills/; без субагентов и без MCP — у Pi нет встроенного MCP)
• Прочее (other, универсальный fallback) (.ai-agent/rules/, .ai-agent/agents/, .ai-agent/commands/, .ai-agent/skills/, .ai-agent/mcp.json) — для любого ИИ-клиента, которого нет в списке выше (Aider, Continue, Cody и т.п.). Ничего не автодетектится — выбирается вручную при установке. На диск пишутся максимально портабельные правила: AGENTS.md в корне (де-факто стандарт для современных агентов), а on-demand-правила и описания субагентов — по нейтральным путям под .ai-agent/ с минимальной frontmatter (description + alwaysApply).

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

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

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