Добавлены принципы качества кода в правила системы

🛡️ Новые принципы:
- Качество кода важнее скорости разработки
- Pre-commit hooks существуют для защиты проекта
- Исправлять ошибки, а не обходить их
- Обход проверок создает технический долг
- Лучше потратить время на исправление, чем накапливать проблемы

📋 Добавлены подробные инструкции:
- Порядок действий при блокировке коммита
- Когда можно использовать --no-verify
- Как правильно работать с ошибками линтера

📁 Файлы:
- interaction-integrity-rules.md - детальные правила (раздел 1.2)
- CLAUDE.md - краткие принципы для быстрого доступа

🎯 Цель: Предотвращение обхода проверок качества кода в будущем

🚀 Generated with [Claude Code](https://claude.ai/code)

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

CLAUDE.md

@@ -62,6 +62,15 @@
 3. **СЛЕДОВАТЬ WORKFLOW** - не нарушать последовательность статусов
 4. **ДОКУМЕНТИРОВАТЬ** - обновлять rules-complete.md при решениях проблем
 
+### ⚡ Принципы качества кода:
+
+- **Качество кода важнее скорости** - лучше потратить время на правильное решение
+- **Pre-commit hooks существуют для защиты проекта** - никогда не обходить их
+- **Исправлять ошибки, а не обходить их** - каждая ошибка ESLint должна быть исправлена
+- **Обход проверок создает технический долг** - `--no-verify` использовать только в крайних случаях
+
+> 📋 **Подробные правила качества кода**: см. раздел 1.2 в [interaction-integrity-rules.md](./interaction-integrity-rules.md#12--принципы-качества-кода)
+
 ### Правила взаимодействия (кратко):
 
 - **Двухэтапный процесс**: Планирование → Одобрение → Выполнение

interaction-integrity-rules.md

@@ -21,7 +21,34 @@
 - ❌ Делать предположения о содержании файлов/компонентов
 - ❌ Гадать, предполагать, домысливать при неопределенности
 
-### 1.2 🛑 КОМАНДЫ ЭКСТРЕННОЙ ОСТАНОВКИ
+### 1.2 ⚡ ПРИНЦИПЫ КАЧЕСТВА КОДА
+
+**КРИТИЧЕСКИ ВАЖНО**: Качество кода важнее скорости разработки
+
+**ОБЯЗАТЕЛЬНЫЕ ПРИНЦИПЫ:**
+
+- ✅ **Качество кода важнее скорости** - лучше потратить время на правильное решение
+- ✅ **Pre-commit hooks существуют для защиты проекта** - никогда не обходить их
+- ✅ **Исправлять ошибки, а не обходить их** - каждая ошибка ESLint должна быть исправлена
+- ✅ **Обход проверок создает технический долг** - `--no-verify` использовать только в крайних случаях
+- ✅ **Лучше потратить время на исправление, чем накапливать проблемы** - долгосрочная перспектива важнее
+
+**ПРИ ОШИБКАХ ЛИНТЕРА:**
+
+1. **Сначала исправить** - разобрать каждую ошибку и исправить правильно
+2. **Потом коммитить** - только после прохождения всех проверок
+3. **Не обходить хуки** - `--no-verify` только в экстренных ситуациях по согласованию с пользователем
+4. **Документировать причины** - если пришлось обойти проверки, записать причину и план исправления
+
+**ПОРЯДОК ДЕЙСТВИЙ ПРИ БЛОКИРОВКЕ КОММИТА:**
+
+1. Проанализировать все ошибки ESLint/TypeScript
+2. Разделить на критические (наши файлы) и предупреждения (старые файлы)
+3. Исправить критические ошибки в первую очередь
+4. Обсудить с пользователем стратегию для остальных ошибок
+5. Только после исправления делать коммит
+
+### 1.3 🛑 КОМАНДЫ ЭКСТРЕННОЙ ОСТАНОВКИ
 
 **"СТОП - ЧИТАЙ ПРАВИЛА"** - немедленно останавливает любую работу