docs(all): реструктурирована документация — docs/internal/ заменён на design/, reference/, archive/, plans/

- Зачем:
  - docs/internal/ превратился в свалку: дизайн-документы, ревью, планы и справочники лежали вперемешку.
  - архивные планы были неотличимы от живых документов.
- Что:
  - docs/internal/ удалён; файлы распределены по docs/design/, docs/reference/, docs/archive/, docs/plans/, docs/assignment/.
  - educational-tasks.md убран из корня в архив (устарел).
  - обновлены все перекрёстные ссылки в AGENTS.md, TODO.md, README.md, docs/README.md и внутри design/reference/.
  - актуализированы architecture_review.md (статус DM-слоя), db_schema.md (DM-слой), TESTING.md, dag_execution_order.md, pxf_bookings.md.
  - добавлены заглушки docs/assignment/README.md и docs/plans/README.md.
- Проверка:
  - make test && make lint
  - rg 'docs/internal' --glob '!docs/archive/*' — должно быть пусто.

docs/archive/educational-tasks.md

@@ -0,0 +1,91 @@
+# Учебные задания по стенду
+
+Этот документ собирает в одном месте задания для менти.  
+Он разбит на блоки: от архитектуры Greenplum и демо‑БД bookings до реализации аналитических слоев DWH.
+
+Если вы только начинаете, выполняйте задания по порядку.
+
+---
+
+## 1. Greenplum и модель данных (введение)
+
+В следующих заданиях мы будем опираться на демо‑БД bookings (Postgres) и слой STG в Greenplum.  
+На этом этапе достаточно бегло посмотреть на структуру и понять общую идею, детальная проработка пойдёт позже.
+
+### 1.1. Знакомство с демо‑БД bookings
+
+1. Прочитайте `bookings/README.md` — какие сервисы и команды относятся к демобазе.
+2. Поднимите стенд и выполните:
+   - `make up`
+   - `make bookings-init`
+3. Подключитесь к демобазе:
+   - `make bookings-psql`
+   - посмотрите таблицы в схеме `bookings` (например, `\dt bookings.*`).
+4. Найдите таблицу `bookings.bookings` и посмотрите на её структуру:
+   - какие типы колонок используются;
+   - какие поля выглядят как ключи, даты, суммы.
+
+### 1.2. Знакомство с STG в Greenplum
+
+1. Прочитайте `sql/stg/bookings_ddl.sql` и краткое описание потока `docs/bookings_to_gp_stage.md` (если интересно — `docs/internal/bookings_stg_design.md`).
+2. Ответьте себе на вопросы:
+   - чем внешняя таблица `stg.bookings_ext` отличается от внутренней `stg.bookings`;
+   - зачем нужны тех.колонки `event_ts`, `_load_ts`, `_load_id`;
+   - чем слой STG отличается от итоговых витрин (DDS/DM) с точки зрения моделирования.
+3. Выполните `make ddl-gp`, затем зайдите в Greenplum (`make gp-psql`) и проверьте наличие схемы и таблиц:
+   - `\dn` и `\dt stg.*`
+   - `SELECT * FROM stg.bookings LIMIT 5;` (после запуска соответствующего DAG).
+
+### 1.3. Как генерируются учебные данные bookings
+
+1. Откройте файл `bookings/generate_next_day.sql` и ответьте себе на вопросы:
+   - с какой даты начинается генерация данных (посмотрите на GUC `bookings.start_date` и переменную `v_start_cfg`);
+   - сколько дней генерируется при первой установке (переменная `bookings.init_days`);
+   - что происходит, если таблица `bookings.bookings` уже не пустая.
+2. В демобазе (`make bookings-psql`) выполните:
+   - `SELECT min(book_date), max(book_date) FROM bookings.bookings;`
+   - затем запустите `make bookings-generate-day` и повторите запрос — как изменился максимальный день?
+3. Откройте `sql/src/bookings_generate_day_if_missing.sql` и обратите внимание, что:
+   - логическая дата запуска DAG (`{{ ds }}`) не влияет на выбор дня генерации;
+   - скрипт всегда смотрит на `max(book_date)` и добавляет **следующий** день (или несколько стартовых дней, если база пуста).
+4. Сделайте вывод: генератор всегда «шагает» по датам вперёд от максимальной даты, поэтому:
+   - при `make bookings-init` вы получаете готовые данные из seed-дампа (при `make bookings-generate` генератор создаст `BOOKINGS_INIT_DAYS` дней начиная с `BOOKINGS_START_DATE`);
+   - при последующих вызовах (`make bookings-generate-day` или DAG) добавляется ровно один новый день.
+
+---
+
+## 2. DAG bookings_to_gp_stage (заготовка заданий)
+
+Этот DAG показывает путь данных от демо‑БД bookings в Postgres до сырого слоя STG в Greenplum.  
+Сейчас он уже реализован как учебный пример, а в будущем вокруг него появятся отдельные задания по моделированию DWH.
+
+### 2.1. Что есть сейчас
+
+1. Откройте `airflow/dags/bookings_to_gp_stage.py`.
+2. Найдите в коде ссылки на SQL‑файлы:
+   - `sql/src/bookings_generate_day_if_missing.sql`
+   - `sql/stg/bookings_load.sql`
+   - `sql/stg/bookings_dq.sql`
+3. Соотнесите шаги DAG с документом `docs/bookings_to_gp_stage.md`:
+   - генерация учебного дня в `bookings.bookings`;
+   - загрузка инкремента в `stg.bookings`;
+   - проверка количества строк между источником и STG.
+4. Обратите внимание, как в DAG используется логическая дата запуска:
+   - `{{ run_id }}` используется как `_load_id` — метка загрузки в таблице `stg.bookings` для конкретного запуска;
+   - сами даты данных (какие дни есть в `bookings.bookings`) определяются генератором по `max(book_date)`, а не по `ds`.
+
+На этом этапе достаточно понять общую цепочку. Детальные задания по переработке модели данных и построению ODS/DDS/DM слоёв будут добавлены позже.
+
+### 2.2. Идеи для будущих заданий (черновик)
+
+> Ниже — набросок задач, к которым мы вернёмся, когда базовые темы по Airflow будут освоены.
+
+Планируемые направления:
+
+- Спроектировать модель данных для основных сущностей демобазы bookings (рейсы, билеты, перелёты) в слоях ODS/DDS/DM.
+- Реализовать слой ODS поверх STG, аккуратно работая с временными атрибутами и ключами.
+- Построить витрины (DM) для типичных аналитических вопросов: загрузка рейсов, выручка по направлениям, динамика бронирований.
+- Добавить DAG’и, которые используют `stg.bookings` как источник и строят следующие слои DWH.
+- Расширить проверки качества данных для потоков bookings → STG → витрины.
+
+Когда будете готовы к этим темам, вернитесь к этому разделу — он станет основой для следующего «модуля» лабораторных заданий.