## 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 и данные пользователей не затронуты.