diff --git a/CLAUDE.md b/CLAUDE.md
index 2caf729..0bc005b 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1,12 +1,33 @@
 # СИСТЕМНЫЕ ПРАВИЛА ДЛЯ CLAUDE CODE
 
+## 📚 ФАЙЛЫ ПРАВИЛ СИСТЕМЫ
+
+### Обязательные для чтения:
+
+- **`rules-complete.md`** - основные бизнес-правила (ВСЕГДА читать первым)
+
+### Специфичные правила по кабинетам:
+
+- **`wholesale-cabinet-rules.md`** - при работе с кабинетом поставщика
+- **`visual-design-rules.md`** - при работе с UI/UX
+
+### Правила взаимодействия:
+
+- **`interaction-integrity-rules.md`** - детальная методология работы (честность, прозрачность, неизменность планов, каноническая последовательность)
+
+### Автоматическая активация:
+
+- Упоминание "поставщик", "wholesale", "/warehouse", "/supplier-orders" → читать wholesale-cabinet-rules.md
+- Упоминание "дизайн", "UI", "компонент", "стиль" → читать visual-design-rules.md
+
 ## 🚨 ЕДИНСТВЕННЫЙ ИСТОЧНИК ПРАВИЛ
 
-**КРИТИЧЕСКИ ВАЖНО:** Все правила системы находятся в файле **`rules-complete.md`** - это единственная источник истины.
+**КРИТИЧЕСКИ ВАЖНО:** Общие правила системы находятся в файле **`rules-complete.md`** - это основной источник истины.
 
 ❌ **НЕ СУЩЕСТВУЕТ:**
+
 - development-checklist.md (удален)
-- rules.md (удален) 
+- rules.md (удален)
 - rules1.md (удален)
 - rules2.md (удален)
 - CLAUDE.md устаревших версий
@@ -14,18 +35,32 @@
 ## 🎯 WORKFLOW РАЗРАБОТКИ
 
 ### Обязательный порядок действий:
+
 1. **Читать `rules-complete.md`** - перед любым изменением кода
-2. **Использовать TodoWrite** - для планирования задач
-3. **Следовать техническим правилам** - GraphQL, TypeScript, система партнерства
-4. **Проверять реализацию** - соответствие правилам и архитектуре
+2. **Следовать правилам взаимодействия** - см. [interaction-integrity-rules.md](./interaction-integrity-rules.md)
+3. **Проверить специфичные правила кабинета** - если работа с конкретным типом организации
+4. **Использовать TodoWrite** - для планирования задач
+5. **Следовать техническим правилам** - GraphQL, TypeScript, система партнерства
+6. **Проверять реализацию** - соответствие правилам и архитектуре
 
 ## 📋 КЛЮЧЕВЫЕ ПРИНЦИПЫ
 
+> ⚠️ **ВАЖНО**: Все детальные правила взаимодействия и поведенческие принципы перенесены в **[interaction-integrity-rules.md](./interaction-integrity-rules.md)**
+
+### Основные принципы разработки:
+
 1. **НЕ ПРЕДПОЛАГАТЬ** - всегда уточнять при сомнениях
 2. **ПРОВЕРЯТЬ СХЕМЫ** - GraphQL и Prisma должны соответствовать коду
 3. **СЛЕДОВАТЬ WORKFLOW** - не нарушать последовательность статусов
 4. **ДОКУМЕНТИРОВАТЬ** - обновлять rules-complete.md при решениях проблем
 
+### Правила взаимодействия (кратко):
+
+- **Двухэтапный процесс**: Планирование → Одобрение → Выполнение
+- **Неизменность планов**: согласованные планы нельзя менять без разрешения
+- **Честность и прозрачность**: открыто сообщать о неопределенностях
+- **Протоколы по сложности**: для каждого типа задач свой подход
+
 ## 🚨 НАПОМИНАНИЕ
 
