0018 — Главный экран и единый каркас приложения¶

Дата: 2026-08-23.
Статус: Принято пользователем; конкретная визуальная геометрия AppShell уточнена решением 0029.
Ответственный: владелец проекта.

Контекст¶

Frontend-прототип сформировался вокруг экрана «Сегодня», а личный и административный кабинеты получили собственные оболочки и навигацию. Это помогло проверить отдельные сценарии, но смешало три разных понятия: главный экран после входа, продуктовый модуль и общий каркас защищённой части приложения.

Пользователь подтвердил необходимость разделить эти понятия, закрепить постоянные визуальные области рабочего экрана и предусмотреть связанные страницы профиля и организации в одном внутреннем интерфейсе.

Решение¶

1. Главный экран — возможность платформы¶

Главный экран живёт в platform/home и открывается по маршруту /home.
Он не является продуктовым модулем, не лицензируется отдельно и не подменяет экран «Сегодня».
После стандартного успешного входа пользователь попадает на /home.
Корень / является умной точкой входа и выбирает маршрут по состоянию доступа:
нет сессии — /login;
email не подтверждён — /check-email;
email подтверждён, но организация ещё не создана — /onboarding/organization;
учётная запись готова к работе — /home.
Если вход начался с допустимой защищённой deep-link через параметр next, после проверки сессии и прав разрешён возврат на этот маршрут.

Содержимое главного экрана определяется эффективными capabilities и текущим контекстом, а не только названием роли:

Контекст пользователя	Основные данные главного экрана
`owner`	состояние организации, краткая сводка «Сегодня», команда, подключённые модули и быстрые действия
`admin`	доступные операции организации и команды в границах выданных прав
`member`	личные задачи, доступные действия и подключённые ему модули
`viewer`	доступная только для чтения сводка
`platform_admin`	состояние платформы, организации, пользователи, инциденты и административные задачи
`super_admin`	возможности `platform_admin` и отдельно защищённые операции `super_admin`

Если у учётной записи одновременно есть платформенная роль и membership организации, AppShell предоставляет явный переключатель контекста «Платформа / Организация». Платформенный экран не показывает tenant-данные без выбранного и проверенного контекста организации.

Первая реализация может быть уже целевой: текущая организация и роль, подключённые модули, компактная сводка «Сегодня», шаги настройки владельца и отдельный административный блок по capabilities. Расширенные метрики добавляются только после появления достоверных backend-данных.

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

2. Единый каркас защищённой части¶

Общий каркас размещается в platform/shell; apps/web остаётся точкой композиции и маршрутизации, а packages/ui хранит только переиспользуемые UI-примитивы.

Все защищённые внутренние страницы используют один AppShell. Для ссылок на визуальные области закреплены идентификаторы:

Зона	Назначение
`S1`	основная навигация по доступным разделам и модулям
`S2`	текущая организация, пользовательский или платформенный контекст и его переключение
`S3`	сервисная навигация: помощь, документация, аккаунт и выход
`P1`	заголовок, описание и breadcrumbs страницы
`P2`	основные и вторичные действия страницы
`P3`	сводка, статусы и ключевые показатели
`P4`	поиск, фильтры, сортировка и переключатели представления
`P5`	основная рабочая область страницы
`P6`	счётчики, порядок, пагинация и служебные метаданные
`O1`	контекстная боковая панель
`O2`	модальное окно для отдельного действия
`O3`	уведомления, подтверждения и ошибки

На desktop S1–S3 располагаются в постоянной боковой панели шириной 252 px, а P1–P6 — в рабочей области. На mobile используются компактная верхняя панель, нижняя навигация, последовательное вертикальное размещение P1–P6; зона O1 открывается на весь экран. При реализации зоны получают устойчивые data-ui-zone атрибуты для обсуждения, тестов и документации.

Auth-страницы используют отдельный AuthShell. Публичный лендинг и документация являются отдельными приложениями и не обязаны повторять внутренний AppShell.

3. «Сегодня» остаётся продуктовым модулем¶

