Integrate Storybook and portable UI design workflow

2026-09-07 22:48:25 +03:00
parent a342e9d63f
commit c6dc20b153
9 changed files with 908 additions and 1 deletions
@@ -0,0 +1,89 @@
+## Why
+
+WealthLedger уже имеет общую основу интерфейса, но участникам разработки
+недоступен единый воспроизводимый каталог её возможностей и состояний.
+Существующий Design объясняет технические решения, однако не определяет,
+какой визуальный результат согласован, как передать его следующей изолированной
+сессии и как установить соответствие реализации этому результату.
+
+Нужно связать доступную UI-основу и UI/UX-проектирование с действующим SDD,
+чтобы владелец видел ожидаемый интерфейс до реализации, а исполнители
+использовали одну согласованную основу и однозначный Design. Planning можно
+вести сейчас; внедрение процессной части начнётся после завершения
+`optimize-session-oriented-sdd-v2`.
+
+## What Changes
+
+- Развить существующую UI-основу и предоставить один доступный участникам
+  каталог ограниченного набора реальных компонентов и UI-композиций
+  WealthLedger, их вариантов, применимых состояний и правил использования.
+  Основное содержание показывает решения приложения; библиотечные примитивы
+  допустимы только как вспомогательная основа с принятыми конфигурациями. Каталог отражает реальное поведение компонентов
+  и общие визуальные правила приложения, позволяя выбирать готовые решения
+  без запуска полного пользовательского сценария.
+- Включить UI/UX-проектирование в существующий Design. Объём визуальной
+  проработки соразмерен изменению: новый или существенно изменённый интерфейс,
+  переиспользование согласованного решения либо обоснованная неприменимость
+  UI/UX. Отсутствие влияния на интерфейс не требует формального макета.
+- Сделать визуальные материалы частью единого согласуемого Design: они
+  объясняют затронутые экраны, состояния, взаимодействия и адаптивное поведение
+  в объёме конкретного change. Следующая изолированная сессия получает
+  однозначную версию полного пакета, а материалы остаются доступны после
+  архивирования change.
+- Передавать согласованный визуальный результат в реализацию и независимую
+  проверку через существующий SDD. Существенное расхождение возвращает работу
+  к соответствующей planning boundary; наличие макета или каталога само по
+  себе не означает approval либо подтверждённое соответствие реализации.
+- Подготовить основу для совместного пилота каталога и обновлённого процесса
+  на последующем небольшом UI change с собственными planning approvals.
+  Текущая поставка даёт готовность к такому пилоту; успешность сквозного
+  workflow можно заявить только после его фактического прохождения.
+- Перед Design повторно сверить действующую canonical authority. Согласование
+  процесса с результатом `optimize-session-oriented-sdd-v2` не даёт права
+  автоматически переутверждать активные changes или переписывать archives.
+
+Вне scope: полный редизайн приложения, каталогизация всех компонентов,
+новая продуктовая фича в роли неявного пилота, замена существующей UI-основы,
+отдельная поставка дизайн-системы как самостоятельного продукта, автоматическое
+преобразование макетов в реализацию и двусторонняя синхронизация. Новый lifecycle,
+дополнительная SDD-роль и отдельный UI/UX approval не вводятся. Концептуальные
+материалы и Discovery остаются входным контекстом, а не утверждёнными
+OpenSpec-артефактами.
+
+## Capabilities
+
+### New Capabilities
+
+- `frontend-ui-catalog` — `specs/frontend-ui-catalog/spec.md`: участники
+  разработки могут воспроизводимо просматривать ограниченный набор реальных
+  UI-компонентов, их варианты и состояния на общей визуальной основе приложения.
+
+### Modified Capabilities
+
+- `openspec-authority-and-lifecycle` —
+  `specs/openspec-authority-and-lifecycle/spec.md`: полномочия Design охватывают
+  применимый визуальный пакет; единые approval, передача, semantic verification,
+  feedback routing и сохранность при archive распространяются на весь пакет.
+- `agent-sdd-session-workflow` — `specs/agent-sdd-session-workflow/spec.md`:
+  Specification, Implementation и независимая Validation используют применимые
+  визуальные материалы из canonical Design при продолжении между сессиями,
+  сохраняя единственную роль сессии и non-authority характер handoff.
+
+## Impact
+
+Основные пользователи изменения — Change Owner, участники UI/UX-проектирования,
+frontend-разработчики и AI-агенты, выполняющие planning, implementation и review.
+Для пользователей приложения этот change не вводит новых инвестиционных
+сценариев и не разрешает массовую смену интерфейса.
+
+Затрагиваются frontend как владелец общей UI-основы и каталога, specs как
+владелец canonical SDD contract и docs как описание фактически поставленного
+процесса и правил использования основы. Локальные agent entrypoints следуют
+этому contract. Backend, денежные расчёты и публичный API не меняются.
+
+Точные границы поставки по всем четырём репозиториям определит Delivery Map
+в Design. Действующие правила доступности, UI-состояний, границ frontend и
+обязательной проверки сохраняются; каталог не вводит конкурирующую модель
+пользовательского поведения. Совместимость инструментов, переносимость
+визуальных материалов и применимость обновлённого процесса к активным changes
+остаются вопросами последующего Design до разрешения внедрения.