Сервис принимает данные по окнам видимости космических аппаратов, строит по ним цепочку планов, хранит актуальную выборку в памяти, ведет 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 и нестабильным тестовым состоянием.