Merge pull request 'Факультативы в отдельной папке' (#245) from 244-optional-labs into main

Reviewed-on: #245

AGENTS.md

@@ -8,15 +8,26 @@
 Стенд строится по спеке
 [«Боевой реализм стенда (v2)»](docs/specs/2026-07-30-stand-v2-realism.md).
 
-Отсюда вопрос к любой доработке — коду, проверке, документу: **чему на ней
+Стенд рассчитан на начинающих инженеров данных. Они недавно изучили ClickHouse,
-научится менти?** Ответ называется одной фразой до того, как писать. Не
+но почти не работали с ним руками. Здесь они разбирают и достраивают хранилище
+небольшого интернет-магазина: проходят путь от загрузки данных до витрин и BI.
+Программа дает практику общепринятых инженерных приемов. После нее участники
+должны уметь построить похожее хранилище без готового образца. Состав и порядок
+работы задает [программа учебных заданий](docs/specs/2026-09-01-labs-program.md).
+
+Стенд существует только ради обучения. Его поддержка имеет смысл, когда
+сохраняет возможность пройти программу или сама становится учебной задачей.
+Отдельной эксплуатационной ценности у стенда нет.
+
+Отсюда вопрос к любой доработке — коду, проверке, документу: **чему она
+учит?** Ответ называется одной фразой до того, как писать. Не
 складывается фраза — это вопрос владельцу, а не строчка кода: проверки в этом
 репозитории однажды уже переросли продукт.
 
 **Усложнение не бесплатно, и платит за него учебная ценность.** Чем сложнее
-стенд, тем хуже он как учебный материал: внимание менти конечно, и каждая
+стенд, тем хуже он как учебный материал: внимание читателя конечно, и каждая
 конструкция, которую он обязан расшифровать по дороге к уроку, списывается с
-этого счёта. Поэтому вопрос выше имеет вторую половину: **что менти платит,
+этого счёта. Поэтому вопрос выше имеет вторую половину: **что читатель платит,
 чтобы это прочесть, и что получает взамен?** Ответ «вопрос — и ничего»
 означает, что писать не нужно.
 
@@ -157,10 +168,21 @@ Airflow) и названия из кода. Если для понятия ес
   дефис (`clickstream-event.md`). Ни даты, ни номера: документ не событие
   истории, а текущее описание живого формата — и собирается из кода, а не
   пишется руками.
-- Имена файлов в `docs/labs/` — слаг строчными латинскими буквами через дефис
+- Имена файлов основной программы в `docs/labs/` — `S-N-slug.md`:
-  (`top-pages-daily.md`), индекс папки — `README.md`. Здесь живут ТЗ учебных
+  номер ступени, номер задания внутри ступени и слаг строчными латинскими
-  заданий. Ни даты, ни номера: задание — не событие истории, а живой документ,
+  буквами через дефис (`1-2-top-pages-daily.md`). Здесь живут ТЗ
-  и правится он вместе с тем, о чем говорит. Слаг называет предмет задания.
+  учебных заданий. Номера повторяют порядок программы из `README.md`, чтобы
+  папка читалась как оглавление; даты нет: задание — живой документ и
+  правится вместе с тем, о чем говорит. Слаг называет предмет задания.
+  Факультативы живут в `docs/labs/optional/`, без номеров, под одним слагом
+  (`superset-dashboard.md`). Общий индекс обеих частей — `docs/labs/README.md`;
+  отдельного индекса в `optional/` нет.
+- Имена файлов в `docs/handbook/` — слаг строчными латинскими буквами через
+  дефис, индекс папки — `README.md`. Здесь живет путеводитель по стенду:
+  учебные главы для читателя. Ни дат, ни номеров: глава — живой документ и
+  правится вместе с тем, что описывает. Исходники интерактивной карты лежат
+  подпапкой `architecture-map/`, а ее рендер — файлом `architecture-map.html`
+  рядом с главами.
 - Имена файлов в `docs/adr/` — `NNNN-краткое-имя.md`: сквозной номер из четырёх
   цифр и слаг (`0001-stand-services.md`). Решения нумеруются подряд, дата
   в имени не нужна.

CONTEXT.md

@@ -11,6 +11,12 @@
 источников, строится по их документации.
 _Избегать_: склад, склад данных
 
+**Сырые данные**:
+Слой STG хранилища и его содержимое: сообщение топика, положенное строкой,
+как пришло, без разбора. В прозе — сырые данные и сырой слой; про
+конкретную таблицу или базу — STG.
+_Избегать_: сырьё
+
 **Состав мира**:
 Постоянная часть мира генератора — популяция посетителей, их привычки,
 двухкуковые пары. По дням его выдаёт план состава.
@@ -122,13 +128,13 @@ ClickHouse. Форма файла решена, длина — нет: стро
 на нем принимаются следующие этапы.
 _Избегать_: зерновой мир
 
-**Опись мира**:
+**Паспорт мира**:
-`data/world-inventory.json` — единственное, что о мире хранится в git: паспорт
+`data/world-inventory.json` — единственное, что о мире хранится в git: шапка
-мира (зерно, версия генератора, хеш каталога), строка на каждый день событий
+(зерно, версия генератора, хеш каталога), строка на каждый день событий
 (число и хеш байтов) и строка на каждый отправленный слепок (хеш байтов).
 Счётчик сверх этого заводится только с названным читателем. Сам мир не
-хранится, а пересчитывается; опись отвечает на один вопрос: тот ли это мир.
+хранится, а пересчитывается; паспорт отвечает на один вопрос: тот ли это мир.
-_Избегать_: манифест, мини-манифест
+_Избегать_: опись мира, манифест, мини-манифест
 
 **Пошаговый режим**:
 Базовый способ движения по оси модельного времени: «прожить следующий
@@ -137,16 +143,23 @@ _Избегать_: манифест, мини-манифест
 **Живой день**:
 Проигрывание текущего модельного дня в реальном времени с ускорением;
 включается по требованию — постоянным фоном идёт, только пока включён
-выключатель пульта.
+выключатель `world_live`.
 
 **Пакетный режим**:
 Проигрывание готового дня пачкой, без темпа: заливка снимка при старте
 стенда, пересборки и проверки.
 
-**Пульт мира**:
+**Даги модельного времени**:
-Даги Airflow, которыми двигают ось модельного времени: работники играют день —
+Даги Airflow, которыми двигают ось модельного времени: шаговые даги играют
-пачкой или в темпе, — а выключатель держит стенд живущим, пока включён.
+день — пачкой или в темпе, — а выключатель держит стенд живущим, пока включён.
-_Избегать_: управляющие даги
+Коротко — даги времени.
+_Избегать_: пульт мира, управляющие даги
+
+**Шаговый даг**:
+Даг модельного времени, который играет день и ставит позицию на оси:
+`world_next_day` — пачкой, `world_live_day` — в темпе. Запускается руками,
+расписания и паузы не имеет; автоматику поверх него даёт выключатель.
+_Избегать_: работник
 
 **Граница суток**:
 Единственный структурный шов модели: сессии режутся по ней, слепок заказов
@@ -211,6 +224,6 @@ _Избегать_: путать с приёмником и пакетным р
 генератора, про отправку; забор — про сторону хранилища, про чтение.
 
 **Техническая проверка**:
-Проверка, чей оракул — внутренний эталон стенда (опись мира), которого у
+Проверка, чей оракул — внутренний эталон стенда (паспорт мира), которого у
 настоящего магазина нет. За учебный урок DQ не выдаётся.
 _Избегать_: DQ-проверка — та работает на наблюдаемых данных магазина.

Makefile

@@ -51,9 +51,11 @@ config-test:
 # того своя дверь и свой конфиг. Версия закреплена, потому что лока в корне
 # нет, а форматтер между версиями меняет вывод — иначе проверка однажды
 # покраснела бы сама, без единой правки в репозитории.
+# Проверка рендера быстрая, не требует стенда и ловит устаревший HTML.
 lint:
-	uvx ruff@0.16.1 check dags infra/superset
+	uvx ruff@0.16.1 check dags infra/superset docs/handbook/architecture-map
-	uvx ruff@0.16.1 format --check dags infra/superset
+	uvx ruff@0.16.1 format --check dags infra/superset docs/handbook/architecture-map
+	uv run docs/handbook/architecture-map/render.py --check
 
 # --- Наполнение миром ---
 

README.md

@@ -1,22 +1,21 @@
 # Учебная дата-платформа кликстрима
 
-Стенд для работы с кликстримом. Преемник учебного стенда
+> Этим стендом можно пользоваться самостоятельно. Он также входит в
+> [план обучения Data Engineering Roadmap](https://de.dementev.space) как
+> курсовая работа. Если вам нужна помощь, обратитесь к автору материалов —
+> ментору [@dementev_dev](https://t.me/dementev_dev).
+
+Этот стенд — для изучения и экспериментов с кликстримом и ClickHouse. Здесь
+можно проследить весь путь данных: от кликстрима и заказов до витрин, проверок
+и графиков. Это преемник учебного стенда
 [clickstream-ch-kafka-superset-demo](https://git.dementev.space/ddmitry/clickstream-ch-kafka-superset-demo).
 
-## Статус
+В стенде подняты кластер ClickHouse из двух шардов, отдельный keeper, Kafka,
-
+Airflow, Superset, Prometheus и Grafana; события кликстрима и заказы бэкенда
-Репозиторий строится по спеке
+приезжают из генератора и идут по слоям STG → ODS → DDS → DM. `make up`
-[«Боевой реализм стенда (v2)»](docs/specs/2026-07-30-stand-v2-realism.md).
+наполняет стенд стартовым миром — первой неделей модельного времени. Чтобы
-Сейчас работают кластер ClickHouse из двух шардов, отдельный
+разобраться в устройстве, начните с [путеводителя](docs/handbook/README.md), а
-clickhouse-keeper, односерверная Kafka в режиме KRaft, Airflow 3.3, Superset,
+учиться — с [уроков](docs/labs/README.md).
-Prometheus, Grafana, экспортёр метрик Kafka и общая база Postgres для
-метаданных. Генератор кликстрима в [`generator/`](generator/) собран
-целиком со стороны клиента: у него есть контракт схемы события, из которого
-собрано [описание выгрузки](docs/formats/clickstream-event.md), модельный мир и
-проигрыватель, отправляющий дни в Kafka или в файл. События доезжают до
-типизированного `ods.event`, а `dds.event_v` отдаёт их на языке бизнес-модели
-без копии данных. `make up` наполняет стенд стартовым миром — первой неделей
-модельного времени.
 
 ## Быстрый старт
 
@@ -28,33 +27,28 @@ Prometheus, Grafana, экспортёр метрик Kafka и общая баз
 пользователя Windows; после правки нужен `wsl --shutdown`. Если своей машины не
 хватает, стенд одинаково хорошо живёт на недорогом VPS.
 
-Проверкам на поднятом стенде также нужны `curl`, `jq`, `awk`,
+`make up` нужны `curl` и `jq`: первым он ходит в Airflow, вторым читает
-`grep`, `sed`, `tail`, `sleep` и `timeout`. `jq` нужен и самому `make up`: им
+паспорт мира, по которому ждет заливки. По умолчанию должны быть свободны
-читается опись мира, по которой он ждёт заливки. По умолчанию должны быть свободны
 порты `23000`, `28080`, `28088`, `28123`, `28124`, `29000`, `29001`, `29090`
-и `29092`. Проверкам без стенда — `make config-test` и `make lint` в корне,
+и `29092`. Всем целям генератора в `generator/` нужен `uv`.
-всем целям генератора в `generator/` — нужен `uv`.
 
 Сначала скопируйте настройки стенда:
 
 ```bash
 cp .env.example .env
 make up
-make smoke
-make check-clickhouse
-make check-services
 ```
 
-Первому знакомству нужны все три проверки на стенде: `make smoke` говорит, что
+`make up` сам ждет заливки стартового мира; что он делает по шагам и какие
-стенд собран, `make check-clickhouse` — что кластер работает кластером, а
+проверки есть у стенда, описано в [карте
-`make check-services` — что Airflow запускает DAG, а Superset ходит в базу.
+проверок](docs/architecture/testing.md).
-Дальше, в рабочей петле, обычно хватает `make smoke`.
 
 `.env.example` — образец обязательной локальной настройки. В нём живут имя
 экземпляра, внешние порты, учебные учётные данные и ключи. Одно значение образца
 верно не везде — `DOCKER_GID`: у группы `docker` на каждой машине свой номер, и
 свой подскажет `getent group docker`. Пока он не сойдётся, стенд работает весь,
-кроме пульта мира — о нём ниже. `compose.yaml` не
+кроме [дагов модельного
+времени](docs/architecture/world.md#даги-модельного-времени). `compose.yaml` не
 дублирует их умолчаниями: если значения нет в `.env`, Compose сразу предложит
 скопировать образец. Внутренние адреса, имена топиков и версии образов описывают
 сам стенд, поэтому записаны литералами в `compose.yaml` и Dockerfile.
@@ -64,233 +58,7 @@ make check-services
 все локальные данные стенда, а следующий `make up` создаст их с новыми
 значениями.
 
-`make up` собирает локальные образы Airflow, Superset и Grafana, поднимает весь
+## Адреса и пароли
-стенд и ждёт здорового состояния долгоживущих контейнеров. В образ Airflow
-добавлены закреплённые клиенты ClickHouse и Kafka. Одноразовые `airflow-init` и
-`superset-init` завершаются с кодом 0. Первый обновляет схему Airflow,
-подготавливает администратора и два подключения к `clickhouse-01`. Второй
-обновляет Superset, создаёт администратора и импортирует подключение к
-`clickhouse-02`. На ноутбуке в режиме энергосбережения приёмочный подъём с
-пустых томов занял около десяти минут, повторный на живом стенде — около трёх.
-
-`make smoke` за секунды спрашивает, собран ли стенд: зависимости машины,
-здоровье контейнеров, устройство keeper, ответ Kafka с машины через отображённый
-порт, четыре цели Prometheus, два источника Grafana, компоненты Airflow и
-подготовленное подключение к `clickhouse-01`. В конце проверка спрашивает у
-Docker, не убивало ли ядро что-нибудь в долгоживущих контейнерах за нехватку
-памяти и не включалась ли политика перезапуска: убитый контейнер Docker
-поднимает сам, и проверка состояния об этом промолчит.
-
-Двенадцать проверок здоровья сразу после `make up --wait` повторяют то, чего
-Compose уже дождался: у каждой долгоживущей службы есть своя `healthcheck`.
-Оставлены они потому, что первый вопрос к стенду всё равно «всё ли живо», а
-ответ на него стоит меньше секунды. Устройство keeper — другое дело: он должен
-работать от пользователя `clickhouse`, с пределом в 262144 открытых файла и со
-своим томом под данные. Всё это объявлено в `compose.yaml`, но здоровым keeper
-выглядит и без этого, поэтому смоук спрашивает у живого контейнера, дошли ли
-объявленные настройки до процесса.
-
-Kafka по той же причине спрашивают снаружи. Её `healthcheck` обращается к
-брокеру изнутри контейнера и по внутреннему слушателю, поэтому здоровой Kafka
-остаётся и тогда, когда объявленный наружу адрес ведёт не туда. Клиент с машины
-в этом случае подключается, получает метаданные и молча виснет на адресе,
-которого с его стороны не существует. Смоук идёт тем же путём, что и будущий
-генератор: стучится в отображённый порт и просит список топиков.
-
-`make check-services` проверяет то, ради чего приходится ждать службу: работу с
-топиком Kafka с машины — создан, найден, удалён, — ручной запуск пробников
-`test_clickhouse` и `test_kafka`, вход в Superset, его метаданные и подключение
-к `clickhouse-02`. Первый пробник создаёт таблицы на обеих нодах и читает через
-`Distributed` на ноде 2 строку из локальной таблицы ноды 1. Второй пишет в Kafka
-и читает свой маркер. Временный топик проверки с машины и запуски DAG удаляются;
-постоянный топик пробника сохраняется, а старые записи чистит Kafka.
-
-`make check-clickhouse` запускает отдельную глубокую проверку ClickHouse:
-описание кластера, макросы, связь с keeper, `ReplicatedMergeTree`,
-`Distributed`, очередь распределённых DDL и очистку временных таблиц. Девятая
-из десяти проверок спрашивает словарь товаров на обеих нодах. Последняя —
-единственная на настоящих событиях: она подневно сверяет стартовый мир с описью
-и при расхождении говорит, где искать — в событиях или в браке.
-
-`make config-test` проверяет Compose, синтаксис файлов DAG и пробельные ошибки
-в diff без запуска стенда.
-
-Обычный рабочий цикл — `make config-test` и `make smoke`; остальные цели гоняют
-тогда, когда правка их касается. Что утверждает каждая проверка, нужен ли ей
-поднятый стенд, сколько стоит прогон и куда класть новую — в
-[карте проверок](docs/architecture/testing.md).
-
-Остановить контейнеры без удаления данных можно командой `make down`. Если
-нужно вернуть прикладной мир к началу, `make rebuild-storage` запустит в
-Airflow его явную пересборку: удалит прикладные базы ClickHouse, топики и
-позиции потребителей Kafka, затем создаст схему и данные заново. Службы и их
-тома останутся на месте. `make clean` удаляет весь стенд вместе с именованными
-томами и для обычной разработки не нужен. Перед пересборкой поставьте
-`world_live` на паузу и дайте уже начатому работнику закончить день.
-
-## Стартовый мир
-
-Стенд поднимается не пустым: `make up` через REST API запускает даг Airflow
-`world_initialize`. Тот создаёт прикладные топики и схему, собирает образ
-генератора и играет в `hits` первые восемь дней модельного времени — понедельник
-по понедельник, 401 185 событий. Следом второй запуск генератора отправляет в
-`orders` семь слепков — за дни 0…6. Даг ждёт приёма обоих источников и только
-тогда ставит позицию мира в `8`. Так у всякой лабы есть данные, и всегда одни и
-те же.
-
-Последний день намеренно неполон: события дня 7 уже приехали, а его слепок
-уедет только с первым ходом мира. Поэтому на свежем стенде правый край графика
-выручки отстаёт от кликстрима и дозаполняется по мере движения мира — так
-виден разный темп потокового трекера и ночной выгрузки магазина.
-
-Повторный `make up` безопасен: `world_initialize` видит готовую позицию,
-сообщает в журнале, что мир уже существует, и не применяет DDL, не собирает
-образ и не заливает данные повторно. Изменённую схему применяют адресно либо
-явной командой `make rebuild-storage`.
-
-Сам мир в git не хранится — он чистая функция зерна, и держать его в
-репозитории значило бы держать там кэш. Вместо него лежит **опись мира**,
-[`data/world-inventory.json`](data/world-inventory.json): зерно, версия
-генератора, хеш каталога товаров и по строке на каждый день — дата, число
-событий и хеш его байтов. У дней с закрытым окном там же лежат счётчики
-классов расхождений по заказам. Опись отвечает на единственный вопрос: тот ли
-это мир, что был вчера.
-
-Спрашивают её двое. `make test` в `generator/` сверяет опись с тем, что
-собирается из кода сегодня: правка генератора меняет мир, и опись надо
-пересобрать — `make inventory` там же. `make check-clickhouse` в корне сверяет
-с описью то, что доехало до `ods.event`, подневно. Хеш дня можно пересчитать и
-руками — это обычный `sha256sum` файла, который пишет файловый приёмник:
-
-```bash
-uv run --project generator python -m clickstream_generator batch \
-  --day 0 --file tmp/day0.jsonl
-sha256sum tmp/day0.jsonl
-```
-
-## Как позвать генератор
-
-События производит генератор из [`generator/`](generator/). Модельный день —
-функция зерна и номера дня, поэтому один и тот же день всегда даёт те же
-события: обрыв лечится повтором. Позицию на оси генератор не помнит — какой
-день играть, решает зовущий.
-
-Режима два, и различаются они темпом. **Пакетный** гонит день подряд, без пауз:
-так заливается мир и так переигрывается день после обрыва. **Живой** держит темп
-модельного времени — по умолчанию ×60: модельные сутки за 24 реальные минуты,
-суточная волна разворачивается на глазах, отставание видно в логе.
-
-На стенде генератор ходит своим образом — разовой службой, которую поднимают
-и убирают на один прогон. На каждый режим по цели:
-
-```bash
-# день D0 целиком в топик hits
-make generate-batch
-# первая сотня событий дня D3
-make generate-batch GENERATOR_DAY=3 GENERATOR_LIMIT=100
-# день D3 живьём, ускорение ×1000
-make generate-live GENERATOR_DAY=3 GENERATOR_SPEED=1000
-```
-
-| Переменная | Что задаёт | Умолчание |
-| --- | --- | --- |
-| `GENERATOR_DAY` | номер дня на оси мира (D0 — первый) | `0`, задано в `Makefile` |
-| `GENERATOR_LIMIT` | потолок событий на прогон; только `generate-batch` | нет: день целиком |
-| `GENERATOR_SPEED` | ускорение модельного времени; только `generate-live` | ×60, задано в генераторе |
-
-Куда отправлять, обеим целям задаёт сам стенд: внутри сети Compose это брокер
-`kafka:9092` и топик `hits`.
-
-Образ цели не пересобирают: нет образа — Compose соберёт его сам, есть —
-возьмёт как есть. Пересобрать намеренно, после правки `generator/Dockerfile`
-или зависимостей, — отдельной командой:
-
-```bash
-docker compose --profile generator build generator
-```
-
-Тот же образ несёт заливка стартового мира. Перед такой заливкой
-`world_initialize` сам собирает его из текущего дерева; на готовом мире
-повторный `make up` до сборки не доходит.
-
-Разведено это нарочно: собрать образ и запустить контейнер — разные действия, и
-цель запуска, молча пересобирающая образ, стирает между ними границу. Что образ
-устарел, видно по собственному прогону — это обратная связь, а не ловушка.
-
-Посмотреть на события, не поднимая стенд, помогает файловый приёмник: одно
-событие — одна строка. Флаг `--limit` берёт начало дня вместо целого дня —
-тому, кто смотрит на конвейер, ждать полсотни тысяч событий незачем.
-
-```bash
-uv run --project generator python -m clickstream_generator batch \
-  --day 0 --limit 100 --file tmp/day0.jsonl
-```
-
-Несколько дней подряд играет один запуск: `--days 8`. Всё, что принимается
-флагами, принимается и переменными окружения — так генератор позовёт даг
-этапа 5; полный список у `--help`.
-
-**Умолчания есть не у всего, и это нарочно.** Зерно, число дней и темп живого
-дня описывают модель мира — их генератор знает сам. День на оси, приёмник и имя
-топика описывают стенд, на котором его запустили: не назвали — отказ и ненулевой
-код возврата, ещё до первого события. Поэтому умолчание дня и живёт в
-`Makefile`: день называет тот, кто запускает, а не тот, кого запускают.
-
-### Пульт мира
-
-Считать дни самому необязательно. В Airflow живёт **пульт мира**: два дага
-создают его начальное состояние, а три двигают ось дальше.
-
-| Даг | Что делает |
-| --- | --- |
-| `world_initialize` | создаёт стартовый мир, если его ещё нет; повторный запуск ничего не меняет |
-| `world_recreate` | удаляет только прикладной мир и запускает его создание заново |
-| `world_next_day` | играет следующие дни пачкой; сколько — параметр запуска, по умолчанию один |
-| `world_live_day` | играет следующий день в темпе модельного времени, около двадцати четырёх минут |
-| `world_live` | выключатель: пока снят с паузы, дёргает `world_live_day` день за днём |
-
-Работник не только играет день: следом он отправляет слепок заказов за
-сыгранное и дёргает отдельный даг, `orders_ingest`, — тот забирает приехавший
-слепок из топика `orders` в сырьё, — и дожидается его конца. Так две половины
-стенда идут в ногу: упал приём — краснеет и работник, а позиция остаётся на
-месте ([ADR 0008](docs/adr/0008-order-ingestion.md)).
-
-Позицию хранит переменная Airflow `world_position` — номер первого несыгранного
-дня. Ставит её работник, сыгравший день, и только по успеху: оборванный прогон
-позицию не двигает, и следующий запуск играет тот же день заново. Отсутствующая
-переменная означает, что мир ещё не создавали; `-1` — очистка не закончена,
-`0` — очистка закончена, а начальная генерация ещё не завершена. Работники
-начинают играть только с позиции `8` и больше.
-
-В форме запуска можно выбрать только число дней. Первый день работник берет из
-`world_position`. Поля «Logical date» и «Run ID» спрятаны в «Advanced Options».
-Они нужны самому Airflow и на выбор дня не влияют. Сыгранные дни и новую
-позицию работник пишет в журнал шага `remember_played`.
-
-Выключатель создаётся на паузе. Снимите — мир поедет сам; поставите обратно —
-встанет на границе модельных суток, доиграв начатый день. Форма пульта и доводы
-целиком — [ADR 0009](docs/adr/0009-world-control.md).
-
-**Плата названа вслух: планировщику Airflow отдан сокет докера** — иначе
-контейнер генератора ему не поднять. Доступ к сокету равен праву root на
-машине; для локального учебного стенда размен принят, но знать о нём надо.
-Открывает дверь не монтирование, а членство в группе: GID группы `docker` у
-каждой машины свой, живёт в `.env` и подсматривается командой
-`getent group docker`.
-
-## Состав и доступ
-
-- `clickhouse-01` — инициатор DDL и точка подключения Airflow;
-- `clickhouse-02` — точка подключения Superset;
-- `clickhouse-keeper` — координатор кластера;
-- `kafka` — один брокер KRaft;
-- `kafka-exporter` — экспортёр метрик Kafka для Prometheus;
-- `postgres-metadata` — один Postgres с отдельными базами и пользователями
-  `airflow` и `superset`;
-- `airflow-apiserver`, `airflow-scheduler` и `airflow-dag-processor` —
-  Airflow 3.3 с LocalExecutor, без triggerer;
-- `superset` — интерфейс и подготовленное подключение ClickHouse;
-- `prometheus` и `grafana` — сбор и просмотр метрик ClickHouse и Kafka.
 
 С настройками из `.env.example` порты доступны только с локальной машины:
 
@@ -302,122 +70,64 @@ uv run --project generator python -m clickstream_generator batch \
 - Prometheus — `http://127.0.0.1:29090`;
 - Grafana — `http://127.0.0.1:23000`, пользователь `admin`, пароль `admin`.
 
-В ClickHouse семь пользователей и шесть ролей:
+Службы, пользователи и роли, применение настроек и результаты сверки
+конфигурации описаны в [справочнике стенда](docs/architecture/stand.md).
 
-- `etl` подключает рабочие даги Airflow; роль `etl_writer` читает и пишет слои
+## Сдвинуть мир вперед
-  хранилища;
-- `lifecycle` применяет канонический DDL и пересоздаёт прикладные базы; роль
-  `lifecycle_owner` не даёт эти административные права рабочим дагам;
-- `bi` подключает Superset; роль `bi_reader` читает ODS, DDS, DM и справочники
-  `dic`, а запросы Superset обращаются к публичным `_v`;
-- `analyst` предназначен для подключения человека и читает все слои и
-  справочники;
-- `grafana` с ролью `monitoring_reader` подключает Grafana и читает все слои,
-  системные таблицы и данные со всех реплик кластера;
-- `dict` читает только базу `dic` и пароля не имеет: им словарь товаров ходит
-  за своей подложкой;
-- `default` остаётся служебным: им ходят проверки здоровья и скрипты внутри
-  контейнеров, но не приложения.
 
-Почему пользователи объявлены файлом, а ноды доверяют общему секрету, — в
+В Airflow запустите даг `world_next_day`: по умолчанию он сыграет один день, а
-[ADR 0007](docs/adr/0007-clickhouse-access.md).
+в форме запуска можно задать другое число дней. Снимите с паузы `world_live`,
-Пользователи и роли объявлены в `infra/clickhouse/users.d/access.xml`. Пароли и
+и мир поедет сам в темпе модельного времени. Подробности — в [справочнике
-общий секрет нод живут в `.env` и передаются в конфигурацию через окружение;
+мира](docs/architecture/world.md#даги-модельного-времени).
-Superset получает пароль `bi`, а Grafana — пароль `grafana` тем же путём.
-Значения для локального стенда есть в `.env.example`.
 
-Изменения значений ClickHouse в `.env` и файлов настройки серверов в
+## Вернуть мир к началу
-`infra/clickhouse/config.d/` и `infra/clickhouse/users.d/` применяются
-пересозданием нод:
 
-```bash
+`make rebuild-storage` запустит в Airflow явную пересборку: удалит прикладные
-docker compose up --force-recreate --wait clickhouse-01 clickhouse-02
+базы ClickHouse, топики и позиции потребителей Kafka, затем создаст схему
-```
+и данные заново. Службы и их тома останутся на месте. Перед пересборкой
+поставьте `world_live` на паузу и дайте уже начатому шаговому дагу закончить
+день.
 
-Команда возвращает управление, когда обе ноды снова здоровы; именованные тома
+## Выключить или сбросить целиком
-при этом сохраняются. `docker compose restart` оставит прежнее окружение и
-может оставить старую версию отдельно смонтированного файла.
 
-Пароли ClickHouse и интерфейсов, пароли Postgres, ключи Airflow и Superset,
+`make down` остановит контейнеры без удаления данных. `make clean` удалит весь
-отсутствие проверки доступа у Kafka и Prometheus — намеренно простые и явно
+стенд вместе с именованными томами и для обычной работы не нужен.
-ненастоящие настройки локального учебного стенда. Это не пример настройки
-защиты: не копируйте значения из `.env.example` в рабочую среду. Все
-опубликованные порты привязаны только к `127.0.0.1`; Postgres наружу не
-опубликован.
 
-В бою перед репликами ClickHouse обычно был бы балансировщик. Здесь в каждом
+## Подключиться из DBeaver
-шарде одна реплика, поэтому балансировать нечего. Балансировщик и топология
-2×2 намеренно не входят в стенд.
 
-Конфигурация сверена 30 июля 2026 года с официальной документацией ClickHouse:
+Драйвер ClickHouse в DBeaver подключается по JDBC через HTTP-порт. Укажите хост
-[настройками сервера](https://clickhouse.com/docs/operations/server-configuration-parameters/settings),
+`127.0.0.1`, порт `28123`, пользователя `analyst` и пароль из переменной
-[Keeper](https://clickhouse.com/docs/guides/oss/deployment-and-scaling/keeper/),
+`CLICKHOUSE_ANALYST_PASSWORD` в `.env`; в образце это `analyst-26-reader`.
-[ReplicatedMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replication),
+Ко второй ноде — порт `28124`.
-[ON CLUSTER](https://clickhouse.com/docs/sql-reference/distributed-ddl) и
-[Distributed](https://clickhouse.com/docs/engines/table-engines/special/distributed).
-Описание кластера задаётся через `remote_servers`, макросы — через `macros`,
-подключение к keeper — через `zookeeper`; путь `ReplicatedMergeTree` содержит
-`{shard}` и `{replica}`, а `Distributed` получает имя кластера, базу, локальную
-таблицу и ключ шардирования. Макросы выбраны, чтобы один DDL через `ON CLUSTER`
-создавал отдельный путь каждого шарда без вписанных вручную значений. Для
-образа зафиксирован точный текущий
-[LTS-выпуск 26.3.17.56](https://github.com/ClickHouse/ClickHouse/releases/tag/v26.3.17.56-lts);
-серверы и keeper используют один образ. Настройки Kafka 4.3.1 сверены с
-[примером односерверного KRaft](https://github.com/apache/kafka/blob/4.3.1/docker/examples/docker-compose-files/single-node/plaintext/docker-compose.yml).
-Секция метрик взята из конфигурации закреплённого образа ClickHouse и проверена
-на серверах и keeper. Подготовка источников Grafana сверена с
-[официальным описанием автоматической настройки](https://grafana.com/docs/grafana/latest/administration/provisioning/)
-и [документацией плагина ClickHouse](https://grafana.com/docs/plugins/grafana-clickhouse-datasource/latest/configure/).
-Prometheus собирает встроенные метрики двух серверов и keeper, а через
-`kafka-exporter` — состояние Kafka. Поверх этого в Grafana поднимается дашборд
-«Данные»: свежесть, поток, брак, сходимость Kafka с ClickHouse, отставание
-чтения и дневной слепок заказов. Устройство зоны — в [справочнике
-мониторинга](docs/architecture/monitoring/README.md), разбор панелей — в
-[описании дашборда](docs/architecture/monitoring/data.md); правил оповещения
-пока нет.
 
-Airflow закреплён на 3.3.0. Состав обязательных процессов, LocalExecutor,
+Пользователь `analyst` читает все слои и справочники. Нативные порты `29000` и
-публичный `airflow.sdk`, API здоровья и SimpleAuthManager сверены с
+`29001` нужны `clickhouse-client`, но не DBeaver. Остальные пользователи и роли
-[архитектурой Airflow 3.3](https://airflow.apache.org/docs/apache-airflow/3.3.0/core-concepts/overview.html),
+описаны в [справочнике
-[публичным интерфейсом](https://airflow.apache.org/docs/apache-airflow/3.3.0/public-airflow-interface.html)
+стенда](docs/architecture/stand.md#пользователи-и-роли-clickhouse).
-и [описанием здоровья](https://airflow.apache.org/docs/apache-airflow/3.3.0/administration-and-deployment/logging-monitoring/check-health.html).
-Для ClickHouse установлен официальный провайдер Airflow: SQL-файлы исполняет
-общий `SQLExecuteQueryOperator`, программные запросы идут через
-`ClickHouseHook`. Провайдер работает поверх закреплённого
-`clickhouse-connect`. Официальный провайдер Kafka сам использует
-`confluent-kafka`; отдельное подключение и его обёртки здесь не нужны, поэтому
-клиент Kafka добавлен в образ напрямую.
-Superset закреплён на 6.1.0; драйвер `clickhouse-connect`, форма
-`clickhousedb://` и драйвер Postgres сверены с
-[документацией подключений Superset](https://superset.apache.org/user-docs/6.1.0/databases/)
-и [настройкой базы метаданных](https://superset.apache.org/admin-docs/6.1.0/configuration/configuring-superset/).
-
-## Что здесь будет
-
-- одно широкое событие кликстрима по образцу выгрузки Яндекс Метрики вместо
-  четырёх топиков;
-- второй источник — заказы бэкенда, ежедневным слепком в ту же Kafka;
-- сверка клиентской покупки с заказом бэкенда: деньги считаем по бэкенду,
-  поведение и атрибуцию — по трекеру;
-- анонимный кликстрим и склейка кука↔пользователь через покупки;
-- ClickHouse кластером как единственным режимом.
-
-## Чем отличается от предшественника
-
-Предшественник остаётся стабильным учебным стендом и заморожен для новых фич:
-там событие разрезано на четыре топика, есть только просмотры страниц,
-посетители опознаны по email, ClickHouse — одна нода. Развитие идёт здесь.
 
 ## Документация
 
+- [docs/handbook/](docs/handbook/) — путеводитель по стенду и порядок чтения.
+- [docs/labs/](docs/labs/) — учебные задания с порядком прохождения и
+  самопроверкой.
 - [docs/specs/](docs/specs/) — спеки: источник истины о задуманном.
 - [docs/adr/](docs/adr/) — принятые решения с доводами и отвергнутыми
   вариантами: почему сделано так, а не иначе.
 - [docs/architecture/](docs/architecture/) — рабочие справочники по зонам
-  ответственности: [хранилище](docs/architecture/storage.md) — конвенции имён,
+  ответственности:
-  раскладка по шардам, приём событий, карта таблиц;
+  - [хранилище](docs/architecture/storage.md) — конвенции имён, раскладка по
-  [проверки](docs/architecture/testing.md) — что утверждает каждая цель `make`
+    шардам, приём событий, карта таблиц.
-  и куда класть новую проверку.
+  - [конвейер](docs/architecture/etl.md) — движение данных между слоями и
+    работа дагов.
+  - [мир и модельное время](docs/architecture/world.md) — начальные данные,
+    ход дней и управление генератором.
+  - [стенд](docs/architecture/stand.md) — службы, доступ и настройка.
+  - [проверки](docs/architecture/testing.md) — что утверждает каждая цель
+    `make` и куда класть новую проверку.
+  - [мониторинг](docs/architecture/monitoring/README.md) — сбор метрик и
+    устройство дашборда.
+  - [Superset](docs/architecture/superset.md) — подключения, наборы данных и
+    граница автоматической настройки.
 - [docs/research/](docs/research/) — исследования; сейчас это формат
   кликстрима Яндекса, по которому строится модель события.
 - [docs/formats/](docs/formats/) — описания форматов источников: по ним

compose.yaml

@@ -34,7 +34,7 @@ x-clickhouse-common: &clickhouse-common
     retries: 30
     start_period: 10s
 
-# Факты генератора и пульта мира названы по одному разу — иначе они однажды
+# Факты генератора и дагов модельного времени названы по одному разу — иначе они однажды
 # разойдутся, и заметит это не проверка, а менти с пустым топиком.
 x-generator-image: &generator-image clickstream-generator:local
 x-orders-topic: &orders-topic orders
@@ -70,7 +70,7 @@ x-airflow-common: &airflow-common
     AIRFLOW_ADMIN_PASSWORD: ${AIRFLOW_ADMIN_PASSWORD:?Скопируйте .env.example в .env}
     CLICKHOUSE_ETL_PASSWORD: ${CLICKHOUSE_ETL_PASSWORD:?Скопируйте .env.example в .env}
     CLICKHOUSE_LIFECYCLE_PASSWORD: ${CLICKHOUSE_LIFECYCLE_PASSWORD:?Скопируйте .env.example в .env}
-    # Пульт мира поднимает генератор отдельным контейнером. Имя сети собирается
+    # Даги времени поднимают генератор отдельным контейнером. Имя сети собирается
     # из имени проекта: у второй копии стенда оно другое.
     <<: *kafka-target
     GENERATOR_IMAGE: *generator-image
@@ -291,7 +291,7 @@ services:
       airflow-init:
         condition: service_completed_successfully
     command: scheduler
-    # Пульт мира зовёт генератор отдельным контейнером, а при LocalExecutor
+    # Даги времени зовут генератор отдельным контейнером, а при LocalExecutor
     # задачи исполняет сам планировщик — значит сокет докера нужен ему одному.
     # Плата названа вслух в README и ADR 0009: доступ к сокету равен праву root
     # на машине. Открывает дверь не монтирование, а группа: у сокета права 660

dags/dds_transform.py

@@ -46,8 +46,8 @@ HITS_PARTITIONS = (0, 1)
 READINESS_TIMEOUT_SECONDS = 300
 READINESS_POLL_SECONDS = 3
 
-# Позиция на оси модельного времени: номер первого несыгранного дня. Её ставит
+# Позиция на оси модельного времени: номер первого несыгранного дня. Её ставят
-# пульт мира, и только она отличает прожитый день от живого — зачем это
+# даги модельного времени, и только она отличает прожитый день от живого — зачем это
 # сессиям, разобрано в sql/dds/session_scope.sql.
 WORLD_POSITION = "world_position"
 
@@ -224,8 +224,8 @@ def _wait_for_phase(
 def _world_position() -> int:
     """Позиция мира числом, с внятным отказом на непригодном значении.
 
-    Ту же переменную читает пульт, но общего модуля у дагов нет намеренно:
+    Ту же переменную читают даги времени, но общего модуля у дагов нет намеренно:
-    связь между пультом и трансформацией держит сама переменная, а не импорт.
+    связь между дагами времени и трансформацией держит сама переменная, а не импорт.
     """
     raw_position = Variable.get(WORLD_POSITION, default=None)
     if raw_position is None:

dags/dq_check.py

@@ -148,7 +148,7 @@ def build_classes_vs_inventory() -> list[str]:
         for mismatch_class, count in day["orders"].items()
     }
     if not expected:
-        raise AirflowException("classes_vs_inventory: в описи нет закрытых дней")
+        raise AirflowException("classes_vs_inventory: в паспорте нет закрытых дней")
 
     query = (SQL_ROOT / "dq" / "classes_vs_inventory.sql").read_text(encoding="utf-8")
     # GROUP BY закономерно не возвращает группу из нуля строк.

dags/homework_check.py

@@ -109,28 +109,28 @@ def homework_check():
     """Дать отдельный результат самопроверки по каждой домашней витрине."""
     check_mart.override(task_id="events_enriched")(
         "dm.events_enriched_v",
-        "docs/labs/events-enriched.md",
+        "docs/labs/1-1-events-enriched.md",
         "events_enriched_vs_dds.sql",
         "events_enriched_scope.sql",
     )
     check_mart.override(task_id="top_pages_daily")(
         "dm.top_pages_daily_v",
-        "docs/labs/top-pages-daily.md",
+        "docs/labs/1-2-top-pages-daily.md",
         "top_pages_daily_vs_dds.sql",
     )
     check_mart.override(task_id="session_overview")(
         "dm.session_overview_v",
-        "docs/labs/session-overview.md",
+        "docs/labs/1-3-session-overview.md",
         "session_overview_vs_dds.sql",
     )
     check_mart.override(task_id="dq_errors_daily")(
         "dm.dq_errors_daily_v",
-        "docs/labs/dq-errors-daily.md",
+        "docs/labs/1-4-dq-errors-daily.md",
         "dq_errors_daily_vs_ods.sql",
     )
     check_mart.override(task_id="utm_effectiveness")(
         "dm.utm_effectiveness_v",
-        "docs/labs/utm-effectiveness.md",
+        "docs/labs/1-5-utm-effectiveness.md",
         "utm_effectiveness_vs_dds.sql",
     )
 

dags/orders_ingest.py

@@ -1,9 +1,9 @@
 """Приём заказов: пакетный забор слепка из Kafka в хранилище.
 
 Путь Kafka → STG → ODS у заказов один и живёт одним дагом: сначала забор
-порции в сырьё, затем разбор того же среза в типизированный ODS и в таблицу
+порции в `stg`, затем разбор того же среза в типизированный ODS и в таблицу
 брака. Расписания у дага нет: его дёргает тот, кто положил слепок в топик, —
-работник пульта мира после проигрыша дня, — и ждёт конца.
+шаговый даг модельного времени после проигрыша дня, — и ждёт конца.
 
 Контраст с приёмом событий и есть урок. События тянет матвью, навсегда
 подписанная на чтеца: приём идёт сам, пока идёт поток. Слепок заказов

dags/world_control.py

@@ -1,25 +1,25 @@
-"""Пульт мира: даги, которыми двигают ось модельного времени.
+"""Даги модельного времени: ими двигают ось мира.
 
-Их три, и они двух родов. **Работники** играют день и запускаются руками:
+Их три, и они двух родов. **Шаговые даги** играют день и запускаются руками:
 `world_next_day` — пачкой, без пауз, сколько дней попросили; `world_live_day` —
 один день в темпе модельного времени. **Выключатель** `world_live` своей работы
-не делает: он тикает по расписанию и дёргает работника живого дня, дожидаясь
+не делает: он тикает по расписанию и дёргает шаговый даг живого дня, дожидаясь
 конца. Снят с паузы — мир едет день за днём; поставлен на паузу — встал на
 границе модельных суток.
 
 Сыграть день — половина работы. Вторая половина: отправить слепок заказов и
-дождаться, пока хранилище его заберёт. Поэтому у обоих работников за проигрышем
+дождаться, пока хранилище его заберёт. Поэтому у обоих шаговых дагов за проигрышем
 идут отправка слепка тем же контейнером генератора и ждущий триггер дага приёма
 `orders_ingest`.
 
 Живой день после установки позиции дожидается еще и `etl_pipeline`. Пачка
 только разгоняет источники: слои после нее менти догоняет ручным запуском.
 
-Разделение не косметическое. Расписание на самом работнике заставило бы кнопку
+Разделение не косметическое. Расписание на самом шаговом даге заставило бы кнопку
-паузы значить две вещи разом — «мир не едет сам» и «даг выключен», — а работник
+паузы значить две вещи разом — «мир не едет сам» и «даг выключен», — а шаговый даг
 при этом выглядел бы в списке выключенным, хотя нажимают его каждый день.
 
-Календарь Airflow к оси мира отношения не имеет: какой день играть, работник
+Календарь Airflow к оси мира отношения не имеет: какой день играть, шаговый даг
 спрашивает у переменной, а не у логической даты прогона.
 
 Решения и доводы целиком — ADR 0009.
@@ -51,7 +51,7 @@ ORDERS_TOPIC = os.environ["KAFKA_ORDERS_TOPIC"]
 STARTING_DAYS = int(os.environ["WORLD_STARTING_DAYS"])
 
 # Позиция на оси: номер первого несыгранного дня. До конца инициализации
-# работники не имеют права угадывать её — состояние объяснено в ADR 0013.
+# шаговые даги не имеют права угадывать её — состояние объяснено в ADR 0013.
 #
 # Позиция ставится, а не увеличивается. Наложись один прогон на другой, худшее
 # при таком правиле — сыгранный дважды день, а повтор схлопнет
@@ -63,12 +63,12 @@ WORLD_POSITION = "world_position"
 # двадцати четырёх минут: тик только спрашивает «не пора ли снова».
 LIVE_TICK = datetime.timedelta(minutes=25)
 
-# Какой день играть, работник узнаёт у первой задачи. Спрашивают её все
+# Какой день играть, шаговый даг узнаёт у первой задачи. Спрашивают её все
 # генераторные шаги: слепок снимается с той же позиции, что и проигрыш.
 PLAYED_DAY = "{{ ti.xcom_pull(task_ids='first_unplayed_day') }}"
 
 START_DATE = datetime.datetime(2026, 1, 1, tzinfo=datetime.UTC)
-TAGS = ["пульт мира"]
+TAGS = ["модельное время"]
 
 
 @task
@@ -120,7 +120,7 @@ def _generator(task_id: str, command: list[str]) -> DockerOperator:
 def _ingest_orders() -> TriggerDagRunOperator:
     """Задача забора: дёрнуть даг приёма и дождаться, чем он кончился.
 
-    Ожидание здесь несущее. Без него работник позеленел бы, не узнав, доехал
+    Ожидание здесь несущее. Без него шаговый даг позеленел бы, не узнав, доехал
     ли слепок, и позиция мира ушла бы вперёд хранилища — а зелёный конец графа
     не должен переживать отказ выше (ADR 0003).
     """
@@ -128,7 +128,7 @@ def _ingest_orders() -> TriggerDagRunOperator:
         task_id="trigger_orders_ingest",
         trigger_dag_id="orders_ingest",
         wait_for_completion=True,
-        # Умолчание — минута опроса, а весь прогон работника пачкой короче.
+        # Умолчание — минута опроса, а весь прогон шагового дага пачкой короче.
         poke_interval=10,
     )
 
@@ -151,7 +151,7 @@ def _ingest_orders() -> TriggerDagRunOperator:
             # (params.rst, Airflow 3.3), чтобы правило было видно сразу.
             description_md=(
                 "Форма задает только число дней. Номер первого несыгранного "
-                "дня работник берет из переменной `world_position` (Admin → "
+                "дня шаговый даг берёт из переменной `world_position` (Admin → "
                 "Variables). Поля Logical date и Run ID нужны самому Airflow "
                 "и на выбор дня не влияют."
             ),
@@ -163,7 +163,7 @@ def world_next_day():
 
     Запускается руками. День по умолчанию один, но разгон вперёд идёт одним
     нажимом, а не десятью: сколько дней играть — параметр запуска. Первый
-    день работник берет из `world_position`. Логическая дата прогона на выбор
+    день шаговый даг берёт из `world_position`. Логическая дата прогона на выбор
     дня не влияет.
     """
 
@@ -215,7 +215,7 @@ def world_live_day():
     Ускорение ×60: модельные сутки укладываются примерно в двадцать четыре
     реальные минуты, и суточная волна разворачивается на глазах. Запускается
     руками; чтобы мир жил так день за днём сам, есть выключатель `world_live`.
-    Следующий день работник берет из `world_position`. Логическая дата прогона
+    Следующий день шаговый даг берёт из `world_position`. Логическая дата прогона
     на выбор дня не влияет.
     """
 

dags/world_lifecycle.py

@@ -185,7 +185,7 @@ def world_initialize():
 
     @task
     def wait_for_events() -> None:
-        """Дождаться приёма всех событий описи, включая строки брака."""
+        """Дождаться приёма всех событий паспорта, включая строки брака."""
         inventory = json.loads(INVENTORY.read_text(encoding="utf-8"))
         expected = sum(day["events"] for day in inventory["days"])
         first_date = inventory["days"][0]["date"]

docs/adr/0005-event-ingestion.md

@@ -2,6 +2,10 @@
 
 Дата: 3 августа 2026 года. Статус: принято.
 
+Позднее тикет #214 сменил имя слоя: вместо «сырья» — сырые данные, сырой слой,
+STG. Текст ниже оставлен в словах своего времени, действующее имя — в
+`CONTEXT.md`.
+
 ## Решение
 
 Топик `hits` читает одна Kafka-таблица формата `RawBLOB`: непустое сообщение

docs/adr/0007-clickhouse-access.md

@@ -43,7 +43,7 @@
 Сетевых ограничений на `default` нет: порты стенда и так открыты только на
 `127.0.0.1`, а внутри сети Compose дверь заперта паролем.
 
-Раздел README «Состав и доступ» описывает, кто каким пользователем ходит и где
+Раздел README «Адреса и пароли» описывает, кто каким пользователем ходит и где
 живут пароли; здесь остаются решение и доводы. Отдельного справочника по
 доступу в `docs/architecture/` нет: точные права видны в `access.xml`, конвенция
 чтения через `_v` описана в доке хранилища.
@@ -107,7 +107,7 @@
 источник истины — файл в git. Стенд считает `access.xml` и переданные через
 `.env` значения настройкой при создании контейнера; отдельного способа
 применять их на живом стенде нет, потому что уроки не меняют базовую модель
-доступа. Порядок применения изменений — в разделе README «Состав и доступ».
+доступа. Порядок применения изменений — в разделе README «Адреса и пароли».
 Оба варианта с SQL — локальное хранилище доступа с `ON CLUSTER` и
 реплицированное в keeper — делают пользователей состоянием тома: `.env` на
 них больше не влияет, и появляется расхождение того же сорта, которое README

docs/adr/0008-order-ingestion.md

@@ -3,6 +3,10 @@
 Дата: 12 августа 2026 года. Статус: частично заменено
 [ADR 0010](0010-order-versions-in-ods.md); забор построен тикетом #93.
 
+Позднее тикет #214 сменил имена: «сырьё» стало сырыми данными, «работник» —
+шаговым дагом. Текст ниже оставлен в словах своего времени, действующие
+имена — в `CONTEXT.md`.
+
 Сохраняются пакетный забор, `RawBLOB`, один чтец на `clickhouse-01`, одна
 партиция топика и отсутствие матвью. Отменены граница «одно чтение — полный
 слепок», замена партиции `snapshot_date`, ODS без дедупликации и готовая схема

docs/adr/0009-world-control.md

@@ -2,6 +2,10 @@
 
 Дата: 13 августа 2026 года. Статус: принято. Реализация — тикет #79.
 
+Позднее тикет #214 сменил имена: «пульт мира» стал дагами модельного времени,
+«работник» — шаговым дагом. Текст ниже оставлен в словах своего времени,
+действующие имена — в `CONTEXT.md`.
+
 ## Решение
 
 Ось модельного времени двигают даги пульта, и они двух родов.

docs/architecture/dds/event.md

@@ -77,9 +77,9 @@ ODS; точный тип и проверка описаны в разделе
 - **`Sign`** — колонка формата без механики: генератор исправлений не шлёт,
   и в модели события колонке ответить нечего. Честный рассказ о ней живёт в
   DDL ODS и лекции.
-- **`ecommerce`** — сырой JSON: сырьё, а не атрибут. Разобранные массивы
+- **`ecommerce`** — сырой JSON из STG. Это содержимое источника; отдельным
-  `purchase_*` и `product_*` в контракте есть; лаба про разбор JSON внутри
+  атрибутом модели оно не становится. Разобранные массивы `purchase_*` и
-  колонки читает ODS.
+  `product_*` в контракте есть; лаба про разбор JSON внутри колонки читает ODS.
 - **`_load_ts`** — у представления нет собственной загрузки, а чужие
   координаты слой не переносит (правило слоя — [модель
   заказа](order.md), «Служебные колонки»); расследование спрашивает ODS по

docs/architecture/dds/order.md

@@ -75,12 +75,12 @@ ODS: это единственный устойчивый ключ сущнос
 **служебные колонки — координаты собственной загрузки слоя; чужие координаты
 спрашиваются у их слоя по ключу сущности**.
 
-Происшествие качества данных расследуется цепочкой, где каждый шаг
+Происшествие качества данных расследуется цепочкой, где каждый шаг спрашивает
-спрашивает свой слой на его языке: по `_load_id` строки DDS видно, какой
+свой слой на его языке: по `_load_id` строки DDS видно, какой запуск собрал
-запуск собрал день; по `order_id` ODS показывает физические версии и брак —
+день; по `order_id` ODS показывает физические версии и брак — там свой
-там свой `_load_id` приёма связывает годные строки, ошибки и сырьё; дальше
+`_load_id` приёма связывает годные строки, ошибки и данные STG; дальше читают
-сырьё STG, пока живо. Окно расследования задано сроками хранения: сырьё —
+STG, пока данные живы. Окно расследования задано сроками хранения: сырые данные
-трое суток, брак — месяц ([дока хранилища](../storage.md)).
+— трое суток, брак — месяц ([дока хранилища](../storage.md)).
 
 ## Читатели
 

docs/architecture/dds/session.md

@@ -111,7 +111,7 @@
 
 - Витрина обзора сессий `session_overview_v`: дневные итоги визитов в
   срезе устройств; читает `dds.session_v` и поднимает зерно до дня — состав и довод
-  в ее [ТЗ](../../labs/session-overview.md) (#135).
+  в ее [ТЗ](../../labs/1-3-session-overview.md) (#135).
 - DQ-сверка с эталоном (см. выше).
 - Лаба сессий: менти собирает нарезку сам до знакомства с кодом стенда,
   потом сравнивает — с эталоном и со стендовой.

docs/architecture/dm.md

@@ -5,24 +5,27 @@
 колонок каждой витрины задаёт раздел 7 мастер-спеки; здесь — форма,
 наполнение и контроль.
 
-## Форма: по зерну, не по цене запроса
+## Таблица или представление
 
-Витрина, меняющая зерно источника — дневной агрегат, сверка по заказам, —
+Дневной агрегат и сверка по заказам меняют зерно источника. На этом стенде такие
-материализуется: `dm.<имя>_rep` / `_dist` и публичное `dm.<имя>_v` с явным
+результаты хранятся в `dm.<имя>_rep` / `_dist` и читаются через публичное
-списком колонок, по общим [конвенциям хранилища](storage.md). Наполняет её
+представление `dm.<имя>_v` с явным списком колонок. Имена и устройство объектов
-`dm_transform`; ритм и механика пересборки — ниже. Витрина, сохраняющая зерно
+следуют общим [конвенциям хранилища](storage.md). Таблицы наполняет
-источника — переименование, обогащение строки, — остаётся обычным
+`dm_transform`; ритм и механика пересборки описаны ниже. В задании этот путь
-представлением: копию событий ради других имён колонок не держит ни один
+приходится пройти целиком: рассчитать агрегат, загрузить его и включить
-боевой склад.
+обновление в конвейер.
 
-Правило выбрано учебной целью, а не ценой запроса. На объёмах стенда
+Переименование колонок и обогащение строки зерно не меняют. Такие витрины на
-представлениями обошлось бы всё: условия сквозь цепочку представлений
+стенде остаются обычными представлениями и не хранят вторую копию событий.
-проходят ([исследование](../research/2026-08-22-view-predicate-pushdown.md)).
-Но пересборка агрегатов конвейером — производственный паттерн, ради
-которого стенд и строится, а пара «таблица рядом с представлением»
-показывает: форма — решение по роли витрины, у одного слоя законны обе.
 
-## Кто строит: стенд и менти
+На объёмах стенда все витрины могли бы остаться представлениями: условия
+проходят сквозь их цепочку
+([исследование](../research/2026-08-22-view-predicate-pushdown.md)).
+Мы все равно оставили материализованные агрегаты ради практики: без них в
+программе не было бы загрузки и пересборки витрин. Представления дают другой
+случай: преобразование строк на прежнем зерне.
+
+## Что готово в стенде, а что остаётся заданием
 
 Стенд привозит готовыми витрины трёх сюжетов дашборда этапа 8 и
 инфраструктуру контроля:
@@ -35,20 +38,20 @@
   [картой идентичностей](dds/identity.md);
 - `dq_summary` — сводка проверок качества (ниже).
 
-Остальные витрины спеки — учебные задания: менти строит их сам по ТЗ с
+Остальные витрины спеки нужно построить в учебных заданиях по готовому ТЗ и
-образцом. Разминка — представление `events_enriched_v` (зерно события),
+образцу. Разминка — представление `events_enriched_v` (зерно события), затем
-затем агрегаты `top_pages_daily`, `session_overview` и `dq_errors_daily`,
+агрегаты `top_pages_daily`, `session_overview` и `dq_errors_daily`, последней —
-последней — самая содержательная `utm_effectiveness` с уроком `declared_*`.
+самая содержательная `utm_effectiveness` с уроком `declared_*`. В финале
-Построенная витрина встаёт в конвейер руками менти: финальный пункт ТЗ
+каждого задания с агрегатом его задачу нужно добавить в `dm_transform`. До
-каждого агрегата — добавить задачу своей витрины в `dm_transform`. До этого
+этого конвейер о витрине не знает, после — пересобирает её вместе со
-конвейер о ней не знает и остаётся зелёным, после — витрина пересобирается
+стендовыми. Представление из разминки добавлять некуда: его не нужно
-наравне со стендовыми. У разминочного представления такого пункта нет:
+пересобирать. Тексты заданий лежат в [`docs/labs/`](../labs/README.md).
-пересобирать нечего. Тексты заданий — в [`docs/labs/`](../labs/README.md).
 
-Дашборд этапа 8 стоит только на витринах стенда: приёмка этапа не зависит
+Дашборд этапа 8 читает только готовые витрины стенда, поэтому его приёмка не
-от выполненных домашек. Свой дашборд по витринам менти —
+зависит от домашних заданий. Отдельный дашборд по учебным витринам можно
-[необязательная лаба](../labs/superset-dashboard.md) после этапа 8. Устройство
+собрать в [факультативном задании](../labs/optional/superset-dashboard.md),
-стендового дашборда — в [доке зоны Superset](superset.md).
+доступном после ступени 2. Устройство стендового дашборда описано в
+[справочнике Superset](superset.md).
 
 ## Ритм пересборки
 
@@ -176,9 +179,10 @@ Distributed-таблица вернула бы каждый непарный з
   `uniqExact(VisitID)` из `ods.event_v`, объект — число строк
   `dds.session_v`;
 - `classes_vs_inventory`: ключ — `mismatch_class`, эталон — счётчик из
-  `orders` в описи мира, объект — число заказов класса в
+  `orders` в паспорте мира, объект — число заказов класса в
   `dm.purchase_vs_orders_v`. Проверяются `match`, `cancelled`, `lost_event`,
-  `duplicate_event` и `amount_delta` только для покрытых описью закрытых дней;
+  `duplicate_event` и `amount_delta` только для покрытых паспортом закрытых
+  дней;
 - `revenue_daily_vs_dds`: ключ — `product_category` внутри дня. Сравниваются
   `orders`, `units`, `revenue` и `aov` с прямым агрегатом `dds.order_v`;
 - `purchase_vs_orders_vs_dds`: ключ — `order_id` внутри дня. Все деловые
@@ -194,14 +198,14 @@ Distributed-таблица вернула бы каждый непарный з
 сопоставления деловых ключей.
 
 `classes_vs_inventory` — техническая растяжка пути от генератора до DM. Она
-подтверждает, что до витрины доехал записанный в описи мир, но не проверяет
+подтверждает, что до витрины доехал записанный в паспорте мир, но не проверяет
 сам генератор: у настоящего магазина такого оракула нет.
 
-Четыре SQL-сверки считают дневные итоги в ClickHouse и возвращают Airflow
+Четыре SQL-сверки считают дневные итоги в ClickHouse и возвращают Airflow только
-только сводку и малый срез диагностики. Техническая сверка с описью читает
+сводку и малый срез диагностики. Техническая сверка с паспортом читает небольшой
-небольшой файл JSON в Python. Все пять сборок пишут в общий донор. После их
+файл JSON в Python. Все пять сборок пишут в общий донор. После их успеха даг
-успеха даг заменяет проверенные дневные партиции. Затем именованные задачи
+заменяет проверенные дневные партиции. Затем именованные задачи читают
-читают опубликованную сводку и падают при `failed_rows > 0`. Расхождение успевает
+опубликованную сводку и падают при `failed_rows > 0`. Расхождение успевает
 сохраниться до красного завершения, а ошибка сборки не затирает прежний
 результат. Красная задача печатает не больше двадцати нарушенных ключей за
 проверку со значениями сторон. Для полного списка итоговую агрегацию SQL-сверки
@@ -214,8 +218,8 @@ business_key`.
 
 ## Даг самопроверки
 
-Домашки контролирует `homework_check` — отдельный даг без расписания: менти
+Домашние задания проверяет `homework_check` — отдельный даг без расписания,
-запускает его рукой. По задаче на каждое из
+который запускают вручную. В нём есть задача для каждого из
 [пяти заданий по витринам](../labs/README.md).
 Задача красная, пока витрины нет или счёт не сходится, и зелёная, когда
 построено верно; сообщение об ошибке говорит, что не так и куда смотреть. Проверки — инварианты против источников витрины,
@@ -223,8 +227,8 @@ business_key`.
 лабы, а не история качества конвейера.
 
 Приём проверен на соседнем учебном стенде Airflow + Greenplum:
-валидационный даг с группами проверок по слоям давал менти обратную связь
+валидационный даг с группами проверок по слоям давал обратную связь по каждому
-по каждому шагу домашки, не трогая рабочий конвейер.
+шагу задания, не трогая рабочий конвейер.
 
 ## Отклонённые варианты
 
@@ -232,7 +236,7 @@ business_key`.
   производственный паттерн слоя — пересборка агрегатов — остался бы
   невидим, а `dm_transform` — без работы.
 - **Материализовать всё.** Копия событий ради переименования колонок —
-  антипаттерн, который менти увёз бы в бой.
+  лишняя; такой пример приучал бы без нужды дублировать исходные данные.
 - **Гибрид по цене запроса.** Выбор формы по стоимости, которой на объёмах
   стенда нет: сторож без настоящей опасности.
 - **Проверки домашек в конвейерном звене DQ.** Конвейер стоял бы красным до
@@ -241,8 +245,8 @@ business_key`.
 - **«Жёлтый» статус недостроенной витрины.** У задачи Airflow нет такого
   состояния; изображать его логами — семантика, которую пришлось бы
   расшифровывать. Красное «ещё не построено» честнее.
-- **Самопроверка пишет в `dq_summary`.** Попытки менти смешались бы с
+- **Самопроверка пишет в `dq_summary`.** Результаты учебных попыток смешались бы
-  историей качества конвейера.
+  с историей качества конвейера.
 - **Окно заказов для `daily_traffic` — прошлое замерзает.** Дни за окном хранили
   бы число известных на момент закрытия — витрина тихо расходится с картой
   и протаскивает обратно «знание на дату», отвергнутое развилкой карты

docs/architecture/etl.md

@@ -37,13 +37,13 @@ world_next_day ─────> источники без ETL
 - **Живой день.** `world_live_day` дёргает конвейер с ожиданием — последним
   шагом, после установки позиции. Порядок несёт смысл: день сыгран — факт,
   упавшая трансформация его не отменяет, поэтому позиция ставится раньше; но
-  зеленеть, не узнав, разложился ли день, работник не должен
+  зеленеть, не узнав, разложился ли день, шаговый даг не должен ([ADR
-  ([ADR 0003](../adr/0003-dag-run-state.md)).
+  0003](../adr/0003-dag-run-state.md)). Такой отказ чинится перезапуском
-  Такой отказ чинится перезапуском `etl_pipeline` рукой — перезапуску ничего
+  `etl_pipeline` рукой — перезапуску ничего не нужно помнить, см. «Объём
-  не нужно помнить, см. «Объём прогона».
+  прогона».
-- **Разгон пачкой.** `world_next_day` конвейер не дёргает: пульт управляет
+- **Разгон пачкой.** `world_next_day` конвейер не дёргает: даги модельного
-  генератором и только им. После разгона менти запускает конвейер сам —
+  времени управляют генератором и только им. После разгона менти запускает
-  и видит, как слои догоняют уехавший вперёд мир.
+  конвейер сам — и видит, как слои догоняют уехавший вперёд мир.
 - **Рождение мира.** `world_initialize` дёргает конвейер последним шагом:
   `make up` отдаёт стенд с собранными слоями, а не пустые витрины. Уроки
   ручного запуска начинаются со следующих дней.
@@ -145,9 +145,9 @@ ODS и ещё не собранный в DDS, затем при необходи
 
 ## Отклонённые варианты
 
-- **Задачи трансформаций прямо в работниках пульта.** Один зелёный прогон —
+- **Задачи трансформаций прямо в шаговых дагах.** Один зелёный прогон —
-  весь день, но пульт — про ось времени: работников два, шаги дублировались
+  весь день, но даги времени отвечают за ось времени: шаговых дагов два, шаги
-  бы, а этапу 5 пришлось бы выдирать их обратно.
+  дублировались бы, а этапу 5 пришлось бы выдирать их обратно.
 - **Make-цель или SQL рукой при приёмке.** Второй оркестратор рядом с
   Airflow — против [ADR 0013](../adr/0013-world-lifecycle.md), — а в живом
   режиме слои копили бы отставание молча.
@@ -163,8 +163,8 @@ ODS и ещё не собранный в DDS, затем при необходи
 
 - [ADR 0003](../adr/0003-dag-run-state.md) — зелёный конец графа не
   переживает отказ выше: отсюда ожидания в триггерах.
-- [ADR 0009](../adr/0009-world-control.md) — пульт мира: его работник
+- [ADR 0009](../adr/0009-world-control.md) — даги модельного времени: их шаговый
-  живого дня и дёргает конвейер.
+  даг живого дня и дёргает конвейер.
 - [ADR 0013](../adr/0013-world-lifecycle.md) — жизненный цикл мира: почему
   прикладным процессом владеет Airflow и почему `world_initialize` кончается
   собранными слоями.

docs/architecture/generator/seeds.md

@@ -42,7 +42,7 @@
 Новый бросок в середине функции сдвигает все последующие значения этого
 подпотока. Код продолжает работать, но тем же свойствам достается другая
 случайность. Соседние подпотоки остаются прежними, а измененная часть
-канонического мира проявляется в описи и побайтовом сравнении.
+канонического мира проявляется в паспорте и побайтовом сравнении.
 
 Какое обещание воспроизводимости это защищает, записано в
 [спеке генератора](../../specs/2026-08-01-generator.md), раздел 2. Здесь важно

docs/architecture/monitoring/data.md

@@ -19,23 +19,23 @@
 ## Почему слои у панелей разные
 
 Свежесть спрашивают у ODS. Это слой, который читают, и у заказов дорога до него
-длиннее: сырьё привозит забор, а типизированную строку кладёт разбор. Встань
+длиннее: в STG данные привозит забор, а типизированную строку кладёт разбор.
-разбор — свежесть ODS это покажет, свежесть сырья нет.
+Встань разбор — свежесть ODS это покажет, а свежесть STG — нет.
 
 Читает свежесть физическую `_dist`, а не каноническое `ods.*_v`. Представление
 прячет за собой `FINAL` и отвечает про текущее состояние сущностей, а вопрос
 здесь про доставку. Местом диагностики доставленных версий физическая таблица
 названа там же, где заведено представление (`sql/ddl/30-ods-views.sql`).
 
-Поток и брак считаются по слою сырья. Сырьё записывает каждую доставку и ничего
+Поток и брак считаются по сырому слою. Он хранит каждую доставку и ничего не
-не схлопывает, а `ReplacingMergeTree` в ODS схлопнет и повтор доставки события,
+схлопывает, а `ReplacingMergeTree` в ODS схлопнет и повтор доставки события, и
-и все версии одного заказа. Считай мы поток по ODS — он занизился бы, и тем
+все версии одного заказа. Считай мы поток по ODS — он занизился бы, и тем
 сильнее, чем дольше живёт стенд.
 
 Доля брака берётся от приехавшего, а не от суммы «годные плюс брак»: брак не
-отдельная куча, а часть сырья, которая не прошла разбор.
+отдельная куча, а часть сырых данных, которая не прошла разбор.
 
-Окно у панели брака — окно дашборда, и это не косметика. Сырьё живёт трое
+Окно у панели брака — окно дашборда, и это не косметика. Сырые данные живут трое
 суток, а брак — месяц: доля за всё время делила бы месяц брака на трое суток
 приехавшего и однажды перевалила бы за сотню процентов.
 
@@ -51,7 +51,7 @@
 укладываются в минуты реального времени, и соседние дни мира помещаются в одно
 окно панели сами.
 
-## Приземлившееся считают по слою сырья
+## Приземлившееся считают в сыром слое
 
 Приземлившееся панели считают по `stg.*_raw_dist`, произведённое — по метрикам
 экспортёра. Таблицы движка Kafka `stg.hits_raw_kafka` и `stg.orders_raw_kafka`
@@ -66,7 +66,7 @@
 Kafka» приходит из Prometheus, ряд «приземлилось в ClickHouse» — из ClickHouse.
 Единицы общие: сообщения за интервал панели. Со стороны Kafka это разность
 офсетов топика, «сейчас минус интервал назад», с суммой по обеим партициям; со
-стороны ClickHouse — `count()` строк сырья по тому же интервалу.
+стороны ClickHouse — `count()` строк STG по тому же интервалу.
 
 Два соседних способа отвергнуты, и оба по замеру на живом стенде. `increase`
 растягивает приращение на всё окно и на минутном интервале промахивается на
@@ -87,11 +87,11 @@ Kafka» приходит из Prometheus, ряд «приземлилось в C
 Kafka идёт чуть выше. Читать надо устойчивый разрыв между линиями; разница в
 один столбец не значит ничего.
 
-Панель смотрит на топик событий. У него приём непрерывный, и разрыв виден
+Панель смотрит на топик событий. У него приём непрерывный, и разрыв виден сразу.
-сразу. Слепок заказов уезжает пачкой раз в модельные сутки, и вопрос к нему
+Слепок заказов уезжает пачкой раз в модельные сутки, и вопрос к нему другой — не
-другой — не «сходится ли поток», а «доехала ли выгрузка и вовремя ли». На него
+«сходится ли поток», а «доехала ли выгрузка и вовремя ли». На него отвечает своя
-отвечает своя панель, и модельный день она берёт из самого сообщения: в сырьё
+панель, и модельный день она берёт из самого сообщения: в STG он приезжает полем
-он приезжает полем `snapshot_date`.
+`snapshot_date`.
 
 ## Что проверено
 

docs/architecture/orders/README.md

@@ -30,9 +30,9 @@
   `ORDERS` для заказной стороны и `BEACONS` для событийной; броски независимы,
   пересечения выходят арифметикой, приоритет классов работает по-настоящему —
   [классы расхождений и опоздание](fate.md).
-- **Опись хранит только то, чего движение мира не меняет**: хеш байтов
+- **Паспорт хранит только то, чего движение мира не меняет**: хеш байтов
-  каждого слепка и счётчики наблюдаемых классов —
+  каждого слепка и счётчики наблюдаемых классов — [что хранит
-  [что хранит опись](inventory.md).
+  паспорт](inventory.md).
 - **Мост к склейке**: план состава владеет человеком; его непрозрачный
   `person_id` заказ показывает как `user_id`, кликстрим остаётся анонимным —
   [мост к склейке](identity.md).

docs/architecture/orders/fate.md

@@ -8,18 +8,18 @@
 **Рамка.** Расхождение — не грязь и не шум, а часть мира: судьба заказа,
 решённая при его рождении и уложенная в окно K целиком.
 
-**Два подпотока дня.** Заказная сторона — судьба заказа: исход, моменты,
+**Два подпотока дня.** Заказная сторона — судьба заказа: исход, моменты, дельта,
-дельта, опоздание. Событийная сторона — порча событийного потока: потеря и
+опоздание. Событийная сторона — порча событийного потока: потеря и дубль. Довод
-дубль. Довод за разделение — различимость по описи: правка заказной механики
+за разделение — различимость по паспорту: правка заказной механики не двигает
-не двигает хеши событий, правка событийной не двигает байты слепка, и по
+хеши событий, правка событийной не двигает байты слепка, и по покрасневшим хешам
-покрасневшим хешам видно, какую сторону трогали. Прежние имена `DISCREPANCIES`
+видно, какую сторону трогали. Прежние имена `DISCREPANCIES` и `LATECOMERS`
-и `LATECOMERS` решения не переживают — они названы по классам витрины, а
+решения не переживают — они названы по классам витрины, а компонент называет
-компонент называет часть мира; новые стороны занимают те же позиции.
+часть мира; новые стороны занимают те же позиции. Заказная сторона названа при
-Заказная сторона названа при реализации — подпоток `ORDERS` на позиции 2;
+реализации — подпоток `ORDERS` на позиции 2; событийная — `BEACONS` на позиции
-событийная — `BEACONS` на позиции 3: маячок счетчика либо не долетает, либо
+3: маячок счетчика либо не долетает, либо отправляется повторно. Отклонено:
-отправляется повторно. Отклонено: *один компонент на всю судьбу* — правка
+*один компонент на всю судьбу* — правка событийной механики молча меняла бы
-событийной механики молча меняла бы байты слепка; *компонент на класс* —
+байты слепка; *компонент на класс* — пять имён под ручки калибровки, которые
-пять имён под ручки калибровки, которые крутятся разом.
+крутятся разом.
 
 **Правило формы, без которого разделение не работает: броски заказной стороны
 делаются на полную длину дня, а не на отобранных заказах.** Иначе длина броска
@@ -62,15 +62,14 @@
 процентов» не заводим.
 
 **Что из двух дорог видно.** В `dds.order` дороги неразличимы — там последняя
-версия; различает их история версий: сырьё STG и физические версии
+версия; различает их история версий: строки STG и физические версии `ods.order`
-`ods.order` до фоновых слияний, а в витринах — выручка дня, которая
+до фоновых слияний, а в витринах — выручка дня, которая сначала выросла, потом
-сначала выросла, потом убыла. Полное различение не обещано: слепок — состояние
+убыла. Полное различение не обещано: слепок — состояние на границе суток, и
-на границе суток, и оплата с отменой в один день в сырье неразличимы; то же у
+оплата с отменой в один день в сырых данных неразличимы; то же у сильно
-сильно опоздавших, приехавших уже терминальными. Точную форму этого урока
+опоздавших, приехавших уже терминальными. Точную форму этого урока решает этап
-решает этап 4. Отклонено: *отмена только после оплаты* — неоплаченному некуда
+4. Отклонено: *отмена только после оплаты* — неоплаченному некуда деться, кроме
-деться, кроме как остаться брошенным; *мгновенная отмена при рождении* —
+как остаться брошенным; *мгновенная отмена при рождении* — «дыхание» окна на
-«дыхание» окна на отменах исчезает; *отмен нет вовсе* — страховочный срез 1,
+отменах исчезает; *отмен нет вовсе* — страховочный срез 1, он в резерве.
-он в резерве.
 
 ## Классы расхождений и опоздание
 

docs/architecture/orders/identity.md

@@ -24,10 +24,10 @@
 Наблюдаемое обещание — четыре свойства: назначенные заказы пары с разных
 `ClientID` несут один `user_id`; событие Метрики не раскрывает `user_id`;
 отдельные прогоны одного мира дают то же соответствие; принятый мир
-воспроизводит эффект склейки без случайных ложных объединений — конкретные
+воспроизводит эффект склейки без случайных ложных объединений. Паспорт не
-числа пар контрактом описи не являются. Межкогортные столкновения принимаются
+закрепляет конкретное число пар. Межкогортные столкновения принимаются по той же
-по той же дисциплине, что у случайных `ClientID`: принимается конкретный
+дисциплине, что у случайных `ClientID`: принимается конкретный канонический мир
-канонический мир по внешнему результату.
+по внешнему результату.
 
 Отклонено: *заказная сторона сама назначает личность* — родство кук всё равно
 пришлось бы спрашивать у плана; *материализованный реестр кука↔пользователь* —

docs/architecture/orders/ingestion.md

@@ -35,10 +35,11 @@ PARTITION` могла бы заменить партицию дня неполн
 
 После завершения генератора Airflow один раз читает байтовый Kafka-чтец и
 записывает полученную порцию в `stg.orders_raw`. Даг зовётся `orders_ingest`, а
-дёргает его тот, кто положил слепок в топик, — работник пульта мира, — и ждёт
+запускает его шаговый даг модельного времени, который положил слепок в топик и
-конца прогона. Все строки получают `_load_id`, равный `run_id` Airflow.
+ждёт конца прогона. Все строки получают `_load_id`, равный `run_id` Airflow.
 `_load_ts` вычисляется при этой записи и дальше переносится без пересчёта.
-Запрос забора лежит в [`sql/stg/orders_raw_load.sql`](../../../sql/stg/orders_raw_load.sql):
+Запрос забора лежит в
+[`sql/stg/orders_raw_load.sql`](../../../sql/stg/orders_raw_load.sql):
 `SQLExecuteQueryOperator` задаёт подключение и передаёт `run_id` как параметр
 ClickHouse `load_id`, а преобразование остаётся в SQL своего слоя.
 
@@ -157,7 +158,7 @@ dbt snapshots — стратегия `check` вместо `timestamp`.
 Отказ — случай другой, и «хвост дождётся» на него не распространяется. Офсеты
 порции коммитятся в момент чтения, поэтому упавшая вставка уносит прочитанное с
 собой: повторное чтение вернёт ноль, а часть строк может уже лежать на шарде.
-Позиция мира при этом не двигается, и тот же день уедет заново — в сырье он
+Позиция мира при этом не двигается, и тот же день уедет заново — в STG он
 окажется частичным дублем, а старый хвост, ушедший той же порцией, не вернётся
 ([ADR 0008](../../adr/0008-order-ingestion.md), «Следствия»).
 
@@ -191,10 +192,10 @@ dbt snapshots — стратегия `check` вместо `timestamp`.
 ## Что проверено
 
 Переход STG → ODS снят на живом стенде 18 августа 2026 года при исполнении #94.
-Опыты этого раздела прогнаны и подтвердили обещанное: разбиение сырья на годные
+Опыты этого раздела прогнаны и подтвердили обещанное: разбиение строк STG на
-строки и брак полное и непересекающееся; две версии одного заказа легли в одну
+годные строки и брак полное и непересекающееся; две версии одного заказа легли в
-партицию и на один шард, а `ods.order_v` вернуло позднюю независимо от фонового
+одну партицию и на один шард, а `ods.order_v` вернуло позднюю независимо от
-слияния; повтор задачи с тем же `_load_id` строку в `ods.order_v` и её
+фонового слияния; повтор задачи с тем же `_load_id` строку в `ods.order_v` и её
 `_load_ts` не изменил, а таблица ошибок записала тот же брак второй раз; строки
 опытов убраны. Числа, механика опытов и поведение ClickHouse, на которое всё это
 опирается, — [документ хранилища](../storage.md), «Что проверено».
@@ -217,9 +218,9 @@ dbt snapshots — стратегия `check` вместо `timestamp`.
 
 Текущее состояние проверено на пересобранном мире 26 августа 2026 года при
 исполнении #165. После двух слепков физическая таблица содержала 3356 версий
-1917 заказов. У всех строк `ods.order_v` дата слепка совпала с последним
+1917 заказов. У всех строк `ods.order_v` дата слепка совпала с последним слепком
-слепком заказа; деловые поля совпали с эталоном `argMax` по `updated_at` из
+заказа; деловые поля совпали с эталоном `argMax` по `updated_at` из сырых
-сырья. В обеих сверках расхождений нет.
+данных. В обеих сверках расхождений нет.
 
 Забор из Kafka в STG снят на живом стенде 18 августа 2026 года при исполнении
 #93: одно прямое чтение приносит весь слепок дня, метаданные доставки доступны,

docs/architecture/orders/inventory.md

@@ -1,20 +1,20 @@
-# Что хранит опись
+# Что хранит паспорт мира
 
 Резолюции развилок [«Расхождения A–D и опоздания: механика, доли и что
 обещано»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/72)
 и [«Места заказов в стартовом
 мире»](https://git.dementev.space/ddmitry/clickstream-data-platform/issues/74).
-Словарь описи — растяжка-хеш против опоры-счётчика — задан «Чем меряется
+Термины паспорта — «растяжка-хеш» и «опора-счётчик» — заданы разделом «Чем
-генератор» в [спеке генератора](../../specs/2026-08-01-generator.md) и
+меряется генератор» в [спеке генератора](../../specs/2026-08-01-generator.md) и
-термином «Опись мира» в [CONTEXT.md](../../../CONTEXT.md).
+статьёй «Паспорт мира» в [CONTEXT.md](../../../CONTEXT.md).
 
-> Опись хранит только то, чего движение мира не меняет.
+> Паспорт хранит только то, чего движение мира не меняет. Хеш кладём всегда,
-> Хеш кладём всегда, счётчик — только когда назван его читатель.
+> счётчик — только когда назван его читатель.
 
 - **У каждого отправленного слепка — своя строка с хешем байтов.** Байты
   слепка не покрыты хешами дней ни при каком раскладе подпотоков — это второй
-  артефакт мира. Побайтовое обещание («слепок переснимается и даёт те же
+  артефакт мира. Побайтовое обещание («слепок переснимается и даёт те же байты»)
-  байты») опись начинает сторожить.
+  паспорт начинает сторожить.
 - **Счётчики классов расхождений — наблюдаемых, после приоритета**, по
   итоговой судьбе заказов дня. В строке закрытого дня поле `orders` хранит
   число заказов каждого класса; пока окно открыто, поля нет. При N сыгранных
@@ -24,7 +24,7 @@
 - **Контрольные числа идентичности не заводятся вовсе**: uniq известных
   пользователей и число двухкуковых пар растут, пока мир едет, — опоры из них
   не выходит; генератор сторожит хеш, транспорт — счёт событий.
-- **Опись описывает мир, а не доставку.** Работа генератора кончается на
+- **Паспорт описывает мир, а не доставку.** Работа генератора кончается на
-  Kafka: дошли ли байты до `ods.order` — вопрос стенда и его
+  Kafka: дошли ли байты до `ods.order` — вопрос стенда и его проверок. Поэтому
-  проверок. Поэтому счёта строк у слепка в описи нет; понадобится проверка
+  счёта строк у слепка в паспорте нет; понадобится проверка приёма заказов —
-  приёма заказов — число заведётся вместе с ней.
+  число заведётся вместе с ней.

docs/architecture/orders/snapshot.md

@@ -112,5 +112,5 @@
 такого значения означает ошибку арифметики источника.
 
 Сверх контракта здесь живёт одно правило: **порядок строк внутри слепка —
-порядок рождения заказов, он же возрастание `order_id`**. Детерминизм даёт
+порядок рождения заказов, он же возрастание `order_id`**. Детерминизм даёт его
-его даром, а хешу слепка в описи нужен именно названный порядок.
+даром, а хешу слепка в паспорте нужен именно названный порядок.

docs/architecture/orders/start-world.md

@@ -25,11 +25,11 @@
 
 Цена принята с открытыми глазами: у части пар стартового мира поздний
 назначенный заказ падает на день 7, и до первого хода мира этих пар в
-`dds.identity_map` нет. Опись пар не считает
+`dds.identity_map` нет. Паспорт пар не считает ([что хранит
-([что хранит опись](inventory.md)), поэтому красной проверки из этого не
+паспорт](inventory.md)), поэтому красной проверки из этого не выходит.
-выходит. Отклонено: *дослать восьмой слепок* — исчезает `awaiting_order` на
+Отклонено: *дослать восьмой слепок* — исчезает `awaiting_order` на свежем
-свежем стенде, в CLI заводится рычаг, стартовый мир становится особым случаем
+стенде, в CLI заводится рычаг, стартовый мир становится особым случаем ровно
-ровно там, где #71 его убирал; *счётчик пар учится спрашивать про слепки* —
+там, где #71 его убирал; *счётчик пар учится спрашивать про слепки* — число
-число верно ровно до первого хода мира; *отменить сдвиг отправки* —
+верно ровно до первого хода мира; *отменить сдвиг отправки* — `awaiting_order`
-`awaiting_order` пропал бы навсегда; *подогнать план под горизонт* — мир
+пропал бы навсегда; *подогнать план под горизонт* — мир перестал бы быть чистой
-перестал бы быть чистой функцией зерна.
+функцией зерна.

docs/architecture/stand.md

@@ -0,0 +1,127 @@
+# Стенд: службы, доступ, настройка
+
+Здесь описано, из каких служб собран стенд, кто к кому подключается и как
+настройки доходят до контейнеров. Состав каркаса обоснован в
+[ADR 0001](../adr/0001-stand-services.md), доступ к ClickHouse — в
+[ADR 0007](../adr/0007-clickhouse-access.md). Адреса и пароли интерфейсов
+остаются в [корневом README](../../README.md#адреса-и-пароли).
+
+## Службы
+
+- `clickhouse-01` — инициатор DDL и точка подключения Airflow;
+- `clickhouse-02` — точка подключения Superset;
+- `clickhouse-keeper` — координатор кластера;
+- `kafka` — один брокер KRaft;
+- `kafka-exporter` — экспортёр метрик Kafka для Prometheus;
+- `postgres-metadata` — один Postgres с отдельными базами и пользователями
+  `airflow` и `superset`;
+- `airflow-apiserver`, `airflow-scheduler` и `airflow-dag-processor` —
+  Airflow 3.3 с LocalExecutor, без triggerer;
+- `superset` — интерфейс с заранее настроенным подключением к ClickHouse;
+- `prometheus` и `grafana` — сбор и просмотр метрик ClickHouse и Kafka.
+
+## Пользователи и роли ClickHouse
+
+В ClickHouse семь пользователей и шесть ролей:
+
+- `etl` — учётная запись рабочих дагов Airflow; роль `etl_writer` читает и
+  пишет слои хранилища;
+- `lifecycle` — учётная запись дагов жизненного цикла; роль `lifecycle_owner`
+  разрешает им применять канонический DDL и пересоздавать прикладные базы. У
+  рабочих дагов этих административных прав нет;
+- `bi` — учётная запись Superset; роль `bi_reader` читает ODS, DDS, DM и
+  справочники `dic`, а запросы Superset обращаются к публичным `_v`;
+- `analyst` — учётная запись аналитика с правом чтения всех слоёв и
+  справочников;
+- `grafana` — учётная запись Grafana; роль `monitoring_reader` читает все слои,
+  системные таблицы и данные со всех реплик кластера;
+- `dict` — беспарольная учётная запись словаря товаров с правом чтения базы
+  `dic`; словарь читает через неё свою подложку;
+- `default` — служебная учётная запись для проверок состояния и скриптов внутри
+  контейнеров; приложения с ней не подключаются.
+
+Почему пользователи объявлены файлом, а ноды доверяют общему секрету, — в
+[ADR 0007](../adr/0007-clickhouse-access.md).
+Пользователи и роли объявлены в `infra/clickhouse/users.d/access.xml`. Пароли и
+общий секрет нод живут в `.env` и передаются в конфигурацию через окружение;
+Superset получает пароль `bi`, а Grafana — пароль `grafana` тем же путём.
+Значения для локального стенда есть в `.env.example`.
+
+## Применение настроек
+
+Чтобы применить новые значения ClickHouse из `.env` или изменения файлов в
+`infra/clickhouse/config.d/` и `infra/clickhouse/users.d/`, пересоздайте ноды:
+
+```bash
+docker compose up --force-recreate --wait clickhouse-01 clickhouse-02
+```
+
+Команда возвращает управление, когда обе ноды снова здоровы; именованные тома
+при этом сохраняются. `docker compose restart` оставит прежнее окружение и
+может оставить старую версию отдельно смонтированного файла.
+
+## Секреты и порты
+
+В локальном учебном стенде намеренно используются простые ненастоящие пароли и
+ключи. Kafka и Prometheus работают без проверки доступа. Это не пример настройки
+защиты: не копируйте значения из `.env.example` в рабочую среду. Все
+опубликованные порты привязаны только к `127.0.0.1`; Postgres наружу не
+опубликован.
+
+## Одна реплика на шард
+
+В бою перед репликами ClickHouse обычно был бы балансировщик. Здесь в каждом
+шарде одна реплика, поэтому балансировать нечего. Балансировщик и топология
+2×2 намеренно не входят в стенд.
+
+## Что проверено
+
+**Конфигурация сверена 30 июля 2026 года** с официальной документацией
+ClickHouse:
+[настройками сервера](https://clickhouse.com/docs/operations/server-configuration-parameters/settings),
+[Keeper](https://clickhouse.com/docs/guides/oss/deployment-and-scaling/keeper/),
+[ReplicatedMergeTree](https://clickhouse.com/docs/engines/table-engines/mergetree-family/replication),
+[ON CLUSTER](https://clickhouse.com/docs/sql-reference/distributed-ddl) и
+[Distributed](https://clickhouse.com/docs/engines/table-engines/special/distributed).
+Кластер описан в `remote_servers`, макросы — в `macros`, а подключение к
+keeper — в `zookeeper`. Путь `ReplicatedMergeTree` содержит `{shard}` и
+`{replica}`.
+Для `Distributed` задаются имя кластера, база, локальная таблица и ключ
+шардирования. Макросы выбраны, чтобы один DDL через `ON CLUSTER` создавал
+отдельный путь для каждого шарда без вписанных вручную значений. В образе
+закреплена точная версия текущего LTS-выпуска —
+[26.3.17.56](https://github.com/ClickHouse/ClickHouse/releases/tag/v26.3.17.56-lts);
+серверы и keeper используют один образ.
+
+Настройки Kafka 4.3.1 сверены с
+[примером односерверного KRaft](https://github.com/apache/kafka/blob/4.3.1/docker/examples/docker-compose-files/single-node/plaintext/docker-compose.yml).
+
+Раздел метрик взят из конфигурации закреплённого образа ClickHouse и проверен
+на серверах и keeper. Автоматическая настройка источников данных Grafana
+сверена с
+[официальным описанием автоматической настройки](https://grafana.com/docs/grafana/latest/administration/provisioning/)
+и [документацией плагина ClickHouse](https://grafana.com/docs/plugins/grafana-clickhouse-datasource/latest/configure/).
+Prometheus собирает встроенные метрики двух серверов и keeper, а через
+`kafka-exporter` — состояние Kafka. Поверх этого в Grafana поднимается дашборд
+«Данные»: свежесть, поток, брак, сходимость Kafka с ClickHouse, отставание
+чтения и дневной слепок заказов. Устройство зоны — в [справочнике
+мониторинга](monitoring/README.md), разбор панелей — в
+[описании дашборда](monitoring/data.md); правил оповещения
+пока нет.
+
+Airflow закреплён на 3.3.0. Состав обязательных процессов, LocalExecutor,
+публичный `airflow.sdk`, API проверки состояния и SimpleAuthManager сверены с
+[архитектурой Airflow 3.3](https://airflow.apache.org/docs/apache-airflow/3.3.0/core-concepts/overview.html),
+[публичным интерфейсом](https://airflow.apache.org/docs/apache-airflow/3.3.0/public-airflow-interface.html)
+и [описанием здоровья](https://airflow.apache.org/docs/apache-airflow/3.3.0/administration-and-deployment/logging-monitoring/check-health.html).
+Для ClickHouse установлен официальный провайдер Airflow: SQL-файлы исполняет
+общий `SQLExecuteQueryOperator`, программные запросы идут через
+`ClickHouseHook`. Провайдер работает поверх закреплённого
+`clickhouse-connect`. Официальный провайдер Kafka уже использует
+`confluent-kafka`. В стенде клиент добавлен в образ напрямую, без отдельного
+подключения Airflow и обёрток провайдера.
+
+Superset закреплён на 6.1.0; драйвер `clickhouse-connect`, схема адреса
+подключения `clickhousedb://` и драйвер Postgres сверены с
+[документацией подключений Superset](https://superset.apache.org/user-docs/6.1.0/databases/)
+и [настройкой базы метаданных](https://superset.apache.org/admin-docs/6.1.0/configuration/configuring-superset/).

docs/architecture/storage.md

@@ -7,20 +7,19 @@
 
 **Что здесь описано и чего ещё нет.** Собран этап 1: кластер из двух шардов,
 keeper, Kafka, каркас сервисов. Этап 2 собран: в `sql/ddl/` лежит вся цепочка
-`Kafka → STG → ODS` — чтец топика `hits`, таблицы сырья, типизированное
+`Kafka → STG → ODS` — чтец топика `hits`, таблицы STG, типизированное событие с
-событие с таблицей ошибок, поверхность актуального состояния и три матвью.
+таблицей ошибок, поверхность актуального состояния и три матвью. Этап 3 добавил
-Этап 3 добавил вход второго источника и довёл его до ODS: топик `orders`, свой
+вход второго источника и довёл его до ODS: топик `orders`, свой чтец, свой сырой
-чтец, своё сырьё, версии заказов с таблицей ошибок и поверхность текущего
+слой, версии заказов с таблицей ошибок и поверхность текущего состояния.
-состояния. Наполняет всю цепочку даг `orders_ingest` двумя шагами, а не матвью.
+Наполняет всю цепочку даг `orders_ingest` двумя шагами, а не матвью. Тот же этап
-Тот же этап принёс первый справочник — словарь товаров из общего с генератором
+принёс первый справочник — словарь товаров из общего с генератором CSV-файла.
-CSV-файла. Живёт он вне цепочки слоёв, в зоне `dic`, и читает не файл, а
+Живёт он вне цепочки слоёв, в зоне `dic`, и читает не файл, а подложку над ним
-подложку над ним ([ADR 0012](../adr/0012-dictionary-home.md)). Этап 4 начат
+([ADR 0012](../adr/0012-dictionary-home.md)). Этап 4 начат публичным договором
-публичным договором события `dds.event_v` над точным состоянием ODS, а следом
+события `dds.event_v` над точным состоянием ODS, а следом получил две физические
-получил две физические модели слоя — заказ и сессию: их собирает заменой
+модели слоя — заказ и сессию: их собирает заменой партиций даг `dds_transform`.
-партиций даг `dds_transform`. Сессия среди них особая: в потоке такой сущности
+Сессия среди них особая: в потоке такой сущности нет, стенд режет её из событий
-нет, стенд режет её из событий сам.
+сам. Дальше по тексту устройство описано так, как оно проектируется; построенное
-Дальше по тексту устройство описано так, как оно проектируется; построенное от
+от заложенного отличает карта таблиц в конце.
-заложенного отличает карта таблиц в конце.
 
 Зона ответственности у документа одна — хранилище. Генератор описан отдельно:
 его замысел — в [спеке генератора](../specs/2026-08-01-generator.md), формат
@@ -97,7 +96,7 @@ ClickHouse и отклонённые варианты записаны в
 Ключи шардирования: `cityHash64(ClientID)` у событий, `cityHash64(order_id)` у
 заказов, `cityHash64` сырой строки у STG и у таблицы ошибок. У первых двух хеш
 выбран против перекоса: структурированный числовой идентификатор распределяется
-по остатку от деления неравномерно. У сырья выбора нет — строку иначе не
+по остатку от деления неравномерно. У сырого слоя выбора нет — строку иначе не
 разложишь; там хеш даёт другое свойство, одинаковые сообщения ложатся на один
 шард.
 
@@ -157,10 +156,10 @@ FROM источник_dist`. Заводское значение `parallel_distr
 даёт две: `_timestamp` — `Nullable(DateTime)`, то есть секунды, и
 `_timestamp_ms` — `Nullable(DateTime64(3))`, миллисекунды. Колонка объявлена
 `Nullable(DateTime64(3, 'UTC'))` и заполняется из `_timestamp_ms`: у брокера
-метка миллисекундная, соседняя `_load_ts` тоже миллисекундная, а слой сырья
+метка миллисекундная, соседняя `_load_ts` тоже миллисекундная, а сырой слой
 хранит приехавшее, и округлять ему нечего. Обнуляемость нужна отдельно от
-разрядности: брокер метку заполняет не всегда, а необнуляемый тип значил бы
+разрядности: брокер метку заполняет не всегда, а необнуляемый тип значил бы либо
-либо падение приёма на первом сообщении, либо тихие нули за 1970 год.
+падение приёма на первом сообщении, либо тихие нули за 1970 год.
 
 Заполняются все они выражением в `SELECT` матвью приёма, а не `DEFAULT` в
 таблице. Для `consumer_host` это обязательно: `DEFAULT hostName()` вычисляется
@@ -173,10 +172,10 @@ FROM источник_dist`. Заводское значение `parallel_distr
 пакетный шаг ([ADR 0008](../adr/0008-order-ingestion.md), [ADR
 0010](../adr/0010-order-versions-in-ods.md)).
 
-Движок таблицы сырья — обычный `ReplicatedMergeTree`, `ORDER BY (kafka_partition,
+Движок таблицы STG — обычный `ReplicatedMergeTree`, `ORDER BY (kafka_partition,
-kafka_offset)`: разбор полётов идёт от «какое сообщение», другого ключа у сырья и
+kafka_offset)`: разбор полётов идёт от «какое сообщение», другого ключа у
-нет. Замену версий сюда ставить нельзя — она отменила бы свойство слоя, ради
+таблицы STG и нет. Замену версий сюда ставить нельзя — она отменила бы свойство
-которого он заведён: повтор доставки в сырье обязан быть виден.
+слоя, ради которого он заведён: повтор доставки в STG обязан быть виден.
 
 Метка времени загрузки зовётся `_load_ts`, тип `DateTime64(3, 'UTC')`. Ставится
 она один раз при записи в STG: для событий — матвью приёма, для дневного слепка
@@ -192,7 +191,7 @@ kafka_offset)`: разбор полётов идёт от «какое сооб
 `_load_ts`. Совпадение слов «техническое время» не делает эти часы одной осью.
 
 Пакетной переобработки у событий в ODS нет: слой наполняют матвью, а не задание
-Airflow. Переделать разобранное руками можно вставкой из сырья с фильтром по
+Airflow. Переделать разобранное руками можно вставкой из STG с фильтром по
 `_load_ts` в пределах трёхсуточного окна; ничья по версии разрешается в пользу
 вставленного позже. Заказы разбирает пакетный шаг из неизменного среза STG по
 `_load_id`; дневные партиции ODS он не заменяет.
@@ -223,10 +222,10 @@ ODS и в таблицу ошибок. Нужен ли он выше ODS, реш
 
 Типы ODS обычно повторяют контракт выгрузки. Денежный `purchaseRevenue` —
 исключение: источник объявляет `Array(Float64)`, а материализованное
-представление ODS разбирает числа сырого JSON сразу в
+представление ODS разбирает числа сырого JSON сразу в `Array(Decimal(18, 2))`.
-`Array(Decimal(18, 2))`. DDS наследует этот тип без нового преобразования.
+DDS наследует этот тип без нового преобразования. Прямой разбор подтвержден
-Прямой разбор подтвержден документацией ClickHouse через Context7 и запросом
+документацией ClickHouse через Context7 и запросом к ClickHouse 26.3; сравнение
-к ClickHouse 26.3; сравнение с сырьем подтвердило: копейки всех покупок целы.
+с сырыми данными подтвердило: копейки всех покупок целы.
 
 ## Версии заказов
 
@@ -257,16 +256,16 @@ DDS. `snapshot_date` в нём одновременно дата наблюде
 
 **Линза называется явно — в типе колонки либо в вызове функции.** Третий
 источник, умолчание сервера, в коде не виден и меняется снаружи, поэтому там,
-где линза что-то решает — в объявлении хранимой колонки и в выражении,
+где линза что-то решает — в объявлении хранимой колонки и в выражении, считающем
-считающем дату, — его не остаётся. Прописать этот пояс своей рукой —
+дату, — его не остаётся. Прописать этот пояс своей рукой — `<timezone>` в
-`<timezone>` в конфигурации ноды или `TZ` контейнеру — было бы той же болезнью
+конфигурации ноды или `TZ` контейнеру — было бы той же болезнью с другим
-с другим умолчанием, и вдобавок отняло бы проверку: когда линза названа в типах
+умолчанием, и вдобавок отняло бы проверку: когда линза названа в типах и в
-и в разборе, пояс сервера на данные не влияет нигде, и в этом можно убедиться,
+разборе, пояс сервера на данные не влияет нигде, и в этом можно убедиться,
-поменяв его. Правило стоит на источнике пояса, а не на функции:
+поменяв его. Правило стоит на источнике пояса, а не на функции: `toDate` по
-`toDate` по колонке, чей тип пояс несёт, законен и имени не требует — так и
+колонке, чей тип пояс несёт, законен и имени не требует — так и работают ключи
-работают ключи партиций `toDate(_load_ts)` у сырья и у таблицы ошибок. Имя
+партиций `toDate(_load_ts)` у таблицы STG и у таблицы ошибок. Имя пишется тогда,
-пишется тогда, когда нужна другая линза, чем у колонки:
+когда нужна другая линза, чем у колонки: `toDate(UTCEventTime, 'Europe/Samara')`
-`toDate(UTCEventTime, 'Europe/Samara')` — это «день по часам счётчика».
+— это «день по часам счётчика».
 
 **Какая линза, решает слой — по тому, кого он обслуживает.** ODS хранит снимок
 выгрузки и говорит на языке выгрузки: у Метрики `UTCEventTime` абсолютна,
@@ -314,8 +313,8 @@ UTC+4), и пересчёт идёт один раз при наполнении
 0008](../adr/0008-order-ingestion.md) и [спецификация приёма
 заказов](orders/ingestion.md).
 
-Цепочка одна: чтец топика → матвью → сырьё STG → матвью разбора → событие и
+Цепочка одна: чтец топика → матвью → STG → матвью разбора → событие и таблица
-таблица ошибок ODS.
+ошибок ODS.
 
 Чтец стоит на обеих нодах и читает одной группой потребителей — имя группы
 `clickstream_hits`, и оно одинаково на обеих нодах по построению: DDL идёт
@@ -344,15 +343,15 @@ Airflow она стоит — там это обычный `SETTINGS` у зап
 пользователя в конфигурации ноды. Синхронный режим связывает шарды: пока второй
 недоступен, вставка падает, офсеты не коммитятся, и приём встаёт целиком — тогда
 как при фоновом первая нода продолжает принимать и копит спул для соседа.
-Платится при этом не одно ожидание на блок, а три распределённые вставки — сырьё,
+Платится при этом не одно ожидание на блок, а три распределённые вставки — STG,
 событие, ошибки, — и все внутри потока-потребителя, что само по себе повод для
 ребаланса по таймауту сессии. Против всего этого — окно в сотню миллисекунд на
 ноутбуке, где мир пересобирается одной командой. Размен не в пользу настройки, а
 компромисс полезнее показать, чем спрятать за галочкой.
 
-Ещё одно место, где сырьё хранит не всё приехавшее: запись с пустым значением и
+Ещё одно место, где сырой слой хранит не всё приехавшее: запись с пустым
-запись-надгробие проходят молча, не оставляя строки. Свойство измерено и принято
+значением и запись-надгробие проходят молча, не оставляя строки. Свойство
-осознанно — подробности в разделе «Что проверено».
+измерено и принято осознанно — подробности в разделе «Что проверено».
 
 **Гарантии нет ни в одну сторону — есть два узких окна.** Окно потери описано
 выше: нода умерла между коммитом офсетов и сбросом спула. Окно дубля
@@ -361,14 +360,14 @@ Airflow она стоит — там это обычный `SETTINGS` у зап
 один раз» нельзя — это обещало бы, что потерь не бывает, а они возможны.
 
 Дубль ниже по течению ведёт себя по-разному. В ODS его схлопнет
-`ReplacingMergeTree`, а сырьё дедупа не имеет вовсе: перезаливка модельного дня
+`ReplacingMergeTree`, а таблицы STG вовсе не устраняют дубли: перезаливка
-честно удваивает `count()` в STG, и живёт эта пара до истечения срока хранения.
+модельного дня честно удваивает `count()` в STG, и живёт эта пара до истечения
-Это свойство слоя, а не поломка, — но обещание идемпотентности конвейера к
+срока хранения. Это свойство слоя, а не поломка, — но обещание идемпотентности
-сырому слою не относится.
+конвейера к сырому слою не относится.
 
 Оговорка к последнему: у семейства `Replicated*` есть своя дедупликация — блок с
 тем же хешем, вставленный повторно, отбрасывается (`insert_deduplicate`).
-Удвоение сырья проходит мимо неё только потому, что при повторном чтении
+Удвоение строк STG проходит мимо неё только потому, что при повторном чтении
 `_load_ts` новый и хеш блока другой. Свойство слоя держится на этом, а не на
 отсутствии механизма.
 
@@ -384,53 +383,54 @@ Airflow она стоит — там это обычный `SETTINGS` у зап
 роняет вставку и останавливает потребление до починки
 ([ADR 0005](../adr/0005-event-ingestion.md)).
 
-Постоянной сверки **слоёв между собой** при этом нет и не должно быть. У сырья
+Постоянной сверки **слоёв между собой** при этом нет и не должно быть. У сырого
-срок жизни трое суток, а ODS хранит всё, поэтому равенство «сырьё = события +
+слоя срок жизни трое суток, а ODS хранит всё, поэтому равенство «строки STG =
-ошибки» разъедется само: сырьё истечёт раньше, а перезаливка модельного дня
+события + ошибки» разъедется само: строки STG истекут раньше, а перезаливка
-задвоит его, тогда как в ODS тот же повтор схлопнется. Правило, красное в норме, учит не
+модельного дня задвоит их, тогда как в ODS тот же повтор схлопнется. Правило,
-смотреть на оповещения
+красное в норме, учит не смотреть на оповещения ([ADR
-([ADR 0002](../adr/0002-monitoring-scope.md)). Равенство проверено разовым
+0002](../adr/0002-monitoring-scope.md)). Равенство проверено разовым опытом при
-опытом при исполнении #43, на управляемой пачке: отправили N сообщений —
+исполнении #43, на управляемой пачке: отправили N сообщений — получили N строк
-получили N строк сырья и N в сумме событий и ошибок. Постоянной целью такой
+STG и N в сумме событий и ошибок. Постоянной целью такой опыт не становится, и
-опыт не становится, и почему — в [карте
+почему — в [карте проверок](testing.md), раздел «Интеграционная проверка
-проверок](testing.md), раздел «Интеграционная проверка постоянной целью не
+постоянной целью не становится». Счёт актуальных событий идёт через
-становится». Счёт актуальных событий идёт через `ods.event_v`, которое скрывает
+`ods.event_v`, которое скрывает `FINAL`: голый `count()` по `ReplacingMergeTree`
-`FINAL`: голый `count()` по `ReplacingMergeTree` зависит от того, сколько
+зависит от того, сколько мержей успело пройти, и спека это прямо запрещает
-мержей успело пройти, и спека это прямо запрещает (раздел 6).
+(раздел 6).
 
 **Постоянная сверка одна, и она другого рода** — не слой против слоя, а ODS
-против [описи мира](../../data/world-inventory.json), лежащей в git
+против [паспорта мира](../../data/world-inventory.json), лежащего в git (`make
-(`make check-clickhouse`, пришла с #42). Разъехаться сама она не может, и в
+check-clickhouse`, пришла с #42). Разъехаться сама она не может, и в этом вся
-этом вся разница: опись описывает восемь дней стартового мира, счёт обрамлён
+разница: паспорт описывает восемь дней стартового мира, счёт обрамлён их датами,
-их датами, повтор заливки схлопывается в `ods.event_v`, а срок хранения ей не
+повтор заливки схлопывается в `ods.event_v`, а срок хранения ей не помеха — ODS
-помеха — ODS хранит всё. Обе стороны равенства зафиксированы: одна кодом
+хранит всё. Обе стороны равенства зафиксированы: одна кодом генератора, другая
-генератора, другая файлом в git. У межслойной сверки такой опоры нет ни с
+файлом в git. У межслойной сверки такой опоры нет ни с одной стороны.
-одной стороны.
 
-## Срок жизни сырья
+## Срок жизни сырых данных
 
-Сырьё в STG живёт трое суток реального времени и уходит само. Трое — это окно
+Сырые данные в STG живут трое суток реального времени и уходят сами. Трое — это
-отладки: столько сырьё лежит на ноутбуке, чтобы менти успел разобрать полёты,
+окно отладки: столько сырые данные хранятся на ноутбуке, чтобы менти успел
-после чего перестаёт занимать место. Нарезка — по дню загрузки, срок — по той же
+разобрать полёты, после чего перестаёт занимать место. Нарезка — по дню
-колонке `_load_ts`, снятие — целыми кусками (`ttl_only_drop_parts`). В DDL
+загрузки, срок — по той же колонке `_load_ts`, снятие — целыми кусками
-значение проставлено явно, чтобы поведение не зависело от умолчания версии.
+(`ttl_only_drop_parts`). В DDL значение проставлено явно, чтобы поведение не
+зависело от умолчания версии.
 
-Нарезать сырьё по модельному дню события было бы соблазнительно — он единица
+Нарезать сырые данные по модельному дню события было бы соблазнительно — он
-переобработки и он же ключ партиции в ODS, — но чистку это ломает. Кусок
+единица переобработки и он же ключ партиции в ODS, — но чистку это ломает. Кусок
-снимается целиком, только когда в нём истекли все строки, а в партиции модельного
+снимается целиком, только когда в нём истекли все строки, а в партиции
-дня лежит приехавшее в разное реальное время: мерж склеит куски разного возраста,
+модельного дня лежит приехавшее в разное реальное время: мерж склеит куски
-самая свежая строка удержит весь кусок, и данные переживут срок неограниченно.
+разного возраста, самая свежая строка удержит весь кусок, и данные переживут
+срок неограниченно.
 
 В партиции дня загрузки склейка идёт точно так же, и строки в ней тоже разного
 возраста — но не более чем на сутки, потому что партицию закрывает календарный
-день. Отсюда и оценка: сырьё живёт трое суток плюс хвост до суток, а не ровно
+день. Отсюда и оценка: сырые данные живут трое суток плюс хвост до суток, а не
-трое. Оговорка про сроки: TTL исполняется на мержах, а не по будильнику, так что
+ровно трое. Оговорка про сроки: TTL исполняется на мержах, а не по будильнику,
-«уходит само» здесь обещано, а «уходит вовремя» — нет.
+так что «уходит само» здесь обещано, а «уходит вовремя» — нет.
 
-Модельного дня среди колонок сырья нет вовсе. Он свойство содержимого, а
+Модельного дня среди колонок STG нет вовсе. Он свойство содержимого, а
-содержимое разбирает ODS — там `EventDate` и живёт, ключом партиции. Сырьё
+содержимое разбирает ODS — там `EventDate` и живёт, ключом партиции. Сырые
-режется своими координатами: и разбор полётов, и переобработка фильтруют по
+данные режутся по своим координатам: и разбор полётов, и переобработка фильтруют
-`_load_ts`, попадая в ключ партиции, а не идя сплошным проходом. Фильтр по
+по `_load_ts`, попадая в ключ партиции, а не идя сплошным проходом. Фильтр по
 модельному дню вдобавок пропускал бы битые строки — у них дата не извлекается.
 
 Две оси времени тут не совпадают намеренно. Ось модельного времени начинается в
@@ -440,21 +440,21 @@ D0 и к реальному календарю не привязана; паке
 дате был бы просто сломан: он отсчитывает срок от реального «сейчас» и удалял бы
 эталонные дни прямо на входе.
 
-В бою слой сырья иногда собирают на движке `Null` — тогда он не хранится вовсе.
+В бою сырой слой иногда собирают на движке `Null` — тогда он не хранится вовсе.
-Такой вариант отвергнут: на стенде сырьё нужно для отладки, поэтому окно, а не
+Такой вариант отвергнут: на стенде сырые данные нужны для отладки, поэтому окно,
-ноль.
+а не ноль.
 
 ## Таблица ошибок
 
 `ods.event_errors` держит строки, не прошедшие строгий приём, вместе с их сырым
-текстом, метаданными доставки и классом брака. Ключи её собственные, потому что у
+текстом, метаданными доставки и классом брака. Ключи её собственные, потому что
-брака нет разобранных полей: шардируется `cityHash64` сырой строки — `ClientID` у
+у брака нет разобранных полей: шардируется `cityHash64` сырой строки —
-строки, которая не разобралась, взять неоткуда; нарезается по дню загрузки, как и
+`ClientID` у строки, которая не разобралась, взять неоткуда; нарезается по дню
-сырьё; живёт месяц. Дольше сырья — намеренно: если брак истекает вместе с ним,
+загрузки, как и сырые данные; живёт месяц. Дольше сырых данных — намеренно: если
-разбираться к моменту разбирательства будет уже нечем. Снятие — целыми кусками
+брак истекает вместе с ними, разбираться к моменту разбирательства будет уже
-(`ttl_only_drop_parts`), как у сырья и по той же причине: строки в партиции дня
+нечем. Снятие — целыми кусками (`ttl_only_drop_parts`), как у STG и по той же
-загрузки разного возраста не более чем на сутки, и куску незачем переживать
+причине: строки в партиции дня загрузки разного возраста не более чем на сутки,
-срок из-за самой свежей строки.
+и куску незачем переживать срок из-за самой свежей строки.
 
 Класс брака лежит в колонке `error_class` типа `LowCardinality(String)`. Без неё
 в таблице копятся строки «что-то не так» без ответа на «что именно», а витрине
@@ -500,13 +500,12 @@ kafka_offset)`: смотрят такую таблицу от класса, а
 
 ## Раскладка SQL
 
-Исполняемые дагами запросы лежат по правилу
+Исполняемые дагами запросы лежат по правилу `sql/<слой>/<объект>_<роль>.sql`.
-`sql/<слой>/<объект>_<роль>.sql`. Слой — слой цели запроса: забор заказов в
+Слой — слой цели запроса: забор заказов в STG живёт в
-сырьё живёт в `sql/stg/orders_raw_load.sql`, разбор — в
+`sql/stg/orders_raw_load.sql`, разбор — в `sql/ods/order_parse.sql`. Даг
-`sql/ods/order_parse.sql`. Даг называет файлы, передаёт параметры и задаёт
+называет файлы, передаёт параметры и задаёт порядок выполнения, но не хранит
-порядок выполнения, но не хранит текст преобразований. Два выражения разбора
+текст преобразований. Два выражения разбора делят локальный макрос Jinja в том
-делят локальный макрос Jinja в том же файле; подключаемого SQL-фрагмента между
+же файле; подключаемого SQL-фрагмента между ними нет.
-ними нет.
 
 SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. При разборе Python-кода
 обработчик DAG читает список DDL-файлов, загружает содержимое каждого
@@ -524,10 +523,10 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 |---|---|
 | `00-databases.sql` | базы слоёв и зона справочников |
 | `05-dic-catalog.sql` | подложка над CSV-каталогом и словарь товаров поверх неё |
-| `10-stg-tables.sql` | чтецы топиков `hits` и `orders`, локальные и распределённые таблицы сырья обоих источников |
+| `10-stg-tables.sql` | чтецы топиков `hits` и `orders`, локальные и распределённые таблицы STG обоих источников |
 | `20-ods-tables.sql` | типизированное событие, версии заказа и обе таблицы ошибок |
 | `30-ods-views.sql` | актуальные события, текущие заказы и матвью разбора в ODS |
-| `40-stg-views.sql` | матвью приёма: чтец в сырьё |
+| `40-stg-views.sql` | матвью приёма: чтец в STG |
 | `45-dds-tables.sql` | физические модели заказа, сессии и карты идентичностей, доноры партиций |
 | `50-dds-views.sql` | публичные договоры сущностей DDS |
 | `55-dm-tables.sql` | физические витрины выручки, сверки и трафика, доноры дневных партиций |
@@ -537,14 +536,14 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 правила порядка слоёв к ней не применяются.
 
 Порядок остальных задают два правила. Первое: матвью принадлежит слою своей
-цели, а не источника, — разбор из STG в ODS лежит среди файлов ODS, потому
+цели, а не источника, — разбор из STG в ODS лежит среди файлов ODS, потому что
-что наполняет ODS. Второе: последней среди матвью цепочки Kafka создаётся
+наполняет ODS. Второе: последней среди матвью цепочки Kafka создаётся матвью
-матвью приёма, и потому она нарушает нумерацию слоёв. Kafka-движок начинает
+приёма, и потому она нарушает нумерацию слоёв. Kafka-движок начинает читать
-читать топик, когда к нему привязывают первую матвью; создай её раньше
+топик, когда к нему привязывают первую матвью; создай её раньше разбора — и всё,
-разбора — и всё, что доедет в зазоре, ляжет в сырьё и не попадёт в ODS
+что доедет в зазоре, ляжет в STG и не попадёт в ODS никуда, ни в событие, ни в
-никуда, ни в событие, ни в ошибки. На пустом топике зазор безвреден,
+ошибки. На пустом топике зазор безвреден, поэтому первый прогон о нём не скажет.
-поэтому первый прогон о нём не скажет. Проснётся он, когда тома ClickHouse
+Проснётся он, когда тома ClickHouse снесены, а данные Kafka целы, — то есть на
-снесены, а данные Kafka целы, — то есть на обычной отладке.
+обычной отладке.
 
 Файлы применяет даг `world_initialize` с ноды 1 отдельной учётной записью
 `lifecycle`: один файл — одна последовательная задача
@@ -579,13 +578,13 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 |---|---|---|
 | `stg` | `stg.hits_raw_kafka` | чтец топика `hits`, формат `RawBLOB` |
 | `stg` | `stg.hits_raw_rep` / `_dist` | сырая строка сообщения плюс метаданные доставки |
-| `stg` | `stg.hits_raw_mv` | наполняет сырьё из чтеца |
+| `stg` | `stg.hits_raw_mv` | наполняет STG из чтеца |
 | `stg` | `stg.orders_raw_kafka` | чтец топика `orders`, формат `RawBLOB`, только на ноде 1 и без матвью |
 | `stg` | `stg.orders_raw_rep` / `_dist` | сырое сообщение слепка, метаданные доставки и `_load_id` |
 | `ods` | `ods.event_rep` / `_dist` | типизированное широкое событие |
 | `ods` | `ods.event_v` | актуальная версия события с полями источника |
 | `ods` | `ods.event_errors_rep` / `_dist` | строки, не прошедшие строгий приём |
-| `ods` | `ods.event_mv`, `ods.event_errors_mv` | разбор сырья в событие и в ошибки |
+| `ods` | `ods.event_mv`, `ods.event_errors_mv` | разбор STG в событие и в ошибки |
 | `ods` | `ods.order_rep` / `_dist` | типизированные версии заказа |
 | `ods` | `ods.order_v` | текущая версия заказа на языке источника |
 | `ods` | `ods.order_errors_rep` / `_dist` | строки слепка, не прошедшие строгий приём |
@@ -612,9 +611,8 @@ SQL-файлы исполняет штатный `SQLExecuteQueryOperator`. Пр
 | `dic` | `dic.products_file` | чтец CSV-каталога, общего с генератором |
 | `dic` | `dic.products` | словарь товаров поверх подложки |
 
-Матвью разбора у заказов нет: срез сырья раскладывают по этим двум целям два
+Матвью разбора у заказов нет: срез STG раскладывают по этим двум целям два
-`INSERT SELECT` одной задачи `parse_batch` из файла
+`INSERT SELECT` одной задачи `parse_batch` из файла `sql/ods/order_parse.sql`.
-`sql/ods/order_parse.sql`.
 
 В слое DDS построены событие, заказ, сессия и карта идентичностей. Событие
 остаётся представлением над ODS; заказ и сессия гасят повтор заменой партиции;
@@ -655,11 +653,11 @@ DDL-словарь с файловым источником внутри `user_f
 **Проверка ко-локации заказов 22 августа 2026 года (#137).** Context7 и
 `system.settings` закреплённого ClickHouse 26.3 назвали одну и ту же тройку
 значений `parallel_distributed_insert_select`: `0` — выключено, `1` — `SELECT`
-на каждом шарде, `2` — `SELECT` и `INSERT` на каждом шарде; заводское — `2`.
+на каждом шарде, `2` — `SELECT` и `INSERT` на каждом шарде; заводское — `2`. На
-На живых данных видны и дефект, и починка: до правки 1189 из 1662 заказов
+живых данных видны и дефект, и починка: до правки 1189 из 1662 заказов лежали на
-лежали на обоих шардах, после явного нуля и повторного разбора того же
+обоих шардах, после явного нуля и повторного разбора того же `_load_id` — ни
-`_load_id` — ни одного. Вершина версий уцелела: деловые поля `ods.order_v`
+одного. Вершина версий уцелела: деловые поля `ods.order_v` сошлись с эталоном,
-сошлись с эталоном, посчитанным прямо из сырья.
+посчитанным прямо из STG.
 
 **Проверка версий заказов 18 августа 2026 года (#94).** MCP Context7 подтвердил,
 что `JSONType` возвращает имя типа значения JSON, — на нём стоит проверка типов
@@ -683,19 +681,19 @@ DDL-словарь с файловым источником внутри `user_f
   потолком разбор отдаёт как `NULL`. Это ловит опыт, который берёт «заведомо
   далёкий» год: 2999-й не разбирается вовсе.
 
-Про сам приём заказов снято следующее. Предикат формы провода разложил все
+Про сам приём заказов снято следующее. Предикат формы провода разложил все 13
-13 661 строку сырья, приехавшую при исполнении #93, без исключений и без
+661 строку STG, приехавшую при исполнении #93, без исключений и без `NULL`: 13
-`NULL`: 13 653 годных и 8 брака, сумма сошлась с общим счётом по каждому
+653 годных и 8 брака, сумма сошлась с общим счётом по каждому `_load_id`,
-`_load_id`, пересечение ветвей — ноль. Все восемь строк брака — версии одного
+пересечение ветвей — ноль. Все восемь строк брака — версии одного заказа с
-заказа с отрицательным `total`; это дефект генератора, разобранный в
+отрицательным `total`; это дефект генератора, разобранный в [спецификации
-[спецификации приёма](orders/ingestion.md), «Что проверено». На управляемой
+приёма](orders/ingestion.md), «Что проверено». На управляемой порции из пяти
-порции из пяти строк (две версии одного заказа плюс по одной строке каждого
+строк (две версии одного заказа плюс по одной строке каждого класса брака)
-класса брака) годные ушли в `ods.order`, брак — в `ods.order_errors` с
+годные ушли в `ods.order`, брак — в `ods.order_errors` с ожидаемыми классами.
-ожидаемыми классами. Обе версии легли в одну партицию и на один шард; `FINAL`
+Обе версии легли в одну партицию и на один шард; `FINAL` через распределённую
-через распределённую таблицу вернул одну строку — ту, что несла позднейшую
+таблицу вернул одну строку — ту, что несла позднейшую версию, — тогда как
-версию, — тогда как физический счёт показывал две. Повтор задачи с тем же
+физический счёт показывал две. Повтор задачи с тем же `_load_id` строку в
-`_load_id` строку в `ods.order_v` и её `_load_ts` не изменил, а таблица ошибок
+`ods.order_v` и её `_load_ts` не изменил, а таблица ошибок записала тот же брак
-записала тот же брак второй раз, как и обещано спецификацией приёма.
+второй раз, как и обещано спецификацией приёма.
 
 Отдельно измерено, что **сводка вставки не годится в счётчики строк**: у
 запроса с `WHERE` `read_rows` считает прочитанное с диска, а не подошедшее, —
@@ -758,27 +756,26 @@ DDL-словарь с файловым источником внутри `user_f
   вовсе, до 7 августа утверждение держалось на опыте владельца.
 - Упавшая матвью роняет вставку и останавливает потребление до починки.
   Проверено сносом цели — распределённой `ods.event_dist` — при живом чтеце: за
-  двадцать секунд (сброс блока идёт за 7,5) в сырьё не приехало ничего, а
+  двадцать секунд (сброс блока идёт за 7,5) в STG не приехало ничего, а офсет
-  офсет группы застыл с отставанием в одно сообщение. Цель вернули — сообщение
+  группы застыл с отставанием в одно сообщение. Цель вернули — сообщение доехало
-  доехало само, без повторной отправки, отставание ушло в ноль, событие
+  само, без повторной отправки, отставание ушло в ноль, событие разобралось.
-  разобралось. Сносить надо именно распределённую таблицу: вставка в
+  Сносить надо именно распределённую таблицу: вставка в `Distributed` кладёт
-  `Distributed` кладёт блок в спул и сразу возвращает управление, так что на
+  блок в спул и сразу возвращает управление, так что на сносе локальной ошибка
-  сносе локальной ошибка всплыла бы фоном и утверждение показалось бы
+  всплыла бы фоном и утверждение показалось бы опровергнутым.
-  опровергнутым.
+- `_load_ts` в `ods.event` — это метка исходной строки STG, а не время
-- `_load_ts` в `ods.event` — это метка исходной строки сырья, а не время
   разбора. Сверено по `WatchID` на двух тысячах событий модельного дня,
   залитого дважды: у каждого события метка совпала с меткой одной из двух его
   доставок, а после `FINAL` — с меткой поздней. Случаев «метки нет среди
   доставок» ноль, то есть `now64()` в матвью разбора нет.
 - Пересозданная матвью пропускает ближайшие сообщения. Снятые и заново
-  созданные матвью разбора при живом чтеце: сообщение, отправленное сразу
+  созданные матвью разбора при живом чтеце: сообщение, отправленное сразу после,
-  после, легло в сырьё и не попало в ODS никуда — ни в событие, ни в ошибки;
+  легло в STG и не попало в ODS никуда — ни в событие, ни в ошибки; то же
-  то же сообщение через минуту разобралось штатно. Воспроизведено дважды
+  сообщение через минуту разобралось штатно. Воспроизведено дважды 7 августа
-  7 августа 2026 года. Это тот же зазор, о котором предупреждает нумерация
+  2026 года. Это тот же зазор, о котором предупреждает нумерация файлов DDL,
-  файлов DDL, только приходит он с другой стороны — не при первом создании, а
+  только приходит он с другой стороны — не при первом создании, а при замене
-  при замене матвью на работающем стенде. Практический вывод один: правишь
+  матвью на работающем стенде. Практический вывод один: правишь матвью — не верь
-  матвью — не верь ближайшей отправке, повтори её. Чем именно держится
+  ближайшей отправке, повтори её. Чем именно держится задержка, не измерено;
-  задержка, не измерено; наблюдение записано как наблюдение.
+  наблюдение записано как наблюдение.
 - Форма ключа `ods.event` принимается такой, как её задумала спека: выражение
   `intHash32(ClientID)` стоит в ключе сортировки `ReplacingMergeTree`, а
   `SAMPLE BY` — по тому же выражению. Вопрос стоял открытым в разделе 11
@@ -811,18 +808,19 @@ DDL-словарь с файловым источником внутри `user_f
 
 Оговорка к первому опыту, и она измеренная: граница проходит по пустоте. Запись
 Kafka с пустым значением (ноль байт) и запись-надгробие (значение `null`)
-читаются, двигают офсет потребителя и не дают строки вовсе — ни в сырьё, ни в
+читаются, двигают офсет потребителя и не дают строки вовсе — ни в STG, ни в
-таблицу ошибок; приём при этом не останавливается. Проверено 5 августа
+таблицу ошибок; приём при этом не останавливается. Проверено 5 августа 2026
-2026 года: в топик ушли четыре записи — пустая, обычная, надгробие, обычная, —
+года: в топик ушли четыре записи — пустая, обычная, надгробие, обычная, — в STG
-в сырьё приехали две, а офсет группы сдвинулся на все четыре. Формат тут ни при
+приехали две, а офсет группы сдвинулся на все четыре. Формат тут ни при чём:
-чём: `LineAsString`, запасной по [ADR 0005](../adr/0005-event-ingestion.md), на
+`LineAsString`, запасной по [ADR 0005](../adr/0005-event-ingestion.md), на том
-том же наборе даёт ровно те же две строки и тот же офсет.
+же наборе даёт ровно те же две строки и тот же офсет.
 
 Свойство принято осознанно и переделкой не закрывается. Генератор стенда пустых
 сообщений не шлёт, приём от них не встаёт, а менять решённый формат из-за
 случая, которого стенд не производит, — размен не в ту сторону. Знать о нём
 стоит ровно затем, чтобы не искать пропавшую строку глазами: пропуск виден в
-самом сырье, `kafka_offset` лежит там колонкой, и дырка в офсетах — это он.
+самой таблице STG, `kafka_offset` лежит там колонкой, и дырка в офсетах — это
+он.
 
 Оговорка к третьему опыту, и она сама непроверенная: `CREATE ... Distributed AS
 <локальная>` копирует умолчания колонок, а значит, умолчание, оказавшееся заодно
@@ -865,7 +863,7 @@ Kafka с пустым значением (ноль байт) и запись-н
 - **`JSONExtract` читает `Decimal` и из числа JSON.** Массив
   `purchaseRevenue`, объявленный источником как `Array(Float64)`, разбирается
   сразу в `Array(Decimal(18, 2))`. Синтаксис подтвержден через Context7 и на
-  ClickHouse 26.3; все суммы после ODS совпали с сырьем до копейки.
+  ClickHouse 26.3; все суммы после ODS совпали с сырыми данными до копейки.
 
 **Сказано по памяти, проверки нет.** Группа пуста: оба утверждения, ждавшие
 матвью разбора, закрыты опытами при исполнении #43 и переехали выше.

docs/architecture/testing.md

@@ -23,9 +23,9 @@
 заметит потерянного подключения Superset: он про ClickHouse и только.
 
 Отсюда правило для новой проверки: **спроси, кого она спрашивает.** Счётчики
-против описи — вопрос к ClickHouse: строки в `ods.event` считает сам
+против паспорта — вопрос к ClickHouse: строки в `ods.event` считает сам сервер и
-сервер и отвечает сразу, значит дом им в `check-clickhouse`, даже если по цене
+отвечает сразу, значит дом им в `check-clickhouse`, даже если по цене они
-они подошли бы смоуку.
+подошли бы смоуку.
 
 ## Карта целей
 
@@ -36,19 +36,19 @@
 Стенд нужен трём целям из восьми. Цена — замер, см. «Что проверено».
 `make smoke` и `make check-services` перемерены 28 августа 2026 года,
 `make config-test` — 21 августа, `make check-clickhouse` — 19 августа,
-корневой `make lint` — 9 августа, `make test` — 30 августа; остальные стоят с
+корневой `make lint` — 3 сентября, `make test` — 30 августа; остальные стоят с
 замера 6 августа.
 
 | Цель | Откуда | Что утверждает | Стенд | Цена |
 |---|---|---|---|---|
 | `make config-test` | корень | Compose разбирается, файлы DAG и дашборды Grafana синтаксически целы, в diff нет пробельных ошибок. О работоспособности не говорит ничего | не нужен | 1 с |
-| `make lint` | корень | Код стенда — `dags/` и `infra/superset/` — отформатирован и проходит ruff | не нужен | 0,4 с |
+| `make lint` | корень | Код стенда и сборщик карты отформатированы и проходят ruff; готовый HTML карты соответствует исходникам | не нужен | 0,8 с |
 | `make smoke` | корень | Стенд **собран**: службы живы, порты отвечают, подключения настроены друг на друга. Вширь и по касательной к каждой службе. Единственная цель, которая здесь правда смоук | нужен | 25 с |
-| `make check-clickhouse` | корень | Всё, что спрашивают **у ClickHouse** и он отвечает сам: макросы, шарды, реплики, путь в keeper, ключ шардирования, очередь распределённых DDL, ответ словаря товаров, счёт событий стартового мира против описи | нужен | 24 с |
+| `make check-clickhouse` | корень | Всё, что спрашивают **у ClickHouse** и он отвечает сам: макросы, шарды, реплики, путь в keeper, ключ шардирования, очередь распределённых DDL, ответ словаря товаров, счёт событий стартового мира против паспорта | нужен | 24 с |
 | `make check-services` | корень | **Службы работают**: DAG запускается и доходит, топик создаётся и удаляется, Superset логинится и ходит в базу | нужен | 71 с |
 | `make lint` | `generator/` | Код генератора отформатирован и проходит ruff | не нужен | 0,4 с |
 | `make typecheck` | `generator/` | Типы генератора сходятся (ty) | не нужен | 0,5 с |
-| `make test` | `generator/` | Генератор делает то, что обещает; схема события остаётся объявленным контрактом, а собранные из кода [описание выгрузки](../formats/clickstream-event.md) и [опись мира](../../data/world-inventory.json) — свежими | не нужен | 176,5 с |
+| `make test` | `generator/` | Генератор делает то, что обещает; схема события остаётся объявленным контрактом, а собранные из кода [описание выгрузки](../formats/clickstream-event.md) и [паспорт мира](../../data/world-inventory.json) — свежими | не нужен | 176,5 с |
 
 **Строк с именем `make lint` две, и это не опечатка.** Одноимённые цели за
 разными дверями охватывают разное: корневая не видит ни одного файла
@@ -76,9 +76,18 @@
 Airflow. В цену целей она не входит. На готовом мире подъём больше не
 пересчитывает данные: `world_initialize` зеленеет без изменений.
 
+`make up` собирает локальные образы Airflow, Superset и Grafana, поднимает весь
+стенд и ждёт здорового состояния долгоживущих контейнеров. В образ Airflow
+добавлены закреплённые клиенты ClickHouse и Kafka. Одноразовые `airflow-init` и
+`superset-init` завершаются с кодом 0. Первый обновляет схему Airflow,
+подготавливает администратора и два подключения к `clickhouse-01`. Второй
+обновляет Superset, создаёт администратора и импортирует подключение к
+`clickhouse-02`. На ноутбуке в режиме энергосбережения приёмочный подъём с
+пустых томов занял около десяти минут, повторный на живом стенде — около трёх.
+
 `make rebuild-storage` тоже не проверка. Команда через Airflow удаляет
 прикладные базы ClickHouse, топики и позиции групп Kafka, заново применяет DDL,
-заливает стартовый мир и возвращает его пульт к концу стартовых дней. Службы и
+заливает стартовый мир и возвращает его позицию к концу стартовых дней. Службы и
 их тома она сохраняет, поэтому возврат к каноническим данным не требует
 холодного запуска всего стенда.
 
@@ -119,13 +128,12 @@ ClickHouse отвечает сразу.
 
 Правки генератора добавляют к этому `make lint`, `make typecheck` и `make test`
 из каталога `generator/`: стенд им не нужен, а `make test` из них самая
-дорогая. Правки дагов и Superset — корневой `make lint`.
+дорогая. Правки дагов, Superset и карты — корневой `make lint`.
 
 Двадцать секунд из ее ста семидесяти шести — пересборка восьми модельных дней
-для сверки с описью мира (20,5 с из 176,5). Дешевле хеши не сравнить: чтобы
+для сверки с паспортом мира (20,5 с из 176,5). Дешевле хеши не сравнить: чтобы
-узнать, тот ли получается мир, его надо получить. Место выбрано по той же
+узнать, тот ли получается мир, его надо получить. Место выбрано по той же оси
-оси «кого спрашивают» — вопрос обращён к коду генератора, стенд ему не
+«кого спрашивают» — вопрос обращён к коду генератора, стенд ему не нужен, — и
-нужен, — и
 краснеет проверка там, где надо: сразу после правки генератора. Не будь её,
 расхождение всплыло бы получасом позже, на поднятом стенде, где выглядит
 поломкой хранилища, а не забытой пересборкой.
@@ -163,10 +171,10 @@ ClickHouse отвечает сразу.
 жизнь с менти, а интеграционный прогон в неё не входит; самое большее, он
 становится темой урока.
 
-Довод не про цену прогона, а про данные. Вложенное остаётся: у сырья срок
+Довод не про цену прогона, а про данные. Вложенное остаётся: у сырых данных срок
 жизни трое суток, а ODS хранит всё, и события, которых мир не рождал, лягут в
-лабы менти неотличимо от настоящих — считая конверсию, он молча посчитает и
+лабы менти неотличимо от настоящих — считая конверсию, он молча посчитает и их.
-их. Хуже явного мусора: явный видно.
+Хуже явного мусора: явный видно.
 
 Отсюда правило для того, что всё-таки вкладывает: **прибираться за собой.**
 Дешевле всего это выходит партицией — опыт играет модельный день за границей
@@ -175,10 +183,10 @@ ClickHouse отвечает сразу.
 же механизм, на котором стоит переобработка дня X.
 
 Что тогда стережёт цепочку постоянно — проверки на **настоящих** данных, тех,
-что стенд произвёл сам: подневный счёт событий против описи мира ловит и
+что стенд произвёл сам: подневный счёт событий против паспорта мира ловит и
 сломанный разбор (события уехали в брак — счёт разошёлся), и потерю по дороге,
-ничего при этом не вкладывая. Это единственный постоянный сторож цепочки
+ничего при этом не вкладывая. Это единственный постоянный сторож цепочки Kafka →
-Kafka → STG → ODS, и живёт он в `make check-clickhouse`.
+STG → ODS, и живёт он в `make check-clickhouse`.
 
 Правило, которое такая проверка обязана выдержать и которое стоит держать в
 голове для следующей: **на растущих данных утверждать можно только про
@@ -237,8 +245,51 @@ Kafka → STG → ODS, и живёт он в `make check-clickhouse`.
 скриптов нет. Отдельной проверкой этот вход тоже не считается: то же самое
 утверждает смоук.
 
+### Что спрашивает смоук
+
+`make smoke` за секунды спрашивает, собран ли стенд: зависимости машины,
+здоровье контейнеров, устройство keeper, ответ Kafka с машины через отображённый
+порт, четыре цели Prometheus, два источника Grafana, компоненты Airflow и
+подготовленное подключение к `clickhouse-01`.
+
+Двенадцать проверок здоровья сразу после `make up --wait` повторяют то, чего
+Compose уже дождался: у каждой долгоживущей службы есть своя `healthcheck`.
+Оставлены они потому, что первый вопрос к стенду всё равно «всё ли живо», а
+ответ на него стоит меньше секунды. Устройство keeper — другое дело: он должен
+работать от пользователя `clickhouse`, с пределом в 262144 открытых файла и со
+своим томом под данные. Всё это объявлено в `compose.yaml`, но здоровым keeper
+выглядит и без этого, поэтому смоук спрашивает у живого контейнера, дошли ли
+объявленные настройки до процесса.
+
+Kafka по той же причине спрашивают снаружи. Её `healthcheck` обращается к
+брокеру изнутри контейнера и по внутреннему слушателю, поэтому здоровой Kafka
+остаётся и тогда, когда объявленный наружу адрес ведёт не туда. Клиент с машины
+в этом случае подключается, получает метаданные и молча виснет на адресе,
+которого с его стороны не существует. Смоук идёт тем же путём, что и будущий
+генератор: стучится в отображённый порт и просит список топиков.
+
+### Что спрашивают глубокие проверки
+
+`make check-services` проверяет то, ради чего приходится ждать службу: работу с
+топиком Kafka с машины — создан, найден, удалён, — ручной запуск пробников
+`test_clickhouse` и `test_kafka`, вход в Superset, его метаданные и подключение
+к `clickhouse-02`. Первый пробник создаёт таблицы на обеих нодах и читает через
+`Distributed` на ноде 2 строку из локальной таблицы ноды 1. Второй пишет в Kafka
+и читает свой маркер. Временный топик проверки с машины и запуски DAG удаляются;
+постоянный топик пробника сохраняется, а старые записи чистит Kafka.
+
+`make check-clickhouse` запускает отдельную глубокую проверку ClickHouse:
+описание кластера, макросы, связь с keeper, `ReplicatedMergeTree`,
+`Distributed`, очередь распределённых DDL и очистку временных таблиц. Девятая из
+десяти проверок спрашивает словарь товаров на обеих нодах. Последняя — подневный
+счёт событий против паспорта, о нем сказано выше.
+
 ## Что проверено
 
+**Перезамер 3 сентября 2026 года при исполнении #222.** `make lint` прошел за
+0,768 секунды; в таблице 0,8 с. `ruff format --check` проверил 13 файлов стенда,
+включая исходники карты, а затем проверка рендера подтвердила свежесть HTML.
+
 **Калибровка заказной стороны 30 августа 2026 года при исполнении #194.**
 Пересборки эталонного мира не будет (#192), поэтому доли заказной стороны
 сверены замером внутренностей генератора — окно 28 модельных дней,
@@ -304,11 +355,11 @@ wc -c /tmp/stage7-events.jsonl /tmp/stage7-snapshot-{1,2,3,4,5,6,7}.jsonl
 time make test
 ```
 
-Опись пересобралась за 20,515 с. Файловый приемник записал 460 731 812 байт:
+Паспорт пересобрался за 20,515 с. Файловый приемник записал 460 731 812 байт:
-458 478 771 байт событий и 2 253 041 байт слепков. `make test` прошел 437/0
+458 478 771 байт событий и 2 253 041 байт слепков. `make test` прошел 437/0 за
-за 176,476 с. Прежние 71 с (7 августа, #42) выросли по двум причинам: тестов
+176,476 с. Прежние 71 с (7 августа, #42) выросли по двум причинам: тестов стало
-стало 437 против 407, и потяжелел сам мир — та же пересборка восьми дней
+437 против 407, и потяжелел сам мир — та же пересборка восьми дней стоила 13 с,
-стоила 13 с, теперь 20,5. Эта правка добавила один тест — проигрыш дня.
+теперь 20,5. Эта правка добавила один тест — проигрыш дня.
 
 **Приемка #172 28 августа 2026 года.** Холодный `create_app()` занимал
 28,3-28,4 секунды, а чтение подключения после запуска - 0,07 секунды. Предел
@@ -416,45 +467,45 @@ shell-версия узкой пересборки за 2 м 25 с пересо
 `make up` после `make clean` прошёл за 8 м 18 с, повтор на живом стенде — за
 3 м 35 с. Отправка семи слепков заняла около 28 секунд.
 
-Прежний замер ниже — 2 м 50 с и 1 м 5 с до появления приёма заказов и пульта
+Прежний замер ниже — 2 м 50 с и 1 м 5 с до появления приёма заказов и дагов
-мира. Весь рост приписывать слепкам нельзя: на холодном прогоне основное время
+модельного времени. Весь рост приписывать слепкам нельзя: на холодном прогоне
-ушло ещё до сценариев ожидания: `airflow-init` завершился примерно на 320-й
+основное время ушло ещё до сценариев ожидания: `airflow-init` завершился
-секунде, обработчик DAG стал здоров примерно на 458-й. Числа здесь называют
+примерно на 320-й секунде, обработчик DAG стал здоров примерно на 458-й. Числа
-цену нынешнего стенда, а не выносят вердикт о регрессии.
+здесь называют цену нынешнего стенда, а не выносят вердикт о регрессии.
 
 **Перезамер 19 августа 2026 года при исполнении #95.** После добавления десятой
 проверки словаря `make check-clickhouse` на чисто поднятом стенде прошёл за
 24 секунды. Это цена всей цели, а не одной новой строки.
 
 **Замер 9 августа 2026 года при появлении корневого `lint` (#65).** Три прогона
-подряд — 0,39, 0,36 и 0,39 секунды на трёх файлах стенда; в таблице 0,4 с. На
+подряд — 0,39, 0,36 и 0,39 секунды на трех файлах стенда, которые тогда входили в проверку; в таблице 0,4 с. На
 машине с непрогретым кешем первый прогон дороже: `uvx` сначала скачивает ruff.
 
 Тогда же снято, что двери не перекрываются: `ruff check --show-files` из корня
-перечисляет ровно три файла стенда, из `generator/` — только файлы генератора.
+перечислял ровно три файла стенда, из `generator/` — только файлы генератора.
 Корневой конфиг правила генератору не подменяет: конфиг ищется вверх по дереву
 от файла, и ближний выигрывает.
 
 **Перезамер 7 августа 2026 года при исполнении #42.** Подъём стенда с нуля
-(`make clean && make up`) — 2 м 50 с, из них 22,5 с занимает сама заливка:
+(`make clean && make up`) — 2 м 50 с, из них 22,5 с занимает сама заливка: 18,7
-18,7 с генерация восьми дней и 3,8 с доставка 401 185 сообщений в Kafka.
+с генерация восьми дней и 3,8 с доставка 401 185 сообщений в Kafka. Повторный
-Повторный `make up` на живом стенде — 1 м 5 с: мир заливается заново, и это
+`make up` на живом стенде — 1 м 5 с: мир заливается заново, и это не оплошность
-не оплошность — `WatchID` те же, повтор схлопнет `ReplacingMergeTree`.
+— `WatchID` те же, повтор схлопнет `ReplacingMergeTree`. Смоук — 9 с,
-Смоук — 9 с, `check-clickhouse` — 8 с с новой девятой проверкой. `make test`
+`check-clickhouse` — 8 с с новой девятой проверкой. `make test` вырос до 71 с:
-вырос до 71 с: 58 с прежних тестов плюс 13 с на пересборку восьми дней для
+58 с прежних тестов плюс 13 с на пересборку восьми дней для сверки с паспортом.
-сверки с описью. Прежние 40 с в таблице устарели ещё до #42 — тесты добавляли
+Прежние 40 с в таблице устарели ещё до #42 — тесты добавляли
 #41 и #43.
 
 Что новая проверка **умеет краснеть**, снято двумя поломками того же дня, и
 проверялись обе ветви её диагноза. Снесли партицию `2026-06-03` в
 `ods.event_rep` — проверка покраснела, показала недостающий день и назвала
-адрес: «таблица брака пуста, события не доехали до ODS, начните с чтеца
+адрес: «таблица брака пуста, события не доехали до ODS, начните с чтеца топика».
-топика». Затем положили в сырьё заведомо негодную строку — брак появился, и
+Затем положили в STG заведомо негодную строку — брак появился, и диагноз
-диагноз сменился на второй, с признаком для различения: «сойдётся недостача с
+сменился на второй, с признаком для различения: «сойдётся недостача с числом
-числом брака — сломан разбор, не сойдётся — брак от прежних опытов». Строки
+брака — сломан разбор, не сойдётся — брак от прежних опытов». Строки опыта
-опыта убраны, день переигран `make generate-batch GENERATOR_DAY=2`; счёт
+убраны, день переигран `make generate-batch GENERATOR_DAY=2`; счёт вернулся к
-вернулся к 401 185, и это заодно показало дедупликацию: повтор дня не удвоил
+401 185, и это заодно показало дедупликацию: повтор дня не удвоил счёт под
-счёт под `FINAL`.
+`FINAL`.
 
 Замеры 6 августа 2026 года, стенд поднят заранее. Время взято по `time` и
 совпадает с тем, что цель печатает сама. Оно плавает от прогона к прогону:

docs/architecture/world.md

@@ -0,0 +1,164 @@
+# Мир и модельное время
+
+Оператор управляет модельным временем стенда. Здесь разобрано, как рождается
+мир, что двигает его ось, какие даги играют дни и где хранится позиция. Доводы
+об устройстве дагов модельного времени — в [ADR
+0009](../adr/0009-world-control.md), о безопасном повторном подъёме и жизненном
+цикле мира — в [ADR 0013](../adr/0013-world-lifecycle.md). Почему последний день
+стартового мира неполон и что хранит паспорт, разобрано в [справочнике
+стартового мира](orders/start-world.md) и [справочнике
+паспорта](orders/inventory.md).
+
+## Стартовый мир
+
+Стенд поднимается не пустым: `make up` через REST API запускает даг Airflow
+`world_initialize`. Тот создаёт прикладные топики и схему, собирает образ
+генератора и играет в `hits` первые восемь дней модельного времени — понедельник
+по понедельник, 401 185 событий. Следом второй запуск генератора отправляет в
+`orders` семь слепков — за дни 0…6. Даг ждёт приёма обоих источников и только
+тогда ставит позицию мира в `8`. Так у каждой лабы есть данные, и всегда одни и
+те же.
+
+Последний день намеренно неполон: события дня 7 уже приехали, а его слепок
+уедет только с первым ходом мира. Поэтому на свежем стенде правый край графика
+выручки отстаёт от кликстрима и дозаполняется по мере движения мира — так
+виден разный темп потокового трекера и ночной выгрузки магазина.
+
+Повторный `make up` безопасен: `world_initialize` видит готовую позицию,
+сообщает в журнале, что мир уже существует, и не применяет DDL, не собирает
+образ и не заливает данные повторно. Изменённую схему применяют адресно либо
+явной командой `make rebuild-storage`.
+
+## Паспорт мира
+
+Сам мир в git не хранится: он вычисляется из зерна, поэтому готовая копия была
+бы лишь кэшем. Вместо него лежит **паспорт мира**,
+[`data/world-inventory.json`](../../data/world-inventory.json): зерно, версия
+генератора, хеш каталога товаров и по строке на каждый день — дата, число
+событий и хеш его байтов. У дней с закрытым окном там же лежат счётчики классов
+расхождений по заказам. Паспорт отвечает на единственный вопрос: тот ли это мир,
+что был вчера.
+
+Спрашивают его двое. `make test` в `generator/` сверяет паспорт с тем, что
+собирается из кода сегодня: правка генератора меняет мир, и паспорт надо
+пересобрать — `make inventory` там же. `make check-clickhouse` в корне по дням
+сверяет паспорт с данными, поступившими в `ods.event`. Хеш дня можно пересчитать
+и руками — это обычный `sha256sum` файла, который пишет файловый приёмник:
+
+```bash
+uv run --project generator python -m clickstream_generator batch \
+  --day 0 --file tmp/day0.jsonl
+sha256sum tmp/day0.jsonl
+```
+
+## Как запустить генератор
+
+События производит генератор из [`generator/`](../../generator/). Модельный день
+— функция зерна и номера дня, поэтому один и тот же день всегда даёт те же
+события: обрыв лечится повтором. Позицию на оси генератор не помнит — номер дня
+передаёт вызывающая команда.
+
+Режима два, и различаются они темпом. В **пакетном** режиме события дня
+отправляются подряд, без пауз: так заливается мир и так переигрывается день
+после обрыва. **Живой** держит темп модельного времени — по умолчанию ×60:
+модельные сутки за 24 реальные минуты, суточная волна разворачивается на глазах,
+отставание видно в журнале.
+
+На стенде генератор запускается из отдельного образа как разовая служба. После
+прогона её убирают. Для каждого режима есть своя цель:
+
+```bash
+# день D0 целиком в топик hits
+make generate-batch
+# первая сотня событий дня D3
+make generate-batch GENERATOR_DAY=3 GENERATOR_LIMIT=100
+# день D3 живьём, ускорение ×1000
+make generate-live GENERATOR_DAY=3 GENERATOR_SPEED=1000
+```
+
+| Переменная | Что задаёт | Умолчание |
+| --- | --- | --- |
+| `GENERATOR_DAY` | номер дня на оси мира (D0 — первый) | `0`, задано в `Makefile` |
+| `GENERATOR_LIMIT` | потолок событий на прогон; только `generate-batch` | нет: день целиком |
+| `GENERATOR_SPEED` | ускорение модельного времени; только `generate-live` | ×60, задано в генераторе |
+
+Адрес назначения для обеих целей задаёт стенд: внутри сети Compose это брокер
+`kafka:9092` и топик `hits`.
+
+При обычном запуске образ генератора не пересобирается. Если образа нет, Compose
+соберёт его; если есть, использует готовый. После правки `generator/Dockerfile`
+или зависимостей образ пересобирают отдельной командой:
+
+```bash
+docker compose --profile generator build generator
+```
+
+Для заливки стартового мира нужен тот же образ. Перед такой заливкой
+`world_initialize` собирает его из текущего дерева; на готовом мире повторный
+`make up` до сборки не доходит.
+
+Сборка образа и запуск контейнера разделены намеренно. Если цель запуска сама
+пересобирает образ, различие между этими действиями исчезает. Следующий запуск
+покажет, что образ устарел.
+
+Посмотреть на события, не поднимая стенд, помогает файловый приёмник: одно
+событие — одна строка. Флаг `--limit` берёт начало дня вместо целого дня —
+тому, кто смотрит на конвейер, ждать полсотни тысяч событий незачем.
+
+```bash
+uv run --project generator python -m clickstream_generator batch \
+  --day 0 --limit 100 --file tmp/day0.jsonl
+```
+
+За один запуск можно проиграть несколько дней подряд: `--days 8`. Всё, что
+принимается флагами, принимается и переменными окружения — так генератор
+запускают даги модельного времени; полный список у `--help`.
+
+**Значения по умолчанию есть не у всех параметров, и это сделано специально.**
+Зерно, число дней и темп живого дня описывают модель мира — их генератор знает
+сам. День на оси, приёмник и имя топика относятся к конкретному запуску
+генератора на стенде: если их не задать, он откажется работать и вернёт
+ненулевой код ещё до первого события. Поэтому значение дня по умолчанию живёт в
+`Makefile`: день задаёт тот, кто запускает, а не тот, кого запускают.
+
+## Даги модельного времени
+
+Считать дни самому необязательно. В Airflow живут **даги модельного времени**:
+два дага создают начальное состояние мира, а три двигают ось дальше.
+
+| Даг | Что делает |
+| --- | --- |
+| `world_initialize` | создаёт стартовый мир, если его ещё нет; повторный запуск ничего не меняет |
+| `world_recreate` | удаляет только прикладной мир и запускает его создание заново |
+| `world_next_day` | играет следующие дни пачкой; сколько — параметр запуска, по умолчанию один |
+| `world_live_day` | играет следующий день в темпе модельного времени, около двадцати четырёх минут |
+| `world_live` | выключатель: пока снят с паузы, запускает `world_live_day` день за днём |
+
+Сыграв день, шаговый даг отправляет слепок заказов и запускает даг
+`orders_ingest`. Тот забирает слепок из топика `orders` в `stg`; шаговый даг
+ждёт его завершения. Так две половины стенда идут в ногу: упал приём — падает и
+шаговый даг, а позиция остаётся на месте ([ADR
+0008](../adr/0008-order-ingestion.md)).
+
+Позицию хранит переменная Airflow `world_position` — номер первого несыгранного
+дня. Шаговый даг записывает позицию только после успешного завершения дня:
+оборванный прогон позицию не двигает, и следующий запуск играет тот же день
+заново. Отсутствующая переменная означает, что мир ещё не создавали; `-1` —
+очистка не закончена, `0` — очистка закончена, а начальная генерация ещё не
+завершена. Шаговые даги начинают играть только с позиции `8` и больше.
+
+В форме запуска можно выбрать только число дней. Первый день шаговый даг берёт
+из `world_position`. Поля «Logical date» и «Run ID» спрятаны в «Advanced
+Options». Они нужны самому Airflow и на выбор дня не влияют. Сыгранные дни и
+новую позицию шаговый даг пишет в журнал шага `remember_played`.
+
+Выключатель создаётся на паузе. Снимите — мир поедет сам; поставите обратно —
+встанет на границе модельных суток, доиграв начатый день. Форма дагов времени и
+доводы целиком — [ADR 0009](../adr/0009-world-control.md).
+
+**У этого решения есть цена: планировщик Airflow подключён к сокету Docker.**
+Без него планировщик не сможет запустить контейнер генератора. Доступ к сокету
+равен правам root на машине; для локального учебного стенда это приемлемо, но
+знать об этом нужно. Доступ даёт не само монтирование сокета, а членство в
+группе `docker`: у неё на каждой машине свой GID. Он записан в `.env`, а узнать
+его можно командой `getent group docker`.

docs/handbook/README.md

@@ -0,0 +1,50 @@
+# Путеводитель по стенду
+
+Если вы впервые видите стенд, начните отсюда. Путеводитель подскажет, на что
+смотреть и в каком порядке, а за подробностями отправит в справочники. Так вы
+разберетесь в устройстве, прежде чем браться за уроки.
+
+## Как читать
+
+Тропа такая: [словарь понятий](../../CONTEXT.md) → главы путеводителя →
+[справочники `docs/architecture/`](../architecture/) →
+[уроки](../labs/README.md).
+
+Словарь не надо читать подряд. Возвращайтесь к нему за незнакомым словом.
+Первая статья словаря объясняет хранилище. Следом идет несколько статей об
+устройстве генератора; они понадобятся нескоро.
+
+## Карта хранилища
+
+[Интерактивная карта](architecture-map.html) показывает путь данных через слои.
+Gitea показывает HTML как текст. Откройте файл из своей копии репозитория
+или скачайте его кнопкой «Raw» и откройте в браузере.
+Держите карту рядом с главой «Хранилище и его слои».
+
+## Главы
+
+### [Хранилище и его слои](storage-layers.md)
+
+От события в Kafka до витрины: глава разбирает путь через STG, ODS, DDS и DM
+и показывает, за что отвечает каждый слой.
+
+### [Потоки Airflow и даги модельного времени](airflow-dags.md)
+
+Шаговый даг играет модельный день, а дневной конвейер раскладывает данные по
+слоям. Глава поможет увидеть их связь и роль каждого дага.
+
+### [Мониторинг: куда смотреть](monitoring.md)
+
+Свежесть и поток данных, брак и отставание собраны на дашборде «Данные».
+Глава научит находить нужную панель и разбирать ее показания.
+
+### [Немного Superset](superset.md)
+
+Глава покажет, как витрина становится графиком и где проходит граница между
+своими объектами и теми, которые поднимает стенд.
+
+### [Генератор: откуда берутся данные](generator.md)
+
+Здесь генератор — источник данных, а не предмет изучения. Глава в общих
+чертах объяснит, откуда берутся события и заказы и в каком виде их получает
+хранилище.

docs/handbook/airflow-dags.md

@@ -0,0 +1,117 @@
+# Потоки Airflow и даги модельного времени
+
+В Airflow два рода дагов. Даги мира создают мир и проигрывают модельные дни,
+а дневной конвейер раскладывает сыгранный день по слоям хранилища.
+
+```mermaid
+flowchart LR
+    world_initialize --> etl_pipeline
+    world_live_day --> etl_pipeline
+    manual[запуск рукой] --> etl_pipeline
+    etl_pipeline --> dds_transform --> dm_transform --> dq_check
+    world_next_day --> sources[источники без ETL]
+```
+
+## Два потока входят по-разному
+
+События приходят в топик `hits`. Хранилище разбирает их само и непрерывно:
+материализованные представления переносят строки из STG в ODS без участия
+Airflow.
+
+Заказы приходят в топик `orders` один раз в модельные сутки, целым слепком. У
+слепка есть начало и конец, поэтому даг `orders_ingest` забирает его одной
+порцией. Такой способ приема называется [пакетным](../../CONTEXT.md).
+
+## Даги мира
+
+Два дага с тегом «жизненный цикл мира» отвечают за стартовый мир:
+
+| Даг | Что делает |
+|---|---|
+| `world_initialize` | Создает стартовый мир, если его еще нет |
+| `world_recreate` | Стирает данные мира и собирает стартовый мир заново |
+
+Три дага с тегом «модельное время» проигрывают следующие дни. Именно их
+называют дагами модельного времени.
+
+| Даг | Что делает |
+|---|---|
+| `world_next_day` | Играет следующие дни пачкой |
+| `world_live_day` | Играет следующий день в темпе модельного времени |
+| `world_live` | Запускает живые дни один за другим, пока снят с паузы |
+
+Сколько дней уже сыграно, стенд помнит в переменной Airflow `world_position`:
+в ней лежит номер первого несыгранного дня. `world_next_day` и `world_live_day`
+записывают новое значение только после успешно сыгранного дня; оборванный
+прогон его не меняет.
+
+Сыграв день D, эти два дага отправляют слепок заказов за день D−1 и ждут, пока
+`orders_ingest` его примет. Эти связи разобраны в [справочнике
+мира](../architecture/world.md#даги-модельного-времени).
+
+## Дневной конвейер
+
+У `etl_pipeline` нет своей обработки. Он по очереди запускает `dds_transform`,
+`dm_transform` и `dq_check` и ждет каждый даг. Параметров у него нет: сколько
+дней обработать, он сам определяет по `world_position` и по тому, что уже лежит
+в слоях. Поэтому один и тот же запуск верен и когда его запустил другой даг, и
+когда вы нажали кнопку, и когда его повторяют после сбоя. Детали есть в
+[справочнике конвейера](../architecture/etl.md#объём-прогона).
+
+`world_next_day` не запускает конвейер. После него слои хранилища отстают от
+мира, пока вы не запустите конвейер сами. `world_live_day`, наоборот,
+запускает `etl_pipeline` и ждет его. Поэтому даг остается в работе и после
+конца модельного дня.
+
+## Что значит красный
+
+Красный `etl_pipeline` не отменяет сыгранного дня: `world_position` уже
+записана. Достаточно перезапустить конвейер рукой; разбираться, на чем
+остановился прошлый прогон, не нужно. Кто запускает конвейер, описано в
+[разделе о трех путях запуска](../architecture/etl.md#три-пути-запуска).
+
+Качество данных проверяет контур DQ. В дневном конвейере это даг `dq_check`:
+упавшая задача печатает в лог ключи строк, не прошедших проверку. Состав
+проверок описан в [разделе «Звено DQ
+конвейера»](../architecture/dm.md#звено-dq-конвейера).
+
+## Как найти в интерфейсе
+
+Даги мира ищите по тегам «модельное время» и «жизненный цикл мира». Остальные
+даги ищите по тегам «заказы», `etl`, `dds`, `dm` и `dq`. `homework_check` с
+тегами `dm` и `labs` проверяет домашние работы; о нем рассказано в учебных
+заданиях.
+
+## Посмотрите сами
+
+Откройте Airflow по адресу из раздела [«Адреса и
+пароли»](../../README.md#адреса-и-пароли). В Admin → Variables найдите
+`world_position`. Затем запустите `world_next_day` на один день по [инструкции
+из README](../../README.md#сдвинуть-мир-вперед). Убедитесь, что `orders_ingest`
+отработал, а витрины еще ничего не получили. Запустите `etl_pipeline` рукой.
+
+В DBeaver, подключенном по
+[инструкции](../../README.md#подключиться-из-dbeaver), выполните два запроса:
+
+```sql
+SELECT report_date, visitors, known_users
+FROM dm.daily_traffic_v
+ORDER BY report_date DESC
+LIMIT 3;
+
+SELECT report_date, sum(revenue) AS revenue
+FROM dm.revenue_daily_v
+GROUP BY report_date
+ORDER BY report_date DESC
+LIMIT 3;
+```
+
+В трафике уже есть сыгранный день, а в выручке только предыдущий: вместе с этим
+днем пришел слепок заказов за предыдущий. Выручка сыгранного дня появится после
+следующего.
+
+## Куда дальше
+
+Детали — в справочниках [конвейера](../architecture/etl.md) и
+[мира](../architecture/world.md). Следующая глава — [«Мониторинг: куда
+смотреть»](monitoring.md).

docs/handbook/architecture-map/README.md

@@ -0,0 +1,9 @@
+# Интерактивная карта хранилища
+
+`map.yaml` хранит слои, узлы, стрелки и тексты карточек.
+`template.html` задает внешний вид и поведение карты.
+`render.py` вкладывает данные в шаблон и пишет файл рядом с главами.
+Правьте исходники, а не `architecture-map.html`.
+Пересоберите карту командой:
+`uv run docs/handbook/architecture-map/render.py`.
+Проверьте свежесть готового файла с флагом `--check`.

docs/handbook/architecture-map/map.yaml

@@ -0,0 +1,695 @@
+title: Карта слоев хранилища
+lead: Проследите, как один смысл меняет имя и поверхность между слоями.
+chapter_url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/handbook/storage-layers.md#user-content-хранилище-и-его-слои
+intro:
+  - Эта карта показывает путь событий и заказов от Kafka до витрин DM.
+  - Щелкните по узлу, чтобы увидеть его назначение, устройство и ключи.
+  - Щелкните по стрелке, чтобы узнать, кто и каким запросом переносит данные.
+  - Когда вы выбираете узел, карта подсвечивает все пути к нему и от него.
+  - Переключатель потока приглушает другую часть карты, но не меняет раскладку.
+  - Сначала прочитайте главу «Хранилище и его слои», затем вернитесь к карте и рассмотрите объекты.
+
+streams:
+  all: Все
+  events: События
+  orders: Заказы
+
+dictionary:
+  title: Словарь
+  caption: 'сбоку цепочки: справочники'
+
+layers:
+  - id: kafka
+    title: Kafka
+    caption: откуда приходит
+  - id: stg
+    title: STG
+    caption: как поступило
+  - id: ods
+    title: ODS
+    caption: язык источника
+  - id: dds
+    title: DDS
+    caption: язык бизнеса
+  - id: dm
+    title: DM
+    caption: данные для дашбордов
+
+mechanisms:
+  - id: materialized_view
+    label: матвью
+    line: solid
+    rhythm: непрерывно, по мере прихода сообщений
+  - id: airflow_dag
+    label: даг Airflow
+    line: dashed
+    rhythm: 'пачкой: раз в модельные сутки (`orders_ingest`) или на каждом прогоне конвейера'
+  - id: view
+    label: представление
+    line: dotted
+    rhythm: без копии, данные читаются на месте
+
+nodes:
+  - id: kafka_hits
+    name: hits
+    layer: kafka
+    order: 0
+    streams: [events]
+    what: Топик Kafka с событиями кликстрима. Каждое сообщение содержит одно событие.
+    read: 'Топик напрямую не читают: таблица `stg.hits_raw_kafka` забирает сообщения из топика. Для данных событий используйте `stg.hits_raw_dist`.'
+    fill:
+      - Источник событий пишет сообщения в топик в темпе выбранного режима мира.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-при%D1%91м-поток-и-его-свойства
+      - label: Формат
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/formats/clickstream-event.md#user-content-описание-выгрузки-событие-кликстрима
+
+  - id: kafka_orders
+    name: orders
+    layer: kafka
+    order: 1
+    streams: [orders]
+    what: Топик Kafka со слепками заказов магазина. После модельного дня приходит снимок изменяемого окна.
+    read: 'Топик напрямую не читают: таблица `stg.orders_raw_kafka` забирает сообщения из топика. Для заказов используйте `stg.orders_raw_dist`.'
+    fill:
+      - Источник заказов публикует слепок пачкой после каждого модельного дня.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/ingestion.md#user-content-поток-данных
+      - label: Устройство слепка
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/snapshot.md#user-content-слепок-и-его-доставка
+
+  - id: stg_hits
+    name: stg.hits_raw_dist
+    layer: stg
+    order: 0
+    streams: [events]
+    what: Сырая строка события и метаданные доставки. STG сохраняет сообщение без разбора.
+    read: 'Читайте `_dist`: у STG нет представления `_v`, а распределенная таблица показывает оба шарда.'
+    parts:
+      - '`stg.hits_raw_kafka` — чтец топика `hits`.'
+      - '`stg.hits_raw_rep` — реплицируемая таблица на шарде.'
+      - '`stg.hits_raw_dist` — распределенная поверхность записи и чтения.'
+      - '`stg.hits_raw_mv` — матвью приема сообщений из чтеца.'
+    fill:
+      - '`stg.hits_raw_mv` пишет непрерывно, по мере прихода сообщений.'
+      - Сырые строки живут трое суток реального времени плюс хвост до суток.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-при%D1%91м-поток-и-его-свойства
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/10-stg-tables.sql
+      - label: DDL матвью
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/40-stg-views.sql
+
+  - id: stg_orders
+    name: stg.orders_raw_dist
+    layer: stg
+    order: 1
+    streams: [orders]
+    what: Сырые строки слепка заказов, метаданные доставки и идентификатор пачки `_load_id`.
+    read: 'Читайте `_dist`: у STG нет представления `_v`, а распределенная таблица показывает оба шарда.'
+    parts:
+      - '`stg.orders_raw_kafka` — чтец топика `orders` на первой ноде.'
+      - '`stg.orders_raw_rep` — реплицируемая таблица на шарде.'
+      - '`stg.orders_raw_dist` — распределенная поверхность записи и чтения.'
+    fill:
+      - Задача `pull_batch` дага `orders_ingest` забирает слепок пачкой раз в модельные сутки.
+      - Сырые строки живут трое суток реального времени плюс хвост до суток.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/ingestion.md#user-content-поток-данных
+      - label: DDL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/10-stg-tables.sql
+
+  - id: ods_event
+    name: ods.event_v
+    layer: ods
+    order: 0
+    streams: [events]
+    what: Типизированное широкое событие с именами полей источника. Запрос представления с `FINAL` возвращает актуальную версию события.
+    read: 'Читайте `ods.event_v`: запрос представления с `FINAL` возвращает актуальные строки вместо физических версий.'
+    parts:
+      - '`ods.event_rep` — реплицируемая таблица версий события на шарде.'
+      - '`ods.event_dist` — распределенная поверхность записи и диагностики.'
+      - '`ods.event_v` — представление актуального состояния с `FINAL`.'
+      - '`ods.event_mv` — матвью разбора годных строк STG.'
+    keys:
+      - '`WatchID` — тот же идентификатор, что `event_id` в DDS.'
+      - '`ClientID` — тот же посетитель, что `client_id` в DDS.'
+      - '`EventDate` — тот же день, что `event_date` в DDS.'
+    fill:
+      - '`ods.event_mv` разбирает строки непрерывно, по мере записи в STG.'
+      - '`ReplacingMergeTree(_load_ts)` хранит версии, а `FINAL` выбирает актуальную.'
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-актуальные-события
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/20-ods-tables.sql
+      - label: DDL представлений
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/30-ods-views.sql
+
+  - id: ods_event_errors
+    name: ods.event_errors_dist
+    layer: ods
+    order: 1
+    streams: [events]
+    what: Сырые события, которые не прошли строгий прием, с классом ошибки и метаданными доставки.
+    read: 'Читайте `_dist`: представления `_v` нет, а распределенная таблица показывает ошибки с обоих шардов.'
+    parts:
+      - '`ods.event_errors_rep` — реплицируемая таблица ошибок на шарде.'
+      - '`ods.event_errors_dist` — распределенная поверхность чтения и записи.'
+      - '`ods.event_errors_mv` — матвью, которое отбирает негодные строки STG.'
+    fill:
+      - '`ods.event_errors_mv` пишет непрерывно, по мере записи в STG.'
+      - Ошибки живут один месяц и не останавливают прием годных событий.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-таблица-ошибок
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/20-ods-tables.sql
+      - label: DDL матвью
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/30-ods-views.sql
+
+  - id: ods_order
+    name: ods.order_v
+    layer: ods
+    order: 2
+    streams: [orders]
+    what: Текущая версия заказа на языке источника. Позиции пока остаются сырым фрагментом JSON.
+    read: 'Читайте `ods.order_v`: запрос представления с `FINAL` возвращает последнюю версию по `snapshot_date`.'
+    parts:
+      - '`ods.order_rep` — реплицируемая таблица версий заказа на шарде.'
+      - '`ods.order_dist` — распределенная поверхность записи и диагностики.'
+      - '`ods.order_v` — представление текущего состояния с `FINAL`.'
+    keys:
+      - '`order_id` — тот же заказ в `dds.order_v` и `dm.purchase_vs_orders_v`.'
+      - '`user_id` — пользователь магазина, который переходит в заказ DDS.'
+    fill:
+      - Задача `parse_batch` дага `orders_ingest` разбирает пачку раз в модельные сутки.
+      - '`ReplacingMergeTree(snapshot_date)` оставляет версию из последнего принятого слепка.'
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-версии-заказов
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/20-ods-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/30-ods-views.sql
+
+  - id: ods_order_errors
+    name: ods.order_errors_dist
+    layer: ods
+    order: 3
+    streams: [orders]
+    what: Сырые строки слепка, которые не прошли строгий прием, с классом ошибки и `_load_id`.
+    read: 'Читайте `_dist`: представления `_v` нет, а распределенная таблица показывает ошибки с обоих шардов.'
+    parts:
+      - '`ods.order_errors_rep` — реплицируемая таблица ошибок на шарде.'
+      - '`ods.order_errors_dist` — распределенная поверхность чтения и записи.'
+    fill:
+      - Задача `parse_batch` дага `orders_ingest` пишет ошибки из той же пачки, что и годные заказы.
+      - Ошибки живут один месяц и не останавливают прием годных заказов.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-таблица-ошибок
+      - label: DDL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/20-ods-tables.sql
+
+  - id: dds_event
+    name: dds.event_v
+    layer: dds
+    order: 0
+    streams: [events]
+    what: Публичное представление события на языке бизнеса. Его запрос переименовывает поля и расшифровывает категорию устройства.
+    read: 'Читайте `dds.event_v`: запрос представления возвращает явный список колонок DDS.'
+    parts:
+      - '`dds.event_v` — только представление над `ods.event_v`; своей таблицы в DDS нет.'
+    keys:
+      - '`event_id` — тот же идентификатор, что `WatchID` в ODS.'
+      - '`client_id` — тот же посетитель, что `ClientID` в ODS; соединяет событие с сессией и картой идентичностей.'
+      - '`event_date` — тот же день, что `EventDate` в ODS.'
+      - '`purchase_id[1]` — тот же заказ, что `order_id` в DDS и DM.'
+    fill:
+      - Данные для `dds.event_v` читаются из актуальных событий ODS без копии и отдельного расписания.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/event.md#user-content-форма
+      - label: DDL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/50-dds-views.sql
+
+  - id: dds_session
+    name: dds.session_v
+    layer: dds
+    order: 1
+    streams: [events]
+    what: Сессия, которую запрос дага `dds_transform` собирает из последовательных событий одной куки. В источнике готовой сессии нет.
+    read: 'Читайте `dds.session_v`: запрос представления возвращает деловые и служебные колонки.'
+    parts:
+      - '`dds.session_rep` — реплицируемая таблица сессий на шарде.'
+      - '`dds.session_dist` — распределенная поверхность загрузки и диагностики.'
+      - '`dds.session_stage_rep` — донор дневных партиций на шарде.'
+      - '`dds.session_stage_dist` — распределенная поверхность донора.'
+      - '`dds.session_v` — публичное представление.'
+    keys:
+      - '`client_id` — тот же посетитель, что в событии DDS и карте идентичностей.'
+      - '`session_date` — день, который в `dm.daily_traffic_v` называется `report_date`.'
+    fill:
+      - Даг `dds_transform` пересобирает данные прожитых дней при каждом прогоне конвейера.
+      - Задачи `session.rebuild` и `session.replace` собирают день в доноре и заменяют партицию.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/session.md#user-content-движок-и-наполнение
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/45-dds-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/50-dds-views.sql
+
+  - id: dds_order
+    name: dds.order_v
+    layer: dds
+    order: 2
+    streams: [orders]
+    what: Заказ в текущем состоянии на языке бизнеса. Артикулы, количества и цены позиций хранятся в согласованных массивах.
+    read: 'Читайте `dds.order_v`: запрос представления возвращает данные без таблиц и донора партиций.'
+    parts:
+      - '`dds.order_rep` — реплицируемая таблица заказов на шарде.'
+      - '`dds.order_dist` — распределенная поверхность загрузки и диагностики.'
+      - '`dds.order_stage_rep` — донор дневных партиций на шарде.'
+      - '`dds.order_stage_dist` — распределенная поверхность донора.'
+      - '`dds.order_v` — публичное представление.'
+    keys:
+      - '`order_id` — тот же заказ, что в ODS, событии покупки и витрине сверки.'
+      - '`user_id` — пользователь магазина, который входит в карту идентичностей.'
+      - '`item_sku` — тот же артикул, что `sku` в `dic.products`.'
+      - '`order_date` — день, который в витринах называется `report_date` или `order_day`.'
+    fill:
+      - Даг `dds_transform` пересобирает изменяемое окно при каждом прогоне конвейера.
+      - Задачи `order.rebuild` и `order.replace` собирают дни в доноре и заменяют партиции.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/order.md#user-content-движок-и-наполнение
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/45-dds-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/50-dds-views.sql
+
+  - id: dds_identity
+    name: dds.identity_map_v
+    layer: dds
+    order: 3
+    streams: [events, orders]
+    what: Известные пары куки трекера и пользователя магазина. Связь появляется после сопоставленной покупки.
+    read: 'Читайте `dds.identity_map_v`: запрос представления с `FINAL` возвращает актуальные строки полного пересчета.'
+    parts:
+      - '`dds.identity_map_rep` — реплицируемая таблица версий пар на шарде.'
+      - '`dds.identity_map_dist` — распределенная поверхность записи.'
+      - '`dds.identity_map_v` — точное публичное представление с `FINAL`.'
+    keys:
+      - '`client_id` — кука из события и сессии DDS.'
+      - '`user_id` — пользователь магазина из заказа DDS.'
+    fill:
+      - Задача `identity_map` дага `dds_transform` пересчитывает все известные пары после обновления заказов.
+      - Новая версия полного набора пишется при каждом прогоне; `FINAL` скрывает физические повторы.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/identity.md#user-content-сборка
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/45-dds-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/50-dds-views.sql
+
+  - id: dm_daily_traffic
+    name: dm.daily_traffic_v
+    layer: dm
+    order: 0
+    streams: [events]
+    what: Дневные счетчики посетителей и известных пользователей после склейки идентичностей.
+    read: 'Читайте `dm.daily_traffic_v`: запрос представления с `FINAL` возвращает актуальные строки полного пересчета.'
+    parts:
+      - '`dm.daily_traffic_rep` — реплицируемая таблица версий счетчиков.'
+      - '`dm.daily_traffic_dist` — распределенная поверхность записи.'
+      - '`dm.daily_traffic_v` — точное публичное представление с `FINAL`.'
+    keys:
+      - '`report_date` — тот же день, что `session_date` в сессии DDS.'
+    fill:
+      - Задача `daily_traffic` дага `dm_transform` при каждом прогоне пересчитывает всю историю и записывает новую версию.
+      - '`FINAL` оставляет текущую строку каждого дня.'
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmdaily_traffic_v
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/55-dm-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/60-dm-views.sql
+
+  - id: dm_revenue
+    name: dm.revenue_daily_v
+    layer: dm
+    order: 1
+    streams: [orders]
+    what: Дневная выручка, число заказов и единиц товара по категориям.
+    read: 'Читайте `dm.revenue_daily_v`: это публичное представление готовой дневной витрины.'
+    parts:
+      - '`dm.revenue_daily_rep` — реплицируемая таблица витрины на шарде.'
+      - '`dm.revenue_daily_dist` — распределенная поверхность загрузки.'
+      - '`dm.revenue_daily_stage_rep` — донор дневных партиций на шарде.'
+      - '`dm.revenue_daily_stage_dist` — распределенная поверхность донора.'
+      - '`dm.revenue_daily_v` — публичное представление.'
+    keys:
+      - '`report_date` — тот же день, что `order_date` в заказе DDS.'
+      - '`product_category` — категория, найденная по `item_sku` заказа и ключу `sku` словаря.'
+    fill:
+      - Даг `dm_transform` пересобирает изменяемое окно заказов при каждом прогоне конвейера.
+      - Задачи `revenue_daily.rebuild` и `revenue_daily.replace` собирают дни в доноре и заменяют партиции.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmrevenue_daily_v
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/55-dm-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/60-dm-views.sql
+
+  - id: dm_purchase
+    name: dm.purchase_vs_orders_v
+    layer: dm
+    order: 2
+    streams: [events, orders]
+    what: Сверка события покупки с заказом магазина. Одна строка показывает совпадение или класс расхождения.
+    read: 'Читайте `dm.purchase_vs_orders_v`: в результате запроса отсутствующей стороне соответствует `NULL`.'
+    parts:
+      - '`dm.purchase_vs_orders_rep` — реплицируемая таблица сверки на шарде.'
+      - '`dm.purchase_vs_orders_dist` — распределенная поверхность загрузки.'
+      - '`dm.purchase_vs_orders_stage_rep` — донор дневных партиций на шарде.'
+      - '`dm.purchase_vs_orders_stage_dist` — распределенная поверхность донора.'
+      - '`dm.purchase_vs_orders_v` — публичное представление.'
+    keys:
+      - '`order_id` — тот же заказ, что `purchase_id[1]` в событии и `order_id` в заказе DDS.'
+      - '`order_day` — общий день события покупки и заказа.'
+    fill:
+      - Даг `dm_transform` пересобирает изменяемый хвост обоих источников при каждом прогоне конвейера.
+      - Задачи `purchase_vs_orders.rebuild` и `purchase_vs_orders.replace` собирают дни в доноре и заменяют партиции.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmpurchase_vs_orders_v
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/55-dm-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/60-dm-views.sql
+
+  - id: dm_dq
+    name: dm.dq_summary_v
+    layer: dm
+    order: 3
+    streams: [events, orders]
+    what: Текущее состояние пяти атомарных проверок качества по дням. История запусков остается в Airflow.
+    read: 'Читайте `dm.dq_summary_v`: запрос к публичному представлению возвращает последнюю опубликованную сводку дня.'
+    parts:
+      - '`dm.dq_summary_rep` — реплицируемая таблица опубликованной сводки.'
+      - '`dm.dq_summary_dist` — распределенная поверхность чтения и записи.'
+      - '`dm.dq_summary_stage_rep` — общий донор дневных партиций.'
+      - '`dm.dq_summary_stage_dist` — распределенная поверхность донора.'
+      - '`dm.dq_summary_v` — публичное представление.'
+    fill:
+      - Даг `dq_check` при каждом прогоне сначала выполняет все пять проверок, затем заменяет готовые дневные партиции.
+      - '`sessions_vs_reference` — `sql/dq/sessions_vs_reference.sql`.'
+      - '`classes_vs_inventory` — `sql/dq/classes_vs_inventory.sql` и паспорт мира.'
+      - '`revenue_daily_vs_dds` — `sql/dq/revenue_daily_vs_dds.sql`.'
+      - '`purchase_vs_orders_vs_dds` — `sql/dq/purchase_vs_orders_vs_dds.sql`.'
+      - '`daily_traffic_vs_dds` — `sql/dq/daily_traffic_vs_dds.sql`.'
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmdq_summary
+      - label: DDL таблиц
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/55-dm-tables.sql
+      - label: DDL представления
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/60-dm-views.sql
+
+  - id: dic_products
+    name: dic.products
+    layer: dic
+    order: 0
+    streams: [orders]
+    what: Словарь товаров вне цепочки слоев. По артикулу доступны название, бренд, категория и цена.
+    read: 'Читайте `dic.products`: у словаря одна поверхность без суффикса.'
+    parts:
+      - '`dic.products_file` — чтец CSV-каталога из файла репозитория.'
+      - '`dic.products` — словарь в памяти поверх подложки.'
+    keys:
+      - '`sku` — тот же артикул, что `item_sku` в позиции заказа DDS.'
+    fill:
+      - ClickHouse перечитывает подложку каждые 60–90 секунд по настройке `LIFETIME`.
+    links:
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-справочники
+      - label: DDL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/05-dic-catalog.sql
+
+edges:
+  - id: hits_to_stg
+    from: kafka_hits
+    to: stg_hits
+    mechanism: materialized_view
+    streams: [events]
+    rhythm: непрерывно, по мере прихода сообщений
+    actor: Чтец `stg.hits_raw_kafka` и матвью `stg.hits_raw_mv`.
+    join: 'Соединения нет: сообщение кладется строкой целиком.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/40-stg-views.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-при%D1%91м-поток-и-его-свойства
+
+  - id: stg_to_event
+    from: stg_hits
+    to: ods_event
+    mechanism: materialized_view
+    streams: [events]
+    rhythm: непрерывно, по мере прихода сообщений
+    actor: Матвью `ods.event_mv` разбирает годные строки.
+    join: 'Соединения нет: матвью разбирает строку в колонки.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/30-ods-views.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-при%D1%91м-поток-и-его-свойства
+
+  - id: stg_to_event_errors
+    from: stg_hits
+    to: ods_event_errors
+    mechanism: materialized_view
+    streams: [events]
+    rhythm: непрерывно, по мере прихода сообщений
+    actor: Матвью `ods.event_errors_mv` отбирает строки, которые не прошли строгий прием.
+    join: 'Соединения нет: негодная строка уходит целиком вместе с классом ошибки.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/30-ods-views.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/storage.md#user-content-таблица-ошибок
+
+  - id: orders_to_stg
+    from: kafka_orders
+    to: stg_orders
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, раз в модельные сутки
+    actor: Задача `pull_batch` дага `orders_ingest` читает `stg.orders_raw_kafka`.
+    join: 'Соединения нет: сообщение слепка кладется целиком, пачка помечена `_load_id`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/stg/orders_raw_load.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/ingestion.md#user-content-одно-чтение-kafka
+
+  - id: stg_to_order
+    from: stg_orders
+    to: ods_order
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, раз в модельные сутки
+    actor: Задача `parse_batch` дага `orders_ingest` пишет годные версии заказа.
+    join: 'Соединения нет: строка разбирается в колонки, версия задается `snapshot_date`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ods/order_parse.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/ingestion.md#user-content-граница-строгого-при%D1%91ма
+
+  - id: stg_to_order_errors
+    from: stg_orders
+    to: ods_order_errors
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, раз в модельные сутки
+    actor: Задача `parse_batch` дага `orders_ingest` пишет негодные строки той же пачки.
+    join: 'Соединения нет: негодная строка пачки уходит целиком.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ods/order_parse.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/orders/ingestion.md#user-content-граница-строгого-при%D1%91ма
+
+  - id: ods_to_dds_event
+    from: ods_event
+    to: dds_event
+    mechanism: view
+    streams: [events]
+    rhythm: без копии, данные читаются на месте
+    actor: Запрос `dds.event_v` читает данные из `ods.event_v` и переименовывает поля на языке бизнеса.
+    join: 'Соединения нет: представление переименовывает колонки той же строки.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/ddl/50-dds-views.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/event.md#user-content-форма
+
+  - id: event_to_session
+    from: dds_event
+    to: dds_session
+    mechanism: airflow_dag
+    streams: [events]
+    rhythm: пачкой, при каждом прогоне `dds_transform`
+    actor: Задачи `session.rebuild` и `session.replace` дага `dds_transform`.
+    join: 'События одной `client_id` за `event_date` режутся по паузам; `session_id` - `cityHash64(client_id, min(event_time))`.'
+    links:
+      - label: SQL сборки
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/session_rebuild.sql
+      - label: SQL замены
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/session_replace.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/session.md#user-content-движок-и-наполнение
+
+  - id: order_to_dds
+    from: ods_order
+    to: dds_order
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, при каждом прогоне `dds_transform`
+    actor: Задачи `order.rebuild` и `order.replace` дага `dds_transform`.
+    join: 'Соединения нет: из заказа берутся поля и позиции, `order_date` выводится из `created_at`.'
+    links:
+      - label: SQL сборки
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/order_rebuild.sql
+      - label: SQL замены
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/order_replace.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/order.md#user-content-движок-и-наполнение
+
+  - id: event_to_identity
+    from: dds_event
+    to: dds_identity
+    mechanism: airflow_dag
+    streams: [events]
+    rhythm: пачкой, при каждом прогоне `dds_transform`
+    actor: Задача `identity_map` дага `dds_transform` соединяет покупки с заказами.
+    join: 'Строки покупки и заказа соединяются по `purchase_id[1] = order_id`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/identity_map_rebuild.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/identity.md#user-content-сборка
+
+  - id: order_to_identity
+    from: dds_order
+    to: dds_identity
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, при каждом прогоне `dds_transform`
+    actor: Задача `identity_map` дага `dds_transform` соединяет заказы с покупками.
+    join: 'Строки заказа и покупки соединяются по `order_id = purchase_id[1]`; берется `user_id`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dds/identity_map_rebuild.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dds/identity.md#user-content-сборка
+
+  - id: session_to_traffic
+    from: dds_session
+    to: dm_daily_traffic
+    mechanism: airflow_dag
+    streams: [events]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Задача `daily_traffic` дага `dm_transform` считает посетителей по сессиям.
+    join: 'Соединения нет: сессии группируются по `session_date`, который становится `report_date`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/daily_traffic_rebuild.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmdaily_traffic_v
+
+  - id: identity_to_traffic
+    from: dds_identity
+    to: dm_daily_traffic
+    mechanism: airflow_dag
+    streams: [events]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Задача `daily_traffic` дага `dm_transform` считает известных пользователей по `client_id`.
+    join: 'GLOBAL LEFT JOIN по `client_id`; сессии без пары остаются в витрине.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/daily_traffic_rebuild.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmdaily_traffic_v
+
+  - id: order_to_revenue
+    from: dds_order
+    to: dm_revenue
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Задачи `revenue_daily.rebuild` и `revenue_daily.replace` дага `dm_transform`.
+    join: 'Соединения таблиц нет: ARRAY JOIN раскрывает `item_sku`, `item_quantity`, `item_price`; `order_date` становится `report_date`.'
+    links:
+      - label: SQL сборки
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/revenue_daily_rebuild.sql
+      - label: SQL замены
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/revenue_daily_replace.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmrevenue_daily_v
+
+  - id: products_to_revenue
+    from: dic_products
+    to: dm_revenue
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Даг `dm_transform` получает категорию через `dictGet` по `item_sku`; ключ словаря — `sku`.
+    join: 'Категория читается через `dictGet` по `item_sku`; ключ справочника - `sku`.'
+    links:
+      - label: SQL
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/revenue_daily_rebuild.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmrevenue_daily_v
+
+  - id: event_to_purchase
+    from: dds_event
+    to: dm_purchase
+    mechanism: airflow_dag
+    streams: [events]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Задачи `purchase_vs_orders.rebuild` и `purchase_vs_orders.replace` дага `dm_transform` читают покупки.
+    join: 'Покупки группируются по `purchase_id[1]` как `purchase_order_id`; `event_date` становится `purchase_day`, затем GLOBAL FULL OUTER JOIN `purchase_order_id = backend_order_id`.'
+    links:
+      - label: SQL сборки
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/purchase_vs_orders_rebuild.sql
+      - label: SQL замены
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/purchase_vs_orders_replace.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmpurchase_vs_orders_v
+
+  - id: order_to_purchase
+    from: dds_order
+    to: dm_purchase
+    mechanism: airflow_dag
+    streams: [orders]
+    rhythm: пачкой, при каждом прогоне `dm_transform`
+    actor: Задачи `purchase_vs_orders.rebuild` и `purchase_vs_orders.replace` дага `dm_transform` читают заказы.
+    join: 'GLOBAL FULL OUTER JOIN: `purchase_order_id = backend_order_id` (`purchase_id[1]` и `order_id`); отсутствующая сторона получает NULL.'
+    links:
+      - label: SQL сборки
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/purchase_vs_orders_rebuild.sql
+      - label: SQL замены
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/sql/dm/purchase_vs_orders_replace.sql
+      - label: Справочник
+        url: https://git.dementev.space/ddmitry/clickstream-data-platform/src/branch/main/docs/architecture/dm.md#user-content-dmpurchase_vs_orders_v

docs/handbook/architecture-map/render.py

@@ -0,0 +1,54 @@
+# /// script
+# requires-python = ">=3.13"
+# dependencies = ["pyyaml"]
+# ///
+
+"""Собрать интерактивную карту хранилища из YAML и HTML-шаблона."""
+
+from __future__ import annotations
+
+import argparse
+import json
+from pathlib import Path
+
+import yaml
+
+ROOT = Path(__file__).parent
+SOURCE = ROOT / "map.yaml"
+TEMPLATE = ROOT / "template.html"
+OUTPUT = ROOT.parent / "architecture-map.html"
+MARKER = "/*__MAP_DATA__*/"
+NOTICE = (
+    "<!-- Файл собран автоматически. Правьте architecture-map/map.yaml и "
+    "template.html, затем выполните uv run "
+    "docs/handbook/architecture-map/render.py. -->\n"
+)
+
+
+def render() -> str:
+    """Подставить данные карты в шаблон без изменения порядка ключей."""
+    data = yaml.safe_load(SOURCE.read_text(encoding="utf-8"))
+    payload = json.dumps(data, ensure_ascii=False, indent=2)
+    template = TEMPLATE.read_text(encoding="utf-8")
+    return NOTICE + template.replace(MARKER, payload)
+
+
+def main() -> int:
+    """Записать карту или проверить, что готовый файл не устарел."""
+    parser = argparse.ArgumentParser(description=__doc__)
+    parser.add_argument("--check", action="store_true", help="проверить готовый файл")
+    args = parser.parse_args()
+    rendered = render()
+    if args.check:
+        if not OUTPUT.exists() or OUTPUT.read_text(encoding="utf-8") != rendered:
+            print(f"{OUTPUT} устарел; пересоберите карту")
+            return 1
+        print(f"{OUTPUT} соответствует исходникам")
+        return 0
+    OUTPUT.write_text(rendered, encoding="utf-8")
+    print(f"собрана карта: {OUTPUT}")
+    return 0
+
+
+if __name__ == "__main__":
+    raise SystemExit(main())

docs/handbook/architecture-map/template.html

@@ -0,0 +1,454 @@
+<!doctype html>
+<html lang="ru">
+<head>
+  <meta charset="utf-8">
+  <meta name="viewport" content="width=device-width, initial-scale=1">
+  <title>Карта слоев хранилища</title>
+  <style>
+    :root {
+      color-scheme: light;
+      --paper: #f7f7f5;
+      --panel: #ffffff;
+      --ink: #272a2d;
+      --muted: #6b7177;
+      --line: #8c9298;
+      --soft: #e6e8e9;
+      --accent: #b54a2a;
+      --accent-soft: #f5ded7;
+    }
+    * { box-sizing: border-box; }
+    body {
+      margin: 0;
+      background: var(--paper);
+      color: var(--ink);
+      font: 15px/1.45 system-ui, -apple-system, BlinkMacSystemFont, "Segoe UI", sans-serif;
+    }
+    header { padding: 22px 26px 12px; }
+    h1 { margin: 0 0 5px; font-size: 25px; }
+    .lead { margin: 0; color: var(--muted); }
+    .controls {
+      display: flex;
+      flex-direction: column;
+      align-items: flex-start;
+      gap: 8px;
+      padding: 8px 26px 16px;
+    }
+    .switcher { display: flex; gap: 6px; }
+    button {
+      border: 1px solid #aeb3b7;
+      border-radius: 18px;
+      background: var(--panel);
+      color: var(--ink);
+      padding: 6px 13px;
+      font: inherit;
+      cursor: pointer;
+    }
+    button[aria-pressed="true"] {
+      border-color: var(--accent);
+      background: var(--accent-soft);
+      color: #71301e;
+    }
+    button:focus-visible, [tabindex="0"]:focus-visible {
+      outline: 3px solid #d79078;
+      outline-offset: 2px;
+    }
+    .legend { display: flex; flex-wrap: wrap; gap: 15px; color: var(--muted); }
+    .legend-item { display: inline-flex; align-items: center; gap: 7px; }
+    .legend-line { width: 34px; border-top: 2px solid var(--line); }
+    .legend-line.dashed { border-top-style: dashed; }
+    .legend-line.dotted { border-top-style: dotted; }
+    main {
+      display: grid;
+      grid-template-columns: minmax(0, 1fr) 350px;
+      gap: 16px;
+      padding: 0 18px 24px;
+      align-items: start;
+    }
+    .map-scroll {
+      overflow-x: auto;
+      border: 1px solid #d7d9da;
+      border-radius: 10px;
+      background: var(--panel);
+    }
+    svg { display: block; width: 100%; min-width: 980px; height: auto; }
+    .layer-title { font-size: 15px; font-weight: 700; text-anchor: middle; }
+    .layer-caption { font-size: 11px; fill: var(--muted); text-anchor: middle; }
+    .zone-caption { font-size: 12px; fill: var(--muted); }
+    .column-guide { stroke: #eef0f1; stroke-width: 1; }
+    .edge-line {
+      fill: none;
+      stroke: var(--line);
+      stroke-width: 1.8;
+      marker-end: url(#arrowhead);
+      transition: opacity .15s, stroke .15s, stroke-width .15s;
+    }
+    .edge-line.dashed { stroke-dasharray: 8 6; }
+    .edge-line.dotted { stroke-dasharray: 2 6; stroke-linecap: round; }
+    .edge-hit { fill: none; stroke: transparent; stroke-width: 14; cursor: pointer; }
+    .node { cursor: pointer; transition: opacity .15s; }
+    .node rect {
+      fill: #f1f2f2;
+      stroke: #858b90;
+      stroke-width: 1.2;
+      rx: 7;
+      transition: fill .15s, stroke .15s, stroke-width .15s;
+    }
+    .node text {
+      fill: var(--ink);
+      font: 12px ui-monospace, SFMono-Regular, Consolas, monospace;
+      text-anchor: middle;
+      pointer-events: none;
+    }
+    .node .stream-mark { fill: var(--muted); font: 10px system-ui, sans-serif; }
+    .is-filtered, .is-context-dim { opacity: .16; }
+    .is-path:not(.is-filtered), .is-hover:not(.is-filtered) { opacity: 1; }
+    .is-path .edge-line, .edge.is-path .edge-line {
+      stroke: var(--accent); stroke-width: 2.8; marker-end: url(#arrowhead-active);
+    }
+    .node.is-path rect { fill: var(--accent-soft); stroke: var(--accent); stroke-width: 2; }
+    .node.is-hover rect { fill: #faefeb; stroke: #d79078; }
+    .edge.is-hover .edge-line { stroke: #d79078; stroke-width: 2.2; }
+    .node.is-selected rect { stroke-width: 3; }
+    .edge.is-selected .edge-line { stroke-width: 4; }
+    aside {
+      min-height: 470px;
+      padding: 20px;
+      border: 1px solid #d7d9da;
+      border-radius: 10px;
+      background: var(--panel);
+    }
+    @media (max-width: 1530px) { main { grid-template-columns: minmax(0, 1fr); } aside { min-height: 0; } }
+    aside h2 { margin: 0 0 3px; font-size: 20px; overflow-wrap: anywhere; }
+    .meta { margin: 0 0 18px; color: var(--muted); }
+    .card-section { margin-top: 17px; }
+    .card-section h3 { margin: 0 0 5px; font-size: 13px; }
+    .card-section p { margin: 0; }
+    .card-section ul { margin: 5px 0 0; padding-left: 20px; }
+    .card-section li + li { margin-top: 5px; }
+    code { font: .92em ui-monospace, SFMono-Regular, Consolas, monospace; }
+    a { color: #8a351e; text-underline-offset: 2px; }
+    .hint { color: var(--muted); font-size: 13px; }
+  </style>
+</head>
+<body>
+  <header>
+    <h1 id="page-title"></h1>
+    <p class="lead" id="lead"></p>
+  </header>
+  <div class="controls">
+    <div class="switcher" id="switcher" aria-label="Выбор потока"></div>
+    <div class="legend" id="legend" aria-label="Механизмы переноса"></div>
+  </div>
+  <main>
+    <div class="map-scroll">
+      <svg id="map" viewBox="0 0 1230 470" role="group" aria-label="Путь данных через слои хранилища"></svg>
+    </div>
+    <aside id="details" aria-live="polite"></aside>
+  </main>
+  <script>
+    const MAP = /*__MAP_DATA__*/;
+    const NS = "http://www.w3.org/2000/svg";
+    const state = { stream: "all", selected: null, hovered: null };
+    const nodeById = new Map(MAP.nodes.map((node) => [node.id, node]));
+    const mechanismById = new Map(MAP.mechanisms.map((item) => [item.id, item]));
+    const positions = new Map();
+    const svg = document.getElementById("map");
+    const details = document.getElementById("details");
+    function svgElement(name, attributes = {}) {
+      const element = document.createElementNS(NS, name);
+      Object.entries(attributes).forEach(([key, value]) => element.setAttribute(key, value));
+      return element;
+    }
+    function layerTitle(layerId) { return MAP.layers.find((layer) => layer.id === layerId)?.title ?? MAP.dictionary.title; }
+
+    function appendRichText(parent, value) {
+      value.split("`").forEach((part, index) => {
+        const element = index % 2 ? document.createElement("code") : document.createTextNode(part);
+        if (index % 2) element.textContent = part;
+        parent.append(element);
+      });
+    }
+    function addSection(title, value) {
+      if (!value || (Array.isArray(value) && !value.length)) return;
+      const section = document.createElement("section");
+      section.className = "card-section";
+      const heading = document.createElement("h3");
+      heading.textContent = title;
+      section.append(heading);
+      if (Array.isArray(value)) {
+        const list = document.createElement("ul");
+        value.forEach((item) => {
+          const row = document.createElement("li");
+          appendRichText(row, item);
+          list.append(row);
+        });
+        section.append(list);
+      } else {
+        const paragraph = document.createElement("p");
+        appendRichText(paragraph, value);
+        section.append(paragraph);
+      }
+      details.append(section);
+    }
+    function addLinks(links) {
+      if (!links?.length) return;
+      const section = document.createElement("section");
+      section.className = "card-section";
+      const heading = document.createElement("h3");
+      heading.textContent = "Ссылки";
+      const list = document.createElement("ul");
+      links.forEach((item) => {
+        const row = document.createElement("li");
+        const link = document.createElement("a");
+        link.href = item.url;
+        link.target = "_blank";
+        link.rel = "noopener noreferrer";
+        link.textContent = item.label;
+        row.append(link);
+        list.append(row);
+      });
+      section.append(heading, list);
+      details.append(section);
+    }
+    function renderIntro() {
+      details.replaceChildren();
+      const heading = document.createElement("h2");
+      heading.textContent = "Как пользоваться картой";
+      details.append(heading);
+      MAP.intro.forEach((line) => {
+        const paragraph = document.createElement("p");
+        paragraph.textContent = line;
+        details.append(paragraph);
+      });
+      const paragraph = document.createElement("p");
+      const link = document.createElement("a");
+      link.href = MAP.chapter_url;
+      link.target = "_blank";
+      link.rel = "noopener noreferrer";
+      link.textContent = "Открыть главу «Хранилище и его слои»";
+      paragraph.append(link);
+      details.append(paragraph);
+      const hint = document.createElement("p");
+      hint.className = "hint";
+      hint.textContent = "Повторный щелчок или Esc снимает выделение.";
+      details.append(hint);
+    }
+    function renderNodeCard(node) {
+      details.replaceChildren();
+      const heading = document.createElement("h2");
+      heading.textContent = node.name;
+      const meta = document.createElement("p");
+      meta.className = "meta";
+      meta.textContent = `${layerTitle(node.layer)} — ${node.streams.map((id) => MAP.streams[id]).join(", ")}`;
+      details.append(heading, meta);
+      addSection("Что это", node.what);
+      addSection("Как читать", node.read);
+      addSection("Из чего состоит", node.parts);
+      addSection("Ключи", node.keys);
+      addSection("Кто наполняет и как часто", node.fill);
+      addLinks(node.links);
+    }
+    function renderEdgeCard(edge) {
+      details.replaceChildren();
+      const heading = document.createElement("h2");
+      heading.textContent = `${nodeById.get(edge.from).name} → ${nodeById.get(edge.to).name}`;
+      details.append(heading);
+      addSection("Механизм", mechanismById.get(edge.mechanism).label);
+      addSection("Ритм", edge.rhythm);
+      addSection("Кто именно", edge.actor);
+      addSection("Как соединяет", edge.join);
+      addLinks(edge.links);
+    }
+    function layoutMap() {
+      const nodeWidth = 180;
+      const nodeHeight = 48;
+      const columnStep = 250;
+      MAP.layers.forEach((layer, index) => {
+        const x = 20 + index * columnStep;
+        MAP.nodes.filter((node) => node.layer === layer.id).forEach((node) => {
+          positions.set(node.id, { x, y: 88 + node.order * 70, width: nodeWidth, height: nodeHeight });
+        });
+      });
+      const dicX = 20 + ((MAP.layers.findIndex((layer) => layer.id === "dds") + MAP.layers.findIndex((layer) => layer.id === "dm")) * columnStep) / 2 + nodeWidth / 2 - 130;
+      MAP.nodes.filter((node) => node.layer === "dic").forEach((node) => positions.set(node.id, { x: dicX, y: 402 + node.order * 70, width: 260, height: nodeHeight }));
+    }
+    function edgePath(edge, sameColumnIndex) {
+      const source = positions.get(edge.from);
+      const target = positions.get(edge.to);
+      if (nodeById.get(edge.from).layer === "dic") {
+        const x1 = source.x + source.width / 2;
+        const y1 = source.y;
+        const x2 = target.x;
+        const y2 = target.y + target.height / 2;
+        return `M ${x1} ${y1} C ${x1} ${y1 - 38}, ${x1} ${y2 + 48}, ${x2} ${y2}`;
+      }
+      const x1 = source.x + source.width;
+      const y1 = source.y + source.height / 2;
+      if (source.x === target.x) {
+        const route = source.x + source.width + 16 + sameColumnIndex * 18;
+        const y2 = target.y + target.height / 2;
+        return `M ${x1} ${y1} C ${route} ${y1}, ${route} ${y2}, ${x1} ${y2}`;
+      }
+      const x2 = target.x;
+      const y2 = target.y + target.height / 2;
+      const bend = Math.max(18, (x2 - x1) / 2);
+      return `M ${x1} ${y1} C ${x1 + bend} ${y1}, ${x2 - bend} ${y2}, ${x2} ${y2}`;
+    }
+
+    function drawMap() {
+      const defs = svgElement("defs");
+      [["arrowhead", "#8c9298"], ["arrowhead-active", "#b54a2a"]].forEach(([id, fill]) => {
+        const marker = svgElement("marker", { id, viewBox: "0 0 8 8", refX: "7", refY: "4", markerWidth: "6", markerHeight: "6", orient: "auto" });
+        marker.append(svgElement("path", { d: "M 0 0 L 8 4 L 0 8 z", fill }));
+        defs.append(marker);
+      });
+      svg.append(defs);
+      MAP.layers.forEach((layer, index) => {
+        const center = 110 + index * 250;
+        svg.append(svgElement("line", { x1: center, y1: 65, x2: center, y2: 377, class: "column-guide" }));
+        const title = svgElement("text", { x: center, y: 28, class: "layer-title" });
+        title.textContent = layer.title;
+        const caption = svgElement("text", { x: center, y: 47, class: "layer-caption" });
+        caption.textContent = layer.caption;
+        svg.append(title, caption);
+      });
+      const dictionaryPosition = positions.get(MAP.nodes.find((node) => node.layer === "dic").id);
+      const zone = svgElement("text", { x: dictionaryPosition.x, y: dictionaryPosition.y - 13, class: "zone-caption" });
+      zone.textContent = MAP.dictionary.caption;
+      svg.append(zone);
+      let sameIndex = 0;
+      MAP.edges.forEach((edge) => {
+        const same = positions.get(edge.from).x === positions.get(edge.to).x;
+        const index = same ? sameIndex++ : 0;
+        const group = svgElement("g", { class: "edge", "data-id": edge.id, tabindex: "0", role: "button", "aria-label": `${nodeById.get(edge.from).name} — ${nodeById.get(edge.to).name}` });
+        const path = edgePath(edge, index);
+        const lineClass = `edge-line ${mechanismById.get(edge.mechanism).line}`;
+        group.append(svgElement("path", { d: path, class: lineClass }), svgElement("path", { d: path, class: "edge-hit" }));
+        bindSelection(group, "edge", edge.id);
+        svg.append(group);
+      });
+      MAP.nodes.forEach((node) => {
+        const position = positions.get(node.id);
+        const group = svgElement("g", { class: "node", "data-id": node.id, tabindex: "0", role: "button", "aria-label": node.name });
+        group.append(svgElement("rect", position));
+        const name = svgElement("text", { x: position.x + position.width / 2, y: position.y + 21 });
+        name.textContent = node.name;
+        const mark = svgElement("text", { x: position.x + position.width / 2, y: position.y + 38, class: "stream-mark" });
+        mark.textContent = node.streams.map((id) => MAP.streams[id]).join(" + ");
+        group.append(name, mark);
+        group.addEventListener("mouseenter", () => { state.hovered = node.id; updateHighlights(); });
+        group.addEventListener("mouseleave", () => { state.hovered = null; updateHighlights(); });
+        bindSelection(group, "node", node.id);
+        svg.append(group);
+      });
+    }
+    function bindSelection(element, type, id) {
+      const choose = () => selectItem(type, id);
+      element.addEventListener("click", choose);
+      element.addEventListener("keydown", (event) => {
+        if (event.key === "Enter" || event.key === " ") { event.preventDefault(); choose(); }
+      });
+    }
+    function findReachability(nodeId) {
+      const nodes = new Set([nodeId]);
+      const edges = new Set();
+      const walk = (start, direction) => {
+        const queue = [start];
+        while (queue.length) {
+          const current = queue.shift();
+          MAP.edges.forEach((edge) => {
+            const matches = direction === "out" ? edge.from === current : edge.to === current;
+            if (!matches) return;
+            edges.add(edge.id);
+            const next = direction === "out" ? edge.to : edge.from;
+            if (!nodes.has(next)) { nodes.add(next); queue.push(next); }
+          });
+        }
+      };
+      walk(nodeId, "in");
+      walk(nodeId, "out");
+      return { nodes, edges };
+    }
+
+    function selectItem(type, id) {
+      const repeated = state.selected?.type === type && state.selected.id === id;
+      state.selected = repeated ? null : { type, id };
+      if (!state.selected) renderIntro();
+      else if (type === "node") renderNodeCard(nodeById.get(id));
+      else renderEdgeCard(MAP.edges.find((edge) => edge.id === id));
+      updateHighlights();
+    }
+
+    function updateHighlights() {
+      let activeNodes = new Set();
+      let activeEdges = new Set();
+      if (state.selected?.type === "node") ({ nodes: activeNodes, edges: activeEdges } = findReachability(state.selected.id));
+      if (state.selected?.type === "edge") {
+        const edge = MAP.edges.find((item) => item.id === state.selected.id);
+        activeNodes = new Set([edge.from, edge.to]);
+        activeEdges = new Set([edge.id]);
+      }
+      const hoverNodes = new Set(state.hovered ? [state.hovered] : []);
+      const hoverEdges = new Set();
+      if (state.hovered) MAP.edges.forEach((edge) => {
+        if (edge.from === state.hovered || edge.to === state.hovered) {
+          hoverEdges.add(edge.id); hoverNodes.add(edge.from); hoverNodes.add(edge.to);
+        }
+      });
+      document.querySelectorAll(".node").forEach((element) => {
+        const node = nodeById.get(element.dataset.id);
+        element.classList.toggle("is-filtered", state.stream !== "all" && !node.streams.includes(state.stream));
+        element.classList.toggle("is-context-dim", Boolean(state.selected) && !activeNodes.has(node.id));
+        element.classList.toggle("is-path", activeNodes.has(node.id));
+        element.classList.toggle("is-hover", hoverNodes.has(node.id));
+        element.classList.toggle("is-selected", state.selected?.type === "node" && state.selected.id === node.id);
+      });
+      document.querySelectorAll(".edge").forEach((element) => {
+        const edge = MAP.edges.find((item) => item.id === element.dataset.id);
+        element.classList.toggle("is-filtered", state.stream !== "all" && !edge.streams.includes(state.stream));
+        element.classList.toggle("is-context-dim", Boolean(state.selected) && !activeEdges.has(edge.id));
+        element.classList.toggle("is-path", activeEdges.has(edge.id));
+        element.classList.toggle("is-hover", hoverEdges.has(edge.id));
+        element.classList.toggle("is-selected", state.selected?.type === "edge" && state.selected.id === edge.id);
+      });
+    }
+
+    function renderControls() {
+      const switcher = document.getElementById("switcher");
+      Object.entries(MAP.streams).forEach(([id, label]) => {
+        const button = document.createElement("button");
+        button.type = "button";
+        button.textContent = label;
+        button.setAttribute("aria-pressed", String(id === state.stream));
+        button.addEventListener("click", () => {
+          state.stream = id;
+          switcher.querySelectorAll("button").forEach((item) => item.setAttribute("aria-pressed", String(item === button)));
+          updateHighlights();
+        });
+        switcher.append(button);
+      });
+      const legend = document.getElementById("legend");
+      MAP.mechanisms.forEach((item) => {
+        const row = document.createElement("span");
+        row.className = "legend-item";
+        const line = document.createElement("span");
+        line.className = `legend-line ${item.line}`;
+        const label = document.createElement("span");
+        appendRichText(label, `${item.label} — ${item.rhythm}`);
+        row.append(line, label);
+        legend.append(row);
+      });
+    }
+
+    document.getElementById("page-title").textContent = MAP.title;
+    document.getElementById("lead").textContent = MAP.lead;
+    layoutMap();
+    drawMap();
+    renderControls();
+    renderIntro();
+    document.addEventListener("keydown", (event) => {
+      if (event.key === "Escape" && state.selected) selectItem(state.selected.type, state.selected.id);
+    });
+  </script>
+</body>
+</html>

docs/handbook/generator.md

@@ -0,0 +1,62 @@
+# Генератор: откуда берутся данные
+
+Генератор изображает две системы интернет-магазина. Первая — счетчик на сайте,
+он шлет события в топик `hits`. Вторая — бэкенд магазина, он раз в модельные
+сутки выгружает слепок заказов в топик `orders`.
+
+## Что он производит
+
+Событие — широкая строка по образцу выгрузки Яндекс Метрики. Генератор создает
+три вида событий: просмотр страницы, корзину и покупку. Все колонки перечислены
+в [описании выгрузки](../formats/clickstream-event.md).
+
+Заказ — та же покупка, но записанная бэкендом магазина, с суммами в деньгах.
+Семь модельных дней после оформления заказ еще может измениться, поэтому каждый
+дневной слепок несет заказы за последние семь дней в их текущем состоянии.
+Устройство и форма слепка разобраны в [отдельном
+справочнике](../architecture/orders/snapshot.md).
+
+## Почему данные всегда одни и те же
+
+Генератор не берет случайность извне. Все его случайные решения выводятся из
+[зерна](../architecture/generator/seeds.md) — одного числа в настройках — и из
+номера дня. То же зерно и тот же номер дня дают ровно те же события, поэтому
+стартовый мир одинаков при каждом `make up`.
+
+Рядом лежит паспорт мира, `data/world-inventory.json`: зерно, версия генератора
+и по строке на каждый день с числом событий и контрольной суммой. По нему
+проверяют, что генератор собрал тот же мир, что и раньше, и что в ODS все
+доехало без потерь. Паспорт описывает только восемь дней стартового мира.
+
+## Кто его запускает
+
+На стенде генератором управляют [даги модельного
+времени](airflow-dags.md#даги-мира). Его можно запустить и напрямую. Команды
+собраны в [справочнике мира](../architecture/world.md#как-запустить-генератор).
+
+У генератора два режима. Пакетный отправляет весь день разом. Живой шлет
+события по ходу модельных суток; сутки идут ускоренно и занимают около двадцати
+четырех минут.
+
+## Посмотрите сами
+
+Подключитесь из DBeaver по [инструкции](../../README.md#подключиться-из-dbeaver)
+и выполните запрос:
+
+```sql
+SELECT EventDate, count() AS events
+FROM ods.event_v
+GROUP BY EventDate
+ORDER BY EventDate;
+```
+
+Сравните первые восемь дней с восемью строками в [паспорте
+мира](../../data/world-inventory.json): числа совпадут. Дни, сыгранные после
+стартового мира, в паспорте не записаны. Так и задумано.
+
+## Куда дальше
+
+Подробнее генератор разобран в [README папки
+`generator/`](../../generator/README.md) и в [справочнике его
+устройства](../architecture/generator/README.md). На этом путеводитель
+заканчивается: дальше справочники и [учебные задания](../labs/README.md).

docs/handbook/monitoring.md

@@ -0,0 +1,71 @@
+# Мониторинг: куда смотреть
+
+В Grafana три дашборда, и у каждого своя тема. «Данные» показывает, все ли в
+порядке с потоком данных. «Кластер» — состояние машин и самого ClickHouse.
+«Запросы» — какие запросы выполнялись и сколько ресурсов они заняли.
+
+Prometheus собирает метрики с двух узлов ClickHouse, keeper и экспортера Kafka.
+Grafana читает и Prometheus, и ClickHouse напрямую. На панелях нет порогов и
+цветовой подсветки: оценивать картинку придется самому. Автоматические
+проверки, которые выносят вердикт, собраны в контуре DQ.
+
+## Дашборд «Данные»
+
+«Свежесть» показывает, сколько времени прошло с последнего события и с
+последнего заказа в ODS. Свежесть заказов растет весь модельный день и
+сбрасывается, когда на границе суток приходит слепок. Это нормальное поведение
+источника, а не поломка.
+
+«Поток» показывает число сырых сообщений в STG за выбранный интервал. «Брак»
+рядом — доля строк, которые не удалось разобрать.
+
+«Сходимость» сравнивает число событий в Kafka и в ClickHouse. Тревожный
+признак — устойчивый разрыв между линиями. Расхождение в одном столбце ничего
+не значит.
+
+«Отставание» показывает, сколько сообщений в Kafka еще не прочитано
+потребителями. «Дневной слепок» перечисляет последние десять слепков заказов в
+STG: по нему видно, пришла ли выгрузка вовремя.
+
+Источники и правила чтения всех панелей разобраны в [справочнике дашборда
+«Данные»](../architecture/monitoring/data.md).
+
+## Почему у панелей разные источники
+
+Свежесть считается по ODS: если разбор остановился, это видно именно там. Поток
+и брак считаются по STG, где сохраняется каждое доставленное сообщение. В ODS
+повторы события и старые версии заказа схлопываются, поэтому счетчик там был бы
+занижен. Подробности — в [разделе о слоях
+панелей](../architecture/monitoring/data.md#почему-слои-у-панелей-разные).
+
+## Два других дашборда
+
+Открывайте «Кластер», когда нужно понять, что происходит с процессором, памятью
+и дисками, с кусками данных и их слияниями в ClickHouse, с keeper или очередью
+DDL. Устройство панелей описано в [справочнике дашборда
+«Кластер»](../architecture/monitoring/cluster.md).
+
+«Запросы» пригодится, когда вы ищете тяжелые запросы, ошибки или расход
+ресурсов по пользователям. Как читать списки, объясняет [справочник дашборда
+«Запросы»](../architecture/monitoring/queries.md).
+
+## Посмотрите сами
+
+Откройте Grafana по адресу из раздела [«Адреса и
+пароли»](../../README.md#адреса-и-пароли), затем дашборд «Данные». Запустите в
+Airflow [`world_live_day`](airflow-dags.md#даги-мира): модельный день займет
+около двадцати четырех минут.
+
+Смотрите свежесть событий и свежесть заказов по отдельности. Пока день идет,
+свежесть событий держится на секундах, а свежесть заказов растет. На границе дня
+слепок отправляется сразу: свежесть заказов сбрасывается, а свежесть событий
+начинает расти, потому что новых событий до следующего дня не будет. Сам даг
+остается в работе и после конца дня, потому что ждет дневной конвейер.
+
+## Куда дальше
+
+Состав мониторинга собран в [справочнике
+зоны](../architecture/monitoring/README.md), детали главного экрана — в
+[справочнике дашборда «Данные»](../architecture/monitoring/data.md), а границы
+решения — в [ADR 0002](../adr/0002-monitoring-scope.md). Следующая глава —
+[«Немного Superset»](superset.md).

docs/handbook/storage-layers.md

@@ -0,0 +1,166 @@
+# Хранилище и его слои
+
+В хранилище приходят два потока из Kafka: в топике `hits` — события
+кликстрима, в `orders` — заказы магазина. Оба проходят один путь: STG → ODS →
+DDS → DM. Каждый слой отвечает на свой вопрос.
+
+```mermaid
+flowchart LR
+    Kafka --> STG --> ODS --> DDS --> DM
+```
+
+## Как читать имена
+
+Для обычного чтения выбирайте объекты с суффиксом `_v`. Это представления:
+их устройство может поменяться, а ваш запрос останется прежним. Суффиксы
+`_rep`, `_dist`, `_kafka` и `_mv` относятся к внутреннему
+устройству хранилища. Они нужны для загрузки, обслуживания и диагностики.
+У словарей есть исключение: у `dic.products` нет суффикса, потому что
+различать нечего — объект один.
+Подробный разбор имен есть в [справочнике
+хранилища](../architecture/storage.md#имена-объектов).
+
+## STG: как поступило
+
+STG — сырой слой. Он сохраняет сообщение целой строкой, без разбора. Рядом
+лежат метаданные доставки: топик, партиция, смещение и время приема. Поэтому в
+STG можно увидеть, что именно приехало из Kafka, даже если сообщение
+испорчено.
+
+Срок хранения — трое суток реального времени. Этого хватает для расследования
+и повторного разбора, но старые строки не занимают диск вечно. Точное правило
+— в [справочнике
+хранилища](../architecture/storage.md#срок-жизни-сырых-данных).
+
+## ODS: язык источника
+
+ODS — слой разобранных данных. Строка получает типы: дата становится датой,
+число — числом. Имена полей остаются на языке источника. Например, событие
+сохраняет колонки `WatchID`, `ClientID` и `EventDate`.
+
+Испорченное сообщение не останавливает загрузку. Оно попадает в таблицу
+`*_errors` вместе с сырой строкой и классом ошибки. Так брак остается виден, а
+годные строки продолжают движение.
+
+## DDS: язык бизнеса
+
+DDS — детальный слой на языке бизнеса. Здесь есть событие, заказ, сессия и
+карта идентичностей. Карта связывает посетителя, то есть куку `ClientID`, с
+пользователем магазина из заказа.
+
+В стенде визитом считают подряд идущие события одной куки без пауз
+дольше 30 минут. Визит не пересекает границу модельных суток.
+Аналитик называет такой визит сессией.
+
+В бою Метрика нарезает визиты сама и добавляет готовый `VisitID` в
+события. Стенд играет ее роль: считает сессии из событий заново, а `VisitID`
+оставляет эталоном для проверки. Иначе сборка сессий свелась бы к группировке
+по чужому полю, и учиться было бы не на чем. Идентификатор сессии
+`session_id` чеканит стенд: в событии его нет. Готовые сессии читайте через
+`dds.session_v`. В `dds.event_v` поля `VisitID` нет: так сессии можно собрать
+самому и сравнить с эталоном.
+
+## DM: данные для дашбордов
+
+DM — слой витрин. Витрина — готовый набор показателей для отчета или
+дашборда. Здесь уже посчитаны, например, дневная выручка по категориям и
+дневные показатели трафика.
+
+К каждой витрине можно обращаться коротким запросом, не повторяя в нем весь
+путь расчета. Состав готовых витрин смотрите в [карте
+таблиц](../architecture/storage.md#карта-таблиц).
+
+## Сбоку цепочки: зона `dic`
+
+Зона `dic` стоит вне пути STG → ODS → DDS → DM. В ней живут справочные данные,
+которые хранилище получает готовыми. Ни один слой их не производит, а читать
+может любой.
+
+Первый справочник стенда — каталог товаров `dic.products`. Его ключ `sku` —
+артикул товара. По нему можно узнать название, бренд и категорию товара. Как
+устроена зона, смотрите в [разделе о
+справочниках](../architecture/storage.md#справочники).
+
+## Сквозные ключи
+
+Один и тот же смысл проходит через слои под разными именами: имя меняется
+вместе с языком слоя. Таблица показывает исходное имя и то, где искать тот же
+смысл дальше.
+
+| Колонка | Что означает | Что соединяет |
+|---|---|---|
+| `WatchID` | Идентификатор события | Событие ODS с событием DDS, где колонка называется `event_id` |
+| `ClientID` | Посетитель, то есть кука | События ODS с событиями, сессиями и картой идентичностей DDS; в DDS колонка называется `client_id` |
+| `order_id` | Идентификатор заказа | Заказ ODS с заказом DDS и витриной сверки `dm.purchase_vs_orders_v` |
+| `sku` | Артикул товара в каталоге | Справочник `dic.products` с позициями заказа DDS, где артикулы лежат в `item_sku`; через категорию товара — с витриной выручки DM |
+| `EventDate` | День на [оси модельного времени](../../CONTEXT.md), который счетчик сайта проставляет в [своем часовом поясе](../architecture/storage.md#часовые-пояса) | Событие ODS с событием DDS, где колонка называется `event_date`, и дневными расчетами DM |
+
+Что здесь значит «посетитель» и чем кука отличается от человека, объясняет
+[словарь понятий](../../CONTEXT.md#язык). Точные имена объектов и полей сверяйте с
+[картой таблиц](../architecture/storage.md#карта-таблиц).
+
+## Посмотрите сами
+
+Подключитесь к ClickHouse по инструкции из разделов [«Адреса и
+пароли»](../../README.md#адреса-и-пароли) и [«Подключиться из
+DBeaver»](../../README.md#подключиться-из-dbeaver). Во всех трех примерах
+`2026-06-01` — это D0, первый день [стартового
+мира](../../CONTEXT.md). Чтобы посмотреть другой день, замените
+эту дату в условии. Первый запрос покажет
+события одного модельного дня:
+
+```sql
+SELECT
+    WatchID,
+    ClientID,
+    EventDate,
+    EventType,
+    URL
+FROM ods.event_v
+WHERE EventDate = '2026-06-01'
+ORDER BY UTCEventTime
+LIMIT 20;
+```
+
+Второй запрос покажет сессии того же дня. Они рассчитаны из событий
+первого запроса:
+
+```sql
+SELECT
+    client_id,
+    started_at,
+    finished_at,
+    events_total,
+    pageviews,
+    purchases,
+    entry_url
+FROM dds.session_v
+WHERE session_date = '2026-06-01'
+ORDER BY events_total DESC
+LIMIT 20;
+```
+
+Третий запрос покажет готовую выручку по категориям за тот же день:
+
+```sql
+SELECT
+    product_category,
+    orders,
+    units,
+    revenue
+FROM dm.revenue_daily_v
+WHERE report_date = '2026-06-01'
+ORDER BY revenue DESC;
+```
+
+Все три запроса читают поверхности `_v`. Первый показывает данные на языке
+источника, второй — расчетную сущность, третий — готовый ответ витрины.
+
+## Куда дальше
+
+Откройте [интерактивную карту](architecture-map.html) из своей копии
+репозитория и проследите путь данных.
+Список объектов, сроки хранения и устройство таблиц — в [справочнике
+хранилища](../architecture/storage.md). Как данные переносят между слоями — в
+следующей главе: [потоки Airflow и даги модельного
+времени](airflow-dags.md).

docs/handbook/superset.md

@@ -0,0 +1,62 @@
+# Немного Superset
+
+Superset показывает витрины слоя DM в виде графиков. К ClickHouse он
+подключается пользователем `bi`. На дашборде стенда «Бизнес-сюжеты» три
+графика:
+
+| График | Витрина |
+|---|---|
+| «Выручка по дням и категориям» | `dm.revenue_daily_v` |
+| «Сверка purchase и заказов» | `dm.purchase_vs_orders_v` |
+| «Посетители и известные пользователи» | `dm.daily_traffic_v` |
+
+## Как витрина становится графиком
+
+От витрины до экрана три объекта Superset: датасет → график → дашборд. Датасет
+описывает витрину: задает русские имена колонок и формат денег. График
+ссылается на эти имена и задает способ показа. Дашборд собирает готовые графики
+на одном экране.
+
+## Стендовые объекты и ваши
+
+Датасеты, графики и дашборд из поставки стенда лежат файлами в репозитории и
+заново импортируются при каждом `make up`. Если поправить такой объект в
+интерфейсе, правка проживет до следующего `make up`, а потом без предупреждения
+заменится версией из файла.
+
+Ваши собственные объекты хранятся в той же базе метаданных Superset, но импорт
+их не трогает: они переживают и `make up`, и `make rebuild-storage`. Стирает их
+только `make clean` вместе с остальным постоянным состоянием стенда. Поэтому
+стендовые объекты оставляйте как есть, а свои отчеты стройте рядом. Устройство
+импорта описано в [справочнике
+Superset](../architecture/superset.md#импорт-при-каждой-инициализации).
+
+## Почему края графиков не совпадают
+
+Правый край графика выручки всегда на день позади графиков кликстрима. Слепок
+заказов за день приходит только со следующим модельным днем. Так устроен
+источник, а не витрина. Вы уже видели этот
+сдвиг в [главе об Airflow](airflow-dags.md#посмотрите-сами). Начальное состояние
+показано в разделе [«Стартовый мир»](../architecture/world.md#стартовый-мир).
+
+## Посмотрите сами
+
+Откройте Superset по адресу из раздела [«Адреса и
+пароли»](../../README.md#адреса-и-пароли) и выберите дашборд «Бизнес-сюжеты».
+Затем откройте SQL Lab и выполните запрос:
+
+```sql
+SELECT report_date, visitors, known_users
+FROM dm.daily_traffic_v
+ORDER BY report_date DESC
+LIMIT 7;
+```
+
+Как построить свой отчет, рассказывают [учебные задания](../labs/README.md).
+
+## Куда дальше
+
+Устройство BI-зоны описано в [справочнике
+Superset](../architecture/superset.md), а состав витрин — в [справочнике
+DM](../architecture/dm.md). Следующая глава — [«Генератор: откуда берутся
+данные»](generator.md).

docs/labs/1-1-events-enriched.md

@@ -0,0 +1,93 @@
+# Задание 1: `dm.events_enriched_v`
+
+**Чему учит:** строить слой как договор о данных, а не как их копию.
+Оставлять витрину представлением, если зерно источника не меняется.
+
+## Сначала прочитать
+
+- [«Хранилище и его слои»](../handbook/storage-layers.md).
+
+## Роль витрины
+
+В `dds.event_v` 44 колонки, включая технические поля источника и массивы
+товаров. Для анализа событий в Superset нужны деловые поля и три готовых
+значения: час события, путь страницы и домен перехода. Тогда вам не придется
+повторять эти выражения в каждом запросе.
+
+Витрины следующих заданий читают DDS напрямую. Использовать
+`dm.events_enriched_v` как источник для них не нужно: задания независимы, их
+можно выполнять в любом порядке.
+
+## Что сделать
+
+Создайте обычное представление `CREATE VIEW dm.events_enriched_v`.
+Единственный источник — `dds.event_v`. Зерно — **событие**: каждой строке
+источника соответствует одна строка витрины.
+
+Физическая таблица, таблица-донор и задача в `dm_transform` не нужны.
+Представление не хранит строки, поэтому ключ шардирования и пересборка ему
+не требуются.
+
+Укажите колонки явно. Иначе новая колонка источника попадет в витрину
+автоматически, и договор с потребителем изменится без вашего участия.
+
+| Группа | Колонки |
+|---|---|
+| Время и посетитель | `event_date`, `event_time`, `event_hour`, `client_id`, `event_id` |
+| Действие | `event_type` (`pageview`, `add_to_cart`, `purchase`), `url`, `page_path`, `referer`, `referer_host`, `title` |
+| UTM-метки | `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`, `utm_term` |
+| Устройство и регион | `device_category`, `browser`, `operating_system`, `region_country`, `region_city` |
+| Товары и покупка | `product_id`, `product_name`, `product_category`, `product_price`, `product_quantity`, `product_event_type`, `purchase_id`, `purchase_revenue`, `purchase_coupon` |
+
+Три колонки вычислите в представлении. Остальные возьмите из источника без
+изменений, сохранив массивы `product_*`.
+
+| Колонка | Как считается | Для чего нужна |
+|---|---|---|
+| `event_hour` | `toHour(event_time)` | Анализ событий по часам суток |
+| `page_path` | путь `url` без домена и параметров | Группировка по странице |
+| `referer_host` | домен `referer` | Анализ источников перехода |
+
+Не добавляйте `_load_id` и `_load_ts`. Их нет и у `dds.event_v`: события в
+DDS читают из ODS без отдельной загрузки. Эти служебные поля указывают на
+запуск, который записал строку на диск. Представление ничего не загружает.
+
+## Типичная ошибка
+
+Не разворачивайте массивы товаров через `ARRAY JOIN`. У события с тремя
+позициями получится три строки. Зерно изменится. Витрину с новым зерном на
+стенде хранят готовым агрегатом — причины описаны в разделе [«Как принято на
+ступени 1»](README.md#как-принято-на-ступени-1).
+
+Главная опасность — потеря событий с пустым массивом товаров: `ARRAY JOIN`
+исключает их из результата. Товары есть только в событиях корзины и покупки.
+Поэтому исчезнет большинство событий — девятнадцать строк из двадцати.
+Запрос выполнится без ошибки, а витрина по имени и составу колонок
+по-прежнему будет выглядеть таблицей событий.
+
+Сохраните массивы как в источнике. Для анализа отдельных товарных позиций
+нужна другая витрина с другим зерном и именем.
+
+## Как проверить себя
+
+Деловой ключ — `event_id` внутри дня. Получите результат прямо из
+`dds.event_v` за тот же день. Соедините его с витриной полным внешним
+соединением по `event_id`. Посчитайте строки, где ключ отсутствует с одной
+из сторон или различаются значения деловых колонок. Расхождений должно быть
+ноль.
+
+Отдельно сверьте `event_hour`, `page_path` и `referer_host` с теми же
+выражениями, рассчитанными прямо по `dds.event_v`.
+
+Если строк в витрине в разы меньше, чем в источнике, и остались только
+события корзины и покупки, это признак развернутых массивов: `ARRAY JOIN`
+исключил все события с пустым массивом товаров.
+
+## Приемка
+
+- [ ] представление `dm.events_enriched_v` создано без физических таблиц;
+- [ ] список колонок в представлении задан явно;
+- [ ] число строк и набор `event_id` совпадают с `dds.event_v` за каждый
+      прожитый день;
+- [ ] задача `events_enriched` в `homework_check` завершилась успешно;
+- [ ] задачи для этой витрины в `dm_transform` нет.

docs/labs/1-2-top-pages-daily.md

@@ -0,0 +1,110 @@
+# Задание 2: `dm.top_pages_daily`
+
+**Чему учит:** создавать витрину с новым зерном: пять объектов, донор и
+замена дневных партиций. Включать ее пересборку в `dm_transform`.
+
+## Сначала прочитать
+
+- [«Хранилище и его слои»](../handbook/storage-layers.md);
+- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
+
+## Роль витрины
+
+По дневным показателям страниц аналитик сравнивает просмотры, посетителей и
+действия с товарами. Добавление в корзину происходит на карточке товара,
+покупка — на странице подтверждения заказа. Отношение добавлений к
+просмотрам карточки показывает ее конверсию.
+
+Для воронки «просмотр → корзина → покупка» этих данных недостаточно:
+действия происходят на разных страницах, а связи между ними в агрегате нет.
+Путь человека исследуют по событиям или сессиям.
+
+## Что сделать
+
+Источник — `dds.event_v`. Зерно витрины — **день события × страница**.
+Читайте DDS напрямую: так выполнение задания не зависит от витрины
+задания 1.
+
+На стенде витрину с новым зерном хранят как готовый агрегат, чтобы не
+рассчитывать ее заново для каждого запроса. Причины описаны в разделе
+[«Как принято на ступени 1»](README.md#как-принято-на-ступени-1). Создайте
+пять объектов:
+`dm.top_pages_daily_rep` / `_dist`, донор `_stage_rep` / `_stage_dist` и
+публичное представление `dm.top_pages_daily_v`. Ключ партиции — день, он же
+единица пересборки.
+
+### Состав колонок
+
+| Колонка | Тип | Значение |
+|---|---|---|
+| `report_date` | `Date` | День события |
+| `page_path` | `LowCardinality(String)` | Путь страницы |
+| `pageviews` | `UInt64` | Число событий `pageview` на странице |
+| `visitors` | `UInt64` | Число разных `client_id` на странице |
+| `cart_adds` | `UInt64` | Число событий `add_to_cart` на странице |
+| `purchases` | `UInt64` | Число событий `purchase` на странице |
+| `_load_id` | `String` | Идентификатор запуска, собравшего день |
+| `_load_ts` | `DateTime64(3, 'UTC')` | Время сборки |
+
+Вычислите `page_path` из `url`, убрав домен и параметры запроса. Полный
+адрес разделил бы показатели одной страницы на сотни строк. Учитывайте все
+три типа событий, а их счетчики вычисляйте через `countIf`.
+
+### Ритм пересборки
+
+События прожитого дня больше не меняются. Определяйте объем прогона по
+состоянию витрины: от первого несобранного прожитого дня до последнего
+прожитого. Отсчет от последнего собранного дня оставит пропуски после
+частичного сбоя.
+
+Как у `revenue_daily`, заполните донор за весь диапазон одной вставкой,
+затем замените дневные партиции по одной.
+
+### Ключ шардирования
+
+Выберите ключ самостоятельно. У `revenue_daily` кроме дня одно измерение с
+шестью близкими по объему значениями. Здесь страниц много, и число событий
+на них сильно различается.
+
+У цели и донора используйте одинаковый ключ: иначе при замене партиции
+строка потеряется на одном шарде и удвоится на другом. О том, [как устроен
+донор](../architecture/storage.md), читайте в разделе «Раскладка по шардам».
+
+## Типичная ошибка
+
+Из-за имени витрины хочется отобрать только просмотры. Но фильтр источника
+по `event_type = 'pageview'` обнулит `cart_adds` и `purchases`, а запрос не
+завершится ошибкой. Конверсия карточек станет нулевой. Проверка одной суммы
+`pageviews` не обнаружит этот фильтр: все просмотры остались на месте.
+Ошибку покажет сверка `purchases` или `cart_adds` с источником, если за день
+были покупки или добавления в корзину.
+
+Выбирайте проверку под возможную ошибку. Этот подход описан в
+[справочнике проверок](../architecture/testing.md).
+
+## Как проверить себя
+
+Деловой ключ — `page_path` внутри дня. Получите прямой агрегат из
+`dds.event_v` за день и соедините его с `dm.top_pages_daily_v` полным
+внешним соединением по ключу. Посчитайте строки, где ключ отсутствует с
+одной из сторон или различается любой из четырех счетчиков. Расхождений
+должно быть ноль.
+
+Перед полным сравнением проверьте дневные суммы:
+
+- сумма `pageviews` равна числу событий `pageview` в `dds.event_v`;
+- сумма `purchases` равна числу событий `purchase` в том же источнике.
+
+Сумма `visitors` по страницам повторно учитывает посетителя, открывшего
+несколько страниц. Число посетителей за день берите из `dm.daily_traffic_v`.
+
+## Приемка
+
+- [ ] созданы пять объектов, донор объявлен через `AS` и шардируется ключом
+      цели;
+- [ ] в `dm.top_pages_daily_v` явно перечислены колонки, включая `_load_id`
+      и `_load_ts`;
+- [ ] объем прогона определяется по состоянию витрины без ручного задания;
+- [ ] задача `top_pages_daily` в `homework_check` завершилась успешно;
+- [ ] задача витрины добавлена в `dm_transform`, повторный прогон конвейера
+      не меняет результат.

docs/labs/1-3-session-overview.md

@@ -0,0 +1,118 @@
+# Задание 3: `dm.session_overview`
+
+**Чему учит:** хранить слагаемые, а не готовые средние и доли. Понимать,
+почему сумма `visitors` по строкам сейчас сходится, но начнет завышать
+аудиторию, если у одной куки появятся визиты с двух устройств.
+
+## Сначала прочитать
+
+- [«Хранилище и его слои»](../handbook/storage-layers.md);
+- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
+
+## Роль витрины
+
+Витрина нужна, чтобы по дням сравнивать визиты с телефона и компьютера: их
+число, длительность, просмотры страниц и частоту покупок.
+
+На прошлом стенде витрина выделяла визиты сама. Теперь их рассчитывают в
+DDS, а повторять зерно сессий ради представления с переименованными
+колонками незачем. Здесь вы учитесь дневной агрегации, поэтому зерно — день
+и устройство. Выбор описан в разделе «Форма: по зерну, не по цене запроса»
+[справочника DM](../architecture/dm.md).
+
+## Что сделать
+
+Источник — `dds.session_v`. Зерно — **день сессии × категория устройства**.
+Зерно новое, поэтому витрина хранится готовым агрегатом — см. [«Как принято
+на ступени 1»](README.md#как-принято-на-ступени-1). Создайте пять объектов:
+`dm.session_overview_rep` / `_dist`, донор `_stage_rep` / `_stage_dist` и
+публичное представление `dm.session_overview_v`. Ключ партиции — день.
+
+### Состав колонок
+
+| Колонка | Тип | Значение |
+|---|---|---|
+| `report_date` | `Date` | День сессии |
+| `device_category` | `LowCardinality(String)` | Категория устройства |
+| `sessions` | `UInt64` | Число визитов |
+| `visitors` | `UInt64` | Число разных `client_id` |
+| `bounce_sessions` | `UInt64` | Визиты ровно из одного события |
+| `purchase_sessions` | `UInt64` | Визиты хотя бы с одной покупкой |
+| `duration_seconds_total` | `UInt64` | Суммарная длительность визитов |
+| `events_total` | `UInt64` | Число событий во всех визитах |
+| `pageviews` | `UInt64` | Число просмотров страниц |
+| `cart_adds` | `UInt64` | Число добавлений в корзину |
+| `purchases` | `UInt64` | Число покупок |
+| `_load_id` | `String` | Идентификатор запуска, собравшего день |
+| `_load_ts` | `DateTime64(3, 'UTC')` | Время сборки |
+
+Возьмите `device_category` из сессии: DDS уже заменил код словом. Из четырех
+категорий встречаются `desktop`, `mobile` и `tablet`. Строку для `tv`
+создавайте только при появлении таких визитов.
+
+Вместо `avg_duration_seconds` храните слагаемые. Среднее из средних по трем
+устройствам даст неверный ответ за день: число сессий в категориях
+различается, поэтому средние нужно взвешивать. Потребитель делит сумму
+`duration_seconds_total` на сумму `sessions`. Долю отказов считают так же:
+сумму `bounce_sessions` делят на сумму `sessions`, а не усредняют готовые
+доли.
+
+### Ритм пересборки
+
+Сессии прожитого дня больше не меняются. Как в задании 2, определяйте
+диапазон от первого несобранного прожитого дня до последнего прожитого.
+Соберите его в донор и замените дневные партиции. Добавьте задачу в
+`dm_transform`.
+
+### Ключ шардирования
+
+Выберите ключ самостоятельно. Визитов с планшета мало, с телефонов и
+компьютеров — значительно больше. Если хотите взять хеш только от
+`device_category`, сначала посчитайте строки на каждом шарде. Затем
+объясните, почему такое распределение вас устраивает.
+
+Ключ донора — тот же, что у цели (см. [«Как принято на ступени
+1»](README.md#как-принято-на-ступени-1) и раздел «Раскладка по шардам»
+[справочника хранилища](../architecture/storage.md)).
+
+## Почему сумма `visitors` сходится с `dm.daily_traffic_v`
+
+Сравните сумму `visitors` по устройствам за день с `dm.daily_traffic_v`. На
+стенде значения совпадут: устройство приписано куке на всю жизнь, поэтому за
+день она учитывается только в одной строке. Это свойство мира стенда; см.
+раздел «Паспорт куки» в [словаре понятий](../../CONTEXT.md).
+
+Если появятся визиты одной куки с двух устройств, сумма начнет завышать
+аудиторию. Проверки счетчиков по категориям этого не обнаружат. Число
+посетителей дня берите из `dm.daily_traffic_v`, где оно рассчитано для дня
+целиком.
+
+## Типичная ошибка
+
+Повторное выделение визитов из событий может дать другие границы сессий, чем
+в DDS. Используйте готовые сессии из `dds.session_v`. Если общее число
+событий совпало с источником, а число сессий завышено, вероятная причина —
+сборка витрины из событий вместо сессий.
+
+## Как проверить себя
+
+Деловой ключ — `device_category` внутри дня. Получите прямой агрегат из
+`dds.session_v` за день. Соедините его с `dm.session_overview_v` полным
+внешним соединением по ключу. Посчитайте строки, где ключ отсутствует с
+одной из сторон или различается любой счетчик. Расхождений должно быть ноль.
+
+Еще две проверки дневных итогов:
+
+- сумма `sessions` равна числу строк `dds.session_v` за день — без потерь и
+  повторного учета визитов;
+- сумма `events_total` равна сумме `events_total` по сессиям того же дня.
+
+## Приемка
+
+- [ ] созданы пять объектов, донор объявлен через `AS` и шардируется ключом
+      цели;
+- [ ] в `dm.session_overview_v` колонки перечислены явно;
+- [ ] источник — `dds.session_v`, повторного выделения визитов нет;
+- [ ] физическая таблица не хранит средние и доли;
+- [ ] задача `session_overview` в `homework_check` завершилась успешно;
+- [ ] задача витрины добавлена в `dm_transform`.

docs/labs/1-4-dq-errors-daily.md

@@ -0,0 +1,113 @@
+# Задание 4: `dm.dq_errors_daily`
+
+**Чему учит:** считать брак по дню загрузки и сохранять сводку дольше
+исходных строк. Пересборка всех партиций после удаления источника по `TTL`
+стирает историю, которую уже не восстановить.
+
+## Сначала прочитать
+
+- [«Хранилище и его слои»](../handbook/storage-layers.md);
+- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
+
+## Роль витрины
+
+Сводку открывают при росте брака в потоке: смотрят, каких ошибок стало
+больше и сколько строк забраковано. Причину конкретной ошибки исследуют
+в `ods.event_errors_dist` и `ods.order_errors_dist`, где есть сырой текст и
+координаты доставки.
+
+## Что сделать
+
+Зерно — **день загрузки × источник × класс брака**. В источнике зерно —
+строка брака. Зерно новое, поэтому витрина хранится готовым агрегатом — см.
+[«Как принято на ступени 1»](README.md#как-принято-на-ступени-1). Создайте
+пять объектов: `dm.dq_errors_daily_rep` / `_dist`, донор `_stage_rep` /
+`_stage_dist` и публичное представление `dm.dq_errors_daily_v`. Ключ
+партиции — день загрузки.
+
+### Состав колонок
+
+| Колонка | Тип | Значение |
+|---|---|---|
+| `load_date` | `Date` | День загрузки забракованной строки |
+| `source` | `LowCardinality(String)` | `event` или `order` |
+| `error_class` | `LowCardinality(String)` | Класс брака из таблицы ошибок |
+| `error_rows` | `UInt64` | Число забракованных строк |
+| `_load_id` | `String` | Идентификатор запуска, собравшего день |
+| `_load_ts` | `DateTime64(3, 'UTC')` | Время сборки |
+
+Вычислите `load_date` как `toDate(_load_ts)` из таблицы ошибок — это
+реальный день приема строки. Модельный день записан внутри исходной строки.
+Ее не удалось разобрать, поэтому надежно получить из нее день не получится.
+Служебная `_load_ts` витрины описывает сборку сводки; ее дата может
+отличаться от `load_date`.
+
+У событий и заказов свои классы брака. `source` входит в зерно, чтобы
+одинаковые имена классов с разным смыслом не объединялись в одну строку.
+
+### Ритм пересборки
+
+Брак хранится месяц по `TTL`, сырые данные — трое суток. Сводка хранится
+бессрочно: итоги нужны и после удаления исходных строк.
+
+Получите список дней загрузки, еще имеющихся в источниках. Соберите их в
+донор и замените только эти партиции, сохранив остальные.
+
+В течение текущих суток ошибки еще поступают: пересчитайте этот день на
+следующем прогоне.
+
+### Ключ шардирования
+
+Выберите ключ самостоятельно. Классов брака у событий и заказов вместе
+меньше десятка. Объясните, насколько существенен перекос при таком объеме.
+
+Ключ донора — тот же, что у цели (см. [«Как принято на ступени
+1»](README.md#как-принято-на-ступени-1) и раздел «Раскладка по шардам»
+[справочника хранилища](../architecture/storage.md)).
+
+## Источники: таблицы `_dist`
+
+Только это задание читает данные не через `_v`: брак нужен для диагностики
+приема и не входит в бизнес-модель. Публичных представлений у таблиц ошибок
+нет, создавать их для задания не нужно. Источники:
+
+- `ods.event_errors_dist` — ошибки разбора событий;
+- `ods.order_errors_dist` — ошибки разбора слепка заказов.
+
+Чтение локальной `_rep` даст строки одного шарда из двух: часть брака не
+попадет в сводку, хотя запрос выполнится без ошибки.
+
+## Типичная ошибка
+
+Если заменить всю таблицу данными из нового донора, исчезнут итоги дней,
+истекших по `TTL` источника. Восстановить их неоткуда.
+
+## Как проверить себя
+
+Деловой ключ — `source` и `error_class` внутри `load_date`. Проверяйте дни,
+оставшиеся хотя бы в одной таблице ошибок. Если дня за пределами `TTL` уже
+нет в источнике, это не ошибка: сверять его уже не с чем.
+
+Посчитайте строки прямо в обеих таблицах ошибок и соедините результат с
+`dm.dq_errors_daily_v` полным внешним соединением по ключу. Затем посчитайте
+строки, где ключ отсутствует с одной из сторон или различается `error_rows`.
+Расхождений должно быть ноль.
+
+Сумма `error_rows` по проверяемым дням равна общему числу строк в
+`ods.event_errors_dist` и `ods.order_errors_dist`. Если она примерно вдвое
+меньше, вероятная причина — чтение `_rep` вместо `_dist`.
+
+Пустая витрина на чистом стенде — верный ответ: обе стороны пусты,
+расхождений ноль, проверка успешна. Требование хотя бы одной строки дало бы
+постоянную ошибку, которую со временем стали бы игнорировать.
+
+## Приемка
+
+- [ ] созданы пять объектов, донор объявлен через `AS` и шардируется ключом
+      цели;
+- [ ] источники — таблицы `_dist` обоих видов брака;
+- [ ] прогон заменяет партиции только дней, еще имеющихся в источниках, и
+      сохраняет дни за пределами их срока хранения;
+- [ ] задача `dq_errors_daily` в `homework_check` завершилась успешно, в том
+      числе на чистом стенде без брака;
+- [ ] задача витрины добавлена в `dm_transform`.

docs/labs/1-5-utm-effectiveness.md

@@ -0,0 +1,138 @@
+# Задание 5: `dm.utm_effectiveness`
+
+**Чему учит:** понимать предупреждение в приставке `declared_`: это сумма со
+слов клиента, а не деньги отчетности. Самостоятельно находить причины
+расхождения двух сумм выручки.
+
+## Сначала прочитать
+
+- [«Хранилище и его слои»](../handbook/storage-layers.md);
+- [«Потоки Airflow и даги модельного времени»](../handbook/airflow-dags.md).
+
+## Роль витрины
+
+Аналитик сравнивает рекламные каналы по дням: трафик, добавления в корзину,
+покупки и заявленные клиентом суммы.
+
+На стенде поведение и атрибуцию считают по трекеру, деньги — по бэкенду.
+Здесь сделано исключение: UTM-метки есть только в кликстриме, поэтому для
+оценки покупок по меткам используют клиентскую сумму.
+
+## Что сделать
+
+Читайте `dds.event_v` напрямую, без соседних витрин DM. Зерно — **день
+события × `utm_source` × `utm_medium` × `utm_campaign`**. Зерно новое,
+поэтому витрина хранится готовым агрегатом — см. [«Как принято на ступени
+1»](README.md#как-принято-на-ступени-1). Создайте пять объектов:
+`dm.utm_effectiveness_rep` / `_dist`, донор `_stage_rep` / `_stage_dist` и
+публичное представление `dm.utm_effectiveness_v`. Ключ партиции — день.
+
+### Состав колонок
+
+| Колонка | Тип | Значение |
+|---|---|---|
+| `report_date` | `Date` | День события |
+| `utm_source` | `LowCardinality(String)` | Источник кампании |
+| `utm_medium` | `LowCardinality(String)` | Канал кампании |
+| `utm_campaign` | `String` | Имя кампании |
+| `visitors` | `UInt64` | Число разных `client_id` |
+| `pageviews` | `UInt64` | Число просмотров страниц |
+| `add_to_carts` | `UInt64` | Число добавлений в корзину |
+| `purchases` | `UInt64` | Число покупок |
+| `declared_revenue` | `Decimal(18, 2)` | Сумма покупок, заявленная клиентом |
+| `_load_id` | `String` | Идентификатор запуска, собравшего день |
+| `_load_ts` | `DateTime64(3, 'UTC')` | Время сборки |
+
+Для `declared_revenue` сложите `purchase_revenue[1]` событий `purchase`. В
+параллельных массивах `purchase*` по контракту хранятся один номер заказа и
+одна сумма на событие. В сверке `purchase_vs_orders` используют тот же
+индекс.
+
+Тип `purchase_revenue` — `Array(Decimal(18, 2))`: исходный `Float64`
+преобразован в ODS. Сложение Decimal точное; `CAST` до или после `sum` не
+меняет результат и не нужен. Тип итога — `Decimal(18, 2)`.
+
+Для `utm_campaign` выбран тип `String`: имен кампаний со временем становится
+много, и затраты на словарь `LowCardinality` перестают окупаться.
+
+### Ритм пересборки
+
+События прожитого дня больше не меняются. Как в задании 2, соберите в донор
+дни от первого несобранного до последнего прожитого и замените дневные
+партиции. Добавьте задачу в `dm_transform`.
+
+### Ключ шардирования
+
+Выберите ключ самостоятельно. Если берете хеш одной из трех UTM-колонок,
+посчитайте долю строк с ее самым частым значением и обоснуйте выбор.
+
+Ключ донора — тот же, что у цели (см. [«Как принято на ступени
+1»](README.md#как-принято-на-ступени-1) и раздел «Раскладка по шардам»
+[справочника хранилища](../architecture/storage.md)).
+
+## Атрибуция по событию, а не по визиту
+
+Группируйте события по их собственным меткам. Модели «первое касание» и
+«последнее касание» здесь не рассчитываются.
+
+В `dds.session_v` записаны UTM первого события визита. Распределение по
+каналам может отличаться от этой витрины, и это не означает ошибку в
+расчете. В отчете различайте атрибуцию визитов и событий.
+
+## Прямой трафик остается в витрине
+
+Сохраните события без меток: прямой трафик обычно крупнейший канал, и без
+него доля рекламы будет завышена. Если отфильтровать такие строки, дневные
+итоги перестанут сходиться с источником — а по этому совпадению вы
+проверяете сборку. Разница составит вклад исключенных событий.
+
+Оставьте пустые метки пустыми строками: новое обозначение прямого трафика
+потребовало бы объяснения.
+
+## Расхождение с `dm.revenue_daily_v`
+
+Сравните за один день `sum(declared_revenue)` своей витрины и `sum(revenue)`
+из `dm.revenue_daily_v`. Суммы не сходятся; проверять их равенство не нужно.
+
+В `revenue_daily` складываются цены позиций, умноженные на количество, без
+скидок и доставки — та же основа, что у клиентской суммы. Расхождение
+объясняется историей заказов, а не способом расчета:
+
+- событие покупки остается после отмены заказа, а `revenue_daily` учитывает
+  только оплаченные заказы;
+- событие покупки может потеряться при доставке, хотя заказ поступил, или
+  поступить дважды;
+- клиентская сумма может отличаться от серверной суммы позиций: генератор
+  намеренно создает это расхождение у одного-двух заказов из ста.
+
+Запишите свой вывод в двух-трех фразах. Число расхождений по заказам и их
+причины можно посмотреть в `dm.purchase_vs_orders_v`, где выделены классы
+расхождений.
+
+## Как проверить себя
+
+Деловой ключ — `utm_source`, `utm_medium`, `utm_campaign` внутри дня.
+Получите прямой агрегат из `dds.event_v` за день и соедините его с
+`dm.utm_effectiveness_v` полным внешним соединением по ключу. Посчитайте
+строки, где ключ отсутствует с одной из сторон или различается любая из пяти
+величин. Расхождений должно быть ноль.
+
+Дополнительно сверьте дневные итоги:
+
+- суммы `pageviews`, `add_to_carts` и `purchases` равны числу событий
+  соответствующих типов в `dds.event_v`;
+- сумма `declared_revenue` равна сумме `purchase_revenue[1]` по всем
+  событиям `purchase` того же дня.
+
+Сумма `visitors` по строкам повторно учитывает одного посетителя,
+приходящего по разным меткам. Для числа посетителей дня она не подходит.
+
+## Приемка
+
+- [ ] созданы пять объектов, донор объявлен через `AS` и шардируется ключом
+      цели;
+- [ ] сохранены строки без UTM-меток;
+- [ ] `declared_revenue` хранится в `Decimal(18, 2)`;
+- [ ] расхождение с `dm.revenue_daily_v` объяснено письменно;
+- [ ] задача `utm_effectiveness` в `homework_check` завершилась успешно;
+- [ ] задача витрины добавлена в `dm_transform`.

docs/labs/2-1-superset-chart.md

@@ -0,0 +1,90 @@
+# Свой график в Superset
+
+**Чему учит:** увидеть, как собственный результат из хранилища становится
+отчетом в BI.
+
+## Сначала прочитать
+
+- [«Немного Superset»](../handbook/superset.md);
+- [задание 3: `dm.session_overview`](1-3-session-overview.md).
+
+## Роль графика
+
+В задании 3 вы собрали витрину `dm.session_overview_v`. Теперь покажите, с
+каких устройств чаще уходят после первой страницы. Постройте столбиковый
+график доли отказов по `device_category` за весь период витрины. Измерение
+одно — `device_category`, метрика тоже одна.
+
+## Что сделать
+
+Заведите физический датасет в подключении к `ClickHouse`: схема `dm`, объект
+`session_overview_v`. Назовите по-русски хотя бы две колонки:
+
+- `device_category` — «Категория устройства»;
+- `report_date` — «Дата отчета».
+
+В редакторе датасета, на вкладке «Metrics», создайте метрику:
+
+| Поле | Значение |
+|---|---|
+| `Metric Key` | `bounce_share` — ключ метрики и ее SQL-псевдоним |
+| `Label` | «Доля отказов» |
+| `SQL expression` | `SUM(bounce_sessions) / SUM(sessions)` |
+| `D3 format` | `.1%` |
+
+Доля считается из сумм слагаемых: среднее готовых долей соврет. Поэтому
+метрике нужно это выражение. Сохраните ее в датасете, а не в графике:
+подписи и формат задаются в датасете, а график их использует. Так во всех
+будущих графиках у метрики будут одинаковые подписи. Это правило описано в
+[справочнике Superset](../architecture/superset.md#дерево-импорта).
+
+Не используйте вкладку «Custom SQL» конструктора графика. Созданная там
+метрика доступна только этому графику, а нужна метрика датасета.
+
+Создайте столбиковый график с метрикой «Доля отказов». В поле «X-axis»
+укажите «Категория устройства», а «Dimensions» не заполняйте. Дашборд
+создавать не нужно: сохраненного графика достаточно.
+
+По умолчанию в графике выбран период «No filter». Оставьте его таким или
+задайте явные даты. Относительный период, например «Last week», даст пустой
+график: модельный календарь стенда отстает от настоящего. Последнюю дату
+витрины посмотрите в SQL Lab:
+
+```sql
+SELECT max(report_date)
+FROM dm.session_overview_v;
+```
+
+Стендовые объекты не меняйте. Что переживает `make up`, а что стирает
+`make clean`, описано в главе [«Немного Superset»](../handbook/superset.md#стендовые-объекты-и-ваши).
+
+## Как проверить себя
+
+График проверяется глазами, поэтому задачи для него в `homework_check` нет.
+В SQL Lab выполните запрос:
+
+```sql
+SELECT device_category,
+       round(100 * sum(bounce_sessions) / sum(sessions), 1) AS bounce_pct
+FROM dm.session_overview_v
+GROUP BY device_category
+ORDER BY device_category;
+```
+
+Сверьте с графиком значение для каждой категории. В разделе «Customize»
+включите «Show Value» или наведите указатель на столбик. Запрос возвращает
+проценты с одним знаком, как формат `.1%`, поэтому числа должны совпасть
+один в один.
+
+## Приемка
+
+- [ ] создан физический датасет `dm.session_overview_v` в подключении
+      `ClickHouse`;
+- [ ] в датасете есть метрика «Доля отказов» с выражением
+      `SUM(bounce_sessions) / SUM(sessions)` и форматом `.1%`;
+- [ ] для `device_category` и `report_date` заданы русские имена «Категория
+      устройства» и «Дата отчета»;
+- [ ] сохранен столбиковый график доли отказов по категориям устройств без
+      относительного фильтра по времени;
+- [ ] график сверен с запросом из SQL Lab;
+- [ ] стендовые объекты не изменены, дашборд не создан.

docs/labs/3-1-sessions-by-hand.md

@@ -0,0 +1,89 @@
+# Нарежь сессии сам
+
+**Чему учит:** собрать сессии из событий и сверить их число с внешним
+эталоном. Найти причину расхождения в отдельных строках.
+
+## Сначала прочитать
+
+- [Хранилище и его слои, раздел DDS](../handbook/storage-layers.md#dds-язык-бизнеса);
+- [формат события: Идентификаторы и время](../formats/clickstream-event.md#идентификаторы-и-время).
+
+## Роль сессии
+
+Визит, или сессия, объединяет действия посетителя за один заход на сайт.
+По визитам аналитик считает длительность и глубину просмотра.
+В хранилище сессии собираются из отдельных событий.
+Сверьте самостоятельный расчет с `VisitID`, чтобы увидеть, как из событий
+получается сессия.
+
+## Что сделать
+
+### Нарезка
+
+В SQL Lab или DBeaver под `analyst` напишите запрос к `ods.event_v`.
+Для своей нарезки и эталона возьмите одни и те же строки за все доступные
+дни: для расследования понадобятся события соседних дней.
+Выберите `ClientID`, `UTCEventTime`, `EventDate`, `EventType` и `VisitID`.
+В `dds.event_v` эталонного `VisitID` нет.
+
+Для начала считайте визитом последовательные события одной куки (`ClientID`);
+пауза дольше 30 минут открывает новый визит.
+Учитывайте события всех типов. Упорядочите их по `UTCEventTime`.
+Присвойте каждому событию номер своей сессии внутри куки.
+Подсказка: оконные функции.
+
+Днем сессии считайте `EventDate` ее первого события: дата из `UTCEventTime`
+отличается от `EventDate` для части событий, поэтому берите `EventDate`.
+При сверке останутся расхождения из-за еще одной договоренности стенда.
+
+### Сверка с эталоном
+
+В эталоне посчитайте число визитов каждой куки за модельный день:
+
+```sql
+SELECT ClientID, EventDate, uniqExact(VisitID) AS reference_sessions
+FROM ods.event_v
+GROUP BY ClientID, EventDate
+ORDER BY EventDate, ClientID;
+```
+
+Посчитайте свои сессии по куке и дню сессии.
+Соедините два готовых агрегата через `FULL OUTER JOIN` по куке и дню.
+В результате полного соединения останутся ключи обеих сторон: при расхождении
+на вашей стороне ключа может не быть совсем. Учтите такие строки при сравнении.
+Выведите сводку по дням с числом разошедшихся кук и список этих кук
+с днем и обоими значениями счета. Общая сумма за день могла бы скрыть
+взаимную компенсацию ошибок разных кук. По списку видно, у кого искать причину.
+
+Расхождений будет всего несколько. Если их нет, мир прожил мало дней.
+Прогоните несколько дней через [даги модельного времени](../handbook/airflow-dags.md#даги-мира)
+и повторите сверку.
+
+### Расследование
+
+Выберите одну разошедшуюся куку. Выведите ее события за два соседних дня
+с `UTCEventTime`, `EventDate`, `VisitID` и номером своей сессии.
+Сопоставьте сессии через события: общего ключа у двух нарезок нет,
+зато у каждого события есть и `VisitID`, и присвоенный вами номер.
+Найдите два соседних события, между которыми границы визитов разошлись.
+Запишите куку, день, время обоих событий и причину одним предложением.
+Уточните определение визита и добейтесь нуля расхождений во всех днях.
+
+## Как проверить себя
+
+Результат задания проверяется глазами, поэтому задачи в `homework_check`
+для него нет. Таблицы и представления создавать не нужно.
+Сохраните исходный и уточненный расчеты, результаты сверки и найденные строки.
+
+**Предупреждение.** В `sql/dds/session_rebuild.sql` и
+`sql/dq/sessions_vs_reference.sql` лежат готовые запросы нарезки и сверки.
+Откройте их после собственного решения и расследования. Сравните запросы
+со своими: копирование готового SQL пропускает расследование.
+Сопоставление со стендовой нарезкой по `session_id` остается на ступень 4.
+
+## Приемка
+
+- [ ] запрос нарезает все события `ods.event_v` за все доступные дни;
+- [ ] сверка через `FULL OUTER JOIN` дает сводку по дням и список кук;
+- [ ] при разборе расхождения указаны кука, день, два события и причина;
+- [ ] уточненный расчет дает ноль расхождений во всех днях.

docs/labs/4-1-session-pipeline.md

@@ -0,0 +1,192 @@
+# Перепиши нарезку стенда
+
+**Чему учит:** изменить расчетную сущность внутри готового конвейера и
+проверить результат внешним эталоном.
+
+## Сначала прочитать
+
+- [задание «Нарежь сессии сам»](3-1-sessions-by-hand.md);
+- [модель сессии DDS](../architecture/dds/session.md);
+- [дневной конвейер трансформаций](../architecture/etl.md#объём-прогона);
+- [раскладка по шардам](../architecture/storage.md#раскладка-по-шардам).
+
+## Граница задания
+
+Даг, таблицы сессий и проверка их числа уже созданы.
+Перепишите только три файла:
+
+- `sql/dds/session_scope.sql`;
+- `sql/dds/session_rebuild.sql`;
+- `sql/dds/session_replace.sql`.
+
+Удалите из них готовый SQL и соберите свою реализацию. Параметры и порядок
+запросов заданы в `dds_transform`. DDL задает целевые таблицы и донор. Донор —
+служебная таблица, где день собирается перед заменой. В
+`sessions_vs_reference.sql` число сессий сравнивается с `VisitID` из ODS.
+
+## Договор с дагом
+
+Объем прогона — дни, которые соберет один запуск. Его вычисляет первый файл.
+
+| Файл | Вход | Результат |
+|---|---|---|
+| `session_scope.sql` | `{position:UInt16}` — номер первого несыгранного дня | `first_day` и `last_day` |
+| `session_rebuild.sql` | `{first_day:Date}`, `{last_day:Date}`, `{load_id:String}` | Сессии в `dds.session_stage_dist` |
+| `session_replace.sql` | День в `{{ params.day }}` | Партиция дня в `dds.session_rep` |
+
+Первый прожитый день, которого еще нет в DDS, становится `first_day`.
+`last_day` — последний прожитый день. Начало шкалы нужно взять из событий ODS:
+`position` считает дни от него. Живой модельный день еще не закончен, поэтому
+сессии за него не собираются.
+
+Если в ODS нет ни одного события, запрос не возвращает строк. Если DDS уже
+догнал мир, запрос возвращает строку с `first_day = NULL`. В этом случае группа
+сессий в Airflow получает состояние `skipped`.
+
+`session_rebuild.sql` сначала очищает `dds.session_stage_rep` на всем кластере.
+Затем он собирает в `dds.session_stage_dist` все дни отрезка. Добавьте к
+вставке `SETTINGS distributed_foreground_insert = 1`. Так строки успеют попасть
+на шарды до замены партиций.
+
+Цель `session_replace.sql` — локальная таблица `dds.session_rep`, источник —
+локальный донор `dds.session_stage_rep`. Операция выполняется на всем кластере.
+
+Не ставьте точку с запятой в конце `session_scope.sql`. Драйвер добавляет формат
+ответа, и точка с запятой превратит строку в мультизапрос, который ClickHouse
+отклонит. День для замены подставляет шаблон Jinja в Airflow. Параметр
+ClickHouse в `ALTER ... PARTITION` здесь не работает.
+
+## Нарежьте сессии
+
+Источник сборки — `dds.event_v`. Одна строка результата представляет один
+визит. На третьей ступени вы уже нарезали сессии:
+
+- сессия не пересекает модельные сутки;
+- пауза больше 30 минут открывает новую сессию;
+- в нарезке участвуют события всех типов.
+
+Пересборка добавляет требования к повторяемости. При одинаковом времени
+порядок событий задает `event_id`, поэтому полный порядок окон —
+`(event_time, event_id)`. Один визит должен получать одинаковый `session_id`
+при каждом запуске. Тогда его можно сравнить с сохраненным результатом.
+Вычислите идентификатор как `cityHash64(client_id, min(event_time))`.
+
+Состав и типы строки заданы в `dds.session_rep`. Заполните начало, конец и
+длительность. Посчитайте все события, просмотры, добавления в корзину и
+покупки. Возьмите входную и выходную страницы, UTM первого события, устройство
+и город. Служебные колонки тоже входят в договор таблицы.
+
+Пишите через `dds.session_stage_dist`: место строки определит ключ
+`client_id`. При записи прямо в локальную таблицу оно зависело бы от ноды,
+которая выполнила запрос.
+
+## Запустите свою реализацию
+
+Готовые дни повторно не собираются. Чтобы новый SQL точно выполнился, выберите
+последний собранный день:
+
+```sql
+SELECT max(session_date)
+FROM dds.session_v;
+```
+
+Берите последний день: более ранняя дыра расширит объем до всех последующих
+прожитых дней.
+
+Сохраните десять строк с идентификатором, границами, длительностью и счетчиками:
+
+```sql
+SELECT
+    session_id,
+    client_id,
+    session_date,
+    started_at,
+    finished_at,
+    duration_seconds,
+    events_total,
+    pageviews,
+    cart_adds,
+    purchases
+FROM dds.session_v
+WHERE session_date = 'YYYY-MM-DD'
+ORDER BY client_id, started_at, session_id
+LIMIT 10;
+```
+
+Создайте в DBeaver подключение к первой ноде по [инструкции из
+README](../../README.md#подключиться-из-dbeaver). Укажите пользователя `etl` и
+пароль `CLICKHOUSE_ETL_PASSWORD` из `.env`. У этой учетной записи есть право
+менять таблицы DDS на кластере. Подставьте найденную дату и удалите только ее
+партицию:
+
+```sql
+ALTER TABLE dds.session_rep ON CLUSTER clickstream_cluster
+DROP PARTITION 'YYYY-MM-DD';
+```
+
+Откройте Airflow и запустите `etl_pipeline`. В даге `dds_transform` раскройте
+группу `session`: в ней должны выполниться задачи `scope` и `rebuild`, а также
+`replace` для выбранного дня. Если после третьей ступени мир ушел вперед,
+в группе появятся задачи `replace` и для последующих прожитых дней. Следом
+выполнятся витрины и `dq_check`.
+
+Если прогон дошел до замены, но упал на проверке, ошибочная партиция уже
+находится в DDS. После правки снова удалите тот же день перед следующим
+запуском. Иначе день останется заполненным, а новая сборка для него не
+выполнится.
+
+## Как проверить себя
+
+Сначала повторите запрос с десятью строками. `session_id`, границы,
+длительность и счетчики должны совпасть с сохраненным результатом. Так вы
+завершите отложенное с третьей ступени сопоставление со стендовой нарезкой по
+`session_id`.
+
+Задача `dq_check.sessions_vs_reference` должна стать зеленой. Та же проверка
+видна в хранилище:
+
+```sql
+SELECT data_date, reference_rows, actual_rows, failed_rows, status
+FROM dm.dq_summary_v
+WHERE check_name = 'sessions_vs_reference'
+ORDER BY data_date;
+```
+
+Эта сверка сравнивает число сессий каждой куки за день с `VisitID`. Нулевой
+`failed_rows` не подтверждает границы, страницы и UTM: две ошибки могут
+оставить тот же счет. Возьмите поштучную сверку из третьей ступени. Для одной
+куки выбранного дня сопоставьте границы `VisitID` по событиям с границами
+строк `dds.session_v`. По исходным событиям проверьте страницы, UTM, устройство
+и город. Страницы и UTM не входят в сохраненные десять строк: готовый SQL
+стенда выбирал их через `argMin` и `argMax` только по `event_time`. При равном
+времени ожидаемое значение определяйте по исходным событиям и полному порядку
+`(event_time, event_id)`.
+
+Осталась физическая раскладка. Напишите отдельный запрос к
+`dds.session_dist`. Для каждой строки он должен:
+
+1. получить фактическую ноду через `hostName()`;
+2. пересчитать ожидаемую ноду по `cityHash64(client_id)`;
+3. посчитать строки, у которых ноды не совпали.
+
+У кластера два равных шарда: остаток 0 соответствует `clickhouse-01`, остаток
+1 — `clickhouse-02`. Сгруппируйте ответ по фактической ноде. На каждой ноде
+число строк на чужом шарде должно быть нулевым. Проверка числа сессий читает
+Distributed-таблицу и такую ошибку не заметит.
+
+После зеленого результата запустите `etl_pipeline` еще раз, не удаляя
+партицию. Расчет объема должен пропустить группу сессий: новых прожитых дней и
+дыр в слое нет.
+
+## Приемка
+
+- [ ] переписаны только три файла `sql/dds/session_*.sql`, инфраструктура
+      упражнения не изменена;
+- [ ] запуск после удаления партиции восстановил выбранный день и завершил
+      `etl_pipeline` успешно;
+- [ ] сохраненные `session_id`, границы, длительность и счетчики десяти строк
+      совпали после пересборки;
+- [ ] `sessions_vs_reference` дает ноль расхождений во всех прожитых днях;
+- [ ] для одной куки вручную сверены границы и атрибуты сессии;
+- [ ] пересчет ключа по `hostName()` не нашел строк на чужом шарде;
+- [ ] повторный прогон без новой дыры пропустил группу сессий.

docs/labs/5-1-order-checks.md

@@ -0,0 +1,148 @@
+# Сначала сторож, потом ломай: заказы
+
+**Чему учит:** до рискованного изменения задавать проверке явный договор и
+испытывать его управляемой ошибкой.
+
+## Сначала прочитать
+
+- [модель заказа DDS](../architecture/dds/order.md);
+- [дневной конвейер](../architecture/etl.md#объём-прогона);
+- [правила проверок](../architecture/testing.md#проверка-которая-не-умеет-краснеть-бесполезна).
+
+Посмотрите также на устройство одной проверки в [`sql/dq/`](../../sql/dq/)
+и на ее включение в [`dq_check`](../../dags/dq_check.py). Готового ответа для
+двух проверок из этого задания в репозитории нет.
+
+## Граница задания
+
+Добавьте два сторожа:
+
+- `sql/dq/order_items_total.sql` проверяет сумму позиций заказа;
+- `sql/dq/orders_vs_ods.sql` сверяет DDS с его источником;
+- `dags/dq_check.py` запускает обе проверки, публикует их строки в
+  `dm.dq_summary` и создает для них отдельные задачи.
+
+На этом шаге не меняйте разбор ODS и сборку DDS. Даги, DDL, таблицы-доноры,
+Kafka и службы остаются несущей частью упражнения.
+
+Перед опытами остановите автоматическое движение мира: поставьте `world_live`
+на паузу и дождитесь завершения активных прогонов. До чистой точки остановки не
+запускайте руками `world_next_day`, `world_live_day`, `world_initialize` и
+`world_recreate`. Это условие стабильного модельного времени: одной паузы
+`world_live` для него мало.
+
+## Два договора качества
+
+Обе проверки следуют договору `dq_check`: запрос возвращает по одной строке
+на день с колонками `data_date`, `reference_rows`, `actual_rows`,
+`failed_rows`, `diagnostics`. Даг сохраняет в `dm.dq_summary` только счетчики,
+статус и координаты запуска. Ограниченные примеры из `diagnostics` ищите в
+журнале упавшей задачи Airflow. Ограничьте их тем же малым числом, что и
+существующие запросы в `sql/dq/`.
+
+### Сумма позиций
+
+Имя проверки - `order_items_total`. Для каждого заказа из `dds.order_v`
+посчитайте сумму `item_price * item_quantity` и сравните ее с `items_total`.
+`reference_rows` считает ключи со стороны `items_total`, `actual_rows` - ключи
+со стороны вычисленной суммы, а `failed_rows` - несовпавшие значения. В
+исправном наборе первые два счетчика равны по построению; сам инвариант выражен
+через `failed_rows`. Для диагностики достаточно `order_id`, ожидаемой суммы и
+суммы позиций.
+
+Проверка относится к типизированному разбору массива `items` на границе
+ODS -> DDS. Скидка, доставка и равенство `total` в этот договор не входят.
+
+### DDS против ODS
+
+Имя проверки - `orders_vs_ods`. Источник модели DDS здесь - текущее состояние
+`ods.order_v`. Внутреннее состояние генератора в этот договор не входит.
+Одним запросом соберите обе стороны на зерне дня заказа и сравните:
+
+- число заказов;
+- максимальный `updated_at`.
+
+День ODS вычисляется в `Europe/Samara`, как `order_date` в DDS. Область
+проверки - объединение дней обеих сторон, включая день, который полностью
+пропал из одного слоя. Перед сравнением приведите времена к одному часовому
+поясу. `reference_rows` - число заказов ODS, `actual_rows` - число заказов DDS,
+а `failed_rows` равен единице для дня, где расходится хотя бы одно значение.
+
+Обе стороны распределены по `order_id`. Дневные агрегаты соедините через
+`GLOBAL FULL OUTER JOIN` с `join_use_nulls = 1`, как в существующих сверках.
+
+Если разбор ODS и сборка DDS одинаково потеряют строку, слои останутся равны
+по этой проверке. Общая потеря при разборе проявится в отдельном балансе по
+`_load_id` из [следующего задания](5-2-order-parsing.md).
+
+## Получите красный и зеленый результаты
+
+Сначала запустите `dq_check` на нетронутых данных. Обе новые задачи должны
+завершиться успешно, а в `dm.dq_summary_v` у обоих имен не должно быть
+нарушенных дней.
+
+Выберите оплаченный заказ из последнего слепка с непустым массивом позиций и
+сохраните его `order_id` и `order_date`. Подключитесь к первой ноде из DBeaver
+по [инструкции из README](../../README.md#подключиться-из-dbeaver) под
+пользователем `etl`. Прибавьте одну копейку к `items_total` этого заказа в
+локальной таблице `dds.order_rep` на всем кластере:
+
+```sql
+ALTER TABLE dds.order_rep ON CLUSTER clickstream_cluster
+UPDATE items_total = items_total + toDecimal64(0.01, 2)
+WHERE order_id = '<order_id>'
+SETTINGS mutations_sync = 2;
+```
+
+Затем запустите только `dq_check`. Задача `order_items_total` должна
+завершиться ошибкой, а ее журнал - назвать выбранный заказ.
+`purchase_vs_orders_vs_dds` тоже даст красный результат: сохраненная витрина
+содержит прежний `items_total`.
+
+Запустите `etl_pipeline`. Текущее окно заказов будет заново собрано из ODS, и
+исходная строка вернется в DDS. Повторный `dq_check` должен дать зеленый
+результат для нового сторожа.
+
+Теперь удалите тот же заказ из `dds.order_rep` на всем кластере:
+
+```sql
+ALTER TABLE dds.order_rep ON CLUSTER clickstream_cluster
+DELETE WHERE order_id = '<order_id>'
+SETTINGS mutations_sync = 2;
+```
+
+До восстановления снова запустите только `dq_check`. Красный результат нужен
+для `orders_vs_ods`, `purchase_vs_orders_vs_dds` и `revenue_daily_vs_dds` на
+дне оплаченного заказа. Затем запустите `etl_pipeline` и повторите проверку.
+Если `orders_vs_ods` не обнаружил удаление, исправьте запрос до следующего
+задания.
+
+## Как проверить себя
+
+В `dm.dq_summary_v` должны быть зелены обе новые и пять прежних проверок:
+
+```sql
+SELECT check_name, sum(failed_rows) AS failed_rows, groupUniqArray(status)
+FROM dm.dq_summary_v
+GROUP BY check_name
+ORDER BY check_name;
+```
+
+Проверка суммы должна охватывать каждый день `dds.order_v`. Сверка слоев
+должна охватывать объединение дней ODS и DDS, включая дни только одной стороны.
+
+## Когда можно остановиться
+
+После двух восстановлений выбранный заказ снова совпадает с ODS. Все семь
+проверок дают зеленый результат. В таком состоянии можно закончить работу или
+перейти к разбору заказов, оставив модельное время на паузе.
+
+## Приемка
+
+- [ ] две новые проверки встроены в `dq_check` и публикуют дневные строки по
+      принятому договору;
+- [ ] каждая проверка дала красный результат на своей управляемой ошибке;
+- [ ] журналы упавших задач содержали ограниченную диагностику;
+- [ ] `etl_pipeline` восстановил обе измененные строки DDS;
+- [ ] `order_items_total`, `orders_vs_ods` и пять прежних DQ зелены;
+- [ ] SQL разбора ODS и сборки DDS на этом шаге не менялся.

docs/labs/5-2-order-parsing.md

@@ -0,0 +1,181 @@
+# Перепишите разбор заказов в ODS
+
+**Чему учит:** сначала измерить обе ветви разбора на управляемом срезе, затем
+переписать переход и повторить тот же опыт.
+
+## Сначала прочитать
+
+- [проверки заказов](5-1-order-checks.md);
+- [прием заказов в ODS](../architecture/orders/ingestion.md);
+- [раскладку по шардам](../architecture/storage.md#раскладка-по-шардам);
+- [`orders_ingest`](../../dags/orders_ingest.py);
+- [`order_parse.sql`](../../sql/ods/order_parse.sql).
+
+Готового запроса для сверки управляемого среза в репозитории нет.
+
+## Граница задания
+
+Сначала проведите опыт на готовом `order_parse.sql`. Затем удалите его SQL,
+соберите разбор заново и повторите опыт с другим маркером.
+
+Не меняйте устройство `orders_ingest`, DDL, Kafka, таблиц и преобразований
+DDS. Оба опыта должны закончиться адресной очисткой только своих строк.
+
+Перед началом убедитесь, что после [предыдущего задания](5-1-order-checks.md)
+все семь DQ остались зелеными. Поставьте `world_live` на паузу, дождитесь
+активных прогонов и до завершения опыта не запускайте `world_next_day`,
+`world_live_day`, `world_initialize` и `world_recreate`. Не запускайте
+`etl_pipeline` между
+отправкой пробной пачки и ее очисткой.
+
+## Четыре строки для двух ветвей
+
+Сделайте четыре сообщения с общим уникальным маркером:
+
+1. годную строку с маркером в `order_id`;
+2. JSON-строку вместо объекта - класс `not_an_object`;
+3. объект с лишним ключом - класс `keyset_mismatch`;
+4. объект с точным набором ключей, но строкой в `user_id` - класс
+   `field_invalid`.
+
+`not_an_object` означает, что корень JSON не объект. `keyset_mismatch` означает,
+что у объекта отличается точный набор верхнеуровневых ключей. `field_invalid`
+означает, что ключи на месте, но значение не прошло проверку типа, формата или
+вместимости.
+
+Соберите строки в `/tmp/<маркер>.jsonl`. Заготовка дает одну годную строку и
+по одному примеру каждого класса брака:
+
+```bash
+LAB_MARKER="lab5-$(date +%s)"
+LAB_BATCH="/tmp/${LAB_MARKER}.jsonl"
+LAB_DAY="$(
+  docker compose exec -T clickhouse-01 sh -lc \
+    'clickhouse-client --user etl --password "$CLICKHOUSE_ETL_PASSWORD" \
+      --query "SELECT toString(max(snapshot_date)) FROM ods.order_dist"'
+)"
+
+jq -cn --arg marker "$LAB_MARKER" --arg day "$LAB_DAY" '
+  def good($id): {
+    order_id: $id, user_id: 1, status: "paid",
+    created_at: ($day + "T00:00:00.000Z"),
+    updated_at: ($day + "T01:00:00.000Z"),
+    items_total: "10.00", discount: "0.00",
+    delivery: "0.00", total: "10.00",
+    items: [{sku: "lab5", qty: 1, price: "10.00"}],
+    snapshot_date: $day
+  };
+  good($marker),
+  ($marker + "-not-an-object"),
+  (good($marker + "-keys") + {lab_marker: true}),
+  (good($marker + "-field") | .user_id = "broken")
+' > "$LAB_BATCH"
+```
+
+Отправьте файл в обычный топик заказов штатным производителем контейнера:
+
+```bash
+docker compose exec -T kafka /opt/kafka/bin/kafka-console-producer.sh \
+  --bootstrap-server kafka:9092 --topic orders < "$LAB_BATCH"
+```
+
+Запустите `orders_ingest` и найдите `_load_id` по маркеру в
+`stg.orders_raw_dist`. У четырех строк должен быть один идентификатор прогона.
+
+## Зафиксируйте исходный результат
+
+До любого запуска `etl_pipeline` проверьте срез по найденному `_load_id`:
+
+- в STG четыре строки;
+- в физической `ods.order_dist` одна годная строка;
+- в `ods.order_errors_dist` три строки, по одной каждого класса;
+- `STG = годные + брак`;
+- текущая строка `ods.order_v` совпадает по деловым полям с результатом
+  `argMax` по `snapshot_date` из годного сырья среза.
+
+Счет физической таблицы нужен именно по `_load_id`: представление
+`ods.order_v` оставляет текущую версию сущности и не показывает, сколько строк
+разобрал запуск. Запрос сверки с `argMax` напишите сами. Эталонные деловые поля
+стройте только из `raw`; отдельно сравните различающиеся `created_at` и
+`updated_at`.
+
+Проверьте раскладку годной строки через `hostName()` на `ods.order_dist`.
+Фактическая нода должна совпасть с остатком `cityHash64(order_id) % 2`:
+0 - `clickhouse-01`, 1 - `clickhouse-02`.
+
+## Уберите пробную пачку
+
+Удалите только строки маркера из локальных таблиц:
+
+```sql
+ALTER TABLE stg.orders_raw_rep ON CLUSTER clickstream_cluster
+DELETE WHERE position(raw, '<маркер>') > 0
+SETTINGS mutations_sync = 2;
+
+ALTER TABLE ods.order_rep ON CLUSTER clickstream_cluster
+DELETE WHERE startsWith(order_id, '<маркер>')
+SETTINGS mutations_sync = 2;
+
+ALTER TABLE ods.order_errors_rep ON CLUSTER clickstream_cluster
+DELETE WHERE position(raw, '<маркер>') > 0
+SETTINGS mutations_sync = 2;
+```
+
+В ClickHouse 26.3 мутации выполняются в фоне. С `mutations_sync = 2` команда
+ждет их завершения на всех репликах. Запросами к трем Distributed-таблицам
+докажите, что строк маркера не осталось, затем удалите временный файл.
+
+Группа `clickstream_orders` уже подтвердила эти сообщения, поэтому обычный
+повтор `orders_ingest` их не прочитает. В Kafka они остаются до удаления по
+политике хранения. `world_recreate` удаляет группу и сам топик, поэтому в
+пересозданный мир пробная пачка не переходит.
+
+Очистка должна закончиться до запуска `etl_pipeline`. Если конвейер все же
+успел собрать временный заказ в DDS, сначала очистите три таблицы выше, затем
+запустите `etl_pipeline`: пересборка текущего окна удалит заказ из DDS и
+обновит витрины.
+
+## Перепишите разбор
+
+Удалите готовый SQL из `sql/ods/order_parse.sql` и сохраните его договор с
+`orders_ingest`:
+
+- вход - строки `stg.orders_raw_dist` одного `{load_id:String}`;
+- каждая строка среза попадает ровно в один результат: годный заказ или брак;
+- произвольный `raw` не останавливает весь разбор исключением;
+- годные строки записываются в `ods.order_dist`, остальные - в
+  `ods.order_errors_dist`;
+- классы брака и их порядок - `not_an_object`, `keyset_mismatch`,
+  `field_invalid`;
+- метки доставки и `_load_id` переходят из STG без пересчета;
+- задача завершается после доставки обоих результатов через Distributed, а
+  строки распределяются по ключу целевой таблицы.
+
+Точный набор полей, типы и граница строгого приема описаны в
+[документе приема](../architecture/orders/ingestion.md#граница-строгого-приёма),
+а целевые колонки - в [`20-ods-tables.sql`](../../sql/ddl/20-ods-tables.sql).
+Внутренность `items` остается сырым JSON: ее разбирает DDS.
+
+Повторите опыт с новым маркером. Получите тот же баланс 4 = 1 + 3, те же три
+класса, верную текущую строку по `snapshot_date`, разные времена и правильный
+шард. Затем очистите второй срез теми же адресными командами и запустите
+`dq_check`.
+
+## Когда можно остановиться
+
+Оба маркера отсутствуют в STG, ODS, таблице брака и DDS; временные файлы
+удалены. Семь DQ дают зеленый результат. В таком состоянии можно перейти к
+сборке DDS, не снимая паузу с модельного времени. Если вы прерываетесь и до
+опыта `world_live` работал, снимите его с паузы.
+
+## Приемка
+
+- [ ] до переписывания зафиксированы баланс 4 = 1 + 3, три класса брака,
+      деловые поля текущей версии и фактический шард;
+- [ ] переписан только `sql/ods/order_parse.sql`, несущая инфраструктура не
+      изменена;
+- [ ] после переписывания новый срез дал тот же результат;
+- [ ] обе годные строки различали `created_at` и `updated_at`;
+- [ ] проверки `hostName()` не нашли строки ODS на чужом шарде;
+- [ ] строки обоих опытов удалены только по своим маркерам;
+- [ ] после очистки общий конвейер и семь DQ находятся в зеленом состоянии.

docs/labs/5-3-order-pipeline.md

@@ -0,0 +1,124 @@
+# Перепишите сборку заказов в DDS
+
+**Чему учит:** переписать пересборку заказов по состоянию слоев и доказать ее
+результат на пропущенном закрытом дне.
+
+## Сначала прочитать
+
+- [проверки заказов](5-1-order-checks.md);
+- [разбор заказов в ODS](5-2-order-parsing.md);
+- [модель заказа DDS](../architecture/dds/order.md);
+- [дневной конвейер](../architecture/etl.md#объём-прогона);
+- [раскладку по шардам](../architecture/storage.md#раскладка-по-шардам).
+
+## Граница задания
+
+Удалите готовый SQL и перепишите только три файла:
+
+- `sql/dds/order_scope.sql`;
+- `sql/dds/order_rebuild.sql`;
+- `sql/dds/order_replace.sql`.
+
+Даг `dds_transform`, DDL, донор, ODS и обе проверки из первого задания уже
+задают границу работы. Перед началом убедитесь, что пробные строки предыдущего
+задания удалены, а семь DQ дают зеленый результат.
+
+Поставьте `world_live` на паузу и дождитесь завершения активных прогонов. До
+завершения опыта не запускайте `world_live_day`, `world_initialize` и
+`world_recreate`. `world_next_day` понадобится только в явно указанном ниже
+случае.
+
+## Договор с дагом
+
+Сохраните интерфейс `dds_transform`:
+
+| Файл | Вход | Результат |
+|---|---|---|
+| `order_scope.sql` | без параметров | одна строка `first_day`, `last_day` |
+| `order_rebuild.sql` | `{first_day:Date}`, `{last_day:Date}`, `{load_id:String}` | выбранные дни в `dds.order_stage_dist` |
+| `order_replace.sql` | день в `{{ params.day }}` | партиция дня в `dds.order_rep` |
+
+Объем состоит из текущего окна источника и хвоста от первого дня, который есть
+в ODS, но отсутствует в DDS. Текущее окно дают строки последнего
+`snapshot_date`: их минимальный и максимальный день заказа. Если источник
+пуст, `order_scope.sql` не возвращает строку. Если дыр нет, `first_day` равен
+началу окна. Если дыра старше, непрерывный отрезок начинается с нее.
+
+`order_rebuild.sql` сначала очищает все партиции `dds.order_stage_rep` на
+кластере, затем записывает в `dds.order_stage_dist` весь выбранный отрезок. Он
+читает текущее состояние `ods.order_v`, вычисляет `order_date`, переводит
+времена в `Europe/Samara`, разбирает `items` в три параллельных массива и
+ставит координаты запуска.
+
+Запись через Distributed должна завершиться до замены и использовать ключ
+целевой таблицы для раскладки строк. Способ собрать весь отрезок внутри файла
+выберите сами.
+
+`order_replace.sql` работает с локальными `dds.order_rep` и
+`dds.order_stage_rep` на всем кластере. `REPLACE PARTITION` переносит готовую
+дневную партицию из донора и оставляет донор на месте. Структура, ключи и
+политика хранения совпадают: DDL объявляет донор через `AS dds.order_rep`.
+
+## Восстановите ближайший закрытый день
+
+Найдите последний по дате день DDS, который лежит левее начала текущего окна
+ODS. Это ближайший к окну закрытый день: его удаление показывает расширение
+объема на дыру без пересборки всей истории.
+
+Если такого дня еще нет, один раз продвиньте мир через `world_next_day`,
+дождитесь `orders_ingest`, затем запустите `etl_pipeline`. После этого снова
+зафиксируйте модельное время до конца опыта и выберите ближайший закрытый день.
+
+Сохраните для него число заказов и контрольную сумму деловых полей без
+`_load_id` и `_load_ts`. Удалите только его партицию:
+
+```sql
+ALTER TABLE dds.order_rep ON CLUSTER clickstream_cluster
+DROP PARTITION 'YYYY-MM-DD';
+```
+
+Сразу запустите `dq_check`, до восстановления партиции. Красный результат
+должны дать `orders_vs_ods` и `purchase_vs_orders_vs_dds`.
+`revenue_daily_vs_dds` тоже даст красный результат, если в партиции были
+оплаченные заказы. `classes_vs_inventory` останется зеленым: до запуска
+`dm_transform` эта проверка читает прежнюю витрину сверки.
+
+Запустите `etl_pipeline`. В группе `dds_transform.order` значение `first_day`
+должно совпасть с удаленным днем, а задачи `replace` - покрыть непрерывный
+отрезок от него до конца текущего окна. `first_day` ищите в строке про объем
+пересборки в журнале задачи `order.scope` дага `dds_transform`. После успешного
+прогона число заказов и контрольная сумма выбранного дня должны совпасть с
+сохраненными.
+
+## Проверьте раскладку и повтор
+
+Напишите отдельный запрос к `dds.order_dist`, который получает фактическую
+ноду через `hostName()`, вычисляет ожидаемую по `cityHash64(order_id) % 2` и
+считает несовпадения по каждой ноде. Остаток 0 соответствует
+`clickhouse-01`, остаток 1 - `clickhouse-02`. На обеих нодах число строк на
+чужом шарде должно быть нулевым. Счетные DQ читают Distributed-таблицы и такую
+ошибку раскладки не обнаруживают.
+
+Запустите `etl_pipeline` еще раз при неизменном модельном времени. Группа
+заказов снова должна пересобрать текущее изменяемое окно. Контрольные суммы
+деловых полей остаются прежними, а все семь проверок дают зеленый результат.
+
+## Когда можно остановиться
+
+Удаленная партиция восстановлена, ее число строк и контрольная сумма совпали
+с исходными. На чужих шардах строк нет, повторный прогон не изменил деловые
+данные, семь DQ зелены. Если до упражнения `world_live` работал, теперь его
+можно снять с паузы.
+
+## Приемка
+
+- [ ] переписаны только три файла `sql/dds/order_*.sql`, инфраструктура
+      упражнения не изменена;
+- [ ] удален ближайший к окну закрытый день, а красный DQ зафиксирован до
+      восстановления;
+- [ ] `first_day` начался с удаленного дня, задачи замены покрыли непрерывный
+      отрезок до конца окна;
+- [ ] число заказов и контрольная сумма восстановленного дня совпали;
+- [ ] `order_items_total`, `orders_vs_ods` и пять прежних DQ зелены;
+- [ ] проверка `hostName()` не нашла заказов DDS на чужом шарде;
+- [ ] повторный `etl_pipeline` сохранил деловые данные и зеленые проверки.

docs/labs/6-1-event-parsing.md

@@ -0,0 +1,214 @@
+# Разберите сырые события рядом со стендом
+
+**Чему учит:** пакетно разобрать сообщения отдельно от живого приема и
+построчно проверить свой результат по нетронутому ODS.
+
+## Сначала прочитать
+
+- [формат события](../formats/clickstream-event.md);
+- [справочник хранилища](../architecture/storage.md), разделы про имена
+  объектов, актуальные события, прием потока и срок жизни сырых данных;
+- [ADR о приеме событий](../adr/0005-event-ingestion.md), раздел с принятым
+  решением;
+- схему [`ods.event_rep`](../../sql/ddl/20-ods-tables.sql).
+
+Готовый стендовый разбор находится в `sql/ddl/30-ods-views.sql`. Откройте его
+после собственной сверки: в нем лежит ответ на основную часть задания.
+
+## Граница задания
+
+Создайте в базе `default` одну свою таблицу годных событий и наполните ее одним
+пакетным `INSERT SELECT` из `stg.hits_raw_dist`. Работайте с первой нодой под
+пользователем `etl`.
+
+Матвью `ods.event_mv` и `ods.event_errors_mv` продолжают принимать живой
+поток. Оставьте их, STG, ODS, Kafka и даги без изменений. Пересоздание матвью
+на работающем стенде оставило бы зазор в приеме, а для пакетного опыта оно не
+нужно.
+
+Дайте своей таблице имя, которое не пересечется с чужой работой, и запишите
+его вместе с запросами. В конце вы удалите только эту таблицу.
+
+## Выберите сырой срез
+
+STG хранит строки примерно три дня по `_load_ts`. Эта колонка отмечает время
+поступления в хранилище. Модельный день события лежит в `EventDate`. Сначала
+найдите среди недавних данных завершившийся интервал со строками. Посмотрите
+счет по минутам:
+
+```sql
+SELECT
+    toStartOfMinute(_load_ts) AS minute,
+    count() AS rows
+FROM stg.hits_raw_dist
+WHERE _load_ts >= now() - INTERVAL 30 MINUTE
+  AND _load_ts < toStartOfMinute(now())
+GROUP BY minute
+ORDER BY minute DESC;
+```
+
+Выберите короткий интервал `[slice_from, slice_to)`, который уже закончился и
+дает удобное для построчной проверки число строк. Если одна минута велика,
+сузьте ее точными границами `_load_ts`. Если недавних строк нет, откройте
+Airflow. При включенном `world_live` посмотрите его текущий запуск и дочерний
+`world_live_day`: дождитесь свежих строк от текущего или следующего планового
+запуска, а при ошибке сначала разберите ее причину. Запустите `world_live_day`
+вручную, только если `world_live` стоит на паузе и активного `world_live_day`
+нет. Успешный прогон распределяет события модельного дня по реальным минутам.
+
+Зафиксируйте до разбора:
+
+- обе границы с миллисекундами и число строк;
+- минимальный и максимальный `kafka_offset` по каждой паре
+  `kafka_topic`, `kafka_partition`.
+
+Во всех дальнейших запросах читайте `stg.hits_raw_dist` только с этими
+границами. Новые строки с более поздним `_load_ts` в срез не попадут. Повторите
+опыт до очистки по TTL; после нее прежний срез уже не восстановить из ODS.
+
+## Соберите собственную таблицу
+
+Таблица содержит все 47 полей источника с именами и типами
+`ods.event_rep`, а также `_load_ts`. Тип `purchaseRevenue` возьмите из ODS:
+`Array(Decimal(18, 2))`.
+
+Схлопните повтор доставки по договору ODS. Возьмите
+`ReplacingMergeTree(_load_ts)`, партицию `EventDate` и полный ключ замены:
+`(CounterID, EventDate, intHash32(ClientID), WatchID)`. Достаточно одной
+локальной таблицы: отдельная Distributed-таблица не добавит урока к пакетному
+опыту на одной ноде.
+
+`WatchID` — логический идентификатор события, уникальный по
+[договору генератора](../specs/2026-08-01-generator.md). Физический ключ ODS
+шире: в `ReplacingMergeTree` версиями считаются строки с одинаковым полным
+ключом сортировки. Используйте его при загрузке и сверке.
+
+## Разберите годные строки
+
+Для каждой строки среза примите решение по тому же строгому входу, что и
+стенд:
+
+1. корень `raw` — JSON-объект;
+2. набор верхнеуровневых ключей в точности равен 47 ключам формата;
+3. `WatchID`, `VisitID`, `ClientID`, `EventDate` и `UTCEventTime` разбираются
+   в ожидаемые типы.
+
+Напишите разбор, который не прерывает пакет из-за одной грязной строки. Сами
+выберите способ безопасного извлечения пяти опорных полей, форму общих выражений
+и место фильтра. Остальные поля извлеките по договору формата.
+
+Перенесите `_load_ts` из STG без пересчета: это время исходной доставки и
+колонка версии. Время запуска вашего запроса сюда не входит. Вставьте в свою
+таблицу только годные строки выбранного среза.
+
+Считайте отвергнутые строки прямо в исходном срезе: отдельная таблица брака в
+задание не входит. Проверьте работу строгого входа одним запросом. Посчитайте:
+
+- все доставки;
+- строки, прошедшие ваш предикат;
+- строки, отвергнутые его отрицанием.
+
+Проверьте равенство общего числа строк сумме прошедших и отвергнутых. Так каждая
+исходная строка учитывается ровно в одной группе. Если отвергнутые строки есть,
+сохраните их `raw`, `_load_ts` и координаты Kafka. Найдите те же
+координаты в `ods.event_errors_dist` и запишите стендовый `error_class`. Если
+брака нет, так и зафиксируйте: опыт проверил успешную ветвь и выполнение
+предиката на этом срезе, но не классификатор ошибок. Подкладывать грязные
+сообщения ради задания не требуется.
+
+## Приведите стороны к одному зерну
+
+В STG одна строка представляет доставку. Повтор сообщения остается второй
+строкой. В `ods.event_v` одна строка представляет актуальное событие, потому
+что представление читает физическую таблицу с `FINAL`.
+
+Свою сторону тоже читайте с `FINAL`. Ожидаемый счет равен числу различных
+полных ключей среди годных доставок. Разница между числом доставок и этим
+счетом показывает повторы в исходном срезе.
+
+Область эталона постройте независимо от своего предиката и результата вставки.
+Снова возьмите весь исходный STG-срез. По координатам Kafka исключите доставки,
+которые есть в `ods.event_errors_dist`. У оставшихся доставок извлеките
+`WatchID` без риска прервать запрос и выберите эти события из свежего
+`ods.event_v`.
+
+Свяжите сырую доставку с ODS по `WatchID`: по договору генератора это уникальный
+идентификатор события. Он задает только область эталона. Дедупликация и
+последующее соединение используют полный физический ключ. Не берите область из
+своей таблицы и не применяйте к ней свой предикат. Иначе ошибочно отвергнутая
+строка исчезнет с обеих сторон сверки.
+
+## Сверьте 47 полей
+
+Соедините свою таблицу и выбранные строки `ods.event_v` через `FULL OUTER
+JOIN` по полному ключу замены. Полное соединение сохраняет строки,
+которых нет на одной из сторон. Разделите результат на три исхода:
+
+- строка есть только в ODS — вы ее потеряли;
+- строка есть только у вас — вы приняли лишнее или иначе разобрали часть
+  ключа;
+- ключ есть с обеих сторон, но различается хотя бы одно из 47 полей.
+
+ClickHouse по умолчанию заполняет отсутствующую сторону значениями типов.
+Включите для сверки `join_use_nulls = 1` или добавьте явный признак присутствия
+в каждую сторону. Не определяйте отсутствие по значениям полей события.
+
+Сравните все поля явно, включая массивы, `ecommerce` и точное десятичное
+`purchaseRevenue`. Удобный вид диагностики выберите сами: важно, чтобы по
+результату можно было назвать отличающиеся колонки одной строки. Выведите число
+строк каждого из трех исходов. В верном разборе все три числа равны нулю.
+
+`_load_ts` не входит в 47 полей источника и не проверяет JSON-разбор.
+Проверьте его отдельно. Свяжите каждую строку своей таблицы с меткой одной из
+доставок того же полного ключа в исходном срезе. После `FINAL` остается самая
+поздняя метка этого ключа внутри среза. С ODS ее не сравнивайте: там может
+храниться более поздняя доставка того же события из-за границ среза.
+
+## Расследуйте расхождение
+
+Если сверка не пуста, возьмите одну строку. Вернитесь к независимому списку
+ключей и исходному `raw`, выведите рядом координаты Kafka и `_load_ts`.
+
+Для измененной строки назовите поля, которые расходятся, и сравните каждое с
+сырой строкой. Для пропавшей или лишней строки проверьте пять опорных полей и
+решение строгого предиката. Если координаты доставки есть в
+`ods.event_errors_dist`, посмотрите `error_class`.
+
+Исправьте разбор, удалите и заново создайте только собственную таблицу, затем
+повторите вставку того же среза. Остановитесь, когда счет исходных доставок по
+прежним границам не изменился, баланс строгого входа сошелся, а построчная
+сверка пуста.
+
+## Где заканчивается проверка
+
+`ods.event_v` — образец для сравнения. Оба разбора могли повторить одну
+ошибку. Для пяти опорных полей у вас есть проверка разбираемости и исходный
+JSON. Остальные 42 поля можно вручную сопоставить с `raw`, однако второго
+независимого источника для всех значений на стенде нет.
+
+## Уберите свой объект
+
+Сохраните DDL таблицы, запрос разбора, границы среза, баланс строгого входа и
+пустую итоговую сверку. Затем удалите свою таблицу командой `DROP TABLE` с ее
+точным именем. Убедитесь через `system.tables`, что объекта больше нет.
+Прикладные строки стенда вы не меняли, поэтому удалять данные из STG, ODS или
+Kafka после опыта не нужно.
+
+## Приемка
+
+- [ ] записаны границы малого завершенного среза, его счет и координаты
+      доставки по партициям Kafka;
+- [ ] создана одна собственная таблица со всеми 47 полями, перенесенным
+      `_load_ts` и физическим договором дедупликации ODS;
+- [ ] пакетный разбор принимает только JSON-объекты с точным набором ключей и
+      пятью разбираемыми опорными полями;
+- [ ] счет исходных строк равен сумме годных и отвергнутых, а найденный брак
+      рассмотрен по `raw`, координатам и стендовому классу;
+- [ ] область ODS получена из всех координат исходного среза и стендовой
+      таблицы ошибок, независимо от собственного предиката и таблицы;
+- [ ] обе стороны приведены к зерну полного физического ключа;
+- [ ] `FULL OUTER JOIN` сравнивает все 47 полей, а числа пропавших, лишних и
+      измененных строк равны нулю;
+- [ ] отдельно подтвержден перенос `_load_ts` и учтены повторы доставки;
+- [ ] границы стендового оракула и TTL записаны вместе с результатом;
+- [ ] собственная таблица удалена, объекты и данные стенда не изменены.

docs/labs/7-1-monitoring.md

@@ -0,0 +1,119 @@
+# Мониторинг: куда смотреть
+
+**Чему учит:** начать расследование с подходящего экрана, найти источник
+нагрузки и объяснить свежесть данных через путь доставки.
+
+## Перед началом
+
+Откройте Grafana и Airflow по адресам из раздела [«Адреса и
+пароли»](../../README.md#адреса-и-пароли). Для первого знакомства в Grafana
+есть три дашборда:
+
+- «Данные» — путь сообщений от источника до хранилища;
+- «Кластер» — процессор, память, диски и внутренняя работа ClickHouse;
+- «Запросы» — выполненные запросы, их стоимость и ошибки.
+
+Откройте все три дашборда и запишите по одному вопросу, на который каждый из
+них помогает ответить. «Данные» оставьте открытым в соседней вкладке.
+
+Проведите два расследования на работающем стенде. Службы останавливать и данные
+портить не понадобится.
+
+## Расследование 1. Кто читает больше всех
+
+Начните в спокойный момент: не запускайте одновременно свои тяжелые запросы.
+Откройте дашборд «Запросы». На панели «Тяжёлые запросы: что прочитало больше
+всех» возьмите первую строку.
+
+Сохраните:
+
+- границы окна и время запроса;
+- место запроса в списке, пользователя и ноду;
+- текст запроса;
+- длительность, память, число прочитанных и отданных строк.
+
+По пользователю и тексту определите, кто отправил запрос и для чего. Затем
+найдите запрос одного из трех открытых дашбордов, который прочитал больше всего
+строк. Если это другая строка, сохраните для нее те же поля.
+
+По тексту найдите панель, которая отправила запрос. Ищите ее среди трех
+дашбордов по названиям колонок, таблиц и показателей. Запишите, зачем запрос
+читает столько строк и согласуется ли это с вопросом, на который отвечает
+панель.
+
+В меню панели «Кто спрашивает: сколько запросов и какой у них аппетит»
+откройте Inspect, затем Query. Ответьте на два вопроса:
+
+1. Почему журнал читают сразу с обеих нод?
+2. Почему из счета исключены строки начала запроса и работа шардов?
+
+Проверьте второе объяснение по панели ошибок: ее фильтр не исключает записи
+шардов. Объясните, почему различаются вопросы панелей, а не только их SQL.
+
+## Расследование 2. Как меняется свежесть заказов
+
+Откройте дашборд «Данные». Панель «Свежесть: сколько прошло с последней
+доехавшей строки» показывает текущее число, а не историю. До наблюдения
+нарисуйте ожидаемую форму свежести событий и заказов в течение одного живого
+дня. Отдельно отметьте момент доставки слепка заказов.
+
+Если `world_live` снят с паузы, наблюдайте его текущий или следующий
+`world_live_day`: новый ручной запуск встанет в очередь. Если выключатель на
+паузе и активного живого дня нет, запустите один `world_live_day` вручную.
+Модельные сутки занимают около 24 реальных минут.
+
+Запишите несколько наблюдений до конца дня и сразу после него:
+
+| Реальное время | Свежесть событий, с | Свежесть заказов, с | Что происходило в Airflow |
+|---|---:|---:|---|
+| | | | |
+
+Дашборд обновляется раз в минуту, поэтому точного совпадения момента
+доставки со строкой таблицы ждать не нужно. Рост и сброс свежести заказов
+перенесите на свой набросок. Объясните форму линии: какую метку времени
+вычитает панель из текущего времени, почему число растет и какое событие его
+сбрасывает. Модельную дату сыгранного дня подпишите отдельно от реального
+времени наблюдения.
+
+Подтвердите сброс двумя следами:
+
+- в Airflow завершился прием слепка `orders_ingest`;
+- на панели «Дневной слепок заказов: какой доехал, когда и после какой паузы»
+  появилась новая верхняя строка.
+
+Если вы начали после доставки, дождитесь следующего дня либо честно запишите,
+какую часть формы увидели. Одно текущее значение не доказывает ни рост, ни
+сброс.
+
+## Объясните путь данных
+
+Не открывая справочник, объясните своими словами:
+
+- почему свежесть считают в ODS, а поток — в STG;
+- почему знаменатель доли брака берут из STG;
+- почему у числителя и знаменателя доли брака одно окно.
+
+Свяжите ответы с тем, что вы видели на панелях. Затем сверьте объяснение с
+[главой о мониторинге](../handbook/monitoring.md) и справочниками дашбордов
+[«Запросы»](../architecture/monitoring/queries.md) и
+[«Данные»](../architecture/monitoring/data.md). Устройство живого дня и
+доставки слепка описано в [главе об Airflow](../handbook/airflow-dags.md).
+
+## Приемка
+
+- [ ] для каждого из трех дашбордов записан вопрос, на который он отвечает;
+- [ ] сохранены окно, текст и показатели верхнего запроса, определены его
+      источник и назначение;
+- [ ] среди запросов открытых дашбордов найден тот, который прочитал больше
+      всего строк, и соответствующая панель;
+- [ ] объяснено, как журнал собирают с двух нод и какие записи учитывают для
+      счета запросов;
+- [ ] до наблюдения нарисован прогноз свежести событий и заказов, а форма
+      линии объяснена через метку последней доставки;
+- [ ] записаны несколько наблюдений, на наброске видны рост и сброс свежести
+      заказов, а доставка подтверждена в Airflow и на панели слепков;
+- [ ] модельная дата отделена от реального времени наблюдения;
+- [ ] объяснен выбор слоев для свежести, потока и доли брака, а также общее
+      окно числителя и знаменателя;
+- [ ] службы не остановлены, данные вручную не правились, стендовые дашборды
+      не изменены.

docs/labs/README.md

@@ -1,93 +1,97 @@
-# Учебные задания: витрины слоя DM и дашборд в Superset
+# Учебные задания
 
-Пять домашних заданий — про витрины слоя DM. Стенд привозит слой
+Программа состоит из двух частей: основная включает семь ступеней, которые вы
-наполовину: витрины трех сюжетов дашборда и контроль качества построены,
+проходите по порядку, а факультативы выбираете по желанию. Причины такого
-остальные витрины строит менти. Каждое из них — самостоятельное ТЗ: что за
+порядка и формы заданий описаны в [программе учебных лаб](../specs/2026-09-01-labs-program.md#2-устройство-программы-основная-программа-и-факультативы).
-витрина, какое у нее зерно, из чего она собирается и как проверить, что
-собралась верно.
 
-Шестое задание — необязательная лаба в Superset. В ней менти собирает свой
+## Основная программа
-дашборд поверх пяти витрин.
+
+| Ступень | Задание | Чему учит |
+|---|---|---|
+| 1 | Пять витрин слоя DM | построить результат для потребителя хранилища; уроки каждой витрины — в таблице ниже |
+| 2 | [Свой график в Superset](2-1-superset-chart.md) | превратить свой результат из хранилища в отчет в BI |
+| 3 | [Нарежь сессии сам](3-1-sessions-by-hand.md) | сверить число сессий в своей нарезке с эталоном и найти события, из-за которых оно расходится |
+| 4 | [Перепиши нарезку стенда](4-1-session-pipeline.md) | изменить расчетную сущность внутри готового конвейера и проверить ее внешним эталоном |
+| 5 | [Сначала сторож, потом ломай: заказы](5-1-order-checks.md)<br>[Перепишите разбор заказов в ODS](5-2-order-parsing.md)<br>[Перепишите сборку заказов в DDS](5-3-order-pipeline.md) | написать проверки качества до рискованного изменения, затем переписать разбор и сборку заказов |
+| 6 | [Разбери сырые события и сверь результат со стендом](6-1-event-parsing.md) | изучить разбор потока отдельно от живого приема и сверить его со стендовым результатом |
+| 7 | [Мониторинг: куда смотреть](7-1-monitoring.md) | выбрать, куда и на что смотреть в живой системе |
+
+## Ступень 1: пять витрин слоя DM
+
+Слой DM в стенде построен наполовину: витрины трех сюжетов дашборда и контроль
+качества уже построены, остальные пять витрин строите вы. Каждая из них —
+самостоятельное ТЗ: в нем есть состав витрины, зерно, источники и способ
+проверки.
+
+| № | Результат | Чему учит |
+|---|---|---|
+| 1 | [`events_enriched_v`](1-1-events-enriched.md) | строить слой как договор о данных, а не как их копию |
+| 2 | [`top_pages_daily`](1-2-top-pages-daily.md) | создавать материализованную витрину с дневной пересборкой в конвейере |
+| 3 | [`session_overview`](1-3-session-overview.md) | хранить слагаемые для расчета средних и долей |
+| 4 | [`dq_errors_daily`](1-4-dq-errors-daily.md) | считать брак по дню загрузки и хранить итоги дольше источника |
+| 5 | [`utm_effectiveness`](1-5-utm-effectiveness.md) | читать `declared_` как предупреждение о сумме со слов клиента |
 
 Общее устройство слоя — [дока DM](../architecture/dm.md). Она отвечает на
 вопросы «почему так», задание отвечает на вопрос «что сделать».
 
-## Порядок
+## Как принято на ступени 1
 
-Задания идут по нарастанию: каждое следующее опирается на то, что уже
+**Читать — через `_v`.** Физические `_rep` и `_dist` служат загрузке и
-усвоено.
+обслуживанию, а публичный договор DDS — `dds.event_v` или `dds.session_v` —
+остается прежним даже при изменении физических объектов. Чтение DDS
+напрямую делает задания независимыми: соседняя витрина может быть еще не
+построена.
+Исключение — задание 4: у таблиц брака публичного договора нет.
 
-| № | Результат | Чему учит |
+**Писать — в `_dist`.** Так строки распределяются по ключу шардирования. При
-|---|---|---|
+записи в локальную таблицу распределение зависит от узла, выполнившего
-| 1 | [`events_enriched_v`](events-enriched.md) | слой — это контракт, а не копия данных |
+запрос, и при следующем запуске может измениться. Подробности — раздел
-| 2 | [`top_pages_daily`](top-pages-daily.md) | зерно сменилось — витрина материализуется и встает в конвейер |
+«Раскладка по шардам» [справочника хранилища](../architecture/storage.md).
-| 3 | [`session_overview`](session-overview.md) | зерно решает, на какие вопросы витрина уже не ответит |
-| 4 | [`dq_errors_daily`](dq-errors-daily.md) | у брака свой день и свой срок жизни |
-| 5 | [`utm_effectiveness`](utm-effectiveness.md) | `declared_` в имени — предупреждение, а не украшение |
-| 6 | [Свой дашборд в Superset](superset-dashboard.md) — необязательная лаба | свои объекты BI живут отдельно от стендовых |
 
-## Общие правила
+**Форма — по зерну.** На стенде агрегат с новым зерном принято хранить
+готовым: потребитель читает его много раз без повторного расчета по
+источнику. Создайте `dm.<имя>_rep` / `_dist`, донор `dm.<имя>_stage_rep` /
+`_stage_dist` и публичное `dm.<имя>_v` с явным списком колонок. При прежнем
+зерне достаточно представления: таблица дублировала бы данные. Доводы —
+раздел «Таблица или представление» [справочника
+DM](../architecture/dm.md).
 
-Они одни для пяти заданий по витринам, поэтому записаны здесь, а не
+**Ключ шардирования — ваше решение.** Объясните, почему выбранный ключ не
-повторяются в каждом ТЗ.
+дает существенного перекоса и почему более сложный ничего не добавит.
+Объявите донор через `AS <цель>_rep` с ключом цели: иначе замена партиции
+потеряет строку на одном шарде и удвоит на другом. Детали — раздел
+«Раскладка по шардам» [справочника хранилища](../architecture/storage.md).
+Пример обоснования — `dm.revenue_daily_dist` в
+[`sql/ddl/55-dm-tables.sql`](../../sql/ddl/55-dm-tables.sql).
 
-**Читать — через `_v`.** Публичный договор сущности DDS — представление с
+**Где лежит код.** DDL заданий — в `sql/ddl/70-labs.sql`: он применяется
-суффиксом `_v`: `dds.event_v`, `dds.session_v`. Витрина называет только
+после стендовых, поэтому ваши объекты не мешаются со стендовыми. В
-его; физические `_rep` и `_dist` служат загрузке и обслуживанию. Соседнюю
+`sql/dm/<витрина>_scope.sql` определяются дни прогона, в `_rebuild.sql` они
-домашку витрина источником тоже не берет: витрина слоя DM читает договор
+собираются в донор, в `_replace.sql` заменяется партиция. Задачу сборки
-DDS, и задания остаются независимыми. Исключение одно и оно оговорено в
+добавьте в [`dags/dm_transform.py`](../../dags/dm_transform.py): без нее
-задании 4: у таблиц брака публичного договора нет.
+конвейер не обновит витрину. Представлению достаточно `CREATE VIEW`.
 
-**Писать — только в `_dist`.** При записи в локальную таблицу раскладку
+**Образец — витрина `revenue_daily`.** У нее есть пять объектов, донор,
-определяет то, какая нода случайно выполняла код, а не свойство данных.
+сборка, замена дневных партиций и задача в конвейере. Используйте ее как
-Правило и его следствия — [дока хранилища](../architecture/storage.md),
+образец всего порядка пересборки. Состав колонок берите из своего ТЗ, иначе
-«Раскладка по шардам».
+получите показатели другой витрины.
 
-**Форма — по зерну.** Витрина, меняющая зерно источника, материализуется:
+## Самопроверка ступени 1
-`dm.<имя>_rep` / `_dist`, донор `dm.<имя>_stage_rep` / `_stage_dist` и
-публичное `dm.<имя>_v` с явным списком колонок. Витрина, сохраняющая зерно,
-остается обычным представлением. Довод — [дока DM](../architecture/dm.md),
-«Форма: по зерну, не по цене запроса».
 
-**Ключ шардирования — твое решение.** Ни одно ТЗ ключа не называет.
+Даг `homework_check` запускается руками, расписания у него нет. Задача
-Правило выбора и требование к донору — [дока
-хранилища](../architecture/storage.md), «Раскладка по шардам»: донор
-объявляется через `AS <цель>_rep` и шардируется тем же ключом, что цель,
-иначе замена партиции потеряет строку на одном шарде и задвоит на другом.
-Названный ключ надо уметь защитить: почему он не дает перекоса и почему
-более сложный тут ничего не добавляет. Образец такой защиты —
-`dm.revenue_daily_dist` в [`sql/ddl/55-dm-tables.sql`](../../sql/ddl/55-dm-tables.sql).
-
-**Где лежит код.** DDL домашек — свой файл `sql/ddl/70-labs.sql`: он
-применяется после стендовых по порядку имени, и твои объекты не мешаются
-со стендовыми. У агрегатов рядом со стендовыми ложатся еще три запроса —
-`sql/dm/<витрина>_scope.sql` спрашивает у хранилища, какие дни пересобирает
-запуск, `_rebuild.sql` собирает их в донор, `_replace.sql` заменяет
-партицию, — и задача в
-[`dags/dm_transform.py`](../../dags/dm_transform.py). У разминочного
-представления нет ничего из этого: весь его код — одно `CREATE VIEW`.
-
-**Образец на все случаи** — витрина `revenue_daily`: у нее есть все пять
-объектов, донор, сборка, замена дневных партиций и задача в конвейере.
-Списывать с нее устройство можно и нужно; списывать состав колонок — нет,
-он у каждой витрины свой.
-
-## Самопроверка
-
-Даг `homework_check` запускается рукой, расписания у него нет. Задача
 витрины красная, пока витрины нет или счет не сходится, и зеленая, когда
-собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет:
+собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет: это
-это инструмент лабы, а не история качества стенда.
+инструмент лабы, а не история качества стенда.
 
 Проверка пяти заданий по витринам устроена одинаково и золотых констант не
 содержит: рядом с витриной независимым запросом собирается тот же ответ —
-прямо из источника витрины, минуя ее саму. У четырех заданий источник эталона
+прямо из источника витрины, минуя ее саму. У четырех заданий источник
-тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания 4 это
+эталона тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания
-таблицы брака ODS, потому что в DDS у брака представительства нет. Обе стороны
+4 это таблицы брака ODS, потому что в DDS нет сущности брака. Обе стороны
-соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число строк,
+соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число
-где стороны разошлись или одной стороны нет. Ноль — зеленый.
+строк, где стороны разошлись или одной стороны нет. Ноль — зеленый. Полное
-Полное соединение здесь обязательно: при обычном пропавший день или
+соединение сохраняет ключи обеих сторон: при внутреннем пропавший день или
-пропавший ключ просто не попал бы в результат и остался бы незамечен.
+ключ не попал бы в результат, и потеря осталась бы незамеченной.
 
 Раздел «Как проверить себя» каждого ТЗ по витрине называет деловой ключ и
 сравниваемые величины. Тот же прием в стендовом исполнении — [даг
@@ -95,11 +99,42 @@ DDS, и задания остаются независимыми. Исключе
 
 **Предупреждение.** Запросы самой проверки лежат в `sql/dq/` открыто, и
 имена называют витрину и роль сверки. Проверка на инвариантах неизбежно
-близка к ответу: чтобы сверить витрину, надо ее пересчитать. Прятать эти
+близка к ответу: чтобы сверить витрину, надо ее пересчитать. Если открыть
-файлы никто не станет — но открыв их до того, как задание сделано, ты
+эти файлы до выполнения задания, можно скопировать готовый SQL, не
-обменяешь урок на готовый SQL.
+разобравшись в расчете самостоятельно. Смотреть туда стоит после своей
-Смотреть туда стоит после своей сборки: сравнить два решения полезно,
+сборки: сравнить два решения полезно, списать одно — нет.
-списать одно — нет.
+
+## Факультативы
+
+Эти задания вы берете по желанию. Полный список сюжетов — в разделе
+[«Факультативы — пять разделов»](../specs/2026-09-01-labs-program.md#4-факультативы--пять-разделов)
+программы.
+
+### Почему выручка не сходится
+
+Открывается после ступени 1. Расхождения между источниками, повторы
+покупок и день, после которого отчет можно считать окончательным.
+
+### Тонкий анализ данных
+
+Открывается после ступени 1. Знание о пользователе на дату и обогащение
+отчета своим словарем.
+
+### Superset и BI
+
+Открывается после ступени 2. В задании
+[Свой дашборд в Superset](optional/superset-dashboard.md) вы собираете
+отдельный дашборд, не меняя объекты стенда.
+
+### Инженерия стенда
+
+Открывается после ступени 1. Прием и хранение данных, раскладка по шардам,
+повторная обработка дня и обновление витрин.
+
+### Что делать, когда стенд сломался
+
+Открывается после ступени 7. Поломки стенда и runbook по итогам
+расследований; весь раздел — повышенная сложность.
 
 ## Уборка
 

docs/labs/dq-errors-daily.md

@@ -1,118 +0,0 @@
-# Задание 4: `dm.dq_errors_daily`
-
-**Чему учит:** у брака свой день и свой срок жизни. Витрина качества живет
-по времени загрузки, а не по модельному дню, и переживает собственный
-источник — поэтому «пересобрать все» здесь означает «стереть историю».
-
-## Роль витрины
-
-Сводка приемки: сколько строк за день не прошли разбор и по какой причине.
-Читают ее, когда качество потока просело: сначала смотрят, вырос ли класс
-брака, потом идут за сырым текстом в саму таблицу ошибок.
-
-Витрина отвечает на вопрос «сколько и чего», а не «что именно сломалось».
-Разбирательство с конкретной строкой начинается в `ods.event_errors_dist` и
-`ods.order_errors_dist`, где рядом с классом лежат сырой текст и координаты
-доставки.
-
-## Источник: единственное исключение из правила `_v`
-
-Общее правило домашек — читать через публичный договор `_v`. У таблиц брака
-такого договора нет, и заводить его ради этой витрины не надо: брак — не
-сущность бизнес-модели, а диагностика слоя приема. Читать нужно
-распределенные таблицы напрямую:
-
-- `ods.event_errors_dist` — брак разбора событий;
-- `ods.order_errors_dist` — брак разбора слепка заказов.
-
-Именно `_dist`, а не `_rep`: локальная таблица вернет строки одного шарда, и
-витрина тихо покажет половину брака. Ошибки при этом не будет — ошибка
-появится позже, когда по витрине примут решение.
-
-## Зерно и форма
-
-Зерно — **день загрузки × источник × класс брака**. Зерно источника —
-строка брака, значит зерно сменилось и витрина материализуется:
-`dm.dq_errors_daily_rep` / `_dist`, донор `_stage_rep` / `_stage_dist`,
-публичное `dm.dq_errors_daily_v`. Ключ партиции — день загрузки.
-
-День здесь — `toDate(_load_ts)`, то есть настоящее время, когда строка
-приехала в хранилище, а не модельный день мира. Модельного дня у брака нет
-и быть не может: он живет в содержимом, а содержимое как раз и не
-разобралось.
-
-## Состав колонок
-
-| Колонка | Тип | Что это |
-|---|---|---|
-| `load_date` | `Date` | день загрузки, в который приехал брак |
-| `source` | `LowCardinality(String)` | `event` или `order` |
-| `error_class` | `LowCardinality(String)` | класс брака из таблицы ошибок |
-| `error_rows` | `UInt64` | число забракованных строк |
-| `_load_id` | `String` | запуск, собравший день |
-| `_load_ts` | `DateTime64(3, 'UTC')` | когда собран |
-
-Две похожие колонки рядом различаются намеренно: `load_date` — про день,
-когда приехал брак, `_load_ts` — про запуск, который собрал витрину. Первая
-деловая, вторая служебная, и совпадать они не обязаны.
-
-Классы у двух источников свои и не пересекаются по смыслу, поэтому колонка
-`source` в зерне обязательна: без нее одинаковое имя класса у событий и у
-заказов слилось бы в одну строку.
-
-## Ритм пересборки: витрина переживает источник
-
-Таблицы брака живут месяц (`TTL`), сырье — трое суток. Витрина живет без
-срока: сводка «сколько брака было в марте» нужна и после того, как сами
-строки марта удалены.
-
-Отсюда правило прогона: пересобираются **только те дни загрузки, которые
-еще есть в источнике**. Спроси у источника список живых дней и замени
-партиции ровно этих дней. Соблазн «собрать все заново в донор и подменить
-таблицу целиком» здесь стоит дороже обычного: истекшие по `TTL` дни исчезли
-бы из витрины навсегда, а вместе с ними — единственная оставшаяся память о
-них.
-
-Текущий день загрузки не замерзает до конца суток: поток событий идет, и
-брак в него еще добавится. Это нормально, день просто пересоберется на
-следующем прогоне.
-
-## Ключ шардирования
-
-Твое решение по [правилу донора](../architecture/storage.md), «Раскладка по
-шардам». Витрина крошечная: классов брака у событий и заказов вместе меньше
-десятка. Учти это в защите ключа — иногда правильный ответ звучит как
-«перекос здесь ничего не стоит, и вот почему».
-
-## Как проверить себя
-
-Деловой ключ — пара `source` и `error_class` внутри `load_date`. Область
-проверки — дни загрузки, которые еще живы хотя бы в одной таблице ошибок:
-день за границей `TTL` сверять не с чем, и его отсутствие в источнике не
-ошибка.
-
-Собери прямой счет по обеим таблицам ошибок, соедини с
-`dm.dq_errors_daily_v` полным внешним соединением по ключу и посчитай
-строки, где ключа нет с одной из сторон или где расходится `error_rows`.
-Ноль — зеленый.
-
-Отдельно: сумма `error_rows` по живым дням равна общему числу строк в
-`ods.event_errors_dist` плюс `ods.order_errors_dist`. Если эта сумма вышла
-примерно вдвое меньше — витрина почти наверняка собрана с `_rep` вместо
-`_dist` и видит один шард из двух.
-
-**Пустая витрина — верный ответ.** На чистом стенде брака нет, обе стороны
-пусты, расхождений ноль, задача зеленая. Проверка, которая требует хотя бы
-одной строки, на здоровом стенде краснела бы всегда и приучала бы себя
-игнорировать.
-
-## Приемка
-
-- [ ] пять объектов витрины созданы, донор объявлен через `AS` и шардируется
-      ключом цели;
-- [ ] источники — `_dist`-таблицы обоих видов брака;
-- [ ] прогон заменяет партиции только живых дней источника и не трогает
-      истекшие;
-- [ ] задача `dq_errors_daily` в `homework_check` зеленая — в том числе на
-      чистом стенде, где брака нет;
-- [ ] задача витрины добавлена в `dm_transform`.

docs/labs/events-enriched.md

@@ -1,114 +0,0 @@
-# Задание 1: `dm.events_enriched_v`
-
-**Чему учит:** слой — это контракт, а не копия данных. Витрина, которая не
-меняет зерно источника, остается представлением, и копии событий ради
-других имен колонок не заводит ни один боевой склад.
-
-Это разминка. Строк она не хранит, в конвейер не встает, ключа шардирования
-у нее нет. Задача одна: собрать плоское событие для BI и не поддаться
-соблазну разложить его на диск.
-
-## Роль витрины
-
-Договор события в DDS широкий — 44 колонки, почти весь формат выгрузки:
-часть из них технические координаты источника, часть — параллельные массивы
-товаров. Аналитику в Superset нужен плоский набор деловых полей и пара
-производных, которые иначе каждый пишет заново в каждом запросе.
-
-Витрина отвечает на вопрос «что вообще происходило»: с нее начинают, когда
-надо посмотреть на события глазами человека, а не разбирать широкую строку
-источника.
-
-Источником для витрин следующих заданий она не служит. Витрина слоя DM
-читает публичный договор DDS — так устроены и стендовые витрины, и потому
-задания независимы: соседнюю домашку можно делать первой, а можно не делать
-вовсе.
-
-## Зерно и форма
-
-Зерно — **событие**: одна строка витрины равна одной строке `dds.event_v`.
-Зерно источника сохранено, значит форма — обычное представление
-`CREATE VIEW dm.events_enriched_v`, без физической таблицы, без донора и
-без задачи в `dm_transform`. Пересобирать нечего.
-
-Источник — `dds.event_v`, и только он.
-
-## Состав колонок
-
-Явный список обязателен: договор не должен расширяться сам, когда в
-источник добавят колонку.
-
-**Время и посетитель:** `event_date`, `event_time`, `event_hour`,
-`client_id`, `event_id`.
-
-**Действие:** `event_type` (`pageview`, `add_to_cart`, `purchase`), `url`,
-`page_path`, `referer`, `referer_host`, `title`.
-
-**Атрибуция:** `utm_source`, `utm_medium`, `utm_campaign`, `utm_content`,
-`utm_term`.
-
-**Паспорт визита:** `device_category`, `browser`, `operating_system`,
-`region_country`, `region_city`.
-
-**Торговый блок, массивами как в источнике:** `product_id`, `product_name`,
-`product_category`, `product_price`, `product_quantity`,
-`product_event_type`, `purchase_id`, `purchase_revenue`, `purchase_coupon`.
-
-Три колонки в источнике не лежат и считаются здесь:
-
-| Колонка | Как считается | Зачем |
-|---|---|---|
-| `event_hour` | `toHour(event_time)` | суточный профиль спрашивают в каждом отчете |
-| `page_path` | путь `url` без домена и параметров | группировка по странице без разбора строки в каждом запросе |
-| `referer_host` | домен `referer` | «откуда пришли» одним значением, а не полным адресом |
-
-Служебных `_load_id` и `_load_ts` у витрины нет, и это не забывчивость. Их
-нет и у `dds.event_v`: событие в DDS не грузят, а читают из ODS, поэтому
-координат собственной загрузки у него не бывает. Служебная колонка называет
-запуск, который положил строку на диск, — здесь на диск никто ничего не
-кладет.
-
-## Ловушка задания
-
-Массивы `product_*` тянет развернуть через `ARRAY JOIN` — так плоская
-таблица становится по-настоящему плоской. Разворачивать нельзя, и вреда
-здесь два.
-
-Очевидный: у события с тремя позициями получилось бы три строки, зерно
-витрины перестало бы совпадать с зерном источника, а вместе с ним развалилось
-бы и правило формы — такую витрину уже пришлось бы материализовать.
-
-Неочевидный и куда более разрушительный: `ARRAY JOIN` — соединение
-внутреннее, и строку с пустым массивом он выбрасывает. Торговый блок пуст у
-всех событий, кроме корзин и покупок, то есть у подавляющего большинства.
-Так «плоская таблица событий» превращается в таблицу товарных позиций и
-теряет девятнадцать строк из двадцати — а по имени и по составу колонок она
-по-прежнему выглядит таблицей событий. Ошибка не падает и ничего не
-подсвечивает.
-
-Массивы едут в договор как есть; разворачивает их тот, кому нужна позиция
-заказа, — и делает это уже в своей витрине, с другим зерном и другим именем.
-
-## Как проверить себя
-
-Деловой ключ — `event_id` внутри дня. Собери прямой ответ из `dds.event_v`
-за тот же день, соедини с витриной полным внешним соединением и посчитай
-строки, где ключа нет с одной из сторон или где различаются значения
-деловых колонок. Ноль — зеленый.
-
-Отдельно проверяются три производные колонки: `event_hour`, `page_path` и
-`referer_host` должны совпасть с тем же выражением, посчитанным по
-`dds.event_v` на лету.
-
-Если строк в витрине оказалось в разы меньше, чем в источнике, а остались в
-ней одни корзины и покупки — это развернутые массивы: `ARRAY JOIN` выбросил
-все события с пустым торговым блоком.
-
-## Приемка
-
-- [ ] `dm.events_enriched_v` создано, физических таблиц под ним нет;
-- [ ] список колонок в представлении явный;
-- [ ] число строк и набор `event_id` совпадают с `dds.event_v` за каждый
-      прожитый день;
-- [ ] задача `events_enriched` в `homework_check` зеленая;
-- [ ] задачи в `dm_transform` **нет** — и не должно быть.

docs/labs/optional/superset-dashboard.md

@@ -1,39 +1,39 @@
-# Задание 6 (необязательное): свой дашборд в Superset
+# Свой дашборд в Superset
 
 **Чему учит:** довести свои витрины до потребителя — завести в Superset
 датасеты поверх публичных представлений, подобрать графики под вопросы и
 собрать из них один связный экран.
 
-Эта лаба идет после заданий 1–5 и опирается на их результат. Ее можно
+Это факультатив раздела «Superset и BI». Его можно пройти после ступени 2,
-пропустить: основной предмет стенда — ClickHouse, а здесь вся работа — в
+когда готовы витрины ступени 1.
-интерфейсе BI.
 
 ## Роль дашборда
 
-Собери обзор трафика и поведения посетителей. Он должен отвечать на три
+Соберите обзор трафика и поведения посетителей. Он должен отвечать на три
 вопроса: что происходило в магазине, какие страницы, устройства и рекламные
 каналы дали результат, были ли ошибки приема данных.
 
 Стендовый дашборд «Бизнес-сюжеты» собран из готовых витрин. Свой дашборд
-собери из пяти витрин, которые ты построил в заданиях. Копировать раскладку
+соберите из пяти витрин, которые вы построили в заданиях. Копировать раскладку
-стендового дашборда не нужно: выбери форму, в которой ответы читаются без
+стендового дашборда не нужно: выберите форму, в которой ответы читаются без
 пояснений рядом с экраном.
 
 ## Свои объекты — отдельно
 
-Не добавляй графики в стендовый дашборд и не правь его датасеты. При
+Не добавляйте графики в стендовый дашборд и не правьте его датасеты. При
 инициализации Superset импорт с `--overwrite` заменит ручные правки стендовых
 объектов файлами из репозитория. `make up` свой дашборд не стирает; срок жизни
-таких объектов описан в [доке Superset](../architecture/superset.md), «Импорт
+таких объектов описан в [доке Superset](../../architecture/superset.md), «Импорт
 при каждой инициализации».
 
-Заведи отдельные датасеты и графики, собери из них свой дашборд. Назови его,
+Заведите отдельные датасеты и графики, соберите из них свой дашборд.
-например, «Мои витрины DM». Это то же правило, по которому DDL домашек лежит
+Назовите его, например, «Мои витрины DM». Это то же правило, по которому DDL
-в `sql/ddl/70-labs.sql`: стенд привозит свои объекты, менти создает свои.
+домашек лежит в `sql/ddl/70-labs.sql`: стендовые объекты уже есть, свои
+создаете вы.
 
 ## Датасеты
 
-Заведи в подключении `ClickHouse` пять физических датасетов схемы `dm`:
+Заведите в подключении `ClickHouse` пять физических датасетов схемы `dm`:
 
 - `events_enriched_v`;
 - `top_pages_daily_v`;
@@ -44,7 +44,7 @@
 ## Состав дашборда
 
 Каждая из пяти витрин должна появиться хотя бы в одном графике. Точный тип
-графика выбери сам. На дашборде покажи следующее:
+графика выберите сами. На дашборде покажите следующее:
 
 | Витрина | Что показать |
 |---|---|
@@ -54,7 +54,7 @@
 | `dq_errors_daily_v` | число ошибок по дню загрузки, источнику и классу |
 | `utm_effectiveness_v` | трафик, покупки и заявленную выручку по рекламным каналам |
 
-Для долей используй слагаемые из витрин. Например, доля отказов считается
+Для долей используйте слагаемые из витрин. Например, доля отказов считается
 как сумма `bounce_sessions`, деленная на сумму `sessions`. Среднее по готовым
 долям для такого графика не подходит — урок задания 3 остается в силе.
 
@@ -65,19 +65,20 @@
 Эта лаба проверяется глазами. У расположения панелей и понятных подписей нет
 счетного инварианта, поэтому задачи для нее в `homework_check` нет.
 
-Открой список дашбордов и проверь:
+Откройте список дашбордов и проверьте:
 
 - «Бизнес-сюжеты» остался отдельным стендовым дашбордом;
-- твой дашборд открывается без ошибок и содержит график от каждого из пяти
+- ваш дашборд открывается без ошибок и содержит график от каждого из пяти
   датасетов;
 - подписи, единицы измерения и легенды читаются без обращения к SQL;
 - прямой трафик не исчез из графика UTM, а заявленная выручка не выдана за
   серверную;
 - пустой график ошибок нормален, если в таблицах брака сейчас нет строк.
 
-Последний проход сделай как читатель: найди на экране самый заметный канал,
+Последний проход сделайте как читатель: найдите на экране самый заметный
-страницу и устройство, затем проверь, понятно ли из подписей, что именно
+канал, страницу и устройство, затем проверьте, понятно ли из подписей, что
-сравнивается. Если ответ приходится угадывать, поправь график или его название.
+именно сравнивается. Если ответ приходится угадывать, поправьте график или
+его название.
 
 ## Приемка
 

docs/labs/session-overview.md

@@ -1,121 +0,0 @@
-# Задание 3: `dm.session_overview`
-
-**Чему учит:** агрегат хранит слагаемые, а не готовые средние и доли.
-Среднее по строкам витрины не складывается никогда, а уникальных нельзя
-складывать даже тогда, когда на сегодняшних данных сумма сходится.
-
-## Роль витрины
-
-Дневной портрет визитов в разрезе устройств: сколько было сессий, какие они
-были длинные, сколько страниц смотрели и как часто доходили до покупки.
-Вопрос витрины — «как люди ходят по магазину с телефона и с настольного
-компьютера, и чем эти визиты отличаются».
-
-Сессия на стенде — расчетная сущность, ее уже нарезал слой DDS. Собирать
-визиты заново из событий не нужно и нельзя: это была бы вторая нарезка,
-которая тихо разойдется с первой.
-
-Витрина с таким именем была и на прошлом стенде, но зерно у нее сменилось,
-и сменилось не по вкусу. Там визитов как сущности не было, и витрина
-нарезала их сама, строкой на визит. Здесь визит — сущность слоя DDS, и
-витрина, повторяющая его зерно, оказалась бы обычным представлением по
-[правилу формы](../architecture/dm.md): копией сессий с другими именами
-колонок. Чтобы задание осталось про дневной агрегат, витрина поднялась на
-зерно выше — до дня и среза.
-
-## Зерно и форма
-
-Зерно — **день сессии × категория устройства**. Источник —
-`dds.session_v`, у него зерно визита, значит зерно сменилось и витрина
-материализуется: `dm.session_overview_rep` / `_dist`, донор `_stage_rep` /
-`_stage_dist`, публичное `dm.session_overview_v`. Ключ партиции — день.
-
-Категория устройства взята из сессии как есть: у куки она постоянна, и слой
-DDS уже перевел код источника в слово. Словарь расшифровки шире, чем мир
-стенда: слов в нем четыре, а встречаются три — `desktop`, `mobile` и
-`tablet`. Строку под `tv` заводить незачем, она возникнет сама, если такие
-визиты появятся.
-
-## Состав колонок
-
-| Колонка | Тип | Что это |
-|---|---|---|
-| `report_date` | `Date` | день сессии |
-| `device_category` | `LowCardinality(String)` | категория устройства |
-| `sessions` | `UInt64` | число визитов |
-| `visitors` | `UInt64` | число разных `client_id` |
-| `bounce_sessions` | `UInt64` | визиты ровно из одного события |
-| `purchase_sessions` | `UInt64` | визиты, в которых была хотя бы одна покупка |
-| `duration_seconds_total` | `UInt64` | суммарная длительность визитов |
-| `events_total` | `UInt64` | событий во всех визитах |
-| `pageviews` | `UInt64` | просмотров страниц |
-| `cart_adds` | `UInt64` | добавлений в корзину |
-| `purchases` | `UInt64` | покупок |
-| `_load_id` | `String` | запуск, собравший день |
-| `_load_ts` | `DateTime64(3, 'UTC')` | когда собран |
-
-Средней длительности и доли отказов в витрине нет намеренно. Хранить
-`avg_duration_seconds` было бы удобнее ровно один раз — пока смотрят одну
-строку. Тот, кто захочет среднее по дню целиком, сложит средние по трем
-устройствам и получит неправду: средние не складываются, они взвешиваются.
-Пара «`duration_seconds_total` и `sessions`» дает верный ответ на любом
-срезе, а деление стоит потребителю один вызов. То же и с долей отказов:
-храним `bounce_sessions` и `sessions`, долю считает тот, кто спрашивает.
-
-С `visitors` история тоньше, и в ней главная ловушка задания. Складывать
-уникальных по строкам нельзя: один и тот же посетитель, попавший в две
-строки, будет посчитан дважды. Проверь на стенде — и увидишь, что сумма
-`visitors` по устройствам за день **сходится** с `dm.daily_traffic_v`.
-
-Это не отменяет правила, а показывает, откуда берется совпадение: в мире
-стенда устройство приписано куке на всю жизнь ([словарь
-понятий](../../CONTEXT.md), «Паспорт куки»), поэтому одна кука лежит ровно
-в одной строке дня, и пересекаться строкам не в чем.
-
-Совпадение это — свойство мира, а не свойство витрины. Появятся визиты
-одной куки с двух устройств — сумма поедет, и ни одна проверка об этом не
-скажет: отчет просто начнет тихо завышать аудиторию. Отсюда правило,
-которое стоит унести с задания: складывать уникальных нельзя даже там, где
-сегодня получается. Число посетителей дня спрашивают у
-`dm.daily_traffic_v`, где оно посчитано на своем зерне.
-
-## Ритм пересборки
-
-Источник — сессии: день замерзает, как только прожит. Объем прогона тот же,
-что в задании 2, — хвост от первого несобранного прожитого дня; механика та
-же: донор и замена дневных партиций.
-
-## Ключ шардирования
-
-Твое решение по [правилу донора](../architecture/storage.md), «Раскладка по
-шардам». Здесь у измерения всего три встречающихся значения, и распределены
-они неровно: планшеты — тонкая полоса, а телефоны и настольные машины держат
-основную массу. Прежде чем брать хеш от одного `device_category`, посчитай,
-сколько строк ляжет на каждый шард, и назови, чем тебя устраивает результат.
-
-## Как проверить себя
-
-Деловой ключ — `device_category` внутри дня. Собери прямой агрегат из
-`dds.session_v` за день, соедини с `dm.session_overview_v` полным внешним
-соединением и посчитай строки, где ключа нет с одной из сторон или где
-расходится любой счетчик. Ноль — зеленый.
-
-Две проверки покрупнее ловят грубую ошибку сразу:
-
-- сумма `sessions` за день равна числу строк `dds.session_v` этого дня:
-  ни один визит не потерян и ни один не задвоен;
-- сумма `events_total` за день равна сумме `events_total` по сессиям того
-  же дня.
-
-Если суммы событий сходятся, а сумма сессий больше числа визитов — почти
-наверняка витрина собрана из событий, а не из сессий.
-
-## Приемка
-
-- [ ] пять объектов витрины созданы, донор объявлен через `AS` и шардируется
-      ключом цели;
-- [ ] `dm.session_overview_v` перечисляет колонки явно;
-- [ ] источник витрины — `dds.session_v`, своей нарезки визитов в ней нет;
-- [ ] средних и долей в физической таблице нет;
-- [ ] задача `session_overview` в `homework_check` зеленая;
-- [ ] задача витрины добавлена в `dm_transform`.

docs/labs/top-pages-daily.md

@@ -1,114 +0,0 @@
-# Задание 2: `dm.top_pages_daily`
-
-**Чему учит:** зерно сменилось — значит витрина материализуется, живет
-дневными партициями и встает в конвейер. Первая настоящая витрина: пять
-объектов, донор, замена партиции, задача в `dm_transform`.
-
-## Роль витрины
-
-Популярность страниц по дням: сколько раз страницу открыли, сколько разных
-посетителей ее видели и что на ней делали кроме просмотра.
-
-Торговое событие садится на ту страницу, где случилось: корзина — на
-карточку товара, покупка — на страницу подтверждения заказа. Поэтому у
-карточки товара рядом стоят просмотры и корзины, и их отношение —
-конверсия карточки — главный вопрос к этой витрине: какие товары кладут в
-корзину, едва открыв, а какие смотрят и уходят.
-
-Воронки «просмотр → корзина → покупка» здесь нет и быть не может: корзина и
-покупка живут на разных страницах, и связать их шаги в одну цепочку на
-зерне страницы не из чего. Путь одного человека собирают из событий или из
-сессий, а витрина страниц отвечает про страницу.
-
-## Зерно и форма
-
-Зерно — **день события × страница**. Источник — события, у него зерно
-события, значит зерно сменилось и витрина материализуется:
-`dm.top_pages_daily_rep` / `_dist`, донор `_stage_rep` / `_stage_dist`,
-публичное `dm.top_pages_daily_v`.
-
-Страница — это `page_path`, путь `url` без домена и параметров запроса;
-считается он здесь же, из колонки `url` источника. Полный адрес в зерно не
-берется: с параметрами запроса одна и та же страница рассыпалась бы на
-сотни строк, и витрина перестала бы отвечать на свой вопрос.
-
-Ключ партиции — день: он же единица пересборки.
-
-Источник — `dds.event_v`, публичный договор события. Витрина задания 1
-источником не служит: витрина слоя DM читает договор DDS, как и стендовые
-витрины, и не зависит от того, выполнена ли соседняя домашка.
-
-## Состав колонок
-
-| Колонка | Тип | Что это |
-|---|---|---|
-| `report_date` | `Date` | день события |
-| `page_path` | `LowCardinality(String)` | путь страницы |
-| `pageviews` | `UInt64` | число событий `pageview` на странице |
-| `visitors` | `UInt64` | число разных `client_id` на странице |
-| `cart_adds` | `UInt64` | число событий `add_to_cart` на странице |
-| `purchases` | `UInt64` | число событий `purchase` на странице |
-| `_load_id` | `String` | запуск, собравший день |
-| `_load_ts` | `DateTime64(3, 'UTC')` | когда собран |
-
-Счетчики условные: строку дают все три типа событий, а различает их
-`countIf`. Отфильтровать источник по `event_type = 'pageview'`, как
-подсказывает имя витрины, — значит получить витрину из одних просмотров:
-страницы останутся на месте, а `cart_adds` и `purchases` у всех строк
-обнулятся. Ошибка тихая: витрина выглядит собранной, и главный ее вопрос —
-конверсия карточки — молча отвечает «ноль везде».
-
-## Ритм пересборки
-
-Источник — события: день замерзает сразу, как только прожит. Значит
-пересобирать нужно только то, что еще не собрано: хвост дней, которых в
-витрине нет, — от первого несобранного прожитого дня до последнего
-прожитого. Готовые дни трогать незачем, а вот дыру, оставленную частичным
-отказом, объем прогона обязан подобрать: ищи не последний собранный день, а
-первый несобранный.
-
-Механика — сборка отрезка в донор одной вставкой и замена дневных партиций
-по одной, как у `revenue_daily`.
-
-## Ключ шардирования
-
-Твое решение по [правилу донора](../architecture/storage.md), «Раскладка по
-шардам». Подумай, чем эта витрина отличается от `revenue_daily`: там кроме
-дня было одно измерение из шести близких по объему значений, здесь —
-страницы, которых много и которые по популярности очень неровные.
-
-## Как проверить себя
-
-Деловой ключ — `page_path` внутри дня. Собери прямой агрегат из
-`dds.event_v` за день, соедини с `dm.top_pages_daily_v` полным внешним
-соединением по ключу и посчитай строки, где ключа нет с одной из сторон или
-где расходится любой из четырех счетчиков. Ноль — зеленый.
-
-Две проверки попроще, ими удобно ловить грубую ошибку до полного
-соединения:
-
-- сумма `pageviews` за день равна числу событий `pageview` этого дня в
-  `dds.event_v`;
-- сумма `purchases` за день равна числу событий `purchase` этого дня.
-
-Проверки ловят разное. Фильтр `WHERE event_type = 'pageview'` первая из них
-пропускает: отбор строк по типу не меняет счет событий того же типа.
-Расхождение покажет только вторая — вместе с `cart_adds` обнулятся и
-`purchases`. Проверку выбирают по тому, умеет ли она покраснеть на твоей
-ошибке, а не по тому, как быстро она пишется: [проверка, которая не умеет
-краснеть, бесполезна](../architecture/testing.md).
-
-`visitors` складывать по строкам нельзя: один посетитель ходит по разным
-страницам и в сумме посчитается несколько раз. Число посетителей дня
-спрашивают у `dm.daily_traffic_v`, а не у этой витрины.
-
-## Приемка
-
-- [ ] пять объектов витрины созданы, донор объявлен через `AS` и шардируется
-      ключом цели;
-- [ ] `dm.top_pages_daily_v` перечисляет колонки явно, включая `_load_id` и
-      `_load_ts`;
-- [ ] объем прогона выводится из состояния витрины, а не задается руками;
-- [ ] задача `top_pages_daily` в `homework_check` зеленая;
-- [ ] задача витрины добавлена в `dm_transform`, повторный прогон конвейера
-      результат не меняет.

docs/labs/utm-effectiveness.md

@@ -1,150 +0,0 @@
-# Задание 5: `dm.utm_effectiveness`
-
-**Чему учит:** приставка `declared_` в имени колонки — предупреждение, а не
-украшение. Она говорит: это заявка клиента, а не деньги отчетности. Урок
-здесь дает конфликт: суммы не сойдутся, и раскапывать почему предстоит
-самому.
-
-Правило стенда: **поведение и атрибуцию считаем по трекеру, деньги — по
-бэкенду**. Эта витрина — единственное разрешенное исключение: атрибуции по
-UTM у бэкенда нет, метки живут только в кликстриме. Раз считать иначе
-нечем, клиентская сумма берется, но называется своим именем.
-
-## Роль витрины
-
-Эффективность рекламных каналов по дням: сколько трафика привел канал,
-сколько корзин и покупок в нем случилось и на какую сумму эти покупки, по
-словам клиента.
-
-## Атрибуция: по событию, а не по визиту
-
-Метки едут на каждом событии, и витрина группирует события по их
-собственным меткам. Модели «первое касание» или «последнее касание» здесь
-нет: их построение — отдельная тема, а это витрина трафика по меткам.
-
-`dds.session_v` при этом несет UTM первого события визита, и ответ «какой
-канал привел» из сессии и из этой витрины будет разным. Это не
-ошибка ни одной из сторон — это два разных вопроса, и в отчете их надо
-различать.
-
-## Прямой трафик из витрины не выбрасывается
-
-Соблазн отфильтровать строки без меток велик: витрина же про рекламу.
-Отфильтровать нельзя по двум причинам. Первая деловая: прямой трафик —
-обычно самый крупный «канал» магазина, и отчет, где его нет, врет о доле
-рекламы. Вторая техническая: как только часть событий выпала, итог витрины
-перестал сходиться с итогом источника, и проверить сборку стало нечем.
-
-Пустые метки остаются пустыми строками, как в источнике. Своего слова для
-«прямого захода» витрина не изобретает: чем меньше выдуманных значений, тем
-меньше расшифровывать читателю.
-
-## Зерно и форма
-
-Зерно — **день события × `utm_source` × `utm_medium` × `utm_campaign`**.
-Зерно источника — событие, значит витрина материализуется:
-`dm.utm_effectiveness_rep` / `_dist`, донор `_stage_rep` / `_stage_dist`,
-публичное `dm.utm_effectiveness_v`. Ключ партиции — день.
-
-Источник — `dds.event_v`, публичный договор события: витрина слоя DM читает
-договор DDS, а не соседнюю витрину.
-
-## Состав колонок
-
-| Колонка | Тип | Что это |
-|---|---|---|
-| `report_date` | `Date` | день события |
-| `utm_source` | `LowCardinality(String)` | источник кампании |
-| `utm_medium` | `LowCardinality(String)` | канал кампании |
-| `utm_campaign` | `String` | имя кампании |
-| `visitors` | `UInt64` | число разных `client_id` |
-| `pageviews` | `UInt64` | просмотров страниц |
-| `add_to_carts` | `UInt64` | добавлений в корзину |
-| `purchases` | `UInt64` | покупок |
-| `declared_revenue` | `Decimal(18, 2)` | выручка покупок глазами клиента |
-| `_load_id` | `String` | запуск, собравший день |
-| `_load_ts` | `DateTime64(3, 'UTC')` | когда собран |
-
-`declared_revenue` складывает `purchase_revenue[1]` событий `purchase`.
-Индекс не описка: блок `purchase*` едет параллельными массивами, и у события
-покупки в них ровно один элемент — контракт источника обещает один номер
-заказа и одну объявленную сумму на событие. Тем же индексом берет свою
-сторону стендовая сверка `purchase_vs_orders`.
-
-Приводить тип не нужно: в договоре `purchase_revenue` уже
-`Array(Decimal(18, 2))`. `Float64` эта сумма была только в выгрузке
-источника, и ODS перевел ее в точные деньги на приеме — сложение Decimal
-точное, и где стоит `CAST`, до или после `sum`, на результат не влияет.
-Витрина просто хранит то, что сложила, в `Decimal(18, 2)`.
-
-`utm_campaign` оставлена обычной строкой: имен кампаний со временем
-становится много, и словарь `LowCardinality` на растущем множестве
-перестает окупаться.
-
-## Ритм пересборки
-
-Источник — события: день замерзает сразу. Объем прогона и механика те же,
-что в задании 2: хвост несобранных дней, донор, замена дневных партиций.
-
-## Ключ шардирования
-
-Твое решение по [правилу донора](../architecture/storage.md), «Раскладка по
-шардам». Зерно здесь составное, из трех колонок, и решение «взять хеш от
-одной из них» надо защищать отдельно: назови, какая доля строк придется на
-самое частое значение выбранной колонки.
-
-## Конфликт, ради которого витрина и написана
-
-Собери за один и тот же день две суммы: `sum(declared_revenue)` из своей
-витрины и `sum(revenue)` из `dm.revenue_daily_v`. Они не сойдутся, и это
-верное поведение обеих витрин.
-
-Базы у двух сумм при этом сравнимые: `revenue_daily` складывает цену позиций
-на количество и ни скидки, ни доставки в себя не берет — ровно то, что видит
-клиент. Значит все расхождение до копейки объясняется тем, что случилось с
-заказом, а не тем, как считали деньги. Ищи ответы среди таких причин:
-
-- отмененный заказ из кликстрима никуда не девается: событие покупки
-  случилось, а `revenue_daily` считает только оплаченные;
-- событие покупки может потеряться по дороге, а заказ при этом доехать —
-  и наоборот, событие приехать дважды;
-- клиент назвал сумму, отличную от серверной суммы позиций: генератор
-  делает это намеренно у одного-двух заказов из ста.
-
-Как эти же расхождения выглядят на зерне заказа, показывает стендовая
-витрина `dm.purchase_vs_orders_v` с ее классами расхождений: это готовый
-ответ на вопрос «а сколько именно и из-за чего». Запиши свой вывод —
-в двух-трех фразах, своими словами.
-
-Проверять сходимость этих двух сумм не нужно и нельзя: они и не должны
-сходиться.
-
-## Как проверить себя
-
-Деловой ключ — тройка `utm_source`, `utm_medium`, `utm_campaign` внутри
-дня. Собери прямой агрегат из `dds.event_v` за день, соедини с
-`dm.utm_effectiveness_v` полным внешним соединением и посчитай строки, где
-ключа нет с одной из сторон или где расходится любая из пяти величин. Ноль —
-зеленый.
-
-Две проверки покрупнее ловят самые частые ошибки:
-
-- сумма `pageviews`, `add_to_carts` и `purchases` за день равна числу
-  событий соответствующего типа в `dds.event_v` за тот же день;
-- сумма `declared_revenue` за день равна сумме `purchase_revenue[1]` по всем
-  событиям `purchase` этого дня.
-
-Обе не сойдутся, если прямой трафик отфильтрован, и разойдутся ровно на его
-долю — по этому следу отфильтрованные строки и находят. `visitors`, как и в
-задании 3, по строкам не складывается: один посетитель приходит по разным
-меткам.
-
-## Приемка
-
-- [ ] пять объектов витрины созданы, донор объявлен через `AS` и шардируется
-      ключом цели;
-- [ ] строки без UTM-меток в витрине остались;
-- [ ] `declared_revenue` хранится в `Decimal(18, 2)`;
-- [ ] расхождение с `dm.revenue_daily_v` объяснено письменно;
-- [ ] задача `utm_effectiveness` в `homework_check` зеленая;
-- [ ] задача витрины добавлена в `dm_transform`.

docs/research/2026-08-31-labs-inventory.md

@@ -116,7 +116,7 @@
 
 **17. Свой дашборд в Superset (готовая необязательная лаба).**  
 Урок: пользовательские объекты BI хранятся отдельно от стендовых и переживают перезапуск. Стендовые объекты при импорте перезаписываются.  
-Материал: `docs/labs/superset-dashboard.md`, `docs/architecture/superset.md`.  
+Материал: `docs/labs/optional/superset-dashboard.md`, `docs/architecture/superset.md`.\
 Форма: построить свое.  
 Проверка: глазами — счетного инварианта у раскладки панелей нет.
 
@@ -276,4 +276,4 @@
 
 STG и прием событий нельзя отдавать в форме «удали и перепиши»: код там служит несущей частью стенда. Для этих участков подходят расследования и форма «собери рядом».
 
-У всех счетных проверок остается общая дыра — раскладка по шардам. Поэтому пересчет ключа по `hostName()` должен входить в ТЗ каждого вычитания отдельной строкой.
+У всех счетных проверок остается общая дыра — раскладка по шардам. Поэтому пересчет ключа по `hostName()` должен входить в ТЗ каждого вычитания отдельной строкой.

docs/specs/2026-07-30-stand-v2-realism.md

@@ -272,12 +272,13 @@ CSV в репозитории (`data/catalog/products.csv`: `sku`, `name`, `cate
 Классы пересекаются — приоритет: `cancelled` > `lost_event` >
 `duplicate_event` > `amount_delta` > `match`.
 
-Пятое — **опоздание** — бесплатно даёт формат доставки: часть заказов
+Пятое — **опоздание** — бесплатно даёт формат доставки: часть заказов впервые
-впервые появляется в слепке D+1/D+2 («вчера не сходилось, сегодня сошлось»),
+появляется в слепке D+1/D+2 («вчера не сходилось, сегодня сошлось»), ориентир
-ориентир ~10%. Точные доли зафиксированы замером на каноническом мире
+~10%. Точные доли зафиксированы замером на каноническом мире (28 дней,
-(28 дней, 2026-08-30, #194) — запись в «Что проверено»
+2026-08-30, #194) — запись в «Что проверено» [карты
-[карты проверок](../architecture/testing.md); опись хранит счётчики наблюдаемых классов после приоритета — в заказах и
+проверок](../architecture/testing.md); паспорт хранит счётчики наблюдаемых
-только по дням с закрытым окном (раздел 8).
+классов после приоритета — в заказах и только по дням с закрытым окном (раздел
+8).
 
 Не берём: сироту-фрод (`purchase` есть, а заказа не будет никогда) —
 механически дублирует B.
@@ -311,14 +312,13 @@ CSV в репозитории (`data/catalog/products.csv`: `sku`, `name`, `cate
   запуск пишет полный текущий набор различных пар; предыдущий результат не
   служит источником следующего.
 - **N:1**: часть покупателей покупает с двух кук («телефон и ноутбук») —
-  параметр мира; значение фиксирует эта спека: 15%, детерминировано
+  параметр мира; значение фиксирует эта спека: 15%, детерминировано от seed.
-  от seed. Ядро лабы:
+  Ядро лабы: `uniq(посетителей) > uniq(людей)`, менти выводит расхождение сам.
-  `uniq(посетителей) > uniq(людей)`, менти выводит расхождение сам.
+  Константа мира: каждый двухкуковый покупатель делает минимум по одному заказу
-  Константа мира: каждый двухкуковый покупатель делает минимум по одному
+  с каждой куки — иначе вторая кука не попадает в карту соответствий (она
-  заказу с каждой куки — иначе вторая кука не попадает в карту соответствий
+  строится только из покупок) и лаба не воспроизводится. Число таких пар растёт,
-  (она строится только из покупок) и лаба не воспроизводится. Число таких
+  пока мир едет, и в паспорт не кладётся ([что хранит
-  пар растёт, пока мир едет, и в опись не кладётся
+  паспорт](../architecture/orders/inventory.md)).
-  ([что хранит опись](../architecture/orders/inventory.md)).
 - Витрины разводят имена честно: **«посетители»** (`uniq(ClientID)`) и
   **«известные пользователи»** (после склейки) — оба числа рядом в дашборде.
 
@@ -339,16 +339,14 @@ CSV в репозитории (`data/catalog/products.csv`: `sku`, `name`, `cate
   ноду 2**. Это осознанная ловушка правильных ошибок: забытый ON CLUSTER или
   VIEW поверх локальной таблицы проявляются в дашборде сами.
 - **Приём Kafka**: у событий — Kafka-таблицы и MV на обеих нодах, одна
-  consumer group, 2 партиции на топик `hits`; MV пишут в Distributed-цели.
+  consumer group, 2 партиции на топик `hits`; MV пишут в Distributed-цели. У
-  У заказов приём другого рода — пакетный забор без MV, чтец на одной ноде,
+  заказов приём другого рода — пакетный забор без MV, чтец на одной ноде, топик
-  топик `orders` в одну партицию ([ADR 0008](../adr/0008-order-ingestion.md)).
+  `orders` в одну партицию ([ADR 0008](../adr/0008-order-ingestion.md)).
-  Раскладку в обоих случаях решает ключ:
+  Раскладку в обоих случаях решает ключ: события — по `cityHash64(ClientID)`
-  события — по `cityHash64(ClientID)` (см. 1.3), заказы —
+  (см. 1.3), заказы — `cityHash64(order_id)`, STG — `cityHash64(сырой строки)`;
-  `cityHash64(order_id)`, сырьё STG — `cityHash64(сырой строки)`; полный
+  полный список и доводы — в [доке хранилища](../architecture/storage.md). Урок
-  список и доводы — в [доке хранилища](../architecture/storage.md). Урок
+  «какая нода читала топик — меняется между прогонами, куда легли данные — нет»
-  «какая нода читала топик — меняется между прогонами, куда легли данные —
+  живёт на событиях: при пакетном заборе читает та нода, которую спросили.
-  нет» живёт на событиях: при пакетном заборе читает та нода, которую
-  спросили.
 - **Приём строгий**: пять опорных колонок — `WatchID`, `VisitID`, `ClientID`,
   `EventDate`, `UTCEventTime` — разбираются как `Nullable`, а набор ключей
   сообщения сверяется с контрактным; строка с NULL среди опорных колонок
@@ -444,23 +442,24 @@ README.
 | DM | витрины `dm.*_v`, `dm.dq_summary` | см. ниже |
 
 У каждой таблицы слоя — пара из локальной и распределённой, имена по конвенции
-суффиксов; она же задаёт служебные колонки, нарезку и срок хранения сырья —
+суффиксов; она же задаёт служебные колонки, нарезку и срок хранения сырых данных
-см. [доку хранилища](../architecture/storage.md).
+— см. [доку хранилища](../architecture/storage.md). Потребительские запросы и
-Потребительские запросы и витрины читают сущности DDS через `_v` с явным
+витрины читают сущности DDS через `_v` с явным списком колонок; `_rep` и `_dist`
-списком колонок; `_rep` и `_dist` служат загрузке, диагностике и обслуживанию.
+служат загрузке, диагностике и обслуживанию. Договор держится конвенцией, а не
-Договор держится конвенцией, а не правами: модель доступа описана в
+правами: модель доступа описана в [ADR 0007](../adr/0007-clickhouse-access.md),
-[ADR 0007](../adr/0007-clickhouse-access.md), договор чтения — в
+договор чтения — в [доке хранилища](../architecture/storage.md), «Имена
-[доке хранилища](../architecture/storage.md), «Имена объектов».
+объектов».
 
 Заказы принимаются **пакетным забором** ([ADR
 0008](../adr/0008-order-ingestion.md), [ADR
-0010](../adr/0010-order-versions-in-ods.md)): чтец топика байтовый, как у событий, но
+0010](../adr/0010-order-versions-in-ods.md)): чтец топика байтовый, как у
-матвью к нему не привязана, и сырьё забирает шаг, которым управляет Airflow —
+событий, но матвью к нему не привязана, и порцию в STG забирает шаг под
-одно прямое чтение вставляет порцию в `stg.orders_raw` с `_load_id` запуска.
+управлением Airflow — одно прямое чтение вставляет её в `stg.orders_raw` с
-Один следующий `task_id` двумя последовательными запросами пишет годные строки
+`_load_id` запуска. Один следующий `task_id` двумя последовательными запросами
-и ошибки из того же среза. `ods.order` выбирает текущую версию по максимальной
+пишет годные строки и ошибки из того же среза. `ods.order` выбирает текущую
-`snapshot_date` ([ADR 0014](../adr/0014-order-version-snapshot-date.md)). Слой
+версию по максимальной `snapshot_date` ([ADR
-сырья остаётся точкой повтора и разбора одной принятой порции.
+0014](../adr/0014-order-version-snapshot-date.md)). Слой Сырой слой остаётся
+точкой повтора и разбора одной принятой порции.
 
 Состав служебных колонок задаёт дока хранилища. Спеке важны два следствия:
 `ods.event` и `ods.order` получают метку загрузки `_load_ts`, но версию
@@ -531,31 +530,28 @@ Kafka день переигрывается генератором заново:
 пачками), Postgres остаётся только служебной базой Airflow. Смешанность
 ландшафта выражена режимами и частотами, а не второй трубой.
 
-## 8. Эталонный мир и опись
+## 8. Эталонный мир и паспорт
 
-В git хранится только опись эталонного мира; сам снимок генерируется на
+В git хранится только паспорт эталонного мира; сам снимок генерируется на месте
-месте — при `make up` и при проверках (решение развилки «Производительность»
+— при `make up` и при проверках (решение развилки «Производительность» карты
-карты #26, подробности — [спека генератора](2026-08-01-generator.md),
+#26, подробности — [спека генератора](2026-08-01-generator.md), раздел 5).
-раздел 5). Снимок — 8 дней, совпадает со стартовым миром: обещание в 14 дней
+Снимок — 8 дней, совпадает со стартовым миром: обещание в 14 дней снято на этапе
-снято на этапе 7. Опись несёт
+7. Паспорт несёт шапку с каноническим зерном и версией генератора, контрольные
-паспорт мира (каноническое зерно, версия генератора), контрольные счётчики
+счётчики и хеши по дням; проверки «пустой git diff» и «пересгенерируй день N —
-и хеши по дням; проверки «пустой git diff» и «пересгенерируй день N —
+сравни хеш» живут на нём. Политика версионирования артефакта (бывший туман карты
-сравни хеш» живут на ней. Политика версионирования артефакта (бывший туман
+#10) закрыта этим же ходом: версионируется паспорт. Контрольные числа паспорта:
-карты #10) закрыта этим же ходом: версионируется опись.
-Контрольные числа описи:
 
 - по строке на каждый отправленный слепок — хеш байтов: побайтовое обещание
-  «слепок переснимается и даёт те же байты» опись сторожит наравне с днями;
+  «слепок переснимается и даёт те же байты» паспорт сторожит наравне с днями;
 - заказная сторона: счётчики наблюдаемых классов расхождений после
   приоритета; каждый показывает число заказов и хранится только для дня с
-  закрытым окном (читатель — техническая проверка `classes_vs_inventory`
+  закрытым окном (читатель — техническая проверка `classes_vs_inventory` звена
-  звена DQ; при N сыгранных днях таких дней N − 7). Отдельных полей для
+  DQ; при N сыгранных днях таких дней N − 7). Отдельных полей для общего числа
-  общего числа заказов и выручки в описи пока нет: для них не назван
+  заказов и выручки в паспорте пока нет: для них не назван читатель;
-  читатель;
 - контрольные числа идентичности не заводятся: uniq известных пользователей
   и число двухкуковых покупателей растут, пока мир едет, а счётчик без
-  названного читателя в опись не кладётся
+  названного читателя в паспорт не кладётся ([что хранит
-  ([что хранит опись](../architecture/orders/inventory.md)).
+  паспорт](../architecture/orders/inventory.md)).
 
 Размер снимка замерен на этапе 7 — запись в разделе «Что проверено»
 [карты проверок](../architecture/testing.md).
@@ -572,7 +568,7 @@ v2 стартует пустым, поэтому объём ниже — это
 | SQL | DDL по слоям и ролям (ON CLUSTER, Replicated*, Distributed; раскладка файлов — в доке хранилища) + трансформации событий, заказов, identity, сверки + словарь | L — ~12–15 файлов, главная сложность |
 | Airflow | DAG'и по образцу v1: etl_pipeline (партиционная переобработка), world_init/next_day, helpers; первый даг — переливка слепка — приходит раньше, этапом 3 | M — ~5–6 файлов |
 | Superset | датасеты + дашборд с тремя новыми сюжетами | M — 2 файла |
-| Эталонный мир | пересборка снимка на месте, счётчики описи, чек-скрипты | M–L |
+| Эталонный мир | пересборка снимка на месте, счётчики паспорта, чек-скрипты | M–L |
 | Мониторинг | дашборды Grafana «данные», «кластер», «запросы»; ClickHouse источником данных, панели на SQL; Prometheus тонким полом (ADR 0002) | M — конфиги и дашборды |
 | Документация | доки v2 пишутся заново (см. раздел 12) | M, в тех же PR |
 
@@ -619,8 +615,8 @@ v2 стартует пустым, поэтому объём ниже — это
 4. Трансформации и витрины: модель DDS заказа, сессии, identity_map,
    выручка, сверка A+C.
 5. Airflow: `etl_pipeline` (партиционная переобработка).
-6. Расхождения B+D и опоздания; счётчики описи.
+6. Расхождения B+D и опоздания; счётчики паспорта.
-7. Эталонный мир: опись и пересборка снимка, чек-скрипты. CI-генерация
+7. Эталонный мир: паспорт и пересборка снимка, чек-скрипты. CI-генерация
    снята (спека генератора, раздел 5).
 8. Superset-дашборд v2.
 9. Мониторинг и runbook «keeper упал / DDL повис в очереди». Состав дашбордов
@@ -658,15 +654,15 @@ ADR 0002 с приёмочными совпадают почти целиком.
   расхождение часов клиент/коллектор — туман карты, вернётся своим тикетом.
 - Лабы и курс: v2 — другой стенд, лабы для него пишутся с нуля отдельной
   работой после этой спеки; редизайн лаб v1 (#7) остаётся в v1 и сюда не
-  переносится. Исключение — домашки слоя DM: ТЗ витрин менти и даг
+  переносится. Исключение — домашки слоя DM: ТЗ витрин менти и даг самопроверки
-  самопроверки забраны в этап 4 резолюцией #135, потому что витрина менти и
+  забраны в этап 4 резолюцией #135, потому что витрина менти и конвейер, в
-  конвейер, в который она встает, проектируются вместе. Сюда же —
+  который она встает, проектируются вместе. Сюда же — необязательная лаба «свой
-  необязательная лаба «свой дашборд в Superset» (#197): она стоит на
+  дашборд в Superset» (#197): она стоит на витринах домашек DM и продумана до
-  витринах домашек DM и продумана до готового ТЗ в этапе 8, тогда как
+  готового ТЗ в этапе 8, тогда как остальные лабы пока на уровне идей. Единый
-  остальные лабы пока на уровне идей. Единый стиль блока
+  стиль блока домашек — за работой учебного пути. Спека даёт будущим лабам
-  домашек — за работой учебного пути. Спека даёт будущим лабам только
+  только опорные точки — контрольные числа паспорта (сверка, идентичность).
-  опорные точки — контрольные числа описи (сверка, идентичность). Явное
+  Явное следствие: после этапа 9 стенд работает, но учебного пути на нём ещё
-  следствие: после этапа 9 стенд работает, но учебного пути на нём ещё нет.
+  нет.
 - Инкрементальный ETL (#8) — свой issue.
 - Реплики (2×2), HAProxy, репликационная эксплуатация — в лекцию, не в стенд.
 - TLS между нодами, настоящее хранилище и ротация секретов, внешние учётные

docs/specs/2026-08-01-generator.md

@@ -41,10 +41,10 @@
   конструкция внутри оправдана только наблюдаемым эффектом: без него это
   сложность, за которую никто не заплатил.
 - **Повторимы должны быть эффекты, а не конкретные числа.** Правка свойств
-  мира сдвигает почти все числа разом — генератор случайных чисел выдаёт
+  мира сдвигает почти все числа разом — генератор случайных чисел выдаёт другую
-  другую последовательность. Опираться на конкретные числа поэтому нечем.
+  последовательность. Опираться на конкретные числа поэтому нечем. Хеши паспорта
-  Хеши описи обещают не постоянство чисел, а то, что их сдвиг не пройдёт
+  обещают не постоянство чисел, а то, что их сдвиг не пройдёт молча: пересобрал
-  молча: пересобрал опись — увидел diff.
+  паспорт — увидел diff.
 - **Цена ошибки здесь мала.** В худшем случае испорчен урок, и чинится он
   правкой генератора после взгляда на получившиеся распределения. Оборона,
   которая дороже ошибки, не заводится.
@@ -59,15 +59,15 @@
   модельный день D — функция (зерно, D). Между прогонами живут только зерно
   и позиция на оси времени.
 - **Детерминизм до байта.** Одно зерно — побайтово тот же снимок; сверка —
-  хешами описи. Транспорт (офсеты Kafka, темп) — вне обещания.
+  хешами паспорта. Транспорт (офсеты Kafka, темп) — вне обещания.
 - **Схема — контракт генератора.** Python-модуль с чистыми данными;
   хранилище строится по рендеренной документации, границу сторожит строгий
   приём на стороне хранилища.
 - **Один сериализатор, глупые приёмники.** День-функция выдаёт канонические
   байты; приёмники — файл, Kafka пачкой, Kafka с темпом.
 - **Числа.** Средний день ~50 тыс. событий; эталонный снимок совпадает со
-  стартовым миром — 8 дней;
+  стартовым миром — 8 дней; в git — только паспорт мира; автоматических порогов
-  в git — только опись мира; автоматических порогов по времени нет.
+  по времени нет.
 
 ## 1. Модель мира
 
@@ -109,23 +109,21 @@
   начинается в D0) — только дают, кому возвращаться в первые дни: дневная
   аудитория на полке с самого D0, разгона «пустого магазина» нет.
 - **Гарантия двухкуковых пар — назначенные заказы в плане.** Единица
-  здесь — человек, не кука: план помечает часть людей покупателями
+  здесь — человек, не кука: план помечает часть людей покупателями (доля —
-  (доля — раздел 9), и 15% покупателей (мастер-спека, раздел 5) получают
+  раздел 9), и 15% покупателей (мастер-спека, раздел 5) получают вторую куку.
-  вторую куку. Обе куки пары принадлежат одному человеку одной когорты;
+  Обе куки пары принадлежат одному человеку одной когорты; вторая рождается в
-  вторая рождается в пределах его окна активности, без фиксированного
+  пределах его окна активности, без фиксированного зазора — по тому же
-  зазора — по тому же затухающему профилю, что и возвраты (уточнение при
+  затухающему профилю, что и возвраты (уточнение при исполнении #38,
-  исполнении #38, 2026-08-02): куку человек заводит, пока ещё ходит.
+  2026-08-02): куку человек заводит, пока ещё ходит. Равные шансы по всему окну
-  Равные шансы по всему окну означали бы вторую куку у давно ушедшего
+  означали бы вторую куку у давно ушедшего человека — и вчетверо меньше пар,
-  человека — и вчетверо меньше пар, реализованных внутри снимка.
+  реализованных внутри снимка. Каждой паре план назначает дни гарантированных
-  Каждой паре план назначает дни гарантированных заказов: по
+  заказов: по одному на куку, из дней активности этой куки, на оси от D0 и
-  одному на куку, из дней активности этой куки, на оси от D0 и позже;
+  позже; человеку предыстории, чьё окно активности таких дней не оставляет, пара
-  человеку предыстории, чьё окно активности таких дней не оставляет,
+  не назначается. День-функция обязана назначенные заказы реализовать; остальные
-  пара не назначается. День-функция обязана назначенные заказы
+  покупки — вольные, их решает генератор торговых событий (#40). План считает
-  реализовать; остальные покупки — вольные, их решает генератор торговых
+  пары, реализованные в запрошенном горизонте; паспорт это число не хранит — оно
-  событий (#40). План считает пары, реализованные в запрошенном горизонте;
+  растёт вместе с миром. Условность в данных не видна: дни назначены той же
-  опись это число не хранит — оно растёт вместе с миром. Условность в данных
+  случайностью, просто брошенной планом один раз.
-  не видна: дни назначены той же случайностью, просто брошенной планом один
-  раз.
 - **Своя ось модельного времени.** Ось событий начинается в
   фиксированный день D0 (понедельник — см. раздел 5); реальный
   календарь в модели не участвует. В `EventDate`/`UTCEventTime` дни оси
@@ -133,10 +131,10 @@
   зависящая (значение — раздел 9). Между прогонами живут только зерно и
   позиция на оси: выключенный ноутбук — мир замер, потом продолжил.
 - **Два режима движения по одной оси.** Пошаговый — базовый для лаб: старт
-  с эталонного снимка, дальше «прожить следующий день» — явное действие.
+  с эталонного снимка, дальше «прожить следующий день» — явное действие. Живой
-  Живой день — текущий день проигрывается с ускорением, дашборд и мониторинг
+  день — текущий день проигрывается с ускорением, дашборд и мониторинг «дышат»;
-  «дышат»; включается по требованию — постоянным фоном идёт, только пока
+  включается по требованию — постоянным фоном идёт, только пока включён
-  включён выключатель пульта ([ADR 0009](../adr/0009-world-control.md)).
+  выключатель `world_live` ([ADR 0009](../adr/0009-world-control.md)).
 - **Граница суток — единственный структурный шов.** Сессии режутся по ней,
   дневная партиция самодостаточна; в конце модельного дня — слепок заказов.
   День проживается целиком, полдня не бывает: недожитый из-за обрыва день
@@ -148,14 +146,13 @@
 Отклонено с доводами:
 
 - *Мутирующее состояние мира* («мир стареет»): ломает параллельность по
-  дням, требует чекпоинтов, счётчики описи узнаваемы только постфактум;
+  дням, требует чекпоинтов, счётчики паспорта узнаваемы только постфактум; ни
-  ни один урок стенда на старении не стоит.
+  один урок стенда на старении не стоит.
 - *Чистая функция без слоя состава*: глобальные инварианты пришлось бы
   выводить в каждом дне заново — тот же план мира, но неявный и размазанный.
 - *Привязка модельного времени к реальному календарю* (T-1 с догоном):
-  конфликтует с ускорением ×60 — за вечер мир уезжает в будущее — и делает
+  конфликтует с ускорением ×60 — за вечер мир уезжает в будущее — и делает даты
-  даты эталонного мира зависимыми от даты запуска, опись теряет
+  эталонного мира зависимыми от даты запуска, паспорт теряет воспроизводимость.
-  воспроизводимость.
 
 Отклонено при исполнении #38 (2026-08-02):
 
@@ -170,9 +167,9 @@
   константы — потолка одновременно живущих кук, которого в жизни нет и
   который менти нечем объяснить.
 - *Вероятностная гарантия пар* («почти наверняка купит с обеих кук»): не
-  гарантия — однажды опись покраснеет, а чинить нечем, кроме смены
+  гарантия — однажды паспорт покраснеет, а чинить нечем, кроме смены зерна; при
-  зерна; при этом несклеенная пара в данных неотличима от двух незнакомцев,
+  этом несклеенная пара в данных неотличима от двух незнакомцев, так что реализм
-  так что реализм этой лотереи невидим.
+  этой лотереи невидим.
 - *Покупка пары в первый визит куки*: гарантия железная и дешёвая, но узор
   «все пары покупают в первый день» виден в данных ровно там, куда лаба
   склейки смотрит пристальнее всего. Условность допустима, пока она не
@@ -185,31 +182,29 @@
 - **Обещание — содержимое до байта.** Два прогона с одним зерном дают тот же
   набор событий: те же `WatchID`/`VisitID`, поля, метки модельного времени.
   Снимок при пересборке побайтово совпадает: канонический порядок ключей и
-  строк; сверка — по хешам описи, а два локально пересобранных снимка
+  строк; сверка — по хешам паспорта, а два локально пересобранных снимка
-  сравнимы обычным diff — пустой означает «ничего не изменилось». Вне
+  сравнимы обычным diff — пустой означает «ничего не изменилось». Вне обещания —
-  обещания — транспорт: офсеты и партиции Kafka, какая нода прочитала,
+  транспорт: офсеты и партиции Kafka, какая нода прочитала, `_load_ts`, темп
-  `_load_ts`, темп живого дня.
+  живого дня.
 - **Условия обещания.** Детерминизм держится при зафиксированном `uv.lock`
-  и внутри канонического контейнера — то есть везде Linux, на маке и в WSL
+  и внутри канонического контейнера — то есть везде Linux, на маке и в WSL тоже;
-  тоже; единственная переменная — архитектура CPU. Истина — CI на Linux; сходимость любой машины проверяет
+  единственная переменная — архитектура CPU. Истина — CI на Linux; сходимость
-  скрипт «пересгенерируй день N — сравни хеш с описью». Расхождение на
+  любой машины проверяет скрипт «пересгенерируй день N — сравни хеш с
-  любой платформе — баг генератора, а не допуск.
+  паспортом». Расхождение на любой платформе — баг генератора, а не допуск.
 - **Раздача зерна — иерархией подпотоков.** Корневое зерно → подпоток
-  состава мира, ветвящийся по номеру дня на когорты плана (состав
+  состава мира, ветвящийся по номеру дня на когорты плана (состав спрашивается
-  спрашивается по дням — раздел 1; уточнение при исполнении #38).
+  по дням — раздел 1; уточнение при исполнении #38). Дни предыстории
-  Дни предыстории отрицательны, а позиция в дереве — неотрицательное
+  отрицательны, а позиция в дереве — неотрицательное целое, поэтому у
-  целое, поэтому у предыстории своя ветвь состава, отдельная от оси
+  предыстории своя ветвь состава, отдельная от оси (уточнение при исполнении
-  (уточнение при исполнении #38, 2026-08-02);
+  #38, 2026-08-02); (зерно, день) → подпоток дня → именованные подпотоки
-  (зерно, день) → подпоток дня → именованные подпотоки компонентов: трафик,
+  компонентов: трафик, торговые события, заказная и событийная стороны (судьба
-  торговые события, заказная и событийная стороны (судьба заказов и порча
+  заказов и порча событийного потока) — в фиксированном порядке (уточнение
-  событийного потока) — в фиксированном порядке (уточнение [судьбой
+  [судьбой заказа](../architecture/orders/fate.md): прежние «расхождения» и
-  заказа](../architecture/orders/fate.md): прежние «расхождения» и
+  «опоздания» были названы по классам витрины, а компонент называет часть мира).
-  «опоздания» были названы по классам витрины, а компонент называет часть
+  По построению: параллельный прогон равен последовательному; продление истории
-  мира).
+  днём N+1 не трогает дни 1…N; правка одного компонента меняет только его часть
-  По построению: параллельный прогон равен последовательному; продление
+  снимка — в паспорте меняются хеши только затронутых дней, дифф двух локальных
-  истории днём N+1 не трогает дни 1…N; правка одного компонента меняет
+  пересборок читаем.
-  только его часть снимка — в описи меняются хеши только затронутых
-  дней, дифф двух локальных пересборок читаем.
 - **Механизм подпотоков — `numpy.random.SeedSequence`.** Сверено через
   Context7 по документации numpy (2026-08-01): `spawn(n)` порождает детей
   расширением `spawn_key`, потомок полностью определяется парой
@@ -223,8 +218,8 @@
   представление в клиентском `purchase` (урок мастер-спеки о расхождениях).
 - **Канонический seed и паспорт мира.** Эталонный мир собирается одним
   каноническим зерном — константой репозитория; свои зёрна менти крутит без
-  гарантий описи. Опись хранит паспорт мира — зерно и версию
+  гарантий паспорта. В шапке паспорта лежат зерно и версия генератора;
-  генератора; чек-скрипты сверяют паспорт раньше счётчиков.
+  чек-скрипты сверяют шапку раньше счётчиков.
 - **Суточный профиль интенсивности задаёт день-функция.** Форма — волны:
   ночной провал, обеденный и вечерний пики, различие будней и выходных;
   пики — до ~2× среднего. С детерминизмом профиль совместим: это часть
@@ -241,8 +236,8 @@
   «параллельно равно последовательно» недостижимо.
 - *Обещание детерминизма поверх обновления зависимостей*: numpy сознательно
   улучшает алгоритмы распределений между версиями (NEP 19), Faker меняет
-  словари. Фиксация — `uv.lock`; обновление зависимостей — осознанная
+  словари. Фиксация — `uv.lock`; обновление зависимостей — осознанная пересборка
-  пересборка описи одним PR.
+  паспорта одним PR.
 
 ## 3. Контракт схемы
 
@@ -289,9 +284,9 @@
 
 - **Один канонический сериализатор, глупые приёмники.** День-функция выдаёт
   упорядоченный поток канонических байтов — единственное место, где событие
-  превращается в JSON. Приёмники не знают о содержимом: файл (локальный кэш
+  превращается в JSON. Приёмники не знают о содержимом: файл (локальный кэш для
-  для пересборки и проверок описи), Kafka пачкой — пакетный режим,
+  пересборки и проверок паспорта), Kafka пачкой — пакетный режим, Kafka с темпом
-  Kafka с темпом ×60 — живой день. Новых топиков нет.
+  ×60 — живой день. Новых топиков нет.
 - **Одно событие — одно сообщение Kafka.** «Пачкой» относится к темпу
   отправки, а не к упаковке: приёмник шлёт события подряд без пауз, но каждое
   отдельным сообщением. Контракт транспорта, не деталь реализации — сторона
@@ -299,9 +294,9 @@
   ([ADR 0005](../adr/0005-event-ingestion.md)), поэтому склейка нескольких
   событий в одно сообщение сломала бы разбор целиком.
 - **Даты и время на проводе — ISO-8601.** `EventDate` уезжает как `2026-06-01`,
-  `UTCEventTime` — как `2026-06-01T12:34:56Z`. Довод — читаемость сырья: весь
+  `UTCEventTime` — как `2026-06-01T12:34:56Z`. Довод — читаемость сырых данных:
-  смысл слоя STG в том, что менти открывает колонку `raw` в обычном клиенте и
+  весь смысл слоя STG в том, что менти открывает колонку `raw` в обычном клиенте
-  разбирает событие глазами, а число эпохи этот урок убивает. Колонка
+  и разбирает событие глазами, а число эпохи этот урок убивает. Колонка
   `ecommerce` — строка, внутри которой лежит экранированный JSON, как отдаёт
   Метрика.
 
@@ -321,9 +316,9 @@
   первым. Записана форма всё равно здесь — иначе каждый выберет своё, и
   разойдётся это уже после приёмки.
 - **Рабочий выбор сериализатора — orjson**: быстрее stdlib json в 5–14 раз,
-  numpy-массивы и datetime сериализует нативно (заметка исследования #31).
+  numpy-массивы и datetime сериализует нативно (заметка исследования #31). Смена
-  Смена библиотеки меняет канонические байты, поэтому проходит как
+  библиотеки меняет канонические байты, поэтому проходит как обновление
-  обновление зависимости: осознанная пересборка описи одним PR.
+  зависимости: осознанная пересборка паспорта одним PR.
 - **Промежуточные файлы не хранятся.** Файл дня — кэш чистой функции:
   потерял — пересчитал. В git снимок не попадает (раздел 5).
 - **Обрыв любого режима — переигровка дня целиком**; дедуп склеивает
@@ -341,7 +336,7 @@
 
 - *Отдельный топик / Kafka как хранилище дней*: офсеты и партиции вне
   обещания детерминизма, retention конечен, в git топик не положишь, хеш с
-  описью не сверишь; Kafka на стенде — труба, не хранилище (раздел 7
+  паспортом не сверишь; Kafka на стенде — труба, не хранилище (раздел 7
   мастер-спеки).
 - *Файл как обязательная станция доставки*: доигрывание обрыва уже решено
   через дедуп, канон держит единственный сериализатор, а не диск; файл
@@ -360,27 +355,25 @@
   ~2× среднего, будни/выходные; ≈8–12 тыс. сессий, 6–8 тыс. посетителей —
   правдоподобный средний магазин.
 - **Эталонный снимок совпадает со стартовым миром — 8 дней**: понедельник
-  по понедельник, полная неделя и один закрытый день за окном K = 7.
+  по понедельник, полная неделя и один закрытый день за окном K = 7. Обещание в
-  Обещание в 14 дней снято на этапе 7 (решение владельца 2026-08-30):
+  14 дней снято на этапе 7 (решение владельца 2026-08-30): у дней 8–13 не
-  у дней 8–13 не нашлось читателя — лабы проигрывают мир дальше без описи,
+  нашлось читателя — лабы проигрывают мир дальше без паспорта, транспорт байты с
-  транспорт байты с описью не сверяет, а проверке «пересгенерируй день N —
+  паспортом не сверяет, а проверке «пересгенерируй день N — сравни хеш» день 3
-  сравни хеш» день 3 годится так же, как день 13. Замеры и тесты, меряющие
+  годится так же, как день 13. Замеры и тесты, меряющие мир на окне в две
-  мир на окне в две недели, не меняются: мир — функция без края, окну
+  недели, не меняются: мир — функция без края, окну замера паспорт не нужен.
-  замера опись не нужна. Удлинение описи остается дешевым ходом
+  Удлинение паспорта остаётся дешёвым ходом (пересборка) и делается, когда
-  (пересборка) и делается, когда читатель появится — например, если
+  читатель появится — например, если растяжке `classes_vs_inventory` понадобится
-  растяжке `classes_vs_inventory` понадобится сверять больше одного
+  сверять больше одного закрытого дня.
-  закрытого дня.
+- **В git — только паспорт, снимок не хранится.** Снимок генерируется при
-- **В git — только опись, снимок не хранится.** Снимок генерируется при
   создании мира и в проверках генератора: артефакт — кэш чистой функции, кэш в
-  git не хранят. Опись несёт паспорт мира, счётчики и хеши по дням; проверки
+  git не хранят. Паспорт несёт шапку, счётчики и хеши по дням; проверки «пустой
-  «пустой git diff» и «пересгенерируй день N — сравни хеш» живут на ней.
+  git diff» и «пересгенерируй день N — сравни хеш» живут на нём. Первый `make
-  Первый `make up` пустого стенда — живая демонстрация детерминизма; готовый мир
+  up` пустого стенда — живая демонстрация детерминизма; готовый мир повторный
-  повторный подъём не пересчитывает. Честная потеря —
+  подъём не пересчитывает. Честная потеря — страховка на случай платформенного
-  страховка на случай платформенного бага: раньше менти с расходящимися
+  бага: раньше менти с расходящимися байтами мог взять готовый снимок из git,
-  байтами мог взять готовый снимок из git, теперь он упрётся в красный чек
+  теперь он упрётся в красный чек паспорта; смягчение — дисциплина целочисленной
-  описи; смягчение — дисциплина целочисленной случайности (раздел 2):
+  случайности (раздел 2): расхождения amd64/arm64 сняты устройством, а не
-  расхождения amd64/arm64 сняты устройством, а не сторожем. CI ради одного
+  сторожем. CI ради одного прогона не заводится (решение владельца 2026-08-30).
-  прогона не заводится (решение владельца 2026-08-30).
 - **Живой день — ×60 по умолчанию**: модельные сутки за 24 реальные минуты,
   суточная волна разворачивается на глазах; темп в среднем ~35 событий/с,
   в пиковые часы сильных дней — до ~100. Число —
@@ -399,7 +392,7 @@
 | Операция | Ориентир |
 |---|---|
 | Генерация одного дня | 1,7–2,8 с (замер 7 августа 2026 года) |
-| Пересборка эталонного мира (8 дней + опись, без транспорта) | 20,5 с (замер 30 августа 2026 года) |
+| Пересборка эталонного мира (8 дней + паспорт, без транспорта) | 20,5 с (замер 30 августа 2026 года) |
 | Заливка стартового мира при `make up` (8 дней, Kafka → матвью → ODS) | 22,5 с (замер 7 августа 2026 года) |
 | Лаг живого дня | секунды |
 
@@ -460,9 +453,9 @@
 - **Раздел 1.4**: «из контракта выводятся DDL и валидация» заменено на data
   contract — хранилище пишется по документации, границу сторожит строгий
   приём (раздел 3 здесь).
-- **Раздел 8**: артефакт `data/startup_history/` в git заменён описью;
+- **Раздел 8**: артефакт `data/startup_history/` в git заменён паспортом;
-  снимок генерируется на месте (раздел 5 здесь). Туман «политика
+  снимок генерируется на месте (раздел 5 здесь). Туман «политика версионирования
-  версионирования артефакта» закрыт этим же ходом: версионируется опись.
+  артефакта» закрыт этим же ходом: версионируется паспорт.
 - **Раздел 11**: пункт «до этапа 3 зафиксировать требования
   производительности» закрыт числами раздела 5.
 - Мелкие согласования там, где текст опирался на артефакт в git: источник
@@ -491,24 +484,25 @@
   теперь есть.
 - **Этап 5 (Airflow)**: живой день со стороны хранилища — обычный ETL-даг
   по расписанию (~раз в 24 минуты); генератор не дорабатывается.
-- **Позиция на оси времени** (хвост отдан пульту мира раньше этапа 5 —
+- **Позиция на оси времени** (хвост отдан дагам модельного времени раньше этапа
+  5 —
   [ADR 0009](../adr/0009-world-control.md))**.** Проигрыватель состояния не
   хранит (раздел 9), поэтому вести позицию — работа того, кто его зовёт. Живёт
-  она переменной Airflow: отсутствие переменной означает, что стартовый мир
+  она переменной Airflow: отсутствие переменной означает, что стартовый мир ещё
-  ещё не создан. В обычной жизни её ставит даг пульта, который сыграл день, —
+  не создан. В обычной жизни её ставит шаговый даг, который сыграл день, —
   значением «последний сыгранный + 1» и только по успеху. Даги жизненного цикла
-  используют `-1` для незавершённой очистки, `0` для чистого мира до генерации
+  используют `-1` для незавершённой очистки, `0` для чистого мира до генерации и
-  и ставят первый несыгранный день только после приёма стартового мира
+  ставят первый несыгранный день только после приёма стартового мира ([ADR
-  ([ADR 0013](../adr/0013-world-lifecycle.md)).
+  0013](../adr/0013-world-lifecycle.md)). Довод — генератор отдельная и
-  Довод — генератор отдельная и заменяемая сущность, привязывать его к
+  заменяемая сущность, привязывать его к хранилищу незачем. Полный `make clean`
-  хранилищу незачем. Полный `make clean` сносит метаданные Airflow вместе с
+  сносит метаданные Airflow вместе с данными ClickHouse, а узкая пересборка явно
-  данными ClickHouse, а узкая пересборка явно сводит сохранённую позицию с
+  сводит сохранённую позицию с заново залитым миром. Расхождение переменной с
-  заново залитым миром.
+  данными (менти почистил партицию руками) лечится документацией, а не сторожем:
-  Расхождение переменной с данными (менти почистил партицию руками) лечится
+  постоянная сверка была бы проверкой, красной в норме ([ADR
-  документацией, а не сторожем: постоянная сверка была бы проверкой, красной
+  0002](../adr/0002-monitoring-scope.md)).
-  в норме ([ADR 0002](../adr/0002-monitoring-scope.md)).
+- **Этап 7 (эталонный мир)**: пересборка обновляет паспорт мира. Отдельного
-- **Этап 7 (эталонный мир)**: пересборка — это опись, не артефакт.
+  артефакта у неё нет. CI-генерация на amd64 и arm64 снята — резолюция в разделе
-  CI-генерация на amd64 и arm64 снята — резолюция в разделе 5.
+  5.
 - **Будущие лабы**: перезаливка дня X пакетным режимом проигрывателя —
   готовая демонстрация идемпотентности конвейера.
 
@@ -521,10 +515,10 @@
 [ADR 0017](../adr/0017-order-numbering.md). Новые решения генератора
 записывают в ADR и в спеке этапа, на котором их принимают.
 
-Журнал собран по темам, но дата и тикет остались у каждого решения. По
+Журнал собран по темам, но дата и тикет остались у каждого решения. По журналу
-журналу видно, какие границы затрагивала каждая правка: иногда она меняла
+видно, какие границы затрагивала каждая правка: иногда она меняла сразу план
-сразу план состава, воронку и каталог. При #40 это было дешево — опись еще
+состава, воронку и каталог. При #40 это было дёшево — паспорт мира ещё не
-не собрали; позже такой ход потребовал бы пересборки описи.
+собрали; позже такой ход потребовал бы пересборки паспорта мира.
 
 ### План состава и числа мира
 
@@ -547,10 +541,10 @@
   покупателей ~190 в день, что дает конверсию ~2% на сессию.
 - **Конфигурация мира — модуль чистых данных** (#38, 2026-08-02) рядом с
   контрактом схемы: все числа мира собраны в одном месте, которое менти может
-  крутить. Правка модуля меняет мир, и проверка описи честно краснеет: опись
+  крутить. Правка модуля меняет мир, и проверка паспорта честно краснеет:
-  сторожит только канон. Вне модуля остается то, что мира не меняет, — свое
+  паспорт сторожит только канон. Вне модуля остается то, что мира не меняет, —
-  зерно и транспортные флаги проигрывателя. Отклонено: внешний конфиг и
+  свое зерно и транспортные флаги проигрывателя. Отклонено: внешний конфиг и
-  переопределения окружением — переменная мира, которой нет в паспорте описи;
+  переопределения окружением — переменная мира, которой нет в шапке паспорта;
   файл-конфиг в репозитории равен модулю по смыслу, но платит загрузчиком и
   валидацией (довод раздела 3 против YAML).
 - **Покупатель перестает быть словом — двумя рычагами сразу** (#40, решение
@@ -749,8 +743,8 @@
   четвертям цены и по медиане, потому что одни только края списка обманываются
   четырьмя исключениями. Хвост соседям: словарь ClickHouse над этим файлом ещё
   не построен (#37/#43) — колонку надо взять в его описание сразу, а не догонять
-  правкой; описи нужен хеш каталога (хвост #42) тем более, потому что теперь в
+  правкой; паспорту нужен хеш каталога (хвост #42) тем более, потому что теперь
-  файле живёт ещё и поведение.
+  в файле живёт ещё и поведение.
 - **Доля просмотров карточек, доходящих до корзины, выросла с 7,3% до 8,6%**
   (#50, 2026-08-02) и подошла к потолку вилки. Визитам вне `/cart` нужны свои
   позиции, а визит с намерением должен класть почти все сравненное; обе границы
@@ -764,7 +758,7 @@
   живых магазинов эта доля гуляет широко; пока она правдоподобна, сама по себе
   ничего не сторожит, и подгонять поведение под ее край не надо. Настоящий
   предел считается в другой валюте — дневной бюджет событий, на котором стоит
-  опись #42. Если будущая правка упрется в него, двигать надо бюджет и его
+  паспорт #42. Если будущая правка упрется в него, двигать надо бюджет и его
   причины, а не долю.
 
 ### Номер заказа, промокод и деньги
@@ -933,28 +927,27 @@
   подъем указал бы внутрь `.venv`: каталог был бы в образе, но модуль его не
   нашел бы. Проверено в контейнере: день совпал побайтово с прогоном на машине.
 
-### Опись мира и словарь
+### Паспорт мира и словарь
 
-- **Опись мира одна** (#42, 2026-08-07; эталонная длина — 8 дней, этап 7,
+- **Паспорт мира один** (#42, 2026-08-07; эталонная длина — 8 дней, этап 7,
-  2026-08-30). Стартовый мир этапа 2 — первые восемь дней,
+  2026-08-30). Стартовый мир этапа 2 — первые восемь дней, понедельник по
-  понедельник по понедельник: полная неделя и первый замкнутый цикл K = 7.
+  понедельник: полная неделя и первый замкнутый цикл K = 7.
-  `data/world-inventory.json` — та самая опись, которую обещает раздел 5.
+  `data/world-inventory.json` — тот самый паспорт, который обещает раздел 5.
-  Этап 7 оставил ее восьмидневной: у хвоста в шесть дней не нашлось читателя
+  Этап 7 оставил его восьмидневным: у хвоста в шесть дней не нашлось читателя
-  (резолюция — в разделе 5); вырастет она продолжением этого же файла, а не
+  (резолюция — в разделе 5); вырастет он продолжением этого же файла, а не
-  вторым. В JSON лежат
+  вторым. В JSON лежат шапка паспорта — зерно, версия генератора и хеш каталога
-  паспорт мира — зерно, версия генератора и хеш каталога — и строки дней с
+  — и строки дней с датой, числом событий и хешем. Паспорт собирает `make
-  датой, числом событий и хешем. Опись собирает `make inventory`, свежесть
+  inventory`, свежесть сторожит `test_inventory.py` тем же способом, что
-  сторожит `test_inventory.py` тем же способом, что свежесть описания выгрузки.
+  свежесть описания выгрузки. Отклонено: *два файла, младший и полный* — две
-  Отклонено: *два файла, младший и полный* — две правды об одном мире и лишнее
+  правды об одном мире и лишнее слово в словаре.
-  слово в словаре.
 - **Хеш каталога лежит в паспорте и объясняет расхождение** (#42, 2026-08-07).
   Правка цены меняет мир так же молча, как правка кода. Хеши дней и без
   каталожного хеша поймают смену мира; он отвечает на следующий вопрос — что
   менялось: разошлись дни и каталог — CSV, только дни — код.
 - **«Манифест» переименован в «опись мира», «зерновой мир» — в «стартовый мир»**
-  (#42, решение владельца 2026-08-07). Обычные русские слова убирают пару
+  (#42, решение владельца 2026-08-07; позднее тикет #214 сменил «опись мира» на
-  «манифест / мини-манифест» и необходимость различать две сущности там, где
+  «паспорт мира»). Обычные русские слова убирают пару «манифест / мини-манифест»
-  вещь одна.
+  и необходимость различать две сущности там, где вещь одна.
 
 ### Открытое на момент заморозки
 

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

@@ -12,11 +12,11 @@ DDL и двумя одноразовыми службами заливал во
 
 Граница владения не совпадала с процессом, и это видно по следствиям. Успешная
 отправка в Kafka выдавалась за созданный мир: `world-init` завершался сразу
-после записи в топик, до приёма сообщений хранилищем.
+после записи в топик, до приёма сообщений хранилищем. Повторный `make up`
-Повторный `make up` смешивал подъём служб с повторной заливкой данных. Узкая
+смешивал подъём служб с повторной заливкой данных. Узкая пересборка хранилища
-пересборка хранилища сохраняла в Kafka сообщения и офсеты прежнего мира, потому
+сохраняла в Kafka сообщения и офсеты прежнего мира, потому что чинила только
-что чинила только ClickHouse. Позиция пульта правилась снаружи Airflow — тем,
+ClickHouse. Позиция на оси правилась снаружи Airflow — тем, кто миром не
-кто миром не управляет.
+управляет.
 
 **Чему учит переезд.** Менти видит один наблюдаемый граф, которому принадлежат
 прикладная схема, данные мира и позиция модельного времени, — и Compose,
@@ -63,7 +63,7 @@ Airflow держит прикладные топики Kafka, каноничес
 
 Каталог `/opt/airflow/world` — то, что нужно для создания мира: `generator/`,
 `data/` и корневой `.dockerignore` смонтированы только для чтения. Из первого
-собирается канонический образ генератора, из второго читается опись мира, а
+собирается канонический образ генератора, из второго читается паспорт мира, а
 последний не пускает в контекст сборки локальные окружения и кэши. Запросы
 стенда приезжают прежним монтированием `sql/`.
 
@@ -101,7 +101,7 @@ Kafka, `SQLExecuteQueryOperator` для исполняемых SQL-файлов
    кода: сборкой образа при подъёме больше никто не занимается.
 5. Играет стартовые дни одним прогоном `batch` того же образа.
 6. Ждёт, пока события доедут до ODS. Условие ожидания то же, что у прежнего
-   сценария, и оно точное: сумма строк `ods.event_dist` за даты описи и строк
+   сценария, и оно точное: сумма строк `ods.event_dist` за даты паспорта и строк
    `ods.event_errors_dist` не меньше суммы событий из
    [`data/world-inventory.json`](../../data/world-inventory.json). «Что-то
    приехало» условием не считается.
@@ -136,21 +136,21 @@ Kafka, `SQLExecuteQueryOperator` для исполняемых SQL-файлов
 третьим местом с той же последовательностью, а первое же расхождение между
 дагами пришлось бы прятать в его параметрах.
 
-### Сторожа у работников мира
+### Сторожа у шаговых дагов
 
 `world_next_day` и `world_live_day` краснеют, если позиции нет либо она меньше
 `WORLD_STARTING_DAYS`. Отказ называет прочитанное значение и следующий шаг:
-поднять стенд или пересобрать хранилище. Выключатель `world_live` своего
+поднять стенд или пересобрать хранилище. Выключатель `world_live` своего сторожа
-сторожа не получает — он краснеет вслед за работником.
+не получает — он краснеет вслед за шаговым дагом.
 
 `orders_ingest` сторожа не получает вовсе: его зовёт сама инициализация, когда
 готового мира ещё нет.
 
 ## Состояния позиции
 
-`world_position` остаётся единственным состоянием пульта.
+`world_position` остаётся единственным состоянием дагов модельного времени.
 
-| Позиция | `world_initialize` | `world_recreate` | Работники |
+| Позиция | `world_initialize` | `world_recreate` | Шаговые даги |
 |---|---|---|---|
 | переменной нет | создаёт мир | очищает и создаёт | красный отказ |
 | `-1` | красный отказ: очистка не завершена, повторите `make rebuild-storage` | очищает и создаёт | красный отказ |
@@ -187,9 +187,9 @@ Kafka, `SQLExecuteQueryOperator` для исполняемых SQL-файлов
 ClickHouse, они состоят в группах потребителей, и удаление группы недопустимо.
 Поэтому сначала удаляются базы, затем топики.
 
-**Позицию удалили руками на живом мире.** Даг честно зальёт мир заново: сырьё
+**Позицию удалили руками на живом мире.** Даг честно зальёт мир заново: число
-в STG удвоится, ODS схлопнет повтор дедупликацией. Условие ожидания на непустом
+строк STG удвоится, ODS схлопнет повтор дедупликацией. Условие ожидания на
-ODS истинно сразу — этим оно и ограничено, обещание «доехала именно эта
+непустом ODS истинно сразу — этим оно и ограничено, обещание «доехала именно эта
 заливка» ни один счёт дать не может. Сторожа на этот случай нет: ошибку менти
 делает себе сам и тут же видит.
 
@@ -197,10 +197,10 @@ ODS истинно сразу — этим оно и ограничено, об
 `world_initialize`, тот ждет `etl_pipeline`, а конвейер ждет слой. В живом
 режиме такую же цепочку образуют `world_live`, `world_live_day`, `etl_pipeline`
 и слой. В обоих случаях три ожидающие задачи оставляют слою последний слот.
-Одновременная пересборка добавляет ожидания и загоняет стенд в тупик.
+Одновременная пересборка добавляет ожидания и загоняет стенд в тупик. Поэтому
-Поэтому пересборка — явная операция обслуживания: оператор ставит `world_live`
+пересборка — явная операция обслуживания: оператор ставит `world_live` на паузу
-на паузу и даёт работникам доиграть. Предусловие остаётся в документации;
+и даёт шаговым дагам доиграть. Предусловие остаётся в документации; механизм
-механизм блокировок стоил бы дороже этой строки.
+блокировок стоил бы дороже этой строки.
 
 ## Границы
 
@@ -226,9 +226,9 @@ ODS истинно сразу — этим оно и ограничено, об
   позиция та же, счётчики `check-clickhouse` те же, в журнале дага сказано, что
   мир уже есть.
 - **`make rebuild-storage`** возвращает канонический мир: позиция проходит
-  `-1` → `0` → `WORLD_STARTING_DAYS`, в ODS ровно даты описи, топики созданы
+  `-1` → `0` → `WORLD_STARTING_DAYS`, в ODS ровно даты паспорта, топики созданы
   заново, офсеты групп идут с нуля, DDS и DM собраны.
-- **Красные пути проверяются своими отказами.** Сторож работника при
+- **Красные пути проверяются своими отказами.** Сторож шагового дага при
   отсутствующей, нулевой и отрицательной позиции; `world_initialize` на `-1`;
   оборванная очистка, оставляющая `-1`. Проверка, не видевшая своей поломки,
   доказывает только то, что умеет печатать «ЗЕЛЁНО».

docs/specs/2026-09-01-labs-program.md

@@ -104,14 +104,14 @@
 
 ### Ступень 6. Разбери сырые события и сверь результат со стендом
 
-Менти пакетно разбирает срез сырья событий в собственную таблицу и построчно
+Менти пакетно разбирает срез событий из STG в собственную таблицу и построчно
 сверяет результат с нетронутым стендовым ODS. Урок — изучить разбор потока
 отдельно от живого приема и использовать стендовый результат как образец для
 сверки. Матвью разбора остаются несущей стеной: их пересоздание молча теряет
 сообщения.
 
 Форма — «собери рядом». Обратная связь — построчная сверка двух разборов. Ее
-границы называются прямо: срок работы ограничен окном хранения сырья, а
+границы называются прямо: срок работы ограничен окном хранения сырых данных, а
 содержимое неопорных колонок можно сравнить только со стендовым разбором, не с
 независимым эталоном.
 
@@ -150,7 +150,8 @@
 - **Какая позиция объясняет разницу в сумме.** Расхождение суммы нужно
   разложить до конкретной вычеркнутой позиции и объяснить до копейки.
 - **Был ли отмененный заказ оплачен.** Текущее состояние не заменяет историю, а
-  некоторые различия после истечения срока сырья уже не восстановить.
+  некоторые различия после истечения срока хранения сырых данных уже не
+  восстановить.
 - **Когда отчет за день можно считать окончательным (#188).** Отчет за день
   становится окончательным лишь после того, как источник больше не может
   изменить этот день.
@@ -171,7 +172,7 @@
 Открывается после ступени 2 основной программы.
 
 - **Свой дашборд.** Готовая лаба
-  [`docs/labs/superset-dashboard.md`](../labs/superset-dashboard.md) учит
+  [`docs/labs/optional/superset-dashboard.md`](../labs/optional/superset-dashboard.md) учит
   хранить пользовательские объекты отдельно от стендовых.
 - **Почему дашборд не видит объект на второй ноде.** Забытый `ON CLUSTER` может
   остаться незаметным до тех пор, пока дашборд не обратится ко второй ноде.
@@ -191,7 +192,8 @@
   потребителей создает еще одну полную копию потока.
 - **Как заметить пропущенные сообщения по офсетам.** Разрыв в офсетах
   показывает потерю, которую трудно заметить по самим данным.
-- **Почему сырье удаляется по времени загрузки.** Очистка сырья живет по
+- **Почему сырые данные удаляются по времени загрузки.** Очистка сырых данных
+  идёт по
   времени загрузки, а не по модельному дню.
 - **Куда попадают битые строки.** Годные строки и брак делят поток без
   пропусков и пересечений; менти подкладывает по строке каждого класса брака

generator/README.md

@@ -64,8 +64,8 @@
 - `src/clickstream_generator/schema_doc.py` — сборка «описания выгрузки»
   ([`docs/formats/clickstream-event.md`](../docs/formats/clickstream-event.md))
   из контракта. Документ руками не правят — пересобирают.
-- `src/clickstream_generator/inventory.py` — сборка описи мира
+- `src/clickstream_generator/inventory.py` — сборка паспорта мира
-  ([`data/world-inventory.json`](../data/world-inventory.json)): паспорт мира
+  ([`data/world-inventory.json`](../data/world-inventory.json)): шапка паспорта
   и хеши восьми дней, которыми наполняется стенд, плюс счётчики классов
   расхождений по заказам для дней с закрытым окном. Руками не правят —
   пересобирают целью `make inventory`.
@@ -77,7 +77,9 @@
 
 ## Команды
 
-Проиграть день — [быстрый старт](../README.md#как-позвать-генератор) и `--help`.
+Проиграть день — раздел [«Как запустить
+генератор»](../docs/architecture/world.md#как-запустить-генератор)
+справочника мира и `--help`.
 
 Из этого каталога — цели генератора живут здесь, а не в корне:
 
@@ -86,7 +88,7 @@
 - `make typecheck` — ty: проверка типов;
 - `make demo` — пройти стадии канонического D0 на одном экране;
 - `make docs` — пересобрать описание выгрузки;
-- `make inventory` — пересобрать опись мира.
+- `make inventory` — пересобрать паспорт мира.
 
 В корне репозитория `make lint` тоже есть, но он про код стенда — даги и
 Superset. Одноимённые цели за разными дверями охватывают разное:

generator/src/clickstream_generator/inventory.py

@@ -1,15 +1,15 @@
-"""Опись мира: чем стенд наполняется при подъёме и каким это обязано выйти.
+"""Паспорт мира: чем стенд наполняется при подъёме и каким это обязано выйти.
 
 Мир — чистая функция зерна (спека генератора, раздел 2), поэтому в git лежит не
-он сам, а опись: паспорт мира, число событий и хеш байтов каждого дня, счётчики
+он сам, а паспорт: шапка, число событий и хеш байтов каждого дня, счётчики
-классов расхождений по заказам. Сам мир пересчитывается когда угодно, а опись
+классов расхождений по заказам. Сам мир пересчитывается когда угодно, а паспорт
 отвечает на единственный вопрос — **тот ли это мир, что был вчера**. Разошлись
 хеши — мир уехал, и дальше уже неважно, чего от него ждали проверки.
 
-Дней в описи восемь: столько заливается в стенд при `make up`. Понедельник по
+Дней в паспорте восемь: столько заливается в стенд при `make up`. Понедельник по
 понедельник — полная неделя с выходными и первый замкнутый цикл окна K = 7.
 Это и есть эталонный мир: обещание в четырнадцать дней снято на этапе 7 —
-у хвоста не нашлось читателя. Понадобится длиннее — опись продолжит этот
+у хвоста не нашлось читателя. Понадобится длиннее — паспорт продолжит этот
 же файл, а не заведет второй.
 
 **Сторожат мир хеши, а не паспорт.** Паспорт отвечает на другой вопрос — «чем
@@ -30,9 +30,9 @@
 Слепок заказов — второй артефакт мира, и хешами дней он не покрыт ни при каком
 раскладе подпотоков, поэтому у каждого отправленного слепка своя строка. Их на
 один меньше, чем дней: прогон дня 0 отправлять ещё нечего. Счёта строк у
-слепка нет — опись описывает мир, а не доставку.
+слепка нет — паспорт описывает мир, а не доставку.
 
-Собирается опись из каталога генератора целью `make inventory`, а свежесть её
+Собирается паспорт из каталога генератора целью `make inventory`, а его свежесть
 сторожит тест — как и у «описания выгрузки».
 """
 
@@ -57,7 +57,7 @@ STARTING_DAYS = 8
 
 
 def build() -> dict[str, Any]:
-    """Опись целиком: паспорт мира, строка на день и строка на слепок.
+    """Паспорт целиком: шапка, строка на день и строка на слепок.
 
     Дни играются по одному и отпускаются: заказы дня остаются, потому что из
     них собираются слепки, а полсотни тысяч событий восьми дней сразу в память
@@ -83,12 +83,12 @@ def build() -> dict[str, Any]:
 
 
 def render() -> str:
-    """Опись текстом файла: отступы в два пробела, кириллица как есть."""
+    """Паспорт текстом файла: отступы в два пробела, кириллица как есть."""
     return json.dumps(build(), ensure_ascii=False, indent=2) + "\n"
 
 
 def _day(number: int, today: day_module.Day) -> dict[str, Any]:
-    """Строка описи: номер дня, его дата, число событий и хеш байтов.
+    """Строка паспорта: номер дня, его дата, число событий и хеш байтов.
 
     Дата считается от D0 арифметикой, а не берётся из событий: ось модельного
     времени так и определена (`world.ORIGIN`), и по этой же дате счётчики
@@ -105,7 +105,7 @@ def _day(number: int, today: day_module.Day) -> dict[str, Any]:
 
 
 def _snapshot(number: int, orders: list[orders_module.Orders]) -> dict[str, Any]:
-    """Строка описи слепка: какой день снят, его дата и хеш отправленных байтов.
+    """Строка паспорта слепка: какой день снят, его дата и хеш отправленных байтов.
 
     Байты те же, что уезжают в топик `orders`, с переводом строки после
     каждого заказа: пересъёмка слепка обязана дать их снова.
@@ -169,12 +169,12 @@ def _digest(payload: bytes) -> str:
 
 def main() -> None:
     parser = argparse.ArgumentParser(
-        description="Собирает опись мира: паспорт, счётчики и хеши дней."
+        description="Собирает паспорт мира: шапку, счётчики и хеши дней."
     )
-    parser.add_argument("output", type=Path, help="путь к файлу описи")
+    parser.add_argument("output", type=Path, help="путь к файлу паспорта")
     output = parser.parse_args().output
     output.write_text(render(), encoding="utf-8")
-    print(f"Опись мира собрана: {output}")
+    print(f"Паспорт мира собран: {output}")
 
 
 if __name__ == "__main__":

generator/src/clickstream_generator/player.py

@@ -15,7 +15,7 @@
 Тайминги печатаются раздельно — генерация и доставка, как требует спека
 (раздел 5): это разные машины разной природы, и сложенные в одно число они
 перестают что-либо говорить. Сериализация считается частью генерации: она
-рождает те самые байты, которые сторожит опись.
+рождает те самые байты, которые сторожит паспорт.
 
 **Слепки заказов идут третьим ходом того же проигрывателя** и живут по правилу
 сдвига: прогон дня D отправляет слепок дня D−1 — ночная выгрузка бэкенда за

generator/src/clickstream_generator/seeds.py

@@ -25,8 +25,8 @@ from enum import IntEnum
 
 import numpy as np
 
-# Каноническое зерно эталонного мира — константа репозитория; опись хранит
+# Каноническое зерно эталонного мира — константа репозитория; паспорт хранит
-# его в паспорте мира. Свои зёрна менти крутит без гарантий описи.
+# его в своей шапке. Свои зёрна менти крутит без гарантий паспорта.
 CANONICAL_SEED = 20260601
 
 

generator/src/clickstream_generator/serialize.py

@@ -18,7 +18,7 @@
   строгий приём хранилища сверяет набор ключей (ADR 0005).
 - **Даты и время — ISO-8601** (спека, раздел 4): `EventDate` уезжает как
   `2026-06-01`, `UTCEventTime` — как `2026-06-01T12:34:56Z`. Довод — читаемость
-  сырья: менти открывает колонку `raw` обычным клиентом и разбирает событие
+  сырых данных: менти открывает колонку `raw` обычным клиентом и разбирает событие
   глазами, а число эпохи этот урок убивает.
 - **Одно событие — один документ JSON**, без перевода строки внутри: приёмник
   сам решает, чем их разделить.

generator/src/clickstream_generator/world.py

@@ -2,8 +2,8 @@
 
 Модуль — приглашение крутить: поменяйте число, пересоберите снимок и
 посмотрите, что стало с данными. Правка любой константы здесь — смена мира,
-поэтому чек описи честно покраснеет: опись сторожит только канонический мир,
+поэтому чек паспорта честно покраснеет: паспорт сторожит только канонический мир,
-свои миры менти собирает без её гарантий (спека генератора, раздел 9).
+свои миры менти собирает без его гарантий (спека генератора, раздел 9).
 
 Числа решены спекой и связаны между собой; связки сторожат тесты
 `test_world.py`, чтобы правка одного числа не рассыпала вывод соседнего.
@@ -28,7 +28,7 @@ COUNTER_TIMEZONE_MINUTES = 240  # Europe/Samara
 # D0 — первый день оси модельного времени, понедельник. Реальный календарь в
 # модели не участвует: дата нужна лишь затем, чтобы дни оси легли в
 # `EventDate`/`UTCEventTime` конкретными числами. От даты запуска мир не
-# зависит — иначе опись перестала бы быть воспроизводимой.
+# зависит — иначе паспорт перестал бы быть воспроизводимым.
 ORIGIN = date(2026, 6, 1)
 
 # Окно изменяемости заказа, модельные дни: слепок бэкенда несёт заказы,

generator/tests/test_demo.py

@@ -5,7 +5,7 @@ from pathlib import Path
 
 
 def test_demo_runs_and_shows_the_whole_chain() -> None:
-    """Сторожит команду и стадии, а числа мира оставляет описи."""
+    """Сторожит команду и стадии, а проверку чисел мира оставляет паспорту."""
     finished = subprocess.run(
         ["make", "--silent", "demo"],
         check=False,

generator/tests/test_inventory.py

@@ -1,7 +1,7 @@
-"""Проверка описи мира: та ли она, что собирается из кода сегодня.
+"""Проверка паспорта мира: совпадает ли он с тем, что собирается из кода сегодня.
 
-Опись собирается из кода, значит разойтись они могут только одним способом —
+Паспорт собирается из кода, значит разойтись они могут только одним способом —
-код правили, опись не пересобрали. Ровно это здесь и сторожится, тем же
+код правили, паспорт не пересобрали. Ровно это здесь и сторожится, тем же
 способом, что свежесть «описания выгрузки».
 
 Проверка дорогая — она пересчитывает восемь модельных дней целиком, и это
@@ -23,24 +23,24 @@ from clickstream_generator.seeds import CANONICAL_SEED
 
 INVENTORY_PATH = Path(__file__).resolve().parents[2] / "data" / "world-inventory.json"
 
-# Прогон, слепок которого сверяется с описью байт в байт. День любой из
+# Прогон, слепок которого сверяется с паспортом байт в байт. День любой из
 # отправляемых; этот дешевле прочих — его окно короче.
 RUN_DAY = 2
 
-# День любой: хеш дня не зависит ни от соседей, ни от края описи.
+# День любой: хеш дня не зависит ни от соседей, ни от края паспорта.
 REPLAY_DAY = 4
 
 
 @pytest.fixture(scope="module")
 def inventory() -> dict:
-    """Опись, собранная из кода: мир пересчитывается один раз на весь модуль."""
+    """Паспорт, собранный из кода: мир пересчитывается один раз на весь модуль."""
     return build()
 
 
 def test_inventory_is_up_to_date(inventory: dict):
     stored = json.loads(INVENTORY_PATH.read_text(encoding="utf-8"))
     assert stored == inventory, (
-        "опись мира отстала от кода — пересоберите: make inventory."
+        "паспорт мира отстал от кода — пересоберите: make inventory."
         " Разошлись хеши дней и каталога — правили data/catalog/products.csv;"
         " разошлись только дни — правили генератор"
     )
@@ -68,7 +68,7 @@ def test_the_inventory_holds_the_hash_of_every_sent_snapshot(inventory: dict, tm
     """У каждого отправленного слепка — своя строка с хешем его байтов.
 
     Байты слепка не покрыты хешами дней ни при каком раскладе подпотоков: это
-    второй артефакт мира, и побайтовое обещание сторожит опись. Слепков на день
+    второй артефакт мира, и побайтовое обещание сторожит паспорт. Слепков на день
     меньше, чем дней: прогон дня 0 не отправляет ничего.
 
     Хеш сверяется с настоящей выгрузкой, а не с самим собой: в файл уезжают те
@@ -86,7 +86,7 @@ def test_the_inventory_holds_the_hash_of_every_sent_snapshot(inventory: dict, tm
 
 
 def test_a_replayed_day_matches_its_inventory_hash(tmp_path):
-    """Опись сверяется с байтами, вышедшими из CLI, а не с собранной тут же:
+    """Паспорт сверяется с байтами, вышедшими из CLI, а не с собранной тут же:
     пересчет сравнивался бы сам с собой.
     """
     stored = json.loads(INVENTORY_PATH.read_text(encoding="utf-8"))

generator/tests/test_serialize.py

@@ -28,7 +28,7 @@ def test_every_event_carries_every_column(events):
 
     «Пусто» по контракту — пустое значение, а не отсутствие ключа: пропавший
     ключ уводит событие в брак целиком (ADR 0005). Порядок ключей — часть
-    канона: от него зависят байты, а значит и хеши описи.
+    канона: от него зависят байты, а значит и хеши паспорта.
     """
     names = [column.name for column in schema.COLUMNS]
     for event in events:

generator/tests/test_snapshot.py

@@ -167,7 +167,7 @@ def test_the_moments_carry_real_milliseconds(days: list[day_module.Day]):
 def test_the_rows_go_in_the_order_of_birth(days: list[day_module.Day]):
     """Порядок строк слепка — порядок рождения заказов, он же рост номера.
 
-    Хешу слепка в описи нужен именно названный порядок: детерминизм даёт его
+    Хешу слепка в паспорте нужен именно названный порядок: детерминизм даёт его
     даром, но обещание побайтового повтора держится на нём, а не на удаче.
     """
     numbers = [record["order_id"] for record in snapshot_records(days, FULL_WINDOW_DAY)]

infra/grafana/provisioning/dashboards/data.json

@@ -104,7 +104,7 @@
     },
     {
       "type": "timeseries",
-      "title": "Поток: сколько строк приезжает в слой сырья",
+      "title": "Поток: сколько строк приезжает в сырой слой",
       "datasource": {
         "type": "grafana-clickhouse-datasource",
         "uid": "clickhouse"

scripts/check-clickhouse.sh

@@ -102,12 +102,12 @@ on_signal() {
 # Единственный постоянный сторож цепочки Kafka → STG → ODS.
 #
 # Проверка спрашивает не «есть ли данные», а «те ли это данные»: подневный счёт
-# в `ods.event` против описи мира, лежащей в git. Поэтому она умеет краснеть на
+# в `ods.event` против паспорта мира, лежащего в git. Поэтому она умеет краснеть на
 # сломанном разборе — уехали события в брак, счёт разошёлся, — и на потере по
 # дороге, а не только на пустой таблице.
 #
 # **Счёт обрамлён датами стартового мира.** Мир растёт: менти переиграет день,
-# этап 5 добавит следующий, — и голый счёт по таблице разойдётся с описью
+# этап 5 добавит следующий, — и голый счёт по таблице разойдётся с паспортом
 # законно, без всякой поломки.
 #
 # **Счёт идёт через ods.event_v** — каноническую поверхность актуального
@@ -138,7 +138,7 @@ check_starting_world() {
         FORMAT TSV")"
 
     if [[ "$actual" == "$expected" ]]; then
-        printf 'ЗЕЛЁНО: события всех дней стартового мира на месте, счёт сходится с описью.\n'
+        printf 'ЗЕЛЁНО: события всех дней стартового мира на месте, счёт сходится с паспортом.\n'
         return
     fi
 
@@ -148,13 +148,13 @@ check_starting_world() {
         GROUP BY error_class
         ORDER BY count() DESC
         FORMAT TSV")"
-    printf 'Опись мира ожидает (дата, событий):\n%s\n' "$expected" >&2
+    printf 'Паспорт мира ожидает (дата, событий):\n%s\n' "$expected" >&2
     printf 'В ods.event лежит:\n%s\n' "${actual:-— ничего —}" >&2
     if [[ -z "$broken" ]]; then
-        fail 'счёт разошёлся с описью, а таблица брака пуста: события не доехали до ODS — начните с чтеца топика stg.hits_raw_kafka и матвью приёма stg.hits_raw_mv'
+        fail 'счёт разошёлся с паспортом, а таблица брака пуста: события не доехали до ODS — начните с чтеца топика stg.hits_raw_kafka и матвью приёма stg.hits_raw_mv'
     fi
     printf 'В ods.event_errors по классам брака:\n%s\n' "$broken" >&2
-    fail 'счёт разошёлся с описью, и в таблице брака есть строки. Сойдётся недостача с их числом — сломан разбор, смотрите матвью ods.event_mv; не сойдётся — брак остался от прежних опытов, а события не доехали: смотрите чтеца топика stg.hits_raw_kafka'
+    fail 'счёт разошёлся с паспортом, и в таблице брака есть строки. Сойдётся недостача с их числом — сломан разбор, смотрите матвью ods.event_mv; не сойдётся — брак остался от прежних опытов, а события не доехали: смотрите чтеца топика stg.hits_raw_kafka'
 }
 
 assert_ddl_queue_completed() {
@@ -282,7 +282,7 @@ assert_equal "$expected_product" "$(query_as_etl clickhouse-01 "$product_sql")"
 assert_equal "$expected_product" "$(query_as_etl clickhouse-02 "$product_sql")" "словарь товаров не ответил на второй ноде"
 printf 'ЗЕЛЁНО: известный sku вернул имя, категорию и цену на обеих нодах.\n'
 
-printf 'Проверка 10/10: стартовый мир в ods.event сходится с описью...\n'
+printf 'Проверка 10/10: стартовый мир в ods.event сходится с паспортом...\n'
 check_starting_world
 
 printf 'ИТОГ: все 10 проверок кластера ClickHouse прошли.\n'

sql/ddl/10-stg-tables.sql

@@ -1,6 +1,6 @@
--- STG: чтецы топиков hits и orders, таблицы сырья обоих источников.
+-- STG: чтецы топиков hits и orders, таблицы STG обоих источников.
 --
--- Слой сырья ничего не интерпретирует: сообщение ложится строкой, как пришло,
+-- Сырой слой ничего не интерпретирует: сообщение ложится строкой, как пришло,
 -- рядом с метаданными доставки. Довод целиком — ADR 0005, конвенции колонок и
 -- сроков — docs/architecture/storage.md.
 
@@ -30,9 +30,9 @@ SETTINGS
     kafka_group_name = 'clickstream_hits',
     kafka_format = 'RawBLOB';
 
--- Локальная таблица сырья.
+-- Локальная таблица STG.
 --
--- Движок именно ReplicatedMergeTree, не Replacing: повтор доставки в сырье
+-- Движок именно ReplicatedMergeTree, не Replacing: повтор доставки в STG
 -- обязан быть виден — ради этого слой и заведён.
 --
 -- Служебные колонки не повторяют имён виртуальных (_topic, _partition,
@@ -45,7 +45,7 @@ SETTINGS
 -- колонки _timestamp_ms, а не из _timestamp. Измерено на стенде 5 августа
 -- 2026 года: _timestamp — Nullable(DateTime), то есть секунды; _timestamp_ms —
 -- Nullable(DateTime64(3)). Взяты миллисекунды: у брокера метка миллисекундная,
--- _load_ts рядом тоже миллисекундная, а слой сырья хранит то, что приехало, и
+-- _load_ts рядом тоже миллисекундная, а сырой слой хранит то, что приехало, и
 -- округлять ему нечего. Обнуляемость обязательна: метку брокер заполняет не
 -- всегда, а необнуляемый тип дал бы либо падение приёма, либо тихий 1970 год.
 --
@@ -115,8 +115,8 @@ SETTINGS
     kafka_format = 'RawBLOB',
     kafka_commit_on_select = 1;
 
--- Локальная таблица сырья заказов. Колонки, типы, ключ, нарезка и срок жизни —
+-- Локальная таблица STG заказов. Колонки, типы, ключ, нарезка и срок жизни —
--- те же, что у сырья событий, и по тем же доводам: docs/architecture/storage.md.
+-- те же, что у STG событий, и по тем же доводам: docs/architecture/storage.md.
 --
 -- Своя колонка здесь одна — _load_id, идентификатор пачки загрузки: он равен
 -- run_id прогона Airflow, который забрал порцию, и по нему разбор в ODS читает

sql/ddl/20-ods-tables.sql

@@ -106,7 +106,7 @@ SAMPLE BY intHash32(ClientID);
 -- События одной куки при этом остаются на одном шарде, и сессионизация со
 -- склейкой идентичностей ниже по течению живут локально.
 --
--- У сырья ключ другой (хеш строки), поэтому сырая строка и разобранное из неё
+-- У STG ключ другой (хеш строки), поэтому сырая строка и разобранное из неё
 -- событие почти всегда лежат на разных шардах. Пошардовые счётчики слоёв
 -- сходиться не должны — сверять слои можно только через _dist.
 CREATE TABLE IF NOT EXISTS ods.event_dist ON CLUSTER clickstream_cluster
@@ -125,10 +125,10 @@ ENGINE = Distributed('clickstream_cluster', 'ods', 'event_rep', cityHash64(Clien
 -- Ключи собственные. Шардирование — cityHash64(raw): ClientID у неразобранной
 -- строки взять неоткуда. ORDER BY (error_class, kafka_partition,
 -- kafka_offset): такую таблицу смотрят от класса брака, а внутри класса — по
--- координатам доставки. Нарезка по дню загрузки, как у сырья: модельного дня
+-- координатам доставки. Нарезка по дню загрузки, как у STG: модельного дня
 -- у брака тоже нет.
 --
--- Срок жизни — месяц, вдесятеро дольше сырья. Истеки брак вместе с сырьём —
+-- Срок жизни — месяц, вдесятеро дольше сырых данных. Истеки брак вместе с ними —
 -- к моменту разбирательства не осталось бы ни того, ни другого.
 CREATE TABLE IF NOT EXISTS ods.event_errors_rep ON CLUSTER clickstream_cluster
 (

sql/ddl/30-ods-views.sql

@@ -25,7 +25,7 @@ AS
 SELECT *
 FROM ods.order_dist FINAL;
 
--- ODS: разбор сырья в событие и в таблицу ошибок.
+-- ODS: разбор STG в событие и в таблицу ошибок.
 --
 -- Матвью две, и вместе они обязаны делить поток без зазора и без нахлёста:
 -- строка, подошедшая обеим, задвоится, а не подошедшая ни одной — исчезнет
@@ -168,7 +168,7 @@ SELECT
     JSONExtract(raw, 'productQuantity', 'Array(UInt64)') AS productQuantity,
     JSONExtract(raw, 'productEventType', 'Array(String)') AS productEventType,
     JSONExtract(raw, 'ecommerce', 'String') AS ecommerce,
-    -- Метка загрузки переносится из сырья как есть, а не ставится заново:
+    -- Метка загрузки переносится из STG как есть, а не ставится заново:
     -- она отвечает на вопрос «когда строка приехала в хранилище». Поставь
     -- здесь now64(3) — и колонка версии молча ответила бы на другой вопрос.
     _load_ts

sql/ddl/40-stg-views.sql

@@ -1,10 +1,10 @@
--- STG: матвью приёма — из чтеца в сырьё.
+-- STG: матвью приёма — из чтеца в таблицу STG.
 --
 -- Номер 40, а не 11, и пропуск в нумерации намеренный. Файлы 20-ods-tables.sql
 -- и 30-ods-views.sql приносит #43, и матвью приёма обязана создаваться после
 -- матвью разбора: Kafka-движок начинает читать топик ровно тогда, когда к нему
 -- привязывают первую матвью. Создай её раньше разбора — и всё, что доедет в
--- зазоре, ляжет в сырьё и не попадёт в ODS никуда, ни в событие, ни в ошибки.
+-- зазоре, ляжет в STG и не попадёт в ODS никуда, ни в событие, ни в ошибки.
 -- На пустом топике зазор безвреден, поэтому первый прогон о нём не скажет:
 -- проснётся он, когда тома ClickHouse снесены, а данные Kafka целы, то есть на
 -- обычной отладке. Нумерацию здесь не «приводить в порядок».

sql/dds/session_scope.sql

@@ -17,7 +17,7 @@
 -- Позиция — номер первого несыгранного дня, счётчик прожитого. Своей копии
 -- начала оси стенд из-за неё не заводит: начало он спрашивает у данных, и
 -- дата дня N в них — константа, начало оси плюс N. Держится якорь на том, что
--- ранние дни из ods.event не исчезают: срок жизни назначен сырью и таблицам
+-- ранние дни из ods.event не исчезают: срок жизни назначен сырым данным и таблицам
 -- ошибок, самому событию — нет (sql/ddl/20-ods-tables.sql).
 --
 -- За «доехал» позиция не отвечает — только за «прожит». Перед расчётом объёма

sql/dq/classes_vs_inventory.sql

@@ -1,8 +1,8 @@
--- DQ: стендовая сторона технической растяжки от описи мира.
+-- DQ: стендовая сторона технической растяжки от паспорта мира.
 --
 -- Эталонные счётчики читает Airflow из world-inventory.json: у настоящего
 -- магазина такого оракула нет. Запрос возвращает только наблюдаемую сторону;
--- Python-задача сопоставляет ее с пятью счетчиками закрытого дня из описи.
+-- Python-задача сопоставляет ее с пятью счетчиками закрытого дня из паспорта.
 SELECT
     order_day AS data_date,
     mismatch_class,

sql/ods/order_parse.sql

@@ -124,7 +124,7 @@ SELECT
     _load_ts
 FROM stg.orders_raw_dist
 WHERE _load_id = {load_id:String} AND NOT row_is_valid
--- Тот же ноль: ключ брака сегодня совпадает с ключом сырья, и локальная
+-- Тот же ноль: ключ брака сегодня совпадает с ключом STG, и локальная
 -- запись легла бы верно — но по совпадению, а не по контракту.
 SETTINGS distributed_foreground_insert = 1,
     parallel_distributed_insert_select = 0;

sql/stg/orders_raw_load.sql

@@ -1,4 +1,4 @@
--- Забор порции слепка заказов из Kafka в сырьё STG.
+-- Забор порции слепка заказов из Kafka в STG.
 --
 -- Забор — один прямой SELECT, без цикла до пустоты: одна порция ClickHouse
 -- берёт десятки тысяч сообщений, а слепок дня — порядка полутора тысяч строк.