55 lines
3.2 KiB
Markdown
55 lines
3.2 KiB
Markdown
## Why
|
||
|
||
T-Bank-backed flows сейчас опираются на одни и те же правила подключения,
|
||
валидности token и поддерживаемых счетов в нескольких местах. Поставленное
|
||
поведение должно быть согласованным: отсутствие connection, невалидный token,
|
||
недоступный account и неподдерживаемый account type должны обрабатываться
|
||
одинаково, когда User открывает счета, Portfolio, Account Ledger или Future
|
||
Cash Events.
|
||
|
||
Текущая реализация повторяет это знание между backend flows. Из-за этого
|
||
будущие изменения supported-account rules или обработки invalid-token легко
|
||
применить не полностью, создав тихое расхождение поведения между экранами,
|
||
которые должны разделять одну access model. Review от 25 авг 2026 подтвердил
|
||
дублирование и отметил code-level fix как требующий этого SDD path.
|
||
|
||
## What Changes
|
||
|
||
- Консолидировать backend rules для T-Bank connection и supported-account
|
||
access так, чтобы каждый T-Bank-backed flow использовал одну внутренне
|
||
согласованную policy.
|
||
- Сохранить существующее observable behavior для users и frontend callers:
|
||
успешные ответы, missing-connection errors, invalid-token errors,
|
||
unavailable-upstream errors и inaccessible-account errors остаются
|
||
совместимыми с текущим delivered contract.
|
||
- Сохранить локальную MVP boundary: frontend продолжает обращаться только к
|
||
backend, T-Bank credentials остаются server-side, а runtime caches остаются
|
||
in-memory.
|
||
- Non-goal: вводить новые T-Bank account types, менять HTTP routes, менять
|
||
форму response DTO, менять token storage semantics, добавлять historical
|
||
storage или менять frontend UI behavior.
|
||
- Non-goal: исправлять несвязанные frontend architecture findings, включая
|
||
auth-gating в hooks или форму account page VM/view.
|
||
|
||
## Capabilities
|
||
|
||
### New Capabilities
|
||
|
||
_Нет._
|
||
|
||
### Modified Capabilities
|
||
|
||
_Нет._
|
||
|
||
Это behavior-preserving backend refactor. Change отказывается от Delta Specs
|
||
через `skip_specs: true`, потому что spec-level behavior не должно меняться.
|
||
Любое обнаруженное изменение поведения должно вернуться к Proposal/Delta Specs
|
||
до Design.
|
||
|
||
## Impact
|
||
|
||
Users и frontend callers не должны увидеть изменённого product behavior.
|
||
Затронутая implementation area — backend T-Bank access logic; specs отслеживает
|
||
SDD lifecycle для refactor. Documentation changes ожидаются только если Design
|
||
обнаружит as-built behavior nuance, который ещё не задокументирован.
|