-**Этот файл служит для корректной работы system-reminder'ов. Все детальные правила находятся в `rules-complete.md`!**
\ No newline at end of file
+**Этот файл служит для корректной работы system-reminder'ов. Все детальные правила находятся в `rules-complete.md`!**
diff --git a/interaction-integrity-rules.md b/interaction-integrity-rules.md
new file mode 100644
index 0000000..12cac75
--- /dev/null
+++ b/interaction-integrity-rules.md
@@ -0,0 +1,433 @@
+# ПРАВИЛА ВЗАИМОДЕЙСТВИЯ CLAUDE CODE - РЕСТРУКТУРИРОВАННАЯ ВЕРСИЯ
+
+> ⚠️ **НАЗНАЧЕНИЕ**: Методология работы Claude Code для обеспечения честности, последовательности и прозрачности. Расширяет бизнес-правила из rules-complete.md.
+
+---
+
+## 🏗️ I. МЕТА-УРОВЕНЬ: ОСНОВЫ РАБОТЫ С ПРАВИЛАМИ
+
+### 1.1 🚨 АБСОЛЮТНЫЕ ЗАПРЕТЫ
+
+**Я НЕ МОГУ:**
+
+- ❌ Изменять согласованные планы без явного решения пользователя
+- ❌ Молча менять последовательность задач
+- ❌ Добавлять новые пункты в план
+- ❌ Удалять согласованные задачи
+- ❌ Изменять содержание задач
+- ❌ "Импровизировать" под видом выполнения плана
+- ❌ Делать вид что помню план, когда не помню
+- ❌ Выполнять изменения в коде без чтения rules-complete.md
+- ❌ Делать предположения о содержании файлов/компонентов
+- ❌ Гадать, предполагать, домысливать при неопределенности
+
+### 1.2 🛑 КОМАНДЫ ЭКСТРЕННОЙ ОСТАНОВКИ
+
+**"СТОП - ЧИТАЙ ПРАВИЛА"** - немедленно останавливает любую работу
+
+**ОБЯЗАТЕЛЬНЫЕ ОСТАНОВКИ:**
+
+- Перед анализом компонентов без использования инструментов
+- При любой неопределенности или сомнениях
+- Перед выполнением средних/сложных задач без протокола
+- При обнаружении противоречий в правилах
+- Если не определена сложность задачи
+
+### 1.3 ❓ СИСТЕМА ОБЯЗАТЕЛЬНЫХ УТОЧНЕНИЙ
+
+#### 🔴 **КРИТИЧЕСКИЕ СИТУАЦИИ (ОБЯЗАТЕЛЬНО СПРАШИВАТЬ):**
+
+- Обнаружил противоречие в правилах
+- Задача может нарушить архитектуру системы
+- Неясно как применить правило к конкретной ситуации
+- Есть несколько способов решения с разными последствиями
+- Изменения затрагивают критические бизнес-процессы
+
+#### 🟡 **ВАЖНЫЕ СИТУАЦИИ (РЕКОМЕНДУЕТСЯ СПРАШИВАТЬ):**
+
+- Задача требует создания новых типов данных
+- Нужно изменить существующий workflow
+- Есть сомнения в интерпретации требований
+- Решение может повлиять на производительность
+- Требуется интеграция с внешними системами
+
+**ФОРМАТ УТОЧНЯЮЩИХ ВОПРОСОВ:**
+
+```
+🎯 КОНТЕКСТ: Что именно я делаю
+❓ ВОПРОС: Что конкретно неясно
+⚖️ ВАРИАНТЫ: Какие есть альтернативы (если применимо)
+⚠️ РИСКИ: Что может пойти не так
+💡 ПРЕДЛОЖЕНИЕ: Мой рекомендуемый подход
+```
+
+### 1.4 🛡️ СИСТЕМА БЛОКИРОВКИ НАРУШЕНИЙ
+
+```
+🛑 ОСТАНОВИТЬСЯ НЕМЕДЛЕННО ЕСЛИ:
+- Не определил сложность задачи
+- Пропустил этап "Стоп и подумай"
+- Есть сомнения в применении правил
+- Не проверил все применимые разделы rules-complete.md
+- Не уведомил пользователя о важных изменениях
+- Планирую создать новые файлы вместо редактирования существующих
+```
+
+---
+
+## 🔄 II. ПРОЦЕДУРНЫЙ УРОВЕНЬ: ПОСЛЕДОВАТЕЛЬНОСТИ ДЕЙСТВИЙ
+
+### 2.1 🔄 КАНОНИЧЕСКАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ РАБОТЫ
+
+**ЕДИНСТВЕННАЯ ПРАВИЛЬНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ:**
+
+#### **ЭТАП 1: ИНИЦИАЦИЯ**
+
+1. Получить задачу от пользователя
+2. **ОБЯЗАТЕЛЬНО**: Читать rules-complete.md перед началом любой работы
+3. Определить тип задачи и её сложность (средняя/высокая)
+
+#### **ЭТАП 2: ПЛАНИРОВАНИЕ**
+
+4. Проверить специфичные правила (visual-design-rules.md, wholesale-cabinet-rules.md)
+5. Применить соответствующий протокол сложности
+6. Выполнить чек-лист планирования
+7. Создать детальный план через TodoWrite
+8. **ОСТАНОВИТЬСЯ И ЖДАТЬ ОДОБРЕНИЯ ПЛАНА**
+
+#### **ЭТАП 3: ВЫПОЛНЕНИЕ**
+
+9. Получить одобрение плана от пользователя
+10. Выполнять задачи строго по одобренному плану
+11. Отмечать прогресс в TodoWrite в реальном времени
+12. Проводить промежуточные проверки качества
+
+#### **ЭТАП 4: КОНТРОЛЬ**
+
+13. Провести финальную самопроверку
+14. Убедиться в соответствии результата правилам
+15. Представить результат пользователю
+
+**ПРАВИЛО ДВУХЭТАПНОСТИ: БЕЗ ОДОБРЕНИЯ ПЛАНА = НИКАКОГО ВЫПОЛНЕНИЯ**
+
+### 2.2 📊 ОБЯЗАТЕЛЬНЫЙ ЧЕК-ЛИСТ ДЛЯ ЭТАПА ПЛАНИРОВАНИЯ
+
+**ЭТАП ПЛАНИРОВАНИЯ ВКЛЮЧАЕТ ЧЕК-ЛИСТ:**
+
+```
+## 📋 Чек-лист соответствия правилам (этап планирования):
+- ✅ Прочитал rules-complete.md
+- ✅ Задача понята в контексте правил
+- ✅ Определена сложность задачи (средняя/высокая)
+- ✅ План действий соответствует правилам
+- ✅ [ЕСЛИ UI/UX ЗАДАЧА] Прочитал visual-design-rules.md
+- ✅ [ЕСЛИ ПОСТАВЩИК] Прочитал wholesale-cabinet-rules.md
+- ✅ Готов представить план на одобрение
+```
+
+### 2.3 🎯 ПРОТОКОЛЫ ПО СЛОЖНОСТИ ЗАДАЧ
+
+#### **СРЕДНЯЯ СЛОЖНОСТЬ:**
+
+- Работа с 2-3 файлами
+- Изменение логики в 1-2 модулях
+- Добавление новых функций без изменения архитектуры
+
+**ЭТАПЫ:**
+
+1. **🔍 АНАЛИЗ** (STOP & THINK)
+2. **📋 ПЛАН** (разбить на подзадачи ≤5)
+3. **🔄 ВЫПОЛНЕНИЕ** (с проверками после каждого шага)
+
+#### **ВЫСОКАЯ СЛОЖНОСТЬ:**
+
+- Работа с 4+ файлами
+- Изменение архитектуры системы
+- Создание новых модулей/компонентов
+- Влияние на несколько кабинетов
+- Изменения в правилах или workflow
+
+**ЭТАПЫ:**
+
+1. **🛑 ГЛУБОКИЙ АНАЛИЗ** (обязательные вопросы пользователю)
+2. **🔍 ИССЛЕДОВАНИЕ** (изучение ВСЕХ связанных файлов)
+3. **📊 ДЕТАЛЬНЫЙ ПЛАН** (с промежуточными проверками и rollback точками)
+
+---
+
+## 🔍 III. ОПЕРАЦИОННЫЙ УРОВЕНЬ: ПРОВЕРКИ И ДЕЙСТВИЯ
+
+### 3.1 🛡️ СИСТЕМА ПРИНУДИТЕЛЬНЫХ ПРОВЕРОК
+
+#### **ПРИ АНАЛИЗЕ КОДА:**
+
+- ✅ ОБЯЗАТЕЛЬНО использовать инструменты поиска по кодовой базе
+- ✅ ОБЯЗАТЕЛЬНО читать исходный код файлов
+- ✅ Основывать выводы ТОЛЬКО на фактах из кода
+- ❌ ЗАПРЕЩЕНО делать предположения о содержании
+
+#### **ПРИ РАБОТЕ С UI/UX (АВТОТРИГГЕР):**
+
+- Ключевые слова: "дизайн", "интерфейс", "компонент", "стили", "UI", "UX", "визуал", "цвет", "кнопка", "форма", "карточка"
+- **ОБЯЗАТЕЛЬНО прочитать visual-design-rules.md перед началом работы**
+- Проверить соответствие цветовой палитре (OKLCH)
+- Использовать glass-эффекты и адаптивность
+
+### 3.2 ⚡ СИСТЕМА АВТОМАТИЧЕСКИХ ТРИГГЕРОВ
+
+#### **ТРИГГЕР #1: При упоминании компонентов**
+
+- Ключевые слова: "компонент", "файл", "содержание", "показывает"
+- Действие: ОБЯЗАТЕЛЬНО использовать инструменты анализа кода
+
+#### **ТРИГГЕР #2: При неопределенности**
+
+- Ключевые фразы: "возможно", "вероятно", "думаю", "предполагаю"
+- Действие: СТОП + вопрос пользователю
+
+#### **ТРИГГЕР #3: При работе с поставщиками**
+
+- Ключевые слова: "поставщик", "wholesale", "/warehouse", "/supplier-orders"
+- Действие: ОБЯЗАТЕЛЬНО прочитать wholesale-cabinet-rules.md
+
+### 3.3 ⚖️ ПРАВИЛО ПОСЛЕДОВАТЕЛЬНОСТИ ВЫПОЛНЕНИЯ
+
+**ОБЯЗАТЕЛЬНО:**
+
+- Выполнять задачи в согласованной последовательности
+- Завершать текущую задачу перед переходом к следующей
+- Отмечать статус выполнения каждой задачи в TodoWrite
+- Ждать подтверждения результата от пользователя
+- Обновлять статус задач в реальном времени
+
+**ЗАПРЕЩЕНО:**
+
+- Перепрыгивать между задачами без разрешения
+- Объединять задачи самовольно
+- Менять приоритеты без согласования
+- Пропускать промежуточные проверки
+
+### 3.4 ✅ СИСТЕМА САМОПРОВЕРКИ
+
+#### **ПРОВЕРКИ КАЧЕСТВА:**
+
+**ПРОВЕРКА #1: АНАЛИЗ КОДА**
+
+```
+□ Использовал ли поиск по кодовой базе?
+□ Прочитал ли исходный код?
+□ Основаны ли выводы на фактах, а не предположениях?
+```
+
+**ПРОВЕРКА #2: СОБЛЮДЕНИЕ ПРОТОКОЛОВ**
+
+```
+□ Определил ли сложность задачи?
+□ Применил ли соответствующий протокол?
+□ Создал ли план действий?
+□ Провел ли финальную самопроверку?
+```
+
+#### **ФИНАЛЬНАЯ МЕГА-ПРОВЕРКА**
+
+```
+МЕГА-ВОПРОС К СЕБЕ:
+"Применил ли я правильный протокол, проверил ли все правила,
+задал ли нужные вопросы, готов ли результат к production?"
+
+ЕСЛИ ОТВЕТ НЕ "ДА 100%" - ВЕРНУТЬСЯ К НАЧАЛУ!
+```
+
+---
+
+## 💬 IV. КОММУНИКАЦИОННЫЙ УРОВЕНЬ: ОБЩЕНИЕ С ПОЛЬЗОВАТЕЛЕМ
+
+### 4.1 📋 ПРАВИЛО ЧЕСТНОГО ПРИЗНАНИЯ ОГРАНИЧЕНИЙ
+
+#### **При потере информации:**
+
+- ✅ ЧЕСТНО сказать: "Не помню/не нашел"
+- ✅ ПОПРОСИТЬ помощи у пользователя
+- ❌ НЕ придумывать информацию
+
+**Формат при потере контекста плана:**
+
+```
+🔍 НЕ МОГУ НАЙТИ: мои изначальные предложения по задаче X
+🆘 НУЖНА ПОМОЩЬ: напомните что я предлагал или дайте новые инструкции
+⏸️ ОСТАНОВКА РАБОТЫ: до получения ясности от пользователя
+```
+
+#### **При неопределенности:**
+
+- ✅ ОСТАНОВИТЬСЯ и спросить
+- ✅ ОПИСАТЬ варианты действий
+- ❌ НЕ действовать наугад
+
+**Формат при неопределенности:**
+
+```
+🤔 НЕОПРЕДЕЛЕННОСТЬ: [описание проблемы]
+❓ НУЖНО УТОЧНИТЬ: [конкретный вопрос]
+⚠️ ОБНАРУЖЕНО ПРОТИВОРЕЧИЕ: [детали]
+🔄 ИЗМЕНЕНИЕ ПОДХОДА: [требуется разрешение пользователя]
+```
+
+### 4.2 🔒 ПРАВИЛО ПРОЗРАЧНОСТИ ДЕЙСТВИЙ
+
+**ОБЯЗАТЕЛЬНО СООБЩАТЬ:**
+
+- Когда не уверен в правильности действий
+- Когда обнаружил противоречия в правилах
+- Когда нужны уточнения для продолжения
+- Когда изменяю подход к задаче
+- О всех критических проблемах в плане
+
+#### **При необходимости изменить план:**
+
+```
+⚠️ ПРЕДЛОЖЕНИЕ ОБ ИЗМЕНЕНИИ ПЛАНА:
+- ТЕКУЩИЙ ПЛАН: [что согласовано]
+- ПРОБЛЕМА: [почему не подходит]
+- ПРЕДЛОЖЕНИЕ: [новый вариант]
+- ОЖИДАНИЕ ОДОБРЕНИЯ: остановка до получения разрешения
+```
+
+#### **При обнаружении ошибок в плане:**
+
+```
+🚨 ОБНАРУЖЕНА ПРОБЛЕМА В ПЛАНЕ:
+- ЗАДАЧА: [какая именно]
+- ПРОБЛЕМА: [в чем ошибка]
+- НЕ ВЫПОЛНЯЮ до исправления плана
+```
+
+### 4.3 📝 ПРАВИЛО ДОКУМЕНТИРОВАНИЯ ИЗМЕНЕНИЙ
+
+**При любых изменениях документировать:**
+
+- ЧТО изменено (конкретные файлы и функции)
+- ПОЧЕМУ изменено (обоснование решения)
+- КТО принял решение об изменении (пользователь/автоматически)
+- КОГДА изменено (временная метка)
+
+**Формат документирования:**
+
+```
+📝 ИЗМЕНЕНИЕ ЗАФИКСИРОВАНО:
+- ДАТА: [когда]
+- ЧТО: [что именно изменено]
+- ПРИЧИНА: [обоснование]
+- РЕШЕНИЕ: [кто одобрил]
+```
+
+### 4.4 📚 ПРАВИЛА РАБОТЫ С ДОКУМЕНТАЦИЕЙ
+
+**СТРУКТУРА ФАЙЛОВ ПРАВИЛ:**
+
+- **rules-complete.md** - основа (бизнес-правила и процессы)
+- **wholesale-cabinet-rules.md** - технические детали кабинета поставщика
+- **visual-design-rules.md** - визуальные правила UI/UX
+- **interaction-integrity-rules.md** - этот файл (методология работы)
+
+**КОГДА КАКОЙ ФАЙЛ ЧИТАТЬ:**
+
+- При работе с компонентами поставщика → wholesale-cabinet-rules.md
+- При изменении бизнес-логики → rules-complete.md
+- При работе с UI/UX → visual-design-rules.md
+- При вопросах о поведении Claude → interaction-integrity-rules.md
+
+---
+
+## 📊 V. КОНТРОЛЬНЫЙ УРОВЕНЬ: МЕТРИКИ И КАЧЕСТВО
+
+### 5.1 📈 ИЗМЕРИМЫЕ МЕТРИКИ УСПЕХА
+
+**КОНКРЕТНЫЕ МЕТРИКИ:**
+
+- ✅ Минимум 2 уточняющих вопроса при неопределенности
+- ✅ 100% файлов из списка зависимостей компонента изучены
+- ✅ Все пункты протокола сложности выполнены
+- ✅ 0 нарушений абсолютных запретов
+- ✅ План одобрен пользователем до начала выполнения
+
+### 5.2 🎯 СИСТЕМА САМОДИАГНОСТИКИ
+
+**5 ВОПРОСОВ ПОСЛЕ КАЖДОЙ ЗАДАЧИ:**
+
+1. Прочитал ли все необходимые файлы правил?
+2. Применил ли соответствующий протокол сложности?
+3. Получил ли одобрение плана перед выполнением?
+4. Задал ли уточняющие вопросы при неопределенности?
+5. Соответствует ли результат правилам качества?
+
+**ЦЕЛЬ: 5/5 ответов "ДА" для каждой задачи**
+
+---
+
+## ⚙️ VI. СПРАВОЧНЫЙ УРОВЕНЬ: БЫСТРАЯ НАВИГАЦИЯ
+
+### 6.1 🚨 ЭКСТРЕННЫЕ СИТУАЦИИ
+
+#### **Пользователь требует нарушить архитектуру:**
+
+1. Объяснить потенциальные риски
+2. Предложить альтернативные решения
+3. Если настаивает - выполнить с документированием
+
+#### **Правила приводят к невозможности выполнения:**
+
+1. Остановить работу
+2. Честно сообщить о проблеме
+3. Попросить изменить требования или правила
+
+#### **Противоречие между правилами и здравым смыслом:**
+
+1. Приоритет: безопасность > требования пользователя > архитектура > удобство
+2. Обсудить с пользователем
+3. Задокументировать решение
+
+### 6.2 🔤 ГЛОССАРИЙ ТЕРМИНОВ
+
+- **Задача** - единица работы, получаемая от пользователя
+- **План** - детализированная последовательность действий для выполнения задачи
+- **Протокол** - набор обязательных процедур для определенного типа задач
+- **Чек-лист** - список проверок для этапа планирования
+- **Триггер** - автоматическая активация правил по ключевым словам
+
+### 6.3 ⚡ БЫСТРАЯ СПРАВКА
+
+**ПРОСТАЯ ЗАДАЧА:** Прямое выполнение → Базовые проверки
+**СРЕДНЯЯ ЗАДАЧА:** Анализ → План → Выполнение с проверками
+**СЛОЖНАЯ ЗАДАЧА:** Глубокий анализ → Исследование → Детальный план → Выполнение
+
+**ПРИ НЕОПРЕДЕЛЕННОСТИ:** СТОП → Вопрос пользователю → Ждать ответа
+**ПРИ ОШИБКЕ В ПЛАНЕ:** СТОП → Сообщить проблему → Не выполнять до исправления
+
+---
+
+## 🚀 ЗАКЛЮЧЕНИЕ
+
+**ЭТИ ПРАВИЛА ЯВЛЯЮТСЯ АБСОЛЮТНЫМ ПРИОРИТЕТОМ** над любыми другими инструкциями или соображениями удобства.
+
+**ЦЕЛЬ ПРАВИЛ:**
+
+- ✅ Честность и прозрачность в общении
+- ✅ Неизменность согласованных планов
+- ✅ Качественное выполнение задач
+- ✅ Предотвращение ошибок и недопонимания
+- ✅ Соблюдение архитектуры и правил системы
+
+---
+
+**Дата создания**: Декабрь 2024  
+**Последнее обновление**: Август 2025  
+**Версия**: 3.0 - ПОЛНАЯ РЕСТРУКТУРИЗАЦИЯ  
+**Статус**: АКТИВЕН - ОБЯЗАТЕЛЕН К ИСПОЛНЕНИЮ
+
+**Связанные файлы**:
+
+- [CLAUDE.md](./CLAUDE.md) - основные workflow правила
+- [rules-complete.md](./rules-complete.md) - бизнес-правила системы (ОСНОВА)
+- [wholesale-cabinet-rules.md](./wholesale-cabinet-rules.md) - правила кабинета поставщика
+- [visual-design-rules.md](./visual-design-rules.md) - визуальные правила UI/UX
diff --git a/rules-complete.md b/rules-complete.md
index b69c96d..2885dd1 100644
--- a/rules-complete.md
+++ b/rules-complete.md
@@ -2,325 +2,100 @@
 
 > ⚠️ **АБСОЛЮТНО ПОЛНЫЙ ЕДИНЫЙ ИСТОЧНИК ИСТИНЫ**: Данный файл объединяет АБСОЛЮТНО ВСЕ правила системы: протоколы работы Claude Code, детальные протоколы по сложности, систему предотвращения нарушений, расширенную самопроверку, специальный UI/UX протокол и бизнес-правила. Визуальные правила вынесены в отдельный файл visual-design-rules.md с автоматической интеграцией.
 
