Что умеет ИИ-агент Интеграма, когда собирает приложение

В двух предыдущих заметках мы смотрели на ИИ-агента с высоты птичьего полёта: как рождается приложение и кто принимает проектные решения. Эта статья — про другое: что конкретно агент собирает внутри приложения. Вы даёте тематику, эксели и пару фраз про боль — а на выходе получаете не «каркас», а работающую систему со структурой, ролями, данными и фирменным оформлением.

Агент действует не наугад: он следует рабочему регламенту integram-app-workflow.md — пошаговой инструкции, которая ведёт его от пустой базы до запущенного приложения. Ниже — экскурсия по слоям, которые агент строит, в том порядке, в каком он за них берётся.

1. Структура данных

Это фундамент. Агент разбирает ваши эксели, определяет домен (производство, услуги, торговля, расписание) и проектирует таблицы, поля и связи по лучшим практикам — не спрашивая вас, «какие поля завести».

Таблицы и поля. Каждый файл или лист — кандидат в таблицу, каждая колонка — кандидат в поле. Агент знает правила хорошей схемы: имена таблиц в единственном числе и по-русски («Заказ», «Сырьё», а не «Orders»); первая колонка таблицы — это и есть «имя записи» (номер заказа, название сырья), поэтому отдельное поле «Название» не плодится. Для каждого поля подбирается тип: короткий текст, число, дата и время, да/нет, большой текст-описание, файл-вложение, пароль.

Два типа связей — и почему это важно. В Интеграме между таблицами бывает ровно два вида связи, и перепутать их — самая дорогая ошибка проектирования:

• Ссылка (справочник) — указатель на одну переиспользуемую запись. Один клиент привязан ко множеству заказов; один статус «Новый» — к сотням записей.
• Подчинённая таблица — набор записей, целиком принадлежащих одному родителю. «Позиции заказа» существуют только внутри своего заказа.

Агент определяет тип каждой связи по чек-листу (переиспользуется ли запись? живёт ли сама по себе?), а после создания сам сверяется с метаданными базы — действительно ли получилась ссылка, а не подчинённая таблица. Для человека это различие разобрано в отдельной заметке: «Как отличить подчинённую таблицу от справочника».

2. Тестовые данные

Пустое приложение невозможно показать заказчику — экраны выглядят сломанными, пока в них нет ни одной строки. Поэтому агент наполняет каждую таблицу осмысленными демо-записями: несколько видов сырья с разными остатками, заказы от разных клиентов с разными датами и статусами, позиции внутри заказов, события в работе на всех стадиях («Ожидает → В работе → Завершён»).

Цель — чтобы каждый экран сразу показывал реальную картину, а вы могли кликать по приложению и видеть, как оно работает, а не воображать это по пустым таблицам. Перед массовой загрузкой в непустую базу агент сначала делает резервную копию — наполнение не должно затереть ценные данные.

3. Роли, права и пользователи

Дальше агент закрывает доступ. Он заводит типовые роли под ваш домен (для производства — менеджер / оператор / руководитель, для услуг — администратор / мастер), создаёт под них пользователей и разграничивает доступ тремя независимыми механизмами:

Механизм	Что ограничивает
Пункты меню	что видно в интерфейсе роли — какие рабочие места ей доступны
Права на объекты	к каким таблицам и отчётам есть доступ и на каком уровне
Маска доступа	какие именно строки внутри доступных таблиц видит конкретный пользователь

Уровни доступа — WRITE (создавать, менять, удалять), READ (только чтение) и BARRED (полный запрет: объект не вернётся даже в ответе API). Уровень наследуется от таблицы к её колонкам, поэтому отдельным чувствительным полям (например, финансовым) можно понизить доступ, не трогая остальные. Отдельными флагами включается выгрузка и удаление — можно разрешить редактирование, но запретить экспорт.

Маска решает задачу «менеджер видит только своих клиентов»: условие вроде Ответственный = [CURRENT_USER] сервер применяет ко всем запросам — и к таблицам, и к отчётам, и к API, — поэтому обойти её через экспорт нельзя. Для приёма заявок с лендинга есть встроенная гостевая роль: заявитель не видит внутренних таблиц и чужих заявок.

