moex-vibe/docs/inbox.md

# Inbox

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

## Долгосрочное продуктовое видение

MoexVibe может постепенно трансформироваться из приложения для анализа инвестиций в приложение для
ведения всех личных финансов. Цель — дать пользователю целостный контроль над финансовым потоком:
активами, обязательствами, доходами, расходами, переводами, накоплениями и инвестициями.

Предполагаемым центром системы является единый журнал финансовых операций (ledger). Балансы,
cash flow, бюджеты, аналитика, прогнозы и автоматизация должны строиться поверх него. Это направление
пока является архитектурной гипотезой и требует отдельного исследования и ADR до реализации.

Вероятная декомпозиция будущего продукта:

1. Единая финансовая модель и журнал операций.
2. Мультиканальное получение и нормализация данных.
3. Банковские продукты и учёт повседневных операций.
4. Cash flow, бюджетирование, цели и сводная аналитика.
5. Несколько продуктовых поверхностей: web, PWA и браузерное расширение.
6. Пользовательские каналы автоматизации: Telegram и agent/MCP-интерфейсы.

## Финансовое ядро

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

- Определить каноническую модель операции, которая сможет представлять доход, расход, перевод,
  комиссию, процент, инвестиционную операцию и корректировку.
- Строить balances и аналитику как вычисляемые представления журнала, сохраняя возможность аудита и
  повторного расчёта.
- Разделять дату совершения операции, дату фактического списания/зачисления и дату получения данных,
  если источник предоставляет эти значения.
- Продумать валюты, статусы операций, категории, контрагентов, теги, комментарии и связи между
  несколькими записями одной составной операции.
- Отдельно исследовать переводы между своими счетами, возвраты, отмены, частичные списания,
  дублирование и ручные корректировки.
- Начать с ledger-first подхода внутри модульного монолита; полный event sourcing рассматривать только
  при появлении подтверждённой необходимости.

### Поддержать несколько способов получения данных

- Не предполагать, что каждый банк или брокер предоставляет доступный и стабильный API.
- Рассматривать API, импорт файлов и ручной ввод как равноправные адаптеры одного ingestion-контура.
- Возможные источники: T-Bank API, API других провайдеров, CSV/XLSX, банковские выписки, брокерские
  отчёты и ручной ввод.
- Использовать общий поток обработки:
  `источник → сырой импорт → нормализация → проверка дублей → журнал → расчёты`.
- Хранить происхождение (provenance) нормализованной записи: тип источника, исходный идентификатор,
  время импорта и ссылку на оригинальные данные.
- Сохранять исходные данные отдельно от канонической операции, чтобы импорт можно было повторить после
  изменения правил нормализации.
- Исследовать идемпотентность синхронизации, reconciliation, обнаружение дублей и понятный пользователю
  разбор конфликтов.
- Определить безопасные сроки хранения сырых выписок и чувствительных банковских данных.

## Банковские продукты и повседневные финансы

### Добавить банковские вклады

- Учитывать сумму, валюту, ставку, срок, даты открытия и закрытия, капитализацию, пополнения и частичные
  снятия, если они предусмотрены продуктом.
- Прогнозировать процентные выплаты и окончание срока вклада в общем календаре событий и cash flow.
- Исследовать эффективную доходность, налоги, автоматическую пролонгацию и досрочное закрытие.

### Добавить накопительные счета

- Учитывать плавающую ставку, ежедневный остаток и различные банковские правила начисления процентов.
- Хранить историю ставок и условий, если она нужна для проверки фактических начислений и прогнозов.
- Поддержать пополнения и снятия как обычные операции единого журнала.

### Добавить металлические счета

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

### Учитывать операции по банковским картам

- Импортировать или вводить доходы, расходы, переводы, комиссии, cashback и возвраты.
- Категоризировать операции вручную и правилами; позже исследовать автоматические рекомендации
  категорий.
- Поддержать разницу между авторизацией и финальным списанием, если источник даёт оба события.
- Использовать карточные операции для cash flow, анализа расходов, бюджетов и контроля регулярных
  платежей.