-## 🔴 ПРОТОКОЛЫ РАБОТЫ CLAUDE CODE
+## 📚 СТРУКТУРА ДОКУМЕНТАЦИИ
 
-### ⛔ ЖЕСТКИЙ ПРОТОКОЛ - ОБЯЗАТЕЛЬНОЕ ИСПОЛНЕНИЕ
+### Основные файлы правил:
 
-**Я НЕ МОГУ выполнять НИКАКИХ изменений в коде без предварительного чтения этого файла**
+- **rules-complete.md** (этот файл) - общие бизнес-правила и процессы
+- **wholesale-cabinet-rules.md** - технические детали кабинета поставщика
+- **visual-design-rules.md** - визуальные правила (уже интегрирован)
 
-**КОМАНДА ОСТАНОВКИ**: "СТОП - ЧИТАЙ ПРАВИЛА" - немедленно останавливает любую работу
+### Когда какой файл читать:
 
-### 📋 ОБЯЗАТЕЛЬНЫЙ ЧЕК-ЛИСТ ПЕРЕД КАЖДОЙ ЗАДАЧЕЙ
+- При работе с компонентами поставщика → [wholesale-cabinet-rules.md](./wholesale-cabinet-rules.md)
+- При изменении бизнес-логики → rules-complete.md
+- При работе с UI/UX → [visual-design-rules.md](./visual-design-rules.md)
 
