2.7 KiB
Why
Поставленный каталог реальных компонентов не даёт явно оформленного общего визуального фундамента и не разделяет общие решения и продуктовые композиции. Это corrective change поверх текущей baseline после integrate-ui-ux-design-workflow; исторические artifacts и evidence двух архивированных changes остаются неизменными.
What Changes
- Единая визуальная основа с определёнными шкалами и семантическими ролями, общая для приложения и каталога, с сохранением текущего вида и поведения.
- Минимальный полезный набор используемых общих компонентов без бизнес-знаний.
- Два содержательных блока Design System и Product: foundations, общие компоненты, реальные продуктовые композиции, состояния и правила применения.
- Проверяемые границы покрытия, изоляции и as-built описание результата.
Non-goals: массовый редизайн, замена всех локальных значений, полный каталог библиотеки или приложения, новый продуктовый пилот, изменение backend/API, переписывание архивов и чужого state. По прямому разрешению владельца planning и implementation выполняются в одном контексте без sdd-session/session records.
Capabilities
New Capabilities
frontend-design-system:specs/frontend-design-system/spec.md— общий визуальный фундамент и независимые от домена общие компоненты.
Modified Capabilities
frontend-ui-catalog:specs/frontend-ui-catalog/spec.md— обязательные содержательные блоки Design System и Product и критерии готовности.
Impact
Frontend и участники разработки получают переиспользуемую визуальную основу и каталог с явными границами. Specs фиксирует corrective contract; docs — фактически поставленный результат. Backend и данные пользователей не затронуты.