feat(etl): добавлен дневной конвейер трансформаций

Зачем:
- Один запуск должен одинаково работать из жизненного цикла, вручную после разгона и повторно после отказа.

Что:
- Добавлена последовательная сцепка DDS и DM с ожиданием каждого слоя.
- DDS дожидается смещений Kafka и очереди доставки ClickHouse за общий срок.
- ETL встроен в создание мира и живой день; документация приведена к новому графу.

Проверка:
- make config-test; make lint.
- make smoke: 21/21; make check-clickhouse: 10/10; make check-services: 7/7.
- make rebuild-storage, живой и пакетный дни, искусственный отказ и ручное восстановление ETL.

docs/adr/0013-world-lifecycle.md

@@ -25,9 +25,11 @@ Kafka, DDL прикладных баз ClickHouse, стартовыми данн
 
 `world_recreate` ставит `-1` до первого удаления и `0` только после успешной
 очистки. `world_initialize` принимает отсутствие позиции или `0`, а значение
-`8` и больше считает готовым миром. Позиция становится `8` последней задачей,
-после генерации стартовых дней и успешного приёма обоих источников. Обычные
-даги движения мира работают только с готовой позицией.
+`8` и больше считает готовым миром. После генерации стартовых дней и успешного
+приема обоих источников позиция становится `8`; затем инициализация последним
+шагом ждет дневной конвейер `etl_pipeline`. При отказе преобразований мир
+остается готовым на позиции `8`, а конвейер после исправления запускают рукой.
+Обычные даги движения мира работают только с готовой позицией.
 
 ## Почему
 
@@ -39,9 +41,10 @@ Kafka, DDL прикладных баз ClickHouse, стартовыми данн
 Kafka сообщения и офсеты прежнего мира.
 
 Airflow уже ведёт последующие дни и приём заказов. Отдав ему начало той же оси,
-получаем один наблюдаемый процесс и одну точку успеха: зелёный
-`world_initialize` означает, что схема создана, стартовый мир принят и его
-следующий день известен.
+получаем один наблюдаемый процесс и одну точку успеха: зеленая ветка создания в
+`world_initialize` подтверждает, что схема создана, стартовый мир принят, его
+следующий день известен, а слои DDS и DM собраны. Короткая ветка готового мира
+по-прежнему подтверждает позицию и ничего не меняет.
 
 ## Что это решение уточняет
 

docs/architecture/dm.md

@@ -125,9 +125,9 @@ Airflow. Партиция — день данных; прогон звена DQ
 `TRUNCATE+INSERT` выполняется той же механикой замены, что и у витрин, —
 ничего отдельного учить не надо.
 
-## Звено DQ конвейера
+## Будущее звено DQ конвейера
 
-Встаёт в `etl_pipeline` после DM ([конвейер](etl.md)) и проверяет только
+Встанет в `etl_pipeline` после DM ([конвейер](etl.md)) и проверит только
 объекты стенда:
 
 - счётная сверка сессий с эталоном `VisitID` — кука × день, эталон читается

docs/architecture/etl.md

@@ -13,8 +13,8 @@
 
 Дневной конвейер на стенде один — даг `etl_pipeline`. Своей работы
 у него нет: он дёргает слойные даги последовательно и ждёт каждый —
-`dds_transform`, затем `dm_transform`. Контур DQ этапа 4 встаёт его же
-звеном после DM; состав звена — в [доке слоя DM](dm.md).
+`dds_transform`, затем `dm_transform`. Будущее звено DQ встанет после DM.
+Его состав описан в [доке слоя DM](dm.md).
 
 Слойные даги устроены по образцу `orders_ingest`: без расписания, один
 активный прогон, запускаются триггером конвейера или рукой при разборе
@@ -22,6 +22,14 @@
 
 ## Три пути запуска
 
+```text
+world_initialize ─┐
+world_live_day ───┼─> etl_pipeline ─> dds_transform ─> dm_transform
+запуск рукой ─────┘
+
+world_next_day ─────> источники без ETL
+```
+
 - **Живой день.** `world_live_day` дёргает конвейер с ожиданием — последним
   шагом, после установки позиции. Порядок несёт смысл: день сыгран — факт,
   упавшая трансформация его не отменяет, поэтому позиция ставится раньше; но
@@ -73,17 +81,26 @@ ODS и ещё не собранный в DDS, затем при необходи
 
 ## Готовность источника
 
