Лучший фреймворк — тот, который соответствует вашим ограничениям

Начните с чёткого определения «лучшего»

«Лучший фреймворк» не имеет смысла, пока вы не ответите: лучший для чего, для кого и при каких ограничениях. Интернетное «лучше» часто подразумевает другой размер команды, бюджет, терпимость к риску или стадию продукта, нежели у вас.

Определите «лучшее» для вашего продукта (а не для интернета)

Начните с одной фразы, которая прямо связана с вашими целями. Примеры:

• «Лучший означает, что мы можем выпустить MVP за 8 недель с текущей командой и сохранить высокую скорость итераций.»
• «Лучший означает предсказуемую производительность при пиковом трафике с минимальной операционной нагрузкой.»
• «Лучший означает готовность к комплаенсу и аудиту, даже если разработка будет медленнее.»

Эти определения потянут вас в разные стороны — и это правильно.

Почему «лучшее» меняется в зависимости от контекста

Фреймворк может быть идеальным для компании с выделенным DevOps, но плохим для маленькой команды, которой нужно управляемое хостинг-решение и простая развёртка. Фреймворк с большой экосистемой может сократить время разработки, в то время как новый — потребует больше кастомной работы (и несёт больше рисков). «Лучший» меняется с графиком, кадрами и стоимостью ошибки.

Ожидания: это рамки для принятия решения, не рейтинг

Эта статья не провозгласит универсального победителя. Вместо этого вы получите повторяемый способ принять обоснованное решение по стеку — такое, которое можно объяснить заинтересованным и пересмотреть позже.

Что здесь считается «фреймворком»

Мы используем «фреймворк» широко: UI-фреймворки (веб), бэкенд-фреймворки, мобильные фреймворки и даже data/ML-фреймворки — всё, что задаёт конвенции, структуру и компромиссы для того, как вы строите и эксплуатируете продукт.

Выпишите ваши безусловные результаты

Прежде чем сравнивать фреймворки, решите, что вы должны получить от выбора. «Лучшее» имеет смысл только когда вы знаете, что оптимизируете — и чем готовы жертвовать.

Разделяйте цели по аудитории

Начните с трёх корзин:

• Пользовательские цели: скорость, удобство, надёжность, доступность.
• Бизнес-цели: влияние на выручку, стоимость, время выхода на рынок, способность к пивоту.
• Инженерные цели: поддерживаемость, тестируемость, наблюдаемость, продуктивность разработчиков.

Это удерживает разговор от абстрактности. Фреймворк, который радует инженеров, но замедляет релизы, может провалить бизнес-цели. Фреймворк, который быстро доставляет, но тяжёл в эксплуатации, может ухудшить надёжность и нагрузку on-call.

Превратите «предпочтения» в измеримые результаты

Запишите 3–5 результатов, достаточно конкретных, чтобы оценивать варианты. Примеры:

• Время до рынка: «Выпустить первую версию за 8 недель командой из 3 человек.»
• Производительность: «Ключевые страницы загружаются за \u003c2.5s на среднем мобильном в 4G.»
• Надёжность: «Поддерживать 99.9% аптайма с понятными откатом и мониторингом.»
• Доступность: «Соответствовать WCAG 2.1 AA для всех публичных флоу.»
• Поддерживаемость: «Новые инженеры могут выпускать изменения в течение первых 2 недель; покрытие юнит-тестами 80%+ для критической логики.»

Сделайте их действительно невозмутимыми

Если всё — «must», то ничего не обязательно. Для каждого результата спросите: Рассмотрим ли мы фреймворк, который этого не достигает? Если да — это предпочтение, а не ограничение.

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

Пропишите реальные ограничения, которые действительно вас ограничивают

Многие дебаты о фреймворках — это на самом деле дебаты об ограничениях. Как только вы выпишете ограничения, многие варианты автоматически отпадут — и обсуждение станет спокойнее и короче.

Ограничения по времени

Начните с календаря, а не с предпочтений. Есть ли у вас фиксированная дата релиза? Как часто нужно выпускать обновления? На какой период поддержки вы обязуетесь (клиентам, внутренним командам, по контракту)?

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

Ограничения по людям

Будьте честны в отношении тех, кто будет строить и поддерживать продукт. Размер команды и опыт важнее, чем «что сейчас в тренде». Небольшая команда часто выигрывает от конвенций и жёстких дефолтов; большая команда может позволить себе больше абстракций и кастомизации.

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

Ограничения по деньгам

Стоимость — это не только лицензии. Хостинг, управляемые сервисы, мониторинг, минуты CI/CD и сторонние интеграции складываются.

