Спасибо за интерес к проекту. Перед отправкой PR ознакомьтесь с правилами ниже - они помогают сохранять кодовую базу сопровождаемой и юридически чистой.
- Откройте issue с описанием, что планируете сделать (багфикс, фича, рефакторинг) - обсудим подход, чтобы работа не ушла впустую.
- Форкните репозиторий, ведите работу в ветке от
main.
Требования: JDK 17, Maven 3.9+, установленный 1C:EDT 2026.2 или 2026.1.
build.cmd [EDT_INSTALL_DIR]
:: build.cmd прописывает путь к компонентам EDT в target-platform, запускает Maven и восстанавливает файл.
:: Эквивалент вручную: inject Directory-location в mcp/targets/default/default.target,
:: mvn clean verify в mcp/, затем git checkout mcp/targets/default/default.target.Тесты - JUnit 4 в mcp/tests/, фрагмент основного бандла. mvn clean verify прогоняет их через tycho-surefire в headless OSGi-рантайме (платформенные и EDT-бандлы доступны, окон никто не открывает), и красный набор валит сборку. -DskipTests не передавайте: он прячет весь набор.
Быстрая локальная итерация - scripts/run-unit-tests.sh: гоняет те же классы на обычном classpath без OSGi, поэтому часть тестов там помечается missing-runtime. Авторитетный прогон - mvn verify.
Новый production-класс должен появиться в scripts/test-coverage-audit.py --check не в корзине untested (сейчас там 0): либо свой тест, либо явная причина, почему юнит-тест до него не достает.
После правок Java-кода:
- Убедитесь, что
BUILD SUCCESS. - Проверьте затронутые инструменты в живой EDT.
- Прогоните EDT-валидацию (
revalidate_objects) по измененным объектам метаданных, если их трогали.
- Весь код и интерфейс (tool names, operations, JSON keys, descriptions) - на английском. Комментарии в BSL - на русском.
- Имена: MCP-tool names -
snake_case; operations внутри фасадов -snake_case; JSON-параметры -camelCase; Java-методы -camelCase. - При добавлении нового инструмента: класс реализует
IMcpTool, регистрируется вMcpServer.registerTools(), попадает в группуToolCategory. - Следуйте существующим паттернам (фасад + delegate-standalone для обратной совместимости,
SchemaComposerдля схемы,ToolResultдля ответа).
Вклады принимаются на условиях AGPL-3.0-or-later. Отправляя PR, вы соглашаетесь, что ваш код распространяется под той же лицензией.
- Сохраняйте существующие copyright-заголовки. Новые файлы от вашего имени - с заголовком
Licensed under AGPL-3.0-or-later. - Не добавляйте AI-атрибуцию в коммиты и PR (
Co-Authored-By,Generated with ...) - авторство должно отражать реального контрибьютора. - Не коммитьте приватные данные: реальные иены проектов, пути, IP, ключи, содержимое
.serene/, логи. Проверяйтеgit diff --cachedперед коммитом.
- Один PR - одна логическая задача. Микс багфикса и рефакторинга в одном PR затрудняет ревью.
- Сообщения коммитов:
type(scope): summary(напримерfix(launch_debugger): auto-resolve threadId). Тело коммита - что изменилось и почему. - Перед merge PR проходит ревью. Ожидайте замечаний - это нормальный процесс.
Откройте issue: версия плагина, версия EDT, шаги воспроизведения, ожидание/реальность, лог (<workspace>/.metadata/.log или plugin state-location). Чем точнее воспроизведение - тем быстрее починим.