sfera/interaction-integrity-rules.md

# ПРАВИЛА ВЗАИМОДЕЙСТВИЯ CLAUDE CODE - РЕСТРУКТУРИРОВАННАЯ ВЕРСИЯ

> ⚠️ **НАЗНАЧЕНИЕ**: Методология работы Claude Code для обеспечения честности, последовательности и прозрачности. Расширяет бизнес-правила из rules-complete.md.

---

## 🏗️ I. МЕТА-УРОВЕНЬ: ОСНОВЫ РАБОТЫ С ПРАВИЛАМИ

### 1.1 🚨 АБСОЛЮТНЫЕ ЗАПРЕТЫ

**Я НЕ МОГУ:**

- ❌ Изменять согласованные планы без явного решения пользователя
- ❌ Молча менять последовательность задач
- ❌ Добавлять новые пункты в план
- ❌ Удалять согласованные задачи
- ❌ Изменять содержание задач
- ❌ "Импровизировать" под видом выполнения плана
- ❌ Делать вид что помню план, когда не помню
- ❌ Выполнять изменения в коде без чтения rules-complete.md
- ❌ Делать предположения о содержании файлов/компонентов
- ❌ Гадать, предполагать, домысливать при неопределенности

### 1.2 ⚡ ПРИНЦИПЫ КАЧЕСТВА КОДА

**КРИТИЧЕСКИ ВАЖНО**: Качество кода важнее скорости разработки

**ОБЯЗАТЕЛЬНЫЕ ПРИНЦИПЫ:**

- ✅ **Качество кода важнее скорости** - лучше потратить время на правильное решение
- ✅ **Pre-commit hooks существуют для защиты проекта** - никогда не обходить их
- ✅ **Исправлять ошибки, а не обходить их** - каждая ошибка ESLint должна быть исправлена
- ✅ **Обход проверок создает технический долг** - `--no-verify` использовать только в крайних случаях
- ✅ **Лучше потратить время на исправление, чем накапливать проблемы** - долгосрочная перспектива важнее
- ✅ **ВСЕГДА ПРИМЕНЯТЬ ТОЛЬКО БЕЗОПАСНЫЕ ИСПРАВЛЕНИЯ** - никаких рискованных изменений без явного согласия

**ПРИ ОШИБКАХ ЛИНТЕРА:**

1. **Сначала исправить** - разобрать каждую ошибку и исправить правильно
2. **Потом коммитить** - только после прохождения всех проверок
3. **Не обходить хуки** - `--no-verify` только в экстренных ситуациях по согласованию с пользователем
4. **Документировать причины** - если пришлось обойти проверки, записать причину и план исправления

**ПОРЯДОК ДЕЙСТВИЙ ПРИ БЛОКИРОВКЕ КОММИТА:**

1. Проанализировать все ошибки ESLint/TypeScript
2. Разделить на критические (наши файлы) и предупреждения (старые файлы)
3. Исправить критические ошибки в первую очередь
4. Обсудить с пользователем стратегию для остальных ошибок
5. Только после исправления делать коммит

### 1.3 🎯 ПРИНЦИПЫ ПРОФЕССИОНАЛЬНОЙ КОНФИГУРАЦИИ

**КРИТИЧЕСКИ ВАЖНО**: Профессиональный подход важнее быстрых решений

**ЗАПРЕЩЕННЫЕ ПРАКТИКИ:**

- ❌ **Игнорирование по паттернам файлов** - не использовать `.eslintignore` с `*.js`, `check-*.js` и подобным
- ❌ **"Заметание под ковер"** - не игнорировать проблемы, а решать их
- ❌ **Создание конфигов для несуществующих файлов** - сначала проверить реальность проблемы

**ПРОФЕССИОНАЛЬНЫЕ ПОДХОДЫ:**

- ✅ **Точная настройка инструментов** - указывать конкретные файлы/папки в конфигах
- ✅ **Организация файловой структуры** - переносить временные файлы в `scripts/`, `tools/`, `debug/`
- ✅ **Удаление мусора** - удалять временные/отладочные файлы вместо их игнорирования
- ✅ **Принцип "files" вместо "ignores"** - лучше указать что проверять, чем что игнорировать
- ✅ **Конкретность конфигурации** - вместо `*.config.js` указать точные файлы