- Исследовать наличные, совместные расходы, разделение одной покупки на категории и переводы между
  собственными счетами.

### Развить контроль финансового потока

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

## Продуктовые поверхности

### Развивать приложение по API-first принципу

- Web/PWA, браузерное расширение, Telegram и MCP/agent-интерфейсы должны использовать общие backend
  application services и API-контракты.
- Финансовые расчёты, правила доступа и изменения ledger не должны дублироваться внутри отдельных
  клиентов.
- Переиспользовать дизайн-токены, форматы данных и подходящие UI-компоненты, но не пытаться сделать
  один интерфейс одинаковым для большого экрана, мобильного устройства и popup расширения.
- Вероятная последовательность развития:
  `браузерное приложение → адаптивный web → устанавливаемая PWA → расширение быстрого доступа → Telegram → MCP/agents`.

### Сделать мобильную PWA

- На первом этапе дать мобильный доступ через Progressive Web App без публикации в App Store и
  Google Play.
- Обеспечить адаптивный интерфейс, установку на домашний экран и корректную работу основных сценариев
  на небольшом экране.
- Исследовать безопасный локальный кеш и явно различать offline-режим, устаревшие данные и актуальные
  данные с backend.
- Не хранить чувствительные финансовые данные и токены в клиентском кеше без отдельной модели угроз и
  обоснованной необходимости.
- Отдельно исследовать push-уведомления, фоновые обновления, ограничения iOS/Android и критерии, при
  которых позднее понадобится нативное приложение.
- Проверять PWA на реальных мобильных viewport'ах, accessibility, плохой сети и восстановлении после
  offline-режима.

### Добавить браузерное расширение быстрого доступа

- Первая версия должна давать компактный доступ к балансу, краткой финансовой сводке, последним
  операциям и ближайшим событиям/выплатам.
- Добавить быстрый ручной ввод расхода с подтверждением и понятным исправлением ошибок.
- Использовать минимально необходимые browser permissions и безопасную авторизацию с возможностью
  отозвать доступ отдельного расширения.
- В первой версии не читать и не анализировать содержимое посещаемых страниц и не внедрять content
  scripts; такие возможности могут рассматриваться только как отдельная будущая фича.
- Не переносить полный web-интерфейс в popup: выбрать несколько коротких сценариев и предусмотреть
  переход в основное приложение за подробностями.
- Исследовать общий пакет API-клиента и дизайн-токенов для web/PWA и расширения, сохраняя независимые
  UI-композиции.

## Пользовательские каналы и автоматизация

### Добавить Telegram-бота

- Начать с безопасных read-only сценариев: баланс, расходы за период, будущие выплаты, события и
  состояние синхронизации.
- Рассмотреть быстрый ручной ввод расходов и заметок только после проектирования подтверждений,
  идемпотентности и исправления ошибок.
- Продумать привязку Telegram-аккаунта, отзыв доступа, минимизацию чувствительных данных в сообщениях и
  защиту команд, изменяющих финансовые записи.
- Бот должен использовать те же application services и правила расчёта, что и web-интерфейс, а не
  создавать параллельную бизнес-логику.

### Исследовать MCP/agent-интерфейс

- Рассмотреть MCP-подобный сервер для подключения OpenClaw, Hermes Agent и других совместимых агентов.
- Начать с узких read-only tools/resources для запросов баланса, cash flow, портфелей, событий и
  аналитики.
- Для любых изменений данных предусмотреть явное подтверждение пользователем, ограниченные scopes,
  аудит вызовов и отзыв доступа.
- Не выдавать агентам банковские токены или необработанные секреты; доступ должен проходить через
  контролируемый API MoexVibe.
- Исследовать защиту от prompt injection, ограничение объёма финансовых данных, rate limits и
  маскирование чувствительной информации.
- Telegram-бот, MCP и будущие клиенты должны быть каналами над общим application layer, а не отдельными
  источниками истины.

## Frontend-платформа

### Перейти к Feature-Sliced Design

