Files
dc-observatio/docs/standards/CHECKLIST.md
T
Дмитрий Соловьев 3638afdb85 pcp: откат UTC-слоя — сквозной naive LocalDateTime без зоны на проводе
Возврат к модели «настенных часов»: одна 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 дренировать/проиграть.
2026-06-04 00:03:52 +03:00

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

Задача считается завершённой только если одновременно выполнено всё ниже, где это релевантно:

Общее

  1. Запрошенное поведение реализовано.
  2. Решение осталось в корректной архитектурной границе.
  3. Нужные тесты добавлены или обновлены.
  4. Нужный validation выполнен, либо невозможность запуска объяснена.
  5. Не внесено несвязанных правок.

Для BPM / Kafka / Zeebe / external integration

  1. BPM остаётся только оркестратором, если BPM участвует.
  2. Доменные правила остаются внутри сервисной границы.
  3. Flows остаются безопасными при at-least-once delivery.
  4. Идемпотентность обеспечена.
  5. operation_id сохранён или добавлен, где это требуется контрактом.
  6. Outbox сохранён или использован, где операция меняет состояние и публикует события.
  7. Retries ограничены и управляемы.
  8. DLQ handling сохранён для критичных consumers.
  9. Versioning / backward compatibility сохранены.
  10. 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 команды, используй минимальный релевантный прогон, а затем более широкий, когда это необходимо.

Если какая-либо команда не была запущена:

  • точно укажи, какая именно команда не запускалась;
  • объясни почему;
  • опиши остаточный риск.