103 lines
5.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Architecture Quality Backlog
Дата: 2026-06-25
Статус: draft
## Контекст
В репозитории уже есть несколько завершённых волн архитектурного улучшения, но после них остались:
- разрозненные остатки архитектурного долга во frontend и backend;
- устаревшие или частично противоречивые документы;
- несколько высокосвязанных зон, которые нельзя безопасно рефакторить одной крупной итерацией.
Эта фича не меняет runtime-поведение. Её задача - превратить найденные архитектурные проблемы в нормализованный, приоритизированный backlog для последующих узких refactor-фич.
## Цель
Зафиксировать актуальный архитектурный backlog по frontend, backend и проектной документации, разделить его на независимые follow-up фичи и определить порядок их выполнения.
## Требования
### 1. Инвентаризация текущего состояния
Нужно опираться на три источника:
- `apps/frontend/src/` - реальные границы слоёв, API слой, session state, query key usage;
- `apps/backend/src/` - границы NestJS-модулей, сервисов, Prisma-доступа, DTO и инфраструктурных клиентов;
- `docs/` и `apps/docs/docs/` - roadmap, epics, feature specs/plans/tasks и опубликованная архитектурная документация.
### 2. Нормализация находок
Каждый найденный пункт долга должен быть отнесён к одной из категорий:
- уже закрыто;
- устарело и требует пересмотра документации;
- открыто и должно стать отдельной follow-up фичей;
- открыто, но пока должно остаться в backlog без немедленной реализации.
### 3. Приоритизация
Backlog должен быть упорядочен по следующему правилу:
- сначала низкорисковые и высокосигнальные документы/contract cleanup задачи;
- затем сервисные границы backend;
- затем frontend state/API hardening;
- позже - крупные или спорные refactor-направления.
### 4. Границы будущих фич
Каждый backlog-item должен быть независимым настолько, чтобы его можно было превратить в отдельную feature-spec без смешивания frontend и backend implementation work в одном change-set.
### 5. Никаких новых возможностей
Фича не должна:
- менять пользовательские сценарии;
- добавлять новые API;
- менять модель данных;
- вводить новые библиотеки или инфраструктуру;
- исправлять runtime-bug'и вне рамок документации и backlog-формализации.
## Предлагаемый backlog
### 1. Documentation Source-of-Truth Sync
Синхронизировать roadmap, epics и опубликованные architecture docs с текущим состоянием кода, убрать устаревшие статусы и противоречия.
### 2. Backend Service Boundary Cleanup
Сделать явными границы `PortfolioService`, `TBankModule` и связанных сервисов, чтобы последующие refactor-фичи можно было изолировать по доменам.
### 3. Backend Contract Type-Safety Hardening
Закрыть свободные строки и dynamic access в screener/T-Bank контрактных зонах, не меняя публичный API.
### 4. Frontend Session Model Simplification
Свести session state к одной понятной точке истины и убрать лишние внутренние импорты между слоями.
### 5. Frontend Query-Key and API Wrapper Hardening
Нормализовать query key factories и повысить устойчивость API request layer к contract drift.
## Ограничения
- Только docs/backlog scope.
- Не трогать runtime-код в рамках этой фичи.
- Не объединять в один backlog-item несвязанные frontend и backend работы.
- Не добавлять новые продуктовые требования.
## Критерии приемки
- Есть один согласованный backlog с приоритетом и кратким обоснованием по каждому пункту.
- Для каждого backlog-item указаны:
- цель;
- риск;
- зависимости;
- ожидаемый артефакт follow-up фичи;
- причина, почему item не закрыт уже сейчас.
- Документация не противоречит текущему коду и уже завершённым refactor-волнам.
- Backlog отражён в `docs/roadmap.md` и связан с релевантными epics/feature docs.
- В рамках этой фичи не изменены файлы `apps/frontend/src/**` и `apps/backend/src/**`.