Есть и тонкий слой — защита данных запросами: запрос всегда выполняется с правами владельца, поэтому поле, закрытое для роли на редактирование, всё равно можно менять строго определённым действием (например, сменить статус заказа кнопкой), не открывая роли полный доступ к таблице.

Отдельно стоит супер-пользователь базы — технический администратор с логином, равным имени базы. Его создаёт сервер автоматически при создании базы, у него полный доступ ко всей структуре и шаблонам, и трогать его нельзя. Все роли, которые заводит агент, — это бизнес-доступ поверх него.

4. Рабочие места (экраны)

Интерфейс приложения — это HTML/JS-страницы, которые агент собирает под типовой пользовательский путь домена: журнал записей с фильтрами, карточка с деталями и сменой статуса, диспетчер со сводкой по стадиям, пульт исполнителя. Даже если в задании об этом не сказано, агент добавляет минимум один дашборд со сводной информацией — это «лицо» приложения, по которому заказчик первым делом судит о системе.

Экраны читают данные гибко: они опираются на стабильные идентификаторы колонок, поэтому переживают аддитивные изменения схемы — добавили поле, ничего не сломалось.

5. Фирменный стиль (темы и бренд)

Визуальная составляющая для заказчика важна не меньше функциональности, и агент относится к ней всерьёз. Главное правило: если у компании есть корпоративный стиль — применять его, а не выдумывать свою палитру.

Что агент берёт из бренда клиента и куда применяет:

• Логотип — с сайта или из присланных материалов, предпочтительно в SVG (чёткий на любом экране); кладётся в файловое хранилище базы.
• Фирменные цвета — основной, акцентный, фон и текст — выносятся в CSS-переменные, чтобы менять палитру в одном месте и держать единый стиль на всех экранах.
• Шрифты и общая стилистика — по образцу сайта компании.

Бренд (логотип и цвета) заменяет собой верхнее меню приложения — фирменная шапка вместо стандартной, без дублирования. Приложение поддерживает светлую и тёмную тему, и агент следит за контрастом: когда шапку перекрашивают в тёмный фирменный цвет, все кнопки и подписи в ней должны остаться читаемыми — это проверяется автоматическим тестом и скриншотом на десктопе и мобильном. Если фирменного стиля нет — агент применяет аккуратное нейтральное оформление, а не случайный «яркий» дизайн.

6. Проверка: тест-план по всему пути

Собрать — половина дела; агент ещё и прогоняет приложение по полному пользовательскому пути, прежде чем отдать его вам. По чек-листу проверяется, что:

• каждый экран открывается и показывает данные, связи между таблицами работают;
• под каждой рабочей ролью (а не под админом) видна кнопка создания, а клик по строке открывает редактирование;
• справочные поля меняются прямо из интерфейса (статус — кликом по статусу);
• роль-владелец может через рабочее место «Пользователи и доступ» завести сотрудника, сменить ему роль и лишить конкретного человека доступа;
• есть дашборд и работает поиск по фильтрам.

7. Безопасность и изоляция

Поверх всего — жёсткие правила. Каждая база полностью изолирована: агент работает строго в одной вашей базе по выданному токену и не имеет доступа к чужим. Перед любым необратимым действием (удаление записей, изменение схемы, массовая загрузка) он сначала делает бэкап. Секреты — пароли и токены — он использует для работы, но не собирает в списки и не выгружает наружу.

Итог

ИИ-агент собирает не фрагмент, а законченное приложение по слоям: структура данных → тестовые данные → роли и права → рабочие места → фирменный стиль → проверка. Ориентир регламента — 89% функционала готово после первой итерации, остальное вы дозапрашиваете по ходу. Это и есть 100% кастомизация лучших практик: типовое проверенное решение для вашего домена, сразу подогнанное под ваш бизнес — без раундов согласований и без рамок готовой коробки.

А ваша роль остаётся прежней и самой ценной — точно сформулировать предметную область. Остальное регламент отдаёт агенту.