### Глобальные принципы разработки (AI Code Promise)

Твоя главная цель — генерировать безупречный, промышленный код, который соответствует стандартам dxt-ui. Ты обещаешь следовать этим правилам неукоснительно:

0. **Обязательное глубокое изучение**:
   - Прежде чем разрабатывать что-либо для любого проекта или пакета, ты ОБЯЗАН полностью изучить его, чтобы детально понять его архитектуру и стилистику.
   - Прежде чем изменять или исправлять любой файл, ты ОБЯЗАН полностью изучить его внутреннюю структуру и логику.
   - Если в инструкциях, путях или файлах указано расположение внутри `node_modules/` или любой другой внешней/привязанной директории, ты ОБЯЗАН сначала проверить, существует ли этот пакет локально в рабочей области (например, в каталоге `packages/`). Если пакет существует локально, ты ОБЯЗАН переопределить пути на локальный каталог пакета рабочей области и изучать/изменять локальные исходные файлы вместо указанных.
    - **КРИТИЧЕСКИЙ ПЕРВЫЙ ШАГ:** Если какой-либо проект, модуль или инструкция содержит ссылки или пути к конкретным файлам (например, типы, руководства для разработчиков, описания), ты ОБЯЗАН подробно изучить все эти файлы по ссылкам в первую очередь. Как только ты начинаешь работу с проектом или видишь, что он импортируется/используется в коде, над которым ты работаешь, ты должен незамедлительно прочитать и изучить все эти файлы по ссылкам, прежде чем приступать к планированию, предложению изменений или написанию кода. Это требование обязательно и распространяется в том числе на файлы, находящиеся в `node_modules/` (всегда сначала переопределяй пути на локальный каталог рабочей области, если они существуют локально).
   - **БЛОКИРУЮЩИЙ КОНТРОЛЬ ПОСЛЕДОВАТЕЛЬНОСТИ (ПРАВИЛО ХРОНОЛОГИИ):**
     1. Определи все пути пакетов, связанных с запросом (например, `/packages/constructor/...` относится к `@dxtmisha/constructor`).
     2. Найди в промпте секции, соответствующие этим пакетам.
     3. Выпиши все пути к вспомогательным файлам типов и руководств, упомянутые в этих секциях (например, `ai-types.txt`, `ai-developer.txt`).
     4. Ты ОБЯЗАН использовать инструмент `view_file` для чтения и изучения ВСЕХ этих файлов ДО ТОГО, как вызывать `list_dir` для папок компонентов, писать какие-либо планы/чек-листы или вносить/предлагать изменения в код. Нарушение этой последовательности является критическим нарушением протокола.



1. **Принцип «Copy-Paste Ready» (Готовность к использованию)**:
   - Генерируй код, который можно скопировать и запустить без единой правки.
   - Все импорты должны быть абсолютными или корректными относительными.
   - Никаких `// ... остальной код`, никаких `// импорты здесь`. Только полный, рабочий файл.

2. **Нулевая толерантность к галлюцинациям**:
   - Используй только те библиотеки и версии, которые указаны в `package.json` проекта.
   - Не выдумывай методы API, которых не существует в текущих версиях зависимостей.
   - Если информации недостаточно — лучше спроси или укажи на ограничение, чем галлюцинируй.

3. **Стандарты чистого кода (Clean Code)**:
   - **DRY & KISS**: Избегай дублирования, пиши максимально просто и понятно.
   - **SOLID**: Каждый модуль, класс или функция должны иметь одну четкую ответственность.
   - **Декларативность**: Отдавай предпочтение декларативному стилю программирования (функциональные методы массивов, композиция).
   - **Никаких сокращений**: Запрещено использовать сокращенные имена для переменных, свойств, аргументов, методов, классов и т. д. (например, нельзя использовать `el`, `rect1`/`r1`, `dx`/`dy`, `val`, `temp`). Все идентификаторы должны быть информативными, полными и самодокументируемыми.
   - **Оптимизация и понятность**: Код должен быть максимально оптимизированным, производительным и понятным, обеспечивающим легкое чтение и поддержку.
   - **Принцип единой ответственности**: Избегай создания больших «мега-функций» или монолитных блоков. Каждая функция должна быть лаконичной и решать ровно одну задачу (1 функция — 1 функционал).

4. **Бескомпромиссный TypeScript**:
   - Никаких `any`. Используй `unknown`, если тип действительно неизвестен, или создавай generic-типы.
   - Всегда определяй интерфейсы для входных и выходных данных.
   - Используй `as const`, `readonly` и перечисления (enums/union types) для повышения надежности.

5. **Профессиональное документирование (TSDoc)**:
   - Сопровождай все экспортируемые сущности комментариями TSDoc на [wikiLanguage] языке.
   - Описывай назначение, параметры, возвращаемые значения и возможные исключения.
   - Примеры использования в комментариях приветствуются для сложных функций.

6. **Архитектурная консистентность**:
   - Соблюдай структуру проекта. Если в проекте принято выносить логику в `composables` или `utils` — следуй этому паттерну.
   - Не изменяй глобальные стили или стили базовых UI-компонентов, если это не было явно запрошено.

7. **Безопасность и Производительность**:
   - Пиши код, защищенный от ошибок (guard clauses, опциональная цепочка `?.`, nullish coalescing `??`).
   - Избегай лишних вычислений в циклах и тяжелых операций в реактивных зависимостях.

8. **Эстетика и Лаконичность**:
   - Код должен быть красивым. Используй логические отступы и группировку кода по смыслу.
   - Экономь токены, избегая избыточных комментариев там, где код говорит сам за себя.

9. **Строгое следование инструкциям**:
   - Выполняй все действия строго в соответствии с предоставленными командами и инструкциями.
   - Никакой самодеятельности, додумывания или выполнения лишних/незапрошенных действий.
   - Строго придерживайся планов, чек-листов и шагов выполнения.
