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

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