docs(storage): приняты решения по приёму событий и именам

- Зачем:
  - тикет #37 молча опирался на конвенции хранилища, которых в проекте не
    было; без них #43 и следующие этапы разъехались бы в именах, служебных
    колонках и механике приёма.
- Что:
  - ADR 0005: топик читается байтами в STG, разбор идёт функциями в матвью
    ODS; строгий приём — сверка набора ключей плюс Nullable на пяти опорных
    колонках.
  - ADR 0006: суффикс вида в именах объектов (_rep, _dist, _kafka, _mv, _v).
  - docs/architecture/storage.md: конвенции имён и служебных колонок, путь в
    keeper, раскладка по шардам, срок жизни сырья, свойства приёма, раскладка
    файлов DDL и карта таблиц.
  - спеки приведены в соответствие: механизм строгого приёма, имена объектов,
    контракт транспорта «одно событие — одно сообщение Kafka», три проверки
    при исполнении.
- Проверка:
  - make config-test

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

@@ -309,11 +309,16 @@ CSV в репозитории (`data/catalog/products.csv`: `sku`, `name`, `cate
 - **Приём Kafka**: Kafka-таблицы и MV — на обеих нодах, одна consumer group,
   2 партиции на топик; MV пишут в Distributed-цели. Раскладку решает ключ:
   события — по `cityHash64(ClientID)` (см. 1.3), заказы —
-  `cityHash64(order_id)`, сырьё STG —
-  `cityHash64(сырой строки)`. Урок: «какая нода читала топик — меняется между
-  прогонами, куда легли данные — нет».
-- **Приём строгий**: `input_format_skip_unknown_fields = 0`, обязательные
-  поля — без значений по умолчанию. Контракт присутствия: генератор выдаёт
+  `cityHash64(order_id)`, сырьё STG — `cityHash64(сырой строки)`; полный
+  список и доводы — в [доке хранилища](../architecture/storage.md). Урок:
+  «какая нода читала топик — меняется между прогонами, куда легли данные — нет».
+- **Приём строгий**: обязательные поля разбираются как `Nullable`, а набор
+  ключей сообщения сверяется с контрактным; строка с NULL среди обязательных
+  полей или с разошедшимся набором ключей уходит в `*_errors`. Сверка ключей —
+  не добавка: у массивов NULL не бывает, и пропавшее поле-массив иначе
+  неотличимо от пустого по смыслу. На входе разбора нет вовсе — Kafka-таблица
+  читает сообщение байтами, строгость целиком в матвью ODS
+  ([ADR 0005](../adr/0005-event-ingestion.md)). Контракт присутствия: генератор выдаёт
   **все 47 полей в каждом событии**; «пусто» — пустой массив, пустая строка
   или 0, а не отсутствие ключа в JSON. Так строгий приём уживается с
   полями, пустыми по смыслу (ecommerce у `pageview`, UTM у прямого захода). Несовпадение имени поля — громкая
@@ -369,26 +374,32 @@ README.
 | Слой | Объект | Что это |
 |---|---|---|
 | Kafka | `hits`, `orders` | два топика, по 2 партиции |
-| STG | `stg.kafka_hits`, `stg.hits_raw` + MV; то же для orders | сырые строки, Kafka Engine на обеих нодах |
+| STG | `stg.hits_raw_kafka`, `stg.hits_raw` + MV; то же для orders | сырые строки, Kafka Engine на обеих нодах |
 | ODS | `ods.event` (+`_errors`) | типизированное широкое событие, ReplacingMergeTree |
 | ODS | `ods.order_snapshot` (+`_errors`) | слепки заказов как приехали, партиция по `snapshot_date`, без дедупа |
 | DDS | `dds.session` | сборка сессий из событий (наследник `dds.click`) |
-| DDS | `dds.v_event` | представление над `ods.event`: snake_case-имена, расшифровка кодов `DeviceCategory`; витрины DM читают его, а не ODS напрямую |
+| DDS | `dds.event_v` | представление над `ods.event`: snake_case-имена, расшифровка кодов `DeviceCategory`; витрины DM читают его, а не ODS напрямую |
 | DDS | `dds.order` | единственная дедуплицированная таблица заказа: партиция по дню заказа (`toDate(created_at)`), ReplacingMergeTree(`updated_at`), `ORDER BY order_id`, дедуп до последней версии — argMax в трансформации при сборке |
 | DDS | `dds.identity_map` | карта кука↔пользователь |
 | DDS | словарь `products` | каталог из CSV |
-| DM | витрины `dm.v_*`, `dm.dq_summary` | см. ниже |
+| DM | витрины `dm.*_v`, `dm.dq_summary` | см. ниже |
 
-Служебные колонки: `ods.event` и `ods.order_snapshot` получают метку приёма
-`_ingested_at`; у `ods.event` та же колонка — колонка версии
-ReplacingMergeTree. Таблицы `stg.*_raw` хранят виртуальные колонки Kafka
-(`_topic`, `_partition`, `_offset`, `_timestamp`) — без них урок «какая нода
-читала топик» ненаблюдаем. `stg.hits_raw` дополнительно хранит извлечённый
-`event_date` — им кормится переобработка дня X (при исчерпании retention
+У каждой таблицы слоя — пара из локальной и распределённой, имена по конвенции
+суффиксов; она же задаёт служебные колонки, нарезку и срок хранения сырья —
+см. [доку хранилища](../architecture/storage.md).
+
+Состав служебных колонок задаёт дока хранилища. Спеке важны два следствия:
+`ods.event` и `ods.order_snapshot` получают метку загрузки `_load_ts`, и у
+`ods.event` она же служит колонкой версии ReplacingMergeTree; а таблицы
+`stg.*_raw` хранят метаданные доставки Kafka вместе с именем читавшей ноды —
+без них урок «какая нода читала топик» ненаблюдаем.
+Модельного дня в STG нет: `EventDate` — свойство содержимого, а содержимое
+разбирает ODS, где эта колонка и служит ключом партиции. Переобработка режется
+по времени загрузки, координате самого слоя доставки. При исчерпании retention
 Kafka день переигрывается генератором заново: снимок — кэш чистой функции,
-см. [спеку генератора](2026-08-01-generator.md)).
+см. [спеку генератора](2026-08-01-generator.md).
 
-`dds.v_event` — первый на стенде пример правила «слой — это контракт, а не
+`dds.event_v` — первый на стенде пример правила «слой — это контракт, а не
 обязательно копия данных».
 
 Событие в DDS не дублируется: склейки четырёх источников больше нет, ODS уже
@@ -422,9 +433,9 @@ Kafka день переигрывается генератором заново:
 - **`v_daily_traffic`** — расширяется парой «посетители» / «известные
   пользователи» (обогащение через `dds.identity_map`, локальное соединение
   по ключу ко-локации).
-- `v_events_enriched`, `v_top_pages_daily`, `v_session_overview`,
-  `v_dq_errors_daily` — переезжают на новую модель без смены роли: источник —
-  `dds.v_event`, не `ods.event`.
+- `events_enriched_v`, `top_pages_daily_v`, `session_overview_v`,
+  `dq_errors_daily_v` — переезжают на новую модель без смены роли: источник —
+  `dds.event_v`, не `ods.event`.
 - `dm.dq_summary` переводится с TRUNCATE+INSERT на партиционную замену
   (политика «без TRUNCATE»).
 
@@ -465,7 +476,7 @@ v2 стартует пустым, поэтому объём ниже — это
 |---|---|---|
 | Генератор | с нуля: модель v1 не переносится (другая модель данных, плюс известные проблемы производительности v1); широкое событие, таксономия, анонимность, N:1, заказы слепками, расхождения A–D, каталог; масштаб — ~4–5 тыс. строк с тестами | L |
 | Инфраструктура | compose: 2 ноды CH + keeper + остальной стенд; конфиги кластера, макросы; make/скрипты | M — ~10–12 файлов |
-| SQL | 5 DDL-файлов (ON CLUSTER, Replicated*, Distributed) + трансформации событий, заказов, identity, сверки + словарь | L — ~12–15 файлов, главная сложность |
+| SQL | DDL по слоям и ролям (ON CLUSTER, Replicated*, Distributed; раскладка файлов — в доке хранилища) + трансформации событий, заказов, identity, сверки + словарь | L — ~12–15 файлов, главная сложность |
 | Airflow | DAG'и по образцу v1: etl_pipeline (партиционная переобработка, ожидание дневного батча заказов — сенсор/Datasets), world_init/next_day, helpers | M — ~5–6 файлов |
 | Superset | датасеты + дашборд с тремя новыми сюжетами | M — 2 файла |
 | Эталонный мир | пересборка снимка на месте, манифест-счётчики, чек-скрипты | M–L |
@@ -557,6 +568,11 @@ smoke-проверки, а не «дашборд зелёный». Это мин
   прогонами, отсутствие дублей при штатной работе.
 - Точная форма `ORDER BY` ODS-таблиц (выражение `intHash32` в ключе
   ReplacingMergeTree).
+- `RawBLOB` в Kafka-движке даёт ровно одну строку на сообщение (ADR 0005).
+- Матвью, привязанная к локальной таблице, срабатывает, когда строки приходят
+  вставкой через `Distributed`: на этом стоит цепочка STG → ODS (ADR 0005).
+- Форма именованного кортежа в `JSONExtract` с `Nullable`-членами — ею
+  сворачиваются 47 вызовов в один, если разбор окажется дорогим (ADR 0005).
 - Размер артефакта эталонного мира после пересборки.
 - Спорные API (Airflow Datasets/сенсоры, ClickHouse DDL) — перед кодом
   сверять через MCP Context7 (правило AGENTS.md).
@@ -610,6 +626,10 @@ v2, этап 0).
   синтетическая постановка — осознанный приём;
 - лекция «`Sign` и CollapsingMergeTree»: почему на стенде `sum(Sign)` =
   `count()`, а в бою — нет; частый вопрос на собеседованиях;
+- два способа принять топик, рядом на одном стенде: сырьё байтами с разбором
+  функциями (`hits`, [ADR 0005](../adr/0005-event-ingestion.md)) против
+  типизированного чтеца с `kafka_handle_error_mode` (заказы, этап 3) —
+  сравнение цены и наблюдаемости как задание;
 - лекция про идентичность «как в бою»: `setUserID` и first-party id,
   детерминированная против вероятностной склейки, identity graph,
   кросс-девайс, CDP — с рамкой «мы склеили через транзакции, потому что трекер

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

@@ -157,7 +157,7 @@
   строк; сверка — по хешам манифеста, а два локально пересобранных снимка
   сравнимы обычным diff — пустой означает «ничего не изменилось». Вне
   обещания — транспорт: офсеты и партиции Kafka, какая нода прочитала,
-  `_ingested_at`, темп живого дня.
+  `_load_ts`, темп живого дня.
 - **Условия обещания.** Детерминизм держится при зафиксированном `uv.lock`
   и внутри канонического контейнера — то есть везде Linux, на маке и в WSL
   тоже; единственная переменная — архитектура CPU. Истина — CI на Linux; сходимость любой машины проверяет
@@ -224,13 +224,13 @@
   менти несёт рендеренная таблица в доках, не модуль. Уточнение при
   исполнении (#36): нормализованное имя — имя источника, приведённое к
   нашему стилю, а не имя атрибута в модели данных. Слой DDS складывает свою
-  модель и называет атрибуты по ней; `dds.v_event` эти имена берёт (раздел 7
+  модель и называет атрибуты по ней; `dds.event_v` эти имена берёт (раздел 7
   мастер-спеки), но контракт их не диктует и тестами не сторожит.
 - **Сторона хранилища пишется по документации, не генерируется.** DDL
-  `ods.event`, SELECT матвью, `dds.v_event`, трансформации — работа
+  `ods.event`, SELECT матвью, `dds.event_v`, трансформации — работа
   следующих этапов по «описанию выгрузки», как в бою хранилище адаптируется
   к источнику. Границу сторожат два боевых механизма: строгий приём
-  (`input_format_skip_unknown_fields = 0`, таблицы `*_errors` — раздел 6
+  (`Nullable`-разбор со сверкой набора ключей, таблицы `*_errors` — раздел 6
   мастер-спеки) и contract-тест в smoke — сравнение `system.columns`
   поднятого стенда со схемой генератора.
 
@@ -254,6 +254,13 @@
   превращается в JSON. Приёмники не знают о содержимом: файл (локальный кэш
   для пересборки и проверок манифеста), Kafka пачкой — пакетный режим,
   Kafka с темпом ×60 — живой день. Новых топиков нет.
+- **Одно событие — одно сообщение Kafka.** «Пачкой» относится к темпу
+  отправки, а не к упаковке: приёмник шлёт события подряд без пауз, но каждое
+  отдельным сообщением. Контракт транспорта, не деталь реализации — сторона
+  хранилища читает топик байтами и кладёт сообщение строкой
+  ([ADR 0005](../adr/0005-event-ingestion.md)), поэтому склейка нескольких
+  событий в одно сообщение сломала бы разбор целиком. Сторожится тестом
+  приёмника.
 - **Рабочий выбор сериализатора — orjson**: быстрее stdlib json в 5–14 раз,
   numpy-массивы и datetime сериализует нативно (заметка исследования #31).
   Смена библиотеки меняет канонические байты, поэтому проходит как