main commit fix.

CLAUDE.md

@@ -16,12 +16,16 @@ This is a microservices-based Telegram bot system for text monitoring and notifi
 ## Architecture
 
 The services follow a message bus pattern using RabbitMQ for async communication:
-- TelegramListener publishes MessageReceived events
+- TelegramListener publishes:
-- TextMatcher subscribes to MessageReceived, stores match history in database, and publishes:
+  - **MessageReceived** events (for new messages)
+  - **MessageEdited** events (for edited messages)
+- TextMatcher subscribes to MessageReceived and MessageEdited, stores match history in database, and publishes:
   - TextSubscriptionMatched events (for first-time matches)
   - TextSubscriptionUpdated events (for updates to previously matched messages)
 - TelegramClient subscribes to both TextSubscriptionMatched and TextSubscriptionUpdated events and notifies users
 
+**Note:** WTelegram sends both `UpdateNewChannelMessage` and `UpdateEditChannelMessage` for the same message. TelegramListener publishes separate events to avoid duplicate notifications downstream.
+
 Each service follows Clean Architecture with separate projects for:
 - Host (API/entry point)
 - AppServices (business logic)
@@ -134,4 +138,61 @@ When running with docker-compose:
 - Entity Framework Core with MariaDB
 - WTelegramClient for Telegram API
 - Rebus for message bus (RabbitMQ)
-- Docker & Docker Compose for containerization
+- Docker & Docker Compose for containerization
+- Drone CI/CD on Kubernetes
+
+## CI/CD Pipeline
+
+**📖 See [_deploy/README.md](_deploy/README.md) for full CI/CD documentation.**
+
+The project uses Drone CI with 5 specialized pipelines:
+
+### 1. Feature Validation (`feature/*`, `fix/*` branches)
+- Triggered on push to feature/fix branches
+- Runs build + tests with Testcontainers support
+- Provides fast feedback before merge
+- Duration: ~3-5 minutes
+
+### 2. Main Validation (`main` branch)
+- Triggered on push to main
+- Same checks as feature validation
+- Ensures main branch stays healthy
+- Duration: ~3-5 minutes
+
+### 3. Contracts-Only Publish (tags with `contracts_only:`)
+- Triggered by tag + commit message containing `contracts_only:<service>`
+- Publishes NuGet contracts without building Docker images
+- Fast iteration on contract changes
+- Duration: ~2 minutes
+- Example: `git commit -m "contracts_only:telegram_listener - Add MessageEdited event"`
+
+### 4. Full Release (clean tags)
+- Triggered by tag without special markers
+- Complete release cycle:
+  1. Publish all NuGet contracts (parallel)
+  2. Build all Docker images with Kaniko (parallel, after contracts)
+  3. Deploy to Kubernetes (automatic for `v*` tags)
+- Duration: ~8-10 minutes
+- Example: `git tag v1.3.0`
+
+### 5. Deploy-Only (tags with `deploy_only:`)
+- Triggered by tag + commit message containing `deploy_only:`
+- Skips building, only deploys existing images
+- Useful for rollbacks and hotfixes
+- Duration: ~1 minute
+- Example: `git commit --allow-empty -m "deploy_only: Deploy v1.2.9"`
+
+### Deployment Scripts
+
+Located in `_deploy/scripts/`:
+- **deploy.sh** - Deploy services to Kubernetes with health checks
+- **rollback.sh** - Rollback deployments to previous version
+- **health-check.sh** - Check health of all services
+
+### Key Optimizations
+
+- **Shared NuGet cache** across pipeline steps (~60% faster builds)
+- **Parallel execution** for independent operations
+- **Proper dependency order**: Contracts → Images → Deploy
+- **Kaniko layer caching** for faster Docker builds
+- **Docker-in-Docker** support for Testcontainers in tests