Самая большая скрытая статья расходов — альтернативная стоимость: каждая неделя, потраченная на изучение нового фреймворка, борьбу с инструментами или переписывание, — это неделя, не потраченная на улучшение продукта или ценности для клиента. «Бесплатный» фреймворк может быть дорогим, если он замедляет доставку или вызывает больше инцидентов.

Если вы взвешиваете купить или строить, включите инструменты ускорения в модель стоимости. Например, платформа vibe-coding вроде Koder.ai может сократить стоимость «первой версии» (веб, бэкенд или мобильное), генерируя рабочую базу из чата — полезно, когда главный ограничитель — время, а не чистота выбранного фреймворка.

Ограничения процесса

Некоторые ограничения исходят из того, как работает ваша организация: утверждения, проверки безопасности, закупки и ожидания стейкхолдеров.

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

Соотнесите фреймворк с жизненным циклом продукта

Выбор фреймворка проще, когда перестать считать его навсегда. Разные фазы продукта вознаграждают разные компромиссы — согласуйте выбор с тем, как долго это нужно жить, насколько быстро будет меняться и как вы ожидаете эволюцию.

MVP: оптимизируйте скорость обучения

Для короткого MVP ставьте выше время выхода на рынок и скорость разработчиков, а не долгосрочную элегантность. Фреймворк с сильными конвенциями, хорошим скэлффолдингом и множеством готовых компонентов поможет вам выпустить и получить обратную связь быстро.

Ключевой вопрос: пожалеете ли вы через 3–6 месяцев, что тратили дополнительные недели на «будущую устойчивость»?

Многолетняя платформа: оптимизируйте поддержку и сопровождение

Если вы строите платформу на годы, основная стоимость — поддержка. Выбирайте фреймворк, который поддерживает чёткие границы (модули, пакеты, сервисы), предсказуемые пути обновлений и простой, документированный способ решения обычных задач.

Будьте честны в отношении команды: поддерживать большую систему вдвоём иначе, чем с выделенной командой. Чем выше ожидаемая текучка, тем больше цените читаемость, конвенции и большой пул найма.

Ожидаемая скорость изменений: стабильность vs частые пивоты

Стабильные требования благоприятствуют фреймворкам, оптимизирующим корректность и согласованность. Частые пивоты — фреймворкам, которые позволяют быстрые рефакторинги, простую композицию и низкую церемонию. Если вы ожидаете еженедельных изменений продукта, выбирайте инструменты, которые делают переименование, перемещение и удаление кода безболезненными.

Запланируйте стратегию выхода

Решите заранее, как это закончится:

• Переписывание: приемлемо для MVP — задокументируйте границы, чтобы можно было заменить модульно.
• Модульная замена: проектируйте швы для замены частей без полного рестарта.
• Долгосрочная эволюция: выбирайте фреймворк с сильным релизным циклом и гайдами по миграции.

Запишите это сейчас — будущее «вы» скажет вам спасибо.

Поймите стоимость сложности

Выбор фреймворка — это не только набор функций, это принятие счета за поддержание дополнительной сложности. «Мощный» стек может быть правильным, но только если команда может позволить себе дополнительные движущиеся части.

Когда простой стек лучше продвинутого

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

Общая сложность — это не только код

Сложность проявляется во всём рабочем процессе:

• Инструменты: дополнительные CLI, генераторы, плагины, форматы конфигурации.
• Шаги сборки: более длинные пайплайны, больше кэширования, проблемы «работает у меня».
• Развёртывание: специальные требования к runtime, краевые случаи хостинга, фиксация версий.
• Отладка: глубокие слои абстракций, менее очевидные трассировки, сложнее воспроизвести.

Фреймворк, который экономит вам 20% кода, может стоить в 2× больше времени на отладку, если сбои становятся менее прозрачными.

Скрытые расходы: онбординг, CI/CD, апгрейды

Сложность накапливается со временем. Новым сотрудникам нужен более долгий вход, CI/CD становится строгим и хрупким, апгрейды превращаются в мини-проекты — особенно если экосистема быстро движется и вводит breaking changes.

Спросите: как часто фреймворк выпускает крупные релизы? Насколько болезненны миграции? Зависите ли вы от сторонних библиотек, которые отстают? Есть ли стабильные паттерны для тестирования и развёртывания?

Предпочитайте «скучные» решения, когда важна предсказуемость

Если ваши ограничения ставят в приоритет надёжность, простоту найма и стабильную итерацию — выбирайте «скучные» фреймворки со зрелыми инструментами и консервативной стратегией релизов. Предсказуемость — это фича, которая прямо защищает время выхода на рынок и долгосрочную поддержку.

