ddmitry/clickstream-data-platform
1
0 Fork 0
Code Issues 5 Pull Requests Actions Packages Projects 1 Releases Wiki Activity

ТЗ ступени 5 «Сначала сторож, потом ломай: заказы» #238

New Issue
Closed
opened 2026-09-06 21:17:25 +03:00 by ddmitry · 4 comments
ddmitry commented 2026-09-06 21:17:25 +03:00
Owner
Copy link
Copy source

Part of #206

Цель

Подготовить ТЗ лабы, в которой учащийся сначала строит проверки качества заказов, а затем безопасно вычитает разбор и трансформацию. Учебный результат: проверки появляются до рискованного изменения и умеют показать управляемую ошибку.

Критерии приемки

  • В ТЗ есть две новые проверки: равенство price * quantity = items_total и сверка слоя с авторитетным источником по дням.
  • Для обеих проверок описаны управляемые ошибки: результат сначала красный, после исправления снова зеленый.
  • Описано ручное подкладывание по одной строки каждого класса ошибки разбора и адресная очистка только своего среза.
  • Описано вычитание ods.order_parse и DDS-заказа: область, пересборка и замена партиции; инфраструктура стенда сохраняется.
  • В самопроверке учтены существующие DQ, баланс годных и ошибочных строк по срезу, физическое шардирование через hostName(), восстановление пропущенного дня и повторный запуск.
  • Все действия и договоры проверены по коду, SQL и дагам; команды дают исполнимое, адресное и по возможности только читающее доказательство.
  • Индекс docs/labs/README.md ведет на новое ТЗ; Markdown-ссылки и git diff --check проверены.
  • Текст прошел writing-for-agents, ai-text-lint и литературную вычитку русского языка.
  • ТЗ разделено на три последовательные части: 5-1-order-checks.md, 5-2-order-parsing.md и 5-3-order-pipeline.md; у каждой части есть собственные критерии приёмки и чистая точка остановки после проверки.

Границы

Меняются только docs/labs/5-1-order-checks.md, docs/labs/5-2-order-parsing.md, docs/labs/5-3-order-pipeline.md и ссылки на них в docs/labs/README.md. SQL, даги, DDL, генератор, службы и данные стенда не меняются. Три части выполняются последовательно; каждая описывает собственный результат, критерии приёмки и чистую точку остановки. ТЗ не содержит реализации учебных SQL или DQ-проверок: учащийся пишет их сам.

Сначала прочитать

  • docs/specs/2026-09-01-labs-program.md, раздел ступени 5 и общее правило вычитания.
  • docs/labs/4-1-session-pipeline.md.
  • docs/architecture/orders/README.md, code-rules.md, fate.md, ingestion.md, inventory.md, snapshot.md.
  • docs/architecture/dds/order.md, docs/architecture/etl.md, docs/architecture/testing.md.
  • sql/dq/, sql/ods/order_parse.sql, sql/dds/order_scope.sql, sql/dds/order_rebuild.sql, sql/dds/order_replace.sql.
  • dags/orders_ingest.py, dags/etl_pipeline.py, dags/dq_check.py.

Проверка

Проверить ссылки, git diff --check и все заявленные команды без make clean и без разрушения общего стенда.

