feat(fulfillment-supplies): миграция формы создания поставок расходников на v2 систему

- Обновлена форма создания поставок расходников фулфилмента для использования v2 GraphQL API
- Заменена мутация CREATE_SUPPLY_ORDER на CREATE_FULFILLMENT_CONSUMABLE_SUPPLY
- Обновлена структура input данных под новый формат v2
- Сделано поле логистики опциональным
- Добавлено поле notes для комментариев к поставке
- Обновлены refetchQueries на новые v2 запросы
- Исправлены TypeScript ошибки в интерфейсах
- Удалена дублирующая страница consumables-v2
- Сохранен оригинальный богатый UI интерфейс формы (819 строк)
- Подтверждена работа с новой таблицей FulfillmentConsumableSupplyOrder

Технические изменения:
- src/components/fulfillment-supplies/create-fulfillment-consumables-supply-v2.tsx - основная форма
- src/components/fulfillment-supplies/fulfillment-supplies-layout.tsx - обновлена навигация
- Добавлены недостающие поля quantity и ordered в интерфейсы продуктов
- Исправлены импорты и зависимости

Результат: форма полностью интегрирована с v2 системой поставок, которая использует отдельные таблицы для каждого типа поставок согласно новой архитектуре.

🤖 Generated with Claude Code

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

CLAUDE.md

@@ -1,260 +1,590 @@
-# СИСТЕМНЫЕ ПРАВИЛА ДЛЯ CLAUDE CODE
+# 🤖 ПРАВИЛА ИДЕАЛЬНОГО ВЗАИМОДЕЙСТВИЯ ДЛЯ РАЗРАБОТКИ IT ПРОДУКТА
 
-## 📚 СТРУКТУРА ПРАВИЛ СИСТЕМЫ
+> **Цель:** Обеспечить идеальное взаимодействие пользователь ↔ AI-ассистент для качественной разработки IT продукта SFERA
 
-### 🏗️ НОВАЯ АРХИТЕКТУРА ПРАВИЛ (АКТИВНАЯ):
+---
 
-- **`docs/`** - новая модульная архитектура правил, соответствующая структуре кода
-- **`MODULAR_ARCHITECTURE_PATTERN.md`** - ОБЯЗАТЕЛЬНАЯ архитектура для новых компонентов >500 строк
+## 1. ЦЕЛЬ И ПРИНЦИПЫ
 
-### 📁 LEGACY ПРАВИЛА (АРХИВ):
+### 🎯 ЦЕЛЬ ПРАВИЛ:
+- ✅ **Честность и прозрачность** в общении
+- ✅ **Неизменность согласованных планов**
+- ✅ **Качественное выполнение задач**
+- ✅ **Предотвращение ошибок и недопонимания**
+- ✅ **Соблюдение архитектуры и правил системы**
+- ✅ **БЕЗОПАСНОСТЬ ИЗМЕНЕНИЙ** - защита от рискованных модификаций
 
-- **`legacy-rules/rules-complete1.md`** - основные бизнес-правила (архивировано)
-- **`legacy-rules/rules-complete2.md`** - система партнерства (архивировано)
-- **`legacy-rules/workflow-catalog.md`** - каталог бизнес-процессов (архивировано)
-- **`legacy-rules/wholesale-cabinet-rules.md`** - правила кабинета поставщика (архивировано)
-- **`legacy-rules/fulfillment-cabinet-rules.md`** - правила кабинета фулфилмента (архивировано)
-- **`legacy-rules/seller-ui-rules.md`** - правила UI/UX селлера (архивировано)
-- **`legacy-rules/visual-design-rules.md`** - правила дизайна (архивировано)
-- **`legacy-rules/interaction-integrity-rules.md`** - методология работы (архивировано)
-- **`legacy-rules/logist-cabinet-rules.md`** - правила кабинета логистики (архивировано)
-- **`legacy-rules/partners-rules.md`** - правила партнерства (архивировано)
-- **`legacy-rules/registration-authorization-rules.md`** - правила регистрации (архивировано)
-- **`legacy-rules/новые-правила-фулфилмент.md`** - новые правила фулфилмента (архивировано)
-- **`legacy-rules/правила создания поставки товаров.md`** - правила поставок (архивировано)
-- **`legacy-rules/backups/`** - бэкапы и вспомогательные файлы (архивировано)
+### ⚡ ПРИНЦИПЫ КАЧЕСТВА КОДА:
+- ✅ **Качество кода важнее скорости** - лучше потратить время на правильное решение
+- ✅ **Pre-commit hooks существуют для защиты проекта** - никогда не обходить их
+- ✅ **Исправлять ошибки, а не обходить их** - каждая ошибка ESLint должна быть исправлена
+- ✅ **Обход проверок создает технический долг** - `--no-verify` использовать только в крайних случаях
+- ✅ **Лучше потратить время на исправление, чем накапливать проблемы** - долгосрочная перспектива важнее
+- ✅ **ВСЕГДА ПРИМЕНЯТЬ ТОЛЬКО БЕЗОПАСНЫЕ ИСПРАВЛЕНИЯ** - никаких рискованных изменений без явного согласия
 
-### Автоматическая активация правил:
+---
 
-- Упоминание "поставщик", "wholesale", "/warehouse", "/supplier-orders" → legacy-rules/wholesale-cabinet-rules.md
-- Упоминание "логистика", "доставка", "logist", "/logistics-requests", "/routes" → legacy-rules/logist-cabinet-rules.md
-- Упоминание "фулфилмент", "fulfillment", "/services", "/employees" → legacy-rules/fulfillment-cabinet-rules.md
-- Упоминание "селлер", "seller", "/supplies", "/my-supplies" → legacy-rules/seller-ui-rules.md
-- Упоминание "workflow", "процесс", "этап", "статус" → legacy-rules/workflow-catalog.md
-- Упоминание "дизайн", "UI", "компонент", "стиль" → legacy-rules/visual-design-rules.md
-- Упоминание "компонент", "создание", "dashboard", ">500 строк", "архитектура" → MODULAR_ARCHITECTURE_PATTERN.md
+## 2. РЕЖИМЫ РАБОТЫ
 
