8.3 KiB
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 до разрешения внедрения.