HIF / Документация / Крупные платформы

Индустриальные дизайн-системы

Статус: сравнительный справочник

Версия: 0.1

Документ сопоставляет крупные публичные дизайн-системы и платформенные руководства. Он не воспроизводит их визуальные стили, а извлекает переносимые принципы, практики эксплуатации и критерии качества, способные усилить HIF.

Сравнение основано только на официальных англоязычных источниках организаций, которым принадлежат системы.

1. Как читать этот документ

1.1 Классы оснований

До включения внешней идеи в Профиль продукта ей ОБЯЗАТЕЛЬНО присваивается класс:

Платформенная конвенция — поведение, которого люди обоснованно ожидают в конкретной ОС, классе устройств или канале распространения. Она обязательна, если этого требует платформа либо отклонение нарушит совместимость, доступность или усвоенное поведение.
Внешний стандарт — нормативное требование применимой спецификации, регулирования или договора. ОБЯЗАТЕЛЬНО фиксируются источник, версия и область.
Конвенция системы — правило, обязательное для принадлежности к конкретной продуктовой экосистеме, например Shopify Admin или Salesforce Lightning. За её пределами оно не обязательно.
Эвристика — полезная проверяемая рекомендация. Она не универсальна и НЕ ДОЛЖНА выдаваться за платформенное или юридическое требование.
Решение HIF — локальный нормативный выбор, принятый через управление HIF. Он остаётся связанным с основаниями и допускает пересмотр.

Популярность не доказывает универсальность. Правило крупной компании может быть превосходным для её пользователей, модели бизнеса и технологий, но ошибочным в другом контексте.

1.2 Приоритет

Конфликты в соответствующем HIF продукте разрешаются в таком порядке:

применимое право, требования безопасности и внешние стандарты;
Конституция HIF;
конвенции взаимодействия и доступности целевой платформы;
утверждённый Профиль продукта;
принятый выпуск дизайн-системы;
продуктовые паттерны и компоненты;
визуальные предпочтения.

Платформенную конвенцию НЕЛЬЗЯ переносить на другую платформу только ради визуальной одинаковости. Кросс-платформенный продукт сохраняет семантику задач, объектов и команд, адаптируя представление, ввод, навигацию, окна и интеграцию с системой.

1.3 Область сравнения

Системы выбраны, если они дают одно или несколько из следующего:

язык взаимодействия платформенного масштаба;
публичные критерии качества или оценки;
зрелую архитектуру токенов, компонентов и паттернов;
руководство по доступной реализации;
модель вклада, зрелости или выпуска;
основания из массового публичного, корпоративного или профессионального ПО.

2. Сравнительная карта

Система	Основной контекст	Характерный вклад	Платформенно-зависимые элементы
Google Material Design 3	Много классов устройств, прежде всего Android	Адаптивные раскладки, семантические роли, явные состояния, выразительные темы	Навигация Android, системные поверхности, Compose и конвенции устройств
Android quality guidance	Android-приложения и Google Play	Проверяемый минимум качества, устойчивость жизненного цикла, форм-факторы, техническое качество	Жизненный цикл, back, разрешения, окна и распространение Android
web.dev	Веб	Полевые метрики производительности, прогрессивное улучшение, семантическая и доступная реализация	API браузера, HTML-семантика и веб-метрики
Apple Human Interface Guidelines	Платформы Apple	Нативная знакомость, различия платформ, системные возможности, настройки доступности	Конвенции iOS, iPadOS, macOS, watchOS, tvOS и visionOS
Microsoft Fluent 2 и Windows	Продукты Microsoft и Windows-приложения	Естественная адаптация, фокус на работе, слои семантических токенов, полная desktop-интеграция	Окна, оболочка, ввод, материалы и системные контролы Windows
IBM Carbon	Корпоративные и насыщенные данными продукты	Явное определение готовности, жизненный цикл вклада, статус доступности, ролевые темы	Бренд IBM и продуктовые конвенции IBM
Adobe Spectrum	Профессиональные творческие кросс-платформенные инструменты	Рациональное поведение, desktop/mobile масштабы, прозрачные статусы и версии	Бренд Adobe и специализированные конвенции творческих инструментов
Salesforce Lightning	Платформа Salesforce и корпоративные процессы	Независимые от реализации blueprint, styling hooks, корпоративная согласованность	Архитектура информации Salesforce, платформенные компоненты и runtime Lightning
Shopify Polaris	Shopify Admin и встроенные коммерческие приложения	Язык предметной области, доступное переиспользование, согласованность задач продавца	Навигация Shopify Admin, коммерческая терминология и требования проверки
Atlassian Design System	Корпоративные продукты совместной работы	Выраженные foundations, семантические токены, self-service документация и масштаб	Оболочка и бренд продуктов Atlassian
GOV.UK Design System и Service Standard	Публичные услуги Великобритании	Целая услуга, исследованные паттерны, progressive enhancement и оценка услуги	Идентичность GOV.UK и обязанности публичного сектора Великобритании
U.S. Web Design System	Федеральные сайты и услуги США	Поэтапное внедрение от принципов, доверие, непрерывность и зрелость доступности	Федеральная идентичность и законодательные обязанности США
GitHub Primer	Плотные интерфейсы продуктивности разработчиков	Эффективность, зрелость компонентов, upstream и безопасные для тем токены	Процессы, терминология и идентичность GitHub

