Универсальные инструкции для проектов на React / Next.js

# Универсальные инструкции для проектов на React / Next.js

> Назначение: общие правила разработки различных проектов на React + TypeScript, Next.js + TypeScript и Tailwind CSS.
> Применение: помести этот файл в корень нового проекта под именем `AGENTS.md`, `CLAUDE.md` или `PROJECT_RULES.md` либо используй его как базовый набор инструкций для ИИ-агента.
> Важно: эти инструкции не содержат правил, специфичных для продукта. Всё, что относится к конкретному проекту, храни в отдельном файле `PROJECT_RULES.md`.

---

# 1. Основной принцип

Создавай приложение, готовое к промышленной эксплуатации, а не набор несвязанных компонентов.

Всегда соблюдай такую последовательность:

1. Изучи текущую структуру проекта, `package.json`, маршрутизацию, базовые UI-компоненты, хранилища состояния, хуки, схемы и правила проекта.
2. Найди существующие действия, вспомогательные функции, схемы и компоненты, которые можно переиспользовать.
3. Определи минимальное изменение, необходимое для выполнения задачи.
4. Сохрани существующее поведение.
5. Реализуй каждую новую функцию полностью: модель, валидацию, UI, хранение/импорт/экспорт, пограничные случаи и проверку.
6. Выполни соответствующие проверки и честно сообщи о результатах.

Не добавляй зависимости, абстракции, глобальное хранилище состояния или архитектурный слой, если они действительно не нужны.
По умолчанию используй `shadcn/ui` для работы над UI. Не добавляй поверх него другой UI-набор без явной причины.

---

# 2. Выбор между React и Next.js

Используй Next.js, когда проекту нужны:

- маршрутизация;
- SEO;
- SSR / Server Components;
- Server Actions;
- Route Handlers / API-маршруты;
- аутентификация;
- доступ к базе данных;
- приватные переменные окружения;
- публикация контента.

Используй React + Vite, когда:

- приложение полностью клиентское;
- SEO не требуется;
- это локальный инструмент, дашборд, редактор, административная панель или интерфейс, похожий на настольное приложение;
- сервер уже существует как отдельный сервис.

Не выбирай Next.js только из-за его популярности. Не добавляй Redux, Zustand, React Query, библиотеку форм или другой UI-набор без конкретной причины.

---

# 3. Стек и проверки по умолчанию

По умолчанию используй:

- React;
- TypeScript в строгом режиме;
- Tailwind CSS;
- `shadcn/ui` как обязательный подход к UI для аккуратного дизайна и быстрой разработки интерфейса;
- Lucide React или библиотеку иконок, используемую текущей конфигурацией shadcn;
- ESLint;
- общую вспомогательную функцию `cn()`;
- валидацию внешних данных во время выполнения;
- доступные HTML-элементы.

Используй `shadcn/ui` как основной источник базовых UI-компонентов: кнопок, полей ввода, списков выбора, диалогов, выдвижных панелей, выпадающих меню, подсказок, вкладок, каруселей, карточек, меток, скелетонов, областей прокрутки и других необходимых компонентов. Создавай собственные базовые компоненты только тогда, когда shadcn не предоставляет подходящего компонента или в проекте уже есть стабильный локальный базовый компонент.

Для MVP начни с данных-заглушек/JSON/localStorage и сначала проверь локальные пользовательские сценарии. Бэкенд, базу данных, платежи, аутентификацию и внешние интеграции добавляй в последнюю очередь, когда UI, модели и сценарии уже понятны.

После изменений кода выполни как минимум эти команды:

```bash
npm run typecheck
npm run lint
npm run build
```

Не утверждай, что проект работает, если эти команды не запускались или завершились с ошибками.

---

# 4. Архитектура

В проектах Next.js, для которых ожидается рост, по умолчанию храни исходный код внутри `src/`: `src/app`, `src/components`, `src/lib`, `src/data`, `src/hooks` и `src/features`. Вспомогательные папки и файлы корневого уровня (`public`, конфигурационные файлы, lock-файлы и README) оставляй в корне проекта.

Для небольших проектов допустима следующая структура:

```text
src/
  app/ or pages/
  components/
  features/
  lib/
  shared/
```

Для средних и крупных проектов используй подход, похожий на FSD:

