specs: archive shared design system correction

2026-09-08 07:11:59 +03:00
parent 61782885b5
commit 5a11419c92
9 changed files with 538 additions and 0 deletions
@@ -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** она остаётся у продуктового владельца и не становится общей только
+  ради классификации каталога
@@ -93,3 +93,33 @@ MUST NOT требовать доступа к реальным финансов
  сценария
 - **THEN** участник видит это ограничение и не получает заявления о проверке
  полного сценария на основании примера
+
+### Requirement: Каталог разделяет Design System и Product
+
+Каталог SHALL иметь два явно различимых содержательных блока: Design System
+и Product. Design System SHALL показывать foundations из действующей общей темы,
+семантические роли, используемые шкалы и общие компоненты, их варианты, состояния,
+доступность и правила применения. Product SHALL содержать реальные бизнес-компоненты
+и композиции приложения с полезными существующими историями, классифицированными
+по ответственности без перемещения бизнес-реализаций в общий слой. Оба блока
+MUST сохранять общую тему и изоляцию от application API, auth и данных пользователя.
+
+#### Scenario: Участник открывает Design System
+
+- **WHEN** выбран блок Design System
+- **THEN** доступны наглядные foundations с актуальными значениями токенов,
+  общие empty/error и loading компоненты, а также принятые конфигурации примитивов
+  с правилами использования и применимыми интерактивными состояниями
+
+#### Scenario: Участник открывает Product
+
+- **WHEN** выбран блок Product
+- **THEN** доступны существующие примеры списка счетов, карточек позиций, событий,
+  обновления сохранённых сумм и skeleton страницы с их вариантами и ограничениями
+
+#### Scenario: Оценивается готовность каталога
+
+- **WHEN** каталог представлен как поставленный результат
+- **THEN** существуют общий фундамент и оба содержательных блока, проверены
+  отображение и применимые взаимодействия, явно описаны границы покрытия;
+  сборка и наличие stories сами по себе не доказывают полноту или продуктовый пилот