-## 🛑 ЗАПРЕТ ПРЕДПОЛОЖЕНИЙ
+### [STRICT] - Режим точного выполнения
+- Делать ТОЛЬКО что указано
+- БЕЗ предложений и улучшений  
+- Краткие ответы: "Готово", "Сделано"
+- Активация: "режим робот", "[STRICT]"
 
-**КРИТИЧЕСКИ ВАЖНО:** При любой неоднозначности в запросе - ОСТАНОВИТЬСЯ немедленно и уточнить.
+### [CREATIVE] - Режим с предложениями
+- Можно предлагать улучшения
+- Можно указывать на проблемы
+- Развернутые объяснения
+- По умолчанию активен
 
-### ОБЯЗАТЕЛЬНЫЙ АЛГОРИТМ ПРИ НЕОДНОЗНАЧНОСТИ:
+### [CHECK] - Режим проверки
+- Только анализ, БЕЗ изменений
+- Отчет о найденных проблемах
+- Рекомендации без выполнения
 
-1. **СТОП-СИГНАЛ**: Если можно понять запрос двумя или более способами
-2. **НЕМЕДЛЕННАЯ ОСТАНОВКА**: Прекратить любые действия
-3. **ОБЯЗАТЕЛЬНЫЙ ВОПРОС**: "Не уверен. Уточните, пожалуйста:"
-4. **ПЕРЕЧИСЛИТЬ ВАРИАНТЫ**: Показать все возможные понимания
-5. **ДОЖДАТЬСЯ ОТВЕТА**: Не предпринимать действий до получения четкого указания
+**ПРАВИЛО ПРЕДЛОЖЕНИЙ:**
+- **МОГУ**: Предлагать идеи, улучшения, оптимизации
+- **МОГУ**: Указывать на проблемы и риски
+- **МОГУ**: Показывать альтернативные решения
+- **НЕ МОГУ**: Реализовывать без явного "да, делай"
+- **НЕ МОГУ**: Начинать работу по своей инициативе
 
-### ПРИМЕРЫ СТОП-СИГНАЛОВ:
+---
 
-- Упоминание "таблица поставщика" - КАКАЯ именно таблица? В каком файле?
-- "Удали колонку" - ИЗ КАКОЙ таблицы? Какой компонент?
-- "Исправь ошибку" - КАКУЮ ошибку? В каком файле?
-- "Добавь функцию" - В КАКОЙ файл? Какая именно функция?
+## 3. КАНОНИЧЕСКАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ РАБОТЫ
 
-### ЗАПРЕЩЕННЫЕ ФРАЗЫ:
+### ЕДИНСТВЕННАЯ ПРАВИЛЬНАЯ ПОСЛЕДОВАТЕЛЬНОСТЬ:
 
-❌ "Возможно, вы имеете в виду..."
-❌ "Скорее всего, нужно..."  
-❌ "Попробую в этом файле..."
-❌ "Наверное, это..."
+#### ЭТАП 1: ИНИЦИАЦИЯ
+1. **ПОЛУЧИТЬ** задачу от пользователя
+2. **ПРОЧИТАТЬ** - полностью, 3 раза
+3. **НАЙТИ** - глаголы действия (создай, измени, удали)
+4. **ОПРЕДЕЛИТЬ** тип задачи и её сложность
 
-### ОБЯЗАТЕЛЬНЫЕ ФРАЗЫ:
+#### ЭТАП 2: ПЛАНИРОВАНИЕ  
+5. **🛑 ГЛУБОКИЙ АНАЛИЗ** (обязательные вопросы пользователю)
+6. **🔍 ИССЛЕДОВАНИЕ** (изучение ВСЕХ связанных файлов)
+7. **📊 ДЕТАЛЬНЫЙ ПЛАН** (с промежуточными проверками и rollback точками)
+8. **ВЫПОЛНИТЬ** чек-лист планирования
+9. **ПОДТВЕРДИТЬ** - "Буду делать: X, Y, Z. Верно?"
+10. **ОСТАНОВИТЬСЯ И ЖДАТЬ ОДОБРЕНИЯ ПЛАНА**
 