```text
src/
  app/       # bootstrap, providers, layouts, routes
  views/     # page-level composition
  widgets/   # large UI blocks
  features/  # user workflows
  entities/  # domain model
  shared/    # generic helpers, config, thin wrappers around shadcn/ui
```

Направление импортов:

```text
app/views -> widgets -> features -> entities -> shared
```

Не следует:

- импортировать `widgets` в `features`;
- размещать бизнес-логику в `shared`;
- превращать `shared/lib` в свалку несвязанных функций;
- дублировать логику изменения данных в нескольких UI-компонентах;
- использовать глубокие импорты внутренних частей другого модуля, если он предоставляет публичный API.

---

# 5. Публичный API

Каждая папка функции, сущности или общего UI должна предоставлять понятный публичный API через `index.ts`, если модуль используется извне. У базовых компонентов shadcn публичный API обычно уже находится в `components/ui/*` или локальном UI-слое проекта.

Хорошо:

```ts
import { createTask } from "@/features/create-task";
```

Плохо:

```ts
import { createTask } from "@/features/create-task/model/createTask";
```

Исключение: внутренний код в пределах одной функции или сущности.

---

# 6. TypeScript

Обязательно:

- включи `strict: true`;
- не используй `any`, кроме изолированного кода совместимости;
- не скрывай ошибки типов утверждениями `as`;
- используй дискриминируемые объединения для сложного состояния;
- проверяй JSON во время выполнения по схеме;
- не создавай несколько одинаковых типов без веской причины.

Пример типа состояния:

```ts
type LoadState<T> =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "success"; data: T }
  | { status: "error"; message: string };
```

---

# 7. Состояние и эффекты React

Храни состояние там, где ему действительно место:

| Тип состояния | Где хранить |
| ------------ | ----------------------------------------------------------- |
| Локальный UI | `useState`, `useReducer` |
| Состояние URL | параметры маршрута/поиска |
| Серверное состояние | серверный рендеринг или слой кеширования/запросов |
| Состояние формы | хук/библиотека форм |
| Глобальный UI | небольшое хранилище состояния при необходимости |
| Доменное состояние | сущность/хранилище, если состояние используется в нескольких сценариях |

Не помещай в глобальное хранилище:

- состояние наведения;
- состояние одного выпадающего меню;
- черновое значение одного поля ввода;
- состояние одного модального окна;
- временно выбранную вкладку одного компонента.

Используй `useEffect` для синхронизации с внешними системами:

- API браузера;
- таймерами;
- подписками;
- внешними хранилищами состояния;
- интеграциями с DOM.

Не используй `useEffect` для производных значений.

Плохо:

```tsx
const [fullName, setFullName] = useState("");

useEffect(() => {
  setFullName(`${firstName} ${lastName}`);
}, [firstName, lastName]);
```

Хорошо:

```tsx
const fullName = `${firstName} ${lastName}`;
```

---

# 8. Границы Next.js

В App Router компоненты по умолчанию являются Server Components.

Добавляй `"use client"` только там, где нужны:

- обработчики событий;
- локальное состояние;
- эффекты;
- `window`, `document` или `localStorage`;
- перетаскивание;
- `contenteditable`;
- библиотеки, работающие только на клиенте.

Не делай весь макет клиентским компонентом без явной необходимости.

К коду, предназначенному только для сервера, относятся:

- доступ к базе данных;
- аутентификация;
- приватные API-клиенты;
- секретные переменные окружения;
- вебхуки;
- проверки доступа.

Никогда не импортируй серверный модуль в клиентский компонент.

---

# 9. Валидация во время выполнения и миграции

Проверяй все внешние данные на границе системы:

- тела запросов;
- данные форм;
- параметры URL/поиска;
- загруженные файлы;
- импортируемый JSON;
- данные localStorage/IndexedDB;
- ответы внешних API.

При добавлении нового поля модели обнови весь жизненный цикл:

1. Тип TypeScript.
2. Схему проверки во время выполнения.
3. Фабрику/значения по умолчанию.
4. Парсер/миграцию старых данных.
5. Вспомогательные функции нормализации.
6. Импорт/экспорт.
7. Индексацию поиска/фильтрации, если поле должно участвовать в поиске.
8. Снимки отмены/повтора действий, если пользователи могут редактировать поле.
9. UI для создания, редактирования и очистки поля.
10. Пограничные случаи и проверки.

