docs(internal): вынесен план работ из PRD в TODO.md

- Зачем:
  - PRD не должен быть трекером задач, у каждого документа своя роль
- Что:
  - TODO.md реструктурирован: добавлен план подготовки курсовой (5 этапов с рекомендациями по инструментам), выполненные задачи перенесены в отдельную секцию
  - PRD.md: раздел «План работ» заменён ссылкой на TODO.md, убраны решённые вопросы
- Проверка:
  - просмотр TODO.md и docs/internal/PRD.md

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

TODO.md

@@ -1,9 +1,93 @@
 # TODO (maintainers / mentors)
 
-Этот файл собирает идеи по доработке стенда, которые не критичны для текущих задач менти,
-но улучшат стабильность и удобство сопровождения.
+Этот файл собирает задачи по подготовке стенда к курсовой работе
+и идеи по доработке, которые не критичны для текущих задач менти.
 
-Статус: ниже есть как актуальные, так и уже выполненные пункты.
+Контекст и стратегия: [docs/internal/PRD.md](docs/internal/PRD.md).
+Дизайн задания: [docs/internal/assignment_design.md](docs/internal/assignment_design.md).
+
+---
+
+## Подготовка курсовой
+
+> Дедлайн: ~2-3 недели (первый студент может подойти к курсовой).
+
+### Этап 1. Вынос CSV-пайплайна
+
+**Инструмент:** Sonnet / Gemini / ChatGPT — механическая работа, перенос файлов.
+
+- [ ] Перенести в [airflow-manual](https://github.com/dementev-dev/airflow-manual):
+  `csv_to_greenplum.py`, `csv_to_greenplum_dq.py`, `ddl_greenplum_base.py`,
+  `helpers/greenplum.py`, `sql/base/orders_ddl.sql`, связанные тесты
+- [ ] Убрать CSV-зависимости из docker-compose / .env (`CSV_DIR`, `CSV_ROWS`)
+- [ ] Обновить README (убрать упоминания CSV-пайплайна)
+
+### Этап 1.5. Полировка эталона
+
+**Инструмент:** Opus (глубокий анализ кода и контекста проекта)
++ ручное тестирование (make up, запуск DAG'ов, проверка данных).
+
+- [ ] Протестировать полный ETL-цикл с нуля
+      (make up → bookings-init → STG → ODS → DDS → DM)
+- [ ] Прогнать инкремент (bookings-generate-day → повторный запуск DAG'ов)
+- [ ] Почистить код эталонного среза
+- [ ] Актуализировать README и документацию
+- [ ] Убедиться, что `make test` и `make lint` проходят
+- [ ] Проверить, что стенд поднимается на чистой машине
+
+### Этап 2. Подготовка main
+
+**Инструмент:** Sonnet — удаление файлов и добавление заглушек
+по списку из [assignment_design.md](docs/internal/assignment_design.md).
+
+- [ ] Оставить только эталонный срез (sales_report + цепочка)
+- [ ] Убрать реализации таблиц-заданий (airplanes, seats, routes в STG/ODS;
+      dim_airplanes, dim_passengers, dim_routes в DDS; 4 витрины DM)
+- [ ] Добавить TODO-маркеры / заглушки в DAG'ах для студенческих тасков
+- [ ] Обновить `ddl_gp.sql` (убрать `\i` для таблиц-заданий)
+
+### Этап 3. ТЗ от аналитика
+
+**Инструмент:** Opus — нужно глубокое понимание предметной области, маппингов
+между слоями, SCD-паттернов и педагогического контекста.
+
+- [ ] Создать `docs/assignment/analyst_spec.md`
+- [ ] Для каждой таблицы-задания: имя, описание, поля, маппинг,
+      бизнес-правила, тип SCD, гранулярность, distribution key
+- [ ] Для dim_routes (SCD2): пошаговый алгоритм текстом, формула hashdiff
+- [ ] Рекомендуемый порядок выполнения
+
+### Этап 4. Валидационный DAG
+
+**Инструмент:** Sonnet (шаблонная работа, структура в assignment_design.md)
++ Opus для финальной вычитки.
+
+- [ ] Создать `airflow/dags/bookings_validate.py`
+- [ ] Создать SQL-скрипты в `sql/validate/`
+- [ ] Таски по слоям: STG, ODS, DDS, DM
+- [ ] Дружелюбные сообщения об ошибках с подсказками
+
+### Этап 5. Ветка solution
+
+**Инструмент:** Вручную / Sonnet — реализация уже есть в ветке
+`chore/bookings-etl`, нужно собрать в ветку `solution`.
+
+- [ ] Создать ветку `solution` от main (после подготовки)
+- [ ] Добавить полные реализации всех таблиц-заданий
+- [ ] Проверить, что всё работает end-to-end
+
+---
+
+## Прочее (бэклог)
+
+- [ ] Протестировать устойчивость `bookings-db` после остановки контейнеров:
+  - прогнать сценарии `make stop` -> `make up` и `make down` -> `make up`;
+  - зафиксировать, ломается ли генератор/данные в `bookings-db`;
+  - при необходимости добавить шаги восстановления и обновить документацию.
+
+---
+
+## Выполнено
 
 - [x] Сделать REST API Airflow основным способом тестирования ETL вместо CLI-вызовов
   через `docker compose exec ... airflow ...`:
@@ -11,11 +95,6 @@
   - оставить CLI как резервный вариант для локальной отладки;
   - проверить, что шаги тестирования воспроизводимы без входа в контейнер Airflow.
 
-- [ ] Протестировать устойчивость `bookings-db` после остановки контейнеров:
-  - прогнать сценарии `make stop` -> `make up` и `make down` -> `make up`;
-  - зафиксировать, ломается ли генератор/данные в `bookings-db`;
-  - при необходимости добавить шаги восстановления и обновить документацию.
-
 - [x] Собрать свой образ Airflow поверх `apache/airflow:2.9.2`:
   - вынести установку Python‑зависимостей из runtime (`pip install ...` при старте контейнеров)
     в отдельный `Dockerfile`;
@@ -27,9 +106,9 @@
   для docker‑стенда:
   - проверить, какие параметры достаточно поменять в env/конфиге (`AIRFLOW__CORE__EXECUTOR`)
     для образа `apache/airflow:2.9.2`;
-  - убедиться, что примерные DAG’и (`csv_to_greenplum`, `bookings_to_gp_stage`) ведут себя
+  - убедиться, что примерные DAG'и (`csv_to_greenplum`, `bookings_to_gp_stage`) ведут себя
     предсказуемо в режиме параллельного исполнения;
-  - при необходимости скорректировать тесты и документацию (README/TESTING) с учётом нового executor’а.
+  - при необходимости скорректировать тесты и документацию (README/TESTING) с учётом нового executor'а.
 
 - [x] Разобрать и стабилизировать интеграцию с Greenplum/PXF:
   - убедиться, что PXF в контейнере `greenplum` всегда корректно инициализируется