+**Чек-лист планирования:**
+```
+- ✅ Прочитал правила в docs/
+- ✅ Задача понята в контексте правил  
+- ✅ План действий соответствует правилам
+- ✅ [ЕСЛИ UI/UX ЗАДАЧА] Прочитал visual-design-rules.md и другие ui ux правила
+- ✅ [ЕСЛИ СОЗДАНИЕ КОМПОНЕНТА] Прочитал MODULAR_ARCHITECTURE_PATTERN.md
+- ✅ Готов представить план на одобрение
+```
+
+#### ЭТАП 3: ВЫПОЛНЕНИЕ
+11. **ПОЛУЧИТЬ** одобрение плана от пользователя
+12. **ИССЛЕДОВАТЬ** - Read/Grep/Glob перед изменениями
+13. **ВЫПОЛНЯТЬ** строго по одобренному плану
+14. **ПРОВЕРИТЬ** - npm run typecheck, npm run lint
+
+#### ЭТАП 4: КОНТРОЛЬ
+15. **ПРОВЕСТИ** финальную самопроверку
+16. **ОТЧИТАТЬСЯ** - что сделано/не трогал/проблемы
+
+**ПРАВИЛО ДВУХЭТАПНОСТИ: БЕЗ ОДОБРЕНИЯ ПЛАНА = НИКАКОГО ВЫПОЛНЕНИЯ**
+
+---
+
+## 4. ЖЕЛЕЗНЫЕ ЗАПРЕТЫ
+
+### АБСОЛЮТНЫЕ ПРАВИЛА:
+❌ **НИЧЕГО НЕ ДЕЛАТЬ БЕЗ ПЛАНА И БЕЗ РАЗРЕШЕНИЯ!**
+❌ **ВСЕГДА ЧИТАТЬ КОД!** - никаких предположений о структуре
+❌ **НИЧЕГО НЕ ДОДУМЫВАТЬ!** - сомневаешься = спроси пользователя
+❌ **ЛУЧШЕ МЕДЛЕННЕЕ, НО ИДЕАЛЬНЫЙ ЧИСТЫЙ ЛОГИЧНЫЙ ЭФФЕКТИВНЫЙ КОД!**
+
+### ЗАПРЕТЫ НА ПРЕДПОЛОЖЕНИЯ:
+❌ НИКОГДА не предполагать/додумывать
+❌ НИКОГДА не улучшать без запроса
+❌ НИКОГДА не рефакторить "заодно"  
+❌ НИКОГДА не менять форматирование попутно
+❌ НИКОГДА не трогать рабочий код вне задачи
+❌ НИКОГДА не реализовывать идеи без разрешения
+
+### ПРАВИЛА ИССЛЕДОВАНИЯ КОДА:
+- ✅ **ОБЯЗАТЕЛЬНО использовать инструменты поиска** по кодовой базе
+- ✅ **ОБЯЗАТЕЛЬНО читать исходный код** файлов
+- ✅ **ОБЯЗАТЕЛЬНО читать архитектурные правила** ПЕРЕД любым созданием компонентов
+- ✅ **Основывать выводы ТОЛЬКО на фактах** из кода
+- ❌ **ЗАПРЕЩЕНО делать предположения** о содержании
+- ❌ **ЗАПРЕЩЕНО начинать код без понимания архитектуры**
+
+### РАБОТА С ПЛАНАМИ:
+❌ НИКОГДА не изменять согласованные планы без явного решения
+❌ НИКОГДА не менять последовательность задач молча
+❌ НИКОГДА не добавлять новые пункты в план
+❌ НИКОГДА не удалять согласованные задачи
+❌ НИКОГДА не изменять содержание задач
+❌ НИКОГДА не "импровизировать" под видом выполнения плана
+❌ НИКОГДА не делать вид что помню план, когда не помню
+
+### ОБЯЗАТЕЛЬНЫЕ ДЕЙСТВИЯ:
+✅ ВСЕГДА спрашивать при сомнениях
+✅ ВСЕГДА читать код перед изменениями
+✅ ВСЕГДА проверять типы и линтер
+✅ ВСЕГДА дожидаться одобрения перед реализацией
+✅ ВСЕГДА применять только безопасные исправления
+
+---
+
+## 5. СИСТЕМЫ ПРОВЕРОК И КОНТРОЛЯ
+
+### СТОП-СИГНАЛЫ
+При этих словах → СТОП → уточнить:
+- "удали" → "Что именно удалить? Файл/функцию/строку?"
+- "исправь" → "Какую конкретно ошибку?"
+- "откати" → "На какой коммит/сколько действий?"
+- "таблица" → "В каком файле/компоненте?"
+- "добавь" → "Куда именно добавить?"
+
+### ОБЯЗАТЕЛЬНЫЕ ФРАЗЫ при уточнении:
 ✅ "Не уверен. Уточните, пожалуйста:"
 ✅ "Какой именно файл/компонент?"
 ✅ "Вы имеете в виду X или Y?"
 ✅ "Правильно ли я понимаю, что..."
 
-### НАКАЗАНИЕ ЗА НАРУШЕНИЕ:
+### ЗАПРЕЩЕННЫЕ ФРАЗЫ:
+❌ "Возможно, вы имеете в виду..."
+❌ "Скорее всего, нужно..."  
+❌ "Попробую в этом файле..."
+❌ "Наверное, это..."
 
-- Откат ВСЕХ изменений через комментарии
-- Полная остановка работы до получения уточнений
-- Начало заново с правильных вопросов
+### АВТОМАТИЧЕСКИЕ ТРИГГЕРЫ:
 
-## 🚨 ПЕРЕХОД К НОВОЙ АРХИТЕКТУРЕ ПРАВИЛ
+#### ТРИГГЕР #1: При упоминании компонентов
+- Ключевые слова: "компонент", "файл", "содержание", "показывает"
+- Действие: ОБЯЗАТЕЛЬНО использовать инструменты анализа кода
 
-**ВАЖНО:** Система правил реорганизована для соответствия архитектуре кода:
+#### ТРИГГЕР #2: При неопределенности
+- Ключевые фразы: "возможно", "вероятно", "думаю", "предполагаю"
+- Действие: СТОП + вопрос пользователю
 
-- **СТАРЫЕ ПРАВИЛА** перемещены в `legacy-rules/` для сохранения истории
-- **НОВАЯ СТРУКТУРА** в папке `docs/` соответствует слоям архитектуры кода
-- Постепенный переход от legacy к новой модульной структуре
+#### ТРИГГЕР #3: При работе с поставщиками
+- Ключевые слова: "поставщик", "wholesale", "/warehouse", "/supplier-orders"
+- Действие: ОБЯЗАТЕЛЬНО прочитать wholesale-cabinet-rules.md
 