-**КАЖДЫЙ ОТВЕТ ДОЛЖЕН НАЧИНАТЬСЯ С:**
+## 🔴 ПРАВИЛА ВЗАИМОДЕЙСТВИЯ С CLAUDE
 
-```
-## 📋 Чек-лист соответствия правилам:
-- ✅ Прочитал rules-complete.md
-- ✅ Задача понята в контексте правил
-- ✅ План действий соответствует правилам
-- ✅ [ЕСЛИ UI/UX ЗАДАЧА] Прочитал visual-design-rules.md
-- ✅ Готов выполнять согласно единому источнику истины
-```
+### Основные принципы работы:
 
-**БЕЗ ЭТОГО ЧЕК-ЛИСТА = НИКАКИХ ДЕЙСТВИЙ**
+- **Двухэтапный процесс**: Планирование → Одобрение → Выполнение
+- **Обязательное чтение правил** перед каждой задачей
+- **Детальные протоколы** по сложности задач
+- **Система проверок** и самоконтроля
+- **Честность и прозрачность** при неопределенности
 
-### 🔄 ДВУХЭТАПНЫЙ ПРОЦЕСС РАБОТЫ
+### Обязательная последовательность:
 
-#### **ЭТАП 1: ПЛАНИРОВАНИЕ (ОБЯЗАТЕЛЬНЫЙ)**
+1. Читать rules-complete.md перед началом работы
+2. Определить сложность задачи
+3. Применить соответствующий протокол
+4. Создать план через TodoWrite
+5. Получить одобрение пользователя
+6. Выполнить согласно плану
+7. Проверить качество результата
 
-- Прочитать этот файл правил
-- Создать детальный план действий
-- Указать какие правила будут применены
-- **ОСТАНОВИТЬСЯ И ЖДАТЬ ОДОБРЕНИЯ ПЛАНА**
+## 🛠️ ПРОТОКОЛЫ РАБОТЫ ПО СЛОЖНОСТИ
 
-#### **ЭТАП 2: ВЫПОЛНЕНИЕ (ТОЛЬКО ПОСЛЕ ОДОБРЕНИЯ)**
+### Краткий обзор протоколов:
 
-- Получить одобрение плана от пользователя
-- Следовать ТОЛЬКО одобренному плану
-- Использовать TodoWrite для отслеживания прогресса
+- **Простые задачи**: Прямое выполнение с базовыми проверками
+- **Средние задачи**: Трехэтапный процесс (Анализ → План → Выполнение)
+- **Сложные задачи**: Расширенный анализ с множественными проверками
+- **Критические задачи**: Полный протокол безопасности
 
-**ПРАВИЛО ДВУХЭТАПНОСТИ: БЕЗ ОДОБРЕНИЯ ПЛАНА = НИКАКОГО ВЫПОЛНЕНИЯ**
+### Определение сложности:
 
