ksv741
0e4c491765
Native archive synchronized 8 added and 3 modified requirements. All 24 main specs pass strict validation. Independent completion-output review confirms all 8 archived files preserve their bytes and all unrelated main specs remain unchanged. Product pilot remains a separate future change.
90 lines
8.3 KiB
Markdown
90 lines
8.3 KiB
Markdown
## 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 до разрешения внедрения.
|