docs(labs): упрощен язык учебных заданий

Зачем: помочь менти понять действия, проверить результат и оценить освоенное умение.

Что: вычитаны 13 заданий основной программы и общий индекс. Итоговые списки обращены к учащемуся, убраны история разработки и повторы. Правила учебного текста записаны в программе, из AGENTS.md добавлена ссылка.

Проверка: git diff --check, локальные ссылки и ссылки на измененные заголовки прошли. Блоки кода и таблицы требований совпадают с исходными. Упражнения на стенде повторно не выполнялись: изменен только текст.

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

@@ -1,7 +1,7 @@
-# Сначала сторож, потом ломай: заказы
+# Проверьте заказы перед изменением обработки
 
-**Чему учит:** до рискованного изменения задавать проверке явный договор и
-испытывать его управляемой ошибкой.
+**Чему учит:** написать проверки заказов до изменения их обработки
+и убедиться на намеренной ошибке, что проверки ее замечают.
 
 ## Сначала прочитать
 
@@ -13,30 +13,30 @@
 и на ее включение в [`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 и службы остаются несущей частью упражнения.
+Разбор ODS и сборку DDS вы перепишете в следующих заданиях. Здесь сохраните
+их, даги загрузки, DDL, таблицы-доноры, Kafka и службы как есть.
 
 Перед опытами остановите автоматическое движение мира: поставьте `world_live`
-на паузу и дождитесь завершения активных прогонов. До чистой точки остановки не
+на паузу и дождитесь завершения активных прогонов. До завершения опытов не
 запускайте руками `world_next_day`, `world_live_day`, `world_initialize` и
 `world_recreate`. Это условие стабильного модельного времени: одной паузы
 `world_live` для него мало.
 
-## Два договора качества
+## Что будут проверять ваши запросы
 
-Обе проверки следуют договору `dq_check`: запрос возвращает по одной строке
+Чтобы `dq_check` мог запустить проверку, ее запрос возвращает по одной строке
 на день с колонками `data_date`, `reference_rows`, `actual_rows`,
 `failed_rows`, `diagnostics`. Даг сохраняет в `dm.dq_summary` только счетчики,
-статус и координаты запуска. Ограниченные примеры из `diagnostics` ищите в
+статус и координаты запуска. Примеры из `diagnostics` ищите в
 журнале упавшей задачи Airflow. Ограничьте их тем же малым числом, что и
 существующие запросы в `sql/dq/`.
 
@@ -46,17 +46,18 @@ Kafka и службы остаются несущей частью упражн
 посчитайте сумму `item_price * item_quantity` и сравните ее с `items_total`.
 `reference_rows` считает ключи со стороны `items_total`, `actual_rows` - ключи
 со стороны вычисленной суммы, а `failed_rows` - несовпавшие значения. В
-исправном наборе первые два счетчика равны по построению; сам инвариант выражен
-через `failed_rows`. Для диагностики достаточно `order_id`, ожидаемой суммы и
+исправном наборе первые два счетчика равны; несовпадения сумм считает
+`failed_rows`. Для диагностики достаточно `order_id`, ожидаемой суммы и
 суммы позиций.
 
 Проверка относится к типизированному разбору массива `items` на границе
-ODS -> DDS. Скидка, доставка и равенство `total` в этот договор не входят.
+ODS -> DDS. Скидку, доставку и равенство `total` здесь проверять не нужно.
 
 ### DDS против ODS
 
 Имя проверки - `orders_vs_ods`. Источник модели DDS здесь - текущее состояние
-`ods.order_v`. Внутреннее состояние генератора в этот договор не входит.
+`ods.order_v`. С ним вы и сравниваете DDS; обращаться к внутреннему состоянию
+генератора для этой проверки не нужно.
 Одним запросом соберите обе стороны на зерне дня заказа и сравните:
 
 - число заказов;
@@ -131,18 +132,17 @@ ORDER BY check_name;
 Проверка суммы должна охватывать каждый день `dds.order_v`. Сверка слоев
 должна охватывать объединение дней ODS и DDS, включая дни только одной стороны.
 
-## Когда можно остановиться
+## Завершите опыт
 
-После двух восстановлений выбранный заказ снова совпадает с ODS. Все семь
-проверок дают зеленый результат. В таком состоянии можно закончить работу или
+После восстановления заказа и успешного `dq_check` можно закончить работу или
 перейти к разбору заказов, оставив модельное время на паузе.
 
-## Приемка
+## Что должно получиться
 
-- [ ] две новые проверки встроены в `dq_check` и публикуют дневные строки по
-      принятому договору;
-- [ ] каждая проверка дала красный результат на своей управляемой ошибке;
-- [ ] журналы упавших задач содержали ограниченную диагностику;
-- [ ] `etl_pipeline` восстановил обе измененные строки DDS;
-- [ ] `order_items_total`, `orders_vs_ods` и пять прежних DQ зелены;
-- [ ] SQL разбора ODS и сборки DDS на этом шаге не менялся.
+- [ ] вы включили две новые проверки в `dq_check`; их дневные результаты
+      появляются в `dm.dq_summary`;
+- [ ] вы увидели ошибку каждой проверки после соответствующего изменения
+      заказа, а в журнале нашли примеры заказов с расхождениями;
+- [ ] вы восстановили заказ через `etl_pipeline` после обоих опытов;
+- [ ] `order_items_total`, `orders_vs_ods` и пять прежних проверок успешны;
+- [ ] разбор ODS и сборка DDS остались прежними.