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) как темы исследования.
• Подготовить отдельную migration-фичу для перевода legacy-таблиц на дизайн-системный DataTable, построенный поверх TanStack Table, без переноса доменной логики таблиц в DS.
• Для миграции таблиц использовать поэтапный порядок: DividendsTable → ScreenerTable → SharePositionTable → BondPositionTable, сначала уточнив минимальный API DataTable на основе реальных кейсов.

Исследовать 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 и персональные уведомления.

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

• Рассчитывать ожидаемый денежный поток по датам: дивиденды, купоны, амортизации и погашения.
• Показывать агрегаты по месяцам, инструментам, портфелям и брокерским счетам.
• Явно разделять объявленные выплаты и прогнозы; для прогнозов показывать методику и уровень неопределённости.
• Исследовать учёт количества бумаг на дату фиксации, валют, налогов, комиссий, оферт и изменений состава портфеля.
• Календарь событий должен стать источником событий, а аналитика выплат — их денежным представлением.
• Для broker-first версии закрепить follow-up на точный расчёт entitlement по истории операций, а не только по текущим позициям счёта.
• Исследовать раздельную семантику eventDate и paymentDate, чтобы будущий фильтр периода мог переключаться между датой события и датой поступления денег.
• Проверить, можно ли получить полный график купонов, амортизаций и частичных погашений, а не только ближайшие доступные bond events.
• Отдельно продумать мультивалютность, налоги и net cashflow, чтобы будущие выплаты не выглядели как гарантированная сумма к зачислению.

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

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

• Добавить график изменения стоимости портфеля во времени.
• Сохранять исторические 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?