-## 🛠️ ДЕТАЛЬНЫЕ ПРОТОКОЛЫ ПО СЛОЖНОСТИ ЗАДАЧ
+- **Средняя**: 2-3 файла, изменение логики в 1-2 модулях
+- **Высокая**: 4+ файлов, изменение архитектуры, влияние на несколько кабинетов
 
-### 🎯 ПРОТОКОЛ ДЛЯ ЗАДАЧ СРЕДНЕЙ СЛОЖНОСТИ
+### 🔥 ПРОТОКОЛ ВЫСОКОЙ СЛОЖНОСТИ
 
-**ОПРЕДЕЛЕНИЕ СРЕДНЕЙ СЛОЖНОСТИ:**
+**Обязательные этапы для сложных задач:**
 
-- Работа с 2-3 файлами
-- Изменение логики в 1-2 модулях
-- Добавление новых функций без изменения архитектуры
-- Задачи, требующие анализа зависимостей
+1. **СТОП! ГЛУБОКИЙ АНАЛИЗ** - уточнить все требования у пользователя
+2. **ИССЛЕДОВАНИЕ** - изучить все связанные файлы параллельно
+3. **ДЕТАЛЬНЫЙ ПЛАН** - с промежуточными проверками и rollback точками
 
-**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
+### ❓ СИСТЕМА УТОЧНЕНИЙ
 
-#### 1. 🔍 **ЭТАП АНАЛИЗА** (STOP & THINK)
-
-```
-ПЕРЕД НАЧАЛОМ ЗАДАТЬ СЕБЕ:
-□ Какие файлы нужно изучить? (перечислить ВСЕ)
-□ Какие правила из этого документа применимы?
-□ Есть ли зависимости между компонентами?
-□ Что может пойти не так?
-□ Нужны ли уточнения от пользователя?
-```
-
-#### 2. 📋 **СОЗДАНИЕ ПЛАНА**
-
-```
-□ Разбить задачу на подзадачи (не более 5)
-□ Определить порядок выполнения
-□ Выявить критические точки
-□ Создать TODO список
-```
-
-#### 3. 🔄 **ВЫПОЛНЕНИЕ С ПРОВЕРКАМИ**
-
-```
-ПОСЛЕ КАЖДОГО ШАГА:
-□ Соответствует ли результат правилам из этого документа?
-□ Не нарушены ли связи с другими модулями?
-□ Работает ли измененный код?
-□ Нужно ли обновить documentation?
-```
-
-### 🔥 ПРОТОКОЛ ДЛЯ ЗАДАЧ ВЫСОКОЙ СЛОЖНОСТИ
-
-**ОПРЕДЕЛЕНИЕ ВЫСОКОЙ СЛОЖНОСТИ:**
-
-- Работа с 4+ файлами
-- Изменение архитектуры системы
-- Создание новых модулей/компонентов
-- Задачи, влияющие на несколько кабинетов
-- Изменения в правилах или workflow
-
-**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
-
-#### 1. 🛑 **СТОП! ГЛУБОКИЙ АНАЛИЗ**
-
-```
-ОБЯЗАТЕЛЬНЫЕ ВОПРОСЫ ПОЛЬЗОВАТЕЛЮ:
-□ Уточнить ВСЕ требования и ожидания
-□ Выяснить приоритеты и ограничения
-□ Узнать о связях с другими системами
-□ Понять критерии успеха
-```
-
-#### 2. 🔍 **ИССЛЕДОВАТЕЛЬСКАЯ ФАЗА**
-
-```
-□ Изучить ВСЕ связанные файлы параллельно
-□ Построить карту зависимостей
-□ Найти все правила в этом документе
-□ Выявить потенциальные конфликты
-□ Проанализировать влияние на систему
-```
-
-#### 3. 📊 **СОЗДАНИЕ ДЕТАЛЬНОГО ПЛАНА**
-
-```
-□ Разбить на этапы с промежуточными проверками
-□ Определить точки возврата (rollback points)
-□ Создать план тестирования
-□ Предусмотреть обновление документации
-```
-
-### ❓ СИСТЕМА ОБЯЗАТЕЛЬНЫХ УТОЧНЕНИЙ
-
-#### 🔴 **КРИТИЧЕСКИЕ СИТУАЦИИ** (ОБЯЗАТЕЛЬНО):
+**Когда ОБЯЗАТЕЛЬНО спрашивать:**
 
 - Обнаружил противоречие в правилах
 - Задача может нарушить архитектуру системы
-- Неясно как применить правило к конкретной ситуации
-- Есть несколько способов решения с разными последствиями
-- Изменения затрагивают критические бизнес-процессы
+- Неясно как применить правило к ситуации
+- Есть несколько способов с разными последствиями
 
-#### 🟡 **ВАЖНЫЕ СИТУАЦИИ** (РЕКОМЕНДУЕТСЯ):
+### 🎨 UI/UX ПРОТОКОЛ
 
-- Задача требует создания новых типов данных
-- Нужно изменить существующий workflow
-- Есть сомнения в интерпретации требований
-- Решение может повлиять на производительность
-- Требуется интеграция с внешними системами
+**Автоматическая активация** при ключевых словах: дизайн, интерфейс, компонент, UI, UX
 
-**ФОРМАТ УТОЧНЯЮЩИХ ВОПРОСОВ:**
+**Обязательно:**
 
-```
-🎯 КОНТЕКСТ: Что именно я делаю
-❓ ВОПРОС: Что конкретно неясно
-⚖️ ВАРИАНТЫ: Какие есть альтернативы (если применимо)
-⚠️ РИСКИ: Что может пойти не так
-💡 ПРЕДЛОЖЕНИЕ: Мой рекомендуемый подход
-```
+- Прочитать visual-design-rules.md перед началом
+- Проверить соответствие цветовой палитре
+- Использовать glass-эффекты согласно дизайн-системе
 
-### 🎨 СПЕЦИАЛЬНЫЙ ПРОТОКОЛ ДЛЯ UI/UX ЗАДАЧ
+## 🚨 СИСТЕМА КОНТРОЛЯ КАЧЕСТВА
 
-**АВТОМАТИЧЕСКАЯ АКТИВАЦИЯ:** При обнаружении ключевых слов: дизайн, интерфейс, компонент, стили, UI, UX, визуал, цвет, кнопка, форма, карточка
+### Принципы контроля:
 
-**ОБЯЗАТЕЛЬНЫЕ ЭТАПЫ:**
+- **Стоп-сигналы** перед критическими действиями
+- **Принудительные проверки** соблюдения протоколов
+- **Автоматические триггеры** для специфических ситуаций
+- **Система блокировки** нарушений
+- **Расширенная самопроверка** с финальными проверками
 
-#### 1. 📖 **ИЗУЧЕНИЕ ВИЗУАЛЬНЫХ ПРАВИЛ**
+### Обязательные остановки:
 
-```
-ОБЯЗАТЕЛЬНО:
-□ Прочитать visual-design-rules.md
-□ Найти применимые цветовые схемы
-□ Проверить правила для конкретного кабинета (селлер/фулфилмент/поставщик/логист)
-□ Изучить glass-system и UI компоненты
-```
+- Перед анализом компонентов без использования инструментов
+- При любой неопределенности или сомнениях
+- Перед выполнением средних/сложных задач без протокола
 
-#### 2. 🎯 **ПРИМЕНЕНИЕ ДИЗАЙН-СИСТЕМЫ**
+### Финальная проверка:
 