Оцените навыки команды и реалии найма

Фреймворк может быть «идеален» на бумаге и всё же оказаться плохим выбором, если команда не может уверенно его строить и эксплуатировать. Самый быстрый путь сорвать сроки — поставить на стек, который понимает только один человек.

Начните с того, что команда уже может выпустить

Посмотрите на текущие сильные и слабые стороны честно. Если доставка зависит от одного эксперта («героя»), вы принимаете скрытый риск: отпуск, выгорание или уход превратятся в инцидент продакшена.

Запишите:

• Что команда уже использует в продакшене (и может дебажить под давлением).
• Что знакомо, но не проверено в продакшене.
• Что никто не использовал кроме туториалов.

Реалии найма — часть архитектуры

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

Кривая обучения vs дедлайн

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

Используйте простую матрицу навыков

Составьте лёгкую матрицу навыков (члены команды × требуемые навыки: фреймворк, тестирование, развёртывание, наблюдаемость). Затем выберите путь, минимизирующий единичные точки экспертизы и максимизирующий способность нанимать и онбордить.

Производительность и масштабирование: подобрать размер решения

Производительность редко — это одна цифра. «Достаточно быстро» зависит от поведения пользователей, их местоположения и того, чего вам стоит медлительность (брошенные корзины, тикеты поддержки, отток). Перед сравнением фреймворков пропишите цели, которые действительно имеют значение.

Установите конкретные цели производительности

Определите небольшой набор измеримых целей, например:

• Время загрузки: например, FMP \u003c2s на среднем мобильном.
• Задержка: например, ответы API \u003c150 ms на 95-м процентиле.
• Пропускная способность: X запросов в секунду в нормальном и пиковом режимах.

Эти числа — ваш базис. Также задайте потолок (максимум, который вам реально нужен в ближайшие 12–18 месяцев). Это поможет не выбирать чрезмерно сложный стек «на всякий случай».

Оценивайте масштаб по реальным паттернам

Масштаб — это не только «сколько пользователей». Это также:

• Объём данных и скорость роста.
• Пиковые паттерны трафика (дни запуска, отчётные окна, сезонные пики).
• Фоновые нагрузки (импорты, отчёты, уведомления).

Фреймворк, хорошо работающий при ровном трафике, может страдать от бурстов, если вы не проектируете под них.

Операционные ограничения важны не меньше сырой скорости

Спросите, что ваша команда сможет надёжно поддерживать:

• Модель хостинга (serverless, контейнеры, управляемые платформы).
• Уровень зрелости мониторинга и алёртинга.
• Ожидания по on-call и реакции на инциденты.

Немного более медленный, но легко наблюдаемый фреймворк может лучше работать в реальности: простота операционной поддержки — реальный выигрыш.

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

Безопасность, комплаенс и управление рисками

Безопасность — это не фича, которую «добавляют потом». Выбор фреймворка либо снижает риск безопасными дефолтами, либо создаёт постоянные уязвимости через слабые инструменты, медленные патчи и сложность аудита.

Начните с реальных потребностей в безопасности

Будьте конкретны: что нужно защищать и каким образом. Частые требования: аутентификация и авторизация (роли, права, SSO), защита данных (шифрование в транзите и покое) и гигиена зависимостей (знание того, какой сторонний код вы шипите).

Практический тест: можно ли реализовать принцип наименьших привилегий без изобретения собственных паттернов? Если «стандартный путь» во фреймворке неясен или непоследователен — вы получите различия в безопасности между командами и сервисами.

Комплаенс — это не только бумажки

Если к вам применимы SOC 2, HIPAA или GDPR, фреймворк должен поддерживать контролы, под которые будут приходить аудиты: логирование доступа, отслеживание изменений, реагирование на инциденты, политики хранения и удаления данных.

Также учитывайте границы данных. Фреймворки, которые поощряют чёткое разделение ответственности (API vs слой хранения, фоновые задачи, управление секретами), обычно упрощают документирование и доказательство контролей.

Зрелость экосистемы: патчи, CVE и поддержка

Посмотрите на частоту патчей и реакцию сообщества на CVE. Есть ли активная команда безопасности? Ясны ли релиз-ноты? Быстро ли обновляются крупные зависимости, или вы регулярно застреваете на старых версиях?

Если вы используете сканирование безопасности (SCA, SAST), убедитесь, что фреймворк и его экосистема хорошо интегрируются с вашими инструментами.

Безопасные дефолты и аудитируемость

Предпочитайте фреймворки, которые по умолчанию включают безопасные заголовки, CSRF-защиту там, где нужно, безопасные cookie и понятные паттерны валидации. Не менее важно: можно ли последовательно аудитировать конфигурацию и поведение в рантайме по всем окружениям?

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

