Skip to content

Latest commit

 

History

History
55 lines (36 loc) · 5.04 KB

CONTRIBUTING.md

File metadata and controls

55 lines (36 loc) · 5.04 KB

Contributing to AI-EDT

Спасибо за интерес к проекту. Перед отправкой 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-кода:

  1. Убедитесь, что BUILD SUCCESS.
  2. Проверьте затронутые инструменты в живой EDT.
  3. Прогоните 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 - одна логическая задача. Микс багфикса и рефакторинга в одном PR затрудняет ревью.
  • Сообщения коммитов: type(scope): summary (например fix(launch_debugger): auto-resolve threadId). Тело коммита - что изменилось и почему.
  • Перед merge PR проходит ревью. Ожидайте замечаний - это нормальный процесс.

Сообщить о баге

Откройте issue: версия плагина, версия EDT, шаги воспроизведения, ожидание/реальность, лог (<workspace>/.metadata/.log или plugin state-location). Чем точнее воспроизведение - тем быстрее починим.