Codex-generated pull request

docs/modules/module-rebuild-plan.md

@@ -189,6 +189,71 @@ tags = ["community"]
 в сборку; если подключён — сборка автоматически тянет нужные UI‑пакеты вместе
 с серверной частью.
 
+### 6.4.1 Эталонная реализация модуля (полная версия с таблицами)
+
+Чтобы сторонние разработчики могли повторять процесс без догадок, нужен
+**эталонный модуль** с максимально полным набором частей: server + admin UI +
+storefront UI. В качестве образца стоит взять **самый полный серверный модуль**
+— то есть с таблицами, миграциями, CRUD, событиями и настройками.
+
+Рекомендуемый состав и структура (монорепо‑формат, всё в одной папке модуля):
+
+```
+modules/rustok-catalog/
+├─ crates/
+│  ├─ catalog-server/          # Rust crate: таблицы, сущности, сервисы, GraphQL/REST
+│  ├─ catalog-migrations/      # Rust crate: миграции SeaORM
+│  └─ catalog-events/          # Rust crate: доменные события (если выделяются отдельно)
+├─ admin/
+│  ├─ next/                    # npm пакет для apps/next-admin
+│  └─ leptos/                  # Rust crate для apps/admin (Leptos UI)
+├─ storefront/
+│  ├─ next/                    # npm пакет для apps/next-frontend
+│  └─ leptos/                  # Rust crate для apps/storefront (Leptos UI)
+├─ module.toml                 # metadata/compatibility для marketplace
+└─ README.md                   # краткая инструкция по локальной сборке/тестам
+```
+
+Минимальный функционал в эталонном серверном модуле:
+- **Таблицы и миграции** (SeaORM), валидный MigrationSource.
+- **Entities/DTO/Services** для CRUD.
+- **События** (event publish) + outbox/transport.
+- **Регистрация в ModuleRegistry** и зависимости.
+- **Настройки модуля** (settings payload + schema).
+- **API слой**: GraphQL/REST контракты для UI‑пакетов.
+- **Сквозной пример фичи**: одна сущность, которая проходит через API → UI →
+  сохранение → события (чтобы быстро понять end‑to‑end поток).
+- **Готовые шаблоны** для UI‑пакетов (Leptos + Next): формы, списки, empty‑state.
+- **Быстрый старт**: короткий чек‑лист (создать/переименовать модуль, обновить
+  manifest, запустить локальную сборку).
+
+Дополнительно, чтобы модуль был максимально полезен внешним разработчикам:
+- **Документация по структуре**: где менять схему БД, где API, где UI.
+- **Минимальные тестовые сценарии** (ручные steps): без отдельной папки тестов,
+  но с чёткими шагами проверки для локального окружения.
+- **Локальный DX/скрипты**: набор команд для запуска server/admin/storefront в
+  dev‑режиме, единая точка входа (Makefile/justfile) и пример `.env`.
+- **Демо‑данные**: сиды для быстрой проверки UI и энд‑ту‑энд флоу.
+- **Контракт версий**: правила совместимости server/admin/storefront и пример
+  диапазонов (semver/compat section).
+- **Схема `module.toml`**: явные поля для server/admin/storefront пакетов,
+  чтобы сборка могла детерминированно подтянуть все части.
+- **Публикация и релиз**: как выпускать модуль (теги/версии), и как сборка
+  выбирает нужную версию из marketplace.
+- **Миграции**: как модуль подключает MigrationSource и когда миграции
+  исполняются в пайплайне (build/deploy).
+- **RBAC для UI**: стандартные guard-правила для админки/витрины.
+- **Event contract**: минимальный набор метаданных в событиях для совместимости
+  со шиной и read-моделями.
+- **Observability**: метрики/логи/трейсы и минимальный dashboard для модуля.
+- **I18n/локализация**: правила для строк UI и переводов.
+- **Security‑практики**: обработка прав, валидация входных данных, запреты на
+  небезопасные операции в фоне/скриптах.
+
+Задача эталонного модуля — показать полный end‑to‑end путь:
+manifest → registry → UI‑пакеты → build → deploy.
+Это критично для внешних разработчиков и для маркетплейса.
+
 ### 6.5 Надёжный механизм установки и сборки по команде бэкенда
 
 Цель — сделать **детерминированный** и **безопасный** контур, где бэкенд