Поддерживаемость и эксплуатация со временем

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

Пути обновления, с которыми можно жить

Посмотрите на ритм релизов проекта и частоту breaking changes. Частые релизы — хороши, но только если апгрейды управляемы. Проверьте наличие:

• Понятных гайдлайнов миграции и автоматизированных codemod-ов.
• Политик обратной совместимости (или честных дедлайнов на депрекейты).
• Частого пролома зависимостей (core plugins ломаются при каждом обновлении фреймворка).

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

Поддержка тестирования, соответствующая реальности

Поддерживаемые системы имеют надёжные тесты, которые реально запускать. Предпочитайте фреймворки с первой очередью поддержки unit, integration и end-to-end тестов, и здравой моделью моков. Учитывайте, насколько хорошо вписываются обычные инструменты: локальные раннеры, CI-пайплайны, snapshot-тестирование и управление тестовыми данными.

Эксплуатация: можно ли быстро дебажить продакшен?

Фреймворк должен облегчать наблюдаемость, а не оставлять её на потом. Убедитесь, что можно добавить:

• Структурированные логи с корреляцией запросов.
• Метрики и дашборды по ключевым пользовательским путям.
• Трейсинг для определения медленных зависимостей.
• Репорты ошибок с читаемыми стек-трейсами и source maps.

Долговременный опыт разработчика

Хорошая документация и стабильные общеупотребительные паттерны уменьшают «племенное знание». Отдавайте предпочтение фреймворкам с хорошими инструментами (линтеры, форматтеры, поддержка типов), консистентными конвенциями и активными мейнтейнерами. Со временем это снижает стоимость онбординга и сохраняет предсказуемость доставки.

Совместимость с экосистемой и требования интеграций

Фреймворк не выбирается в вакууме — он должен дружить с существующими инструментами, вендорами и потоками данных в вашей компании. Если фреймворк делает обычные интеграции громоздкими, вы будете платить эту цену каждый спринт.

Начните с карты интеграций

Раннее выпишите реальные точки интеграции: платежи, аналитика, CRM и хранилище данных. Для каждой укажите, нужен ли официальный SDK, библиотека из сообщества или достаточно тонкого HTTP-клиента.

Например, платёжные провайдеры часто требуют специфических flow подписи, верификации вебхуков и идемпотентности. Если фреймворк противоречит этим конвенциям, «простая интеграция» станет постоянным источником поддержки.

Учитывайте стиль API

Фреймворк должен соответствовать выбранному стилю API:

• REST: важны роутинг, валидация, пагинация и инструменты OpenAPI.
• GraphQL: центральны schema-first, батчинг, кэширование и директивы авторизации.
• Event-driven: фоновые воркеры, повторные попытки, dead-letter очереди и наблюдаемость — обязательны.

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

Не игнорируйте платформенные ограничения

Веб, мобильные, десктопные и встроенные окружения накладывают разные требования. Фреймворк, идеальный для server-rendered веба, может не подойти мобильному продукту с оффлайн-поддержкой, фоновым синком и строгими лимитами на размер бандла.

Проверьте зрелость и нейтральность вендора

Смотрите дальше за счёт звёзд на GitHub. Оценивайте ритм релизов, гарантии совместимости и количество мейнтейнеров. Отдавайте предпочтение библиотекам, которые не привязывают вас к одному вендору, если только это не осознанный выбор.

Если сомневаетесь, добавьте пункт «уверенность в интеграции» в матрицу оценки и привяжите допущения в документе решения (см. /blog/avoid-common-pitfalls-and-document-the-decision).

Составьте шортлист и оцените прозрачно

После того как вы определили результаты и ограничения, прекратите абстрактные споры. Соберите шортлист 2–4 опции, которые на бумаге выглядят жизнеспособно. Если фреймворк явно не проходит жёсткое ограничение (например, требуемая модель хостинга, лицензия или критическая интеграция), не держите его «на всякий случай».

Сформируйте компактный шортлист

Хороший шортлист достаточно разнообразен, чтобы сравнить компромиссы, но достаточно мал, чтобы честно оценить каждую опцию. Для каждого кандидата напишите одно предложение «почему он может выиграть» и одно «почему он может провалиться». Это удерживает оценки от хайпа.

Оцените по невозмутимым целям и рискам

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

Пример (оценки 1–5, выше лучше):

Посчитайте Weighted Score = Weight × Score и суммируйте по каждому фреймворку. Смысл не в математической «истине», а в дисциплине, делающей видимыми расхождения в мнениях (например, кто-то ставит интеграции 5, кто-то — 2).

