diff --git a/notes b/notes
index 14a7c9d..7bfbf2f 100644
--- a/notes
+++ b/notes
@@ -125,4 +125,29 @@ src/shared/
 Составной блок с данными на 2+ страницах?	widgets/	↓
 Это действие пользователя с логикой?	features/	↓
 Привязан к бизнес-сущности?	entities/	↓
-Абстрактный UI без бизнес-логики?	shared/ui/	—
\ No newline at end of file
+Абстрактный UI без бизнес-логики?	shared/ui/	—
+
+
+И еще размышлений
+
+
+
+
+
+
+Что у нас по факту
+Мы взяли FSD и добавили:
+- Слой Layouts — каркас страницы
+- Слой Screens — контент страницы с локальными компонентами
+- Правило scope — компонент живёт максимально близко к месту использования, и поднимается на уровень выше только при переиспользовании
+Это не FSD в чистом виде. Но и не что-то принципиально новое.
+Существующие названия
+Feature-Sliced Design (FSD) — то от чего отталкиваемся, но расходимся в деталях.
+Screaming Architecture (Robert C. Martin) — структура проекта "кричит" о том, что он делает. Открываешь screens/knv/ui/ — видишь КНВ. Открываешь widgets/ — видишь глобальное. Это близко к нашему подходу.
+Colocation Principle — держи код рядом с тем, где он используется. Именно этот принцип отличает нас от FSD: page-specific компоненты лежат внутри screen, а не в глобальном widgets/.
+Как назвать
+Я бы не стал придумывать новое название. Это:
+> FSD с принципом колокации (FSD + Colocation)
+Или проще — адаптированный FSD. Суть отличия укладывается в одно правило:
+> Компонент живёт на самом низком уровне, где он используется. Поднимается выше только при переиспользовании на 2+ страницах.
+Если хочется краткое название для внутренней документации — можно SLD (Scoped Layer Design), подчёркивая что каждый компонент привязан к scope (shared → entity → feature → widget → screen → layout → page).