3638afdb85
Возврат к модели «настенных часов»: одна ISO-строка без зоны
("2026-05-29T01:00:00") от БД до экрана, никто не привязывает её к
часовому поясу, сдвигаться нечему.
Бэкенд — снять зону с границы API:
- DTO OffsetDateTime/Instant -> LocalDateTime и убрана конвертация
atOffset(ZoneOffset.UTC)/toUtcOffset() в фабриках и мапперах:
tgu PlanResponse/NewChainDTOs/TguPlanningDTO, request RequestApiDtos,
complex ComplexPlanRun*DTO, dynamic ObservationParametersDebugDTO.
- Удалён толерантный Jackson-слой: PcpTimeModule(+autoconfig, ServiceLoader,
imports), PcpTimeModuleV3, LocalDateTimeTimeZoneSerializer; снята их
регистрация в Camunda/Rest/dynamic JacksonConfig. Штатный JSR-310
(JavaTimeModule + WRITE_DATES_AS_TIMESTAMPS=false) оставлен.
- Kafka-конверт KafkaMessage.time сериализуется ISO без офсета.
- mission-planing Mode/SurveyMode/DropMode entity и репозитории/сервис
переведены на LocalDateTime; колонки БД остаются timestamptz (Hibernate
мапит на naive без миграции — прецедент MissionEntity/PlanEntity).
- RequestServiceClient (dynamic) синхронизирован по типу с request-service.
Анти-регрессия: LocalDateTime.now(ZoneOffset.UTC) для серверных штампов
оставлен (выбор настенных часов UTC, не зона на проводе).
Фронт — снять офсет с egress: toUtcIso/фильтры отдают naive без Z
(после удаления толерантного десериализатора штатный парсер падал бы на Z).
Дисплейные хелперы (показ «как пришло», без сдвига) сохранены.
Тесты: контрактные ждут naive ISO; удалены UTC-артефакты (нормализация
офсетов) и тесты прослоек. Удалён docs/standards/DATETIME_UTC.md.
Операционно перед выкатом: сервисы катить согласованно; Kafka-топики с
ранее опубликованным офсетом +00:00 дренировать/проиграть.
6.0 KiB
6.0 KiB
CHECKLIST.md
Назначение
Этот документ содержит краткие checklists для review/merge, Definition of Done, обязательных тестов и validation.
Пункты ниже применяются по принципу where relevant:
- для обычных Kotlin/Spring-изменений достаточно общего checklist;
- для изменений в BPM / Zeebe / Camunda / Kafka / retries / DLQ / compensation / schema evolution дополнительно применяются профильные пункты;
- для критичных процессов глубина проверок и тестов должна быть пропорциональна риску изменения.
Review checklist
Для всех нетривиальных изменений
Перед merge необходимо подтвердить:
- запрошенное поведение реализовано;
- решение осталось в корректной архитектурной границе;
- существующие публичные контракты не сломаны без явного запроса;
- добавлены или обновлены релевантные тесты;
- не внесено несвязанных правок;
- время на API — naive
LocalDateTimeбез зоны; backend штампуетnowчерезLocalDateTime.now(ZoneOffset.UTC), фронт парсит/форматирует черезutils/utcTimeбезnew Date("<строка>"); - egress фронта к бэку — naive ISO (
YYYY-MM-DDTHH:mm:ss, без Z); - validation выполнен по правилам
AGENTS.md, либо пропуски явно объяснены.
Дополнительно для BPM / Kafka / Zeebe / external integration изменений
Перед merge необходимо подтвердить, где это релевантно:
- business key определён и используется консистентно;
- operation id принимается от вызывающей стороны и используется для dedup;
- ошибки классифицированы семантически;
- side effects идемпотентны или явно компенсируются;
- доменные события публикуются через Outbox;
- logs / metrics / traces содержат обязательные поля корреляции;
- тесты покрывают duplicate delivery и retry behavior;
- изменения деплоя и конфигурации трассируемы в VCS.
Definition of Done
Задача считается завершённой только если одновременно выполнено всё ниже, где это релевантно:
Общее
- Запрошенное поведение реализовано.
- Решение осталось в корректной архитектурной границе.
- Нужные тесты добавлены или обновлены.
- Нужный validation выполнен, либо невозможность запуска объяснена.
- Не внесено несвязанных правок.
Для BPM / Kafka / Zeebe / external integration
- BPM остаётся только оркестратором, если BPM участвует.
- Доменные правила остаются внутри сервисной границы.
- Flows остаются безопасными при at-least-once delivery.
- Идемпотентность обеспечена.
operation_idсохранён или добавлен, где это требуется контрактом.- Outbox сохранён или использован, где операция меняет состояние и публикует события.
- Retries ограничены и управляемы.
- DLQ handling сохранён для критичных consumers.
- Versioning / backward compatibility сохранены.
- Observability сохранена или улучшена.
Обязательные тесты для значимых изменений
Базовый минимум
Как минимум покрывать, где применимо:
- happy path;
- изменённые ветки branching / validation logic;
- regression scenario для bug fix.
Дополнительно для BPM / Kafka / Zeebe / external integration
Покрывать, где применимо:
- retryable failure с последующим успехом;
- исчерпание retries;
- ветку business error;
- обработку timeout;
- сценарий compensation;
- duplicate delivery / duplicate event handling;
- contract compatibility;
- schema compatibility.
Для критичных процессов и high-risk изменений
Покрывать пропорционально риску изменения через automated tests и/или явный resilience test plan:
- перезапуск воркера во время выполнения;
- временную недоступность БД;
- временную недоступность внешней зависимости;
- разрыв связности Kafka / BPM;
- сценарий load / lag recovery.
Validation
Следуй разделу Validation commands из AGENTS.md.
Если для изменения есть module-specific команды, используй минимальный релевантный прогон, а затем более широкий, когда это необходимо.
Если какая-либо команда не была запущена:
- точно укажи, какая именно команда не запускалась;
- объясни почему;
- опиши остаточный риск.