Init

2026-05-25 14:23:52 +03:00
parent b3a6012ebb
commit d48ddd2657
1066 changed files with 104601 additions and 3 deletions
@@ -0,0 +1,19 @@
+Сервис принимает данные по окнам видимости космических аппаратов, строит по ним цепочку планов, хранит актуальную выборку в памяти, ведет tracked-состояние планов в Postgres, отдает данные по REST и автоматически запускает Camunda-процесс перед стартом подходящего плана.
+
+Текущий поток работы:
+1. На старте и затем по расписанию сервис подтягивает окна видимости из внешнего API через `ExternalPointsUpdateScheduler.kt` и `ExternalPointsClient.kt`.
+2. Дополнительно сервис принимает обновления по Kafka через `SpacecraftPointsKafkaConsumer.kt`.
+3. Каждое обновление преобразуется в доменную модель и приводит к пересчету цепочки планов через `SpacecraftPointsService.kt` и `PlanCalculationService.kt`.
+4. Актуальные планы хранятся в `PlanRepository.kt`, входные точки по КА в `SpacecraftPointsRepository.kt`.
+5. REST API отдает планы, tracked-статусы, список платформ и диагностическое чтение внешних окон через контроллеры в `controller/`.
+6. `PlanProcessScheduler.kt` периодически проверяет ближайшие планы и запускает BPMN `createSatelliteMission` через `SatelliteMissionProcessService.kt`.
+7. `TrackedPlanService.kt` хранит жизненный цикл плана в таблице `tracked_plan`, а `SpacecraftPlanningStateService.kt` читает состояние текущего базового плана КА из `spacecraft_planning_state`.
+
+Что важно учитывать:
+- Внешний API окон видимости уже подключен, но сервис критически зависит от его доступности и от доступности классификатора платформ.
+- Актуальная расчетная цепочка хранится только в памяти, поэтому после рестарта прогревается заново.
+- Подтвержденные планы и служебное состояние жизненного цикла лежат в Postgres через Flyway migrations `V1`-`V3`.
+- Алгоритм планирования остается упрощенным: он работает по кандидатам, собранным из окон наблюдения, и не выглядит как финальная production-логика оптимизации.
+- В модуле есть тесты, но на момент аудита `./gradlew :services:pcp-tgu-service:test` падает: 5 из 13 тестов красные.
+
+Итог: это рабочий Spring Boot сервис планирования КА с двумя каналами ingest, REST API, tracked persistence и интеграцией с Camunda. Основные ограничения сейчас связаны с in-memory хранением расчетного хвоста, незавершенной логикой around confirmation/base-plan и нестабильным тестовым состоянием.