- Постепенно привести frontend к FSD-архитектуре с явными границами между `app`, `pages`, `widgets`,
  `features`, `entities` и `shared`.
- Не делать одномоментное переписывание: сначала исследовать текущие зависимости и определить
  миграционную стратегию по вертикальным срезам.
- До начала работ определить правила публичных API слоёв, допустимых импортов и размещения
  TanStack Query hooks/API-клиентов.

### Создать дизайн-систему

- Зафиксировать визуальные токены: цвета, типографику, отступы, размеры, состояния и адаптивность.
- Добавить тёмную тему на основе семантических токенов, предусмотрев системное предпочтение и ручное
  переключение.
- Собрать базовые компоненты для форм, таблиц, навигации, обратной связи и визуализации данных.
- Исследовать варианты: собственный слой компонентов, готовая библиотека наподобие MUI или гибридный
  подход. Отдельно оценить TanStack Table как основу сложных таблиц.
- Определить, нужна ли дизайн-система только внутри monorepo или как отдельный npm-пакет.
- Предусмотреть accessibility, визуальные regression-тесты и каталог компонентов (например,
  Storybook) как темы исследования.

### Исследовать Backend-Driven UI

- Рассматривать BDUI как исследовательскую гипотезу, а не выбранную целевую архитектуру.
- Проверить, какие сценарии действительно требуют серверной конфигурации интерфейса: состав
  аналитических блоков, таблиц, фильтров или dashboard.
- Сравнить пользу BDUI со сложностью версионирования схем, типизации, кеширования, тестирования и
  обратной совместимости.
- Рассмотреть более лёгкие альтернативы: feature flags, server-driven configuration или schema-driven
  формы и таблицы.

## Качество frontend

### Развивать автоматические тесты

- В проекте уже есть Vitest, Testing Library, MSW и frontend-тесты; идея заключается в развитии
  покрытия и quality gates, а не в создании тестовой инфраструктуры с нуля.
- Определить целевую тестовую пирамиду: unit-тесты бизнес-логики, component/integration-тесты
  пользовательских сценариев и небольшой набор E2E smoke-тестов.
- Исследовать контроль покрытия, обязательные проверки в CI, accessibility-тесты и visual regression.
- При переходе к FSD закрепить тесты за срезами и использовать их как страховочную сетку поэтапной
  миграции.

## Производительность API

### Исследовать и улучшать производительность API

- Сначала определить измеримые цели и собрать baseline по задержкам, частоте ошибок и наиболее
  дорогим endpoint'ам.
- Исследовать узкие места в запросах к MOEX и T-Bank, агрегации данных, кеше, Prisma-запросах и
  сериализации ответов.
- Рассматривать оптимизации только после измерений: batching, индексы, кеширование, pagination,
  фоновые обновления и ограничение параллелизма.
- Не смешивать производительность с устойчивостью: быстрый ответ и доступность последней копии данных
  при отказе внешнего API являются связанными, но разными задачами.

## Каталог и исследование инструментов

### Улучшить поиск инструментов

- Искать не только по точному тикеру, но также по названию, ISIN и другим доступным идентификаторам.
- Исследовать ранжирование результатов, fuzzy search, подсказки, историю запросов и быстрые фильтры по
  типу инструмента.
- Продумать обработку одинаковых тикеров, разных режимов торгов, опечаток и отсутствующих результатов.
- Проверить, какие улучшения должны выполняться на backend, а какие относятся только к UX frontend.

### Сделать таблицы акций и облигаций информативнее

- Определить отдельные наборы ключевых колонок для акций и облигаций вместо одной универсальной
  перегруженной таблицы.
- Исследовать сортировку, фильтрацию, настройку и сохранение колонок, закрепление, пагинацию и
  виртуализацию больших наборов данных.
- Для акций рассмотреть цену, изменение, капитализацию, дивидендные показатели, ликвидность и уровень
  листинга.
- Для облигаций рассмотреть доходность, дату погашения, купон, НКД, дюрацию, оферту, амортизацию,
  ликвидность и кредитный рейтинг.
