Sergey Krylov e69f183372 feat: finalize api-envelope-contract — tests, frontend simplify, contract tests, docs

2026-06-25 06:15:26 +03:00

46 KiB

Raw Blame History

Inbox

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

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

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

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

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

Единая финансовая модель и журнал операций.
Мультиканальное получение и нормализация данных.
Банковские продукты и учёт повседневных операций.
Cash flow, бюджетирование, цели и сводная аналитика.
Несколько продуктовых поверхностей: web, PWA и браузерное расширение.
Пользовательские каналы автоматизации: 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 на основе реальных кейсов.

Провести аудит frontend debt backlog

Сначала зафиксировать текущий frontend debt как отдельную audit-фичу, а не как одну большую cleanup-инициативу.
Разделить открытые пункты на небольшие follow-up фичи: docs sync, infrastructure hardening, shared API/boundary cleanup.
Не смешивать аудит с реализацией follow-up задач; audit должен только подтвердить актуальное состояние и приоритеты.
Эпик для этой декомпозиции: Frontend Debt Backlog.

Исследовать 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. Не объединять все пункты в один большой рефакторинг без декомпозиции.

Обновление 2026-06-24: Проведён audit frontend-debt-audit. Созданы и выполнены 4 follow-up фичи: frontend-docs-sync, frontend-infrastructure-hardening, frontend-shared-boundary-cleanup, frontend-test-hygiene. Пункт P2 «Двойная система API-типов» — resolved (codegen unification). Остальные пункты ниже остаются открытыми и нуждаются в отдельных фичах.

Текущее состояние 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-контракт

RESOLVED — см. feature api-envelope-contract. TransformInterceptor — единственный владелец envelope, ApiEnvelopePayload<T> — внутренний carrier для cache metadata, frontend normalizeEnvelope упрощён, добавлен HTTP contract-тест (envelope-contract.spec.ts).

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-типов

RESOLVED — codegen unification выполнена, responses.ts удалён, единый types.ts из OpenAPI.
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 и миграционной стратегии; не включать его скрыто в локальный рефакторинг портфелей.

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

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

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

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

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

46 KiB Raw Blame History Unescape Escape