Таблица служит ориентиром, а не рейтингом. Ни одна из систем не заменяет исследования пользователей, моделирование предметной области или сквозную оценку.

3. Google: Material Design 3, качество Android и web.dev

3.1 Вклад корпуса Google

Google публикует три разных уровня:

Material Design 3 — язык и переиспользуемая система дизайна;
Android quality guidance — качество продукта и платформы;
web.dev — веб-реализация и полевые измерения.

HIF ОБЯЗАН различать эти уровни. Material-компоненты не гарантируют устойчивость жизненного цикла Android, доступность, надёжность или ценность. Визуально согласованный сайт также может провалить реальную производительность.

3.2 Переносимые инварианты

Адаптация структурна, а не пропорциональна. Канонические раскладки Material меняют навигацию и композицию панелей в значимых точках. HIF СЛЕДУЕТ моделировать compact, medium и expanded как преобразования тех же объектов и задач, а не растягивание холста.
Состояния взаимодействия первичны. Enabled, disabled, hover, focus, pressed, dragged и selected различны. Для сочетаний нужен приоритет и более одного цветового признака.
Качество включает ценность. Android разделяет core value, UX, техническое качество, приватность и безопасность. Визуальный блеск не компенсирует ненадёжный, бесполезный или вводящий в заблуждение продукт.
Прерывания нормальны. Поворот, складывание, background, блокировка, восстановление процесса, потеря сети и возврат из другого приложения — не крайние случаи.
Производительность — часть UX. Для веба СЛЕДУЕТ измерять LCP, INP и CLS по реальным пользователям на 75-м перцентиле релевантных сегментов. Текущие ориентиры web.dev «good»: LCP ≤ 2,5 с, INP ≤ 200 мс, CLS ≤ 0,1. Это версионируемые эвристики Google, а не вечные законы.
У метрик есть жизненный цикл. Experimental, pending и stable имеют разную устойчивость. Профиль качества фиксирует определение и версию.

3.3 Платформенные конвенции

Для Android конвенциями являются актуальные правила навигации, predictive back, окон, edge-to-edge, системных панелей, разрешений, адаптивных раскладок и жизненного цикла. Стандартные Material-компоненты — исходный выбор, когда верно передают семантику.

Цвет, типографика, формы и движение Material не универсальны. Expressive — необязательный инструмент, совместимый с reduced motion, контрастом, плотностью, культурой и задачей.

Для веба семантический HTML, навигация браузера, адресуемые URL, нативные формы, клавиатура, zoom, reflow и progressive enhancement важнее имитации app shell.

3.4 Вопросы HIF-проверки

Сохраняются ли задача и состояние при всех позах устройства и переходах жизненного цикла?
Все ли состояния отдельно смоделированы, воспринимаемы и проверяемы?
Есть ли полевые измерения, а не только быстрая лабораторная машина?
Создаёт ли продукт устойчивую ценность, а не просто engagement?
Изолированы ли экспериментальные возможности обратимым решением?

4. Apple Human Interface Guidelines

4.1 Вклад Apple

Apple понимает «feels at home» как платформенно-зависимый результат. HIG соединяет foundations, patterns, components и inputs с отдельными правилами каждой платформы. Переносим не внешний вид Apple, а дисциплину системных возможностей и ожиданий.