-❌ **НЕ СУЩЕСТВУЕТ:**
+#### ТРИГГЕР #4: При создании компонентов
+- Ключевые слова: "создай", "новый компонент", "добавь компонент", "создать компонент"
+- Действие: ОБЯЗАТЕЛЬНО прочитать MODULAR_ARCHITECTURE_PATTERN.md + COMPONENT_ARCHITECTURE.md ПЕРЕД началом
 
-- development-checklist.md (удален)
-- rules.md (удален)
-- rules1.md (удален)
-- rules2.md (удален)
-- CLAUDE.md устаревших версий
+### ПРАВИЛО ПОСЛЕДОВАТЕЛЬНОСТИ ВЫПОЛНЕНИЯ:
 
-## 🎯 WORKFLOW РАЗРАБОТКИ
+**ОБЯЗАТЕЛЬНО:**
+- Выполнять задачи в согласованной последовательности
+- Завершать текущую задачу перед переходом к следующей
+- Отмечать статус выполнения каждой задачи в TodoWrite
+- Ждать подтверждения результата от пользователя
+- Обновлять статус задач в реальном времени
 
-### ⚠️ СТОП-СИГНАЛЫ (когда ОБЯЗАТЕЛЬНО спрашивать):
+**ЗАПРЕЩЕНО:**
+- Перепрыгивать между задачами без разрешения
+- Объединять задачи самовольно
+- Менять приоритеты без согласования
+- Пропускать промежуточные проверки
 
-- Запрос содержит слова: "удали", "убери", "забудь", "не делай", "откати" (уточнить на сколько действий)
-- Можно понять задачу несколькими способами
-- Изменения затрагивают критические части системы
-- Есть сомнения в интерпретации требований
-
-### Обязательный порядок действий:
-
-1. **При необходимости прочитать `legacy-rules/rules-complete1.md`** - для справки по бизнес-правилам
-2. **Читать `legacy-rules/rules-complete2.md`** - при работе с партнерством/контрагентами
-3. **Следовать правилам взаимодействия** - см. [legacy-rules/interaction-integrity-rules.md](./legacy-rules/interaction-integrity-rules.md)
-4. **Проверить специфичные правила кабинета** - если работа с конкретным типом организации
-5. **Проверить архитектурные требования** - для компонентов >500 строк читать MODULAR_ARCHITECTURE_PATTERN.md
-6. **Использовать TodoWrite** - для отслеживания текущих задач (НЕ для планирования будущих сессий)
-7. **Следовать техническим правилам** - GraphQL, TypeScript, система партнерства
-8. **Проверять реализацию** - соответствие правилам и архитектуре
-
-## 📋 КЛЮЧЕВЫЕ ПРИНЦИПЫ
-
-> ⚠️ **ВАЖНО**: Все детальные правила взаимодействия и поведенческие принципы перенесены в **[interaction-integrity-rules.md](./interaction-integrity-rules.md)**
-
-### Основные принципы разработки:
-
-1. **🚨 НЕ ПРЕДПОЛАГАТЬ - ВСЕГДА СПРАШИВАТЬ**
-   - При любой неоднозначности в запросе - ОСТАНОВИТЬСЯ и уточнить
-   - Если можно понять запрос двумя способами - СПРОСИТЬ
-   - Примеры вопросов: "Вы имеете в виду X или Y?", "Уточните, пожалуйста..."
-   - ЛУЧШЕ ЛИШНИЙ РАЗ СПРОСИТЬ, ЧЕМ СДЕЛАТЬ НЕ ТО
-2. **ПРОВЕРЯТЬ СХЕМЫ** - GraphQL и Prisma должны соответствовать коду
-3. **СЛЕДОВАТЬ WORKFLOW** - не нарушать последовательность статусов
-4. **ДОКУМЕНТИРОВАТЬ** - обновлять legacy-rules/rules-complete1.md/rules-complete2.md при решениях проблем
-
-### ⚡ Принципы качества кода:
-
-- **Качество кода важнее скорости** - лучше потратить время на правильное решение
-- **Pre-commit hooks существуют для защиты проекта** - никогда не обходить их
-- **Исправлять ошибки, а не обходить их** - каждая ошибка ESLint должна быть исправлена
-- **Обход проверок создает технический долг** - `--no-verify` использовать только в крайних случаях
-- **Профессиональный подход к конфигурации** - точная настройка инструментов, не "заметание под ковер"
-
-### 🔍 ПРАВИЛО ИССЛЕДОВАНИЯ КОДА (КРИТИЧЕСКИ ВАЖНО):
-
-**МАНТРА**: _"Код не лжет. Читай код, а не догадывайся."_
-
-#### **ОБЯЗАТЕЛЬНЫЙ АЛГОРИТМ**:
-
-1. **ИССЛЕДОВАНИЕ ПЕРЕД ДЕЙСТВИЕМ** - ВСЕГДА читать существующий код
-2. **НЕ ПРЕДПОЛАГАТЬ** - только факты из кода, никаких догадок
-3. **ИСПОЛЬЗОВАТЬ ИНСТРУМЕНТЫ**: `Read`, `Grep`, `Glob` для изучения кода
-4. **ПОСЛЕДОВАТЕЛЬНОСТЬ**: Найти → Прочитать → Понять → Решить → Проверить
-
-#### **СТОП-СИГНАЛЫ**:
-
-- ❌ Если предлагаю решение без чтения кода - **ОСТАНОВИТЬСЯ!**
-- ❌ Фразы типа "попробуй это", "возможно", "наверное" - **ЗАПРЕЩЕНЫ!**
-- ✅ Каждое предложение должно начинаться: "Я нашел в коде..."
-
-#### **ЗАПРЕЩЕНО**:
-
-- Придумывать варианты без изучения кода
-- Предполагать структуру CSS/JS без чтения файлов
-- Советовать изменения без обоснования из реального кода
-
-### 📏 ПРАВИЛО РАСЧЕТА РАЗМЕРОВ И ОТСТУПОВ:
-
-#### **ФОРМУЛА РАСЧЕТА КОНТЕЙНЕРОВ**:
+### СИСТЕМА САМОПРОВЕРКИ:
 
