Техническое задание

Программный комплекс «ДелаЮ» (платформа «Дела.ЮГИт»)

Правообладатель / разработчик	ЮГИт
Версия документа	2.2 (черновик)
Дата	27.05.2026
Статус	Утверждено к реализации (этап 0–1)

---

1. Бренд и позиционирование

Элемент	Значение
Наименование	ДелаЮ
Линейка / платформа	Дела.ЮГИт (дела на платформе ЮГИт)
Разработчик / правообладатель	ЮГИт
Основной слоган	«Дела под контролем — ДелаЮ»
Короткий слоган (логотип)	Веду дела — ДелаЮ
Этап разработки	Сначала платформа (ядро + каталог модулей); отраслевые подсистемы — по опыту внедрения, отдельными ТЗ

1.1. Варианты слоганов (на выбор заказчика и маркетинга)

№	Слоган	Акцент
★1	Дела под контролем — ДелаЮ	Контроль, сроки, прозрачность
2	От заявки до архива — без потерь	Полный цикл
3	Одна платформа. Все дела. Вся команда.	Единое пространство
4	Умные процессы. Честные сроки. ЮГИт.	ИИ + надёжность вендора
5	Веду дела — ДелаЮ	Классика, запоминается
6	Государственный масштаб. Человеческий интерфейс.	ОМСУ / госсектор

Рекомендация: в коммуникации использовать ★1 на сайте и в презентациях, №5 — в визитке и подписи к логотипу.

---

2. Назначение и описание продукта

2.1. Одно предложение (elevator pitch)

ДелаЮ — отечественная модульная платформа ЮГИт, где обращения, дела, документы, согласования и отчёты ведутся в одном контуре: от регистрации входящего письма до архива и аналитики для руководителя.

2.2. Описание для сайта и презентации

ДелаЮ помогает организации не терять информацию и не срывать сроки. Сотрудник работает в личном кабинете: календарь, канбан задач, дела и реестры, переписка и документы. Руководитель видит дашборды, просрочки и качество исполнения. Администратор собирает подсистему под контур заказчика и включает только нужные модули из каталога (включая блок из 20+ ИИ-сервисов).

Платформа закрывает цепочку: входящая корреспонденция → исполнение по бизнес-процессу → ЭП и печатные формы → архив (в т.ч. аудиозаписей) → отчётность и интеграции с внешними ИС. Всё с ролевой моделью, аудитом и размещением в инфраструктуре заказчика (PostgreSQL, Docker, облако РФ / on-premise).

2.3. Описание для реестра ПО и закупки (официально)

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

Область применения: органы государственной власти и местного самоуправления, муниципальные и казённые учреждения, коммерческие организации.

Архитектура: модульная; поставка в виде подсистем (отраслевых конфигураций) на едином ядре. Каталог — 86 функциональных модулей (раздел 6.7–6.8), из них 20 модулей ИИ (M47–M66).

2.4. Техническая суть (для ТЗ)

Платформа поставляется как единое техническое ядро с каталогом функциональных модулей (M01–M86) и одной или несколькими подсистемами. Подсистема задаёт включённые модули, меню, реестры, организации и матрицу доступа для конкретного заказчика (муниципалитет, ведомство, холдинг).

Целевые потребители: органы власти и подведомственные учреждения, муниципальные и казённые организации, коммерческие структуры (B2B).

---

3. Термины и определения

Термин	Определение
Платформа «ДелаЮ»	Программный комплекс целиком: ядро, общие сервисы, администрирование, API.
Подсистема	Развёрнутая конфигурация платформы для конкретного заказчика/контура: набор модулей, меню, реестров, организаций и политик доступа.
Не отдельный продукт «с нуля», а настроенный контур на общем ядре. Примеры: пилотные контуры коммерции и госзаказиков.
Модуль	Законченная функциональная область платформы (учёт пользователей, документы, архив и т.д.), включаемая или отключаемая в составе подсистемы.
Реестр	Унифицированный справочник/перечень однотипных записей (граждане, объекты, договоры и др.) с настраиваемой структурой полей.
Дело / заявление	Учётная единица процесса: карточка с жизненным циклом, документами, сроками, исполнителем.
Организация	Юридическое или структурное подразделение в контуре подсистемы (мультитенантность).
Структура (ШР)	Кадрово-штатная и организационная иерархия: подразделения, должности, привязка пользователей.
Роль	Набор прав на действия и данные в рамках подсистемы.
Пользователь	Учётная запись сотрудника, допущенного к подсистеме и организациям.

---

4. Цели создания системы

1. Единое рабочее место — учёт, документы, сроки и отчёты без разрозненных файлов и таблиц.
2. Управляемость — централизованная настройка подсистем, модулей, ролей и реестров администратором.
3. Прозрачность — фиксация действий пользователей, версий документов, истории изменений.
4. Масштабируемость — подключение новых отраслевых подсистем и модулей без замены платформы.
5. Соответствие требованиям заказчика — в т.ч. по ПДн, размещению в инфраструктуре РФ, отечественному стеку (по согласованию).

---

5. Состав системы (логическая архитектура)

┌────────────────────────────────────────────────────────────────────┐
│                    Платформа «ДелаЮ» (ядро)                        │
├────────────────────────────────────────────────────────────────────┤
│  Администрирование │ Безопасность │ Аудит │ Интеграции │ Отчёты    │
├──────────┬──────────┬──────────┬──────────┬──────────┬─────────────┤
│ Подсист. │  Роли    │Пользова- │ Структура│Документы │ Архив       │
│ (конфиг.)│          │  тели    │  (ШР)    │          │             │
├──────────┴│─────────┴──────│───┴──────────┴──────────┴─────────────┤
│    Модули ->   матрица     ->     Отраслевые реестры и             │
│           │    доступа     │      процессы (в составе подсистемы)  │
└───────────│────────────────│───────────────────────────────────────┘

Уровни:

Уровень	Назначение	Пользователи
Платформа	Управление подсистемами, глобальными модулями, лицензированием, мониторингом	Администратор платформы, вендор (ЮГИт)
Подсистема	Организации, пользователи, роли, реестры, меню, отчёты в контуре заказчика	Администратор подсистемы, руководитель
Рабочее место	Ежедневная работа: дела, документы, задачи, реестры	Специалист, регистратор, контролёр

---

6. Функциональные модули платформы

Каталог: 86 модулей (M01–M86): 6 модулей ядра (п. 6.1–6.6) + 60 расширенных (п. 6.7) + 20 дополнительных (п. 6.8).
Подсистема подключает модули из каталога по матрице «модуль × подсистема». Отраслевые реестры и процессы — надстройка над ядром (раздел 7), создаются после стабилизации платформы.

6.1. Подсистемы и каталог (M01)

Назначение: создание и сопровождение изолированных контуров на едином ядре: модули, бренд, организации, роли, аудит.

6.1.1. Модель данных