4.2 Переносимые инварианты

Знакомые контролы уменьшают переобучение. Предпочтительны системные компоненты и поведение, если они верно выражают смысл.
Платформенная идентичность существенна. Телефон, desktop, часы, телевизор и spatial interface не разделяют неизменную модель.
Доступность адаптивна. Нужна реакция на larger text, increased contrast, reduced motion/transparency, captions, assistive input и screen readers.
Focus не равен selection. Focus указывает цель ввода, selection меняет или обозначает состояние. Их ОБЯЗАТЕЛЬНО различать, если activation ведёт к значимому переходу.
Приватность — интерфейс. Запрос данных или возможностей требует понятного контекста, цели и момента.

4.3 Платформенные конвенции

На Apple-платформах конвенциями являются системная навигация, меню, shortcuts, окна, жесты, sheets, alerts, sharing, permissions, масштабирование текста, safe areas и ввод. Требования зависят от ОС и версии и сверяются с актуальными HIG и SDK.

SF Symbols, материалы, системные шрифты и Apple Design Resources имеют платформенные и лицензионные ограничения и не являются white-label библиотекой.

4.4 Вопросы HIF-проверки

Что сохраняет общую семантику, а что адаптируется под платформу?
Работает ли интерфейс на поддерживаемых размерах Dynamic Type?
Передают ли метки VoiceOver роль, значение, состояние и результат?
Уважаются ли системные настройки без дублирующего in-app переключателя?
Не удаляет ли custom UI возможность системного контрола?

5. Microsoft Fluent 2 и Windows

5.1 Вклад Microsoft

Принцип Fluent «natural on every platform» поддерживает нативные компоненты и знакомые паттерны для большей части опыта, оставляя custom expression ключевым моментам. Windows расширяет интерфейс за пределы canvas: окна, title bar, input, shell, установка, обновление, производительность, безопасность и доступность.

5.2 Переносимые инварианты

Согласованность сначала поведенческая. Знакомое взаимодействие и целая задача важнее одинакового рендера.
Сосредоточенность — свойство продукта. Уменьшать шум, защищать flow, ставить работу выше декора.
Семантические токены отделяют смысл от значения. Raw global tokens и alias tokens с контекстом должны быть разными слоями.
Desktop-приложение участвует в ОС. Activation, resize, inputs, title bars, файлы, notifications, install/update/uninstall и energy — части UX.
Контент функционален. Краткий активный язык и сообщения, где система принимает ответственность, снижают стоимость задачи.

5.3 Платформенные конвенции

На Windows конвенциями являются keyboard/pointer, окна, видимый focus, high-contrast/forced colours, scaling, title-bar controls, shell и shortcuts. Mica и Acrylic — условные Windows treatments, а не универсальная иерархия.

«Effortless, Calm, Personal, Familiar, Complete and Coherent» — эвристики, пока Профиль продукта не определил для них наблюдаемые основания.

5.4 Вопросы HIF-проверки

Полностью ли опыт работает с keyboard, pointer, touch и assistive inputs?
Корректно ли приложение ведёт себя как изменяемое системное окно?
Верны ли семантические токены в light, dark и forced-colour?
Включены ли install, update, interruption и recovery в journey map?
Не вытесняет ли бренд знакомые контролы?

6. IBM Carbon

6.1 Вклад Carbon

Carbon соединяет работающий код, design assets, guidance, contribution и community. Особенно переносима операционная явность: lifecycle компонентов, definition of done и видимый статус доступности.

6.2 Переносимые инварианты

Компонент решает названную проблему. Переиспользование основано на стабильной семантике и поведении, не на повторе вида.
Стабильное означает полное. Спецификация дизайна, код, документация, комплект дизайна, доступность и проверки выпускаются вместе.
Статус доступности многомерен. Состояния по умолчанию и сложные состояния, клавиатура и программа экранного доступа показываются отдельно.
Ролевые токены включают темы. Роли стабильны, значения тем меняются. Component token не используется вне компонента.
Миграция проектируется. Feature flags дают будущие breaking changes без скрытой смены текущего major.
Content входит в систему. Labels, errors и tone — качество компонента.

6.3 Конвенции системы

Палитра, типографика, grid и branded motion Carbon относятся к IBM. Контрольный список компонента, статус доступности, ролевые токены и процесс участия — переносимые эвристики.

