# Адаптация проекта к Bark Brand System

Твоя задача — привести существующий интерфейс к Bark Brand System, а не
проектировать новый продукт.

## Источники

Корень бренд-системы — `vendor/bark-brand-system/` или
`node_modules/@bark/brand-system/` (npm-пакет; пути ниже — от этого корня).
Перед изменениями обязательно прочитай актуальные файлы:

1. `vendor/bark-brand-system/AGENTS.md`
2. `vendor/bark-brand-system/docs/STYLE_GUIDE.md`
3. `vendor/bark-brand-system/docs/INHERITANCE_RULES.md`
4. `vendor/bark-brand-system/docs/COMPONENT_RULES.md`
5. `vendor/bark-brand-system/docs/SSO_AVATAR.md`
6. `vendor/bark-brand-system/docs/DATA_FORMATS.md`
7. `vendor/bark-brand-system/tokens/brand.tokens.json`
8. `vendor/bark-brand-system/products/<product>/brand.config.json`

Сначала получи актуальное состояние проекта и проверь незакоммиченные
изменения. Не перезаписывай пользовательские правки.

## Главный принцип

Код и текущий интерфейс приложения определяют, какие страницы, функции, данные
и элементы существуют.

Брендбук определяет только то, как существующие элементы должны выглядеть и
вести себя.

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

## Приоритет решений

1. Текущая задача пользователя.
2. Реальный код, бизнес-логика и информационная архитектура приложения.
3. Product config подключённого Bark-продукта.
4. Правила, шаблоны и tokens Bark Brand System.

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

## Запрет на выдумывание

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

Не придумывай данные, метрики, статусы, названия разделов и бизнес-сценарии.

Не удаляй, не скрывай и не объединяй существующие функции, данные или элементы
без прямого запроса пользователя.

Не заменяй существующие библиотеки графиков, форм, таблиц, авторизации или
роутинга только ради оформления.

Не выполняй несвязанные refactor, migration или dependency upgrades.

Если брендбук требует компонент, но соответствующей функции в приложении нет,
зафиксируй это как найденный gap. Не создавай бизнес-логику молча.

Если функция уже существует, используй её и приведи существующий компонент к
стандарту Bark. Не создавай рядом второй компонент.

## Что разрешено менять

- цвета, шрифты, размеры, отступы, радиусы и состояния через Bark tokens;
- существующие logo, favicon, title, manifest и metadata;
- оформление существующих navigation, sidebar, footer и controls;
- существующие loading, empty, error и disabled states;
- существующие Avatar, charts, modals, fields и buttons;
- расположение существующего logout согласно footer-контракту.

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

## Обязательные правила

- Используй Bark tokens и готовые шаблоны. Не создавай локальную палитру.
- Red Hat Display — только логотип/wordmark; Onest — весь интерфейс, включая
  H1/H2; IBM Plex Mono — числовые данные.
- Используй только Lucide icons из `https://lucide.dev/`.
- Сохраняй lower-case no-space wordmark: `bark<module>`.
- В sidebar прокручивается только navigation. Theme switch, блок идентичности
  с `Выйти` и footer остаются закреплены снизу.
- Для переходов и долгих кнопок используй общую систему загрузки Bark из
  `templates/loader.html` и `templates/loader.snippet.js`.
- Если проект использует SSO, существующая кнопка входа сразу показывает
  spinner 18px + `Входим…`, получает `disabled`/`aria-busy` и остаётся loading
  до redirect/error. Используй `startButtonLoading()`; не создавай вторую кнопку
  или одновременный full-screen loader для той же фазы.
- Если в приложении уже есть Avatar сотрудника, передавай в него актуальный
  `response.user.picture` по `docs/SSO_AVATAR.md`. Не создавай новый Avatar.
- Идентичность в оболочке ровно одна: блок `.bark-sidebar__user` в футере
  сайдбара (`templates/sidebar.html`) — аватар 40px с фото из SSO (fallback —
  инициалы `initialsFromName()`), имя и email в одну строку с ellipsis,
  icon-only `Выйти` справа. В шапке страницы аватара и имени нет; `barkone` —
  задокументированное легаси-исключение.
- Плотность закреплена: `.bark-main` `24px 32px 40px`, секции через 24px, сетки
  через 16px, панель 20px (`--dense` `12px 16px`), строки таблиц 44px/36px.
  Не делай экраны «воздушнее» стандарта; отступы больше 40px — только в empty
  states и на auth-экранах.
- Favicon подключай только через сгенерированный `favicon.head.html`
  (SVG + PNG + apple-touch + manifest + theme-color = продуктовый цвет);
  иконки не рисуй вручную, старые favicon удаляй.