Сущность	Атрибуты / связи
Subsystem	код, наименование, описание, статус (draft / active / archived), цвет бренда, шаблон отрасли, метка версии, дата публикации
SubsystemModule	матрица «подсистема × модуль каталога», флаг enabled
ModuleCatalog	M01–M86: код, название, группа, признак ядра, порядок (справочник платформы, не редактируется в контуре заказчика)
AuditLog	действие, пользователь, подсистема, объект, payload JSON, IP, время

6.1.2. Интерфейс

Экран	Поведение
Подсистемы	список контуров; popup-карточка: сводка, матрица модулей, публикация, архив; клонирование
Мастер создания	3 шага (bs-stepper): (1) контур и отрасль, (2) выбор модулей по группам каталога, (3) версия и публикация; автоматическое создание головной организации, ролей и членства администратора
Каталог модулей	просмотр M01–M86, фильтр по группе и поиск, popup с описанием и списком подсистем, где модуль включён
Журнал аудита	список событий активной подсистемы, фильтр по действию, popup с JSON payload

6.1.3. Жизненный цикл конфигурации

1. Черновик — настройка модулей и реквизитов.
2. Публикация — статус «Действует», фиксация published_at и метки версии; запись в AuditLog.
3. Архив — контур выводится из эксплуатации без удаления данных.

Клонирование: новый код/имя, копия включённых модулей и организаций, статус «Черновик».

6.1.4. Критерии приёмки M01

1. Мастер создаёт подсистему с выбранными модулями; создатель получает членство администратора.
2. В карточке переключаются модули матрицы; изменения фиксируются в аудите.
3. Черновик публикуется одной операцией.
4. Каталог отображает 86 модулей с фильтрацией.
5. Журнал аудита показывает детали записи в popup.

Этап 2: визуальный конструктор меню, политики данных по реестрам, сравнение версий конфигурации.

Результат для заказчика: отдельный брендированный контур без дублирования кода платформы.

---

6.2. Роли пользователей (M02)

Назначение: разграничение доступа к модулям и административным функциям в рамках активной подсистемы; права не дублируются в прикладных модулях.

6.2.1. Модель данных

Сущность	Атрибуты
Role	код, наименование, описание, признак системной роли
RoleModulePermission	роль × модуль: can_view, can_create, can_change, can_delete

Матрица строится только по модулям, включённым в подсистеме (M01 → SubsystemModule.enabled).

6.2.2. Интерфейс

Экран	Поведение
Список ролей	код, название, число пользователей, тип; действия: карточка, редактирование, копирование, удаление
Карточка	popup: описание, таблица назначенных прав; кнопка «Редактировать»
Создание	мастер из 2 шагов (bs-stepper): (1) реквизиты роли, (2) матрица прав по включённым модулям
Копирование	popup: новый код и имя; копируются все RoleModulePermission

6.2.3. Правила

• системные роли (is_system) нельзя удалить;
• роль с назначенными пользователями (SubsystemMembership) нельзя удалить;
• копирование и создание — M02 / can_create; редактирование матрицы — can_change.

6.2.4. Критерии приёмки M02

1. Администратор создаёт роль через мастер; права сохраняются в матрице.
2. Карточка показывает сводку прав; редактирование обновляет матрицу.
3. Копия роли получает те же права при новом коде.
4. Удаление заблокировано для системных ролей и ролей с пользователями.

Этап 2: права на тип дела/реестр, экспорт, наследование между подсистемами.

Ограничение: права оцениваются в контексте активной подсистемы и организации пользователя.

---

6.3. Пользователи (M03)

Назначение: централизованный учёт сотрудников, допуск к подсистемам и организациям, ведение расширенной кадрово-контактной карточки в рамках платформы (без дублирования полноценной кадровой системы M04).

Обоснование объёма данных: для согласований, маршрутов BPM, отчётности и интеграций недостаточно пары полей «ФИО + e-mail»; карточка пользователя должна содержать не менее 30 атрибутов (учётная запись + профиль), сгруппированных для просмотра и редактирования.

6.3.1. Каталог атрибутов (минимум 30)

Группа	Атрибуты
Учётная запись	логин, рабочий e-mail, признак «активен», дата последнего входа
ФИО и личные	фамилия, имя, отчество, пол, дата рождения, СНИЛС, ИНН
Паспорт	серия, номер, кем выдан, дата выдачи
Контакты	телефон основной, мобильный, рабочий, внутренний, личный e-mail, Telegram
Адреса	регистрация, проживание
Работа	личный/табельный №, должность (текст), тип занятости, даты приёма/увольнения, подразделение (текст), руководитель
Система	часовой пояс, язык интерфейса, принудительная смена пароля, 2FA (флаг), примечание
Допуск	организация + роль в активной подсистеме (членство SubsystemMembership)

Связь с M04: текстовые поля «подразделение/должность» допускаются до внедрения штатного расписания; после M04 — синхронизация с Department / штатной единицей (этап 2).

6.3.2. Интерфейс (Materialize)

Экран	Поведение
Список	таблица пользователей подсистемы; панель действий: «Добавить» (при can_create), в строке — просмотр карточки, редактирование, блокировка
Карточка	модальное окно (modal-xl), просмотр по группам (accordion); редактирование — та же модалка, форма POST
Создание	пошаговый мастер (4 шага, bs-stepper, как form_wizard_numbered в шаблоне Materialize): (1) учётная запись, (2) личные и паспорт, (3) контакты и адреса, (4) работа и назначение роли/организации; финальная отправка — один POST, создание User + UserProfile + SubsystemMembership

6.3.3. Операции и права

• Просмотр — M03 / can_view;
• Создание — мастер, can_create;
• Изменение — карточка/форма, can_change (в т.ч. смена пароля администратором);
• Блокировка — is_active=False, can_delete (самоблокировка запрещена);
• разблокировка, журнал сессий, SSO, делегирование — этап 2 (отдельные подпункты ТЗ).

6.3.4. Критерии приёмки M03

1. Администратор создаёт пользователя через 4-шаговый мастер; пользователь появляется в списке с назначенной ролью и организацией.
2. Карточка открывается в popup и отображает все группы атрибутов (≥30 полей).
3. Редактирование сохраняет изменения без перезагрузки всего раздела (допустим redirect с авто-открытием карточки).
4. Блокировка скрывает доступ (логин отклоняется); кнопка недоступна для текущего пользователя.
5. Пользователь без can_create не видит кнопку «Добавить».

---

6.4. Структура (M04)

Назначение: организационно-штатная структура для маршрутов BPM, согласований и привязки сотрудников к подразделениям.

6.4.1. Модель данных

Сущность	Назначение
Organization	юридический/учётный контур в подсистеме
Department	дерево подразделений (parent), код, наименование, руководитель (manager)
Position	штатная единица: код, наименование, число ставок (headcount)
UserAssignment	связь пользователь ↔ подразделение ↔ должность

6.4.2. Интерфейс