- Состав полей и источники данных определить отдельным исследованием; этот список пока является
  гипотезой.

### Показывать кредитные рейтинги облигаций

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

## События и будущие выплаты

### Добавить календарь будущих событий

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

### Добавить аналитику будущих выплат

- Рассчитывать ожидаемый денежный поток по датам: дивиденды, купоны, амортизации и погашения.
- Показывать агрегаты по месяцам, инструментам, портфелям и брокерским счетам.
- Явно разделять объявленные выплаты и прогнозы; для прогнозов показывать методику и уровень
  неопределённости.
- Исследовать учёт количества бумаг на дату фиксации, валют, налогов, комиссий, оферт и изменений
  состава портфеля.
- Календарь событий должен стать источником событий, а аналитика выплат — их денежным представлением.

## Портфельная аналитика

### Показывать историю баланса портфеля

- Добавить график изменения стоимости портфеля во времени.
- Сохранять исторические snapshots или восстанавливать историю из операций; сравнить точность,
  стоимость хранения и сложность обоих подходов.
- Отделять изменение стоимости активов от внешних денежных потоков: пополнений, выводов, покупок,
  продаж, комиссий и налогов.
- Исследовать поддержку брокерских и ручных портфелей, нескольких валют и сравнения с benchmark.

### Создать отдельный раздел аналитики

- Развить существующую аналитику портфеля в отдельное направление, а не дублировать уже реализованные
  показатели PnL и распределения.
- Рассмотреть доходность за выбранный период, абсолютный и относительный результат, денежные потоки,
  структуру активов, вклад отдельных позиций, будущие выплаты и сравнение с benchmark.
- До реализации выбрать корректные методики доходности (например, money-weighted/XIRR и
  time-weighted return) и правила обработки вводов/выводов.
- Продумать единый аналитический слой для ручных портфелей и данных брокерских счетов при сохранении
  различий между их источниками.

### Экспортировать аналитику в PDF и XLSX

- PDF рассматривать как человекочитаемый отчёт, XLSX — как структурированные данные для дальнейшего
  анализа.
- Определить состав отчёта, период, валюту, временную зону, формат чисел и метаданные об актуальности
  источников.
- Исследовать генерацию на backend и frontend, ограничения больших отчётов, фоновые задачи и
  повторяемость расчётов.
- Экспорт должен использовать те же расчёты, что и экран аналитики, чтобы показатели не расходились.

## Устойчивость данных T-Bank

### Сохранять доступность данных при отказе T-Bank API

- Текущий краткоживущий кеш не считать полноценным резервированием.
- Исследовать периодические устойчивые snapshots счетов, позиций, операций и необходимых метаданных
  инструментов в собственной БД.
- При недоступности T-Bank показывать последнюю успешную копию с явным статусом устаревших данных и
  временем последнего обновления.
- Определить допустимую давность данных, расписание синхронизации, retries/backoff, reconciliation и
  поведение после восстановления API.
- Отдельно проработать безопасность токенов, шифрование чувствительных данных, сроки хранения,
  удаление пользовательских данных и резервное копирование собственной БД.
- Исследовать деградацию по частям: свежие рыночные цены могут оставаться доступны через MOEX, даже
  если позиции и операции T-Bank временно не обновляются.

## Технический долг — кандидат на следующую итерацию

Результаты аудита от 2026-06-19. Перед реализацией нужно оформить отдельную maintenance-фичу или
технический эпик с границами итерации, acceptance criteria, plan и tasks. Не объединять все пункты в
один большой рефакторинг без декомпозиции.

Текущее состояние quality gates хорошее: на момент аудита проходят lint, format-check, backend build,
frontend build, 94 backend-теста и 168 frontend-тестов.

### P0/P1: изолировать данные T-Bank по пользователям

- Сейчас аутентификация и ручные портфели являются многопользовательскими, но T-Bank использует один
  server-side токен, а broker endpoints доступны любому пользователю с ролью `user`.
