pcp-request-service: аудит-фиксы RS1/RS3/RS6/RS7

RS1 (#29): планировщик истечения заявок — RequestExpiryService (@Scheduled + FOR UPDATE SKIP LOCKED, мультиинстанс-safe), refreshStatus вызывается и при создании заявки. RS7 (#35): единый топик pcp.request.status.v1 → geoportal (COMPLETED/EXPIRED в payload), замена orphan pcp.request.completed.v1; эмиссия из matching и expiry через тот же outbox; backoff/next_attempt_at/cap для outbox FAILED. RS3 (#31): DefaultErrorHandler + DeadLetterPublishingRecoverer (DLQ pcp.route.georeference-dlq.v1), bounded retry, контрактные ошибки в DLQ. RS6 (#34): проброс coverageRequiredPercent из API, разведение терминов покрытие/важность. Доки: бэклог, аудит сервиса заданий, карты взаимодействий. RS2 (#30) отложено до #28, RS5 (#33) — до роста требований к точности.
2026-06-06 23:47:19 +03:00
parent 2499aebf2d
commit c1259c3105
33 changed files with 1600 additions and 139 deletions
@@ -0,0 +1,310 @@
+# Аудит сервиса заданий — pcp-request-service
+
+Дата: 2026-06-06. Автор: Claude (Opus 4.8).
+Охват: сервис `pcp-request-service` («сервис заданий») — задача [#26](бэклог-pcp-tgu-ops-ui.md).
+Метод: статический разбор кода (контроллеры, Kafka-listener, сервисы сопоставления и жизненного
+цикла, outbox, earth-grid), схема БД и Flyway-миграция, конфиг в `config-repo`, обзор тестов.
+
+Парные документы: общий [аудит-проекта-2026-06-06.md](аудит-проекта-2026-06-06.md),
+карты [PCP_ARCHITECTURE.md](architect/PCP_ARCHITECTURE.md) и
+[PCP_SERVICE_INTERACTIONS.md](architect/PCP_SERVICE_INTERACTIONS.md).
+Стык с сервисом паспорта маршрута (`pcp-route-processing-service`) — отдельная задача
+[#28](бэклог-pcp-tgu-ops-ui.md), здесь только обозначен.
+
+## Сводка по состоянию
+
+Базовое здоровье — хорошее. Сервис держит жизненный цикл заявок на съёмку, ведёт учёт отснятой
+территории геометрическим вычитанием и сопоставляет приходящие паспорта маршрутов с заявками.
+Конкурентность и работа в нескольких инстансах продуманы: per-row пессимистичные блокировки,
+`SKIP LOCKED` в outbox, advisory-lock на пересборку сетки, дедуп по уникальным ключам,
+transactional outbox. 19 тестовых файлов с покрытием ключевых сервисов и репозиториев.
+
+Главные риски — не в инфраструктуре, а в **бизнес-логике закрытия и сопоставления**:
+закрытие «по времени» само по себе не срабатывает (нет планировщика истечения), а матчинг
+засчитывает покрытие без проверки совместимости аппарата. Приоритеты: **RS1**, **RS2** (высокий),
+далее RS3/RS4 (средний), затем долг RS5–RS7.
+
+Порт 7005. БД `pcp_requests` (PostgreSQL + PostGIS), Flyway `V1`, `ddl-auto: validate`.
+Пакет `org.nstart.dep265.requestservice` (несогласован с остальными — см. B3 общего аудита).
+
+## Назначение и контур
+
+Заявки создаются **только по HTTP**; паспорта маршрутов приходят **из Kafka**; завершение
+заявки уходит наружу через **transactional outbox**.
+
+```
+                 HTTP (оператор / pcp-tgu-ops-ui через Vite-прокси)
+   POST/GET/DELETE /v1/requests · GET /v1/cells · /v1/grid
+                         │
+                         ▼
+        ┌───────────────────────────────────┐
+ Kafka  │        pcp-request-service         │  Kafka
+ IN ───▶│  заявки · покрытие · lifecycle ·   │── OUT ──▶  pcp.request.status.v1 → geoportal
+        │  earth-grid · transactional outbox │            (outbox; COMPLETED/EXPIRED, #35)
+        └───────────────────────────────────┘
+   ▲                     │
+   │                     ▼
+pcp.route.georeference.v1     DB: pcp_requests (PostgreSQL + PostGIS)
+   │
+ pcp-route-processing-service  ◀── связь для задачи #28
+ («сервис паспорта маршрута»)
+```
+
+### Карта взаимодействий
+
+| Направление | Канал | Контрагент | Примечание |
+|---|---|---|---|
+| IN (HTTP) | `/v1/requests` (POST/GET/`/map`/`/{id}`/`/{id}/cells`/DELETE) | UI / оператор | заявки заводятся только здесь |
+| IN (HTTP) | `/v1/cells` (+`/priority-map`), `/v1/grid` (settings, `/rebuild`) | UI / оператор | сетка и карта важности |
+| IN (Kafka) | `pcp.route.georeference.v1` | **pcp-route-processing-service** | `KafkaMessage<RoutePassportDto>`, контракт из `pcp-types-lib` |
+| OUT (Kafka) | `pcp.request.status.v1` | **geoportal** (внешний) | outbox `REQUEST_TERMINAL_STATUS`; терминальный статус `COMPLETED`/`EXPIRED` в payload (#35) |
+| — | `pcp.request.in.v1` (`app.kafka.topics.request`) | — | в конфиге есть, **слушателя нет** — мёртвый конфиг (RS4) |
+| DB | `pcp_requests` (Postgres + PostGIS) | — | Flyway `V1`, `ddl-auto: validate` |
+
+HTTP-поверхность: [RequestController](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/controller/RequestController.kt),
+[CellsController](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/controller/CellsController.kt),
+[GridManagementController](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/controller/GridManagementController.kt).
+
+## Доменная модель и БД
+
+Источник: [V1__create_schema.sql](../services/pcp-request-service/src/main/resources/db/migration/V1__create_schema.sql).
+
+- **`requests`** — заявка/задание: `geometry` (исходная) + `remaining_geometry` (что осталось снять),
+  `geometry_area` / `remaining_area`, `coverage_required_percent`, окно `begin/end_date_time`,
+  `status`, `match_count`, `last_matched_at`, `completed_at`, мягкое удаление `deleted_at`,
+  `@Version version` (оптимистичная блокировка). Статусы CHECK-ограничением:
+  `ACCEPTED · ACTIVE · COMPLETED · EXPIRED · DELETED`.
+- **`request_optics_params` / `request_rsa_params`** — параметры съёмки (разрешение, угол Солнца,
+  облачность / поляризация, интерферометрия). Хранятся, но в матчинге **не используются** (RS2).
+- **`request_route_matches`** — аудит и идемпотентность сопоставления: `UNIQUE(request_id, route_id)`,
+  `original_intersection_*`, `applied_intersection_*`, `coverage_delta_percent`, `contributes_to_coverage`.
+- **`outbox_events`** — transactional outbox: `UNIQUE(event_type, aggregate_id)`, статусы `NEW/PUBLISHED/FAILED`.
+- **`earth_cells` / `request_cells` / `earth_grid_settings`** — сетка Земли и проекция заявок на неё;
+  PostGIS-триггеры заполняют `contour_geom` и пересчитывают `earth_cells.importance`
+  (= Σ `request_cell.importance × coverage_percent/100`). Это **карта важности**, не прогресс съёмки (RS6).
+
+Геометрия хранится как WKT (`TEXT`); вычисления — JTS (`jts-core`), без hibernate-spatial.
+
+## Учёт отснятой территории
+
+Ядро — [RouteMatchingService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RouteMatchingService.kt),
+геометрия — [GeometryService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/GeometryService.kt).
+
+На каждый паспорт маршрута:
+1. Кандидаты выбираются по **окну времени + статусу** (`ACCEPTED`/`ACTIVE`, не удалённые) —
+   [findRequestIdsForRoute](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/repository/RequestRepository.kt).
+2. Идемпотентность: `existsByRequestIdAndRouteId` + `request_route_matches UNIQUE` + обработка гонки вставки.
+3. На каждую заявку — своя транзакция с `findByIdForUpdate` (row-lock): маршрут пересекается с
+   **`remaining_geometry`** (не с исходной), остаток уменьшается `difference`, пересчитывается `remaining_area`.
+4. `coveredPercent = (geometry_area − remaining_area) / geometry_area × 100`.
+
+Поскольку учёт идёт по остатку, **перекрывающиеся маршруты не задваиваются** — второй маршрут
+засчитывает только новую площадь. Это корректная кумулятивная модель покрытия.
+
+Ограничения учёта вынесены в находки **RS2** (игнор совместимости аппарата), **RS5** (планарная
+площадь в градусах), **RS6** (earth-grid — это важность, а не покрытие).
+
+## Жизненный цикл и закрытие заданий
+
+Вся логика — пересчёт статуса «с нуля» в
+[RequestLifecycleService.refreshStatus](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestLifecycleService.kt),
+по приоритету сверху вниз:
+
+| Условие | Статус |
+|---|---|
+| `coveredPercent ≥ coverage_required_percent` | **COMPLETED** (ставится `completed_at`) — приоритет над сроком |
+| иначе `now < begin_date_time` | ACCEPTED |
+| иначе `now > end_date_time` | **EXPIRED** |
+| иначе | ACTIVE |
+
+При переходе в терминальный статус (`COMPLETED` или `EXPIRED`) — транзакционный outbox-эвент
+`REQUEST_TERMINAL_STATUS` (идемпотентно по `(event_type, aggregate_id)`,
+[RequestStatusOutboxService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestStatusOutboxService.kt)),
+который затем публикуется
+[OutboxPublisherService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/OutboxPublisherService.kt)
+в `pcp.request.status.v1` (geoportal). См. #35.
+
+Ключевая особенность (бывший источник RS1): `refreshStatus` исторически вызывался **только из матчинга
+маршрута**. После #29 его дополнительно дёргают планировщик истечения (`RequestExpiryService`) и
+`createRequest`, поэтому закрытие «по времени» теперь срабатывает (см. RS1).
+
+## Горизонтальное масштабирование (несколько инстансов)
+
+Сервис **спроектирован под несколько одинаковых инстансов** — это сильная сторона.
+
+Безопасно при N инстансов:
+- **Матчинг** — `findByIdForUpdate` (`SELECT … FOR UPDATE`, пессимистичная блокировка строки заявки)
+  в отдельной транзакции на заявку (`PROPAGATION_REQUIRED` из не-транзакционного listener →
+  одна независимая транзакция на заявку), плюс `@Version` и дедуп `(request_id, route_id)`.
+  Инстансы делят партиции топика (consumer-group `pcp-request-service-route`).
+- **Outbox** — `SELECT … FOR UPDATE SKIP LOCKED` + `UNIQUE(event_type, aggregate_id)` →
+  параллельные инстансы не публикуют эвент дважды
+  ([OutboxEventRepository](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/repository/OutboxEventRepository.kt)).
+- **Пересборка сетки** — `pg_try_advisory_xact_lock`
+  ([GridRebuildLockService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/GridRebuildLockService.kt)) →
+  ребилдит только один инстанс.
+- **Создание заявки** — `existsById` + PK + обработка `23505` → дубликат не пройдёт при гонке.
+
+Семантика доставки — **at-least-once**; повторная обработка маршрута безопасна за счёт дедупа.
+После #31 «ядовитое» сообщение уходит в DLQ (`DefaultErrorHandler` + bounded retry), а не блокирует
+партицию. Outbox FAILED после #35 ретраится с backoff и пределом попыток. Параллелизм потребления
+маршрутов ограничен числом партиций топика.
+
+---
+
+## Находки
+
+### RS1 (высокий). Нет планировщика истечения — закрытие «по времени» не срабатывает — ✅ устранено (#29)
+Файлы: [RequestLifecycleService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestLifecycleService.kt),
+[RouteMatchingService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RouteMatchingService.kt)
+
+`refreshStatus` — единственный путь смены статуса — вызывается **только при сопоставлении маршрута**.
+Единственный `@Scheduled` в сервисе — публикация outbox. Поэтому если по заявке после `end_date_time`
+**не пришло ни одного маршрута**, она навсегда останется `ACTIVE`/`ACCEPTED` и **никогда не станет
+`EXPIRED`**. В `EXPIRED` заявка попадает лишь побочно — если какой-то маршрут случайно пересечётся
+с ней уже после истечения срока. Дополнительно: `createRequest` всегда ставит `ACCEPTED`, даже если
+окно уже в прошлом (`refreshStatus` при создании не вызывается).
+
+Рекомендация: периодический job (`@Scheduled` + advisory-lock или `SKIP LOCKED`-выборка), который
+переводит просроченные заявки в `EXPIRED` без участия маршрутов; вызывать `refreshStatus` и при создании.
+
+**Готово (#29):** добавлен [RequestExpiryService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestExpiryService.kt) —
+`@Scheduled`-воркер переводит просроченные `ACCEPTED`/`ACTIVE` в `EXPIRED`, забирая заявки батчами через
+`findExpirableForUpdateSkipLocked` (`FOR UPDATE SKIP LOCKED` + верхний лимит батчей — безопасно при нескольких
+инстансах). `refreshStatus` теперь вызывается и в `createRequest`, поэтому статус приёма отражает окно
+(`ACCEPTED`/`ACTIVE`/`EXPIRED`). Конфиг — `pcp.request.expiry.*`. Тесты: `RequestExpiryServiceTest`,
+`RequestRepositoryJpaTest`.
+
+### RS2 (высокий). Матчинг игнорирует совместимость аппарата
+Файлы: [RouteMatchingService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RouteMatchingService.kt),
+[RequestValidationService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestValidationService.kt)
+
+Кандидаты подбираются только по окну времени и статусу, а покрытие засчитывается по любому
+геометрическому пересечению. `survey_type` (оптика/РСА), разрешение, угол Солнца, облачность и
+**крен** в фильтрации **не участвуют**: крен парсится и валидируется (0–90°), но как фильтр не
+используется; параметры съёмки лежат в БД мёртвым грузом. Следствие: РСА-маршрут «закроет»
+оптическую заявку, маршрут с негодным разрешением/освещённостью засчитается как покрытие.
+Перекликается с UI-задачей #4.
+
+Рекомендация: добавить проверку совместимости маршрут↔заявка перед зачётом покрытия (как минимум
+survey_type и крен; в идеале — разрешение и угол Солнца). Требует, чтобы паспорт маршрута нёс тип
+сенсора — согласовать в рамках #28.
+
+**Решение (2026-06-06): отложено до #28.** `RoutePassportDto` сейчас не несёт явный `surveyType`
+(есть `polarisation`, `resolutionRange`/`Azimuth`, `rollAngle`, `visirAngle`). Фиксируем контракт
+паспорта в рамках аудита связи сервисов #28 и тогда же добавляем фильтр совместимости. До этого
+matching не трогаем.
+
+### RS3 (средний). Нет DLQ / обработчика ошибок Kafka — poison-сообщение блокирует партицию — ✅ устранено (#31)
+Файл: [RequestKafkaListener.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/kafka/RequestKafkaListener.kt)
+
+Listener ловит исключение, логирует и **перебрасывает** его. DLQ и кастомный `CommonErrorHandler`
+не настроены — работают дефолты Spring Kafka. Невалидное («ядовитое») сообщение маршрута будет
+ретраиться бесконечно и **заблокирует партицию**. У парного `pcp-route-processing-service` DLQ есть,
+здесь — нет.
+
+Рекомендация: `DefaultErrorHandler` с ограниченными ретраями и `DeadLetterPublishingRecoverer`
+(топик вида `pcp.route.georeference-dlq.v1`); невалидные по контракту сообщения отправлять в DLQ,
+а не зацикливать.
+
+**Готово (#31):** [KafkaConsumerConfig](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/config/KafkaConsumerConfig.kt) —
+`DefaultErrorHandler` + `DeadLetterPublishingRecoverer` (DLQ `pcp.route.georeference-dlq.v1`),
+экспоненциальный bounded retry; контрактные ошибки (`JsonProcessingException`/`ConstraintViolationException`)
+не ретраятся, а сразу уходят в DLQ с диагностическими заголовками (`pcp-exception-class`,
+`pcp-original-topic`/`-partition`/`-offset`). Настройки — `app.kafka.consumer.route.*`. По образцу
+`pcp-route-processing-service`. Тест — `KafkaConsumerConfigTest`.
+
+### RS4 (средний). Мёртвый конфиг: cleanup и входной топик заявок — ✅ устранено (#32)
+Файл: [config-repo/pcp-request-service.yaml](../config-repo/pcp-request-service.yaml)
+
+`app.request.cleanup-cron` / `cleanup-retention-days` были заданы, но **кода под них нет** — архивации
+или удаления старых заявок не происходило. Аналогично `app.kafka.topics.request: pcp.request.in.v1`
+был сконфигурирован, но **без слушателя** (заявки заводятся только по HTTP). Конфиг вводил в заблуждение.
+
+Решение (#32): ключи удалены из `config-repo` (привязок `@Value` не было). Если cleanup/приём заявок
+из Kafka понадобятся — заводить конфиг вместе с реализацией.
+
+### RS5 (низкий). Планарная площадь в градусах вместо геодезической
+Файл: [GeometryService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/GeometryService.kt)
+
+Площади считаются JTS `geometry.area` в координатах EPSG:4326 (градусы). Для компактных заявок
+процент покрытия как отношение почти корректен, но для крупных и высокоширотных областей даёт
+систематическое искажение (градус долготы у полюса короче).
+
+Рекомендация: при росте требований к точности — считать площадь геодезически (например, PostGIS
+`ST_Area(geography)` или проекция в равновеликую СК), а не планарно в градусах.
+
+**Решение (2026-06-06): отложено.** Покрытие считается отношением площадей, поэтому для обычных AOI
+планарная оценка близка к геодезической. Переключение `area()` на геодезию ripple-эффектом затронет
+учёт `coverageDeltaPercent` и точечные ассерты площадей в `RouteMatchingServiceTest`; делаем при
+реальном росте требований к точности (крупные/высокоширотные заявки).
+
+### RS6 (низкий). `coverage_required_percent` захардкожен в 100%; earth-grid ≠ покрытие — ✅ устранено (#34)
+Файлы: [RequestService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestService.kt),
+[RequestGridProjectionService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestGridProjectionService.kt)
+
+`createRequest` всегда ставит `DEFAULT_COVERAGE_REQUIRED_PERCENT = 100.0`, игнорируя значение из API,
+хотя колонка и поле его поддерживают. Отдельно стоит зафиксировать: `request_cells.coverage_percent`
+и `/priority-map` — это **доля футпринта заявки в ячейке × важность** (карта приоритетов), считается
+один раз при создании и **маршрутами не обновляется**. Реальный прогресс съёмки живёт только в
+`remaining_geometry` / `remaining_area`. Это легко перепутать по названию поля.
+
+Рекомендация: пробрасывать требуемый процент из API; в документации/именовании развести «важность
+ячейки» и «прогресс покрытия».
+
+**Готово (#34):** в `CreateRequestDto` добавлено опциональное поле `coverageRequiredPercent`
+(0 < x ≤ 100, по умолчанию 100); оно пробрасывается в сущность и служит порогом `COMPLETED`,
+константа `DEFAULT_COVERAGE_REQUIRED_PERCENT` убрана. В KDoc разведены «прогресс покрытия»
+(`coverageRequiredPercent`/`remaining_area`) и «важность заявки» (`importance` → карта приоритетов
+ячеек). Тесты — `RequestServiceTest`, `RequestApiDtoContractTest`.
+
+### RS7 (средний). Уведомление geoportal о финале заявки; outbox FAILED без backoff — ✅ устранено (#35)
+Файлы: [OutboxPublisherService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/OutboxPublisherService.kt),
+[OutboxEventRepository.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/repository/OutboxEventRepository.kt),
+[RequestStatusOutboxService.kt](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestStatusOutboxService.kt)
+
+Потребитель завершения заявок — внешний сервис **geoportal** (в этом монорепо его нет, поэтому в
+[PCP_SERVICE_INTERACTIONS.md](architect/PCP_SERVICE_INTERACTIONS.md) консьюмер не виден). Ему нужно
+сообщать про **оба** терминальных исхода: «выполнено» (`COMPLETED`) и «срок вышел» (`EXPIRED`). Сейчас
+эмитится только `COMPLETED` (в `pcp.request.completed.v1`), а `EXPIRED`-эвента нет вовсе. Плюс
+публикуемая выборка берёт `NEW` + `FAILED`, поэтому FAILED **ретраится**, но без backoff и без cap:
+при устойчивом сбое Kafka каждые 5 с все инстансы перевыбирают FAILED (нагрузка, но не потеря).
+
+Решение: свести уведомления в единый топик **`pcp.request.status.v1`** (по аналогии с
+`pcp.slots.status.v1`) с терминальным статусом в payload, заменив orphan `pcp.request.completed.v1`;
+эмитить `EXPIRED`-эвент через тот же transactional outbox (зависит от планировщика истечения **RS1**,
+который и создаёт переход в `EXPIRED`). Outbox дополнить `next_attempt_at`/экспоненциальным backoff и
+пределом попыток — по образцу `RoutePassportOutboxWorker` из `pcp-route-processing-service`.
+
+**Готово (#35):** единый топик `pcp.request.status.v1` с терминальным статусом в payload
+(`COMPLETED`/`EXPIRED`, плюс `occurredAt`/`coveragePercent`) — заменил orphan `pcp.request.completed.v1`.
+Единое событие `REQUEST_TERMINAL_STATUS` пишется в той же транзакции из двух мест:
+[RouteMatchingService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RouteMatchingService.kt)
+(по достижению покрытия) и [RequestExpiryService](../services/pcp-request-service/src/main/kotlin/org/nstart/dep265/requestservice/service/RequestExpiryService.kt)
+(по истечению срока). Outbox получил `attempts`/`next_attempt_at`: при сбое — удвоение backoff от
+`initial-backoff-ms` до `max-backoff-ms`, после `max-attempts` событие становится терминальным `FAILED`
+и из выборки выпадает. Конфиг — `pcp.outbox.*`. Мелкий зазор: заявка, **созданная** уже просроченной,
+терминальное событие не порождает (вырожденный кейс; обычные пути ACTIVE→COMPLETED/EXPIRED покрыты).
+
+## Что в порядке (намеренно не отмечаем как проблемы)
+
+- Конкурентность и мультиинстанс: row-lock на заявку, `SKIP LOCKED` в outbox, advisory-lock на сетку,
+  `@Version`, дедуп по уникальным ключам — сделано грамотно.
+- Transactional outbox: терминальный эвент `REQUEST_TERMINAL_STATUS` пишется в той же транзакции, что и завершение/истечение заявки.
+- Идемпотентность сопоставления: повтор маршрута безопасен (`request_route_matches UNIQUE` + проверки).
+- Кумулятивный учёт покрытия по остатку (без задвоения перекрытий).
+- Тесты: `RouteMatchingServiceTest`, `OutboxPublisherServiceTest`,
+  `RequestStatusOutboxServiceTest`, `RequestExpiryServiceTest`, `RequestRepositoryJpaTest`, `MigrationSchemaTest`.
+
+## Статус работ
+
+Сделано:
+- ✅ **RS1** — устранено (#29): планировщик истечения `RequestExpiryService` + `refreshStatus` при создании.
+- ✅ **RS3** — устранено (#31): `DefaultErrorHandler` + DLQ `pcp.route.georeference-dlq.v1`.
+- ✅ **RS4** — устранено (#32): мёртвый конфиг удалён из `config-repo`.
+- ✅ **RS6** — устранено (#34): проброс `coverageRequiredPercent` из API + разведение терминов.
+- ✅ **RS7** — устранено (#35): единый топик `pcp.request.status.v1` (COMPLETED/EXPIRED) + backoff/cap outbox.
+
+Отложено (осознанно):
+- ⏸ **RS2** (#30) — фильтр совместимости аппарата. Отложено **до #28**: паспорт маршрута не несёт явный `surveyType`, контракт фиксируется в аудите связи сервисов.
+- ⏸ **RS5** (#33) — геодезическая площадь. Отложено до роста требований к точности (переключение `area()` затрагивает matching и тесты; покрытие — отношение площадей).