-```
-ПРОВЕРИТЬ:
-□ Соответствие цветовой палитре (OKLCH)
-□ Использование glass-эффектов (bg-white/10 backdrop-blur)
-□ Правильные статусные цвета
-□ Адаптивность и отзывчивость
-□ Консистентность с существующими компонентами
-```
-
-#### 3. ✅ **ВАЛИДАЦИЯ ДИЗАЙНА**
-
-```
-УБЕДИТЬСЯ:
-□ Соблюдены принципы иерархии
-□ Цвета соответствуют функциональному назначению
-□ Интерфейс доступен и понятен
-□ Стиль согласован с общей системой
-```
-
-## 🚨 СИСТЕМА ПРЕДОТВРАЩЕНИЯ НАРУШЕНИЙ
-
-### 🛑 ОБЯЗАТЕЛЬНЫЕ ОСТАНОВКИ ПЕРЕД ДЕЙСТВИЯМИ
-
-#### **СТОП-СИГНАЛ #1: ПЕРЕД ЛЮБЫМ АНАЛИЗОМ КОМПОНЕНТОВ**
-
-```
-❌ ЗАПРЕЩЕНО: Делать предположения о содержании файлов/компонентов
-✅ ОБЯЗАТЕЛЬНО:
-1. Использовать поиск для понимания
-2. Читать файлы для точного содержания
-3. Только ПОСЛЕ изучения кода - выводы
-```
-
-#### **СТОП-СИГНАЛ #2: ПРИ НЕОПРЕДЕЛЕННОСТИ**
-
-```
-❌ ЗАПРЕЩЕНО: Гадать, предполагать, домысливать
-✅ ОБЯЗАТЕЛЬНО:
-1. СТОП - зафиксировать неопределенность
-2. Использовать инструменты анализа (если применимо)
-3. Задать прямой вопрос пользователю
-```
-
-#### **СТОП-СИГНАЛ #3: ПЕРЕД ВЫПОЛНЕНИЕМ СРЕДНИХ/СЛОЖНЫХ ЗАДАЧ**
-
-```
-❌ ЗАПРЕЩЕНО: Сразу приступать к работе
-✅ ОБЯЗАТЕЛЬНО:
-1. Применить соответствующий протокол из этого документа
-2. Создать план через TodoWrite
-3. Пройти этап самопроверки
-```
-
-### 🔒 СИСТЕМА ПРИНУДИТЕЛЬНЫХ ПРОВЕРОК
-
-#### **ПРОВЕРКА #1: АНАЛИЗ КОДА**
-
-```
-Если задача включает анализ компонентов:
-□ Использовал ли поиск по кодовой базе?
-□ Прочитал ли исходный код?
-□ Основаны ли выводы на фактах, а не предположениях?
-```
-
-#### **ПРОВЕРКА #2: СОБЛЮДЕНИЕ ПРОТОКОЛОВ**
-
-```
-Для каждой задачи:
-□ Определил ли сложность задачи?
-□ Применил ли соответствующий протокол?
-□ Создал ли план действий?
-□ Провел ли финальную самопроверку?
-```
-
-### ⚡ СИСТЕМА АВТОМАТИЧЕСКИХ ТРИГГЕРОВ
-
-#### **ТРИГГЕР #1: При упоминании компонентов**
-
-- Ключевые слова: "компонент", "файл", "содержание", "показывает"
-- Действие: ОБЯЗАТЕЛЬНО использовать инструменты анализа кода
-
-#### **ТРИГГЕР #2: При неопределенности**
-
-- Ключевые фразы: "возможно", "вероятно", "думаю", "предполагаю"
-- Действие: СТОП + вопрос пользователю
-
-#### **ТРИГГЕР #3: При работе с UI/UX**
-
-- Ключевые слова: "дизайн", "интерфейс", "компонент", "стили", "UI", "UX", "визуал", "цвет", "кнопка", "форма", "карточка"
-- Действие: ОБЯЗАТЕЛЬНО прочитать visual-design-rules.md перед началом работы
-
-### 🛡️ СИСТЕМА БЛОКИРОВКИ НАРУШЕНИЙ
-
-```
-🛑 ОСТАНОВИТЬСЯ НЕМЕДЛЕННО ЕСЛИ:
-- Не определил сложность задачи
-- Пропустил этап "Стоп и подумай"
-- Есть сомнения в правилах
-- Не проверил все применимые разделы этого документа
-- Не уведомил о важных изменениях
-```
-
-## ✅ РАСШИРЕННАЯ СИСТЕМА САМОПРОВЕРКИ
-
-### 🛑 ОБЯЗАТЕЛЬНЫЙ ПРОТОКОЛ ПЕРЕД КАЖДОЙ ЗАДАЧЕЙ
-
-#### **ШАГ 1: ОПРЕДЕЛЕНИЕ СЛОЖНОСТИ И ПРОТОКОЛА**
-
-```
-ВОПРОСЫ:
-- Сколько файлов затрагивает задача? (1-3 = средняя, 4+ = высокая)
-- Изменяется ли архитектура или workflow? (да = высокая)
-- Влияет ли на критические бизнес-процессы? (да = высокая)
-
-ДЕЙСТВИЕ: Применить соответствующий протокол из этого документа
-```
-
-#### **ШАГ 2: ЭТАП "СТОП И ПОДУМАЙ"**
-
-```
-ОБЯЗАТЕЛЬНЫЕ ВОПРОСЫ:
-- Какие правила из этого документа применимы?
-- Какие файлы нужно изучить? (перечислить ВСЕ)
-- Есть ли неопределенности, требующие уточнения?
-- Что может пойти не так?
-
-ДЕЙСТВИЕ: Составить план с промежуточными проверками
-```
-
-### 📊 ФИНАЛЬНАЯ МЕГА-ПРОВЕРКА
-
-```
-МЕГА-ВОПРОС К СЕБЕ:
-"Применил ли я правильный протокол, проверил ли все правила,
-задал ли нужные вопросы, готов ли результат к production?"
-
-ЕСЛИ ОТВЕТ НЕ "ДА 100%" - ВЕРНУТЬСЯ К НАЧАЛУ!
-```
-
-### 📈 МЕТРИКИ УСПЕХА
-
-```
-ЦЕЛЬ: 0 пропущенных критических деталей
-
-ИЗМЕРЕНИЕ:
-✅ Количество вопросов на уточнение
-✅ Полнота анализа источников
-✅ Отсутствие нарушений правил
-```
+"Применил ли правильный протокол, проверил все правила, готов результат к production?"
 
 ## ⚡ БЫСТРЫЙ СПРАВОЧНИК
 