- `BrokerOperation` и `BrokerOperationSyncState` не содержат владельца или подключения, поэтому
  сохранённая история также не имеет пользовательской изоляции.
- До расширения приложения определить целевую модель: строго single-user deployment либо
  пользовательские broker connections с ownership, scopes и безопасным хранением токенов.
- Закрыть возможность одному пользователю видеть или синхронизировать счета другого пользователя.

### P1: унифицировать API envelope и runtime-контракт

- Часть контроллеров возвращает `{ data, meta }`, после чего глобальный `TransformInterceptor`
  оборачивает ответ повторно.
- Frontend содержит `normalizeEnvelope`, который поддерживает одновременно одинарную и двойную
  обёртку; это маскирует расхождение runtime-ответов со Swagger/OpenAPI.
- Выбрать единственного владельца envelope: interceptor либо контроллеры, удалить двойную обёртку и
  временный compatibility-код после миграции.
- Добавить интеграционные contract-тесты реальных HTTP-ответов, а не только DTO/OpenAPI schemas.

### P1: усилить production-конфигурацию и auth security

- Запрещать production-запуск с дефолтными JWT access/refresh secrets и валидировать обязательные
  переменные окружения при старте.
- Заменить отражение любого CORS origin на явный allowlist для соответствующего окружения.
- Не возвращать внутренний `Error.message` клиенту при необработанных ошибках; логировать подробности
  только на backend с безопасной корреляцией запросов.
- Исследовать rate limiting для регистрации, входа, refresh и тяжёлых sync endpoints.
- Проверить cookie policy, CSRF-модель и security headers перед появлением PWA и расширения.

### P1: сделать локальную историю T-Bank рабочим read-path

- Синхронизация уже записывает операции и состояние в Prisma, но пользовательское чтение истории
  продолжает обращаться напрямую к T-Bank.
- Определить источник истины и стратегию чтения: local-first, upstream-first с fallback или явные
  режимы свежих/архивных данных.
- Показывать время последней успешной синхронизации, полноту диапазона и статус устаревших данных.
- Выполнять запись страниц транзакционно или с безопасным checkpoint, предусмотреть повторный запуск,
  reconciliation и частично завершённую синхронизацию.
- Оптимизировать последовательные upsert'ы больших страниц после измерения реальной нагрузки.

### P1/P2: подготовить модель сессий к нескольким поверхностям

- Сейчас у пользователя хранится один hash refresh token; вход или refresh перезаписывает предыдущую
  сессию.
- Для браузера, PWA, расширения, Telegram и MCP исследовать отдельные сессии/устройства, rotation,
  reuse detection, scopes, аудит и точечный отзыв доступа.
- Не расширять существующую single-token модель на новые клиенты без отдельного threat model.

### P2: устранить двойную систему frontend API-типов

- `src/api/types.ts` генерируется из OpenAPI, но frontend в основном использует вручную поддерживаемый
  `src/api/responses.ts`.
- Выбрать source of truth и миграционный путь к generated contract types, сохранив вручную только
  действительно frontend-specific view models.
- Запретить незаметное расхождение nullable/optional полей и envelope между backend и frontend.

### P2: декомпозировать крупные backend/frontend модули

- `PortfolioService` объединяет CRUD, ownership, MOEX enrichment, кеширование, расчёты PnL,
  дивиденды и агрегированную аналитику.
- Broker UI содержит крупные страницы, таблицы и монолитный test suite; это усложнит FSD-миграцию и
  повторное использование на PWA/extension.
- Выделять границы по ответственности и публичным интерфейсам, избегая механического дробления файлов
  без архитектурной цели.
- В frontend постепенно отделить entities/features/widgets/shared и унифицировать форматтеры,
  таблицы, состояния загрузки и ошибок.

### P2: сократить неконтролируемую типовую небезопасность

- В обоих ESLint-конфигах отключён `no-explicit-any`; аудит обнаружил 95 приведений `as any`.
- Основные зоны: динамические gRPC clients T-Bank, screener filters, optimistic updates и broker tests.
- Сначала добавить типизированные границы для protobuf/gRPC и тестовые factories, затем постепенно
  усиливать lint rule без массового шумного rewrite.

