docs(labs): переписана проза пяти ТЗ ступени 1 и раздел «Как принято»

- Зачем:
  - владелец при чтении забраковал прозу ТЗ ступени 1: образы вместо
    утверждений, заголовки-метафоры, договоренности стенда поданы как
    законы. Тикет #228.
- Что:
  - пять ТЗ (задания 1–5) написаны заново по форме ТЗ ступени 2:
    содержание, колонки, формулы, самопроверка и приемка сохранены.
  - раздел README лаб «Общие правила ступени 1» переименован в «Как принято
    на ступени 1» и переписан как выбор с доводом; точечно поправлены
    «Самопроверка» и таблица ступени 1.
- Проверка:
  - grep по «ё», «менти», формам «ты» и словам-законам по docs/labs/*.md
    молчит (единственное «правило» — в нетронутом разделе «Уборка»).
  - скрипт ссылок и якорей из #226 печатает пусто; git diff --check чист.
  - сверка имен в обратных кавычках и чекбоксов старых и новых файлов —
    без расхождений.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>

docs/labs/README.md

@@ -27,77 +27,73 @@
 
 | № | Результат | Чему учит |
 |---|---|---|
-| 1 | [`events_enriched_v`](events-enriched.md) | слой — это контракт, а не копия данных |
-| 2 | [`top_pages_daily`](top-pages-daily.md) | зерно сменилось — витрина материализуется и встает в конвейер |
-| 3 | [`session_overview`](session-overview.md) | зерно решает, на какие вопросы витрина уже не ответит |
-| 4 | [`dq_errors_daily`](dq-errors-daily.md) | у брака свой день и свой срок жизни |
-| 5 | [`utm_effectiveness`](utm-effectiveness.md) | `declared_` в имени — предупреждение, а не украшение |
+| 1 | [`events_enriched_v`](events-enriched.md) | строить слой как договор о данных, а не как их копию |
+| 2 | [`top_pages_daily`](top-pages-daily.md) | создавать материализованную витрину с дневной пересборкой в конвейере |
+| 3 | [`session_overview`](session-overview.md) | хранить слагаемые для расчета средних и долей |
+| 4 | [`dq_errors_daily`](dq-errors-daily.md) | считать брак по дню загрузки и хранить итоги дольше источника |
+| 5 | [`utm_effectiveness`](utm-effectiveness.md) | читать `declared_` как предупреждение о сумме со слов клиента |
 
 Общее устройство слоя — [дока DM](../architecture/dm.md). Она отвечает на
 вопросы «почему так», задание отвечает на вопрос «что сделать».
 
-## Общие правила ступени 1
+## Как принято на ступени 1
 
-Они одни для пяти заданий по витринам ступени 1, поэтому записаны здесь, а не
-повторяются в каждом ТЗ.
+**Читать — через `_v`.** Физические `_rep` и `_dist` служат загрузке и
+обслуживанию, а публичный договор DDS — `dds.event_v` или `dds.session_v` —
+остается прежним даже при изменении физических объектов. Чтение DDS
+напрямую делает задания независимыми: соседняя витрина может быть еще не
+построена.
+Исключение — задание 4: у таблиц брака публичного договора нет.
 
-**Читать — через `_v`.** Публичный договор сущности DDS — представление с
-суффиксом `_v`: `dds.event_v`, `dds.session_v`. Витрина называет только
-его; физические `_rep` и `_dist` служат загрузке и обслуживанию. Соседнюю
-домашку витрина источником тоже не берет: витрина слоя DM читает договор
-DDS, и задания остаются независимыми. Исключение одно и оно оговорено в
-задании 4: у таблиц брака публичного договора нет.
+**Писать — в `_dist`.** Так строки распределяются по ключу шардирования. При
+записи в локальную таблицу распределение зависит от узла, выполнившего
+запрос, и при следующем запуске может измениться. Подробности — раздел
+«Раскладка по шардам» [справочника хранилища](../architecture/storage.md).
 
-**Писать — только в `_dist`.** При записи в локальную таблицу раскладку
-определяет то, какая нода случайно выполняла код, а не свойство данных.
-Правило и его следствия — [дока хранилища](../architecture/storage.md),
-«Раскладка по шардам».
+**Форма — по зерну.** На стенде агрегат с новым зерном принято хранить
+готовым: потребитель читает его много раз без повторного расчета по
+источнику. Создайте `dm.<имя>_rep` / `_dist`, донор `dm.<имя>_stage_rep` /
+`_stage_dist` и публичное `dm.<имя>_v` с явным списком колонок. При прежнем
+зерне достаточно представления: таблица дублировала бы данные. Доводы —
+раздел «Форма: по зерну, не по цене запроса» [справочника
+DM](../architecture/dm.md).
 
-**Форма — по зерну.** Витрина, меняющая зерно источника, материализуется:
-`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).
 
-**Ключ шардирования — ваше решение.** Ни одно ТЗ ключа не называет.
-Правило выбора и требование к донору — [дока
-хранилища](../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`.
 
-**Где лежит код.** 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`: у нее есть все пять
-объектов, донор, сборка, замена дневных партиций и задача в конвейере.
-Списывать с нее устройство можно и нужно; списывать состав колонок — нет,
-он у каждой витрины свой.
+**Образец — витрина `revenue_daily`.** У нее есть пять объектов, донор,
+сборка, замена дневных партиций и задача в конвейере. Используйте ее как
+образец всего порядка пересборки. Состав колонок берите из своего ТЗ, иначе
+получите показатели другой витрины.
 
 ## Самопроверка ступени 1
 
 Даг `homework_check` запускается рукой, расписания у него нет. Задача
 витрины красная, пока витрины нет или счет не сходится, и зеленая, когда
-собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет:
-это инструмент лабы, а не история качества стенда.
+собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет: это
+инструмент лабы, а не история качества стенда.
 
 Проверка пяти заданий по витринам устроена одинаково и золотых констант не
 содержит: рядом с витриной независимым запросом собирается тот же ответ —
-прямо из источника витрины, минуя ее саму. У четырех заданий источник эталона
-тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания 4 это
-таблицы брака ODS, потому что в DDS у брака представительства нет. Обе стороны
-соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число строк,
-где стороны разошлись или одной стороны нет. Ноль — зеленый.
-Полное соединение здесь обязательно: при обычном пропавший день или
-пропавший ключ просто не попал бы в результат и остался бы незамечен.
+прямо из источника витрины, минуя ее саму. У четырех заданий источник
+эталона тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания
+4 это таблицы брака ODS, потому что в DDS нет сущности брака. Обе стороны
+соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число
+строк, где стороны разошлись или одной стороны нет. Ноль — зеленый. Полное
+соединение сохраняет ключи обеих сторон: при внутреннем пропавший день или
+ключ не попал бы в результат, и потеря осталась бы незамеченной.
 
 Раздел «Как проверить себя» каждого ТЗ по витрине называет деловой ключ и
 сравниваемые величины. Тот же прием в стендовом исполнении — [даг
@@ -105,11 +101,10 @@ DDS, и задания остаются независимыми. Исключе
 
 **Предупреждение.** Запросы самой проверки лежат в `sql/dq/` открыто, и
 имена называют витрину и роль сверки. Проверка на инвариантах неизбежно
-близка к ответу: чтобы сверить витрину, надо ее пересчитать. Прятать эти
-файлы никто не станет — но открыв их до того, как задание сделано, вы
-обменяете урок на готовый SQL.
-Смотреть туда стоит после своей сборки: сравнить два решения полезно,
-списать одно — нет.
+близка к ответу: чтобы сверить витрину, надо ее пересчитать. Если открыть
+эти файлы до выполнения задания, можно скопировать готовый SQL, не
+разобравшись в расчете самостоятельно. Смотреть туда стоит после своей
+сборки: сравнить два решения полезно, списать одно — нет.
 
 ## Факультативы