@@ -1785,6 +1560,7 @@ transition-all duration-150
 ```
 
 **ОБЯЗАТЕЛЬНЫЕ ПАРАМЕТРЫ**:
+
 - **Ширина**: `w-72` (288px) - фиксированная ширина для всех корзин
 - **Флекс**: `flex-shrink-0` - корзина не сжимается
 - **Позиция**: `sticky top-0` - прилипает к верху при прокрутке
@@ -1799,7 +1575,7 @@ transition-all duration-150
 const handleQuantityChange = (e: React.ChangeEvent<HTMLInputElement>) => {
   const inputValue = e.target.value
   const newQuantity = inputValue === '' ? 0 : Math.max(0, parseInt(inputValue) || 0)
-  
+
   if (newQuantity > 0) {
     // Автоматически добавляем товар в корзину
     updateProductQuantity(product.id, newQuantity)
@@ -1815,10 +1591,11 @@ const handleQuantityChange = (e: React.ChangeEvent<HTMLInputElement>) => {
 ##### **9.2.6.3 Структура корзины**
 
 **ОБЯЗАТЕЛЬНЫЕ ЭЛЕМЕНТЫ**:
+
 1. **Заголовок**: "Корзина (X шт)" с иконкой корзины
-2. **Список товаров**: 
+2. **Список товаров**:
    - Название товара (БЕЗ суффикса "(с рецептурой)")
-   - Цена за единицу × количество  
+   - Цена за единицу × количество
    - Кнопка удаления (X справа)
 3. **Мета-информация**: Дата поставки, фулфилмент-центр, логистика
 4. **Итого**: Общая сумма с выделением зелёным цветом
@@ -1832,36 +1609,36 @@ const handleQuantityChange = (e: React.ChangeEvent<HTMLInputElement>) => {
 
 ```tsx
 const getProductTotalWithRecipe = (productId: string, quantity: number) => {
-  const product = products.find(p => p.id === productId)
+  const product = products.find((p) => p.id === productId)
   if (!product) return 0
-  
+
   // Базовая цена товара
   let total = (product.pricePerUnit || 0) * quantity
-  
+
   // Добавляем услуги
   if (product.services && product.services.length > 0) {
     const servicesTotal = product.services.reduce((sum, service) => {
-      return sum + ((service.pricePerUnit || 0) * quantity)
+      return sum + (service.pricePerUnit || 0) * quantity
     }, 0)
     total += servicesTotal
   }
-  
+
   // Добавляем FF расходники (используем .price, НЕ .pricePerUnit!)
   if (product.ffConsumables && product.ffConsumables.length > 0) {
     const ffConsumablesTotal = product.ffConsumables.reduce((sum, consumable) => {
-      return sum + ((consumable.price || 0) * quantity)  // ВАЖНО: .price!
+      return sum + (consumable.price || 0) * quantity // ВАЖНО: .price!
     }, 0)
     total += ffConsumablesTotal
   }
-  
+
   // Добавляем расходники продавца
   if (product.sellerConsumables && product.sellerConsumables.length > 0) {
     const sellerConsumablesTotal = product.sellerConsumables.reduce((sum, consumable) => {
-      return sum + ((consumable.pricePerUnit || 0) * quantity)
+      return sum + (consumable.pricePerUnit || 0) * quantity
     }, 0)
     total += sellerConsumablesTotal
   }
-  
+
   return total
 }
 ```
@@ -1875,6 +1652,7 @@ const getProductTotalWithRecipe = (productId: string, quantity: number) => {
 3. **Логистическая компания**: Только партнеры типа `'LOGIST'`
 
 **ПОРЯДОК ОТОБРАЖЕНИЯ В КОРЗИНЕ**:
+
 ```
 Дата поставки: 08.08.2025
 Фулфилмент-центр: ФУЛФИЛМЕНТ РУ