Экран	Поведение
Дерево	таблица с отступами по уровню; переключатель организации (если несколько); счётчики должностей и назначений
Подразделение	форма создания; popup: реквизиты, список должностей и назначений
Редактирование	popup: изменение реквизитов, добавление должности, назначение сотрудника на должность
Должность	popup: просмотр/редактирование ставки; удаление, если нет назначений

6.4.3. Правила

• удаление подразделения запрещено при наличии дочерних узлов или должностей;
• удаление должности запрещено при наличии UserAssignment;
• операции — по правам M04 (can_create / can_change / can_delete).

6.4.4. Критерии приёмки M04

1. Создано подразделение с родителем и руководителем; отображается в дереве.
2. В подразделение добавлена должность с числом ставок.
3. Сотрудник назначен на должность; отображается в карточке подразделения.
4. Связь с M03: поля «подразделение/должность (текст)» в профиле дополняются, но не заменяют M04.

Этап 2: синхронизация с внешней кадровой системой, использование в маршрутах BPM «руководитель отдела».

Связь: организация — контур; подразделение — иерархия внутри организации.

---

6.5. Документы (M05)

Назначение: единое хранилище файлов подсистемы с версионностью, привязкой к делам и демо-подписью; основа для СЭД (M24–M30) и шаблонов (этап 2).

6.5.1. Модель данных

Поле / сущность	Назначение
DocumentFile	файл, метаданные, тип (attachment, incoming, outgoing, …)
root_document	связь версий с корневой записью
version, is_current	нумерация; в реестре — только актуальные
case	опциональная привязка к делу (M22)
is_signed, signature_meta	демо электронной подписи

6.5.2. Интерфейс

Экран	Поведение
Реестр	таблица актуальных версий; фильтры: поиск, тип, ЭП; скачивание файла
Мастер загрузки	2 шага (bs-stepper): реквизиты + привязка к делу → файл
Карточка (popup)	метаданные, таблица версий, скачивание, новая версия, подпись, удаление цепочки
Ограничения	для архивного дела (M06): нет новых версий, подписи и удаления

6.5.3. Права

• Просмотр и скачивание — M05 / can_view;
• Загрузка и новая версия — can_create;
• Подпись — can_change;
• Удаление цепочки версий — can_delete;
• события — журнал аудита (M01).

6.5.4. Критерии приёмки M05

1. Документ загружается через мастер и отображается в реестре.
2. Вторая версия снимает флаг is_current с предыдущей.
3. Карточка показывает историю версий.
4. Подпись фиксируется в signature_meta (демо).
5. Для архивного дела операции изменения заблокированы.

Этап 2: шаблоны Word/PDF, сравнение версий, откат, Госключ, обязательность типов на этапах BPM.

---

6.6. Архив дел (M06)

Назначение: долгосрочное хранение завершённых дел с учётом сроков хранения, legal hold и ограничений на изменение; подготовка к выгрузке комплектов (этап 2).

6.6.1. Модель данных (дело)

Поле	Назначение
is_archived, archived_at	Признак и момент перевода в архив
archived_by	Пользователь, выполнивший архивирование
archive_reason	Текст основания / комментария
retention_until	Дата окончания срока хранения (пусто — «бессрочно» в смысле не задан срок в системе)
legal_hold	Запрет восстановления/«уничтожения» по регламенту (флаг)
status	При архивировании — archived

6.6.2. Интерфейс

Экран	Поведение
Реестр архива	таблица: номер, тема, дата архива, срок хранения, legal hold, число вложений; фильтры: поиск, legal hold, «срок ≤ 90 дней»; пагинация
Карточка в popup	сводка, основание, переключение legal hold, восстановление (если hold снят), ссылка на полную карточку дела, кнопка экспорта
Карточка дела	для неархивного — форма «В архив» (основание, срок в годах или бессрочно); для архивного — баннер, read-only комментарии, операции M06
Редактирование дела (M22)	недоступно для архивных записей (404 при прямом URL)

6.6.3. Права

• Просмотр архива и экспорт-заглушка — M06 / can_view;
• Архивирование с карточки дела, legal hold, восстановление — M06 / can_change;
• Все операции пишутся в журнал аудита (M01).

6.6.4. Критерии приёмки M06

1. Дело переводится в архив с основанием и сроком хранения (или без даты).
2. Архивный реестр фильтруется и открывает popup.
3. Legal hold блокирует восстановление до снятия флага.
4. Восстановление возвращает дело в работу (статус «Исполнено» как безопасное значение по умолчанию).
5. Экспорт формирует техническую заглушку с записью в аудите.

Этап 2: типы дел и нормативные сроки, уничтожение по истечении срока, ZIP/PDF комплект, интеграция с ГАИС.

---

6.7. Каталог модулей (M07–M66)

60 модулей, включаемых в подсистему по требованию заказчика. Код M — единая нумерация для матрицы лицензирования, меню и прав доступа.

A. Рабочее место и продуктивность (M07–M14)

Код	Модуль	Назначение
M07	Личный кабинет пользователя	Профиль, настройки, активные подсистемы, быстрый доступ к задачам и уведомлениям
M08	Рабочий стол «На сегодня»	Очередь задач, просрочки, входящие на исполнение
M09	Календарь задач и событий	Личный и общий календарь, служебные мероприятия, контрольные даты
M10	Канбан досок	Визуализация этапов: колонки статусов, drag-and-drop, WIP-лимиты
M11	Планировщик операций (диаграмма Ганта)	Сроки этапов проекта/дела, зависимости, критический путь
M12	Напоминания и подписки	Push/e-mail/in-app, эскалация при бездействии
M13	Избранное и быстрые фильтры	Закладки на реестры, сохранённые поиски
M14	Лента активности	Хронология действий по делам и документам, где участвует пользователь

6.7.A.1. Личный кабинет (M07)

Назначение: сводка для сотрудника: задачи, согласования BPM, уведомления, избранное, членства в подсистемах, базовые настройки профиля.

Экран	Поведение
Кабинет	виджеты-счётчики (открытые/просроченные задачи, непрочитанные уведомления, BPM); списки задач и уведомлений; закладки M13; форма часового пояса, языка, контактов
Popup задачи	загрузка карточки задачи по AJAX (общий с M08)

Права: просмотр — M07 / can_view; настройки — M07 / can_change. События настроек пишутся в ленту M14.

6.7.A.2. На сегодня (M08)

Экран	Поведение
Реестр задач	вкладки: сегодня, просроченные, неделя; завершение одной кнопкой; popup и полная форма редактирования
Создание/редактирование	поля: название, описание, исполнитель, срок, start_date, duration_days, приоритет, колонка канбана, дело

Права: CRUD по матрице M08. Создание/завершение — запись в ленту M14.

6.7.A.3. Календарь (M09)

FullCalendar: события из задач (start_date или due_date), цвет по приоритету, фильтр «все / мои», переход в карточку задачи.

6.7.A.4. Канбан (M10)