Задокументируйте допущения, чтобы решение оставалось объяснимым

Рядом с матрицей зафиксируйте ключевые допущения (ожидания трафика, ограничения развёртывания, план найма, обязательные интеграции). Когда приоритеты поменяются, вы сможете обновить входные данные и пересчитать, вместо того чтобы заново спорить о всём.

Валидируйте через тайм-боксированный PoC

Решение о фреймворке — не акт веры. Перед тем как окончательно закрепиться, проведите небольшой строгий PoC, который снимет самые большие неизвестности — быстро.

Жёсткий тайм-бокс (2–5 дней)

Держите его коротким, чтобы не «влюбиться» в прототип, но достаточно длинным, чтобы задействовать реальные интеграции. Определите, что нужно узнать к концу спайка (не что построить).

Если ваш главный риск — скорость, а не глубокие технические неизвестности, подумайте о параллельном подходе: один инженер «спайкает» фреймворк, другой использует инструмент ускорения (например, Koder.ai), чтобы сгенерировать рабочую базу из чата. Сравнение результатов по одним и тем же ограничениям прояснит: строим традиционно, ускоряемся или комбинируем подходы.

Прототипируйте самый рискованный элемент

Не делайте самый простой демо-пэйдж. Постройте то, что вероятнее всего сломает план, например:

• Auth + role-based access с вашим реальным провайдером идентификации.
• Критический flow со server rendering, кэшированием и выборкой данных.
• Ключевую интеграцию (платежи, CRM, аналитика), которая управляет вашей бизнес-логикой.

Если фреймворк не справится с рискованной частью чисто — остальные плюсы не имеют значения.

Измеряйте то, что будет больно позже

Зафиксируйте конкретные сигналы пока работа свежа:

• Время сборки (локально и в CI).
• Размер бандла и его влияние на загрузку.
• Задержка API (end-to-end).
• DX friction: время настройки, ясность дебага, эргономика тестов, качество документации.

Записывайте числа, не впечатления.

Решение: фиксируем, переключаемся или сузить scope

Завершите PoC мемо: что сработало, что нет и что бы изменили. Результат — одно из трёх: закрепиться на фреймворке, перейти к другому кандидату или сузить объём продукта, чтобы в него влезть.

Если платный инструмент или уровень подписки влияет на выполнимость, проясните стоимость заранее (см. /pricing). Например, у Koder.ai есть тарифы Free, Pro, Business и Enterprise, которые меняют экономику быстрого прототипирования против найма.

Избегайте распространённых ловушек и задокументируйте решение

Хорошие выборы фреймворков чаще разрушаются процессом, а не технологией. Решение простое: сделайте компромиссы явными и зафиксируйте, почему вы выбрали именно это.

Частые ловушки

• Гнаться за трендами: «все так делают» — не требование. Если новый инструмент не снимает реальное ограничение (время, найм, интеграции, надёжность), это отвлечение.
• Подгонка под одного инженера: фреймворк, который понимает только один человек, — риск доставки, а не ускорение.
• Игнорирование затрат выхода: миграция, переобучение, новые операционные инструменты и переписывание интеграций — часть цены.
• Давать краевые сценарии решать за всё: оптимизируйте под 80% пути, оставшиеся 20% решайте таргетированно.

Когда стоит менять фреймворк (и когда нет)

Меняйте, когда текущий стек блокирует критические результаты: отсутствие возможностей безопасности/комплаенса, постоянные проблемы с надёжностью, невозможность нанять/удержать людей или платформенные ограничения, заставляющие делать постоянные костыли.

Не меняйте только потому, что где-то «может быть» лучше производительность, интерфейс выглядит устаревшим или вы хотите модернизировать ради модернизации. Если продуктные требования можно решить инкрементально — переключение обычно несёт больше риска, чем пользы.

Зафиксируйте решение через ADR

Используйте лёгкий Architecture Decision Record, чтобы будущие команды понимали «почему»:

# ADR: Framework Selection for \u003cProduct\u003e

## Status
Proposed | Accepted | Superseded

## Context
What problem are we solving? What constraints matter (timeline, team skills, integrations, compliance)?

## Decision
We will use \u003cFramework\u003e for \u003cScope\u003e.

## Options Considered
- Option A: \u003c...\u003e
- Option B: \u003c...\u003e

## Rationale
Top reasons, with evidence (benchmarks, PoC notes, team feedback).

## Consequences
What gets easier/harder? Risks and mitigations. Migration/rollback plan.

## Review Date
When we will revisit this decision.

(Блок кода выше оставлен в исходном виде.)

Повторно используемый чек-лист

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