diff --git a/CLAUDE.md b/CLAUDE.md
new file mode 100644
index 0000000..43c994c
--- /dev/null
+++ b/CLAUDE.md
@@ -0,0 +1 @@
+@AGENTS.md
diff --git a/dwh-modeling/README.md b/dwh-modeling/README.md
index 6bafb58..b3b9ef2 100644
--- a/dwh-modeling/README.md
+++ b/dwh-modeling/README.md
@@ -281,7 +281,7 @@ AND (dim_customer.valid_to IS NULL OR fact_sales.order_date < dim_customer.valid
 ```
 и получаем актуальный на тот день email и город.
 
-> 🔍 Подробнее про SCD — в отдельной статье [Slow Changing Dimensions](SCD.md) (сравнение Type 1/2/3, паттерны обновления).
+> 🔍 Подробнее про SCD — в отдельной статье [Slowly Changing Dimensions](SCD.md) (сравнение Type 1/2/3, паттерны обновления).
 
 Теперь, когда мы разобрались, что такое факты, измерения и SCD, давайте посмотрим, как именно можно устроить слой DDS внутри — есть несколько вариантов.
 
@@ -374,82 +374,9 @@ AND (dim_customer.valid_to IS NULL OR fact_sales.order_date < dim_customer.valid
 - новые источники проще прикручивать;
 - меньше шансов «сломать» старые отчёты.
 
----
+Data Vault хорошо подходит там, где много разнородных источников, нужна полная история изменений и прозрачный аудит. За гибкость приходится платить сложностью модели и количеством таблиц — поэтому для небольших проектов (2–5 источников, маленькая команда) DV почти наверняка избыточен.
 
-#### Чем DV отличается от 3NF и Звезды
-
-Если сильно упростить:
-
-- В **3NF/Звезде** мы часто смешиваем:
-  - бизнес-ключ,
-  - текущие атрибуты,
-  - историю (SCD2)  
-  — всё это в одной таблице измерения.
-
-- В **Data Vault** это *разнесено*:
-  - Hub — только бизнес-ключ;
-  - Satellite — только атрибуты + история;
-  - Link — только связи между сущностями.
-
-За это приходится платить сложностью модели и количеством таблиц. Зато DV хорошо выдерживает:
-- много разнородных источников;
-- «грязные» данные;
-- жёсткие требования по аудиту и трассировке.
-
----
-
-#### Raw Vault и Business Vault — два слоя
-
-Часто говорят «Raw Vault» и «Business Vault». Грубо:
-
-- **Raw Vault** — «как прилетело из источников».  
-  Хабы, линкы и сателлиты, максимально близкие к исходным данным.  
-  Задача: надёжно собрать и сохранить **полную историю**.
-
-- **Business Vault** — «как удобно считать дальше».  
-  На основе Raw Vault появляются:
-  - служебные таблицы (PIT, Bridge и т.п.),
-  - подготовленные представления под витрины и отчёты,
-  - бизнес-правила (например, что считать «активным клиентом»).
-
-Дальше поверх этого уже строятся **обычные витрины в формате Звезды**, с которыми работают аналитики.
-
-Если примерить это к классическим слоям `stg → ods → dds → dm`, то **очень грубо** можно думать так:
-
-- `stg` всё равно остаётся как «приземление» (landing) из источников;
-- **Raw Vault** по духу ближе к **ODS**: мало бизнес-логики, зато полная история и интеграция из разных систем;
-- **Business Vault** ближе к **DDS**: здесь уже живут бизнес-правила и подготовка данных к витринам;
-- `dm` по-прежнему остаётся витринами в формате Звезды, с которыми работают аналитики и BI.
-
-Важно: это именно *аналогия для понимания*, а не жёсткое правило проектирования.
-
----
-
-#### Когда DV вам, скорее всего, рано
-
-Если у вас:
-
-- 2–5 источников,
-- небольшая команда (1–2 инженера + аналитик),
-- задачи уровня «сделать первые отчёты»,
-
-то **Data Vault почти наверняка избыточен**.  
-Чаще всего хватает связки:
-
-> `stg → ods → dds (3NF или простая Звезда с SCD2) → dm (Звезда)`
-
----
-
-#### Что важно запомнить из этой статьи
-
-Для этой статьи достаточно:
-
-- знать, что **Data Vault** — это способ строить хранилище как **конструктор из Hub/Link/Satellite**,  
-- понимать, что он нужен в первую очередь там, где:
-  - много систем-источников,
-  - нужна *полная* история и прозрачный аудит.
-
-Детали (Raw vs Business Vault, PIT/Bridge, DV 1.0 vs 2.0 и т.п.) — это уже тема для отдельной, взрослой статьи.
+> 🔍 Подробнее про Data Vault — сравнение с 3NF/Звездой, Raw и Business Vault, когда внедрять — в отдельной статье [DataVault: как пережить бурную жизнь источников](DataVault.md).
 
 ---
 
@@ -577,6 +504,8 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
 
 > 💡 **Материализованное представление (MATERIALIZED VIEW)** — это «кэш» результата. Обновляется по расписанию (например, ночью).
 
+✏️ **Попробуйте сами:** [Домашка: статусы клиента от STG до DDS (и немного DM)](Homework_Customer_Status_DDS_DM.md) — пройдёте тот же путь, но самостоятельно.
+
 ---
 
 ## 8. Как выбрать модель данных? Советы от практиков
@@ -628,7 +557,7 @@ GROUP BY d.date_actual, p.product_name, c.customer_segment;
    Почему: ему нужны готовые метрики без сложных JOIN’ов. Звезда даёт понятные таблицы: «продажи по дням и товарам» — без углубления в атомарные сущности.
 
    — **BI-разработчик в Power BI / Tableau** → **Звезда**  
-   Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простою модель.
+   Почему: все инструменты визуализации оптимизированы под star schema. Один факт + несколько измерений = быстрые отчёты и простую модель.
 
    — **Инженер ML (Data Scientist / ML-инженер)** → **3NF или сырые ODS-таблицы**  
    Почему: для фичей нужны атомарные события и детальные атрибуты. Машинное обучение ценит полноту и детализацию данных больше, чем удобство отчётов.