Пример:

```ts
return {
  ...item,
  status: item.status ?? "active",
  tags: normalizeTags(item.tags),
  dueDate: normalizeDate(item.dueDate),
};
```

Не добавляй поле модели только в UI.

---

# 10. Формы

Каждая форма должна включать:

- схему валидации;
- ошибки полей;
- состояние отправки/загрузки;
- отключённую кнопку отправки во время отправки;
- защиту от повторных отправок;
- состояние ошибки;
- поведение при успехе;
- поведение сброса/черновика, когда это применимо.

Форма не завершена, если она работает только при полностью успешном запросе.

---

# 11. shadcn/ui и общий UI

По умолчанию используй `shadcn/ui`, чтобы быстро создавать аккуратные, согласованные интерфейсы.

Правила:

- сначала проверь, есть ли нужный компонент в реестре shadcn;
- добавляй компоненты shadcn через CLI или принятым в проекте локальным способом;
- не создавай собственные Button, Input, Modal, Dropdown, Tooltip, Tabs или Card, если shadcn уже покрывает этот сценарий;
- адаптируй компоненты shadcn через `className`, варианты и композицию, а не копируй похожие компоненты;
- отделяй бизнес-компоненты от базовых: `components/marketplace`, `features/*/ui`, `widgets/*` или `entities/*/ui`;
- в `components/ui` или `shared/ui` храни только базовые компоненты shadcn и тонкие переиспользуемые обёртки;
- не помещай туда бизнес-компоненты, специфичные для продукта;
- если shadcn не предоставляет компонент, создай минимальную локальную обёртку, согласованную с текущей конфигурацией shadcn.

Базовый набор компонентов shadcn для рабочих интерфейсов:

```text
button
input
select
textarea
checkbox
switch
dialog
sheet
dropdown-menu
popover
tooltip
tabs
card
badge
avatar
separator
scroll-area
skeleton
carousel
accordion
collapsible
hover-card
```

Для сценариев маркетплейса, чата и поддержки также предусмотрены следующие более новые компоненты shadcn:

```text
message
message-scroller
attachment
marker
```

Всегда используй `cn()`:

```ts
export function cn(...values: Array<string | false | null | undefined>) {
  return values.filter(Boolean).join(" ");
}
```

---

# 12. Выбор подходящего места в UI

Прежде чем добавлять новый инструмент, выбери подходящее место:

| Размер функции | Размещение | Пример |
| ---------------------------------- | --------------------------------- | ----------------------------------- |
| 1–5 быстрых настроек | контекстное меню / выпадающее меню / всплывающая панель | статус, срок, теги |
| 5–12 сгруппированных настроек | прокручиваемая всплывающая панель с разделами | свойства сущности, компактные фильтры |
| большие наборы данных или массовые действия | боковая / выдвижная панель | фильтры, панель инструментов |
| сложная форма или опасное действие | модальное окно | импорт/экспорт, подтверждение удаления |
| постоянное рабочее пространство | отдельное представление/страница/виджет | дашборд, календарь, редактор |

Правило:

> Если элемент управления используется время от времени, оставь его в меню.
> Если элемент управления используется постоянно, оставь его видимым в основной области.
> Если элемент управления сложный и объёмный, перенеси его в боковую панель или модальное окно.

Не превращай небольшую группу элементов управления в большую карточку на странице. В рабочих интерфейсах это впустую расходует ценное пространство.

---

# 13. Компактный UI для редакторов, дашбордов и рабочих пространств

В приложениях для работы основное содержимое должно оставаться в центре внимания.

Обязательно:

- второстепенные элементы управления не должны сдвигать вниз заголовок, текст, доску или редактор;
- свойства сущности обычно должны открываться кнопкой-иконкой рядом с заголовком;
- у кнопок настроек должен быть `aria-label`;
- важный статус можно показывать небольшой меткой;
- действия создания/добавления должны появляться в понятном контексте;
- сценарии с активным использованием боковых панелей должны включать удобное для мобильных устройств меню или переключатель;
- не делай рабочий инструмент похожим на лендинг.

Плохо:

```tsx
${largepropertiescard}
  <Select>Status</Select>
  <Select>Task</Select>
  <Input>Date</Input>
  <Input>Tags</Input>
</LargePropertiesCard>
```