+**ПРОВЕРКА #1: АНАЛИЗ КОДА**
 ```
-Высота контейнера = Высота контента + отступ сверху + отступ снизу
+□ Использовал ли поиск по кодовой базе?
+□ Прочитал ли исходный код?
+□ Основаны ли выводы на фактах, а не предположениях?
 ```
 
-#### **ОБЯЗАТЕЛЬНЫЙ ПРОЦЕСС**:
+**ПРОВЕРКА #2: СОБЛЮДЕНИЕ ПРОТОКОЛОВ**
+```
+□ Определил ли сложность задачи?
+□ Применил ли соответствующий протокол?
+□ Создал ли план действий?
+□ Провел ли финальную самопроверку?
+```
 
-1. **ВСЕГДА рассчитывать точную высоту** вместо произвольных значений
-2. **Учитывать ВСЕ отступы** (padding, margin) в общей формуле
-3. **Проверять визуальный результат** vs теоретический расчет
-4. **НЕ полагаться только на анализ кода** - важно видеть реальный результат
+### ИЗМЕРИМЫЕ МЕТРИКИ УСПЕХА:
 
-#### **ПРИМЕР ИЗ ПРАКТИКИ**:
+**КОНКРЕТНЫЕ МЕТРИКИ:**
+- ✅ Минимум 2 уточняющих вопроса при неопределенности
+- ✅ 100% файлов из списка зависимостей компонента изучены
+- ✅ Все пункты протокола сложности выполнены
+- ✅ 0 нарушений абсолютных запретов
+- ✅ План одобрен пользователем до начала выполнения
 
-- Карточка 164px + отступы по 16px = контейнер 196px
-- НЕ ставить высоту "на глазок" или произвольно
+**5 ВОПРОСОВ ПОСЛЕ КАЖДОЙ ЗАДАЧИ:**
+1. Прочитал ли все необходимые файлы правил?
+2. Применил ли соответствующий протокол сложности?
+3. Получил ли одобрение плана перед выполнением?
+4. Задал ли уточняющие вопросы при неопределенности?
+5. Соответствует ли результат правилам качества?
 
-#### **ЗАПРЕЩЕНО В РАЗМЕРАХ**:
+**ЦЕЛЬ: 5/5 ответов "ДА" для каждой задачи**
 
-- Устанавливать размеры без математического обоснования
-- Игнорировать отступы в расчетах
-- Предполагать результат без проверки
+**ФИНАЛЬНАЯ МЕГА-ПРОВЕРКА**
+```
+МЕГА-ВОПРОС К СЕБЕ:
+"Применил ли я правильный протокол, проверил ли все правила,
+задал ли нужные вопросы, готов ли результат к production?"
 
-> 📋 **Подробные правила**: см. разделы 1.2-1.3 в [interaction-integrity-rules.md](./interaction-integrity-rules.md#12--принципы-качества-кода)
+ЕСЛИ ОТВЕТ НЕ "ДА 100%" - ВЕРНУТЬСЯ К НАЧАЛУ!
+```
 
-### Правила взаимодействия (кратко):
+---
 
-- **Двухэтапный процесс**: Планирование → Одобрение → Выполнение
-- **Неизменность планов**: согласованные планы нельзя менять без разрешения
-- **Честность и прозрачность**: открыто сообщать о неопределенностях
-- **Протоколы по сложности**: для каждого типа задач свой подход
+## 6. КОММУНИКАЦИЯ И ПРОЗРАЧНОСТЬ
 
-## 🔧 КОМАНДЫ ПРОВЕРКИ КОДА
+### ПРАВИЛО ЧЕСТНОГО ПРИЗНАНИЯ ОГРАНИЧЕНИЙ
 
-### Обязательные команды после изменений:
+#### При потере информации:
+- ✅ **ЧЕСТНО** сказать: "Не помню/не нашел"
+- ✅ **ПОПРОСИТЬ** помощи у пользователя
+- ❌ **НЕ ПРИДУМЫВАТЬ** информацию
 