Part of #206 ## Цель Подготовить ТЗ лабы, в которой учащийся сначала строит проверки качества заказов, а затем безопасно вычитает разбор и трансформацию. Учебный результат: проверки появляются до рискованного изменения и умеют показать управляемую ошибку. ## Критерии приемки - [x] В ТЗ есть две новые проверки: равенство `price * quantity = items_total` и сверка слоя с авторитетным источником по дням. - [x] Для обеих проверок описаны управляемые ошибки: результат сначала красный, после исправления снова зеленый. - [x] Описано ручное подкладывание по одной строки каждого класса ошибки разбора и адресная очистка только своего среза. - [x] Описано вычитание `ods.order_parse` и DDS-заказа: область, пересборка и замена партиции; инфраструктура стенда сохраняется. - [x] В самопроверке учтены существующие DQ, баланс годных и ошибочных строк по срезу, физическое шардирование через `hostName()`, восстановление пропущенного дня и повторный запуск. - [x] Все действия и договоры проверены по коду, SQL и дагам; команды дают исполнимое, адресное и по возможности только читающее доказательство. - [x] Индекс `docs/labs/README.md` ведет на новое ТЗ; Markdown-ссылки и `git diff --check` проверены. - [x] Текст прошел `writing-for-agents`, `ai-text-lint` и литературную вычитку русского языка. - [x] ТЗ разделено на три последовательные части: `5-1-order-checks.md`, `5-2-order-parsing.md` и `5-3-order-pipeline.md`; у каждой части есть собственные критерии приёмки и чистая точка остановки после проверки. ## Границы Меняются только `docs/labs/5-1-order-checks.md`, `docs/labs/5-2-order-parsing.md`, `docs/labs/5-3-order-pipeline.md` и ссылки на них в `docs/labs/README.md`. SQL, даги, DDL, генератор, службы и данные стенда не меняются. Три части выполняются последовательно; каждая описывает собственный результат, критерии приёмки и чистую точку остановки. ТЗ не содержит реализации учебных SQL или DQ-проверок: учащийся пишет их сам. ## Сначала прочитать - `docs/specs/2026-09-01-labs-program.md`, раздел ступени 5 и общее правило вычитания. - `docs/labs/4-1-session-pipeline.md`. - `docs/architecture/orders/README.md`, `code-rules.md`, `fate.md`, `ingestion.md`, `inventory.md`, `snapshot.md`. - `docs/architecture/dds/order.md`, `docs/architecture/etl.md`, `docs/architecture/testing.md`. - `sql/dq/`, `sql/ods/order_parse.sql`, `sql/dds/order_scope.sql`, `sql/dds/order_rebuild.sql`, `sql/dds/order_replace.sql`. - `dags/orders_ingest.py`, `dags/etl_pipeline.py`, `dags/dq_check.py`. ## Проверка Проверить ссылки, `git diff --check` и все заявленные команды без `make clean` и без разрушения общего стенда.
ddmitry added the wayfinder:taskready-for-agent labels 2026-09-06 21:17:25 +03:00
ddmitry self-assigned this 2026-09-06 21:17:25 +03:00
ddmitry commented 2026-09-06 22:14:53 +03:00
Author
Owner
Copy link
Copy source

Результат

Подготовлен PR «ТЗ ступени 5 „Сначала сторож, потом ломай: заказы“», коммит d686de5. Задание лежит в docs/labs/5-1-order-checks.md, индекс ведет на него.

Учащийся сначала пишет две проверки заказов и доказывает их управляемыми ошибками, затем переписывает разбор ODS и три SQL-файла сборки DDS внутри готового конвейера. Даги, DDL, Kafka, службы и таблицы-доноры остаются несущей частью упражнения.

Проверено:

  • локальные ссылки и якоря, git diff --check и отдельная проверка нового файла;
  • четырехстрочная заготовка jq с одной годной строкой, тремя классами брака и разными временами created_at и updated_at;
  • формы мутаций в отдельном clickhouse-local, без изменения общих таблиц стенда;
  • техническая линия Claude Opus: 3 исходные блокирующие находки и 5 замечаний закрыты, перепроверка APPROVED, все 8 исходов CLOSED и PROPORTIONATE;
  • линия формы: APPROVED.

Граница результата сохранена: orders_vs_ods сравнивает DDS с непосредственным источником ods.order_v по дням и не является сквозным эталоном генератора — одинаковую потерю строки в обоих слоях она не обнаружит. Это прикрыто отдельным опытом по контролируемому сырому срезу и проверкой текущей версии по snapshot_date.

Полный опыт с изменением данных общего стенда не запускался; проверены команды, код, SQL, даги и документация, а не разрушительная демонстрация на общей базе.

