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

- Зачем: начинающим трудно читать задания из-за необъясненных терминов и неестественных формулировок.
- Что: переработаны вводная и 21 задание, названы темы разделов, объяснены термины и сокращены повторы; согласованы правила учебного текста и ссылки.
- Проверка: сохранены 25 блоков SQL и команд и таблицы состава колонок; проверены 153 локальные ссылки и 32 входящие ссылки на разделы; git diff --check прошел.

docs/labs/optional/revenue-over-time.md

@@ -1,16 +1,18 @@
 # Почему вчерашняя выручка меняется сегодня
 
-**Чему учит:** обосновать окно пересчета витрины и требования к истории
-заказов по наблюдаемым опозданиям и изменениям статусов.
+Вы проследите, как опоздавшие заказы и смена статусов меняют выручку
+за прошедший день. По этим наблюдениям определите, какие дни пересчитывать
+и какую историю заказов сохранять.
 
 Факультатив доступен после ступени 1. Понадобятся Airflow и DBeaver с
 подключением `student` по [инструкции](../../../README.md#подключиться-из-dbeaver).
-Он читает данные стенда и записывает ваши наблюдения в базу `default`.
+Пользователь `student` может читать данные стенда и записывать ваши наблюдения
+в базу `default`.
 Вы будете наблюдать один день оформления заказов, продвигая мир по одному
 модельному дню. Проверьте, можно ли при загрузке выручки каждый раз считать
 только новый день. Новые данные останутся в стенде.
 
-## Подготовьте первое наблюдение
+## Подготовка
 
 Поставьте `world_live` на паузу. Дождитесь завершения начатых прогонов
 генерации и обработки, затем запустите `etl_pipeline` и дождитесь успеха.
@@ -28,14 +30,15 @@ SELECT
 Дата слепка, по которому сделано очередное наблюдение, будет **S**.
 Это модельные даты магазина. Календарная дата запуска Airflow день D не задает.
 
-Слепок снимается к концу суток и доставляется следующим прогоном. Поэтому
-покупки последнего сыгранного дня уже видны в событиях, а их заказов в
+Слепок содержит состояние заказов на конец модельных суток и доставляется
+при следующем запуске генератора. Поэтому покупки последнего завершившегося
+дня уже видны в событиях, а их заказов в
 хранилище еще нет. Проверьте это для D в `dds.order_v` и
 `dm.purchase_vs_orders_v`.
 
-## Подготовьте место для наблюдений
+## Таблицы для истории заказов
 
-Публичное представление заказа показывает текущее состояние, а сырые слепки
+Представление `dds.order_v` показывает текущее состояние заказов, а сырые слепки
 хранятся ограниченное время. Сохраните историю в двух своих таблицах: потом
 вы сможете сравнивать наблюдения обычными SQL-запросами в том же DBeaver.
 
@@ -66,7 +69,7 @@ ENGINE = MergeTree
 ORDER BY (order_date, snapshot_date);
 ```
 
-## Сохраните первое наблюдение
+## Первое наблюдение
 
 Напишите два `INSERT INTO ... SELECT` с явным списком колонок назначения:
 
@@ -93,7 +96,7 @@ ORDER BY (order_date, snapshot_date);
 статусам и сумму `items_total` только у `paid`. Эта сумма должна сходиться
 с сохраненной выручкой, сложенной по всем категориям.
 
-## Продвигайте мир по одному дню
+## Наблюдения за следующие дни
 
 Для каждого следующего наблюдения:
 
@@ -102,16 +105,16 @@ ORDER BY (order_date, snapshot_date);
    не обновляет.
 3. Повторите два запроса сохранения с новой датой S и проверьте записанные строки.
 
-Во всех запросах остается прежний день D. За один запуск проигрывайте один
+Во всех запросах остается прежний день D. За один запуск добавляйте один
 день, чтобы сохранить промежуточные состояния. Пакетный `world_next_day`
 отправляет события без пауз; ждать 24 минуты живого дня здесь не нужно.
 
-Продолжайте до слепка **D + 7** включительно. У заказов дня D окно состоит
-из семи дней, от D до D + 6. Последний шаг нужен для сравнения состояния
-в конце окна и за его пределами.
+Продолжайте до слепка **D + 7** включительно. Заказы дня D могут меняться
+семь дней, от D до D + 6. Этот период называется окном изменяемости.
+Последний шаг нужен для сравнения состояния в конце окна и после него.
 От исходного наблюдения потребуется восемь однодневных запусков.
 
-## Найдите изменения в уже загруженном дне
+## Изменения заказов и выручки
 
 Для сравнения прочитайте `default.lab_order_history` дважды: в одном
 подзапросе отберите прежнюю S, в другом — новую; день D остается общим.
@@ -138,7 +141,7 @@ ORDER BY (order_date, snapshot_date);
 Достаточно ли добавлять в старый день только опоздавшие заказы? Проверьте
 свой ответ на найденных изменениях статусов.
 
-## Определите, какую историю нужно хранить
+## Требования к истории заказов
 
 Возьмите отмененный заказ, у которого в вашей истории был статус `paid`.
 Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.
@@ -153,7 +156,7 @@ ORDER BY (order_date, snapshot_date);
 Какие сведения для каждой задачи должен передавать источник и сохранять
 хранилище? Проверьте, каких нужных сведений нет в ваших таблицах наблюдений.
 
-## Задайте правило пересчета
+## Правило пересчета витрины
 
 Сравните сохраненные состояния при S = D + 6 и S = D + 7: состав заказов,
 их статусы, суммы и выручку. Какой слепок последним мог изменить заказы дня D
@@ -171,13 +174,13 @@ ORDER BY (order_date, snapshot_date);
 [слепка и его доставки](../../architecture/orders/snapshot.md#слепок-и-его-доставка)
 и [границ истории отмен](../../architecture/orders/fate.md#судьба-заказа).
 
-## Что должно получиться
+## Результат работы
 
 - [ ] сохранена последовательность наблюдений одного дня D с датами слепков S;
 - [ ] на опоздавших заказах и изменениях статусов показаны ошибки загрузки
       только новых дней или только новых заказов;
 - [ ] изменение выручки между наблюдениями сходится с изменением вкладов заказов;
-- [ ] оплата одной из последующих отмен подтверждена двумя наблюдениями;
+- [ ] для одного отмененного заказа найдены два наблюдения: с оплатой и с отменой;
 - [ ] сформулированы требования к истории расчетов и истории оплаты;
 - [ ] правило пересчета и момент закрытия дня обоснованы наблюдениями
       и правилом доставки слепков.