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/dq-errors-daily.md

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