Редактор меняет текст в CMS, менеджер разбирает заявки, администратор выдаёт доступы, а техническая команда следит за интеграциями. Пока бизнес небольшой, эти процессы можно держать в нескольких сервисах и таблицах. Затем появляется знакомая проблема: данные расходятся, права назначаются вручную, а любое новое действие требует ещё одной кнопки и отдельной инструкции.
AdminCore мы строим для другого сценария. Это не универсальная панель со всеми возможными разделами, а модульная основа цифрового продукта. Ею пользуются люди, к ней подключаются внутренние сервисы, а часть регулярных операций могут выполнять ИИ-агенты. У всех один путь к данным: документированный API с понятными правилами доступа.
Почему одной красивой панели недостаточно
Административный интерфейс часто проектируют как набор экранов: пользователи, заявки, контент, настройки. На старте этого хватает. Сложности начинаются, когда те же действия нужно выполнять не только из браузера. Например, автоматически подготовить черновик статьи, получить список новых обращений или обновить статус пользователя по результатам проверки.
Если логика спрятана внутри страниц админки, для каждой интеграции приходится писать отдельный обходной путь. Такие решения быстро расходятся: форма проверяет одно, фоновый процесс — другое, а внешний сервис вообще пишет данные напрямую.
В AdminCore экран отвечает за удобство работы, но не владеет бизнес-логикой. Twig формирует представление, а чтение и изменение прикладных данных проходят через API-контроллер. Тот же контракт используют административная панель, внутренние процессы и авторизованные агенты.
API как общий рабочий язык
API-first в нашем случае — не модная подпись к архитектуре. Это практическое ограничение: контроллер страницы не обращается к базе, а загрузка файлов не происходит мимо предусмотренного метода. Правила проверки данных и доступа не приходится копировать между разными частями системы.
У такого подхода есть ещё один полезный эффект. Новый интерфейс можно заменить или расширить, не переписывая весь продукт. Мобильное приложение, кабинет клиента или служебный агент подключаются к уже существующим операциям. Если меняется формат ответа, это отражается в документации, а не обнаруживается случайно после обновления.
Что уже входит в ядро AdminCore
Сейчас в системе есть модули пользователей и заявок, редакционный раздел, управление авторами и категориями, медиатека, права доступа и API-ключи. Это не демонстрационные экраны: каждый раздел связан с API и следует общей модели разрешений.
Редакционный контур позволяет готовить статьи в визуальном редакторе, сохранять черновики, планировать публикацию и возвращаться к версиям материала. Для изображений хранятся не только файлы, но и содержательные alt-тексты, подписи и сведения об авторстве. Такой порядок важен и для доступности, и для нормальной подготовки страниц к поисковой индексации.
Модульность особенно заметна в больших продуктах, где рядом работают каталог, контент, пользователи и множество внутренних операций. В нашем кейсе разработки платформы LaLaZa хорошо видно, почему такие контуры лучше разделять заранее, а не после того, как система уже стала сложной.
Роли не должны превращаться в формальность
В проекте предусмотрены роли администратора, редактора, паблишера и рекламодателя. При этом роль пользователя на сайте не даёт ему доступ в AdminCore: административный вход предназначен для администраторов и редакторов.
Одного названия роли мало, поэтому доступ настраивается по модулям и действиям. Сотруднику можно разрешить просмотр определённого раздела, но закрыть редактирование или удаление. Редактору не нужен доступ к управлению ключами, а администратору не обязательно каждый день работать с публикациями.
API-ключи создают только администраторы. Для ключа задаётся точный набор методов, его можно отозвать, а секрет показывается один раз при создании. Даже ключ с широкими полномочиями не отменяет состояние и ограничения владельца. Так интеграция не превращается в бессрочный пропуск ко всей системе.
ИИ-агент — оператор с ограниченным доступом
Самая рискованная схема автоматизации выглядит просто: агенту дают прямой доступ к базе и просят «разобраться». Он действительно сможет сделать многое, в том числе то, чего от него не ожидали. В AdminCore агент работает так же, как другой клиент API. Он получает только необходимые методы и структурированные ответы.
Например, редакционный агент может подготовить материал, загрузить иллюстрацию и сохранить черновик. Для этого ему не требуется доступ к таблицам пользователей или настройкам ролей. Другому агенту можно разрешить читать новые заявки, но запретить их удаление и изменение учётных записей. По такому принципу мы проектируем услугу ИИ-агентов и автоматизации: полномочия должны соответствовать конкретной задаче.
Для агентов ведутся отдельные инструкции по работе с методами, а сам контракт описан в OpenAPI. Это снижает количество догадок: агент знает, какие поля обязательны, какой формат ожидается и что означает ошибка. Человеку при этом остаются редакционные и управленческие решения, которые не стоит принимать автоматически.
Какие модули подключаются под задачу
AdminCore не обещает, что любая CRM, сквозная аналитика или партнёрская программа уже включена одной галочкой. Такие контуры зависят от процессов конкретной компании. Сначала нужно определить источник данных, статусы, правила дедупликации и границы ответственности, а затем добавлять методы и интерфейсы.
Поэтому интеграции с CRM и 1С, атрибуция рекламных обращений, партнёрские ссылки или антифрод рассматриваются как отдельные модули. Они подключаются к общей системе доступа, но не смешиваются с ядром. Подробнее о том, как мы проектируем учёт заявок, интеграции с CRM и рекламную аналитику, рассказываем в отдельном материале.
Как появляется новая функция
Работа начинается не с макета экрана. Сначала мы описываем действие: кто его выполняет, какие данные нужны, что можно изменить и какой результат должен вернуть API. Затем определяем права, добавляем метод в контракт и только после этого собираем интерфейс.
Такой порядок кажется более медленным лишь в первые дни. Зато при следующем расширении уже не приходится выяснять, почему кнопка в админке работает иначе, чем импорт или фоновая задача. Веб-интерфейс, интеграции и агенты опираются на одни правила.
В результате AdminCore остаётся управляемым по мере роста проекта. Новые разделы не получают скрытый доступ к данным, а автоматизация не зависит от того, открыт ли у сотрудника браузер. Если вашему продукту нужна административная система с понятными ролями, API и возможностью постепенно подключать ИИ-агентов, задачу можно обсудить с командой WowCash.