docs: expand product vision and technical debt

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?