today остаётся в modules/today и открывается по /today.
Модуль владеет своей бизнес-логикой, данными, permissions и содержимым зон P1–P6, но не глобальной навигацией, профилем или оболочкой приложения.
/home может показывать компактный виджет «Сегодня» и переход в модуль, но не копирует весь рабочий экран модуля.
Текущий TodayPage, который содержит собственную глобальную навигацию, при реализации этого решения разделяется на модульное содержимое и общий AppShell.

Решение 0003 продолжает определять визуальный эталон «Сегодня», но больше не трактуется как определение общего главного экрана. Термин dashboard в решении 0012 означает интерфейс продуктового модуля, а не стартовую страницу всей системы.

4. Личный кабинет¶

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

/settings                    -> redirect /settings/profile
/settings/profile
/settings/security
/settings/notifications      -> отложено до появления уведомлений

Профиль: имя, аватар, email и его статус, язык и часовой пояс.
Безопасность: смена пароля, активные сессии и отзыв сессий.
На первом шаге допустим более узкий фактический состав — email и пароль — с явным обозначением ещё не реализованных полей.
Подключённые продуктовые модули и права сотрудников не относятся к личному профилю и переносятся в настройки организации.

Доступ к собственному аккаунту следует из активной подтверждённой учётной записи. Целевые permissions для мутаций: account.profile.update и account.security.manage.

5. Настройки организации¶

Настройки организации являются общей platform capability и доступны только в выбранном организационном контексте:

/organization/settings                 -> redirect /organization/settings/general
/organization/settings/general
/organization/settings/members
/organization/settings/modules
/organization/settings/permissions
/organization/settings/billing         -> отложено до решения по billing

Разделы включают общие данные организации, участников, подключённые модули, распределение прав и позднее тариф. Аудит действий добавляется после реализации общей audit capability.

Базовый доступ проверяется через organization.settings.view и organization.settings.manage. Для чувствительных операций используются более узкие capabilities: organization.members.manage, organization.modules.view, organization.modules.manage, organization.permissions.manage. owner первоначально получает полный организационный доступ; точная матрица для admin, member и viewer остаётся отдельным решением.

6. Маршрутизация и перелинковка¶

Целевая карта внутреннего приложения:

/
/home
/onboarding/organization
/today
/settings/profile
/settings/security
/organization/settings/general
/organization/settings/members
/organization/settings/modules
/organization/settings/permissions
/admin
/admin/users
/admin/administrators
/admin/organizations

Переходы выполняются внутренним router без полной перезагрузки приложения. Навигация формируется из эффективных прав и всегда сохраняет единый визуальный каркас. Недоступный маршрут не скрывается только визуально: backend остаётся источником истины и возвращает отказ доступа.

«Карта проекта» из решения 0011 остаётся административным разделом /admin, но не является универсальным главным экраном super_admin после авторизации.

Не входит в решение¶

Этим ADR не утверждаются:

новая схема доменов и репозиториев;
состав ветки STAGE, pipeline deploy и тестовая матрица STAGE;
роли и последовательность AI-агентов разработки;
точная матрица организационных ролей за пределами зафиксированных capabilities;
реализация кода, backend-схемы и реальные данные.

Эти вопросы рассматриваются отдельными блоками и требуют самостоятельного подтверждения.

Последствия¶

Целевая структура дополняется platform/shell, platform/home, а существующие platform/account и platform/organizations развиваются и подключаются через общий каркас.
Существующие TodayPage, AdminShell и компактная оболочка /settings требуют последующей миграции; данный документ сам по себе не означает, что миграция выполнена.
Новые внутренние страницы не создают собственную глобальную навигацию.
Появляется единый словарь визуальных зон для постановки UI-задач и acceptance-тестов.
Главный экран может развиваться по ролям без превращения каждого варианта в отдельный продуктовый модуль.

Откат или замена¶

Изменение статуса /home как общей platform capability, возврат today в роль главного экрана или отказ от общего AppShell требует нового ADR и плана миграции.

Последующее визуальное решение¶

Решение 0029 заменило только конкретные visual values: desktop rail 252 px на 188 px, обязательную mobile bottom navigation на modal drawer и прежние tokens на light/dark Control Surface. Зоны S1–S3, P1–P6, O1–O3, platform /home, module /today, маршруты и permission boundaries этого решения сохраняются.