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

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

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

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

docs/labs/README.md

@@ -10,28 +10,28 @@
 |---|---|---|
 | 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) | изучить разбор потока отдельно от живого приема и сверить его со стендовым результатом |
+| 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) | строить слой как договор о данных, а не как их копию |
+| 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). Она отвечает на
+Общее устройство слоя — [справочник DM](../architecture/dm.md). Он отвечает на
 вопросы «почему так», задание отвечает на вопрос «что сделать».
 
 ## Как принято на ступени 1
@@ -99,9 +99,8 @@ DM](../architecture/dm.md).
 собрано верно. В сводку качества конвейера `dm.dq_summary` он не пишет: это
 инструмент лабы, а не история качества стенда.
 
-Проверка пяти заданий по витринам устроена одинаково и золотых констант не
-содержит: рядом с витриной независимым запросом собирается тот же ответ —
-прямо из источника витрины, минуя ее саму. У четырех заданий источник
+Для каждой витрины проверка независимо рассчитывает ожидаемый результат
+прямо по ее источнику. У четырех заданий источник
 эталона тот же, что у витрины, `dds.session_v` или `dds.event_v`; у задания
 4 это таблицы брака ODS, потому что в DDS нет сущности брака. Обе стороны
 соединяются по деловому ключу через `FULL OUTER JOIN`, и считается число
@@ -109,16 +108,13 @@ DM](../architecture/dm.md).
 соединение сохраняет ключи обеих сторон: при внутреннем пропавший день или
 ключ не попал бы в результат, и потеря осталась бы незамеченной.
 
-Раздел «Как проверить себя» каждого ТЗ по витрине называет деловой ключ и
+Раздел «Как проверить себя» каждого задания по витрине называет деловой ключ и
 сравниваемые величины. Тот же прием в стендовом исполнении — [даг
 `dq_check`](../../dags/dq_check.py) и запросы в [`sql/dq/`](../../sql/dq).
 
-**Предупреждение.** Запросы самой проверки лежат в `sql/dq/` открыто, и
-имена называют витрину и роль сверки. Проверка на инвариантах неизбежно
-близка к ответу: чтобы сверить витрину, надо ее пересчитать. Если открыть
-эти файлы до выполнения задания, можно скопировать готовый SQL, не
-разобравшись в расчете самостоятельно. Смотреть туда стоит после своей
-сборки: сравнить два решения полезно, списать одно — нет.
+Запросы проверок лежат в `sql/dq/`. Откройте их после собственного решения:
+они заново рассчитывают показатели витрины, поэтому содержат ответ на
+существенную часть задания. Сравните свой способ расчета с готовым.
 
 ## Факультативы
 
@@ -152,12 +148,12 @@ DM](../architecture/dm.md).
 
 ### Что делать, когда стенд сломался
 
-Открывается после ступени 7. Поломки стенда и runbook по итогам
-расследований; весь раздел — повышенная сложность.
+Открывается после ступени 7. Поломки стенда и инструкции по восстановлению
+по итогам расследований; весь раздел — повышенная сложность.
 
 ## Уборка
 
-Черновики и опыты за собой сносить: правило проверок стенда —
-[дока тестирования](../architecture/testing.md). Снесенная витрина обязана
-снова покраснить свою задачу в `homework_check` — если не покраснила,
-проверка ничего и не проверяла.
+После опытов удаляйте свои временные объекты. Если удалили учебную витрину,
+ее задача в `homework_check` должна снова завершиться ошибкой: отсутствие
+витрины тоже проверяется. Подробнее — в
+[справочнике проверок](../architecture/testing.md).