6.4 Вопросы HIF-проверки

Стабильнее ли формулировка проблемы текущего визуального вида?
Видит ли потребитель зрелость реализации и доступности?
Включает ли done документацию и design assets?
Можно ли preview, measure и migrate breaking change?
Не дробят ли domain extensions базовую семантику?

7. Adobe Spectrum

7.1 Вклад Spectrum

Spectrum ориентирован на сложные профессиональные инструменты. Принципы рациональность, человечность и сосредоточенность поддержаны исследованиями, проверками, масштабом платформы, инклюзивным дизайном и прозрачными статусами.

7.2 Переносимые инварианты

Professional density и touch ergonomics требуют разных scales. Размеры меняются, роли и отношения сохраняются.
Сложность должна быть целевой. Профессиональная мощность не оправдывает неоднозначные icons, недокументированные states и лишний декор.
Voice стабилен, tone контекстен. Errors, onboarding и routine controls требуют разной интенсивности.
Status создаёт доверие. Индивидуальные версии, issues, checklists и implementation availability показывают реальную зрелость.
Custom interactions требуют разных inputs.
Examples входят в contract. Код примера ОБЯЗАН показывать доступную композицию, а не изолированный компонент.

7.3 Конвенции системы

Icons, бренд Adobe, точные scales и creative-tool conventions специфичны. Прозрачный статус, accessible examples, responsive scale и contextual tone переносимы.

7.4 Вопросы HIF-проверки

Проверена ли density экспертами без ущерба другим способам ввода?
Безопасны ли публичные examples для production?
Объявлены ли browsers, platforms и inputs?
Ясно ли разделены stable, beta и experimental?
Customisation идёт через поддерживаемую семантику, а не hacks?

8. Salesforce Lightning Design System

8.1 Вклад Lightning

Lightning отделяет спецификацию дизайна от среды выполнения. Схема компонента объединяет семантический HTML, CSS, атрибуты доступности и поведение, базовые компоненты дают реализацию, а точки настройки стиля — поддерживаемое изменение.

8.2 Переносимые инварианты

Схема — технологически нейтральный контракт. Анатомия, семантика, доступность и поведение не зависят от фреймворка.
Точки расширения предотвращают форки. Ограниченный публичный API стилей безопаснее private selector overrides.
Platform components несут maintenance. Поддерживаемый base component обычно дешевле повторной реализации.
Enterprise consistency включает data entry. Saving, validation, permission, record identity и long operations требуют общих паттернов.
Deprecation явна. Механизм может работать, но уже не быть рекомендуемым.

8.3 Конвенции системы

Структура Lightning, record concepts и shell специфичны Salesforce. За пределами Salesforce можно принять blueprint model, но не имитировать интеграцию внешним видом.

8.4 Вопросы HIF-проверки

Независима ли спецификация от framework?
Семантичны, ограничены и версионированы ли extension points?
Соответствует ли implementation blueprint?
Можно ли upgrade без private DOM/CSS?
Согласованы ли record, permission и validation?

9. Shopify Polaris

9.1 Вклад Polaris

Polaris строится вокруг commerce-задач продавцов и партнёров Shopify. Его доступность начинается с native web standards; ARIA используется, когда HTML недостаточно. Доступные components не гарантируют доступную composition.

9.2 Переносимые инварианты

Domain language — инфраструктура. Общие имена объектов, состояний и действий сильнее одной визуальной согласованности.
Native behaviour — первый вариант. Custom controls требуют потребности, инструкций, полной проверки и желательно стандартной альтернативы.
Переиспользуемая доступность масштабируется. Исправление компонента помогает всем потребителям.
Composition отвечает за результат. Focus order, labels, IA, errors и journeys остаются ответственностью продукта.
Ecosystem fit проверяем. Embedded app не заставляет заново учить Shopify Admin.

9.3 Конвенции системы

В Shopify Admin его навигация, terminology, surfaces и актуальный Polaris могут быть обязательны, включая distribution. Вне контекста их нельзя копировать.

9.4 Вопросы HIF-проверки

Используются ли закреплённые object/action names?
Может ли native element снизить риск?
Проверен ли journey, а не только components?
Сохраняет ли embedded experience host navigation?
Уступает ли бренд продукта доверию host platform?

