Семнадцать дизайн-систем отвечают из одной точки

У сайта была настоящая система: токены в три слоя, сборка, линтер, перепись страниц. Но все проверки смотрели только на сайт. UI-киты не были связаны с ним ни одной ссылкой, прототипы хранили значения четырьмя способами, а у беспилотного такси был свой второй конвейер сборки. Одно имя в разных местах значило разное. Агенту, который писал прототип, никто не говорил, какая у файла система, и линтер такие файлы не мерил.

1. 01

   Одна папка systems/, по записи на систему: ядро, сайт, две платформы, три кита, продукты. Прототип привязан к системе одним полем, а индекс из записей читают все: раздел на сайте, коннектор, линтер и хук

2. 02

   Шесть слоёв, от примитивов до экрана, и ссылаться можно только вниз: направление проверяет сборка. Новые смысловые имена заводит только ядро, система лишь даёт им значения

3. 03

   Токены в DTCG 2025.10, собирает их Terrazzo одной командой: CSS со слоями и light-dark(), типы, мост Tailwind и файлы Figma по режимам

4. 04

   Контракт компонента один на все системы: что это, когда ставить и когда нет, варианты, состояния, значения, доступность, пример. По нему одна витрина на систему, 120 компонентов в 17 системах

5. 05

   Агент получает систему файла сам: kit_for по пути отдаёт цепочку, шкалу и имена, kit_read часть системы, kit_component контракт со значениями по цепочке и тем, что не сошлось

1. 01

   Тема

   Тему проверил по чеклисту из 19 пунктов, и слабое место нашлось сразу: пользователь пока один, я и мои ИИ-агенты, а это близко к «мне так удобнее». Поэтому скринер зовёт тех, кто вёл системы годами. Остальное сошлось: не сайт и не перерисовка, а продукт с ролями и ограничениями, сверху Figma Enterprise и старый Safari. Потери времени и ошибки агентов меряются числом, задача есть у любой команды, где больше одного продукта, а развилок хватает: наследование, переименование, закрытые системы. Свой опыт прямой, систему сайта веду сам.

2. 02

   Конкуренты

   Разобрал, как системы отдают себя ИИ-агентам. Лучший набор у Primer MCP: поиск значения, контракт, примеры и проверка CSS в одном сервере. Storybook MCP собирает манифест компонентов из историй, но только для React. У shadcn проект сам объявляет, из каких реестров берёт компоненты, у v0 система хранится навыком со стартовым приложением, которое человек проверяет до сохранения. zeroheight отдаёт страницы руководства, то есть документ, а не компонент. Взял у Primer поиск и проверку в одном месте, у shadcn привязку в файле проекта, у v0 образец экрана. Не взял модель документа и Figma как источник.

3. 03

   Разговоры

   Данные гипотетические: смоделированы для анализа, до проверки на людях

   Подготовил скринер на восемь разговоров и пять тестов: дизайнер, разработчик, продакт, два ИИ-агента и два скептика, владелец системы в большой компании и архитектор платформы. К нему гайд JTBD-интервью. Живых разговоров не было, роли смоделировал, а скептики говорят доводами спора о масштабе, каждый довод с местом в коде. Главное: продукт молчит там, где должен отказать, и даёт правдоподобный ответ вместо «не знаю». Пользователь меряет время до работающей системы, а продукт меряет время записи. И имя это интерфейс: ключ ds-NNN вылезает туда, где пишет человек.

4. 04

   Требования

   Данные гипотетические: смоделированы для анализа, до проверки на людях

   Главная работа: когда продукту нужен свой вид, получить систему, согласованную с родителем, которую любой агент применит без ошибок. Под неё пять ролей с мерой успеха и восемь Job Stories, например: когда путь файла не привязан ни к одной системе, услышать «системы нет, вот как привязать». Решил, что ключ остаётся личностью записи, но уходит из того, что пишет человек: app.json принимает имя.