Хорошо:

```tsx
${titlerow}
  <TitleInput />
  <PropertiesMenu />
</TitleRow>
```

---

# 14. Наложенные элементы, выпадающие меню, всплывающие панели и контекстные меню

Каждое меню должно вести себя как полноценный наложенный элемент.

Правила:

- если меню может выходить за границы контейнера, рендери его через `createPortal(..., document.body)`;
- используй `position: fixed` или надёжный вспомогательный инструмент позиционирования;
- явно задавай `z-index`;
- используй непрозрачный `backgroundColor`;
- не полагайся только на полупрозрачный фон `bg-black/50` или размытие;
- добавляй границу, обводку или тень;
- задавай `max-height` и `overflow-y-auto`;
- закрывай по `Escape`;
- закрывай по щелчку/касанию снаружи;
- не допускай, чтобы текст страницы просвечивал сквозь меню или отображался поверх него;
- состояния наведения и активности не должны менять размеры пункта.

Минимальный стиль наложенного элемента:

```tsx
<div
  role="menu"
  className="rounded-2xl border p-2 shadow-2xl"
  style=${backgroundcolor:"#151a21",
    boxShadow: "0 24px 70px rgb(0 0 0 / 78%)",
    isolation: "isolate",
    zIndex: 1000,}
>
  ...
</div>
```

Если фон меню отображается неправильно или содержимое оказывается над ним, проверь:

- портал;
- `position`;
- `z-index`;
- родительские контексты наложения;
- `isolation`;
- непрозрачность/фон;
- переполнение/обрезку родительского элемента.

---

# 15. Списки вариантов в меню

Список задач, проектов, пользователей, тегов или других вариантов в меню не должен выглядеть как плотная стена текста.

Для двухстрочного пункта:

- используй `min-height` 40–44px;
- добавляй `gap` между иконкой, текстом и галочкой;
- используй вертикальные отступы, например `py-1.5`;
- задавай заголовку и метаданным разную высоту строки;
- добавляй `mt-0.5` между заголовком и метаданными;
- применяй `min-w-0` к родительскому элементу, содержащему текст;
- применяй `truncate` к заголовку и метаданным;
- применяй `shrink-0` к галочкам и иконкам.

Пример:

```tsx
<button className="flex min-h-11 items-center gap-2.5 rounded-lg px-2.5 py-1.5">
  <span className="min-w-0 flex-1">
    <span className="block truncate font-medium leading-5">${title}</span>
    <span className="mt-0.5 block truncate text-xs leading-4 text-muted">
      {meta}
    </span>
  </span>
  {isActive ? <Check className="shrink-0" /> : null}
</button>
```

---

# 16. Длинный текст и переполнение

Любой пользовательский текст может содержать длинное слово без пробелов.

Для редакторов, элементов `contenteditable`, Markdown, заголовков карточек и комментариев:

- используй `min-w-0` для дочерних элементов flex/grid;
- используй актуальные утилиты Tailwind для переноса длинных слов;
- в новых версиях Tailwind `break-words` может записываться как `wrap-break-word`;
- прежде чем использовать классы переноса слов, переполнения, text-wrap, сетки, отступов или произвольных значений, проверь документацию текущей версии Tailwind в проекте;
- если элемент находится во flex-контейнере и длинный текст нарушает его ширину, проверь, подходит ли `wrap-anywhere`;
- используй `truncate` для коротких строк в карточках;
- переноси основной текст, а не допускай горизонтальное переполнение;
- текст не должен отображаться поверх меню, всплывающей панели или модального окна;
- проверяй на длинной строке без пробелов.

Для редактируемого блока:

```tsx
className = "min-w-0 wrap-break-word whitespace-pre-wrap";
```

Если проект использует старую версию Tailwind, в которой нет `wrap-break-word`, проверь установленную версию Tailwind и официальную документацию или примечания к версии, затем используй поддерживаемый эквивалент: `break-words`, произвольное значение или CSS-свойство.

Для метки:

```tsx
className = "inline-flex whitespace-nowrap";
```

Метка не должна сжимать текст по вертикали. Если она не помещается, перенеси её на новую строку или используй `truncate` с явно заданной, понятной шириной.

---

# 17. Tailwind CSS: проверяй актуальные имена классов

