Save this content to: AGENTS.md

# Aestetic UI — инструкции для работы

## Источники и границы

- Читать [требования пользователя](docs/requirements.md), затем документы нужного участка. Требования, технические решения и статус реализации хранятся раздельно.
- Изменение плана, кода или статуса не разрешает ослаблять постоянные требования. Новую гипотезу не выдавать за согласованное решение пользователя.
- Это самостоятельный продукт. Anilau используется только как референс; не изменять его код, документацию, окружение или данные в рамках задач Aestetic UI.
- Пользователю отвечать по-русски. Названия API и код сохранять в их техническом виде.

## Постоянные правила выполнения

- Применять `optimize-codex-usage` в каждом задании: `/Users/alexandrach/.codex/skills/optimize-codex-usage/SKILL.md` на текущем компьютере. При переносе использовать доступную установленную копию; отсутствие обязательного источника сообщать, не подменять его памятью.
- Использовать одно текущее рабочее дерево и текущую ветку. Не создавать дополнительные worktree, копии проекта и ветки и не переключать ветку по инициативе исполнителя.
- Не запускать тесты, typecheck, lint, validation builds, benchmarks, audits и другие проверки без явного запроса пользователя. Обычная реализация, commit/push или выпуск не являются запросом на проверки. Обязательные hooks/CI не отключать и не обходить.
- Не открывать новый экземпляр, окно или вкладку браузера без предварительного явного разрешения. Управление существующей вкладкой для задачи тоже требует разрешённого объёма доступа.
- Не публиковать пакет, сайт, удалённый репозиторий и не менять настройки Codex без соответствующего поручения. Подготовка интеграции не равна её установке.
- Сохранять несвязанные изменения пользователя. В отчёте разделять реализацию, выполненные проверки, ручную приёмку, публикацию и подключение потребителей.
- Делегировать только при явном запросе или применимой инструкции. В разрешённое делегированное задание включать оптимизацию расхода и эти границы.

## Проектные правила разработки

Это рабочие решения архитектуры; их основания и будущие изменения фиксируются в `docs/decisions.md`.

- Сначала изучить существующий компонент и композицию. Не вводить новый вариант только ради единичной страницы.
- Laravel-компоненты владеют разметкой, стилями и взаимодействием; бизнес-модели, права и запросы принадлежат приложению.
- Навигация, оболочка и смысловая иерархия — части системы первого выпуска.
- Живой каталог рендерит реальные Blade-компоненты. Дублирующие HTML-макеты не являются источником истины.
- Правила назначения и примеры находятся в версионированном реестре. Каталог и MCP используют его совместно; существующий код определяет фактический API.
- Не выдавать запись `planned` за доступный компонент. Перед применением через MCP учитывать версию пакета потребителя.
- Расстояния принадлежат компонентам и отношениям элементов; не размазывать произвольные margin/padding по страницам. Не создавать глобальный токен для уникальной геометрии.
- Новые компоненты сопровождать примерами состояний и описанием, когда их выбирать. Доступность и клавиатура входят в контракт; визуальная приёмка и проверки отражаются по факту.