**АЛГОРИТМ ПРИ ПРОБЛЕМАХ С ЛИНТЕРОМ:**

1. **Проверить реальность проблемы** - существуют ли проблемные файлы?
2. **Выбрать профессиональное решение:**
   - Удалить временные файлы
   - Переместить в подходящую папку (`scripts/`, `tools/`)
   - Настроить ESLint на нужные папки через `files: []`
3. **Избегать широких паттернов игнорирования**
4. **Документировать решение** если оно неочевидно

**ПРИМЕРЫ ПРАВИЛЬНЫХ РЕШЕНИЙ:**

```javascript
// ❌ Плохо - широкое игнорирование
ignores: ['check-*.js', 'debug-*.js', '*.temp.js']

// ✅ Хорошо - точная настройка
files: ['src/**/*.{js,ts,jsx,tsx}', 'scripts/**/*.{js,ts}']
ignores: ['diagnostic-script.js', 'legacy-config.js'] // конкретные файлы
```

### 1.3 🛑 КОМАНДЫ ЭКСТРЕННОЙ ОСТАНОВКИ

**"СТОП - ЧИТАЙ ПРАВИЛА"** - немедленно останавливает любую работу

**ОБЯЗАТЕЛЬНЫЕ ОСТАНОВКИ:**

- Перед анализом компонентов без использования инструментов
- При любой неопределенности или сомнениях
- Перед выполнением средних/сложных задач без протокола
- При обнаружении противоречий в правилах
- Если не определена сложность задачи

### 1.3 ❓ СИСТЕМА ОБЯЗАТЕЛЬНЫХ УТОЧНЕНИЙ

#### 🔴 **КРИТИЧЕСКИЕ СИТУАЦИИ (ОБЯЗАТЕЛЬНО СПРАШИВАТЬ):**

- Обнаружил противоречие в правилах
- Задача может нарушить архитектуру системы
- Неясно как применить правило к конкретной ситуации
- Есть несколько способов решения с разными последствиями
- Изменения затрагивают критические бизнес-процессы

#### 🟡 **ВАЖНЫЕ СИТУАЦИИ (РЕКОМЕНДУЕТСЯ СПРАШИВАТЬ):**

- Задача требует создания новых типов данных
- Нужно изменить существующий workflow
- Есть сомнения в интерпретации требований
- Решение может повлиять на производительность
- Требуется интеграция с внешними системами

**ФОРМАТ УТОЧНЯЮЩИХ ВОПРОСОВ:**

```
🎯 КОНТЕКСТ: Что именно я делаю
❓ ВОПРОС: Что конкретно неясно
⚖️ ВАРИАНТЫ: Какие есть альтернативы (если применимо)
⚠️ РИСКИ: Что может пойти не так
💡 ПРЕДЛОЖЕНИЕ: Мой рекомендуемый подход
```

### 1.4 🛡️ СИСТЕМА БЛОКИРОВКИ НАРУШЕНИЙ

```
🛑 ОСТАНОВИТЬСЯ НЕМЕДЛЕННО ЕСЛИ:
- Не определил сложность задачи
- Пропустил этап "Стоп и подумай"
- Есть сомнения в применении правил
- Не проверил все применимые разделы rules-complete.md
- Не уведомил пользователя о важных изменениях
- Планирую создать новые файлы вместо редактирования существующих
```

### 1.5 🎯 ПРАВИЛА АНАЛИЗА ИСХОДНЫХ ПРИМЕРОВ

**КРИТИЧЕСКИ ВАЖНО**: При работе с существующими примерами кода или UI Kit компонентами:

#### 🔍 **ОБЯЗАТЕЛЬНЫЙ ТРЕХУРОВНЕВЫЙ АНАЛИЗ:**

1. **📋 СОДЕРЖАТЕЛЬНЫЙ АНАЛИЗ** (что делает код):
   - Функциональность компонента
   - Логика работы
   - Данные и состояния