ИИ-агент должен проверять установленную в проекте версию Tailwind, прежде чем использовать новые или потенциально зависящие от версии классы.

Порядок действий:

1. Изучи `package.json` и lock-файл.
2. Определи основную версию Tailwind.
3. Если класс может различаться между версиями, проверь официальную документацию именно этой версии.
4. Не заменяй классы механически, без проверки.
5. При использовании произвольного значения убедись, что оно включается в результат сборки.

Особое внимание обращай на:

- `break-words` / `wrap-break-word` / `wrap-anywhere`;
- `text-wrap`, `text-balance` и `text-pretty`;
- `overflow-*`;
- `size-*`;
- произвольные цвета, например `bg-[#151a21]`;
- произвольные тени;
- произвольные шаблоны сетки;
- динамические имена классов.

Не собирай динамические классы Tailwind таким образом:

```tsx
const color = "red";
return <div className={`bg-${color}-500`} />;
```

Tailwind может не обнаружить такой класс во время сборки. Используй таблицу соответствий:

```tsx
const colorClassName = {
  danger: "bg-red-500",
  success: "bg-emerald-500",
}${variant};
```

Если важный фон наложенного элемента не должен зависеть от результата сборки Tailwind, допустимо использовать встроенный `style.backgroundColor`.

---

# 18. Макет и сворачивание боковой панели

Сворачивание боковой или выдвижной панели не должно менять высоту страницы или оставлять пустой блок.

Правила:

- каркас приложения: `h-dvh min-h-dvh overflow-hidden`;
- внутренние области: `flex min-h-0 flex-1 overflow-hidden`;
- включай прокрутку только в подходящей области через `overflow-y-auto`;
- при сворачивании меняй ширину/flex-basis, а не высоту;
- свёрнутая боковая панель должна иметь стабильную ширину;
- предусмотри понятный элемент управления для восстановления боковой панели;
- разрушительные действия или действия создания не должны оставаться отдельными кнопками без контекста;
- предпочтения можно сохранять в localStorage.

Пример:

```tsx
<main className="flex h-dvh min-h-dvh flex-col overflow-hidden">
  <div className="flex min-h-0 flex-1 overflow-hidden">
    <Sidebar className="h-full min-h-0 shrink-0" />
    <section className="min-h-0 flex-1 overflow-y-auto" />
  </div>
</main>
```

---

# 19. API браузера и localStorage

В Next.js API браузера доступны только в Client Components.

Правила:

- файл, использующий `localStorage`, `window`, `document`, перетаскивание или `contenteditable`, должен включать `"use client"`;
- не читай `localStorage` в серверном компоненте;
- не вызывай ошибки гидратации разными начальными значениями;
- оборачивай операции с хранилищем в `try/catch`;
- сбои хранилища не должны ломать UI;
- проверяй сохранённые предпочтения UI после перезагрузки;
- сборка не должна падать с ошибкой `window is not defined`.

Пример:

```tsx
const toggle = useCallback(() => {
  setIsCollapsed((current) => {
    const next = !current;

    try {
      window.localStorage.setItem(KEY, next ? "true" : "false");
    } catch {
      // UI still works without browser storage.
    }

    return next;
  });
}, []);
```

Проверь, что:

- состояние по умолчанию работает при пустом хранилище;
- перезагрузка сохраняет состояние;
- приватный режим или ошибки хранилища не ломают экран;
- сборка не падает с ошибкой `window is not defined`.

---

# 20. Связи между инструментами

Если одна сущность связана с другой, связь должна быть настоящей:

- храни её в модели;
- показывай в UI;
- щелчок по ней открывает связанную сущность;
- при создании связанной сущности сразу сохраняй связь;
- сохраняй связь при импорте/экспорте;
- учитывай связь в поведении поиска/фильтрации, когда это полезно;
- если связанная сущность удалена, показывай в UI запасной вариант.

Не создавай декоративную кнопку «Связать», если связь не сохраняется.

---

# 21. Единые доменные операции

У каждой пользовательской операции должен быть единый источник истины.

Не следует:

- создавать сущность одним способом из slash-меню;
- создавать её другим способом из панели инструментов;
- обходить валидацию из палитры команд;
- дублировать логику изменения данных в контекстном меню.

Вместо этого:

- храни доменную операцию в одном месте;
- вызывай эту операцию из UI-компонентов;
- используй одну и ту же валидацию и ограничения для каждой точки входа.

---

# 23. Доступность

Обязательно:

- используй `<button>` для действий;
- используй `<a>` для навигации;
- добавляй `aria-label` кнопкам, состоящим только из иконки;
- добавляй подписи для полей ввода;
- показывай видимое состояние фокуса;
- поддерживай навигацию с клавиатуры;
- закрывай модальные окна и всплывающие панели по `Escape`;
- закрывай всплывающие панели щелчком снаружи;
- используй удержание фокуса внутри модальных окон;
- не используй цвет как единственный способ передачи смысла;
- не заменяй `<button>` на `${div_onclick}`.

---

# 24. Состояния загрузки, отсутствия данных и ошибки

Экраны, работающие с данными, должны учитывать:

- загрузку;
- успех;
- отсутствие данных;
- отказ в доступе;
- сетевую ошибку;
- ошибку сервера;
- повторную попытку.

Пустой экран без объяснения — это ошибка.

---

# 25. Безопасность

Обязательно:

- храни секреты только на сервере;
- используй валидацию во время выполнения;
- обеспечивай контроль доступа на сервере;
- проверяй MIME-типы и размеры файлов;
- очищай пользовательский HTML;
- не используй `dangerouslySetInnerHTML` без средства очистки;
- не записывай токены или персональные данные в логи;
- не доверяй значениям `role` или `userId`, переданным браузером.

---

# 26. Производительность

Сначала измеряй, затем оптимизируй.

Используй:

- динамические импорты для тяжёлых модулей редакторов, диаграмм, карт и PDF;
- оптимизацию изображений;
- виртуализацию больших списков;
- отмену запросов/защиту от устаревших запросов в поиске;
- селекторы для уменьшения повторных рендеров.

Не добавляй мемоизацию без причины.

---

# 27. Проверяй дизайн на реалистичном содержимом

Дополнительные рекомендации по качеству интерфейсов можно найти здесь:

- https://jakub.kr/skills/make-interfaces-feel-better

Этот ресурс полезен при доработке типографики, состояний наведения, теней, границ, отступов, оптического выравнивания, микровзаимодействий и общего ощущения от интерфейса.

Прежде чем завершить задачу по UI, проверь его с:

- длинным словом без пробелов;
- длинным русским заголовком;
- коротким заголовком;
- пустым заголовком;
- несколькими тегами;
- длинным названием списка/категории;
- несколькими вариантами в выпадающем списке;
- активными и неактивными статусами;
- указанной и отсутствующей датой.

Проверь, что:

- ничего не перекрывается;
- наложенные элементы закрывают расположенное под ними содержимое;
- текст не просвечивает сквозь меню;
- метки не сжимают текст по вертикали;
- элементы не теснят друг друга;
- полосы прокрутки не закрывают важный текст;
- состояния наведения и фокуса хорошо различимы;
- всё корректно выглядит и на настольной, и на мобильной ширине.

---

# 28. Проверки после изменений

После изменений кода выполни:

```bash
npm run typecheck
npm run lint
npm run build
```

Если изменён UI:

- открой страницу в браузере;
- пройди основной пользовательский сценарий;
- проверь взаимодействие клавиатурой и мышью;
- проверь поведение `Escape` и щелчка снаружи;
- проверь перезагрузку;
- проверь длинный текст;
- проверь мобильную ширину области просмотра;
- сделай скриншот, если изменился визуальный слой.

Если проверка в браузере невозможна, прямо скажи об этом. Не выдавай `typecheck` за визуальную проверку.

---

# 29. Git и рабочее дерево

Перед внесением изменений проверь текущее состояние:

```bash
git status --short
```

Правила:

- не отменяй чужие изменения без явного запроса;
- не используй разрушительные команды без явного разрешения;
- не выполняй несвязанный с задачей рефакторинг;
- не создавай коммиты автоматически, если пользователь не просит;
- не меняй окончания строк и не переформатируй весь проект без необходимости.

---

# 30. Итоговый отчёт

В итоговом ответе укажи:

- что изменилось;
- какие файлы важны;
- какие проверки выполнены;
- что не удалось проверить;
- какие риски остаются.

Отчёт должен быть кратким и честным.