10. Atlassian Design System

10.1 Вклад Atlassian

Atlassian представляет систему как foundations, components, content и tools, поддерживаемые разными профессиями. Trusted fundamentals важнее бесконечного каталога, потребности системы — разовой feature.

10.2 Переносимые инварианты

Не оптимизировать под бесконечную гибкость. Opinionated building blocks проще изучать, проверять и сопровождать.
Docs, support и tooling — features. Без них выпуск неполон.
Имена tokens выражают use. Выбор по смыслу, не совпадающему цвету.
Tooling обеспечивает migration. Typed access, linters, codemods и предупреждения соединяют решения и промышленное применение.
Встроенная доступность — основа, не гарантия.
Самообслуживание — цель управления. Обычные решения не должны ждать central team.

10.3 Конвенции системы

Бренд и shell Atlassian специфичны. Semantic tokens, constrained flexibility, migration tooling и self-service docs переносимы.

10.4 Вопросы HIF-проверки

Новая option решает повторяемую потребность или избегает решения?
Находит ли tooling raw values, deprecated tokens и unsupported use?
Объясняет ли документация композицию в полные паттерны?
Оставлена ли централизованная проверка для значимой новизны?
Можно ли развить систему один раз без search-and-replace?

11. GOV.UK Design System и Service Standard

11.1 Вклад GOV.UK

GOV.UK наиболее чётко различает component library и успешную service. Design System содержит исследованные styles, components и patterns; Service Standard оценивает whole problem, channels, inclusion, security, measurement, technology и reliable operation.

11.2 Переносимые инварианты

Решать целую проблему. Красивая транзакция недостаточна, если проверка права, доказательства, работа без сети, поддержка или последующие действия не работают.
Начинать с потребностей и наблюдаемого поведения. Паттерны обосновываются исследованием и service data, не предпочтением организации.
Progressive enhancement создаёт resilience. Semantic HTML, content без CSS и функциональный путь без JS, где возможно.
Доступные компоненты не делают услугу доступной.
Переиспользование до изобретения. Искать существующие паттерны и доказательства.
Показывать зрелость и неопределённость. Опубликованное, экспериментальное и созданное сообществом examples не равнозначны.
Определять и публиковать success measures.
Plain language — interaction design.

11.3 Платформенные и сервисные конвенции

Бренд GOV.UK, точный вид и UK content rules обязательны только для применимых услуг. Юридические обязанности зависят от юрисдикции.

Целостное мышление об услуге, подтверждённые доказательствами паттерны, прогрессивное улучшение и прослеживаемые меры переносимы.

11.4 Вопросы HIF-проверки

Какова целая проблема, включая внешние каналы?
Какие доказательства поддерживают нестандартный паттерн?
Сохраняется ли существенный сценарий при частичном отказе?
Участвовали ли люди с access needs?
Измерены ли success, failure и abandonment без вредных incentives?

12. U.S. Web Design System

12.1 Вклад USWDS

USWDS допускает поэтапное внедрение на уровнях principles, guidance и code, не приравнивая установку пакета к зрелости. Впереди визуальной формы стоят реальные потребности, заслуженное доверие, доступность, непрерывность и умение слушать.

12.2 Переносимые инварианты

Principles могут предшествовать code.
Trust зарабатывается повторно. Reliability, honesty, privacy, continuity и stewardship времени и данных — качества интерфейса.
Согласованность не равна единообразию.
Доступность — ограничение дизайна, а не финальная проверка соответствия.
Слушать нужно непрерывно. Исследования, обратная связь, поддержка и аналитика дают разные части опыта.
Adoption maturity многомерна. Code без principles и principles без coverage — разные состояния.

12.3 Конвенции системы

Федеральная идентичность, banners, notices и statutory requirements специфичны. Maturity model и trust principles переносимы.

12.4 Вопросы HIF-проверки

Раздельно ли измерены principles, guidance и code?
Какие interactions создают или разрушают trust?
Сохраняется ли continuity между продуктами, устройствами и временем?
Доходит ли feedback до способной изменить service команды?
Обоснованы ли local differences или только историчны?

13. GitHub Primer

Primer включён дополнительно как пример зрелого управления плотными, высокочастотными профессиональными интерфейсами.

13.1 Переносимые инварианты