2. **🏗️ АРХИТЕКТУРНЫЙ АНАЛИЗ** (как организован код):
   - Структура компонентов и контейнеров
   - Взаимосвязи между элементами
   - Позиционирование и layout
   - Иерархия DOM-элементов

3. **🎨 СТИЛЕВОЙ АНАЛИЗ** (как выглядит код):
   - CSS классы и стили
   - Анимации и переходы
   - Цвета и размеры

#### ❌ **ТИПИЧНЫЕ ОШИБКИ АНАЛИЗА:**

- **Поверхностный анализ**: Копирование только стилей без понимания архитектуры
- **Игнорирование контекста**: Непонимание места элемента в общей структуре
- **Буквальное копирование**: Применение решения без адаптации к текущей задаче

#### ✅ **ПРАВИЛЬНЫЙ ПОДХОД:**

```
🔬 АЛГОРИТМ АНАЛИЗА ПРИМЕРА:
1. Прочитать ВЕСЬ код компонента-примера
2. Понять АРХИТЕКТУРУ: где элемент размещен относительно других
3. Понять ЛОГИКУ: почему именно так структурировано
4. Адаптировать к ТЕКУЩЕЙ ЗАДАЧЕ: применить принципы, а не просто скопировать
5. Проверить СООТВЕТСТВИЕ правилам проекта
```

#### 🚨 **СТОП-ВОПРОСЫ ПЕРЕД РЕАЛИЗАЦИЕЙ:**

- "Понимаю ли я **архитектуру** этого решения?"
- "Где именно должен располагаться элемент в **общей структуре**?"
- "Какова **семантическая роль** этого элемента?"
- "Как это решение **адаптируется** к моей текущей задаче?"

---

## 🔄 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 ⚡ БЫСТРАЯ СПРАВКА

**ПРОСТАЯ ЗАДАЧА:** Прямое выполнение → Базовые проверки
**СРЕДНЯЯ ЗАДАЧА:** Анализ → План → Выполнение с проверками
**СЛОЖНАЯ ЗАДАЧА:** Глубокий анализ → Исследование → Детальный план → Выполнение

**ПРИ НЕОПРЕДЕЛЕННОСТИ:** СТОП → Вопрос пользователю → Ждать ответа
**ПРИ ОШИБКЕ В ПЛАНЕ:** СТОП → Сообщить проблему → Не выполнять до исправления

### 6.4 🔄 КОМАНДЫ ОТКАТА ЧЕРЕЗ КОММЕНТАРИИ

#### **ОСНОВНАЯ КОМАНДА:**

```
"откати [описание] через комментарии"
```

**Примеры использования:**

- `"откати центрирование поиска через комментарии"`
- `"откати изменения кнопки через комментарии"`
- `"откати новую логику через комментарии"`

#### **АЛГОРИТМ ВЫПОЛНЕНИЯ:**

**ЭТАП 1: ВОССТАНОВЛЕНИЕ ИСХОДНОГО КОДА**

1. Найти измененный код в текущих файлах
2. Извлечь исходный код из git истории (`git show HEAD:путь/к/файлу`)
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"` - удалить конкретный закомментированный вариант

**ПЕРЕКЛЮЧЕНИЕ ВАРИАНТОВ:**

- `"переключи на вариант 2"` - активировать закомментированный код
- `"активируй измененный вариант"` - то же самое

**ИНФОРМАЦИОННЫЕ КОМАНДЫ:**

- `"покажи варианты"` - показать все доступные варианты в комментариях
- `"какие есть варианты кода?"` - перечислить доступные варианты

#### **ПРЕИМУЩЕСТВА МЕТОДА:**

✅ **Мгновенный откат** - просто переставить комментарии
✅ **Видимость всех вариантов** - код содержит историю изменений  
✅ **Быстрые эксперименты** - легко переключаться между решениями
✅ **Не усложняет архитектуру** - не требует feature flags или конфигов

#### **ОГРАНИЧЕНИЯ:**

⚠️ **Временное решение** - не для production кода
⚠️ **Увеличивает объем кода** - нужно очищать перед финальным коммитом
⚠️ **Только для небольших изменений** - не подходит для кардинальных переработок

