Адаптер компонентов shadcn для Cursor

# Визуальный адаптер компонентов shadcn

## 🎯 Цель
Выполни рефакторинг существующего компонента `${component_name}`, расположенного в `${component_file_path}`, чтобы он соответствовал **визуальному дизайну, структуре и поведению** референсного компонента, доступного по адресу:

> ${install_command:bunx --bun shadcn@latest add accordion}
${reference_url:}   ← необязательно; оставь пустым, если страницы документации нет

НЕ заменяй бизнес-логику, существующий интерфейс props или способы получения данных. Сохрани их.
Адаптируй только **визуальный слой**: структуру разметки, имена классов, анимации и атрибуты доступности.

---

## 📋 Шаг 1 — Анализ существующего компонента

Перед написанием любого кода:

1. Прочитай полный исходный код `${component_file_path}`.
2. Составь карту:
   - Всех **props и их типов** (интерфейсы TypeScript или PropTypes).
   - Внутренних **переменных состояния** (`useState`, `useReducer`, срезы Zustand и т. п.).
   - Используемых **провайдеров контекста или пользовательских хуков**.
   - Отрисовываемых **дочерних компонентов** и их расположения.
   - **Обработчиков событий** и обратных вызовов, предоставляемых родителю.
3. Перечисли каждый **импорт** — отметь те, которые будут конфликтовать с примитивом shadcn или могут быть им заменены.

Выведи краткую таблицу аудита, прежде чем менять какой-либо код:

| Элемент | Текущее значение | Действие |
|------|--------------|--------|
| Props | ... | сохранить / переименовать / удалить |
| Состояние | ... | сохранить / перенести |
| Контекст/хуки | ... | сохранить / заменить |
| Подкомпоненты | ... | сохранить / заменить |
| Зависимости | ... | сохранить / установить / удалить |

---

## 📦 Шаг 2 — Разрешение зависимостей

Выполни команду установки напрямую:

${install_command}

После завершения команды сгенерированные файлы появятся в
${components_dir:components/ui}/. Перейди к шагу 3, используя эти файлы.

---

## 🔬 Шаг 3 — Изучение референсного компонента

ЕСЛИ ${reference_url} предоставлен → получи его содержимое и извлеки визуальную спецификацию, как прежде.

ЕСЛИ ${reference_url} пуст → прочитай файлы, загруженные командой CLI
на шаге 2, и извлеки ту же информацию непосредственно из исходного кода:
  - схему вариантов cva
  - атрибуты data-state / data-disabled
  - классы анимаций/переходов
  - роли и свойства ARIA
  - паттерны использования cn()

---

## 🛠 Шаг 4 — Рефакторинг компонента

Примени визуальную структуру из шага 3 к существующему компоненту из шага 1.

### Правила:
- ✅ Сохрани все **существующие имена и типы props**, если нет прямого эквивалента shadcn.
- ✅ Сохрани всё **получение данных, бизнес-логику и обратные вызовы**.
- ✅ Оборачивай примитивы Radix с помощью **`forwardRef`** и разворачивай `...props`, чтобы сохранить гибкость.
- ✅ Используй `cn()` для любого объединения className — никогда не конкатенацию строк.
- ✅ Экспортируй именованные составные подкомпоненты, если референсный компонент их использует (например, `Accordion`, `AccordionItem`, `AccordionTrigger`, `AccordionContent`).
- ❌ НЕ импортируй сгенерированный файл shadcn с последующим реэкспортом — создай примитив прямо в рефакторируемом файле, чтобы логика оставалась рядом.
- ❌ НЕ добавляй классы Tailwind, отсутствующие в референсном компоненте, без явного указания.

### Адаптивное поведение (`${responsive_breakpoints:sm md lg}`):
Примени адаптивные классы по принципу mobile-first. Убедись, что текущие контрольные точки в `tailwind.config.ts` соответствуют соглашениям проекта. Если референс использует запросы к контейнерам, установи `@tailwindcss/container-queries`.

---

## 🧩 Шаг 5 — Провайдеры контекста и хуки

Если референсному компоненту требуется провайдер контекста (например, `ToastProvider`, `TooltipProvider`):

1. Проверь, смонтирован ли он уже в `${provider_file:app/layout.tsx}` или `${provider_file:app/providers.tsx}`.
2. Если нет, добавь его в соответствующий файл layout. Предоставь точный diff.
3. Если требуется пользовательский хук (например, `useToast`, `useDialog`), помести его в `${hooks_dir:hooks/}` и импортируй оттуда.

---

## ❓ Шаг 6 — Уточняющие вопросы (задай перед генерацией, если ответ неизвестен)

Если что-либо из следующего нельзя определить по существующему коду, **спроси до написания**:

1. **Данные/props**: Какова структура передаваемых данных? (При необходимости предоставь пример объекта.)
2. **Управление состоянием**: Состояние компонента локальное или управляется извне (Zustand, Redux, React Query)?
3. **Ресурсы**: Требуются ли изображения, логотипы или пользовательские значки, которых нет в lucide-react?
4. **Адаптивность**: Какая компоновка ожидается на контрольных точках `${responsive_breakpoints:sm md lg}`?
5. **Размещение**: Где в дереве маршрутов/макетов приложения будет находиться этот компонент? (Важно для размещения провайдера контекста.)

---

## 📐 Шаг 7 — Формат результата

Предоставь результат в следующем виде:

1. **`${component_file_path}`** — полный файл компонента после рефакторинга.
2. **`${components_dir:components/ui}/${shadcn_component_slug}.tsx`** — примитив shadcn (только если нужен и не сгенерирован CLI).
3. **`lib/utils.ts`** — только если его нужно создать или обновить.
4. **Diff макета/провайдера** — только если нужно добавить провайдер.
5. Короткий раздел **примечаний по миграции** со списком:
   - Удалённых зависимостей
   - Переименованных props (если есть)
   - Необходимых ручных шагов (например, добавления переменных CSS в `globals.css`)

---

## 🎨 Переменные Tailwind CSS (дизайн-токены shadcn)

Подтверди, что `globals.css` содержит необходимые пользовательские свойства CSS. Если референсный компонент использует токены вроде `--radius`, `--background`, `--foreground`, `--primary`, `--ring`, добавь недостающие переменные. Используй стандартный набор токенов shadcn для `${color_theme:zinc}`, если в проекте ещё не определена собственная тема.

---

## 🚫 Ограничения

- Фреймворк: **${framework:Next.js 14+ App Router}**
- Стилизация: только **Tailwind CSS ${tailwind_version:3}** — без встроенных стилей, CSS-модулей и styled-components.
- TypeScript: **строгий режим**. Весь новый код должен быть полностью типизирован.
- Не повышай и не понижай существующие версии зависимостей, если нет прямого конфликта peer-зависимостей.