5. 05

   Варианты

   Перед планом правок два агента-скептика спорили: один звал систему переусложнённой, другой недостаточно гибкой. Почти все их замечания подтвердились в коде, спорили о порядке. Расширенные коллекции Figma основой семей не стали: они только в Enterprise. Свой вывод под Android отложил, пока нет заказчика: у каждого вывода цена поддержки, а пакет в плоском DTCG прогонит через Style Dictionary тот, кому нужен Compose. Переписывать палитру родителя дочке нельзя, на общей палитре держится согласованность Сбера; свои роли она заводит в своём пространстве. Глубину держу не больше трёх уровней, сейчас местами четыре; канал llms.txt не делаю.

6. 06

   Архитектура

   Девять объектов по схемам реестра: система, ключ, имя, название, псевдоним, контракт, экран, приложение и журнал. Система ссылается на родителя по ключу, прототип на систему одним полем, а прежнее имя после переименования отвечает с пометкой. Для страницы раздела хватило словаря из пяти слов: система, имя, название, ключ, контракт.

7. 07

   Сценарии

   User flowПуть человека по экранам от начала задачи до её завершения, со всеми развилками. «завести дочернюю систему» описал дважды. Сейчас: четыре развилки и минимум три ручных шага после команды, а без app.json прототип молча меряется системой сайта. Цель: одна команда, платформа и компоненты от родителя, app.json записан сам. Screenflow раздела «Дизайн-системы»: список, сводка, компоненты, экраны и связи, и что добавить в каждый по итогам.

8. 08

   Прототип

   Здесь прототип и есть продукт. Спецификацию единой точки собрал вместе с ИИ 1 октября, план до работы проверил агент-критик, а сборщик сменил только после пилота строка к строке. Код писали ИИ-агенты по шагам с проверяемым итогом, я проверял и возвращал недоделанное.

9. 09

   UX-тест

   Данные гипотетические: смоделированы для анализа, до проверки на людях

   Написал пять задач теста: найти систему файла, завести дочку, переименовать, отдать систему ИИ, выбрать компонент. Прошёл их глазами пяти типичных пользователей: команды выполнены на деле на копии репозитория, реакции смоделированы. Нашёл: три краевых пути из четырёх молча уходят в систему сайта, переименование Сбера задевает шесть файлов и 35 мест, а отказ в пробном переименовании печатается после плана. По итогам 23 правки, двенадцать малых закрывают ошибки агентов ещё до теста на людях.

10. 10

    Количественный тест

    Данные гипотетические: смоделированы для анализа, до проверки на людях

    First Click на сводке системы retry в разделе: 30 дизайнеров, которые ведут системы, и задание «Найдите, какие значения retry взял у родителя, а какие свои». Порог до замера: 70 % первым нажатием приходят в одно место. Итог: «Связи» 12, «Компоненты» 10, цепочка в шапке 8. Ни одно место не набрало и половины: ответа на этот вопрос в разделе нет. Отсюда вкладка «своё против родителя» в правках.

11. 11

    Метрики

    A/B-тест здесь неприменим: автор один, трафика нет. Вместо него до и после на стенде агента: 20 путей и 20 заданий, прогон до правок и после каждой. Метрики продукта, а не экрана: время завести систему, цель до пяти минут одной командой; доля ошибок агентов, цель меньше 5 %; число мест на правку семьи, цель одно; и все пятеро видят отказ до запуска команды.

• ·Реестр systems/ со схемами записи, контракта, экрана и журнала
• ·Сборщик ds-build: CSS, типы, Tailwind и Figma одной командой, проверка стоит в тестах перед пушем
• ·Коннектор: kit_list, kit_read, kit_for и kit_component
• ·Правило для агентов в шесть строк: система файла, образец экрана, контракт с «когда нет»
• ·ds-lint мерит файл шкалой его системы, а храповик не даёт нарушениям расти