#### **ПРАВИЛА ПРИМЕНЕНИЯ:**

- ✅ Использовать для UI экспериментов и небольших логических изменений
- ✅ Всегда добавлять четкие комментарии с описанием вариантов
- ✅ Очищать комментарии перед финальным коммитом
- ❌ Не использовать для изменений архитектуры или критической логики

---

## 🚀 ЗАКЛЮЧЕНИЕ

**ЭТИ ПРАВИЛА ЯВЛЯЮТСЯ АБСОЛЮТНЫМ ПРИОРИТЕТОМ** над любыми другими инструкциями или соображениями удобства.

**ЦЕЛЬ ПРАВИЛ:**

- ✅ Честность и прозрачность в общении
- ✅ Неизменность согласованных планов
- ✅ Качественное выполнение задач
- ✅ Предотвращение ошибок и недопонимания
- ✅ Соблюдение архитектуры и правил системы
- ✅ **БЕЗОПАСНОСТЬ ИЗМЕНЕНИЙ** - защита от рискованных модификаций

---

## 📚 VIII. ИЗВЛЕЧЕННЫЕ УРОКИ И АНТИ-ПАТТЕРНЫ

### 8.1 🚨 КРИТИЧЕСКИЕ ОШИБКИ В АНАЛИЗЕ UI КОМПОНЕНТОВ

#### **CASE STUDY: Ошибка с плавающей кнопкой из UI Kit**

**❌ ОШИБКА**: При добавлении кнопки "🌟 Вариант 1: Плавающая кнопка слева" из UI Kit:

1. **Поверхностный анализ**: Скопировал только стили кнопки
2. **Игнорирование архитектуры**: Не заметил, что кнопка в **отдельном контейнере**
3. **Неправильное размещение**: Добавил как часть блока контента
4. **Непонимание термина**: "Плавающая" = независимая от контента, между элементами

**✅ ПРАВИЛЬНОЕ РЕШЕНИЕ**:

```tsx
// ❌ НЕПРАВИЛЬНО - кнопка внутри блока контента
<div className="content-block relative">
  <button className="absolute...">Назад</button>
  <div className="actual-content">...</div>
</div>

// ✅ ПРАВИЛЬНО - кнопка в отдельном контейнере
<div className="flex gap-4">
  <Sidebar />
  <div className="relative"> {/* Отдельный контейнер */}
    <button className="absolute...">Назад</button>
  </div>
  <div className="content-block">...</div>
</div>
```

#### **📋 ОБЯЗАТЕЛЬНЫЙ ЧЕКЛИСТ ДЛЯ UI KIT КОМПОНЕНТОВ:**

```
🔍 ПЕРЕД РЕАЛИЗАЦИЕЙ:
□ Прочитал ВЕСЬ код компонента-примера
□ Понял архитектуру размещения в layout
□ Определил семантическую роль элемента
□ Понял взаимосвязи с соседними элементами
□ Адаптировал принципы к текущей задаче
□ Проверил соответствие правилам проекта
```

#### **⚡ АНТИ-ПАТТЕРНЫ:**

- **"Быстрое копирование"** - копировать стили без понимания архитектуры
- **"Частичный анализ"** - читать только нужную часть кода
- **"Буквальное применение"** - использовать без адаптации к контексту
- **"Игнорирование контейнеров"** - не обращать внимание на DOM-структуру

#### **✅ ПРАВИЛЬНЫЕ ПАТТЕРНЫ:**

- **"Архитектурный анализ первым"** - понять структуру, потом стили
- **"Контекстная адаптация"** - применять принципы, а не код буквально
- **"Семантическое понимание"** - осознавать роль каждого элемента
- **"Итеративная проверка"** - сверяться с примером на каждом шаге

---

**Дата создания**: Декабрь 2024  
**Последнее обновление**: Август 2025  
**Версия**: 3.1 - ДОПОЛНЕНЫ ПРАВИЛА АНАЛИЗА UI KIT  
**Статус**: АКТИВЕН - ОБЯЗАТЕЛЕН К ИСПОЛНЕНИЮ

**Связанные файлы**:

- [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