specs: archive shared design system correction
This commit is contained in:
@@ -0,0 +1,56 @@
|
||||
# frontend-design-system Specification
|
||||
|
||||
## Purpose
|
||||
Определяет единый визуальный фундамент WealthLedger и переиспользуемые общие
|
||||
компоненты, чтобы приложение и каталог сохраняли согласованное представление.
|
||||
|
||||
## Requirements
|
||||
|
||||
### Requirement: Приложение и каталог используют единый визуальный фундамент
|
||||
|
||||
Приложение и каталог SHALL использовать один источник темы и токенов: цвета
|
||||
с семантическими ролями, типографику, интервалы, радиусы, тени и применимые
|
||||
адаптивные параметры. Общий фундамент MUST быть независим от бизнес-сущностей
|
||||
и уровня приложения; подключение провайдеров принадлежит приложению и runtime
|
||||
каталога. Параллельные копии значений MUST NOT создаваться там, где существующий
|
||||
механизм темы уже владеет шкалой. Выделение фундамента MUST сохранять текущий
|
||||
внешний вид, светлую схему и поведение приложения без массовой замены локальных
|
||||
значений оформления.
|
||||
|
||||
#### Scenario: Компонент отображается в приложении и каталоге
|
||||
|
||||
- **WHEN** один компонент с одинаковыми props отображается в обоих runtime
|
||||
- **THEN** он получает одинаковые тему, токены и общие визуальные правила
|
||||
|
||||
#### Scenario: Участник выбирает токен
|
||||
|
||||
- **WHEN** участник изучает фундамент дизайн-системы
|
||||
- **THEN** доступны используемые шкалы, их значения, семантические роли и правила
|
||||
применения без необходимости обращаться к данным приложения
|
||||
|
||||
#### Scenario: Владение темой перенесено
|
||||
|
||||
- **WHEN** приложение использует выделенный общий фундамент
|
||||
- **THEN** исходные эффективные значения и внешний вид остаются прежними,
|
||||
включая встроенные шкалы, глобальные стили и локальное оформление
|
||||
|
||||
### Requirement: Общие компоненты независимы от предметной области
|
||||
|
||||
Дизайн-система SHALL предоставлять минимальный набор реально используемых
|
||||
общих компонентов с описанием назначения, вариантов, состояний и доступности.
|
||||
Они MUST NOT знать о счетах, позициях, API или authentication. Существующие
|
||||
компоненты SHALL переиспользоваться, если удовлетворяют этой границе; новые
|
||||
обёртки MUST NOT вводиться только ради имени или покрытия каждого примитива.
|
||||
Принятые конфигурации библиотечных компонентов MAY демонстрироваться напрямую.
|
||||
|
||||
#### Scenario: Требуется общее состояние интерфейса
|
||||
|
||||
- **WHEN** разработчик выбирает общее empty/error или loading представление
|
||||
- **THEN** он получает используемый приложением компонент с доступной семантикой,
|
||||
необязательными действиями там, где они применимы, без бизнес-зависимостей
|
||||
|
||||
#### Scenario: Композиция имеет бизнес-смысл
|
||||
|
||||
- **WHEN** композиция представляет счёт, позицию или продуктовый запросный экран
|
||||
- **THEN** она остаётся у продуктового владельца и не становится общей только
|
||||
ради классификации каталога
|
||||
Reference in New Issue
Block a user