### P2: расширить стратегию тестирования

- Тестов много, но CI не задаёт coverage thresholds и не содержит E2E smoke-набора.
- Добавить runtime contract tests для API envelope, интеграционные тесты ownership/tenancy и security
  regression tests.
- Усилить покрытие портфельных hooks/pages, screener и ошибок синхронизации.
- Позже добавить небольшой Playwright-набор для ключевых пользовательских путей, accessibility и PWA.

### P3: оптимизировать frontend delivery

- Сейчас страницы импортируются eager, а production bundle frontend на момент аудита составляет
  примерно 471 KB JavaScript до gzip.
- Исследовать route-level lazy loading, разделение тяжёлых графиков/таблиц и bundle analysis.
- Зафиксировать performance budgets до появления PWA и новых продуктовых поверхностей.

### P3: подготовить финансовые типы данных к будущему ledger

- Текущие `Float` для цены, `Int` для количества и JSON-строки достаточны только для части нынешних
  сценариев и не должны автоматически стать основой общего финансового журнала.
- Для ledger отдельно спроектировать decimal/money типы, валюту, точность, округление, signed amounts,
  fractional quantities и immutable raw source data.
- Изменение финансовой модели потребует ADR и миграционной стратегии; не включать его скрыто в
  локальный рефакторинг портфелей.

## Предварительная карта зависимостей

Карта не задаёт приоритеты и сроки, а только показывает вероятные технические связи:

1. Автотесты, границы frontend-архитектуры и базовые решения по дизайн-системе создают фундамент для
   безопасных UI-изменений.
2. Улучшенный поиск и информативные таблицы используют этот фундамент и уточняют модель данных
   инструментов.
3. Календарь событий формирует нормализованный источник данных для аналитики будущих выплат.
4. Устойчивое хранение snapshots T-Bank поддерживает историю баланса и достоверную аналитику во время
   сбоев внешнего API.
5. История портфеля и согласованные методики расчёта доходности предшествуют полноценному разделу
   аналитики и экспорту.
6. BDUI имеет смысл оценивать после появления нескольких стабильных аналитических и табличных
   сценариев; до этого его польза не доказана.
7. Каноническая модель операции и ingestion-контур предшествуют банковским продуктам, учёту расходов,
   бюджетам и общей cash flow аналитике.
8. Telegram-бот и MCP/agent-интерфейсы должны появляться после стабилизации application services,
   модели авторизации и аудита финансовых операций.
9. Адаптивный web и стабильные API-контракты предшествуют PWA; безопасная авторизация и короткие
   application-сценарии предшествуют браузерному расширению.
10. Все поверхности используют единые расчёты и правила доступа, но развивают интерфейсы независимо
    под ограничения конкретного канала.
11. Tenancy T-Bank, production security, единый API-контракт и модель сессий являются фундаментом до
    подключения PWA, расширения, Telegram, MCP и новых источников финансовых данных.
12. Рабочий local read-path брокерской истории и корректные money-типы предшествуют единому ledger и
    надёжной cash flow аналитике.

## Отложенные вопросы

- Какие портфели являются основным объектом будущих функций: ручные, брокерские T-Bank или оба типа?
- Какие внешние источники событий и рейтингов допустимы по качеству, стоимости и лицензированию?
- Какие форматы выписок и отчётов банков и брокеров нужно поддержать первыми?
- Насколько подробным должен быть ручной учёт, если автоматический импорт недоступен?
- Нужны ли уведомления помимо Telegram: внутри приложения, email или push?
- Какие действия Telegram-боту и агентам можно разрешить помимо чтения данных?
- Какие сценарии PWA должны работать offline, а какие требуют обязательного соединения?
- Какие браузеры нужно поддержать расширением после первой версии?
- При каких ограничениях PWA появится необходимость в нативном мобильном приложении?
- Должна ли дизайн-система распространяться на другие приложения вне текущего monorepo?