При переходе из карты или задания к подробностям менти получает актуальное объяснение и может отличить инструкцию для работающего стенда от старого плана разработки.
Что сделать
Проверить четыре руководства docs/bookings_to_gp_{stage,ods,dds,dm}.md на соответствие текущим SQL/DAG и требованиям учебных заглушек. Сосредоточить их на предпосылках запуска, действиях загрузки, результате и поиске ошибок; объяснения структуры связать с картой.
Согласовать docs/dag_execution_order.md с README и руководствами загрузок. Движение данных, порядок задач и зерно таблиц описывать точно.
Разобрать документы docs/design/bookings_*_design.md: отделить полезные актуальные объяснения от планов создания уже существующих файлов. Старые планы явно обозначить как историю разработки и убрать из основного маршрута менти. Содержательные материалы не удалять без определения места, где они остаются доступны.
Проверить роли TESTING.md, docs/reference/qa-plan.md, docs/reference/dq_taxonomy.md и docs/design/naming_conventions.md в навигации. Ученик должен находить проверку своего задания отдельно от проверки разработки и глубокой диагностики стенда.
Устранить повторяющиеся несовместимые описания на пути карта → руководство → SQL/ТЗ. Для действующего кода сверяться с реализацией; для заглушек противоречие требований требует явного решения, которое затем отражается во всех затронутых местах.
Уже найденные места для проверки
docs/design/bookings_ods_design.md показывает загрузку ods.airports через UPDATE/INSERT; действующий sql/ods/airports_load.sql выполняет TRUNCATE/INSERT.
В docs/bookings_to_gp_dds.md обновление описательных полей dim_routes распространяется на все версии, а в analyst_spec.md — на открытые версии. На main загрузчик является заглушкой: корректный договор нельзя определить из SELECT 1;.
docs/bookings_to_gp_dds.md называет загрузку календаря полным пересозданием, а дизайн-документ описывает заполнение один раз. Проверить действующий SQL.
docs/dag_execution_order.md говорит о загрузке новых рейсов в факт, тогда как зерно факта — пара (ticket_no, flight_id).
Границы
Работа ограничена документами, к которым ведет учебный маршрут, и необходимыми правками ссылок. Не превращать ее в переписывание всей истории проекта. Содержание программы, SQL, DAG, DDL, конфигурация и данные стенда не меняются.
Критерии готовности
На основном пути чтения отсутствуют неотмеченные старые планы разработки, представленные как актуальные инструкции.
Руководства загрузок различают действующую реализацию и ожидаемое поведение учебных заглушек.
Найденные расхождения проверены; для каждого зафиксировано исправление либо согласованное решение по требованиям.
У каждого существенного правила есть основной документ, а остальные места ссылаются на него без несовместимых копий.
Из заданий легко найти их самопроверку; тесты разработки и глубокая диагностика вынесены из обязательного первого чтения.
Проверены внутренние ссылки, имена таблиц и файлов, команды из измененных инструкций и отсутствие изменений SQL/DAG.
Повторно пройден целиком маршрут README → структура/карта → разбор SQL → первое задание → проверка результата; указано, какие шаги проверены чтением, а какие выполнены на стенде.
Сначала прочитать
Результаты двух предыдущих задач; индекс документации, четыре руководства загрузок, порядок запуска, ТЗ, действующие SQL/DAG, docs/design/bookings_*_design.md.
Part of #1
Blocked by: #3
## Учебная цель
При переходе из карты или задания к подробностям менти получает актуальное объяснение и может отличить инструкцию для работающего стенда от старого плана разработки.
## Что сделать
1. Проверить четыре руководства `docs/bookings_to_gp_{stage,ods,dds,dm}.md` на соответствие текущим SQL/DAG и требованиям учебных заглушек. Сосредоточить их на предпосылках запуска, действиях загрузки, результате и поиске ошибок; объяснения структуры связать с картой.
2. Согласовать `docs/dag_execution_order.md` с README и руководствами загрузок. Движение данных, порядок задач и зерно таблиц описывать точно.
3. Разобрать документы `docs/design/bookings_*_design.md`: отделить полезные актуальные объяснения от планов создания уже существующих файлов. Старые планы явно обозначить как историю разработки и убрать из основного маршрута менти. Содержательные материалы не удалять без определения места, где они остаются доступны.
4. Проверить роли `TESTING.md`, `docs/reference/qa-plan.md`, `docs/reference/dq_taxonomy.md` и `docs/design/naming_conventions.md` в навигации. Ученик должен находить проверку своего задания отдельно от проверки разработки и глубокой диагностики стенда.
5. Устранить повторяющиеся несовместимые описания на пути карта → руководство → SQL/ТЗ. Для действующего кода сверяться с реализацией; для заглушек противоречие требований требует явного решения, которое затем отражается во всех затронутых местах.
## Уже найденные места для проверки
- `docs/design/bookings_ods_design.md` показывает загрузку `ods.airports` через UPDATE/INSERT; действующий `sql/ods/airports_load.sql` выполняет TRUNCATE/INSERT.
- В `docs/bookings_to_gp_dds.md` обновление описательных полей `dim_routes` распространяется на все версии, а в `analyst_spec.md` — на открытые версии. На `main` загрузчик является заглушкой: корректный договор нельзя определить из `SELECT 1;`.
- `docs/bookings_to_gp_dds.md` называет загрузку календаря полным пересозданием, а дизайн-документ описывает заполнение один раз. Проверить действующий SQL.
- `docs/dag_execution_order.md` говорит о загрузке новых рейсов в факт, тогда как зерно факта — пара `(ticket_no, flight_id)`.
## Границы
Работа ограничена документами, к которым ведет учебный маршрут, и необходимыми правками ссылок. Не превращать ее в переписывание всей истории проекта. Содержание программы, SQL, DAG, DDL, конфигурация и данные стенда не меняются.
## Критерии готовности
- [x] На основном пути чтения отсутствуют неотмеченные старые планы разработки, представленные как актуальные инструкции.
- [x] Руководства загрузок различают действующую реализацию и ожидаемое поведение учебных заглушек.
- [x] Найденные расхождения проверены; для каждого зафиксировано исправление либо согласованное решение по требованиям.
- [x] У каждого существенного правила есть основной документ, а остальные места ссылаются на него без несовместимых копий.
- [x] Из заданий легко найти их самопроверку; тесты разработки и глубокая диагностика вынесены из обязательного первого чтения.
- [x] Проверены внутренние ссылки, имена таблиц и файлов, команды из измененных инструкций и отсутствие изменений SQL/DAG.
- [x] Повторно пройден целиком маршрут README → структура/карта → разбор SQL → первое задание → проверка результата; указано, какие шаги проверены чтением, а какие выполнены на стенде.
## Сначала прочитать
Результаты двух предыдущих задач; [индекс документации](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/README.md), четыре руководства загрузок, [порядок запуска](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/dag_execution_order.md), [ТЗ](https://git.dementev.space/ddmitry/airflow-greenplum/src/branch/main/docs/assignment/analyst_spec.md), действующие SQL/DAG, `docs/design/bookings_*_design.md`.
Выполнено и принято: PR #7 влит в main, коммит слияния 351dbbb.
Результат
Руководства STG/ODS/DDS/DM описывают подготовку, действия загрузки, результат и поиск ошибок. Указано, какие загрузки и DQ уже работают, а какие нужно реализовать по ТЗ.
Снимки ODS описаны как TRUNCATE + INSERT; транзакционные загрузки сохраняют метки STG и отбирают дельту по HWM. Порядок задач соответствует main.
Календарь заполняется только при пустой таблице. Зерно факта — (ticket_no, flight_id), число строк проверяется на точное равенство с ods.segments.
Для dim_routes закреплено обновление описательных полей только у открытых версий. Закрытые версии сохраняют значения на момент закрытия. ТЗ, руководство и карта согласованы.
Самопроверка остается рядом с заданием. Проверки разработки и глубокая диагностика доступны отдельно; дизайн-планы и QA-план сохранены как история по прежним адресам.
Проверки
make lint, git diff --check и проверка сборки карты прошли. make test: 4 passed, 14 skipped — 13 smoke-тестов пропущены условием доступности Airflow в тестовом окружении, один интеграционный требует отдельного запуска.
Проверены 292 локальные ссылки в 19 документах, якоря, 40 адресов карты, имена задач, таблиц и Make-таргетов. Сборщик карты проверил 39 объектов, 90 связей и 215 ссылок. Содержимое пяти исторических документов сохранено, что подтверждено сравнением с исходной веткой.
Чтением и в Chromium через Playwright пройден маршрут README → структура/карта → разбор готового SQL → первое задание → ТЗ → самопроверка. В браузере использовались локально отрисованные Markdown и интерактивная карта; проверены сегменты билета, две роли аэропорта, модели и места, выбор связей, переключение вида и сброс. Ошибок JavaScript нет.
Граница проверки: живые загрузки Airflow/Greenplum и bookings_validate не запускались; в рабочей копии нет .env. Проверка документации и интерфейса не подменяет прогон ETL.
Изменены только 17 Markdown-файлов; SQL, DAG, DDL, конфигурация и данные стенда не менялись. Все семь критериев этой задачи выполнены.
Выполнено и принято: [PR #7](https://git.dementev.space/ddmitry/airflow-greenplum/pulls/7) влит в `main`, коммит слияния `351dbbb`.
### Результат
- Руководства STG/ODS/DDS/DM описывают подготовку, действия загрузки, результат и поиск ошибок. Указано, какие загрузки и DQ уже работают, а какие нужно реализовать по ТЗ.
- Снимки ODS описаны как `TRUNCATE + INSERT`; транзакционные загрузки сохраняют метки STG и отбирают дельту по HWM. Порядок задач соответствует `main`.
- Календарь заполняется только при пустой таблице. Зерно факта — `(ticket_no, flight_id)`, число строк проверяется на точное равенство с `ods.segments`.
- Для `dim_routes` закреплено обновление описательных полей только у открытых версий. Закрытые версии сохраняют значения на момент закрытия. ТЗ, руководство и карта согласованы.
- Самопроверка остается рядом с заданием. Проверки разработки и глубокая диагностика доступны отдельно; дизайн-планы и QA-план сохранены как история по прежним адресам.
### Проверки
`make lint`, `git diff --check` и проверка сборки карты прошли. `make test`: **4 passed, 14 skipped** — 13 smoke-тестов пропущены условием доступности Airflow в тестовом окружении, один интеграционный требует отдельного запуска.
Проверены 292 локальные ссылки в 19 документах, якоря, 40 адресов карты, имена задач, таблиц и Make-таргетов. Сборщик карты проверил 39 объектов, 90 связей и 215 ссылок. Содержимое пяти исторических документов сохранено, что подтверждено сравнением с исходной веткой.
Чтением и в Chromium через Playwright пройден маршрут README → структура/карта → разбор готового SQL → первое задание → ТЗ → самопроверка. В браузере использовались локально отрисованные Markdown и интерактивная карта; проверены сегменты билета, две роли аэропорта, модели и места, выбор связей, переключение вида и сброс. Ошибок JavaScript нет.
**Граница проверки:** живые загрузки Airflow/Greenplum и `bookings_validate` не запускались; в рабочей копии нет `.env`. Проверка документации и интерфейса не подменяет прогон ETL.
Изменены только 17 Markdown-файлов; SQL, DAG, DDL, конфигурация и данные стенда не менялись. Все семь критериев этой задачи выполнены.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of #1
Blocked by: #3
Учебная цель
При переходе из карты или задания к подробностям менти получает актуальное объяснение и может отличить инструкцию для работающего стенда от старого плана разработки.
Что сделать
docs/bookings_to_gp_{stage,ods,dds,dm}.mdна соответствие текущим SQL/DAG и требованиям учебных заглушек. Сосредоточить их на предпосылках запуска, действиях загрузки, результате и поиске ошибок; объяснения структуры связать с картой.docs/dag_execution_order.mdс README и руководствами загрузок. Движение данных, порядок задач и зерно таблиц описывать точно.docs/design/bookings_*_design.md: отделить полезные актуальные объяснения от планов создания уже существующих файлов. Старые планы явно обозначить как историю разработки и убрать из основного маршрута менти. Содержательные материалы не удалять без определения места, где они остаются доступны.TESTING.md,docs/reference/qa-plan.md,docs/reference/dq_taxonomy.mdиdocs/design/naming_conventions.mdв навигации. Ученик должен находить проверку своего задания отдельно от проверки разработки и глубокой диагностики стенда.Уже найденные места для проверки
docs/design/bookings_ods_design.mdпоказывает загрузкуods.airportsчерез UPDATE/INSERT; действующийsql/ods/airports_load.sqlвыполняет TRUNCATE/INSERT.docs/bookings_to_gp_dds.mdобновление описательных полейdim_routesраспространяется на все версии, а вanalyst_spec.md— на открытые версии. Наmainзагрузчик является заглушкой: корректный договор нельзя определить изSELECT 1;.docs/bookings_to_gp_dds.mdназывает загрузку календаря полным пересозданием, а дизайн-документ описывает заполнение один раз. Проверить действующий SQL.docs/dag_execution_order.mdговорит о загрузке новых рейсов в факт, тогда как зерно факта — пара(ticket_no, flight_id).Границы
Работа ограничена документами, к которым ведет учебный маршрут, и необходимыми правками ссылок. Не превращать ее в переписывание всей истории проекта. Содержание программы, SQL, DAG, DDL, конфигурация и данные стенда не меняются.
Критерии готовности
Сначала прочитать
Результаты двух предыдущих задач; индекс документации, четыре руководства загрузок, порядок запуска, ТЗ, действующие SQL/DAG,
docs/design/bookings_*_design.md.Выполнено и принято: PR #7 влит в
main, коммит слияния351dbbb.Результат
TRUNCATE + INSERT; транзакционные загрузки сохраняют метки STG и отбирают дельту по HWM. Порядок задач соответствуетmain.(ticket_no, flight_id), число строк проверяется на точное равенство сods.segments.dim_routesзакреплено обновление описательных полей только у открытых версий. Закрытые версии сохраняют значения на момент закрытия. ТЗ, руководство и карта согласованы.Проверки
make lint,git diff --checkи проверка сборки карты прошли.make test: 4 passed, 14 skipped — 13 smoke-тестов пропущены условием доступности Airflow в тестовом окружении, один интеграционный требует отдельного запуска.Проверены 292 локальные ссылки в 19 документах, якоря, 40 адресов карты, имена задач, таблиц и Make-таргетов. Сборщик карты проверил 39 объектов, 90 связей и 215 ссылок. Содержимое пяти исторических документов сохранено, что подтверждено сравнением с исходной веткой.
Чтением и в Chromium через Playwright пройден маршрут README → структура/карта → разбор готового SQL → первое задание → ТЗ → самопроверка. В браузере использовались локально отрисованные Markdown и интерактивная карта; проверены сегменты билета, две роли аэропорта, модели и места, выбор связей, переключение вида и сброс. Ошибок JavaScript нет.
Граница проверки: живые загрузки Airflow/Greenplum и
bookings_validateне запускались; в рабочей копии нет.env. Проверка документации и интерфейса не подменяет прогон ETL.Изменены только 17 Markdown-файлов; SQL, DAG, DDL, конфигурация и данные стенда не менялись. Все семь критериев этой задачи выполнены.