## Результат Подготовлен [PR «ТЗ ступени 5 „Сначала сторож, потом ломай: заказы“»](https://git.dementev.space/ddmitry/clickstream-data-platform/pulls/239), коммит `d686de5`. Задание лежит в `docs/labs/5-1-order-checks.md`, индекс ведет на него. Учащийся сначала пишет две проверки заказов и доказывает их управляемыми ошибками, затем переписывает разбор ODS и три SQL-файла сборки DDS внутри готового конвейера. Даги, DDL, Kafka, службы и таблицы-доноры остаются несущей частью упражнения. Проверено: - локальные ссылки и якоря, `git diff --check` и отдельная проверка нового файла; - четырехстрочная заготовка `jq` с одной годной строкой, тремя классами брака и разными временами `created_at` и `updated_at`; - формы мутаций в отдельном `clickhouse-local`, без изменения общих таблиц стенда; - техническая линия Claude Opus: 3 исходные блокирующие находки и 5 замечаний закрыты, перепроверка `APPROVED`, все 8 исходов `CLOSED` и `PROPORTIONATE`; - линия формы: `APPROVED`. Граница результата сохранена: `orders_vs_ods` сравнивает DDS с непосредственным источником `ods.order_v` по дням и не является сквозным эталоном генератора — одинаковую потерю строки в обоих слоях она не обнаружит. Это прикрыто отдельным опытом по контролируемому сырому срезу и проверкой текущей версии по `snapshot_date`. Полный опыт с изменением данных общего стенда не запускался; проверены команды, код, SQL, даги и документация, а не разрушительная демонстрация на общей базе.
ddmitry commented 2026-09-06 22:15:14 +03:00
Author
Owner
Copy link
Copy source

Эксперимент с наблюдением

В этом прогоне координатор несколько раз опрашивал долгий Claude-прогон через sleep 25; это произошло из-за смешения тайм-аута вызова инструмента yield_time_ms=30000 с частотой наблюдения. Повторные уведомления съели внимание, измеренной экономии токенов или денег нет.

Принятое владельцем правило: работу с Claude ведет отдельный субагент, а Git и трекер — отдельный помощник. Полные отчеты и триаж передаются уникальными файлами напрямую автору и ревьюеру; сообщения несут путь, замороженную версию и следующее действие. Наблюдение после запуска механизируется watcher-ом примерно с минутным интервалом, который сообщает только изменение, терминальный результат или настоящий блокер.

Это принятые границы ответственности и обмена. Сам watcher и экономия от него в этом комментарии не выдаются за измеренный результат; подробная записка эксперимента сохранена во временном файле /tmp/wayfinder206-stage5-luna-monitoring-note.md.

## Эксперимент с наблюдением В этом прогоне координатор несколько раз опрашивал долгий Claude-прогон через `sleep 25`; это произошло из-за смешения тайм-аута вызова инструмента `yield_time_ms=30000` с частотой наблюдения. Повторные уведомления съели внимание, измеренной экономии токенов или денег нет. Принятое владельцем правило: работу с Claude ведет отдельный субагент, а Git и трекер — отдельный помощник. Полные отчеты и триаж передаются уникальными файлами напрямую автору и ревьюеру; сообщения несут путь, замороженную версию и следующее действие. Наблюдение после запуска механизируется watcher-ом примерно с минутным интервалом, который сообщает только изменение, терминальный результат или настоящий блокер. Это принятые границы ответственности и обмена. Сам watcher и экономия от него в этом комментарии не выдаются за измеренный результат; подробная записка эксперимента сохранена во временном файле `/tmp/wayfinder206-stage5-luna-monitoring-note.md`.
ddmitry commented 2026-09-06 22:45:01 +03:00
Author
Owner
Copy link
Copy source

Решение о разделении

После разбора отзыва Fable владелец принял разделение PR #239 на три последовательные части: 5-1-order-checks.md, 5-2-order-parsing.md и 5-3-order-pipeline.md. Содержание и порядок учебного опыта сохраняются; у каждой части будут собственные критерии приёмки и чистая точка остановки.

В записи решения сохранены четыре замечания к форме ТЗ:

  • Договор и реализация: отделить требования от устройства готового решения; обязательным остаётся ожидание Distributed-записи перед заменой партиции.
  • Диагностика: явно направлять учащегося в журнал задачи Airflow, поскольку dm.dq_summary не хранит эту диагностику.
  • Восстановление: говорить о любом закрытом дне левее окна, ближайшем к нему, и объяснять пересборку оставшегося отрезка.
  • Язык: убрать лишние олицетворения; термин «сторож» сохраняется как словарь задания.

