5.5 KiB
WealthLedger: документация проекта
WealthLedger помогает частному инвестору понимать состав портфеля, исполненные операции, полученные доходы и будущие выплаты по счетам T-Bank. Приложение работает локально; данные брокера получает backend. Здесь объясняются понятия, границы системы, ключевые сценарии и причины решений.
Первое знакомство
- Прочитайте обзор системы: пользователи, внешние системы, исполняемые части и движение данных.
- Откройте карту возможностей: выберите предметную область и найдите её поведение, ограничения и ответственность компонентов.
- Сверяйте незнакомые понятия с глоссарием. Особенно важны различия между User, Session, подключением и брокерским счётом, между полученным доходом и прогнозом выплаты.
- Изучите локальное окружение и один сценарий: вход → подключение T-Bank → счёт → портфель → доходы или события.
После этого вы должны уметь объяснить, откуда приходит финансовое значение, какой компонент им владеет и где проверить его ограничения.
Найти ответ по задаче
| Вопрос | Начать здесь |
|---|---|
| Как части проекта работают вместе? | Обзор и схемы |
| Как устроена конкретная возможность и кто за неё отвечает? | Карта возможностей |
| Что означает термин или финансовый показатель? | Глоссарий |
| Почему выбраны эти архитектурные ограничения? | Решения ADR |
| Какие условия нужны для работы и как понимать локальные ошибки? | Окружение и восстановление |
| Где точные API-типы, статусы и правила изменения контракта? | HTTP API и генерация контракта |
| Как проверяются согласованность и качество системы? | Сопровождение |
| Как обновлять знания вместе с кодом? | Ведение документации |
Тематический индекс связывает вопросы с соответствующими объяснениями. Читать весь репозиторий для ответа на один вопрос не требуется.
Какому источнику доверять
Документация объясняет текущее устройство и поведение системы. Точный публичный HTTP-контракт публикует backend в OpenAPI; ADR сохраняют причины принятых решений. Требования и предложения изменений могут отдельно согласовываться в OpenSpec, но для понимания описанных сценариев доступ к нему не нужен. Карта владельцев фактов помогает различать назначение этих знаний и разрешать расхождения.
Текущие объяснения находятся в architecture и features; руководства — в
development. Исследования содержат проверенные наблюдения
и варианты, аудиты — исторические свидетельства.
Наличие рекомендации в исследовании или требования в старом change ещё не
означает, что возможность реализована. Статус каждого ADR указан в
журнале решений.
Основная документация читается самостоятельно, без исходников других репозиториев. Исторические свидетельства сохраняют исходные технические адреса своего времени и не являются обязательным чтением для понимания системы. Документы используют Markdown, схемы — Mermaid.