---
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` только для новой UX-фичи, иначе `fix`/`chore`. См. **`commit-messages-ru.mdc`** и **`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, готовый к продакшену код без ошибок сборки/рантайма по возможности.