Колонки KanbanColumn, смена колонки (POST), при «Готово» — completed_at. Фильтр «все / мои». События переноса — M14.

6.7.A.5. Гант (M11)

Таблица задач с start_date/due_date и duration_days; вычисление gantt_end_date; фильтр «мои». Этап 2: зависимости, drag-resize, критический путь.

6.7.A.6. Уведомления (M12)

Поле	Назначение
level	info / warning / urgent
link	переход при «прочитано»

Реестр с фильтрами по уровню и непрочитанным; «прочитать все»; отметка одного уведомления.

6.7.A.7. Избранное (M13)

Favorite: label, url_path, icon_class, sort_order, привязка к подсистеме. SavedFilter: module_code, name, params (JSON). CRUD на одной странице.

6.7.A.8. Лента активности (M14)

ActivityEvent: verb, target_repr, module_code, link_path, actor, subsystem. Фильтры: модуль, «только мои», поиск по тексту.

Критерии приёмки M07–M14 (этап 1): меню содержит M11 и M13; кабинет показывает сводку; задачи создаются с датами для Ганта; канбан и календарь работают в подсистеме pilot; уведомления с уровнями; избранное и фильтры сохраняются; лента отображает события с кодом модуля.

B. Статистика, отчётность и качество (M15–M21)

Код	Модуль	Назначение
M15	KPI-дашборды и сводки	Виджеты: дела в работе, просрочки, нагрузка по людям и отделам
M16	Конструктор отчётов	Пользовательские отчёты, поля, группировки, сохранённые шаблоны
M17	Регламентированная отчётность	Формы для ОМСУ/ведомств, периоды, версии показателей
M18	Графики и визуализация	Диаграммы, тренды, сравнение периодов, drill-down
M19	Оценка качества обработки	Индикаторы полноты, возвраты, повторные обращения, SLA
M20	Мониторинг статусов и просрочек	Светофор, очереди риска, фильтры для контролёров
M21	Аналитика по подразделениям	Срезы по структуре (ШР), рейтинги исполнения

6.7.B.1. KPI-дашборды (M15)

Виджеты: дела в работе, просрочки, задачи, входящие, BPM. Графики ApexCharts: динамика дел за период (7/30/90 дн.), задачи по приоритету. Списки: статусы дел, нагрузка по исполнителям, топ просроченных.

Права: M15 / can_view.

6.7.B.2. Конструктор отчётов (M16)

Модель ReportTemplate: code, name, query_key, columns (JSON), report_kind, description, is_active, default_period_days. Запуск формирует ReportRun с result и period_label. UI: реестр шаблонов, popup, мастер создания, таблица результата, история запусков.

Ключи запросов (этап 1): cases_summary, correspondence_in, tasks_by_user, docs_by_type, bpm_pending, cases_trend.

Права: просмотр/запуск — can_view; создание шаблона — can_create.

6.7.B.3. Регламентированная отчётность (M17)

RegulatoryReportSubmission: form_code, form_name, period_label, version, status (черновик/сдано/принято), indicators (JSON). Черновик → сдача с фиксацией submitted_by/at.

6.7.B.4. Графики (M18)

Страница с тремя диаграммами (дела, задачи, корреспонденция), выбор периода. Этап 2: drill-down в реестры.

6.7.B.5. Качество (M19)

Индикаторы: заполненность исполнителя, входящие без дела, документы без ЭП, риск SLA, повторные обращения.

6.7.B.6. Мониторинг просрочек (M20)

Светофор (красный/жёлтый/зелёный) по делам и задачам; сортировка по риску.

6.7.B.7. Аналитика по подразделениям (M21)

Срез по Department + UserAssignment: открытые/просроченные/исполненные дела, рейтинг 0–100.

Критерии приёмки M15–M21: дашборд и графики отображаются в pilot; отчёт запускается и пишется в историю; регламентированная форма сохраняется и сдаётся; M21 показывает отделы при назначениях M04.

C. Дела, реестры и учёт (M22–M23)

Код	Модуль	Назначение
M22	Реестр дел (универсальный)	Карточка дела, статусы, исполнитель, связи, история
M23	Универсальные реестры (конфигуратор)	Настраиваемые справочники, поля, импорт, валидация

6.7.C.1. Реестр дел (M22)

Экран	Поведение
Реестр	фильтры: поиск, статус, исполнитель, приоритет, просрочка; пагинация; popup-карточка
Мастер (2 шага)	суть дела → исполнение (исполнитель, срок, приоритет, статус); автонумерация КОД-ГОД-NNNN
Карточка дела	документы, BPM, комментарии (M38), архив (M06), ИИ-сводка
Редактирование	только неархивные дела

Права: просмотр — M22/can_view (без change — только свои дела); создание/изменение — can_create/can_change. События в ленту M14.

6.7.C.2. Универсальные реестры (M23)

RegistryType: code, name, description, field_schema (JSON), is_active, sort_order.
RegistryRecord: data (JSON по схеме), organization, created_by.

Экран	Поведение
Типы реестров	список с числом записей, popup, редактор схемы
Записи	таблица по колонкам схемы; CRUD; popup; импорт JSON-массива

Права: CRUD по матрице M23. Валидация обязательных полей по схеме.

Критерии приёмки M22–M23: дело создаётся мастером и открывается в popup; фильтры реестра работают; тип реестра с JSON-схемой; записи добавляются и импортируются.

D. Первичный и внутренний документооборот (M24–M32)

Код	Модуль	Назначение
M24	Первичный документооборот (входящие)	Регистрация входящей корреспонденции, реквизиты, номер, дата
M25	Исходящая корреспонденция	Регистрация исходящих, связь с входящим, контроль отправки
M26	Журнал регистрации документов	Сквозной журнал, поиск, печать реестров
M27	Маршрутизация и переадресация	Передача между подразделениями, резолюции, история переадресаций
M28	Просмотр истории документа	Версии, кто и когда изменил, цепочка согласований
M29	Шаблоны печатных форм	Word/PDF, подстановка полей из карточки
M30	Работа с ЭП (КЭП/УКЭП)	Подписание, проверка, пакетное подписание, протокол
M31	Госключ и внешние каналы ЭП	Интеграция с Госключ/доверенными УЦ (по контуру заказчика)
M32	Сканирование и комплекты документов	Пакетная загрузка, комплектность, связь с делом

6.7.D.1. Входящие (M24)

Экран	Поведение
Реестр входящих	фильтры: поиск, статус; пагинация; popup-карточка
Регистрация	мастер: тема, отправитель, дата, исполнитель, дело, статус; автонумерация ВХ-ГОД-NNNN
Карточка	реквизиты, переадресация (M27), печать (M29), история (M28)

Права: M24 / can_view, can_create, can_change. Запись в журнал M26 и ленту M14.

6.7.D.2. Исходящие (M25)

Реестр исходящих с привязкой linked_incoming к входящему. Регистрация с автонумерацией ИСХ-ГОД-NNNN.