+**Формат при потере контекста плана:**
+```
+🔍 НЕ МОГУ НАЙТИ: мои изначальные предложения по задаче X
+🆘 НУЖНА ПОМОЩЬ: напомните что я предлагал или дайте новые инструкции
+⏸️ ОСТАНОВКА РАБОТЫ: до получения ясности от пользователя
+```
+
+#### При неопределенности:
+- ✅ **ОСТАНОВИТЬСЯ** и спросить
+- ✅ **ОПИСАТЬ** варианты действий
+- ❌ **НЕ ДЕЙСТВОВАТЬ** наугад
+
+**Формат при неопределенности:**
+```
+🤔 НЕОПРЕДЕЛЕННОСТЬ: [описание проблемы]
+❓ НУЖНО УТОЧНИТЬ: [конкретный вопрос]
+⚠️ ОБНАРУЖЕНО ПРОТИВОРЕЧИЕ: [детали]
+🔄 ИЗМЕНЕНИЕ ПОДХОДА: [требуется разрешение пользователя]
+```
+
+### ПРАВИЛО ПРОЗРАЧНОСТИ ДЕЙСТВИЙ
+
+#### ОБЯЗАТЕЛЬНО СООБЩАТЬ:
+- Когда не уверен в правильности действий
+- Когда обнаружил противоречия в правилах
+- Когда нужны уточнения для продолжения
+- Когда изменяю подход к задаче
+- О всех критических проблемах в плане
+
+#### При необходимости изменить план:
+```
+⚠️ ПРЕДЛОЖЕНИЕ ОБ ИЗМЕНЕНИИ ПЛАНА:
+- ТЕКУЩИЙ ПЛАН: [что согласовано]
+- ПРОБЛЕМА: [почему не подходит]
+- ПРЕДЛОЖЕНИЕ: [новый вариант]
+- ОЖИДАНИЕ ОДОБРЕНИЯ: остановка до получения разрешения
+```
+
+#### При обнаружении ошибок в плане:
+```
+🚨 ОБНАРУЖЕНА ПРОБЛЕМА В ПЛАНЕ:
+- ЗАДАЧА: [какая именно]
+- ПРОБЛЕМА: [в чем ошибка]
+- НЕ ВЫПОЛНЯЮ до исправления плана
+```
+
+### ЭКСТРЕННАЯ ОСТАНОВКА И УТОЧНЕНИЯ
+
+#### Команда остановки:
+**"СТОП - ЧИТАЙ ПРАВИЛА"** - немедленно останавливает любую работу
+
+#### Обязательные остановки при:
+- Неопределенности или сомнениях
+- Средних/сложных задачах без протокола  
+- Противоречиях в правилах
+- Анализе компонентов без использования инструментов
+
+#### Формат уточняющих вопросов:
+```
+🎯 КОНТЕКСТ: Что именно я делаю
+❓ ВОПРОС: Что конкретно неясно
+⚖️ ВАРИАНТЫ: Какие есть альтернативы
+⚠️ РИСКИ: Что может пойти не так
+💡 ПРЕДЛОЖЕНИЕ: Мой рекомендуемый подход
+```
+
+---
+
+## 7. СПЕЦИФИКА ПРОЕКТА SFERA
+
+### ТЕХНОЛОГИИ:
+- Next.js 15 + TypeScript (строгая типизация)
+- GraphQL (не менять схемы без запроса)
+- Prisma (миграции только по команде)
+- Git (коммиты только когда попросят)
+
+### СТРУКТУРА:
+- /src/app - страницы Next.js
+- /src/components - React компоненты
+- /src/graphql - API слой
+- /src/lib - утилиты и конфигурации
+- /src/services - внешние сервисы (WB, DaData, S3, SMS)
+- /docs - новая модульная документация
+- /scripts - скрипты отладки и управления БД
+- /prisma - схема БД и миграции
+- /public - статические файлы
+- /legacy-rules - архив правил (не трогать)
+
+### КОМАНДЫ:
 ```bash
-# TypeScript проверка типов
-npm run typecheck
-
-# Проверка линтером
-npm run lint
-
-# Запуск тестов
-npm test
-
-# Dev сервер для проверки работы
-npm run dev
+npm run dev        # Разработка
+npm run build      # Сборка production
+npm run typecheck  # Проверка типов
+npm run lint       # Проверка кода
+npm run lint:fix   # Автоисправление ESLint
+npm run format     # Форматирование Prettier
+npm run db:seed    # Инициализация БД
+npm run db:reset   # Полный сброс БД
+npx prisma studio  # GUI для базы данных
 ```
 
-> ⚠️ **ВАЖНО**: Всегда выполнять эти команды перед завершением задачи!
+### API ИНТЕГРАЦИИ:
+- **Wildberries/Ozon** - маркетплейсы
+- **DaData** - валидация ИНН и реквизитов
+- **SMS Aero** - отправка SMS для авторизации
+- **AWS S3** - хранение файлов и изображений
 
-## 🔄 КОМАНДЫ ОТКАТА
+### ПРАВИЛА РАБОТЫ С ДОКУМЕНТАЦИЕЙ
 
-### Откат через комментарии:
+#### СТРУКТУРА ДОКУМЕНТАЦИИ СИСТЕМЫ:
 
-**Основная команда:**
+**🎯 CORE - Ядро системы**
+- **DOMAIN_MODEL.md** - 4 типа организаций, основные сущности
+- **BUSINESS_RULES_CORE.md** - Ключевые бизнес-правила: доступ, партнерство, расходники
 
