# Правила развития

## Единственный источник истины

Публичный компонент, его CSS, документация, registry entry и catalog example изменяются одним pull/merge request в этом репозитории.

Приложения не должны исправлять общий компонент локальным копированием. Если срочный adapter неизбежен, он должен:

- оборачивать публичный компонент;
- не копировать его внутреннюю реализацию;
- иметь ссылку на issue/design-system change;
- быть внесён в `docs/ADOPTION.md` как временный долг.

## Добавление компонента

Компонент принимается в систему, если:

1. он независим от доменной модели;
2. его API можно описать без упоминания конкретной таблицы/ноды/проекта;
3. он использует существующую тему и layer scale;
4. определены keyboard и disabled/pending states;
5. добавлен React или DOM adapter в зависимости от потребителей;
6. есть catalog example;
7. обновлён registry.

## Изменение геометрии

Геометрия меняется централизованно. Нельзя исправлять высоту/радиус в одном приложении, если изменение относится к общему контролу.

Допустимы density variants, если они имеют устойчивое назначение (`default`, `compact`) и тестируются как часть API.

## Deprecated

Перед удалением export:

- он получает статус deprecated в registry;
- документация указывает replacement;
- минимум один minor release сохраняет совместимость;
- после миграции известных consumers export удаляется в major release.

## Проверки

Минимум для merge:

- typecheck всех пакетов;
- registry validation;
- production build каталога;
- ручная визуальная проверка dark/light и нескольких accent;
- keyboard smoke test для Dropdown, Select, Window и Inspector.

Следующий уровень зрелости — автоматические screenshot regression и interaction tests. Они добавляются до массовой миграции приложений.

## Владение

У дизайн-системы должен быть явный code owner. Product team может предлагать компоненты, но общий API и theme contract проходят отдельное review, потому что изменение распространяется на все будущие приложения.