docs(labs): расследования выручки привязаны к задачам DE

Зачем: результатом лабораторных должны быть обоснованные решения о подготовке данных для витрин.

Что: добавлены проверяемые результаты сверки полноты, выбора ключа, точного разбора и правила пересчета; обновлены программа и индекс, убран подсчет долей потерь.

Проверка: SELECT-запросы под analyst, расчеты по сохраненной истории девяти наблюдений, 54 локальные ссылки, git diff --check и независимое техническое ревью.

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

@@ -1,13 +1,13 @@
 # Почему вчерашняя выручка меняется сегодня
 
-**Чему учит:** объяснять изменения уже рассчитанного отчета поступлением
-заказов и сменой их статусов, определять момент закрытия дня и границы
-доступной истории.
+**Чему учит:** обосновать окно пересчета витрины и требования к истории
+заказов по наблюдаемым опозданиям и изменениям статусов.
 
 Факультатив доступен после ступени 1. Понадобятся Airflow и DBeaver с
 подключением `analyst` по [инструкции](../../../README.md#подключиться-из-dbeaver).
 Вы будете наблюдать один день оформления заказов, продвигая мир по одному
-модельному дню. Новые данные останутся в стенде.
+модельному дню. Проверьте, можно ли при загрузке выручки каждый раз считать
+только новый день. Новые данные останутся в стенде.
 
 ## Подготовьте первое наблюдение
 
@@ -73,7 +73,7 @@ SELECT
 в конце окна и за его пределами.
 От исходного наблюдения потребуется восемь однодневных запусков.
 
-## Объясните изменения отчета
+## Найдите изменения в уже загруженном дне
 
 После каждого шага сравнивайте заказы по `order_id`, а не по положению строк
 в выгрузке. Найдите:
@@ -93,11 +93,12 @@ SELECT
 выше; учтите и заказы, которых еще не было в первом наблюдении. Сумма
 изменений вкладов должна совпасть с изменением `revenue` до копейки.
 
-Для одного из этих отмененных заказов сравните изменение его вклада
-с изменением общей выручки между теми же наблюдениями. Совпало ли
-направление изменений? Найдите в своей таблице заказы, определившие общий итог.
+Покажите на этих наблюдениях, какой результат остался бы в витрине,
+если бы конвейер после первого расчета обрабатывал только новые дни заказов.
+Достаточно ли добавлять в старый день только опоздавшие заказы? Проверьте
+свой ответ на найденных изменениях статусов.
 
-## Что известно об отменах
+## Определите, какую историю нужно хранить
 
 Возьмите отмененный заказ, у которого в вашей истории был статус `paid`.
 Укажите два наблюдения, доказывающих, что он был оплачен, а затем отменен.
@@ -105,9 +106,14 @@ SELECT
 Теперь возьмите отмененный заказ, для которого ни в одной вашей выгрузке
 нет `paid`. Проверьте утверждение «этот заказ никогда не был оплачен»:
 что известно о его состоянии между двумя слепками? Достаточно ли сохраненных
-наблюдений для такого вывода? Укажите, какие данные позволили бы его проверить.
+наблюдений для такого вывода?
 
-## Когда день закрыт
+Сформулируйте требования к данным для двух задач: восстановить состояние
+витрины на момент прошлого расчета и узнать, был ли заказ когда-либо оплачен.
+Какие сведения для каждой задачи должен передавать источник и сохранять
+хранилище? Проверьте предложение на своих выгрузках и на промежутке между ними.
+
+## Задайте правило пересчета
 
 Сравните сохраненные состояния при S = D + 6 и S = D + 7: состав заказов,
 их статусы, суммы и выручку. Какой слепок последним мог изменить заказы дня D
@@ -115,6 +121,12 @@ SELECT
 можно считать окончательным. Было бы достаточно совпадения двух соседних
 сумм, если бы окно еще не закончилось?
 
+Запишите правило выбора дней для пересчета после очередного слепка.
+Считайте, что начальная история уже загружена и ежедневные прогоны не
+пропускались. Укажите, по какой дате определяются границы, какие дни нужно
+пересчитать и когда день можно перестать включать в расчет. Подтвердите
+правило своими наблюдениями, включая опоздание и отмену.
+
 После собственных выводов сверьтесь с описанием
 [слепка и его доставки](../../architecture/orders/snapshot.md#слепок-и-его-доставка)
 и [границ истории отмен](../../architecture/orders/fate.md#судьба-заказа).
@@ -122,12 +134,13 @@ SELECT
 ## Что должно получиться
 
 - [ ] сохранена последовательность наблюдений одного дня D с датами слепков S;
-- [ ] найдены опоздавшие заказы и изменения статусов;
-- [ ] изменение выручки между двумя наблюдениями объяснено вкладами заказов;
+- [ ] на опоздавших заказах и изменениях статусов показаны ошибки загрузки
+      только новых дней или только новых заказов;
+- [ ] изменение выручки между наблюдениями сходится с изменением вкладов заказов;
 - [ ] оплата одной из последующих отмен подтверждена двумя наблюдениями;
-- [ ] вы различаете доказанную оплату и отсутствие сведений о ней;
-- [ ] состояние дня за пределами окна совпало с окончательным, а момент
-      закрытия обоснован правилом доставки слепков.
+- [ ] сформулированы требования к истории расчетов и истории оплаты;
+- [ ] правило пересчета и момент закрытия дня обоснованы наблюдениями
+      и правилом доставки слепков.
 
 После работы оставьте `world_live` на паузе либо верните автоматическое
 продвижение, если пользовались им до наблюдения.