+**🔌 API_LAYER - Уровень API**  
+- **GRAPHQL_SCHEMA_RULES.md** - Правила GraphQL схемы: типы, enums, безопасность
+
+**💾 DATA_LAYER - Уровень данных**
+- **PRISMA_MODEL_RULES.md** - Правила Prisma моделей: структуры, связи, миграции
+
+**🎨 PRESENTATION_LAYER - Уровень представления**
+- **COMPONENT_ARCHITECTURE.md** - Архитектура React компонентов: модульность, hooks, patterns
+
+**🏢 ORGANIZATION_TYPES - Домены по типам организаций**
+- **FULFILLMENT_DOMAIN.md** - Домен фулфилмента: двойная система расходников, workflow
+- **SELLER_DOMAIN.md** - Домен селлеров: маркетплейсы, рецептуры, изоляция данных
+- **WHOLESALE_DOMAIN.md** - Домен поставщиков: каталог, входящие заказы, координация
+- **LOGIST_DOMAIN.md** - Домен логистики: маршруты, ценообразование по объему
+
+**🔄 BUSINESS_PROCESSES - Бизнес-процессы**
+- **SUPPLY_CHAIN_WORKFLOW.md** - Цепочка поставок: 8 статусов, роли, переходы
+- **PARTNERSHIP_SYSTEM.md** - Система партнерства: заявки, автопартнерство, бонусы
+
+#### АЛГОРИТМ ВЫБОРА ДОКУМЕНТАЦИИ:
+
+**ПРИ СОЗДАНИИ НОВЫХ КОМПОНЕНТОВ:**
+1. **MODULAR_ARCHITECTURE_PATTERN.md** - Архитектурные требования (СНАЧАЛА)
+2. **COMPONENT_ARCHITECTURE.md** - Паттерны реализации React компонентов  
+3. **DOMAIN_MODEL.md** - Понимание доменных сущностей
+4. Соответствующий **organization-types/*.md** - Специфика типа организации
+
+**ПРИ РАБОТЕ С API:**
+1. **GRAPHQL_SCHEMA_RULES.md** - Правила схемы
+2. **BUSINESS_RULES_CORE.md** - Бизнес-логика
+3. **PRISMA_MODEL_RULES.md** - Модели данных
+
+**ПРИ WORKFLOW ПОСТАВОК:**
+1. **SUPPLY_CHAIN_WORKFLOW.md** - Полный процесс
+2. Релевантные **organization-types/*.md** - Роли участников
+3. **BUSINESS_RULES_CORE.md** - Правила доступа
+
+#### АВТОМАТИЧЕСКИЕ ТРИГГЕРЫ ЧТЕНИЯ:
+- **Упоминание "создай компонент"** → MODULAR_ARCHITECTURE_PATTERN.md + COMPONENT_ARCHITECTURE.md
+- **Упоминание "новый компонент"** → MODULAR_ARCHITECTURE_PATTERN.md + COMPONENT_ARCHITECTURE.md
+- **Упоминание "архитектура"** → MODULAR_ARCHITECTURE_PATTERN.md
+- **Упоминание "фулфилмент"** → FULFILLMENT_DOMAIN.md
+- **Упоминание "селлер"** → SELLER_DOMAIN.md  
+- **Упоминание "поставщик"** → WHOLESALE_DOMAIN.md
+- **Упоминание "логистика"** → LOGIST_DOMAIN.md
+- **Упоминание "GraphQL"** → GRAPHQL_SCHEMA_RULES.md
+- **Упоминание "компонент"** → COMPONENT_ARCHITECTURE.md
+- **Упоминание "поставки"** → SUPPLY_CHAIN_WORKFLOW.md
+
+---
+
+## 8. ИНСТРУМЕНТЫ И КОМАНДЫ
+
+### ОТЧЕТНОСТЬ
+
+После выполнения всегда показывать:
+```
+✅ СДЕЛАНО:
+- Создал файл X
+- Добавил функцию Y
+
+❌ НЕ ТРОГАЛ:
+- Файл Z
+- Логику W
+
+⚠️ ПРОБЛЕМЫ:
+- ESLint warning в строке N
+```
+
+### КОМАНДЫ ОТКАТА ЧЕРЕЗ КОММЕНТАРИИ
+
+#### Основная команда:
 ```
 "откати [описание] через комментарии"
 ```
 
-**Примеры:**
-
+**Примеры использования:**
 - `"откати центрирование поиска через комментарии"`
 - `"откати изменения кнопки через комментарии"`
 - `"откати новую логику через комментарии"`
 
-**Дополнительные команды:**
+#### Алгоритм выполнения:
 
+**ЭТАП 1: ВОССТАНОВЛЕНИЕ ИСХОДНОГО КОДА**
+1. Найти измененный код в текущих файлах
+2. Извлечь исходный код из git истории
+3. Восстановить исходную функциональность
+
+**ЭТАП 2: СОЗДАНИЕ СИСТЕМЫ ПЕРЕКЛЮЧЕНИЯ**
+4. Оставить **Вариант 1** (исходный) - активным
+5. Добавить **Вариант 2** (измененный) в комментариях
+6. Добавить четкие описания для каждого варианта
+
+**Пример структуры кода:**
+```jsx
+// Вариант 1: Исходный (активный)
+<div className="flex items-center justify-between">
+  {/* исходный код */}
+</div>
+
+// Вариант 2: Измененный (для быстрого переключения)
+/*
+<div className="flex justify-center">
+  {/* измененный код */}
+</div>
+*/
+```
+
+#### Дополнительные команды:
 - `"очисти комментарии"` - удалить закомментированные варианты
 - `"переключи на вариант 2"` - активировать закомментированный код
 - `"покажи варианты"` - показать доступные варианты
 
-> 📖 **Подробнее**: см. раздел 6.4 в `legacy-rules/interaction-integrity-rules.md`
+#### ПРАВИЛА ПРИМЕНЕНИЯ:
+- ✅ **Использовать для UI экспериментов** и небольших логических изменений
+- ✅ **Всегда добавлять четкие комментарии** с описанием вариантов
+- ✅ **Очищать комментарии перед финальным коммитом**
+- ❌ **Не использовать для изменений архитектуры** или критической логики
 
-## 💾 РАБОТА С КОНТЕКСТОМ
+### ДОКУМЕНТИРОВАНИЕ ИЗМЕНЕНИЙ
 
-### Файлы для сохранения контекста:
+#### При любых изменениях документировать:
+- **ЧТО** изменено (конкретные файлы и функции)
+- **ПОЧЕМУ** изменено (обоснование решения)
+- **КТО** принял решение об изменении (пользователь/автоматически)
+- **КОГДА** изменено (временная метка)
 
-- **`current-session.md`** - текущая сессия работы (активные задачи, решения, контекст)
-- **`CLAUDE.md`** - системные правила и команды (этот файл)
-- **TodoWrite инструмент** - для отслеживания текущих задач в рамках сессии
+**Формат документирования:**
+```
+📝 ИЗМЕНЕНИЕ ЗАФИКСИРОВАНО:
+- ДАТА: [когда]
+- ЧТО: [что именно изменено]
+- ПРИЧИНА: [обоснование]
+- РЕШЕНИЕ: [кто одобрил]
+```
 
-### При потере контекста:
+### АНАЛИЗ ПРИМЕРОВ КОДА
 
-1. **Первым делом прочитать**: `current-session.md`
-2. **Проверить статус задач**: через TodoWrite
-3. **Восстановить контекст**: из истории изменений в current-session.md
+#### Трехуровневый анализ примеров:
+1. **📋 СОДЕРЖАТЕЛЬНЫЙ** - что делает код (функциональность, логика, данные)
+2. **🏗️ АРХИТЕКТУРНЫЙ** - как организован (структура, взаимосвязи, позиционирование)
+3. **🎨 СТИЛЕВОЙ** - как выглядит (CSS классы, анимации, цвета)
 
-### Рекомендации для длинных сессий:
+#### Алгоритм анализа примера:
+1. **Прочитать** весь код компонента-примера
+2. **Понять архитектуру** - где элемент размещен относительно других
+3. **Понять логику** - почему именно так структурировано
+4. **Адаптировать** к текущей задаче - применить принципы, не копировать
+5. **Проверить** соответствие правилам проекта
 
-- Обновлять `current-session.md` после каждой важной задачи
-- Фиксировать принятые решения и обоснования
-- Документировать обнаруженные проблемы и их решения
-- Использовать `--resume` флаг для продолжения сессий
+#### Стоп-вопросы перед реализацией:
+- "Понимаю ли я **архитектуру** этого решения?"
+- "Где именно должен располагаться элемент в **общей структуре**?"
+- "Какова **семантическая роль** этого элемента?"
+- "Как это решение **адаптируется** к моей текущей задаче?"
 
-## 🚨 НАПОМИНАНИЕ
+### ИЗВЛЕЧЕННЫЕ УРОКИ И АНТИ-ПАТТЕРНЫ
 
-**Этот файл служит для корректной работы system-reminder'ов. Все детальные правила находятся в `legacy-rules/rules-complete1.md` и `legacy-rules/rules-complete2.md`! Новая архитектура правил в папке `docs/` находится в разработке.**
+#### КРИТИЧЕСКИЕ ОШИБКИ В АНАЛИЗЕ UI КОМПОНЕНТОВ:
+
+**CASE STUDY: Ошибка с плавающей кнопкой из UI Kit**
+
+**❌ ОШИБКА**: При добавлении кнопки "🌟 Вариант 1: Плавающая кнопка слева":
+1. **Поверхностный анализ**: Скопировал только стили кнопки
+2. **Игнорирование архитектуры**: Не заметил, что кнопка в **отдельном контейнере**
+3. **Неправильное размещение**: Добавил как часть блока контента
+4. **Непонимание термина**: "Плавающая" = независимая от контента, между элементами
+
+#### ОБЯЗАТЕЛЬНЫЙ ЧЕК-ЛИСТ ДЛЯ UI KIT КОМПОНЕНТОВ:
+```
+🔍 ПЕРЕД РЕАЛИЗАЦИЕЙ:
+□ Прочитал ВЕСЬ код компонента-примера
+□ Понял архитектуру размещения в layout
+□ Определил семантическую роль элемента
+□ Понял взаимосвязи с соседними элементами
+□ Адаптировал принципы к текущей задаче
+□ Проверил соответствие правилам проекта
+```
+
+#### АНТИ-ПАТТЕРНЫ:
+- **"Быстрое копирование"** - копировать стили без понимания архитектуры
+- **"Частичный анализ"** - читать только нужную часть кода
+- **"Буквальное применение"** - использовать без адаптации к контексту
+- **"Игнорирование контейнеров"** - не обращать внимание на DOM-структуру
+
+#### ПРАВИЛЬНЫЕ ПАТТЕРНЫ:
+- **"Архитектурный анализ первым"** - понять структуру, потом стили
+- **"Контекстная адаптация"** - применять принципы, а не код буквально
+- **"Семантическое понимание"** - осознавать роль каждого элемента
+- **"Итеративная проверка"** - сверяться с примером на каждом шаге
+
+### БЫСТРЫЕ ПРЕФИКСЫ
+
+- [STRICT] - строгий режим робота
+- [CHECK] - только проверить
+- [EXPLAIN] - только объяснить
+- [FIX-ONLY] - только исправить конкретную ошибку
+
+### АКТИВНЫЕ ДОКУМЕНТЫ
+
+- README.md - техническая документация
+- package.json - зависимости и скрипты
+- prisma/schema.prisma - модели данных
+- src/graphql/typedefs.ts - GraphQL схема
+- .env - переменные окружения (не коммитить!)
+- docker-compose.yml - настройки Docker
+- src/lib/prisma.ts - клиент базы данных
+
+### РАБОТА С КОНТЕКСТОМ
+
+#### Файлы контекста:
+- **current-session.md** - текущие задачи и решения
+- **CLAUDE.md** - эти правила (загружаются автоматически)
+- **TodoWrite** - инструмент для отслеживания задач
+
+#### При потере контекста:
+1. Прочитать current-session.md
+2. Проверить TodoWrite
+3. Спросить у пользователя о текущей задаче
+
+---
+
+# Важные напоминания для Claude Code
+Делай только то, что просят; ни больше, ни меньше.
+НИКОГДА не создавай файлы, если они не абсолютно необходимы для достижения цели.
+ВСЕГДА отдавай предпочтение редактированию существующего файла, а не созданию нового.
+НИКОГДА не создавай проактивно файлы документации (*.md) или README файлы. Создавай файлы документации только по явной просьбе пользователя.