diff --git a/docs/inbox.md b/docs/inbox.md index fa9b04f..eed5561 100644 --- a/docs/inbox.md +++ b/docs/inbox.md @@ -1,15 +1,475 @@ # Inbox -## Ideas +Идеи ниже не являются утверждёнными требованиями или roadmap. Перед реализацией каждой идеи нужно +проверить существующие артефакты, провести исследование и подготовить спецификацию нужного масштаба. -- Добавить календарь дивидендов -- Добавить экспорт портфеля в Excel -- Добавить темную тему -- Показывать прогноз дивидендов +## Долгосрочное продуктовое видение -## Improvements -- Перфоманс api -- Улучшить поиск по тикеру +MoexVibe может постепенно трансформироваться из приложения для анализа инвестиций в приложение для +ведения всех личных финансов. Цель — дать пользователю целостный контроль над финансовым потоком: +активами, обязательствами, доходами, расходами, переводами, накоплениями и инвестициями. -## Questions -- Нужна ли поддержка вкладов? +Предполагаемым центром системы является единый журнал финансовых операций (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?