При реализации под проверкой остаются три вопроса среды: путь kafka-console-producer.sh в образе apache/kafka:4.3.1, форма ALTER ... ON CLUSTER ... SETTINGS mutations_sync = 2 и повторное чтение сообщений маркера после world_recreate. Уже закрытые TECH-находки этим решением не переоткрываются; сильные технические договоры и проверенные имена сохраняются. Выполнение этих трёх проверок здесь не заявляется.

## Решение о разделении После разбора отзыва Fable владелец принял разделение PR #239 на три последовательные части: `5-1-order-checks.md`, `5-2-order-parsing.md` и `5-3-order-pipeline.md`. Содержание и порядок учебного опыта сохраняются; у каждой части будут собственные критерии приёмки и чистая точка остановки. В записи решения сохранены четыре замечания к форме ТЗ: - **Договор и реализация:** отделить требования от устройства готового решения; обязательным остаётся ожидание Distributed-записи перед заменой партиции. - **Диагностика:** явно направлять учащегося в журнал задачи Airflow, поскольку `dm.dq_summary` не хранит эту диагностику. - **Восстановление:** говорить о любом закрытом дне левее окна, ближайшем к нему, и объяснять пересборку оставшегося отрезка. - **Язык:** убрать лишние олицетворения; термин «сторож» сохраняется как словарь задания. При реализации под проверкой остаются три вопроса среды: путь `kafka-console-producer.sh` в образе `apache/kafka:4.3.1`, форма `ALTER ... ON CLUSTER ... SETTINGS mutations_sync = 2` и повторное чтение сообщений маркера после `world_recreate`. Уже закрытые TECH-находки этим решением не переоткрываются; сильные технические договоры и проверенные имена сохраняются. Выполнение этих трёх проверок здесь не заявляется.
ddmitry commented 2026-09-06 23:26:29 +03:00
Author
Owner
Copy link
Copy source

Ступень 5 реализована тремя заданиями в пределах прежней семиступенчатой
программы. Каждое задание заканчивается чистым состоянием стенда и проверяемой
приемкой: две DQ и их красные опыты; разбор ODS до и после переписывания;
сборка DDS, восстановление дня, шардирование и повторный прогон.

Проверка orders_vs_ods использует непосредственный источник DDS -
ods.order_v. Одинаковую потерю в ODS и DDS она не обнаруживает. Этот предел
не скрыт: путь raw -> ODS отдельно проверяется балансом одной годной строки и
трех классов брака по _load_id.

Команды Kafka и кластерных мутаций подтверждены на развернутой версии стенда.
Для world_recreate проверен код жизненного цикла: он удаляет прикладные
consumer groups и топики, поэтому пробная пачка не попадает в новый мир.

Ступень 5 реализована тремя заданиями в пределах прежней семиступенчатой программы. Каждое задание заканчивается чистым состоянием стенда и проверяемой приемкой: две DQ и их красные опыты; разбор ODS до и после переписывания; сборка DDS, восстановление дня, шардирование и повторный прогон. Проверка `orders_vs_ods` использует непосредственный источник DDS - `ods.order_v`. Одинаковую потерю в ODS и DDS она не обнаруживает. Этот предел не скрыт: путь raw -> ODS отдельно проверяется балансом одной годной строки и трех классов брака по `_load_id`. Команды Kafka и кластерных мутаций подтверждены на развернутой версии стенда. Для `world_recreate` проверен код жизненного цикла: он удаляет прикладные consumer groups и топики, поэтому пробная пачка не попадает в новый мир.
Sign in to join this conversation.
No Branch/Tag Specified
Labels
Clear labels
needs-info
needs-triage
ready-for-agent
ready-for-human
wayfinder:grilling
wayfinder:map
wayfinder:prototype
wayfinder:research
wayfinder:task
wontfix
No labels ready-for-agent wayfinder:task
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
ddmitry (Dmitry Dementiev)
No Assignees ddmitry
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: ddmitry/clickstream-data-platform#238