Feature/kafka topic keys

CONTRIBUTING.md

@@ -4,86 +4,143 @@
 
 ## Как начать
 
-1. Убедитесь, что есть issue с описанием задачи (или создайте его).
+1. Убедитесь, что есть issue с описанием задачи или создайте его.
+
 2. Ответвитесь от актуальной `main`:
-   ```bash
-   git checkout main
-   git pull origin main
-   git checkout -b feat/краткое-имя-задачи
 
-3. Имя ветки должно соответствовать шаблону: `{тип}/{краткое-описание}`
+```bash
+git checkout main
+git pull origin main
+git checkout -b feature/краткое-имя-задачи
+```
+
+3. Имя ветки должно соответствовать шаблону:
+
+```text
+{тип}/{краткое-описание}
+```
+
+Основные типы веток:
 
-**Основные типы веток:**
-- `feature/` - добавление нового функционала
-- `fix/` - исправление ошибок
-- `hotfix/` - срочные исправления в основной ветке
-- `docs/` - обновление документации
-- `refactor/` - рефакторинг кода без изменения функциональности
-- `test/` - добавление или исправление тестов
+* `feature/` — добавление нового функционала
+* `fix/` — исправление ошибок
+* `hotfix/` — срочные исправления в основной ветке
+* `docs/` — обновление документации
+* `refactor/` — рефакторинг кода без изменения функциональности
+* `test/` — добавление или исправление тестов
+* `ci/` — изменения CI/CD и инфраструктурных файлов
 
-4. Держите ветку в актуальном состоянии
+4. Держите ветку в актуальном состоянии.
 
-Перед открытием PR (и при длительной работе) подтяните изменения из main:
+Перед открытием PR и при длительной работе подтяните изменения из `main`:
 
 ```bash
 git fetch origin
 git merge origin/main
 ```
 
-> Важно: на момент отправки PR ветка должна быть синхронизирована с актуальным main, иначе не пройдут rule-checks/CI.
+> Важно: на момент отправки PR ветка должна быть синхронизирована с актуальным `main`, иначе могут не пройти rule checks / CI.
 
 ## Код-стайл и коммиты
 
-Соблюдайте форматирование и линтер: 
+Проект написан на `.NET`.
 
-```bash
-npm run lint
+Перед отправкой PR код должен:
+
+* собираться в `Release` конфигурации;
+* проходить анализаторы без предупреждений;
+
+Коммиты рекомендуется писать в стиле Conventional Commits или в коротком понятном формате:
+
+```text
+[add]: add delete account outbox event
+[fix]: handle revoked refresh token
+[docs]: update README
+[test]: cover outbox publisher
+[refactor]: split outbox publisher base
 ```
+
+## Локальные проверки перед PR
+
+Перед отправкой PR желательно выполнить те же проверки, которые запускаются в CI.
+
+### Build
+
 ```bash
-npm run lint:fix
+dotnet build Planara.Auth.sln \
+  --no-restore \
+  -c Release \
+  /p:RunAnalyzersDuringBuild=true \
+  /p:TreatWarningsAsErrors=true
 ```
 
-Коммиты в стиле Conventional Commits: [add], [fix], [docs] и т.д.
-
-Документация к коду через `JSDoc` и комментарии к строчкам.
+## Сборка и проверки в CI
 
-## Сборка и проверки
+Pull request считается готовым к review, если проходят основные проверки:
 
-Перед PR обязательно:
+* `dotnet build`
+* проверки GitHub Actions
+* указан type label
 
-```
-npm run build
-npm run lint
-```
+Если CI падает, сначала исправьте причину падения в своей ветке, затем обновите PR.
 
 ## Как оформить PR
 
-В описании укажите:
+В описании PR укажите:
+
+* что изменено;
+* почему это нужно;
+* какие сценарии проверены;
+* связанный issue, если есть;
+* type label;
 
-- Что изменено — списком через -.
+Для связи с issue используйте:
 
-- Почему — краткая мотивация/контекст.
+```text
+Closes #<номер>
+```
 
-- Связанный issue — используйте авто-закрытие: Closes #<номер> или связь через поле `development` для PR.
+или укажите связь через поле `Development`.
 
-- Добавьте нужные labels (например, enhancement) и assignee.
+## Labels
 
-- Reviewers назначатся автоматически через `CODEOWNERS`.
+Для PR используются labels:
 
-## Чек-лист перед отправкой
+* labels типа изменения — описывают, что именно меняется;
+
+### Type labels
 
-- Ветка создана от main и синхронизирована с актуальным main
+Type label описывает характер изменения в PR или issue.
 
-- `npm run build` проходит локально
+Доступные type labels:
 
-- `npm run lint` без ошибок
+* `bug` — исправление ошибки или неработающего поведения
+* `documentation` — изменения или дополнения документации
+* `duplicate` — issue или pull request уже существует
+* `enhancement` — новая функциональность или улучшение существующей логики
+* `good first issue` — задача, подходящая для первого вклада
+* `help wanted` — требуется дополнительное внимание или помощь
+* `invalid` — issue или PR некорректен или неактуален
+* `question` — требуется дополнительная информация
+* `wontfix` — задача не будет выполняться
 
-- Добавлены/обновлены тесты/доки (если нужно)
+Для обычного PR чаще всего используются:
+
+* `enhancement` — для новой функциональности;
+* `bug` — для исправления ошибки;
+* `documentation` — для изменений документации.
+
+## Чек-лист перед отправкой
 
-- PR описан по шаблону, указан issue, выставлены labels и assignee.
+* Ветка создана от актуальной `main`
+* Ветка синхронизирована с `main`
+* `dotnet build` проходит локально
+* Документация обновлена, если изменилось поведение API
+* PR описан понятно и связан с issue, если issue есть
+* Указан type label
 
 ## Коммуникация
 
-Вопросы — в **Issues/Discussions**.
+Вопросы, предложения и обсуждения — в **Issues** или **Discussions**.
 
-Пожалуйста, соблюдайте наш [Кодекс поведения](./CODE_OF_CONDUCT.md).
+Пожалуйста, соблюдайте [Кодекс поведения](./CODE_OF_CONDUCT.md).

src/Kafka/KafkaTopicKeys.cs

@@ -0,0 +1,17 @@
+namespace Planara.Common.Kafka;
+
+/// <summary>
+/// Ключи Kafka-топиков
+/// </summary>
+public static class KafkaTopicKeys
+{
+    /// <summary>
+    /// Событие создания пользователя
+    /// </summary>
+    public const string UserCreated = "UserCreated";
+
+    /// <summary>
+    /// Событие удаления пользователя
+    /// </summary>
+    public const string UserDeleted = "UserDeleted";
+}

src/Planara.Common.csproj

@@ -3,7 +3,7 @@
     <PropertyGroup>
         <TargetFramework>net10.0</TargetFramework>
         <ImplicitUsings>enable</ImplicitUsings>
-        <Version>1.10.0</Version>
+        <Version>1.11.0</Version>
         <Authors>a1unade</Authors>
         <Company>Planara</Company>
         <Copyright>Copyright © Planara</Copyright>