Translate all README files to Russian

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

services/device-control-service/README.md

@@ -1,20 +1,20 @@
 # device-control-service (Go)
 
-Status: not implemented yet.
+Статус: пока не реализован.
 
-Responsibility:
-- Expose a gRPC API (see `proto/device_control.proto`) for issuing commands
-  to devices — called by Laravel (manual control) and rule-engine-service
-  (rule-triggered actions).
-- Publish the command to the device's MQTT topic (`devices/{device_id}/commands`)
-  and listen for acknowledgements (`devices/{device_id}/ack`).
-- Maintain the Device Shadow pattern in Redis: `desired_state` (what the user
-  wants) vs `reported_state` (what the device confirmed), plus `status` and
-  `last_seen`.
-- Owns the health-check loop (or delegates to health-check-service): a ticker
-  goroutine that flips a device to `offline` when `last_seen` exceeds a
-  timeout, and emits an event for notification-service.
+Зона ответственности:
+- Предоставляет gRPC API (см. `proto/device_control.proto`) для отправки
+  команд устройствам — вызывается из Laravel (ручное управление) и из
+  rule-engine-service (действия по срабатыванию правил).
+- Публикует команду в MQTT-топик устройства (`devices/{device_id}/commands`)
+  и слушает подтверждения (`devices/{device_id}/ack`).
+- Поддерживает паттерн Device Shadow в Redis: `desired_state` (чего хочет
+  пользователь) против `reported_state` (что подтвердило устройство), плюс
+  `status` и `last_seen`.
+- Владеет циклом health-check (либо делегирует его health-check-service):
+  горутина-тикер переводит устройство в `offline`, когда `last_seen`
+  превышает таймаут, и генерирует событие для notification-service.
 
-Not this service's job: deciding *when* to send a command based on sensor
-thresholds — that's rule-engine-service's logic. This service only executes
-and tracks state for whatever command it's given.
+Не входит в зону ответственности: решение о том, *когда* отправлять команду
+на основе показаний датчиков — это логика rule-engine-service. Этот сервис
+только исполняет команды и отслеживает состояние для той команды, что ему дали.

services/esp32-emulator/README.md

@@ -1,11 +1,11 @@
 # esp32-emulator (Go)
 
-Status: not implemented yet.
+Статус: пока не реализован.
 
-Responsibility:
-- Stand in for real ESP32 hardware during MVP development.
-- Publish plausible telemetry (temperature/humidity/etc.) to
-  `devices/{device_id}/telemetry` over MQTT on an interval.
-- Subscribe to `devices/{device_id}/commands` and reply on
-  `devices/{device_id}/ack`, so device-control-service has something real
-  to talk to.
+Зона ответственности:
+- Заменяет реальное железо ESP32 на время разработки MVP.
+- Публикует правдоподобную телеметрию (температура/влажность/и т.д.) в
+  `devices/{device_id}/telemetry` по MQTT с заданным интервалом.
+- Подписывается на `devices/{device_id}/commands` и отвечает в
+  `devices/{device_id}/ack`, чтобы device-control-service было с кем
+  по-настоящему взаимодействовать.

services/health-check-service/README.md

@@ -1,11 +1,12 @@
 # health-check-service (Go)
 
-Status: not implemented yet. May start as a goroutine inside
-device-control-service and get split out into its own container later —
-kept as a separate directory from day one so the split is a non-event.
+Статус: пока не реализован. Может начаться как горутина внутри
+device-control-service и позже выделиться в отдельный контейнер — поэтому
+с первого дня держим отдельную директорию, чтобы это разделение прошло
+безболезненно.
 
-Responsibility:
-- Periodically (ticker) check `last_seen` for every device in Redis.
-- When a device exceeds the offline timeout, flip its `status` to `offline`
-  and publish an event for notification-service.
-- Good place to demonstrate goroutines + graceful shutdown in Go.
+Зона ответственности:
+- Периодически (по тикеру) проверяет `last_seen` каждого устройства в Redis.
+- Когда устройство превышает таймаут офлайна, переводит его `status` в
+  `offline` и публикует событие для notification-service.
+- Хороший повод продемонстрировать горутины + graceful shutdown в Go.

services/ingest-service/README.md

@@ -1,13 +1,13 @@
 # ingest-service (Go)
 
-Status: not implemented yet.
+Статус: пока не реализован.
 
-Responsibility:
-- Subscribe to MQTT topics `devices/{device_id}/telemetry`.
-- Validate/parse payload (device_id, sensor_type, value, timestamp).
-- Batch-write raw readings into ClickHouse `telemetry` table.
-- Publish a "new reading" event to RabbitMQ for rule-engine-service.
+Зона ответственности:
+- Подписка на MQTT-топики `devices/{device_id}/telemetry`.
+- Валидация/парсинг payload (device_id, sensor_type, value, timestamp).
+- Батч-запись сырых показаний в таблицу ClickHouse `telemetry`.
+- Публикация события «новое показание» в RabbitMQ для rule-engine-service.
 
-Not this service's job: interpreting what a sensor reading *means* (thresholds,
-actions) — that belongs to rule-engine-service. This service only ingests and
-stores.
+Не входит в зону ответственности: интерпретация того, что *означает*
+показание датчика (пороги, действия) — это задача rule-engine-service. Этот
+сервис только принимает и сохраняет данные.

services/rule-engine-service/README.md

@@ -1,18 +1,18 @@
 # rule-engine-service (Go)
 
-Status: not implemented yet.
+Статус: пока не реализован.
 
-Responsibility:
-- Consume "new reading" events from RabbitMQ (async — delivery reliability
-  matters more than latency here).
-- Load active `automation_rules` for the relevant zone/device from PostgreSQL,
-  caching in memory/Redis to avoid a DB round-trip per event.
-- Evaluate rule conditions generically: `sensor_type X operator value` against
-  the reading — no hardcoded sensor/device names, everything comes from the
-  `automation_rules` row.
-- On match: call device-control-service over gRPC (needs a fast pass/fail
-  result) and publish an event to notification-service over RabbitMQ (not
-  latency-critical).
+Зона ответственности:
+- Потребляет события «новое показание» из RabbitMQ (асинхронно — здесь
+  надёжность доставки важнее задержки).
+- Загружает активные `automation_rules` для нужной зоны/устройства из
+  PostgreSQL, кэшируя в памяти/Redis, чтобы не ходить в БД на каждое событие.
+- Оценивает условия правил обобщённо: `sensor_type X operator value` против
+  показания — никаких зашитых названий датчиков/устройств, всё берётся из
+  строки `automation_rules`.
+- При срабатывании: вызывает device-control-service по gRPC (нужен быстрый
+  результат успех/неудача) и публикует событие в notification-service через
+  RabbitMQ (не критично к задержке).
 
-Not this service's job: talking to MQTT or Redis directly — device state
-changes always go through device-control-service's gRPC API.
+Не входит в зону ответственности: прямое взаимодействие с MQTT или Redis —
+изменения состояния устройства всегда идут через gRPC API device-control-service.