6.7.D.3. Журнал регистрации (M26)

Сквозной журнал всех направлений: фильтры поиск, направление, год; оператор из RegistrationJournalEntry.

6.7.D.4. Маршрутизация (M27)

CorrespondenceRoute: from_user, to_user, comment. Смена исполнителя и статуса «В работе»; событие в CorrespondenceEvent.

6.7.D.5. История (M28)

CorrespondenceEvent: registered, routed, status, linked, signed, version, comment. Экран версий документов дела.

6.7.D.6. Печатные формы (M29)

PrintTemplate: code, name, body с плейсхолдерами {{reg_number}}, {{subject}}, {{counterparty}}, {{reg_date}}. Предпросмотр и печать из браузера.

6.7.D.7. Электронная подпись (M30)

Центр подписания: список неподписанных DocumentFile, пакетное подписание (демо КЭП через sign_document). Точечная подпись — также M05.

6.7.D.8. Госключ (M31)

Заглушка интеграции с Госключ/УЦ; этап 2 — OAuth и проверка цепочки.

6.7.D.9. Сканирование (M32)

Пакетная загрузка файлов в дело (DocumentFile, тип SCAN). Множественный выбор файлов в форме.

Критерии приёмки M24–M32: входящее регистрируется с номером и журналом; исходящее связывается с входящим; переадресация фиксируется; история показывает события; шаблон печати рендерится; пакетное подписание и скан работают в pilot.

E. Бизнес-процессы (M33–M36)

Код	Модуль	Назначение
M33	Конструктор бизнес-процессов	Моделирование BPMN, этапы, ветвления, таймеры
M34	Исполнение маршрутов согласования	Задачи согласующим, «согласовано/отклонено», комментарии
M35	SLA и эскалации	Нормативы времени, автоматическое повышение при нарушении
M36	Регламентные сроки по типам дел	Календарь рабочих дней, переносы, обоснования

6.7.E.1. Конструктор BPM (M33)

BPMTemplate: code, name, description, steps (JSON: id, name, assignee_id), is_active.

Экран	Поведение
Шаблоны	реестр, popup, редактор JSON-шагов
Экземпляры	запущенные процессы по делам, фильтры
Запуск	выбор шаблона и дела → start_process

6.7.E.2. Согласования (M34)

Карточки задач BPMTask (pending); экран решения: согласовать/отклонить + комментарий; быстрое решение с карточки дела.

6.7.E.3. SLA (M35)

SLARule: code, name, hours_limit, escalate_to, is_active. Монитор: просрочки, зона риска, «застой», очередь BPM.

6.7.E.4. Регламенты (M36)

CaseRegulation: default_working_days, applies_on_status. Применение к делу устанавливает due_date.

Критерии приёмки M33–M36: шаблон с шагами создаётся; процесс запускается и проходит согласование; монитор SLA показывает метрики; регламент выставляет срок дела.

Интерактивный конфигуратор бизнес процессов (этап 2 — визуальный BPMN)

F. Чат и совместная работа (M37–M41)

Код	Модуль	Назначение
M37	Внутренний чат	Диалоги, группы по делу/проекту, вложения
M38	Комментарии к карточкам	Треды в деле, реестре, документе
M39	Упоминания и подписки на объекты	@сотрудник, уведомление об изменениях
M40	Видеосовещания (интеграция)	Ссылки на ВКС, протокол встречи
M41	Уведомления в мессенджеры	Telegram/Max и др. по шлюзу

6.7.F.1. Внутренний чат (M37)

ChatRoom: name, case, members M2M. ChatMessage: body, author. UI в стиле app-chat: список комнат-карточек, экран переписки с пузырями, @упоминания.

6.7.F.2. Комментарии (M38)

Comment: case/document, parent (треды). Хаб /comms/comments/; на карточке дела — треды и ссылка на хаб.

6.7.F.3. Упоминания и подписки (M39)

Mention + уведомление M12 при @username. ObjectSubscription на дело/документ — уведомление при новом комментарии.

6.7.F.4. Видеосовещания (M40)

VideoMeeting: title, meeting_url, scheduled_at, protocol_notes, case.

6.7.F.5. Мессенджеры (M41)

MessengerChannel: telegram/max, webhook_url (демо). Этап 2 — реальная доставка через M42.

Критерии приёмки M37–M41: чат с сообщениями; комментарий с @ создаёт Mention; подписка шлёт уведомление; ВКС с ссылкой; канал мессенджера в реестре.

G. Интеграции (M42–M45)

Код	Модуль	Назначение
M42	Модуль интеграций (шлюз)	Единая точка: очереди, ретраи, мониторинг обменов
M43	REST / OpenAPI	Публичное и внутреннее API, ключи, лимиты
M44	СМЭВ	Отправка/приём межведомственных сообщений
M45	Внешние ИС (ГИС ЖКХ, 1С, ERP, почта)	Коннекторы по адаптерам, маппинг полей

6.7.G.1. Шлюз интеграций (M42)

IntegrationEndpoint: code, name, endpoint_type, config (JSON), max_retries, is_active.
IntegrationMessage: direction, payload, status, retry_count, external_id.

Экран	Поведение
Шлюз	KPI: активные коннекторы, очередь, ошибки, отправлено за день
Коннекторы	CRUD, тестовая отправка
Журнал	фильтры, popup payload, повтор при ошибке

6.7.G.2. REST / OpenAPI (M43)