Эффективность и доступность совместны. Компактный интерфейс остаётся инклюзивным при заранее спроектированных семантике, фокусе, целях и альтернативах.
Maturity публична. Experimental, ready и deprecated задают ожидания.
Upstream только повторяемые проверенные решения. Local component сначала созревает в использовании.
Theme-safe tokens семантичны. Base values — внутренние входы, functional/component tokens — consumer API.
Breaking change сопровождается migration.
У документации есть критерии промышленного применения. Примеры, текст, альтернативный текст, ссылки и проверка входят в качество.

Терминология, плотность и бренд GitHub остаются конвенциями системы.

14. Межотраслевые инварианты, принимаемые HIF

Следующие положения повторяются в независимых системах и совместимы с Конституцией. HIF принимает их как исходные инженерные и governance-требования при последующем нормативном оформлении.

14.1 Семантика и поведение

Начинать с людей, задач, объектов, команд, состояний и последствий.
Сохранять семантику между themes, platforms и representations.
Использовать native/established controls до custom interaction.
Описывать states, transitions, inputs и failures.
Различать focus, selection, activation, expansion и checked.
Компонент ОБЯЗАН предоставлять семантику, не только style.

14.2 Доступность и inclusion

Доступность начинается в исследовании и архитектуре.
Conformant components необходимы, но недостаточны.
Автоматические проверки, клавиатура, программа экранного доступа, масштабирование и перекомпоновка, контраст, принудительные цвета и проверка людьми дают разные доказательства и показываются отдельно.
System preferences текста, contrast, colour и motion уважаются по умолчанию.
Смысл НЕ ДОЛЖЕН зависеть только от colour, position, motion, sound или gesture.

14.3 Адаптация

Layout и navigation адаптируются без потери identity или essential capability.
Platform conventions важнее pixel equality.
Support matrix устройств, браузеров, inputs, locales и AT явна.
Density задаётся Профилем по frequency, expertise, input и access needs.

14.4 Контент

Проектирование содержания входит в спецификацию взаимодействия и компонента.
Нужны стабильный словарь предметной области, описательные подписи и сообщения о результате.
Сообщать, что произошло, последствия и следующее действие.
Voice стабилен; tone пропорционален context и risk.
Content проектируется под localisation до фиксации layout.

14.5 Архитектура системы

Разделять raw values, semantic roles и component decisions.
Согласовывать components, patterns, assets, code, docs и tests.
Предпочитать поддерживаемые точки расширения частным переопределениям.
Отдельно фиксировать зрелость, поддержку, доступность и устаревание.
Общий компонент требует повторяющейся семантической проблемы в нескольких контекстах.

14.6 Качество и управление

Определять условия готовности до присвоения стабильного статуса.
Требовать доказательства и ответственного для паттернов.
Документация, миграция и поддержка — результаты выпуска.
Измерять сценарии, техническое качество и результаты.
Публиковать ограничения и неопределённость.
High-impact failures важнее aesthetic inconsistency.

15. Различия, которые HIF сохраняет

Native или branded. Apple/Windows ставят platform familiarity выше; enterprise — family consistency. Решение зависит от host и context.
Comfort или density. Public services часто просты; professional tools плотны. Оба варианта требуют доказательств и доступности.
Progressive enhancement или application runtime. Сильный web default не является execution model offline creative tool или OS shell.
Централизованный контроль или участие сообщества. При любой форме нужны права на решения, доказательства и жизненный цикл.
Единообразие или непрерывность. Одинаковый вид редко обязателен; стабильный смысл, предсказуемый результат и связное движение обязательны.
Minimum compliance или excellence. WCAG/store/platform — пол, а не доказательство usability, dignity, trust и value.

16. Правила использования внешней системы в Профиле продукта

Профиль ОБЯЗАН записать:

систему, выпуск и дату получения;
платформы и каналы распространения;
platform/system conventions и heuristics;
packages, assets и licences;
browsers, devices, inputs и assistive technologies;
token mapping и ownership темы;
exceptions компонентов и паттернов;
известные пробелы доступности;
правила миграции и обновления;
доказательства сквозного соответствия HIF.

«Использует Material/Carbon/Polaris» не является заявлением качества. Профиль объясняет что, зачем и как проверено.

17. Источники

Ниже приведены только официальные англоязычные публикации. Дата проверки: 30 июля 2026 года.