- Фильтры списков — тулбар 32px с accent-чипами и «Сбросить» (≤3 inline,
  дальше один popover «Фильтры»); пагинация — 25/50/100 с mono-счётчиком,
  без infinite scroll. Уведомления — только единый toast
  (`templates/toast.snippet.js`): ok/info 5s, warn 8s, bad до закрытия;
  валидация — у поля, постоянное состояние — `.bark-alert`.
- Даты/числа/деньги — только через единый форматтер
  (`templates/format.snippet.js`, правила в `docs/DATA_FORMATS.md`): всё время
  в МСК, `ДД.ММ.ГГГГ`, 24 часа, запятая в дробях, `1 234,56 ₽` с копейками,
  `3,6 млн` вместо `3.55M`, закреплённые лестницы относительного времени и
  длительностей. Ручное форматирование запрещено.
- Если в приложении уже есть графики, используй разрешённые chart-типы и
  существующую chart library. Не добавляй графики на экраны, где их не было.
  Для новых графиков — только Apache ECharts с темой Bark
  (`templates/chart-theme.snippet.js`), self-hosted bundle без CDN, максимум
  4 серии из закреплённой палитры.
- Сортировка таблиц: ровно одна активная (`aria-sort`), числа/даты сначала по
  убыванию, состояние в URL. Действия строк: до 2 icon-кнопок 32px, дальше
  kebab с `.bark-menu`; деструктивные — только в меню и с подтверждением.
- Если logout уже существует, используй `.bark-sidebar__logout` и перенеси его
  в pinned sidebar/drawer footer без изменения session-логики.

## Порядок работы

1. Изучи существующие routes, screens, components и текущие состояния UI.
2. Кратко перечисли, что реально найдено и что будет изменено.
3. Отдельно укажи, какие элементы ты не будешь добавлять.
4. Сопоставь каждый изменяемый элемент с конкретным правилом брендбука.
5. Выполни минимально необходимую адаптацию, работая с существующими компонентами.
6. Проверь light/dark theme, desktop/mobile, overflow и длинный контент.
7. Проверь loading, empty, error, disabled и focus states затронутых элементов.
8. Если проект открывается в браузере, сравни screenshots затронутых экранов до
   и после изменений на desktop/mobile.
9. Запусти существующие tests, lint и build.
10. Не останавливайся на плане, если нет настоящего блокера.

## Каталог проектов и карта инфраструктуры

Для каждого сотруднического web-проекта, лендинга или дашборда,
который создаётся или заметно обновляется:

- проверь каталог `https://dashboard.nozhmaster.ru/` по каноническому URL;
- не создавай дубль: добавь новую карточку или обнови существующую;
- укажи короткое понятное сотрудникам описание, отдел, владельца и
  правильный тип проекта;
- после production-деплоя сделай актуальный desktop-скриншот первого экрана без
  секретов и персональных данных; обновляй его после крупных визуальных
  изменений;
- проверь живую карточку в каталоге и отсутствие дублей.

При любом изменении архитектуры, деплоя, домена, порта, БД, cron, очереди,
внешнего API или способа запуска обнови единую карту
`https://gitlab.toolsfs.synology.me/v.shurygin/infra-map` по её шаблонам. Не
создавай параллельный реестр и не записывай секреты.

Если доступа к dashboard или infra-map нет, явно зафиксируй блокер и перечень
данных для обновления. Изменение не считается полностью завершённым, пока
каталог и карта не актуализированы или блокер не описан.

## Критерии готовности

- не появилось незапрошенных UI-элементов;
- существующие UI-элементы не исчезли без явного запроса;
- существующие функции, данные и пользовательские сценарии сохранены;
- нет второго Avatar, sidebar, chart engine или набора controls;
- цвета, размеры и состояния берутся из Bark tokens/components;
- идентичность одна: блок в футере сайдбара (фото SSO/инициалы + имя + email +
  icon-only `Выйти`); в шапке страницы аватара нет;
- плотность страниц соответствует закреплённым числам (страница `24/32/40`,
  панель 20, таблицы 44/36) — без «воздушных» экранов;
- favicon подключён через `favicon.head.html`, все пять пунктов приёмки
  выполнены;
- footer и navigation не перекрываются;
- текст не выходит за границы на desktop/mobile;
- loading/error/empty states не вызывают layout shift;
- light/dark theme остаются читаемыми;
- существующие tests, lint и build проходят;
- `bark-check` проходит (job `bark:check` из `ci/bark-brand.gitlab-ci.yml`);
- мета сайдбара показывает актуальную версию: `Bark UI vX.Y.Z`.
- карточка сотруднического web-проекта в dashboard актуальна и не дублируется;
- карта инфраструктуры обновлена, если изменились деплой или зависимости.

## Финальный отчёт

В финале сообщи:

- что именно изменено;
- что намеренно не менялось и не добавлялось;
- какие проверки выполнены;
- какие gaps, конфликты или отклонения остались.