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

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

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

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

Рекомендация: в коммуникации использовать ★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. Термины и определения

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. Модель данных

6.1.2. Интерфейс

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. Модель данных

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

6.2.2. Интерфейс

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)

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

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

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. Модель данных

6.4.2. Интерфейс

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. Модель данных

6.5.2. Интерфейс

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. Модель данных (дело)

6.6.2. Интерфейс

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)

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

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

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

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

Права: 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)

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

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)

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)

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

Права: просмотр — 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.

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

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

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

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

Права: 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)

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

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

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)

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)

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

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

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)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Нефункциональные требования (базовый уровень)

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

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

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

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. Источник шаблона

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

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

Решение для этапа 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)

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

Настройки сохраняются в профиле пользователя и/или в брендинге подсистемы (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)

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

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

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

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

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