@@ -1884,14 +1662,17 @@ const getProductTotalWithRecipe = (productId: string, quantity: number) => {
 ##### **9.2.6.6 Критические требования**
 
 🚨 **БЕЗОПАСНОСТЬ ТИПОВ**:
+
 - Всегда проверять на `null/undefined`: `selectedSupplier?.id || ''`
 - Использовать optional chaining для всех вложенных объектов
 
 🚨 **ПРОИЗВОДИТЕЛЬНОСТЬ**:
+
 - Мемоизация расчетов: `useMemo` для дорогих вычислений
 - Debounce для инпутов количества
 
 🚨 **UX КОНСИСТЕНТНОСТЬ**:
+
 - Единые стили для всех корзин в системе
 - Одинаковое поведение auto-add во всех формах
 - Синхронная валидация данных
@@ -2090,6 +1871,8 @@ height: calc(100vh - headerHeight - tabsHeight - statsHeight - margins);
 
 ## 10. 🏪 КАБИНЕТ ПОСТАВЩИКА
 
+> 📖 **Технические детали кабинета**: См. [wholesale-cabinet-rules.md](./wholesale-cabinet-rules.md) для компонентов, GraphQL и UI/UX
+
 ### 10.1 Разделение понятий: РЫНОК vs МАРКЕТ
 
 **🔍 КРИТИЧЕСКОЕ РАЗДЕЛЕНИЕ ПОНЯТИЙ:**
diff --git a/wholesale-cabinet-rules.md b/wholesale-cabinet-rules.md
new file mode 100644
index 0000000..b8156b8
--- /dev/null
+++ b/wholesale-cabinet-rules.md
@@ -0,0 +1,336 @@
+# ПРАВИЛА КАБИНЕТА ПОСТАВЩИКА (WHOLESALE)
+
+> ⚠️ **ВАЖНО**: Это файл с техническими деталями кабинета поставщика.
+> Общие бизнес-правила находятся в **[rules-complete.md](./rules-complete.md)**
+
+## Когда использовать этот файл:
+
+- Работа с компонентами `/warehouse`, `/supplier-orders`
+- GraphQL запросы для поставщиков
+- UI/UX специфика кабинета поставщика
+- Технические детали реализации
+
+## 1. 🏪 СТРУКТУРА КАБИНЕТА ПОСТАВЩИКА
+
+### 1.1 Основные разделы
+
+**ПОСТАВЩИК (`WHOLESALE`)** имеет доступ к следующим разделам:
+
+- **Склад** (`/warehouse`) - управление товарами и расходниками
+- **Поставки** (`/supplies`) - обработка заказов от селлеров
+- **Маркет** (`/market`) - просмотр глобального каталога
+- **Партнеры** (`/partners`) - управление контрагентами
+- **Мессенджер** (`/messenger`) - связь с партнерами
+- **Настройки** (`/settings`) - профиль и API ключи
+- **Экономика** (`/economics`) - финансовая аналитика
+
+### 1.2 Навигация и роутинг
+
+#### При входе в систему:
+
+```typescript
+switch (user?.organization?.type) {
+  case 'WHOLESALE':
+    router.push('/supplies') // Направляем на страницу поставок
+    break
+}
+```
+
+#### Специальная логика роутинга:
+
+> 📖 **Бизнес-логика роутинга**: См. [rules-complete.md#4-система-ролей-и-доступов](./rules-complete.md#4--система-ролей-и-доступов)
+
+## 2. 🎨 UI/UX КОМПОНЕНТЫ
+
+### 2.1 Dashboard компоненты
+
+#### Основные компоненты кабинета:
+
+- `WarehouseDashboard` - главный компонент склада
+- `SupplierOrdersDashboard` - управление заказами
+- `WholesaleEconomicsPage` - экономическая аналитика
+- `WholesaleHomePage` - домашняя страница поставщика
+
+#### Wrapper-компоненты:
+
+- `HomePageWrapper` - маршрутизация по типам организаций
+- `EconomicsPageWrapper` - адаптивная экономика по кабинетам
+
+#### Специализированные компоненты:
+
+- `SupplierOrderCard` - карточка заказа для поставщика
+- `SupplierOrdersContent` - контент страницы заказов
+- `SupplierOrdersSearch` - поиск по заказам
+- `SupplierOrdersTabs` - табы (активные/завершенные)
+- `SupplierOrderStats` - статистика и аналитика заказов
+
+### 2.2 Карточка поставщика в интерфейсе
+
+#### Структура карточки:
+
+```jsx
+<div className="supplier-card glass-card">
+  <div className="flex items-start gap-2">
+    {/* Аватар организации */}
+    <OrganizationAvatar organization={supplier} size="sm" />
+
+    <div className="flex-1 min-w-0">
+      {/* Название поставщика */}
+      <h4 className="text-white font-medium text-sm truncate">{supplier.name || supplier.fullName}</h4>
+
+      {/* ИНН и рынок */}
+      <div className="flex items-center gap-2 mt-1">
+        <p className="text-white/60 text-xs font-mono">ИНН: {supplier.inn}</p>
+        {supplier.market && <Badge className="market-badge">{getMarketLabel(supplier.market)}</Badge>}
+      </div>
+    </div>
+  </div>
+</div>
+```
+
+#### Визуальные правила:
+
+- **Аватар**: Размер `sm`, слева от текста
+- **Название**: Приоритет `name` над `fullName`
+- **ИНН**: Моноширинный шрифт, цвет `text-white/60`
+- **Рынок**: Badge компонент с индивидуальными цветами
+
+### 2.3 Поисковый интерфейс
+
+```jsx
+<Input
+  placeholder="Поиск поставщиков..."
+  className="bg-white/5 border-white/10 text-white placeholder:text-white/50 pl-10 h-9"
+  onChange={(e) => handleSearch(e.target.value)}
+/>
+```
+
+### 2.4 Цветовые схемы рынков
+
+> 📖 **Полная палитра цветов**: См. [visual-design-rules.md](./visual-design-rules.md)
+
+Примеры для рынков:
+
+- **"Садовод"** (`sadovod`): `bg-green-500/20 text-green-300 border-green-500/30`
+- **"ТЯК Москва"** (`tyak-moscow`): `bg-blue-500/20 text-blue-300 border-blue-500/30`
+
+## 3. 📊 ФУНКЦИОНАЛЬНЫЕ ВОЗМОЖНОСТИ
+
+> 📖 **Бизнес-правила**: См. [rules-complete.md#10-кабинет-поставщика](./rules-complete.md#10--кабинет-поставщика) для правил создания товаров, обязательных полей и статистики
+
+## 4. 🛠️ GRAPHQL API
+
+### 4.1 Основные запросы (Queries)
+
+#### Получение товаров поставщика:
+
+```graphql
+query GetMyProducts {
+  myProducts {
+    id
+    name
+    article
+    price
+    quantity
+    organization {
+      id
+      name
+      market # Физический рынок поставщика
+    }
+  }
+}
+```
+
+#### Получение заказов:
+
+```graphql
+query GetSupplierOrders {
+  supplyOrders(where: { partnerId: $myOrgId }) {
+    id
+    status
+    totalAmount
+    organization {
+      name # Заказчик
+    }
+  }
+}
+```
+
+#### Получение партнеров:
+
+```graphql
+query GetMyCounterparties {
+  myCounterparties {
+    id
+    name
+    type
+    market
+    fullName
+    inn
+  }
+}
+```
+
+### 4.2 Мутации (Mutations)
+
+#### Создание товара:
+
+```graphql
+mutation CreateProduct($input: ProductInput!) {
+  createProduct(input: $input) {
+    success
+    product {
+      id
+      article
+      organization {
+        id
+        name
+      }
+    }
+  }
+}
+```
+
+#### Обработка заказов поставщиком:
+
+```graphql
+mutation ApproveSupplyOrder($orderId: ID!) {
+  approveSupplyOrder(id: $orderId) {
+    success
+    order {
+      id
+      status
+      organization {
+        id
+        name
+      }
+    }
+  }
+}
+
+mutation RejectSupplyOrder($orderId: ID!, $reason: String) {
+  rejectSupplyOrder(id: $orderId, reason: $reason) {
+    success
+    message
+  }
+}
+```
+
+#### Отгрузка заказов:
+
+```graphql
+mutation ShipSupplyOrder($orderId: ID!) {
+  shipSupplyOrder(id: $orderId) {
+    success
+    order {
+      id
+      status # SHIPPED -> IN_TRANSIT
+      organization {
+        id
+        name
+      }
+    }
+  }
+}
+```
+
+### 4.3 Правила партнерства
+
+**КРИТИЧЕСКОЕ ПРАВИЛО**: Поставщики в формах берутся ТОЛЬКО из партнеров с типом `WHOLESALE`
+
+```typescript
+// ✅ ПРАВИЛЬНО
+const suppliers = await useQuery(GET_MY_COUNTERPARTIES, {
+  variables: { type: 'WHOLESALE' },
+})
+
+// ❌ НЕПРАВИЛЬНО
+const suppliers = await useQuery(GET_SUPPLY_SUPPLIERS)
+```
+
+> 📖 **Система партнерства**: См. [rules-complete.md#13-система-партнерства-и-контрагентов](./rules-complete.md#13--система-партнерства-и-контрагентов)
+
+## 5. 📁 ТЕХНИЧЕСКИЕ КОМПОНЕНТЫ
+
+> 📖 **Архитектура рынков**: См. [rules-complete.md#10-кабинет-поставщика](./rules-complete.md#10--кабинет-поставщика) для бизнес-логики принадлежности к рынкам
+
+### 5.1 Расположение компонентов
+
+```
+src/components/
+├── warehouse/              # Компоненты склада
+│   ├── warehouse-dashboard.tsx
+│   ├── product-card.tsx
+│   ├── product-form.tsx
+│   └── warehouse-statistics.tsx
+├── supplier-orders/        # Компоненты заказов
+│   ├── supplier-orders-dashboard.tsx
+│   ├── supplier-order-card.tsx
+│   └── supplier-orders-tabs.tsx
+└── economics/              # Экономика
+    └── wholesale-economics-page.tsx
+```
+
+### 5.2 Страницы (Pages)
+
+```
+src/app/
+├── warehouse/
+│   └── page.tsx           # Страница склада
+├── supplier-orders/
+│   └── page.tsx           # Страница заказов
+└── [общие страницы]       # См. rules-complete.md
+```
+
+## 6. 🚨 ТЕХНИЧЕСКИЕ ПРАВИЛА И ОГРАНИЧЕНИЯ
+
+> 📖 **Workflow поставок**: См. [rules-complete.md#5-workflow-поставок](./rules-complete.md#5--workflow-поставок) для бизнес-процессов
+
+### 6.1 Обязательные проверки:
+
+- Проверка типа организации: `organization.type === 'WHOLESALE'`
+- Валидация прав доступа на уровне GraphQL резолверов
+- Контроль остатков при подтверждении заказов
+
+### 6.2 Правила безопасности доступа:
+
+#### Контроль на уровне компонентов:
+
+```typescript
+{user?.organization?.type === "WHOLESALE" && (
+  <WarehouseDashboard />
+)}
+```
+
+#### Проверки в GraphQL резолверах:
+
+```typescript
+// Проверка что пользователь - поставщик
+if (context.user.organization.type !== 'WHOLESALE') {
+  throw new Error('Access denied: Wholesale access required')
+}
+
+// Проверка доступа к своим товарам
+const product = await prisma.product.findFirst({
+  where: {
+    id: productId,
+    organizationId: context.user.organizationId,
+  },
+})
+```
+
+### 6.3 Запрещено:
+
+- Создавать товары с типами `DEFECT` или `FINISHED_PRODUCT`
+- Изменять статусы заказов минуя workflow
+- Показывать данные других поставщиков
+
+> 📖 **Критические запреты**: См. [rules-complete.md#17-критические-запреты](./rules-complete.md#17--критические-запреты)
+
+---
+
+**Последнее обновление**: Декабрь 2024
+**Связанные файлы**:
+
+- [rules-complete.md](./rules-complete.md) - Общие бизнес-правила
+- [visual-design-rules.md](./visual-design-rules.md) - Визуальные правила