--- description: Next.js App Router + shadcn/ui — эталон /servers, поиск по репозиторию, формат ответа и проверки alwaysApply: true --- # Next.js 16 (App Router, Turbopack) + shadcn/ui — правила проекта Стек ориентира: **Next.js 16.2.4** (App Router, Turbopack), **React**, **shadcn/ui**. При расхождении с документацией — верифицировать по официальным источникам для вашей версии. **Язык:** все ответы пользователю — **только на русском**. **Git / Generate Commit Message:** subject и body коммита — **на русском** (префикс `feat`/`fix`/scope — на английском). Подробности — **`release-versioning.mdc`**. ## 1. Документация в первую очередь - Решения сверять с **официальной** документацией Next.js и shadcn/ui (актуальные версии проекта). - Не выдумывать API и «недокументированные» паттерны; предпочитать стабильные, описанные в доках решения. ## 2. Эталон UI/UX: страница `/servers` (критично) - **`app/(main)/servers`** (и связанные компоненты) — **главный эталон** дизайна и поведения. - Выравнивать: layout, отступы, сетку, типографику, структуру компонентов, паттерны взаимодействия. - Переиспользовать оттуда же компоненты и паттерны; **не вводить новый UI-паттерн**, если эквивалент уже есть на `/servers`. ## 3. Большой репозиторий (критично) - **Перед изменениями** искать по проекту: похожие компоненты, существующие паттерны, общие утилиты, хуки, UI-абстракции. - **Не дублировать:** если похожее решение уже есть — расширять или переиспользовать, а не писать с нуля. ## 4. Согласованность между файлами При правке фичи проверять и при необходимости обновлять **все** связанное: компоненты, хуки, route handlers / server actions, типы, стили/обёртки UI — не только открытый файл. ## 5. Зависимости и влияние Перед реализацией: от чего зависит целевой файл, где используется, какие побочные эффекты; избегать ломающих изменений без явной необходимости. ## 6. Нативные возможности фреймворка - Next.js: App Router, Server Components, Server Actions, Route Handlers — по умолчанию предпочтительнее кастомных обходных путей. - UI: компоненты **shadcn/ui**; не плодить самописное, если стандартное решение покрывает задачу. ## 7. Практики качества - Рекомендации Next.js: загрузка данных, рендеринг, производительность. - Минимизировать `'use client'` там, где достаточно серверных компонентов. - Композиция shadcn/ui и доступность (a11y). ## 8. Валидация каждого изменения (обязательно) В ответе явно указать: - **Почему** это согласуется с Next.js, shadcn/ui и эталоном **`/servers`**. - **Server vs Client Component** и обоснование. - Что **переиспользовано** из проекта (паттерны/компоненты). - Какие **файлы проанализированы**. ## 9. Turbopack и консоль разработки После правок: проверить сборку/типы (по возможности запустить проверки проекта), ошибки гидратации, предупреждения; критичное исправить; не игнорировать предупреждения о плохих практиках. ## 10. Правки кода - Минимальные, но **полные** (все зависимые места обновлены). - Не рефакторить несвязанную логику. ## 11. Формат ответа (обязательная структура) 1. **Шаг 0:** список проанализированных файлов. 2. **Шаг 1:** что изменено. 3. **Шаг 2:** почему (Next.js + shadcn/ui + `/servers` + паттерны кодовой базы). 4. **Шаг 3:** анализ влияния (что ещё затронуто). 5. **Шаг 4:** код (диффы или несколько файлов). 6. **Шаг 5:** проверка dev/консоли (ошибки, предупреждения, исправления). 7. **Шаг 6:** опциональные улучшения. ## 12. Дублирование и антипаттерны Явно указывать, если найдено дублирование или антипаттерн; ссылаться на существующую реализацию в проекте; предлагать переиспользование или рефакторинг вместо копипаста. ## Цель Вести себя как **senior** в production-кодовой базе: консистентность, переиспользование, выравнивание с `/servers`, безопасные масштабируемые изменения по best practices Next.js и shadcn/ui, готовый к продакшену код без ошибок сборки/рантайма по возможности.