ApiClientKey: prefix, rate_limit. Страница спецификации, /api/v1/*, OpenAPI JSON.

6.7.G.3. СМЭВ (M44)

Коннекторы типа smev: отправка запроса, демо-приём ответа, журнал.

6.7.G.4. Внешние ИС (M45)

Типы external_1c, external_gis, mail; config.field_mapping; демо-синхронизация.

Критерии приёмки M42–M45: сообщение проходит очередь/ретрай; API-ключ создаётся; СМЭВ in/out в журнале; внешний коннектор с маппингом.

H. Архивы и долгосрочное хранение (M46)

Код	Модуль	Назначение
M46	Аудиоархив	Хранение записей звонков/совещаний, привязка к делу, поиск, прослушивание, сроки хранения

Документный архив — модуль ядра M06; аудиоархив M46 дополняет его для голосовых материалов.

6.7.H.1. Аудиоархив (M46)

AudioArchiveItem: title, file, source_type (call/meeting), duration_sec, transcript, case, recorded_at, retention_until.

Экран	Поведение
Реестр	KPI, фильтры, popup, плеер на карточке
Загрузка	привязка к делу, срок хранения
Транскрибация	M62, демо-текст в transcript

6.7.I.1. ИИ-хаб (M47–M66, этап 1)

Экран	Модули
Обзор	M47 hub, лимиты M66
Ассистент	M47, RAG по M61
Поиск	M48
Инструменты	M49–M56, M59, M60, M63
База знаний	M61 CRUD
Политики	M66, журнал AiRequestLog
OCR	M51 заглушка

Критерии приёмки M46–M66 (этап 1): аудио в реестре с транскриптом; ассистент и поиск работают; инструменты по делу; политика и журнал отображаются.

I. Искусственный интеллект (M47–M66) — 20 модулей

Код	Модуль	Назначение
M47	ИИ-ассистент (чат)	Ответы по регламентам и карточке дела в интерфейсе
M48	Семантический поиск	Поиск по смыслу в делах, документах, реестрах
M49	Классификация обращений	Автотип/тема/приоритет входящего
M50	Извлечение реквизитов (NER)	ФИО, адреса, даты, номера из сканов и PDF
M51	OCR документов	Распознавание сканов, черновик карточки
M52	Суммаризация дела	Краткая выжимка истории для руководителя
M53	Генерация проекта ответа	Черновик письма/решения по шаблону и контексту
M54	Проверка полноты дела	Чек-лист: чего не хватает до перевода на этап
M55	Прогноз сроков исполнения	Оценка даты завершения по истории аналогов
M56	Риск просрочки	Раннее предупреждение «красная зона»
M57	Дедупликация персон (ИИ)	Совпадения граждан/контрагентов в реестрах
M58	Аномалии в данных	Выбросы, противоречия, дубли записей
M59	Q&A по НПА и локальным актам	Вопросы по нормам с указанием источника
M60	Подсказка маршрута согласования	Рекомендация следующего шага BPM
M61	База знаний (RAG)	Индексация регламентов, инструкций, FAQ
M62	Транскрибация аудио/видео	Текст из записи + привязка к аудиоархиву (M46)
M63	Тональность обращения	Негатив/эскалация для приоритизации
M64	Автотегирование документов	Теги, тип, связь с делом
M65	Генерация пояснений к отчётам	Текстовый комментарий к цифрам дашборда
M66	Политики ИИ и журнал запросов	Модели, лимиты, ПДн, аудит промптов/ответов

L. Инфраструктура, данные и доступ (M67–M72)

Код	Модуль	Назначение
M67	Геопортал / GIS	Карта объектов, слои, геокодирование, привязка к делу
M68	Мобильное PWA	Полевые наряды, офлайн-черновики, синхронизация
M69	SSO / ЕСИА	Единый вход, федеративная аутентификация для госсектора
M70	ETL и массовый импорт	Планировщик загрузок, журнал пакетов, повторный запуск
M71	Витрина данных (Data Hub)	Публикация наборов для аналитики и внешних потребителей
M72	Портал гражданина	Приём обращений снаружи, статус для заявителя (опционально)

6.7.L.1. Инфраструктура (M67–M72, этап 1)

Экран	Модули	Поведение
Обзор	M67 hub	KPI: геообъекты, PWA-черновики, SSO, ETL, витрина, обращения
Геопортал	M67	Leaflet-карта, слои GeoLayer, объекты GeoObject, привязка к делу, демо-геокодирование
PWA	M68	Устройства PwaDevice, офлайн PwaDraft, кнопка синхронизации
SSO	M69	Реестр SsoProvider (ЕСИА/SAML/OIDC)
ETL	M70	Задания EtlJob, журнал EtlRun, демо-запуск пакета
Data Hub	M71	Каталог DataDataset, публикация наборов
Портал гражданина	M72	CitizenAppeal, статусы, связь с делом, modal

Критерии приёмки M67–M72 (этап 1): карта с точками; синхронизация черновика PWA; провайдер SSO в списке; ETL-запуск в журнале; набор данных в витрине; обращение гражданина с номером.

M. НСИ, формы и операции (M73–M77)

Код	Модуль	Назначение
M73	Центральные справочники (НСИ)	Единые классификаторы: ОКТМО, типы документов, темы обращений
M74	Конструктор форм карточек	Визуальный редактор полей дела/реестра без программирования
M75	Массовые операции	Пакетная смена статуса, назначение исполнителя, экспорт
M76	Реестр выгрузок и печати	Журнал сформированных печатных форм и выгрузок
M77	Контроль исполнения поручений	Реестр поручений руководства, сроки, отчёт исполнителя

6.7.M.1. НСИ и операции (M73–M77, этап 1)

Экран	Модули	Поведение
Обзор	M73 hub	KPI НСИ, схем форм, поручения, массовые/выгрузки
НСИ	M73	CRUD NSIClassifier / NSIValue, иерархия parent
Конструктор форм	M74	FormSchema (target case/registry/correspondence), JSON полей; интеграция: динамические поля в карточке/мастере дела (case_extra), записи реестра по resolve_registry_schema, синхронизация field_schema реестра при сохранении схемы
Массовые	M75	BulkOperation — статус/назначение по фильтру дел
Выгрузки	M76	ExportJob — журнал, демо-генерация CSV
Поручения	M77	ManagementDirective, отчёт исполнителя, просрочка

Критерии приёмки M73–M77 (этап 1): справочник с значениями; схема формы сохраняется и применяется к форме дела/записи реестра; массовая операция в журнале; выгрузка в статусе «Готово»; поручение с отчётом закрывается.

N. Безопасность, эксплуатация, обучение (M78–M82)

Код	Модуль	Назначение
M78	Шаблоны уведомлений	Редактор текстов e-mail/SMS/in-app по событиям
M79	Антивирусная проверка вложений	Сканирование файлов при загрузке (интеграция с AV)
M80	Маскирование и обезличивание ПДн	Скрытие полей по роли, режим демонстрации
M81	Резервное копирование (UI)	Статус бэкапов, ручной запуск восстановления на тест
M82	Мониторинг и панель здоровья	Uptime, очереди, ошибки, версия релиза

6.7.N.1. Эксплуатация (M78–M82, этап 1)

Экран	Модули	Поведение
Обзор	M78 hub	KPI шаблонов, AV, бэкапов, снимков
Уведомления	M78	NotificationTemplate по event_code и каналу
Антивирус	M79	AvScanResult, демо-скан; интеграция: автоматический вызов scan_document_on_upload при создании документа и новой версии, статус на карточке документа
ПДн	M80	PiiMaskingPolicy, роли и demo_mode
Бэкапы	M81	BackupRecord, демо-запуск
Мониторинг	M82	SystemHealthSnapshot + метрики очередей

Критерии приёмки M78–M82 (этап 1): шаблон сохраняется; скан в журнале и после загрузки вложения; политика ПДн; бэкап в списке; снимок health с версией.

O. Лицензии, UX и расширяемость (M83–M86)

Код	Модуль	Назначение
M83	Лицензирование модулей	Учёт включённых M-кодов, срок лицензии, предупреждения
M84	Обучение и онбординг	Туры по интерфейсу, база подсказок, «что нового»
M85	Конструктор дашбордов	Пользовательская раскладка виджетов M15
M86	Каталог коннекторов	Marketplace адаптеров интеграций к M42

6.7.O.1. UX и лицензии (M83–M86, этап 1)

Экран	Модули	Поведение
Обзор	M83 hub	Лицензии, обучение, marketplace
Лицензии	M83	LicenseEntitlement + флаг включения модуля
Обучение	M84	OnboardingArticle (тур/подсказка/changelog)
Дашборды	M85	UserDashboardLayout, JSON виджетов M15; интеграция: KPI-дашборд M15 читает раскладку пользователя (DELAYU_LAYOUT), скрывает виджеты вне списка
Marketplace	M86	MarketplaceConnector, демо-установка

Критерии приёмки M83–M86 (этап 1): таблица лицензий; материал обучения; раскладка дашборда влияет на M15; коннектор в каталоге.

Сводная таблица: ядро + расширение

Группа	Коды	Кол-во
Ядро (детально в п. 6.1–6.6)	M01–M06	6
Рабочее место	M07–M14	8
Аналитика	M15–M21	7
Дела и реестры	M22–M23	2
Документооборот и ЭП	M24–M32	9
Бизнес-процессы	M33–M36	4
Коммуникации	M37–M41	5
Интеграции	M42–M45	4
Аудиоархив	M46	1
ИИ	M47–M66	20
Дополнительные (п. 6.8)	M67–M86	20
Итого в каталоге	M01–M86	86

7. Отраслевые подсистемы (после платформы)

Текущий фокус разработки: платформа «ДелаЮ» — ядро M01–M06, каталог M07–M86, UI, администрирование, демо-контур.

Подсистемы заказчика создаются на базе платформы опытным путём: мастер подсистемы, матрица модулей, универсальные реестры (M23), при необходимости — отдельное ТЗ на отраслевые реестры и процессы (docs/tz-source/).

Принцип	Описание
Не дублировать ядро	Пользователи, роли, документы, архив — только модули платформы
Расширение	Отраслевые сущности — реестры, типы дел, шаблоны процессов в контуре подсистемы
Документация	Каждая крупная подсистема — отдельный документ ТЗ, вне данного файла

---

8. Сквозные сервисы платформы

Реализуются как отдельные модули каталога (раздел 6.7) или как общие компоненты ядра:

Сервис	Модули каталога
Аутентификация, 2FA, сессии	Ядро + M07
Полнотекстовый поиск	M48, общий индекс
Журнал аудита	Ядро (обязателен)
Файловое хранилище	M05, M32
Импорт/экспорт CSV, XLSX	M23, M70
Печать и экспорт PDF	M29, M17

---

9. Роли пользователей (типовые)

Роль	Полномочия (обобщённо)
Администратор платформы	Подсистемы, глобальные модули, мониторинг
Администратор подсистемы	Организации, пользователи, роли, реестры, конфигурация меню
Руководитель	Просмотр всех дел подразделения, отчёты, согласования
Специалист	Ведение дел и реестров в рамках прав
Регистратор	Создание и первичная обработка обращений
Аудитор	Только чтение + журнал аудита

Конкретная матрица прав утверждается для каждой подсистемы на этапе внедрения.

---

10. Основные бизнес-процессы (сквозные)

10.1. Создание новой подсистемы (мастер)

1. Администратор платформы запускает мастер.
2. Указывает код, название, шаблон (чистое ядро / копия существующей подсистемы).
3. Выбирает модули из каталога.
4. Создаёт головную организацию.
5. Назначает администратора подсистемы.
6. Публикует конфигурацию → пользователи входят в контур подсистемы.

10.2. Ежедневная работа специалиста

1. Вход в систему, выбор подсистемы (если доступно несколько).
2. Рабочий стол: задачи, просрочки, входящие.
3. Работа с делом/реестром: данные, документы, смена статуса.
4. Формирование печатной формы, передача на согласование.
5. Завершение → архив (по правилам).

10.3. Администрирование доступа

1. Создание пользователя, привязка к организации и подсистеме.
2. Назначение роли.
3. Проверка матрицы «роль × модуль».
4. Аудит изменений прав.

---

11. Требования к данным и мультитенантности

1. Все прикладные данные (дела, реестры, документы) привязаны к организации и контексту подсистемы.
2. Пользователь видит только данные тех организаций и подсистем, к которым допущен.
3. Справочники могут быть общими для подсистемы или изолированными по организации (настройка).
4. Резервное копирование и восстановление БД — по регламенту заказчика.

---

12. Нефункциональные требования (базовый уровень)

Категория	Требование
Доступность	Веб-интерфейс, актуальные версии Chrome, Edge, Yandex Browser
Производительность	Отклик типовых операций ≤ 3 с при штатной нагрузке (уточняется нагрузочным тестом)
Масштаб	Не менее ___ одновременных пользователей на инсталляцию (заполняет заказчик)
Безопасность	Ролевая модель, хеширование паролей, HTTPS, журнал аудита
ПДн	Соответствие 152-ФЗ, класс защищённости ИСПДн — по акту заказчика
Развёртывание	PostgreSQL, Docker, Nginx; опционально Astra Linux
Язык интерфейса	Русский

---

13. Состав поставки

1. Серверная часть (backend) и веб-клиент (frontend).
2. СУБД PostgreSQL, скрипты миграций.
3. Инструкция администратора и пользователя.
4. Комплект для реестра отечественного ПО (по запросу).
5. Исходные ТЗ на отраслевые подсистемы (при наличии) — в docs/tz-source/.

---

14. Этапы реализации (предложение)

Этап	Модули (примеры)	Результат
0. Основа	—	Django, PostgreSQL, health, CI
1. Ядро	M01–M06, M02–M03	Подсистемы, роли, пользователи, архив
2. Рабочее место	M07–M14	Личный кабинет, календарь, канбан
3. Документооборот	M24–M32, M30–M31	Входящие, ЭП, история, переадресация
4. Процессы	M33–M36, M22–M23	BPM, дела, реестры
5. Коммуникации и интеграции	M37–M45	Чат, СМЭВ, шлюз
6. Аналитика	M15–M21	Дашборды, отчёты, качество
7. ИИ (волна 1)	M47–M56	Ассистент, OCR, классификация, риски
8. ИИ (волна 2)	M57–M66, M46	RAG, транскрибация, аудиоархив
8a. UI-каркас	Materialize starter-kit	Layout, меню, Customizer, вход
9. Пилот подсистемы	M23, отраслевые реестры	Первая конфигурация заказчика (отдельное ТЗ)
10. Расширение	M67–M86	GIS, PWA, ЕСИА, НСИ, мониторинг

---

15. Критерии приёмки (общие)

1. Создана подсистема с выбранным набором модулей, назначены пользователи и роли.
2. Специалист ведёт дело/запись реестра, прикладывает документ, меняет статус.
3. Руководитель видит отчёт и журнал действий.
4. Завершённое дело переводится в архив согласно политике.
5. Пользователь без права не получает доступ к чужому модулю/данным.
6. Документация и развёртывание на стенде заказчика выполнены по акту.

внесены демо данные для тестирования и испытаний системы

---

16. Пользовательский интерфейс и шаблон Materialize

16.1. Принципы UI

1. Единый визуальный язык — тот же шаблон Materialize v13.11.1 (Material Design), что использовался в предыдущей итерации разработки; без «с нуля» нового дизайна.
2. Панель настройки внешнего вида (Customizer) — берётся из шаблона: тема светлая/тёмная, semi-dark, цвет primary, компоновка меню, фиксация navbar, RTL (при необходимости).
3. Адаптивность — desktop-first для операторов; ключевые экраны пригодны для планшета (PWA, M68).
4. Русский интерфейс — все подписи, сообщения об ошибках, пустые состояния.
5. Доступность — контраст, фокус клавиатуры на формах (базовый уровень WCAG по согласованию).

16.2. Источник шаблона

Компонент	Путь / пакет
Django-версия шаблона	D:\Materialize 13.11.1 – …\django-version\
Стартовый каркас	django-version\starter-kit\ — layout, menu, navbar, footer
Полная демо-версия	django-version\full-version\ — примеры страниц (таблицы, формы, wizard)
Настройка темы	web_project\template_helpers\theme.py, template-config\demo-*.py
Меню (JSON)	templates\layout\partials\menu\vertical\json\vertical_menu.json
Customizer	has_customizer, customizer_controls в TEMPLATE_CONFIG

Предыдущая попытка (delau): фронтенд на Vue + Vuetify из Vue-редакции того же семейства Materialize. Визуально целевое состояние — как в той ветке, но на чистом репозитории newsystem без накопленного технического долга.

16.3. Выбор стека UI (рекомендация для реализации)

Вариант	Суть	Плюсы	Минусы
A. Django + Materialize (django-version)	SSR, шаблоны Django, меню JSON, customizer из коробки	Быстрый старт, один деплой, админка Django рядом	Сложные SPA-экраны (канбан, BPM) требуют HTMX/Alpine или встраивания Vue
B. Django API + Vue Materialize	Backend REST + SPA как в delau	Богатый UX, канбан/календарь, привычный стек из прошлой попытки	Два приложения, больше DevOps
C. Гибрид (рекомендуется)	Каркас A (layout, auth, настройки, админ-разделы) + острова B для M09–M11, M33, M15	Баланс скорости и UX	Чётко разделить границы «страница SSR / остров Vue»

Решение для этапа 0–1: взять **django-version/starter-kit — перенести web_project, templates, src (static), подключить к проекту newsystem; реализовать вход, layout, Customizer, заглушки разделов меню.
Решение для этапа 2+: экраны с высокой интерактивностью — Vue-редакция Materialize** (отдельная папка frontend/ в монорепо) с тем же primary_color и токенами темы.

Использовать только django-version проще для каркаса и админки; для «крутого» операционного UX канбан/календарь всё равно понадобится Vue из того же пакета шаблона.

16.4. Панель настройки внешнего вида (Customizer)

Переносится из шаблона без изменения набора контролов (минимум):

Параметр	Назначение
Тема (light / dark / system)	Общий тон интерфейса
Primary color	Акцентный цвет бренда подсистемы
Semi dark menu	Тёмное боковое меню
Layout collapsed	Свёрнутое меню
Navbar sticky / static	Поведение шапки
Content wide / compact	Ширина контентной области

Настройки сохраняются в профиле пользователя и/или в брендинге подсистемы (M01).

16.5. Предварительная структура меню

Меню формируется динамически из включённых модулей подсистемы (M01) и прав роли (M02). Ниже — эталон платформенного меню (без отраслевых разделов).

ДелаЮ
├── 🏠 Главная
├── ── Ежедневная работа ──
│   ├── Личный кабинет          [M07]
│   ├── Мне на сегодня          [M08]
│   ├── Календарь               [M09]
│   ├── Канбан                  [M10]
│   ├── Реестр дел              [M22]
│   └── Входящие / СЭД          [M24]
├── ── Документы ──
│   ├── Документы и вложения    [M05]
│   ├── Исходящие               [M25]
│   ├── Журнал регистрации      [M26]
│   └── Работа с ЭП             [M30]
├── ── Данные и реестры ──
│   ├── Универсальные реестры   [M23]
│   ├── Поиск                   [M48]
│   └── Импорт / ETL            [M70]
├── ── Коммуникации ──
│   ├── Чат                     [M37]
│   └── Уведомления             [M12]
├── ── Аналитика ──
│   ├── Дашборды                [M15]
│   ├── Отчёты                  [M16–M17]
│   └── Качество исполнения     [M19]
├── ── ИИ-помощник ──
│   ├── Ассистент               [M47]
│   └── База знаний             [M61]
└── ── Администрирование ──     (по ролям)
    ├── Подсистема и модули     [M01]
    ├── Организации и ШР        [M03–M04]
    ├── Пользователи и роли     [M02–M03]
    ├── Бизнес-процессы         [M33]
    ├── Интеграции              [M42]
    ├── Справочники НСИ         [M73]
    ├── Архив и аудиоархив      [M06, M46]
    ├── Журнал аудита
    └── Настройки интерфейса    (Customizer)

Платформенное меню (только администратор платформы, вне подсистемы):

Пункт	Модуль
Подсистемы	M01
Каталог модулей M01–M86	M01
Лицензии	M83
Мониторинг	M82
Паспорт продукта / версия	—

16.6. Эталонные экраны из шаблона (переиспользование)

Задача ДелаЮ	Страница-образец Materialize (full-version)
Списки дел/реестров	Tables, Datatables
Карточка дела	Pages → Account, Form layouts
Мастер подсистемы	Form Wizard
Дашборд	Dashboards Analytics
Канбан	Apps Kanban (Vue-редакция предпочтительна)
Календарь	Apps Calendar
Чат	Apps Chat
Настройки профиля	Pages → Account Settings
Ошибки 404/403	Misc Error

---

17. Приложения и связанные документы

Документ	Назначение
docs/tz-source/	Исходные ТЗ заказчиков на отраслевые подсистемы (вне scope платформы)
docs/delayu-product-opisanie.md	Маркетинговое и реестровое описание
docs/model-uchastnikov-produkt-kommertiya.md	Модель участников (коммерция)

---

18. История изменений

Версия	Дата	Автор	Изменения
1.0	19.05.2026	ЮГИт	Первый черновик: состав модулей, подсистемы, этапы
2.2	27.05.2026	ЮГИт	Слоганы, описание продукта, каталог M07–M66 (60+20 ИИ)
2.3	27.05.2026	ЮГИт	Правки архитектуры; каталог M67–M86; UI/Materialize; меню
2.4	27.05.2026	ЮГИт	Фокус на платформе; отраслевые подсистемы вынесены; старт реализации

---

Документ утверждён к реализации этапов 0–1. Отраслевые подсистемы описываются отдельными ТЗ после стабилизации ядра.