Live Robot

Документ фиксирует согласованные требования на текущем этапе.

1) Границы маршрутизации и шаблонов (зафиксировано)

• Поддерживаются 2 зоны:
  • site/* — фронт
  • site/admin/* — админка (менеджер/администратор)

Зона	Shell (header, stick, nav)	Сетка карточек
0–479	1 колонка, stick скрыт/overlay	1 колонка (minmax)
480+	—	до 2 колонок автоматически
768+	stick fixed, боковые блоки	3–4 колонки
1024+	основной desktop layout	~5 колонок в .container
1440+	full‑bleed фон	без изменений (cap 1432)

2) Совместимость с БД

• Новая система не меняет существующие имена таблиц/полей/типов.
• Цель: полная обратная совместимость с текущей БД diy_crm.
• При изменениях применять только совместимые доработки (без ломающих переименований).

3) Типы модулей

Разрешённые типы модулей:

• frontend
• backend
• service
• widget

4) Обязательный минимум таблиц (ядро)

Обязательные таблицы:

• crm_user
• crm_materials
• crm_page_modules
• crm_images
• crm_delivery
• crm_payment
• crm_products
• crm_sales
• crm_sale_items
• crm_sale_status

Важно: используется фактическое имя crm_sale_items (не crm_sales_items).

5) Стартовые материалы в crm_materials

Минимально необходимые записи (зафиксированы по текущему дампу trio_crm.sql):

• index → FrontendPageModule
• login → FrontendLoginModule
• register → FrontendLoginModule
• forgot → FrontendLoginModule
• 404 → FrontendPageModule
• dashboard → AdminSettingsModule
• cabinet → AdminCabinetModule
• setup → AdminSetupModule
• demo → FrontendPageModule

Примечание: в текущей схеме url хранится как slug без префикса admin, зона определяется роутером.

6) Модули: выполнено и запланировано

Выполнено

• FrontendPageModule
• FrontendLoginModule
• FrontendBlogModule
• AdminSettingsModule
• AdminMaterialsModule
• AdminMenuModule
• AdminBlogModule
• AdminSetupModule
• WidgetMenuModule
• WidgetSwitcherModule

Запланировано

• AdminOrdersModule
• AdminProductsModule
• AdminCategoriesModule

Примечание: отдельный AdminPageModule не планируется, так как редактирование материалов страниц уже реализовано через AdminMaterialsModule.

7) Структура каталогов модулей

• modules/frontend/*
• modules/backend/*
• modules/service/*
• modules/widget/*

8) Архитектурный roadmap (следующий этап)

Components

Базовые доменные компоненты:

• Catalog
• Order
• Blog
• User
• Integration (платежи/доставка/внешние интеграции)

Plugins

Минимум 5 событий:

• order.created
• order.status.changed
• comment.created
• ttn.checked
• user.registered

Plugins: этап внедрения (зафиксировано)

Внедрение выполняется поэтапно, чтобы избежать перегрузки и упростить отладку.

Этап 1 (реализовано)

• Ввести базовый PluginManager (register/dispatch, без усложнений).
• Подключить события:
  • order.created
  • order.status.changed
  • user.registered
• Реализовать плагины:
  • AuditLogPlugin
  • OrderStatusNotifyPlugin
  • UserRegisteredNotifyPlugin

Статус: каркас реализован (PluginManager, config/plugins.php, плагины, подключение в DI и Application).

Этап 2 (после стабилизации)

• OrderCreatedTelegramPlugin для order.created.
• StockReservePlugin для order.created и/или order.status.changed.
• DeliveryStatusSyncPlugin для ttn.checked.

Этап 3 (после запуска блога/комментариев)

• CommentModerationPlugin для comment.created.
• CommentNotifyPlugin для comment.created.

Правила производительности и надежности

• Не добавлять тяжёлые внешние запросы в критический путь без таймаутов.
• Ошибки плагинов логировать, не ломая основной сценарий (кроме явно критичных кейсов).
• Внедрять плагины по одному с коротким циклом наблюдения.

Тест в бою (обязательно)

• После Этапа 1 — наблюдение 5–7 дней:
  • ошибки в логах по событиям/плагинам;
  • задержка пользовательских сценариев (создание заказа, смена статуса);
  • корректность уведомлений и аудит-следа.
• При стабильной работе — переход к Этапу 2.

Helpers

• 8–10 утилитных helper-функций (format/date/slug/url/image/text и т.д.).

9) Стандарт форм в админке

• Для create/edit форм backend-модулей использовать universalform.js:
  • форма с классом ajax-form
  • блок .form-message внутри формы
  • JSON-ответы success/error
  • при необходимости redirect в JSON
  • сохранять fallback для обычного POST

---

Статус документа: актуален на текущий этап разработки v3.