статусы задач

docs/internal/bookings_stg_code_review.md

@@ -42,27 +42,29 @@
 
 Файлы: `sql/stg/routes_ddl.sql`, `sql/stg/flights_ddl.sql`, `sql/stg/segments_ddl.sql`, `sql/stg/boarding_passes_ddl.sql`.
 
-### 2.2. DQ-проверки ссылочной целостности: “текущий батч” vs “вся история” (статус: зафиксировано и частично усилено)
+### 2.2. DQ-проверки ссылочной целостности: “текущий батч” vs “вся история” (статус: исправлено)
 
 Часть DQ-скриптов проверяет наличие “родительских” записей в таблице **без фильтра `batch_id`**.
 При append-only истории это может скрыть проблемы текущей загрузки:
 родитель был загружен в прошлом батче → проверка пройдёт, даже если текущий батч родителя не загрузил.
 
-Что сделано для справочников (snapshot), которые загружаются каждый запуск:
+Что сделано:
 - `routes_dq.sql`: проверка airports/airplanes стала батч-строгой (`batch_id = текущий батч`).
 - `seats_dq.sql`: проверка airplanes стала батч-строгой (`batch_id = текущий батч`).
 - `flights_dq.sql`: проверка routes стала батч-строгой (`batch_id = текущий батч`).
 
-Почему не всё делаем батч-строго:
-- Для инкрементальных таблиц (например, `segments`) ссылки могут указывать на данные,
-  загруженные в предыдущих батчах → там корректнее проверять “существует в STG вообще”, а не “существует в текущем батче”.
+Примечание (почему не везде `batch_id = текущий батч`):
+- Если дочерняя таблица грузится инкрементом, то ссылки могут указывать на “исторические” записи,
+  загруженные в предыдущих батчах → для таких связей корректнее проверять “существует в STG вообще”.
+- Для `boarding_passes` (full snapshot) ссылки на `tickets/segments` также проверяются по STG-истории,
+  потому что `tickets/segments` не перезагружаются полным снэпшотом каждый запуск.
 
 ### 2.3. Smoke-тесты DAG’ов (статус: исправлено)
 
 Что сделано:
 - Тесты усилены: теперь проверяются ключевые зависимости графа через `get_direct_relatives("downstream")`.
 
-### 2.4. Документация по DAG (статус: синхронизировано базово)
+### 2.4. Документация по DAG (статус: синхронизировано)
 
 Что сделано:
 - `docs/bookings_to_gp_stage.md` обновлён так, чтобы отражать текущий набор таблиц и шагов пайплайна.
@@ -71,11 +73,11 @@
 
 ## 3) Рекомендации по качеству и читаемости (Clean Code для SQL и DAG)
 
-### 3.1. “Empty window” в инкременте: договориться о политике (fail vs skip)
+### 3.1. “Empty window” в инкременте: договориться о политике (fail vs skip) (статус: исправлено)
 
-Сейчас поведение разное:
-- `bookings_dq.sql` / `tickets_dq.sql` / `flights_dq.sql` / `segments_dq.sql` падают, если в окне инкремента 0 строк;
-- `boarding_passes_dq.sql` делает `RAISE NOTICE` и `RETURN`.
+Раньше поведение было разным:
+- часть DQ-скриптов падала, если в окне инкремента 0 строк;
+- `boarding_passes_dq.sql` делал `RAISE NOTICE` и `RETURN`.
 
 Обе стратегии допустимы, но в учебном решении важно выбрать одну и объяснить:
 - **Fail** полезен, когда “ожидаем данные в каждом запуске” (например, учебный генератор должен добавлять день);
@@ -138,7 +140,7 @@ assert airports_load in tickets_dq.get_direct_relatives("downstream")
 ## 5) Чек-лист “готово как эталон”
 
 - [x] В DDL-комментариях нет неверных обещаний про co-location/уникальность ключей.
-- [ ] Для DQ определена и описана политика “0 строк”: где fail, где skip.
+- [x] Для DQ определена и описана политика “0 строк”: где fail, где skip.
 - [x] DQ ссылочной целостности не маскирует проблемы текущего батча (batch-строгие проверки там, где это уместно).
 - [x] `docs/bookings_to_gp_stage.md` соответствует фактическому DAG.
 - [x] Smoke-тесты проверяют хотя бы критические зависимости графа.