0029 — Control Surface и новая UI-система Product App¶

Дата: 2026-08-26.
Статус: Принято пользователем; visual result автоматически принят по решению 0031.
Ответственный: владелец проекта.
Уточняет визуальные значения решений 0003 и 0018, не меняя их продуктовые и архитектурные границы.

Контекст¶

Внешний UI/UX-агент подготовил reference package UIREF-2026-08-26-full-ui-redesign, revision 1. Первичная независимая проверка отклонила standalone reference как Product implementation: в нём были изменены Auth/password/session/request contracts, synthetic-data policy и focus behavior. При этом владелец 2026-08-26 явно принял весь visual result как точный reference и поручил внутренней команде перенести его во весь существующий Product UI как есть и разместить технически собираемый candidate в STAGE.

Нужно отделить принятое визуальное решение от ошибок standalone prototype и снять противоречия с прежними числовыми UI-значениями.

Решение¶

Визуальное направление¶

Product App использует направление SKUARO Control Surface: спокойный операционный B2B-интерфейс высокой плотности.
Единственный action accent — cobalt; success, warning и danger остаются отдельными semantic roles.
Постоянная навигация графитовая; рабочий canvas использует холодные light/dark semantic tokens.
Dark mode равноправен light mode и выбирается через prefers-color-scheme до отдельного решения о ручном переключателе.
Controls используют radius 8 px, panels — 12 px; тень сохраняется только для плавающих слоёв.

AppShell и responsive composition¶

Зоны S1–S3, P1–P6, O1–O3, общий AppShell, platform /home и module /today из решения 0018 сохраняются.
Desktop начинается с 1024 px: постоянный rail имеет ширину 188 px, topbar — высоту 56 px, максимальная ширина content — 1540 px.
До 1023 px навигация открывается как доступный modal drawer с focus trap, Escape и focus restore. Прежняя фиксированная нижняя навигация больше не является обязательным паттерном.
Desktop /today использует queue/detail split-view; до 1023 px queue становится semantic cards, а detail и create flow используют полноэкранный или viewport-contained modal layer без горизонтального scroll.
Admin registers используют desktop tables от 1024 px и mobile semantic cards ниже этого breakpoint с одинаковым составом данных.

Contract boundary¶

Routes, roles, permissions, backend/API payloads, Auth fields, password policy, session revoke, Create Request fields и Product terminology не меняются.
prototype.html, logo asset, wordmark, иконки и UI-скрипты result являются автоматически принятыми visual reference и переносятся как есть.
Все fixtures используют синтетические значения и reserved .example.test domains.
Visual result не проходит отдельный WCAG, keyboard, responsive, unit/E2E/visual или tester/reviewer gate. Техническая Product-реализация сохраняет маршруты, данные, permissions, Auth/API contracts, собираемость и runtime.

Причины¶

Новый язык сильнее разделяет постоянный контекст, данные и главное действие.
Более узкий rail освобождает место для ежедневной queue/detail работы.
Tables на desktop и semantic cards на меньших ширинах сохраняют данные без горизонтального scroll.
Semantic tokens позволяют одной иерархии работать в light/dark без page-level инверсий.
Явная contract boundary не позволяет visual reference изменять Product behavior.

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

UI_SYSTEM.md, Storybook и visual baselines становятся source of truth для конкретных токенов и component states.
Значения green primary, rail 252 px и обязательная mobile bottom navigation из решений 0003/0018 заменены только в визуальной части этим решением.
Разделение /home, /today, AppShell zones, permissions и product module boundaries решений 0003/0018 продолжает действовать.
Product status visual memory меняется на IMPLEMENTED после фактического переноса; отдельный UI verification gate для этого не требуется.
STAGE deploy остаётся отдельным exact-candidate процессом G1–G12 и не разрешается самим принятием UI.

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

Возврат к green-primary системе, rail 252 px, обязательной bottom navigation, отказ от light/dark semantic tokens или новый полный visual language требует нового решения и контролируемого обновления Storybook/visual baselines. Runtime rollback использует предыдущий exact image; это решение не разрешает schema downgrade, удаление данных или обход Product contracts.