Таблица агрегирует решения, принятые по ходу обсуждения и сопоставляет их с модулями для использования при разработке.
| Модуль | Решение | Комментарий |
|---|---|---|
| Общее (MVP-скоуп) | Справочники (Порты/Причалы/Стоянки, Суда, Типы ресурсов) и записи Агентов/Исполнителей в MVP создаются вручную в БД, без UI для создания/редактирования части сущностей | CRUD-экраны создания не нужны в MVP для этих сущностей — только просмотр/изменение части полей и сценарии, явно помеченные MVP в этой таблице |
| Роли | Роль "Системный администратор" - за рамками MVP | Интерфейса для администрирования в MVP не будет. Сама роль существует и будет реализована после MVP, поэтому в сценариях роль указана. |
| Роли | Роль "Служба контроля" - за рамками MVP | Интерфейса для службы контроля в MVP не будет. Сама роль существует и будет реализована после MVP, поэтому в сценариях роль указана. |
| Пользователи | Восстановление пароля — После MVP (в MVP только смена пароля из профиля); блок «Администрирование пользователей» (список, блокировка/разблокировка) целиком — После MVP | В MVP нет self-service восстановления доступа — при потере пароля нужен ручной сброс администратором вне UI |
| Регистрация | Пользователь, забывший пароль в период MVP, не сможет восстановить доступ самостоятельно | Потребуется ручное вмешательство администратора через БД |
| Регистрация и авторизация | Самостоятельная регистрация, подтверждение почты, 2FA, проверка СБ — После MVP; в MVP пользователей заводит администратор/вручную в БД | Экран саморегистрации не нужен в MVP; нужна только форма логина/выхода и минимальный профиль |
| Заявки | Процессы эскалации/таймера заявок в каких-либо статусах за рамками MVP | В MVP никак не управляем, если заявка долгое время пребывает в каком-то из статусов. SLA и автоматическое действие (эскалация/напоминание/возврат) будут определены после реализации MVP. |
| Заявки | Критерий обязательности осмотра - за рамками системы | За рамками системы принимается решение о необходимости провести осмотр судна |
| Заявки | Заявки заново не переоткрываются, конечный статус заявки Отменено или Исполнено | При необходимости повторного осмотра должна создаться новая заявка Агентом |
| Заявки | В рамках MVP не планируется управление занятостью Исполнителя. | Агент просто выбирает исполнителя из реестра, сам Исполнитель принимает решение, сможет ли он провести осмотр в указанные даты |
| Заявки | В рамках MVP можно изменить все поля заявки во всех статусах кроме Отменено, Исполнено | |
| Заявки | Комментарии при изменении заявки не обязательны (в MVP). Обязателен комментарий при отмене заявки | |
| Заявки | Подписание актов, заявок, ЭЦП - за рамками MVP | |
| Заявки | Практически весь жизненный цикл заявки — MVP; исключения После MVP: экспорт списка, настройка полей реестра, ЭЦП, API результатов осмотра, удаление заявки сис.администратором | Основной модуль разработки для MVP; |
| Комментарии | Создание комментариев в Заявках - за рамками MVP. Но в рамках MVP реализуем создание комментариев (обязательных и не обязательных) в момент изменения заявки | Причины изменений заявки должны сохраниться также как и комментарий к заявке |
| Комментарии | Только просмотр списка — MVP; создание/изменение/удаление — После MVP | В MVP список комментариев функционально пуст (заполняется только системными записями из смены статусов заявки, если это отдельно предусмотрено) — согласовано как принятый риск, не баг |
| Справочники | В MVP в справочник "Порты, причалы и стоянки" позволяем Агентам, Исполнителям вносить новые данные. | Принимаем риск, что пользователи могут внести некорректные данные |
| Справочники | В MVP в справочник "Судна" позволяем Агентам вносить новые данные. | Принимаем риск, что пользователи могут внести некорректные данные |
| Справочники | В MVP не реализовываем статусы порта, и процессы архивации/распаковки | В MVP по умолчанию все порты, причалы и стоянки в статусе Активно |
| Справочники | В MVP не реализовываем статусы Судна, и процессы архивации/распаковки | В MVP по умолчанию все Судна в статусе Активно |
| Справочники | В MVP не реализовываем интерфейс для управления справочником Типов ресурсов (атрибутов каждого типа) | В MVP вручную будут в БД внесены все типы ресурсов, атрибуты каждого типа ресурса. Наполнение справочника представлено в разделе |
| Главная | Дашборды для Агента/Исполнителя/Администрации порта — MVP; дашборд для Службы контроля/безопасности — После MVP | В MVP роль СБ не имеет отдельного интерфейса главной страницы |
| Реестр Агентов / Реестр Исполнителей | Создание Агента/Исполнителя и привязка пользователя к организации — После MVP; просмотр, карточка, обновление данных, работа с ресурсами Исполнителя — MVP | Организации и связи «пользователь-организация» готовятся вручную до старта MVP; в проде понадобится процесс/скрипт первоначального наполнения |
| Уведомления | Генерация сообщения, отправка в ЛК (колокольчик), список новых, пометка прочитанным — MVP; email/MAX-каналы и «Панель всех уведомлений» (полная история) — После MVP | В MVP прочитанные уведомления недоступны для повторного просмотра — риск для пользователя «потерять» важное уведомление; |
| Локализация | В MVP необходима двуязычность интерфейса: на русском и английских языках | Дата и время в формате: dd.mm.yyyy hh:mm / дд.мм.гггг чч:мм |
Комментарии (2) · по состоянию на 2026-10-02
К странице
[Ревью] Заметки для AI-агента, реализующего портал «Осмотры судов» (по итогам 3 раундов ревью документации)
Ниже — практические указания для разработки MVP, синтезированные из всей документации INS, включая эту страницу решений, Глоссарий (id 73075176), Список функций (id 73075171) и Шаблоны уведомлений (id 73075640).
1. Общий принцип MVP-скоупа Справочники и реестры не имеют полноценного UI создания в MVP, но частично доступны для пополнения через интерфейс: - «Порты, причалы и стоянки» и «Судна» — Агенты/Исполнители МОГУТ добавлять новые записи через UI (принят риск некорректных данных). Реализовать простую форму добавления, без сложной валидации сверх базовой. - «Типы ресурсов» (атрибуты) — только вручную в БД, UI не нужен вообще. - Создание Агента/Исполнителя как организации и привязка пользователя к организации — После MVP; для MVP это делается вручную в БД/скриптом. Не проектировать экран регистрации организации. - Статусы у Порт/Судно НЕ реализуются в MVP — все записи считаются “Активно” по умолчанию, поле статуса можно не выводить в UI или показывать как read-only константу.
2. Роли - «Системный администратор» и «Служба контроля» — роли существуют в системе и упоминаются в сценариях/матрицах прав, но НЕ имеют своего UI/интерфейса в MVP. Не реализовывать личный кабинет/дашборд для этих ролей. - Внимание: в документации встречаются синонимы «Служба контроля» / «Служба безопасности» / «СБ» / «ФСБ» — это одна и та же роль в разных местах (проверить финальное решение автора перед реализацией enum значений роли). - Блок «Администрирование пользователей» (список, блокировка/разблокировка) и восстановление пароля — целиком После MVP. В MVP только смена пароля из своего профиля.
3. Терминологическая ловушка: «Судно» Термин «Судно» используется двояко: (1) объект осмотра (осматриваемое плавсредство, идентифицируется по ИМО+наименование) и (2) тип ресурса Исполнителя (собственное плавсредство Исполнителя для проведения осмотра, напр. водолазный катер). Модель данных/API должны явно разделять эти две сущности (разные таблицы/типы), несмотря на одинаковое название в UI-тексте. См. Глоссарий (id 73075176).
4. Модель данных - ИНН, ОГРН, ИМО — хранить как строки (string), не как числа: содержат ведущие нули/спецформат, не участвуют в арифметике. ОГРН — 13 символов для юрлиц, 15 для ИП. - Атрибуты типов ресурсов реализованы по EAV-подобной схеме (Тип_ресурса → Атрибут → Характеристика/Значение) — при реализации ORM учитывать динамическую схему, не фиксированные колонки. - ERD и словарь данных теперь синхронизированы по типам полей — перед реализацией миграций свежую версию Логической модели данных (id 73074181) и Словаря данных (id 73074184) нужно свести построчно (были найдены расхождения int/string по ИНН/ОГРН в PlantUML-версии ERD — уточнить у автора актуальную типизацию перед генерацией схемы БД). - Комментарий в MVP жёстко привязан только к Заявке (не к другим сущностям) — это осознанное решение, не ограничение для расширения в будущем.
5. Статусная модель «Заявка» - Заявки не переоткрываются: финальные статусы — «Отменено» и «Исполнено», из них переходов нет. Повторный осмотр = новая заявка. - Комментарий при изменении заявки НЕ обязателен, но ОБЯЗАТЕЛЕН при отмене — реализовать соответствующую валидацию на уровне API/формы. - Никаких таймеров/эскалаций/SLA-автоматизации по статусам в MVP — не реализовывать фоновые джобы для отслеживания “заявка висит слишком долго”. - Управление занятостью Исполнителя не реализуется — Агент просто выбирает Исполнителя из реестра, система не проверяет доступность/загрузку.
6. Комментарии - В MVP отдельного экрана создания произвольных комментариев к заявке НЕТ. Комментарий создаётся автоматически/полуавтоматически в момент изменения заявки (как причина изменения) — реализовать как часть формы редактирования заявки, а не отдельный модуль. - Список комментариев в MVP может быть функционально пустым, если система не генерирует системные записи при смене статуса — это принятый риск, не ошибка реализации.
7. Уведомления - В MVP: генерация, отображение в колокольчике (ЛК), список новых, отметка “прочитано”. Email/иные каналы и полная история — После MVP. - ВАЖНО: прочитанные уведомления в MVP становятся НЕДОСТУПНЫ для повторного просмотра (нет истории/архива) — реализовать именно так, несмотря на то что часть текста в разделе 3.6 может создавать иллюзию “архивирования всех уведомлений”. Если в UI-тексте будет предложена формулировка про архив/историю — не реализовывать её, ориентироваться на данное решение. - Тексты уведомлений — использовать готовые шаблоны со страницы «Шаблоны текстов для уведомлений» (id 73075640), не придумывать свои формулировки. - Механизм обновления уведомлений (push/WebSocket или поллинг) в документации не указан — по умолчанию реализовать простой поллинг (например, раз в 30-60 сек), пока не будет уточнено обратное.
8. Подписи/ЭЦП/интеграции - Подписание актов и заявок, ЭЦП — полностью за рамками MVP. Не проектировать интеграцию с сервисами ЭЦП. - Интеграция с PortCall и любые внешние API — за рамками MVP, заявки создаются только вручную Агентом через UI. - Критерий обязательности осмотра судна принимается за рамками системы — не реализовывать логику “нужен ли осмотр”, это решение вводится извне (человеком).
9. Локализация - Интерфейс должен поддерживать русский и английский языки (двуязычность) с самого MVP. - Формат даты/времени: dd.mm.yyyy hh:mm (рус: дд.мм.гггг чч:мм).
10. Где искать больше контекста - Полный перечень функций и их MVP/После-MVP статус — страница id 73075171. - Термины — Глоссарий id 73075176. - Тексты уведомлений — id 73075640. - Общая сводка решений — эта страница (id 73075569).
[Ревью] Обновление после раунда 4 (16.09.2026)
Документация продолжила дорабатываться, часть допущений из этой заметки теперь закреплена в тексте страниц (не только в комментариях). Дополняю ключевыми уточнениями для AI-агента:
Остальные пункты из первоначальной заметки (роли, статусная модель заявки, EAV-паттерн словаря данных, правила заявки, комментарии, е-подпись, локализация) остаются в силе без изменений.