Этот документ нужен тем, кто меняет пользовательский интерфейс дашборда.
Что интерфейс должен делать¶
Интерфейс должен помогать человеку быстро отвечать на четыре вопроса:
- что выглядит здоровым;
- что выглядит рискованным;
- что заблокировано;
- куда нужно провалиться дальше.
Если экран не помогает ответить хотя бы на один из них, скорее всего, это просто шум.
Что интерфейс обязан уважать¶
Интерфейс должен явно показывать текущую архитектуру:
- здоровье кода из графового слоя;
- готовность контекста из слоя памяти;
- доверие к сессиям и знаниям из слоя управления.
Это важнее, чем добавление ещё одной красивой диаграммы.
Для экранов композиционного анализа интерфейс должен работать от проекта, а не от общего сводного виджета. Сначала используется projectCatalog() для выбора проекта, затем проектные данные запрашиваются через projectScaSummary(name), projectScaDependencies(name), projectScaVulnerabilities(name) и projectScaSbom(name). scaOverview нужно трактовать только portfolio-агрегат, а не как основной источник данных для страницы конкретного проекта.
Для экранов уведомлений страница по умолчанию не pre-populated. Рабочий интерфейс должен вызвать bootstrapNotificationRuntime(body) и загрузить живые данные через POST /api/v2/dashboard/subscriptions/bootstrap. Если на экране видны только демонстрационные карточки, это не доказательство рабочего контура.
Важно отделять демонстрационный захват экрана от живого режима. Файл frontend/scripts/capture_sales_deck_ui.mjs нужен для скриншотов и фикстур, а не как доказательство того, что реальный поток уведомлений уже загружен.
Для портфельной работы интерфейс также должен поддерживать saved view и portfolio alerts. Первый помогает повторно открыть тот же набор фильтров, а второй позволяет команде подписаться на важное состояние портфеля без ручной перенастройки экрана.
Как выглядит хороший экран дашборда¶
Сильный экран должен:
- быстро объяснять сам себя;
- ясно показывать смену состояний;
- делать деградацию видимой;
- быстро вести пользователя к следующему решению.