-Первым шагом `dds_transform` обязан дождаться, пока хвост топика `hits`
-дожёван: отставание его потребителей нулевое (`system.kafka_consumers`).
-Зелёный приём заказов о событиях не говорит ничего — топики разные и
-потребители разные. В живом режиме зазор ничтожен, но в пакетном генератор
-выстреливает дни в топик быстрее, чем чтец их прожёвывает, и сессии собираются
-по недожёванному дню. DQ-сверка такой день подсветит, но починить его до
-этапа 5 нечем: профилактика дешевле ремонта, которого ещё нет.
+Первый шаг `dds_transform` проходит два барьера за общий срок в 300 секунд.
+Сначала клиент `confluent-kafka` сверяет подтвержденные смещения группы
+`clickstream_hits` с верхними смещениями обоих разделов `hits`. Группа, оба
+раздела и все смещения должны существовать. Суммарное отставание должно стать
+нулевым. Каждый опрос пишет в журнал оба смещения и отставание по разделу.
 
-Шага этого в даге ещё нет — он приезжает отдельным тикетом (#156), и до тех
-пор дыра открыта: сессии считают день прожитым по позиции мира, а хвост потока
-не стережёт никто. На приёмке отставание смотрят руками.
+Только после этого шаг проверяет обе ноды ClickHouse через
+`clusterAllReplicas`: у `ods.event_dist` в `system.distribution_queue` не
+должно остаться файлов. Каждый опрос пишет в журнал ноды, число файлов и
+`last_exception` очереди. Оба барьера опрашиваются раз в три секунды и делят
+один крайний срок. После Kafka срок не отсчитывается заново.
+
+Зелёный приём заказов о событиях не говорит ничего — топики разные и
+потребители разные. Одного нулевого отставания Kafka тоже мало: чтец мог
+подтвердить сообщение раньше, чем Distributed-таблица доставила файл на шард.
+Два барьера закрывают обе части пути до того, как сессии выберут свой объем.
+
+Ждущие вызовы сделаны `TriggerDagRunOperator`. Проверка через Context7 по
+ближайшей доступной документации Airflow 3.x (версия 3.1.6) подтвердила, что
+оператор опрашивает точный созданный им прогон и краснеет вслед за потомком.
 
 ## Идемпотентность
 

docs/architecture/testing.md

@@ -237,6 +237,33 @@ Kafka → STG → ODS, и живёт он в `make check-clickhouse`.
 
 ## Что проверено
 
+**Приемка #156 27 августа 2026 года.** `make rebuild-storage` занял 7 минут.
+На чистом прикладном мире `world_initialize` сам довел позицию до `8`, дождался
+`etl_pipeline` и оставил заполненными DDS и обе витрины. После пересборки прошли
+`make smoke` 21/21 и `make check-clickhouse` 10/10.
+
+Два прогона `world_next_day` не изменили слои; один ручной `etl_pipeline` без
+параметров догнал оба дня. Полный прогон `world_live_day` занял 27 м 2 с и
+завершился только после успешных DDS и DM.
+
+Временная синтаксическая поломка `sql/dm/daily_traffic_rebuild.sql` дала
+красную цепочку: DDS завершился успешно, а `daily_traffic`, DM, `etl_pipeline`
+и `world_live_day` покраснели. После возврата исправного SQL ручной
+`etl_pipeline` без параметров завершился успешно на позиции `12` и восстановил
+слои.
+
+Для проверки пакетного барьера `stg.hits_raw_mv` временно отсоединили командой
+`DETACH` на обеих нодах. После `world_next_day` отставание Kafka составило
+46 367 (19 128 + 27 239). Во время ожидания матвью вернули командой `ATTACH`.
+Журнал готовности записал повторные опросы с отставанием 46 367, затем 27 239
+и 0; после этого очередь `ods.event_dist` содержала 0 файлов на обеих нодах,
+и ETL завершился успешно. Проверка `EXISTS` снова дала `1` на обеих нодах,
+позиция равна `13`.
+
+После пересборки `make check-services` дважды дал 5/1: только импорт Superset
+не уложился в существующий тайм-аут 30 с. Диагностический пробник импорта с
+ожиданием 90 с прошел 3/0. Финальный штатный повтор прошел 7/7 за 129 с.
+
 **Перезамер 21 августа 2026 года при исполнении #124.** Образ Airflow собран с
 `apache-airflow-providers-clickhousedb==1.0.0`,
 `apache-airflow-providers-common-sql==2.0.1` и

docs/specs/2026-08-21-world-lifecycle.md

@@ -20,8 +20,9 @@ DDL и двумя одноразовыми службами заливал во
 
 **Чему учит переезд.** Менти видит один наблюдаемый граф, которому принадлежат
 прикладная схема, данные мира и позиция модельного времени, — и Compose,
-который держит только инфраструктуру. Зелёный `world_initialize` значит ровно
-одно: схема создана, оба источника приняты, следующий день известен.
+который держит только инфраструктуру. Зеленая ветка создания в
+`world_initialize` подтверждает: схема создана, оба источника приняты,
+следующий день известен, слои DDS и DM собраны.
 
 ## Решение
 
@@ -106,11 +107,16 @@ Kafka, `SQLExecuteQueryOperator` для исполняемых SQL-файлов
    приехало» условием не считается.
 7. Отправляет слепки заказов вторым прогоном образа — со сдвигом, дни 0…6
    ([заказы в стартовом мире](../architecture/orders/start-world.md)).
-8. Дёргает `orders_ingest` ждущим триггером и зеленеет только вслед за ним.
-9. Последней успешной задачей ставит позицию в `WORLD_STARTING_DAYS`.
+8. Дергает `orders_ingest` ждущим триггером и продолжает только после его
+   успеха.
+9. Ставит позицию в `WORLD_STARTING_DAYS`: источники приняты, мир уже создан.
+10. Последним шагом дергает `etl_pipeline` ждущим триггером. Конвейер
+    последовательно ждет `dds_transform` и `dm_transform`; отказ слоя красит
+    инициализацию.
 
 Порядок задач связывает проверки: каждый шаг подтверждён предыдущим, а красная
-задача называет место остановки.
+задача называет место остановки. Ветка "мир уже существует" конвейер не
+запускает: обычный повтор `make up` по-прежнему ничего не меняет.
 
 ### `world_recreate` — снести мир и создать заново
 
@@ -163,9 +169,15 @@ Kafka, `SQLExecuteQueryOperator` для исполняемых SQL-файлов
 недействителен и пересборку надо повторить. Стенд обязан назвать незавершённую
 очистку вслух и не продолжать работу молча.
 
-**Очистка прошла, потомок не доработал.** Позиция остаётся `0`. Инициализация
-детерминирована, поэтому следующий `make up` просто пробует её заново — с
-того же места и с тем же результатом.
+**Очистка прошла, создание остановилось до установки позиции.** Позиция
+остаётся `0`. Инициализация детерминирована, поэтому следующий `make up` просто
+пробует её заново — с того же места и с тем же результатом.
+
+**ETL упал после установки позиции.** Мир и оба источника уже готовы, поэтому
+позиция остается в `WORLD_STARTING_DAYS`. После исправления запускают рукой
+`etl_pipeline`: он сам выводит объем из состояния данных. Повторный
+`world_initialize` здесь не поможет: при готовой позиции инициализация уйдет в
+короткую ветку без изменений.
 
 **Позицию в `WORLD_STARTING_DAYS` ставит только успех обоих источников.**
 События доехали, слепки приняты, `orders_ingest` зелёный — тогда и только тогда
@@ -181,10 +193,11 @@ ODS истинно сразу — этим оно и ограничено, об
 заливка» ни один счёт дать не может. Сторожа на этот случай нет: ошибку менти
 делает себе сам и тут же видит.
 
-**Слоты Airflow.** Их четыре, и вложенные ожидания в них укладываются, пока
-пересборка не наложилась на движение мира: `world_recreate` ждёт
-`world_initialize`, тот ждёт `orders_ingest` — три слота из четырёх. Одновременно
-работающий выключатель добавляет свои и загоняет стенд в тупик ожиданий.
+**Слоты Airflow.** Их четыре. При пересборке `world_recreate` ждет
+`world_initialize`, тот ждет `etl_pipeline`, а конвейер ждет слой. В живом
+режиме такую же цепочку образуют `world_live`, `world_live_day`, `etl_pipeline`
+и слой. В обоих случаях три ожидающие задачи оставляют слою последний слот.
+Одновременная пересборка добавляет ожидания и загоняет стенд в тупик.
 Поэтому пересборка — явная операция обслуживания: оператор ставит `world_live`
 на паузу и даёт работникам доиграть. Предусловие остаётся в документации;
 механизм блокировок стоил бы дороже этой строки.
@@ -214,8 +227,8 @@ ODS истинно сразу — этим оно и ограничено, об
   мир уже есть.
 - **`make rebuild-storage`** возвращает канонический мир: позиция проходит
   `-1` → `0` → `WORLD_STARTING_DAYS`, в ODS ровно даты описи, топики созданы
-  заново, офсеты групп идут с нуля. Цена прогона называется числом и сверяется
-  с прежними 2 м 25 с.
+  заново, офсеты групп идут с нуля, DDS и DM собраны. Время прогона измеряется
+  заново.
 - **Красные пути проверяются своими отказами.** Сторож работника при
   отсутствующей, нулевой и отрицательной позиции; `world_initialize` на `-1`;
   оборванная очистка, оставляющая `-1`. Проверка, не видевшая своей поломки,