Реструктуризация системы правил: создание модульной документации

- Разделение rules-complete.md на специализированные файлы - Создание interaction-integrity-rules.md с методологией работы Claude Code - Создание wholesale-cabinet-rules.md с техническими деталями кабинета поставщика - Обновление CLAUDE.md с новой структурой навигации по правилам - Добавление автоматических триггеров для различных типов задач 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
2025-08-08 16:06:32 +03:00
parent 3acaf8bd99
commit 2b7f92772c
4 changed files with 891 additions and 304 deletions
--- 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 МАРКЕТ

 **🔍 КРИТИЧЕСКОЕ РАЗДЕЛЕНИЕ ПОНЯТИЙ:**