Дмитрий Соловьев
87905311b1
Базой цепочки план становится на ЗАКЛАДКЕ (LAID_IN), а не на приёмке.
После принятого плана можно отправить коррекцию — она тоже примется;
несколько выдач «в полёте» по одному КА теперь норма, а не конфликт.
- ACCEPT больше не двигает currentBasePlanId/chainVersion и не запирает
слот — только переводит план в AWAITING_LAYIN.
- Новый позитивный топик layin-confirmed + LayinConfirmedConsumer →
handleLayinConfirmed: AWAITING_LAYIN → LAID_IN, план становится базой
(chainVersion++), конкуренты на пересекающемся окне гасятся в новый
терминальный статус SUPERSEDED. Гард ±10 мин (LAYIN_MIN_SEPARATION_MINUTES):
нельзя заложить план со стартом в пределах 10 мин от уже заложенного (409).
- «В полёте» считается из статусов планов (ISSUING/WAITING_DECISION), а не
из единственного active-слота; снят гард «идёт выдача другого плана».
IssueDuePlanWorker гейтится hasBlockingInFlight, базу нового плана берёт
как latestCommittedPlanId; grace больше не двигает базу.
- PlanProjectionService якорит по самому дальнему committed-окну
{ISSUING, WAITING_DECISION, AWAITING_LAYIN, LAID_IN}.
- REJECT ставит паузу только если по КА не осталось живых кандидатов.
- CreateDraftUseCase: replace-черновик наследует ПРЕДШЕСТВЕННИКА исходного
плана (base.basePlanId), а не сам план — коррекция занимает тот же слот;
fork-forward по-прежнему ссылается на базу. Идемпотентность черновиков —
по слоту (КА + окно), а не по basePlanId.
- Тест-контроллер: POST /test/tgu/plans/{id}/confirm-layin (через BFF
pcp-ui-service) — имитация события «план заложен».
- Док PCP_TGU_PLAN_STATUS_LIFECYCLE обновлён (LAID_IN-переход, SUPERSEDED).
config-repo
Файлы в этом подпроекте предназначены для spring-cloud-config-server.
Ожидаемый сценарий:
- этот каталог хранится в GitLab-репозитории с конфигами
spring-cloud-config-serverчитает его черезCONFIG_GIT_URI- сервисы запрашивают конфиги по имени
spring.application.name
Для tle-monitoring-service используются файлы:
tle-monitoring-service.yaml
Пример запроса к Config Server:
GET /tle-monitoring-service/local
Архитектурные договоренности:
pcp-request-serviceявляется единственным owner request/grid-домена.pcp.services.requestдолжен использоваться как основной runtime endpoint для requests/cells/grid.pcp.services.earth-gridсохранен только как legacy alias и должен резолвиться вpcp.services.request.- lifecycle booked slots должен идти Kafka-first; legacy HTTP
/api/slots/booking/processне считается рабочим основным путем. pcp.services.adminуказывает наpcp-srpring-boot-admin-server; сервисы PCP должны регистрироваться в нем через Spring Boot Admin client.