Участие в разработке

Поток PR

1. Создайте feature branch от main: feat/<short-name> или fix/<short-name>.
2. Внесите код + документацию в том же MR.
3. Заведите PR, заполните чеклист ниже.
4. Убедитесь, что CI проходит.
5. Получите минимум 1 approve (2 для значимых архитектурных изменений).
6. Мерж через squash.

Коммиты рекомендуется оформлять по Conventional Commits (feat:, fix:, docs:, refactor: и т.д.), чтобы release pipeline мог автоматически собирать changelog.

Критерии готовности (Definition of Done, DoD)

PR готов к мержу, если:

• Код проходит все CI-проверки.
• Для изменений локального ingress / docs runtime проходят make verify-web-compose и make verify-local-web.
• Юнит-тесты написаны на новую логику и занимают основной объём покрытия.
• Интеграционные / service-тесты обновлены там, где затронуты адаптеры, транзакции, wiring или межмодульное взаимодействие.
• Для внешних провайдеров обновлены контрактные тесты на моковых API-ответах.
• Для новых портов используются mockery-сгенерированные моки; hand-written mocks/stubs для нового кода не добавлялись.
• Документация обновлена:
  • Если изменилась доменная модель → обновлён 10-business/.
  • Если изменилась схема → обновлён 20-architecture/schemas/.
  • Если новый сервис → есть 30-services/<n>/README.md + AGENTS.md, обновлён родительский AGENTS.md.
  • Если нетривиальное архитектурное решение → есть ADR в 20-architecture/adr/.
  • Если изменились deploy / CI/CD / release процессы → обновлён 40-operations/ или 50-processes/.
• Нет хардкоженных secrets.
• Обсервабилити: новый код логируется, метрики на критичных местах.
• Миграции проверены на staging.
• Для user-visible изменений или release-кандидата обновлены CHANGELOG.md и VERSION (если требуется новый релиз).

Правила ревью

Ревьюверам:

• Проверяйте архитектурные границы (чистая архитектура, отсутствие импортов core из connectors).
• Проверяйте документацию — не только код.
• Сомневайтесь в новых зависимостях.
• Требуйте тесты по пирамиде, а не только happy-path unit.

Стиль кода

• Go: go fmt, goimports, go vet, golangci-lint с проектной конфигурацией.
• SQL: миграции — snake_case, форматированы единообразно.
• Markdown: конфиг markdownlint в репо.
• Генерация моков: mockery для внутренних портов.
• Локальный рантайм: перед сдачей изменений в docs/deploy слое проверяйте docker compose ... config, локальный HTTPS ingress и доступность docs.tracium.dev.