main/audits/2026-10-11/reports/13-reliability-and-security-report.md

# Аудит 13 — Reliability & Security

## 1. Audit metadata

- **Audit ID:** 13, Reliability & Security.
- **Дата:** 2026-10-11.
- **Workspace:** `/Users/ksv741/Project/vibe/WealthLedger`.
- **Режим:** пассивный read-only аудит исходников, конфигураций, существующих тестов и behavioral specs. Единственный созданный файл — этот отчёт вне четырёх исследованных репозиториев.

| Repo | Найденный путь относительно workspace | Точный HEAD | Начальный `git status --short` |
| --- | --- | --- | --- |
| backend | `backend/` | `0ad84ff4f0b4712abc7e69dc299856f14af6eadd` | Пустой, дерево чистое |
| frontend | `frontend/` | `c8821200ce699dab1ce65360d1968d5877a2e78b` | Пустой, дерево чистое |
| specs | `specs/` | `fcdc805f6c1b3be6a20a7e858e3e80cbd83a9121` | Пустой, дерево чистое |
| docs | `docs/` | `e6fd4f64b81dd73b33959b845a1babcfac1891c8` | Пустой, дерево чистое |
| workspace root | `./` | `dc030f84c979cedb2628ef4bd97c62d6c63a9256` | Пустой, дерево чистое |

Прочитаны собственные `AGENTS.md` всех четырёх репозиториев и применимые локальные правила. Правила использовались для навигации, а не как доказательство корректности или необходимости механизма.

**Skills:** установленный `ponytail-audit` найден и прочитан. По его фактическому контракту security/correctness находятся вне его scope: он применён только к вопросу безопасного удаления/упрощения защит. Такие удаления не обоснованы; число удаляемых строк/dependencies не оценивалось. Security-проход выполнен по `security-review` с трассировкой входов, проверкой ownership и контраргументов. `graphify` прочитан, существующий `graphify-out/graph.json` не найден; построение графа и установка пакетов не выполнялись из-за read-only ограничения.

**Предыдущий аудит:** `audit-results/technical-audit-2026-10-11.md` использован как реестр гипотез. Выводы ниже заново проверены по указанным исходникам и вызывающим путям. Совпадающие гипотезы отмечены в Related IDs, но прежний отчёт не служит доказательством.

**Что запускалось:** `git status --short`, `git rev-parse HEAD` в root и четырёх repos; точечные файловые/content searches; два статических подсчёта контроллеров и HTTP-декораторов через `rg`. При завершении по `verification-before-completion` — повторные Git status и `git diff --check`, просмотр нового отчёта, `git check-ignore` для его пути и `git diff --no-index --check /dev/null audit-results/13-reliability-and-security-report.md` для whitespace нового ignored файла.

**Что не запускалось:** приложение, HTTP-запросы, payload attacks, реальные T-Bank/MOEX/NCR API, тесты, build, full-suite/verify, install, codegen, миграции, dependency/secret scanners, чтение реальной БД и env dump. Тесты ниже **прочитаны, но не исполнены**. Runtime-воспроизведение и фактическая конфигурация production — `UNVERIFIED`.

Root `.gitignore:1–37` игнорирует `audit-results/`; allowlist не менялся. `deploy/` обнаружен как дополнительный самостоятельный checkout и не включён в аудит четырёх repos. Для deployment рассмотрены только предоставленный root `compose.yaml`, frontend Nginx config и тематическая docs.

## 2. Executive verdict

1. **Факт / P1:** ошибка persistence в дочерней работе или завершении hourly может оставить durable `running`. Координатор ждёт без конечной границы, а следующий обход того же процесса отклоняется. Это наиболее важный отказ восстановления, потому что затрагивает дальнейшую свежесть нескольких финансовых ресурсов — RISK-001.
2. **Факт / P2:** исключение общего уровня обхода не добавляется в список failures и может завершиться как `succeeded`. Сохранённые данные при этом не обязательно обновлены — RISK-002.
3. **Факт / P2:** выбор fallback прогнозов способен блокировать новый полный результат для изменившегося окна; календарь облигаций после первой загрузки вообще не освежается обычным hourly-путём. Это два независимых механизма сохранения устаревших выплат — RISK-003/004.
4. **Факт / P2:** основной экран счёта теряет уже подготовленную metadata портфеля и скрывает failure фонового чтения. Пользователь не получает необходимого контекста сохранённых сумм — RISK-005.
5. **Факты / P2:** online instrument paths превращают постоянную ошибку брокерского token в `500`; нижняя граница пароля имеет разные единицы frontend/backend. Оба дефекта имеют локальные исправления у существующих владельцев — RISK-006/007.
6. **Сохранённые гарантии:** в выбранных потоках не найден подтверждённый IDOR, SQL injection, XSS или передача брокерского token в публичный ответ. Ownership, generation/attempt fences, banking CAS/fingerprint/tombstones и точная денежная арифметика нужны. Это вывод о проверенной выборке, а не сертификат отсутствия уязвимостей во всей системе.
7. **Риск / `UNVERIFIED`:** в приложении и поставляемом Nginx нет ограничения публичных login/register попыток; внешний HTTPS proxy может закрывать этот риск, но его конфигурация не предоставлена — RISK-008. Подтверждённых P0, эксплуатаций и измерений ущерба нет.

Итого: **7 дефектов по коду** — один P1 и шесть P2; **1 условный security risk** с Decision `INVESTIGATE`. Основная работа — корректные failure states и recovery, а не сокращение защит или внедрение нового framework.

## 3. Inventory & coverage

### 3.1. Фактический стек и метод подсчёта

- Backend: NestJS/TypeScript, Prisma с `adapter-better-sqlite3`, локальная SQLite, bcrypt, JWT, Pino, T-Bank gRPC; MOEX/NCR HTTP — `backend/package.json:40–67`, `backend/src/prisma/prisma.service.ts:12–30`, `backend/prisma/schema.prisma:1–9`.
- Frontend: React/Vite SPA, TanStack Query, generated OpenAPI transport, auth в памяти; PWA cache только статической оболочки — `frontend/package.json:39–62`, `frontend/vite.config.ts:45–51`.
- Найдено **11 controller source files и 52 HTTP method declarations**. Метод: из `backend/` выполнены `rg --files src/modules -g '*.controller.ts' | wc -l` и `rg --count '^\s*@(Get|Post|Put|Patch|Delete)\(' src/modules -g '*.controller.ts'`; второй результат суммирован: `1+2+1+10+2+3+8+2+14+5+4=52`. Это source inventory, не runtime route count; Swagger/framework routes и внешние proxies не включены.
- При просмотре guards все 48 прикладных declarations защищены class-/method-level `JwtAuthGuard`; четыре намеренно публичных — register, login, refresh, logout. Наличие guard отдельно не принималось за доказательство object authorization.

### 3.2. Asset / threat map

| Asset | Actor / capability | Entry point | Значимая угроза | Проверенный владелец / controls |
| --- | --- | --- | --- | --- |
| User credentials, Session | Неаутентифицированный клиент; владелец действующей cookie | `/auth/register`, `/login`, `/refresh`, `/logout` | Подбор, replay, конкурирующая rotation, утечка | Runtime DTO, bcrypt, generic login error, HS256/type/TTL, refresh hash CAS, cookie boundary |
| Brokerage credentials | Авторизованный User; поздний RPC прежнего подключения | PUT/DELETE `/tbank-connection` | Plaintext exposure, повреждение рабочего подключения, late writes | Проверка token до transaction, AES-GCM, атомарная замена generation, каскады |
| Accounts, portfolio, value history | User с чужим accountId или старой generation | Brokerage account reads / background publication | IDOR, раскрытие прежних данных, ложная свежесть | User/revision/account-scoped queries, подтверждённая membership, conditional publish |
| Bank cards, operations, refunds | User с чужими nested IDs; retry/lost response; competing writers | `/bank-cards/**` | Cross-user links, double effect, lost update, refund overrun | Owner checks внутри transaction, client UUID + fingerprint, version CAS, tombstone, BigInt |
| Ledger / income | User с чужим/устаревшим cursor; malformed upstream page | Operations/income GET, staged publication | Перескок owner/filter, частичный reconciliation | HMAC cursor + binding, scoped reads, stage markers, atomic publication |
| Public catalog, screener artifacts | User с чужим searchId; отказ token producer | Stocks/bonds search/detail/company | Межпользовательский результат, error poisoning, лишние retries | Projection, searchId owner/revision/TTL, credentials separated from shared public rows |
| Stored forecasts / durable work | Ошибка сети/SQLite, смена membership, process crash | Hourly walk, forecast resolution | Неверные суммы, устаревший forecast, вечный running | Dependency versions, transactional fences, processRunId; найденные пробелы RISK-001–004 |
| Logs / backup | Оператор; сторонний читатель логов/копий | HTTP completion, application events, recovery runbook | Secrets/PII exposure, утрата ключа/данных | Safe completion fields, redaction, allowlist, отдельный encryption key; live storage не проверено |

### 3.3. Threat Boundary Matrix — семь прослеженных семейств потоков

| Flow | Вход → обязательная boundary → consumer | Проверка nested ownership / replay | Результат |
| --- | --- | --- | --- |
| 1. Login / refresh / logout | AuthController → CredentialsDto/AuthService → Session и AuthProvider/shared fetch | JWT algorithm/type, hash rotation; неуспешный refresh не пишет cookie | CAS сохранить; password mismatch RISK-007; perimeter RISK-008 |
| 2. Replace / delete connection | Controller `request.user.sub` → TbankConnectionService → token validator/crypto → SQLite transaction → frontend reset | Client userId не authority; old generation каскадно удаляется; неудачная validation сохраняет старую connection | Проверенные fences сохранить |
| 3. Portfolio / events / all | Guard + user.sub → `access.local(userId, accountId)` → scoped repositories/ForecastService → AccountPage | `all` ограничен membership пользователя; forecasts scoped user+revision; нет fallback другого owner | RISK-003/004/005; confirmed IDOR path не найден |
| 4. Ledger / income / sync status | Controllers → access.local → scoped readPage и cursor HMAC/binding → durable work status | Binding включает userId, revision, account revisions и filters; sync status читает user/revision/id | Authorizing checks сохранить; read-owner drift — cross-audit signal |
| 5. Banking create / transfer / refund / update / delete | Guard → DTO/input → BankCardsRepository.write → owner lookups + CAS + DB constraint → explicit DTO | Проверены source/target card, category, original expense, duplicate UUID другого owner, deleted replay | Равносильной замены fingerprint/CAS/tombstone не найдено; KEEP |
| 6. Instrument search / detail / screener | Guard → current/onlineToken → fixed upstream → public projection; searchId → owner+revision+TTL | Public instrument sources отделены от personal holdings; screener pages проверяют User и generation | RISK-006; shared public cache сам по себе не утечка |
| 7. Hourly work / publication / restart | Native timer → reserveHourly → membership/portfolio/operations/events owners → conditional settle | AttemptId/processRunId и transaction fences; stale publication не становится актуальной | RISK-001/002; multi-process lease пока не нужен при одном процессе |

**Основные evidence для матрицы:** `backend/src/modules/auth/application/auth.service.ts:64–140,166–201`; `backend/src/modules/auth/presentation/auth.controller.ts:81–137`; `backend/src/modules/investments/tbank-connection/tbank-connection.controller.ts:32–56`; `backend/src/modules/investments/tbank-connection/tbank-connection.service.ts:31–88`; `backend/src/integrations/tbank/tbank-access.service.ts:148–237,262–288`; `backend/src/modules/investments/operations/infrastructure/brokerage-operations.repository.ts:82–148`; `backend/src/modules/investments/operations/application/brokerage-operations.service.ts:347–388`; `backend/src/modules/investments/tbank-sync/tbank-sync.service.ts:313–389`; `backend/src/modules/banking/bank-cards/application/bank-operations.service.ts:94–240,251–330`; `backend/src/modules/investments/instruments/stocks/application/stock-screener.service.ts:65–109`.

### 3.4. Репрезентативность и пределы

Выборка risk-based: все controller guards просмотрены, а детальная трассировка ограничена семью семействами выше и их общими security/persistence boundaries. Прочитаны репрезентативные configured HTTP/SQLite tests: auth rotation/storage failures, banking foreign links/refund race/replay, forecast filtering/late calendar; наличие test source не доказывает его прохождение.

Pattern searches в frontend `src/**/*.{ts,tsx}` по `dangerouslySetInnerHTML|innerHTML|eval\(|new Function|localStorage|sessionStorage` и backend `src/**/*.ts` по unsafe/raw SQL, `child_process`, `execSync`, `eval` совпадений не дали. Это ограниченный inventory потенциальных sinks, не автоматический SAST и не доказательство безопасности всех данных.

Вне покрытия: dependency CVE audit, все финансовые формулы/инструменты, вся active OpenSpec history, CI/tooling, реальные secrets и DB, серверные права/HTTPS/WAF, live restore, raw/generated artifact scans. Отсутствие `graphify` graph и информации о внешнем proxy ограничивает только соответствующие способы подтверждения, не отменяет source findings.

## 4. Security & Reliability Findings

### RISK-001 — Durable `running` не имеет гарантированного выхода после persistence failure

- **Decision = FIX; Severity = P1; Confidence = High; Effort = M.** Тип: дефект recovery по коду; частота SQLite failures `UNVERIFIED`.
- **Evidence:** `backend/src/modules/investments/tbank-sync/tbank-hourly.scheduler.ts:166–189,197–218`; `backend/src/modules/investments/tbank-sync/tbank-sync.repository.ts:190–201,223–242`; `backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:563–593`; `backend/src/modules/investments/operations/application/brokerage-operations-sync.service.ts:195–230,296–301`.
- **Claim:** кратковременная ошибка publish/finish/fail либо settle может закончить process-level работу, оставив durable row `running`. Hourly waiter не имеет deadline; `reserveHourly` не заменяет такой row в том же processRunId.
- **Current mechanism:** events refresh возвращает work IDs; `settledWorks` опрашивает их каждые 100 ms до выхода из `running`. Общий catch enrichment очищает completions/active/queue, но не переводит abandoned rows в terminal state. `settleHourly(...).catch(() => undefined)` также подавляет ошибку записи.
- **Threat model:** свежие personal datasets → storage failure/прерванный worker → publish/finish или settle → предположение «каждый running обязательно завершится» → бесконечное ожидание и запрет следующего обхода → existing attempt/generation fences → bounded observation и согласованный recovery.
- **Impact / actual cost:** автоматическое обновление connection может остановиться до restart или иного пути, заново резервирующего дочернюю работу. Также остаётся периодический DB polling. **Impact unmeasured**: число затронутых connections, длительность и DB/runtime cost не измерены.
- **Why now:** hourly — текущий владелец обновления personal datasets; пассивный portfolio GET не исправляет lifecycle. Если stuck row принадлежит hourly, даже восстановление SQLite само по себе его не освобождает.
- **Minimum change:** ограничить ожидание дочерних attempts; различать завершённую и abandoned работу; при восстановившемся storage условно завершать/перерезервировать запись по исходному attemptId. Ошибку самого settlement сделать наблюдаемой и повторно сверять её на штатном tick. Одного дополнительного UPDATE в catch недостаточно, если SQLite ещё недоступна.
- **Guarantees at risk:** timeout не равен cancellation RPC. При освобождении work поздний ответ должен проиграть attempt/generation fence; старый child не должен завершить новый attempt. Сохранённые успешные snapshots нельзя удалять ради выхода из running.
- **Counterarguments / trade-offs:** перезапуск помогает благодаря processRunId, а новый data request иногда восстановит child; это не гарантированное восстановление в живом процессе. Межпроцессный lease проблему одного процесса не решает. Ограничение observation должно учитывать допустимую длительность большого портфеля.
- **Verification or rollback:** isolated SQLite regression с однократным отказом `publishSource`/`finish` и отдельно `settleHourly`: storage восстанавливается, row выходит из running, следующая eligibility разрешает новую работу, late publication старого attempt отклоняется. Существующие suites hourly не проверяют: `backend/test/upcoming-events.e2e-spec.ts:140–147` подменяет scheduler. Runtime proof сейчас `UNVERIFIED`; rollback локальных lifecycle changes не должен менять schema/data.
- **Related finding IDs:** RISK-002, RISK-004; прежняя гипотеза technical F2 заново подтверждена.

### RISK-002 — Общая ошибка обхода может публиковаться как полный успех

- **Decision = FIX; Severity = P2; Confidence = High; Effort = S.** Тип: code-level correctness bug статуса.
- **Evidence:** `backend/src/modules/investments/tbank-sync/tbank-hourly.scheduler.ts:93–110,113–125,145–151,178–190`; `backend/src/modules/investments/tbank-sync/tbank-sync.repository.ts:32–56,245–271`; consumer `backend/src/modules/investments/portfolio/application/portfolio.service.ts:55–75,207–229`.
- **Claim:** exception из `membership.request`, `workError`, `access.local` или orchestration попадает в общий catch без добавления failure. Пустой `failures` становится `succeeded`, даже когда обязательные шаги не выполнены.
- **Current mechanism:** итог выводится из длины failures и счётчика attempted, а не из достигнутого завершения обязательного обхода. Например, `membership.request` может бросить до первого increment; catch вызывает `settle([], 0)` → `succeeded`.
- **Threat model:** trustworthy freshness/outcome → DB exception → walk catch → отсутствие локального failure ошибочно принимается за успех → клиент получает ложный `lastAttempt` → existing безопасные public codes → явно unsuccessful aggregate outcome.
- **Impact / actual cost:** пользователь и диагностика видят успешный обход со старыми либо отсутствующими данными. **Impact unmeasured**; payload не обязательно повреждён — дефект в достоверности статуса.
- **Why now:** этот status переносится в metadata нескольких финансовых resources; он нужен для понимания ошибок обновления.
- **Minimum change:** общий catch обязан явно фиксировать безопасную причину и failed/partial outcome; считать skipped mandatory sections незавершёнными. Использовать текущие progress/sections и logger, не вводить новый status framework.
- **Guarantees at risk:** успешные account snapshots должны сохраняться при частичной ошибке. Смена/deletion connection — interruption, а не ложная проблема новой generation. Не выводить raw exception/message в public sections.
- **Counterarguments / trade-offs:** локальные operations/events catches уже добавляют failures и работают лучше; они не защищают исключения вне своих блоков. `attempted` не доказывает completion и может давать partial при фактическом отсутствии выполненных обязательных секций.
- **Verification or rollback:** controlled orchestration case с reject membership reservation до increment и с reject `workError` после завершённого child: `lastAttempt` не succeeded, сохранённый payload неизменен. Проверить отдельный partial-success case. Runtime proof `UNVERIFIED`.
- **Related finding IDs:** RISK-001, RISK-005; прежняя technical F2.

### RISK-003 — Overlapping fallback блокирует публикацию нового полного forecast

- **Decision = FIX; Severity = P2; Confidence = High; Effort = M.** Тип: code-level correctness bug и расхождение behavioral requirement.
- **Evidence:** `backend/src/modules/investments/portfolio/infrastructure/forecast.repository.ts:50–79,80–174`; `backend/src/modules/investments/upcoming-events/upcoming-events.service.ts:152–173,271–279`; `backend/src/modules/investments/portfolio/application/forecast.service.ts:35–94,98–123`; `specs/openspec/specs/brokerage-account-upcoming-events/spec.md:10–24,63–76`.
- **Claim:** при новом scopeKey и существующем пересекающемся forecast `if (!previous && fallback) return fallback` возвращает старый payload даже при полном новом candidate. Ежедневный сдвиг default window — обычный достижимый путь, не искусственная атака.
- **Current mechanism:** accountId/from/to входят в persisted identity. Без exact row ищется первый overlap без `orderBy`; новый candidate не достигает dependency validation/upsert. При отсутствии candidate и непересекающемся окне последний forecast также не выбирается, хотя spec требует успешный пустой фильтр сохранённого результата.
- **Threat model:** прогнозные суммы и исходное окно → нормальная смена UTC дня/новых holdings → events.get/resolve → fallback принят за достаточную замену нового полного расчёта → сохранение прежних выплат → transactional version checks → отделить публикацию полного результата от фильтрации чтения.
- **Impact / actual cost:** пользователь может продолжать получать старое количество бумаг/суммы после обновления sources; out-of-window read без candidate может вернуть `data: null` вместо сохранённого пустого результата. **Impact unmeasured**.
- **Why now:** окно меняется штатно, а fallback является основной защитой последнего полного прогноза при failures. Ошибка находится внутри этой важной защиты.
- **Minimum change:** у существующих ForecastService/Repository развести выбор последнего полного результата конкретного owner/account и фильтрацию request window. Полный новый hourly-расчёт должен публиковаться, неуспех — оставлять прежний. Задать детерминированный порядок выбора сохранённого forecast.
- **Guarantees at risk:** не заменять полный прогноз частичным; сохранить его исходные `calculatedAt`, dependency revisions и окно при простом фильтрующем GET. Membership/portfolio/source CAS checks необходимы. Простого удаления строки 79 без проверки read semantics недостаточно.
- **Counterarguments / trade-offs:** fallback нужен; существующий `backend/test/upcoming-events.e2e-spec.ts:619–640` правильно требует сохранение timestamp при узком read window. Он не проверяет новый полный candidate после смены holdings и окна. Само пересечение не доказывает актуальность расчёта.
- **Verification or rollback:** isolated repository/service cases: старый window + новый полный candidate с изменившимся количеством; narrow read без новой публикации; failed refresh; несколько сохранённых windows; пустое пересечение. Проверить суммы, `calculatedAt`, выбранную revision и сохранность rollback, а не число DB calls. Runtime proof `UNVERIFIED`.
- **Related finding IDs:** RISK-004, RISK-005; прежняя technical F1.

### RISK-004 — Hourly не обновляет сохранённые event calendars

- **Decision = FIX; Severity = P2; Confidence = High; Effort = S.** Тип: дефект refresh policy.
- **Evidence:** `backend/src/modules/investments/tbank-sync/tbank-hourly.scheduler.ts:166–175`; `backend/src/modules/investments/upcoming-events/upcoming-events.service.ts:182–239`; `backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:113–125,152–158,164–193,607–623,679–692`; `specs/openspec/specs/hourly-investment-sync/spec.md:8–9`.
- **Claim:** hourly events.refresh идёт через readMany/requestMany с `force=false`; dividends/bond-events имеют `stable` policy. Если row уже существует, её наличие считается достаточным, независимо от времени наблюдения.
- **Current mechanism:** обновление по TTL есть только у quote kinds. `bond-events` не имеет rangeKey, поэтому может остаться на первом успешном ответе бессрочно. Dividends получают новый key при изменении окна/дня и могут загружаться заново тогда, но изменение выплаты внутри прежнего окна не подхватывается последующими часовыми обходами.
- **Threat model:** полнота ожидаемых выплат → изменившиеся данные provider → hourly calendar refresh → календарь ошибочно считается неизменяемым справочником → новые/отменённые выплаты не отражены → versioned source publication → целевой hourly refresh calendars.
- **Impact / actual cost:** обещанный обход выполняется без RPC за актуальным календарём; RISK-003 может затем отдельно заблокировать и новый forecast. **Impact unmeasured**; дополнительные необходимые RPC тоже пока не измерены.
- **Why now:** portfolio holdings и payout calendars — изменяемые источники, на которых построены пользовательские прогнозы.
- **Minimum change:** передавать существующий force именно для event-calendar sources в hourly-пути либо задать им обоснованный ограниченный TTL. Стабильные metadata переиспользовать; обычный GET оставить пассивным. Не force-обновлять все kinds ради двух календарей.
- **Guarantees at risk:** rate budget, one producer/observer coordination, сохранение старого полного calendar при malformed/error и late generation fence.
- **Counterarguments / trade-offs:** public shared calendar cache полезен и не требует удаления. Daily key частично маскирует проблему dividends, но не решает intraday изменения и постоянный bond-events key. Force всех instrument sources создаст ненужный traffic.
- **Verification or rollback:** два controlled hourly refresh одной connection и окна с разными provider responses; второй calendar действительно обновляет revision и результат. Fail второго запроса сохраняет первый; обычный GET не делает RPC. Runtime proof `UNVERIFIED`.
- **Related finding IDs:** RISK-001, RISK-003; прежняя technical F3.

### RISK-005 — AccountPage скрывает свежесть portfolio и failed background read

- **Decision = FIX; Severity = P2; Confidence = High; Effort = S.** Тип: failure-state UX / достоверность финансового представления.
- **Evidence:** `frontend/src/entities/portfolio/api/usePortfolio.ts:19–25`; `frontend/src/shared/api/resource-query.ts:129–147`; `frontend/src/pages/account/ui/AccountPage/AccountPage.vm.ts:86–101,125–135`; `frontend/src/pages/account/ui/AccountPage/AccountPage.tsx:24–34`; `frontend/src/pages/account/ui/AccountPage/components/AccountPageLoaded.view.tsx:55–59`; `frontend/src/shared/ui/SourceSyncStatus/SourceSyncStatus.tsx:23–47`; test consumer `frontend/src/pages/account/ui/AccountPage/AccountPage.test.tsx:751–855`.
- **Claim:** VM возвращает `source: portfolio.meta`, но container не передаёт source в loaded view. При cached data transport error не включается в loaded presentation и не даёт retry.
- **Current mechanism:** query wrapper предоставляет data/meta/error раздельно. SourceSyncStatus уже умеет показывать timestamp, stale и lastAttempt, но получает undefined. VM сохраняет loaded при наличии data; это полезно, однако ошибка остаётся невидимой.
- **Threat model:** смысл сохранённых финансовых сумм → upstream/read failure → cached Query → metadata потеряна на VM→view boundary → старые суммы показаны без freshness/error context → existing status component → передать metadata и локальный read error.
- **Impact / actual cost:** пользователь не видит возраст данных и неудачное перечитывание; риск решений по устаревшим суммам. **Impact unmeasured**. Чужие данные этим дефектом не раскрываются.
- **Why now:** silent stale UI усиливает последствия RISK-001–004. Тест явно закрепляет отсутствие уведомлений, поэтому обычный зелёный suite не устранит проблему.
- **Minimum change:** передать существующий source prop; добавить безопасный local background-read error/retry у нынешнего page owner. Отдельно сохранить neutral first-load и access-failure path.
- **Guarantees at risk:** не стирать cached snapshot из-за transient failure, не показывать прежнего owner после auth/connection switch, не запускать personal sync кнопкой повторного чтения. Status должен быть доступным текстом/accessible name.
- **Counterarguments / trade-offs:** тихое сохранение payload предотвращает flash/error page, но сохранение и отсутствие failure context — разные решения. Частичный snapshot уже отображается отдельно и не заменяет freshness.
- **Verification or rollback:** existing route test с stale/failed `meta` и MSW background `503`: старые суммы остаются, timestamp/предупреждение видны, retry выполняет GET; успешный refetch снимает error. Runtime/browser proof `UNVERIFIED`.
- **Related finding IDs:** RISK-002, RISK-003, RISK-004; прежняя technical F5.

### RISK-006 — Invalid broker token в online paths превращается в retryable `500`

- **Decision = FIX; Severity = P2; Confidence = High; Effort = S.** Тип: error mapping / recovery defect.
- **Evidence:** `backend/src/integrations/tbank/tbank.client.ts:527–565`; `backend/src/modules/investments/instruments/application/catalog-discovery.service.ts:143–165,227–249,295–317`; `backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:241–267`; `backend/src/integrations/tbank/tbank-token.service.ts:26–35`; `backend/src/common/filters/http-exception.filter.ts:19–31`; consumer `frontend/src/shared/api/client.ts:127–151,162–193`.
- **Claim:** если сохранённый token внешне отозван и ещё не помечен `invalidToken`, online RPC бросает обычный Error с внутренним code; online application path не переводит его в публичный `INVALID_TBANK_TOKEN`.
- **Current mechanism:** background owners умеют terminal invalid-token handling; connection.put использует `translateInvalidToken`. Online search/detail/company вызывают client напрямую. Filter безопасно скрывает Error, но выдаёт `500 INTERNAL_SERVER_ERROR`, который frontend считает transient.
- **Threat model:** корректное recovery connection → внешнее revoke credentials → online GET → постоянная ошибка принята за внутренний transient failure → повтор заведомо неуспешного RPC/неверное сообщение → existing translator → применить перевод на online boundary.
- **Impact / actual cost:** пользователь теряет recovery code. Для одного GET frontend допускает до **трёх HTTP попыток**: две итерации `RETRY_DELAYS_MS` и finalAttempt; это верхняя граница по коду, не измеренный traffic. Реальное amplification зависит от caller/provider. **Impact unmeasured**.
- **Why now:** online reference paths реализованы и доступны через защищённые controllers; background handling не защищает эти calls.
- **Minimum change:** переиспользовать текущий invalid-token translator у online application owner. Сохранить отдельные outcomes transient unavailable / not found. Решение о durable invalidToken flag должно быть generation-aware и не требовать записи без captured revision.
- **Guarantees at risk:** не отдавать raw provider error; не пометить новое подключение ошибочным из-за позднего failure старого token; не убрать bounded network retry для действительно transient errors.
- **Counterarguments / trade-offs:** `onlineToken` уже возвращает правильный code, если invalidToken flag выставлен; defect существует до обнаружения revoke background owner. `500` не раскрывает secret — это не data leak, а нарушение классификации.
- **Verification or rollback:** controlled online endpoint с provider `UNAUTHENTICATED`/`PERMISSION_DENIED`: публичный `400 INVALID_TBANK_TOKEN`, frontend GET не повторяется; transient upstream по-прежнему даёт `503`. Runtime proof `UNVERIFIED`.
- **Related finding IDs:** RISK-005; прежняя technical F13.

### RISK-007 — Нижняя граница пароля проверяется в разных единицах

- **Decision = FIX; Severity = P2; Confidence = High; Effort = S.** Тип: runtime validation / UX correctness, не password bypass.
- **Evidence:** `backend/src/modules/auth/presentation/auth.dto.ts:43–54,66–74`; `frontend/src/features/auth/model/auth.schema.ts:36–43`; `specs/openspec/specs/user-authentication/spec.md:10,109–110`; `docs/domains/authentication/overview.md:12–21`.
- **Claim:** frontend и behavioral spec требуют 12–72 UTF-8 bytes; backend minimum — MinLength(12), maximum — UTF-8 bytes. Для шести кириллических букв frontend minimum выполняется, backend minimum — нет.
- **Current mechanism:** единственный backend byte validator проверяет только максимум. `CredentialsDto` общий для login и registration; расхождение docs уже отмечает, но правило runtime остаётся несогласованным.
- **Threat model:** доступный auth flow → пользователь с не-ASCII password → frontend schema / server DTO → единицы длины ошибочно считаются одинаковыми → API отвергает принятый формой ввод → existing backend validator → единая policy на runtime boundary.
- **Impact / actual cost:** лишний запрос и непредсказуемый отказ формы; потенциальная несовместимость policy для существующих credentials. **Impact unmeasured**. Более строгий minimum не является подтверждённой эксплуатацией.
- **Why now:** это явно сохранённое требование, а не рекомендация внешнего checklist о более длинном пароле.
- **Minimum change:** проверять обе byte bounds в текущем PasswordBytesConstraint и согласовать minimum metadata. Если нужно изменить саму password policy — сначала отдельное решение владельца, затем согласованный frontend/backend contract.
- **Guarantees at risk:** верхние 72 bytes защищают от bcrypt truncation; пароль нельзя trim/normalize. Нельзя silently сделать существующий password непригодным для login при ужесточении registration policy.
- **Counterarguments / trade-offs:** byte minimum допускает меньше видимых не-ASCII символов; это уже выбранный spec contract, а не автоматически лучшая security policy. Изменение policy не следует маскировать исправлением единиц.
- **Verification or rollback:** existing configured HTTP validation boundary и frontend schema: ASCII и не-ASCII на 11/12/72/73 bytes, сохранение пробелов в password. Runtime proof `UNVERIFIED`.
- **Related finding IDs:** RISK-008; прежняя technical F12.

### RISK-008 — Защита public auth от перебора и resource exhaustion не подтверждена

- **Decision = INVESTIGATE; Severity = P2; Confidence = Medium; Effort = S.** Тип: architecture/deployment risk; **UNVERIFIED для фактической публичной установки**.
- **Evidence:** `backend/src/modules/auth/presentation/auth.controller.ts:55–79`; `backend/src/modules/auth/application/auth.service.ts:19–26,35–78`; `backend/src/main.ts:19–41`; `backend/src/app.module.ts:18–35`; `frontend/docker/nginx.conf:20–33`; `docs/domains/authentication/overview.md:89–95`; root `compose.yaml:40–43`.
- **Claim:** app-level ограничение auth attempts не реализовано; поставляемый Nginx proxy также не содержит его. Можно подтвердить отсутствие защиты в этой цепочке, но нельзя по ней подтвердить доступность обходного public пути или отсутствие защиты внешнего HTTPS proxy.
- **Current mechanism:** public login всегда выполняет bcrypt compare, включая dummy hash неизвестного email; register нового email выполняет bcrypt hash. Source inventory не обнаружил auth throttler/global guard. Frontend block submit не ограничивает прямые HTTP-клиенты.
- **Threat model:** account confidentiality / CPU availability → неаутентифицированный клиент с доступом к public auth → login/register → отсутствует доказанный admission budget → подбор credentials/накопление bcrypt work → existing generic errors, expensive hash, внешний proxy возможен → проверить perimeter и ограничить при необходимости.
- **Impact / actual cost:** условный brute-force/resource-exhaustion risk. Частота попыток, доступность сервера, CPU budget и реальные controls **not measured / UNVERIFIED**; account compromise не заявляется.
- **Why now:** credentials открывают доступ к сохранённым финансовым данным, а register/login намеренно публичны.
- **Minimum change:** сначала прочитать реальную внешнюю proxy policy и путь обхода. Если защиты нет, задать ограниченный budget auth requests на существующей boundary, отдельно рассмотрев распределённый подбор одного account. Не добавлять lockout, CAPTCHA, Redis или новый auth subsystem без этой проверки.
- **Guarantees at risk:** account lockout может дать attacker-controlled DoS; IP policy зависит от доверенной proxy chain. Generic login errors и dummy hashing сохраняются; logging попыток не должен содержать credentials/email values.
- **Counterarguments / trade-offs:** root Compose публикует frontend на loopback, внешний reverse proxy обязателен для HTTPS и может уже фильтровать. Docs честно описывает app limitation. При закрытом доступе remediation priority может быть ниже; нет оснований для P0/P1 exploitation claim.
- **Verification or rollback:** самый дешёвый шаг — static inspect live proxy configuration/правильность client IP без attack/load test; затем isolated auth boundary test rejection budget, отсутствие bcrypt/upstream work после rejection и восстановление доступа. Не проводить production brute force.
- **Related finding IDs:** RISK-007.

## 5. Protected Invariants Registry

`Safe-to-remove? = No` означает отсутствие доказанной равносильной замены, а не необходимость сохранить каждую нынешнюю строку реализации.

| Invariant | Mechanism | Evidence | Safe-to-remove? |
| --- | --- | --- | --- |
| Client не выбирает identity; nested resource чужого User недоступен | Verified user.sub + scoped card/operation/category/account queries | `backend/src/modules/banking/bank-cards/presentation/bank-cards.controller.ts:94–166`; `backend/src/modules/banking/bank-cards/infrastructure/bank-cards.repository.ts:62–72`; `backend/src/modules/banking/bank-cards/application/bank-operations.service.ts:100–197`; `backend/src/integrations/tbank/tbank-access.service.ts:262–288` | No |
| Password hash и token не являются публичной User моделью | bcrypt и явный toUser projection | `backend/src/modules/auth/application/auth.service.ts:48–52,64–78,142–144`; `backend/src/modules/auth/presentation/auth.controller.ts:113–119` | No |
| Один current refresh имеет одного победителя; loser не отзывает победителя | SHA-256 hash высокоэнтропийного token + conditional updateMany + unique jti | `backend/src/modules/auth/application/auth.service.ts:99–113,166–205`; `backend/test/app.e2e-spec.ts:161–214` | No |
| Refresh cookie закрыта JS и ограничена auth boundary | HttpOnly, SameSite=Lax, Secure вне development, host-only/path | `backend/src/modules/auth/presentation/auth.controller.ts:125–137` | No |
| Auth/session switch не публикует старый response/cache в новой identity | In-memory token, generation checks, clear/reset Query cache, serialised cookie writes | `frontend/src/features/auth/model/auth.vm.ts:41–115,121–151`; `frontend/src/shared/api/client.ts:53–119` | No |
| Broker token зашифрован с integrity protection | AES-256-GCM с random nonce и authenticated tag; validated key | `backend/src/integrations/tbank/tbank.crypto.ts:14–49`; `backend/src/config/env.validation.ts:75–83` | No |
| Failed token replacement не портит прежнюю connection; старые writes не проходят | Validation до DB transaction; fresh revision/cascade + attempt fences | `backend/src/modules/investments/tbank-connection/tbank-connection.service.ts:31–88`; `backend/src/modules/investments/portfolio/infrastructure/portfolio.repository.ts:121–147`; `backend/prisma/schema.prisma:25–71,232–262` | No |
| Lost create response не даёт второй banking effect, changed intent не переиспользует ID | UUID primary key + normalized createFingerprint после ownership check | `backend/src/modules/banking/bank-cards/application/bank-cards.service.ts:74–95`; `backend/src/modules/banking/bank-cards/application/bank-operations.service.ts:214–240`; `backend/src/modules/banking/bank-cards/application/bank-card-input.ts:74–81` | No |
| Deleted operation не воскресает от delayed create replay | Tombstone + same-ID replay → 410 | `backend/src/modules/banking/bank-cards/application/bank-operations.service.ts:221–230,286–330` | No |
| Competing edit/refund сохраняет version и refund ceiling | CAS source/version, refund sum и write transaction/retry | `backend/src/modules/banking/bank-cards/application/bank-operations.service.ts:152–209,251–330`; `backend/src/modules/banking/bank-cards/infrastructure/bank-cards.repository.ts:35–59`; `backend/test/bank-cards.e2e-spec.ts:462–514` | No |
| Деньги не теряют точность и не суммируются между валютами | BigInt decimal и RUB kopecks bounds; grouped currency totals | `backend/src/common/decimal.ts:19–83`; `backend/src/modules/banking/bank-cards/domain/rub-money.ts:12–38`; `backend/src/modules/investments/portfolio/infrastructure/tbank-portfolio.mapper.ts:109–138` | No |
| Cursor сохраняет owner/filter/data identity | HMAC verification + owner/revision/filter binding | `backend/src/modules/investments/operations/application/brokerage-operations.service.ts:347–388`; `backend/src/modules/investments/operations/infrastructure/brokerage-operations.repository.ts:128–148` | No |
| Частичная external page не заменяет полный operation dataset | Stage marker, continuation checks, duplicate conflict detection, atomic rows+coverage+revision | `backend/src/modules/investments/operations/infrastructure/brokerage-operations.repository.ts:602–699,712–881` | No |
| Forecast publication соответствует версиям обязательных dependencies | Connection write fence + portfolio/source revision/timestamp checks | `backend/src/modules/investments/portfolio/infrastructure/forecast.repository.ts:35–49,80–174` | No; исправление RISK-003 не удаляет fence |
| Shared public sources не содержат personal holdings/credentials | Public projection, initiating/observing attempt authorization | `backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts:646–677`; `backend/src/modules/investments/instruments/infrastructure/catalog-discovery.repository.ts:154–180,252–277` | No |
| Upstream overload и secret errors имеют bounded handling | TLS, queue bound, deadline, два RPC attempts, безопасные context/error codes | `backend/src/integrations/tbank/tbank.client.ts:49–54,214–218,504–586`; `backend/src/integrations/moex/moex.client.ts:164–198`; `backend/src/integrations/ncr/ncr-ratings.client.ts:36–57` | No |
| Raw secrets/body/SQL/error stack не выдаются в HTTP completion/envelope | Problem filter + allowlisted completion/context | `backend/src/common/filters/http-exception.filter.ts:19–47`; `backend/src/common/logging/logging.module.ts:15–54`; `backend/src/common/logging/structured-logger.service.ts:7–25,43–60` | No; текущие messages дополнительно проверяются семантически |
| Backup/restore не создаёт смесь БД и ключа/новых данных | Stop writers, full data-directory backup, отдельный key, explicit isolated restore | `docs/architecture/deployment.md:137–176` | No; runtime execution UNVERIFIED |

**Важные контрсценарии:** убрать fingerprint → retry с тем же UUID, но другой суммой больше не отличим от исходного intent; убрать tombstone → delayed POST сможет создать удалённую операцию; убрать CAS → stale PATCH или competing refund теряет установленную границу; убрать revision/attempt fence → ответ до replacement может опубликоваться после него. Эти механизмы не являются ритуальными guards.

### Never remove without replacement

- Server-side DTO validation, explicit identity/ownership и проверки всех nested references.
- Bcrypt byte ceiling, safe public User projection, refresh hash CAS, token type/algorithm/expiry и cookie flags.
- AES-GCM integrity/key validation, generation rotation, conditional late-publication fences.
- Banking createFingerprint, client UUID, version CAS, tombstones, refund serialization и transaction rollback.
- Exact Money representation и currency separation.
- Staging completeness/continuation/duplicate guards и атомарное обновление rows/coverage/revisions.
- Forecast dependency checks и сохранение последнего полного результата при partial failure.
- TLS, queue bounds, timeout/retry limits, safe error mapping и log projections.
- Durable attempt identity и восстановление после restart; RISK-001 требует усилить lifecycle, а не удалить его.

## 6. Failure Recovery Map

| Failure | Текущий механизм / observable state | Recovery и предел | Evidence / decision |
| --- | --- | --- | --- |
| Unknown email / wrong password | Generic INVALID_CREDENTIALS, dummy bcrypt для unknown user | Новый login; admission budget вне app не подтверждён | `auth.service.ts:64–78`; RISK-008 |
| Concurrent / superseded refresh | Один hash CAS winner, loser 401 без Set-Cookie | Winner usable; loser допускает re-login; нет cross-tab lock/history | `auth.service.ts:99–113,183–190`; `auth.controller.ts:81–90`; KEEP |
| Refresh/logout storage failure | 500 через safe filter, cookie не перезаписывается неуспехом | Возможен retry; frontend очищает локальную identity при failed refresh/logout | `backend/test/app.e2e-spec.ts:102–159`; `frontend/src/features/auth/model/auth.vm.ts:81–115,135–141`; tests не запускались |
| Invalid replacement broker token | Validation вне transaction, InvalidToken translator | Старые connection/private rows сохранены | `tbank-connection.service.ts:31–72`; KEEP |
| Upstream transient / queue full | Два bounded RPC attempts; queue overflow сразу 503 | Следующая штатная попытка, без вложенного service retry | `tbank.client.ts:504–568`; KEEP |
| Lost banking POST response | Same UUID + same fingerprint → current DTO | Safe replay; changed intent 409; deleted replay 410 | `bank-operations.service.ts:214–240`; KEEP |
| Competing banking edit / refund | CAS/transaction конфликт откатывает записи | Перечитать version и повторить осознанный edit | `bank-operations.service.ts:152–209,251–330`; KEEP |
| Partial operations pagination | Staging не публикуется без complete marker | Old shown scope сохранён; re-reservation меняет attempt и очищает stage | `brokerage-operations.repository.ts:409–436,625–639,724–734`; KEEP |
| Calendar/provider parse failure | Safe unavailable, старый full source/forecast сохраняется | Следующая authorized refresh; stable policy может не освежить сохранённый calendar | `catalog-enrichment.service.ts:524–578`; RISK-004 |
| Child persistence failure / hourly settle failure | In-memory worker завершён, durable running может остаться | Automatic live-process recovery не гарантирован; restart помогает, но не заменяет нормальный recovery | RISK-001 |
| Orchestration exception до completion | Общий catch с прежним списком failures | Может falsely succeeded; требуется явный unsuccessful aggregate | RISK-002 |
| Process restart | Другой processRunId отменяет hourly running, срок определяется началом прежней попытки | Не более одного актуального следующего запуска; multi-process lease отсутствует намеренно | `tbank-sync.repository.ts:174–220`; single process — root `compose.yaml:32–38` |
| Old forecast / changed request window | Exact scope либо первый overlap | Новый full candidate может быть отвергнут; non-overlap без candidate даёт null | RISK-003 |
| Cached portfolio + read failure | Cached payload сохраняется | Status/retry на loaded page теряются | RISK-005 |
| Внешне отозванный token до background detection | Online path даёт safe 500 | Frontend повторяет transient GET вместо нужного recovery | RISK-006 |
| SQLite/disk/key loss | Docs требует согласованный backup и isolated restore | Локальный backup не защищает от потери диска; live/off-host restore и сохранность ключа UNVERIFIED | `docs/architecture/deployment.md:137–176` |

Сокращённые имена source files в этой таблице относятся к полным evidence в findings и registry; это карта механизмов, не новые findings.

## 7. DELETE / SIMPLIFY / KEEP / INVESTIGATE

| Decision | Объект | Основание |
| --- | --- | --- |
| DELETE | Подтверждённых безопасных удалений protective mechanisms нет | No replacement proof; общий dead-code cleanup — другой audit |
| SIMPLIFY | Подтверждённых обязательных complexity changes нет | Новый workflow/retry/lease framework не решает найденные локальные дефекты |
| KEEP | Ownership, refresh CAS/cookie boundary, AES-GCM | Защищают identity/credentials, не заменяются UI validation |
| KEEP | Banking UUID + fingerprint + version CAS + tombstones + transactions | Разные сценарии: replay, changed intent, stale edit, delayed resurrection, refund concurrency |
| KEEP | Connection/attempt revisions, stage completeness, forecast dependency checks | Защита late publication, partial reconciliation и исходных финансовых assumptions |
| KEEP | Exact decimal/BigInt/currency grouping | Защита monetary correctness |
| KEEP | Bounded RPC retry/queue/TLS, safe Problem/log projections | Необходимые integration/error boundaries |
| KEEP | Один native scheduler timer без inter-process lease | Минимально достаточно при подтверждённом single-process deployment contract; перед scaling нужна замена |
| FIX | RISK-001–007 | Восстановление, достоверность результатов и согласованность runtime boundaries |
| INVESTIGATE | RISK-008: external auth admission policy | Приложение не ограничивает auth; production perimeter не проверен |
| INVESTIGATE | Off-host backup + original encryption key + live restore | Инструкции есть, выполнение/сохранность копий не доказаны; не объявляется code vulnerability |

## 8. Cost & benefit

| Action | Класс ожидаемой пользы / стоимости | Фактическое измерение | Обязательная граница регрессии |
| --- | --- | --- | --- |
| RISK-001/002 | Reliability, диагностируемость, меньше бесконечного polling/manual restart; локальные дополнительные branches | not measured | Late attempt fencing, partial success, DB rollback, восстановление без data deletion |
| RISK-003/004 | Financial correctness/freshness; calendars потребуют дополнительных RPC | not measured | Старый full forecast при failure, passive GET, shared-source isolation, rate budget |
| RISK-005 | User trust/recovery; reuse existing status component | not measured | Cached payload не стирается; auth/access change его скрывает |
| RISK-006 | Runtime traffic и корректное recovery постоянной ошибки | not measured; максимум три frontend GET attempts — только source bound | Transient retry остаётся bounded; новая connection не помечается старым failure |
| RISK-007 | Меньше rejected auth input и cognitive load несогласованной policy | not measured | Bcrypt 72-byte ceiling и неизменность password bytes |
| RISK-008 verification | Подтвердить существующую защиту прежде, чем добавить новую | not measured | Trusted client IP, отсутствие attacker-induced account lockout |
| KEEP registry | Избежать data-loss/security regression от cleanup | not measured | Сохранение всех перечисленных invariants |

Экономия CI minutes, agent tokens, процентов runtime, строк кода/dependencies не измерялась и не заявляется. Подключение нового Redis, distributed scheduler или security framework не обосновано текущей проверенной областью.

## 9. Top actions

### Quick wins — подтверждённые локальные дефекты

1. **RISK-005 / S:** передать существующий portfolio metadata prop и показать read failure/retry, сохраняя snapshot.
2. **RISK-006 / S:** подключить existing invalid-token translation к online paths, проверить status/code и отсутствие frontend повторов постоянной ошибки.
3. **RISK-002 / S:** общий exception обхода завершать явным unsuccessful outcome; не выдавать `succeeded` до обязательного completion.
4. **RISK-004 / S:** targeted hourly refresh только payout calendars через существующий механизм force/TTL.
5. **RISK-007 / S:** выровнять runtime UTF-8 bounds по выбранной password policy.

### Требуют test proof / уточнения семантики

6. **RISK-001 / M — главный reliability priority:** bounded wait и recovery abandoned/settlement work в живом процессе; isolated SQLite failure injection и поздний ответ старого attempt.
7. **RISK-003 / M:** закрепить разделение hourly full publication и фильтрующего forecast GET, затем исправить selection/persistence. ADR нужен только при изменении самой behavioral policy, а не ради локальной правки guard.

RISK-008 не превращён в подтверждённое внедрение rate limiter: сначала дешёвая verification внешнего proxy в следующем разделе. Масштабный рефакторинг, новое хранилище и миграции не входят в эти действия.

## 10. Cross-audit signals

- **08 — Test quality:** отсутствие прямых hourly `tick/reserveHourly/settleHourly` assertions и старые local-read race сценарии; `backend/test/upcoming-events.e2e-spec.ts:140–147`, `backend/test/tbank-local-reads.e2e-spec.ts:489–515`. Не дублировать общий audit test quality; relevant regression cases уже перечислены выше.
- **07 — API/data-flow efficiency:** income read ещё инициирует membership/request planning; `backend/src/modules/investments/operations/application/brokerage-operations.service.ts:408–435`. Это другой owner refresh, а не отдельная security находка данного аудита.
- **15 — SDD/docs:** существующий events DTO не содержит исходное forecast window, хотя spec его требует; `backend/src/modules/investments/upcoming-events/upcoming-events.dto.ts:68–79`, `specs/openspec/specs/brokerage-account-upcoming-events/spec.md:12,86–87`. Требуется согласовать contract, не добавить произвольное поле в рамках этого read-only аудита.
- **06/15 — Backend policy/spec coherence:** eligibility длительного обхода разрешается по elapsed hour вместо пропущенного term; `backend/src/modules/investments/tbank-sync/tbank-sync.repository.ts:190–201`, `specs/openspec/specs/hourly-investment-sync/spec.md:19–25`. Не трактуется как overlap эксплуатация: running guard существует.
- **12 — Configuration:** off-host backup, permissions ключей и внешние HTTPS/rate policies принадлежат реальному deployment; `docs/architecture/deployment.md:123–143`. Не создавать дублирующий конфигурационный аудит без этих inputs.

## 11. Open questions / verification plan

| Вопрос, меняющий решение | Текущее основание | Самый дешёвый следующий proof |
| --- | --- | --- |
| Ограничивает ли live external HTTPS proxy auth и можно ли обойти его? | RISK-008; frontend Nginx без limit, root port на loopback | Пассивно посмотреть реальную proxy policy и network exposure. Если контролируется — KEEP существующую защиту, не внедрять второй limiter |
| Какой deadline допустим для большого hourly portfolio и как fence отменяет старую работу? | RISK-001; нет верхней границы aggregate waiter | Controlled isolated failure case сначала; затем representative длительность без live accounts. Deadline не должен разрешать stale publication |
| Чем отделяются новая полная forecast publication и простое фильтрующее чтение? | RISK-003 и существующий narrow-window test | Утвердить ожидаемые outcomes трёх случаев: new full candidate, failed refresh, filter-only read. Один isolated SQLite case на каждую границу |
| Можно ли доказать auth recovery при зависшем, а не rejected transport? | `frontend/src/shared/api/client.ts:127–131` обходит GET deadline для auth; `frontend/src/features/auth/model/auth.vm.ts:85–118,135–140` ожидает serialised запрос | MSW deferred refresh без ответа + controlled timer. Source показывает отсутствие app deadline; необходимость и допустимый срок требуют принятого bootstrap/recovery contract. До этого не добавлять speculative timeout во все mutations |
| Какая auth atomicity нужна при failure создания первой Session после User commit? | `backend/src/modules/auth/application/auth.service.ts:48–61,152–164`: отдельные writes | Isolated failure в session.create после user.create; определить требуемый rollback или явный login recovery. Account сохраняется и login возможен, поэтому не заявлена потеря credentials/critical exploit |
| Должны ли concurrent logout/refresh возвращать строго один terminal session outcome? | `backend/src/modules/auth/application/auth.service.ts:95–113,127–138,183–190`: refresh CAS только по hash, logout проверяет hash до отдельного update | Controlled two-request barrier на isolated DB; согласовать семантику до расширения CAS. Bounded revocation принята в `docs/adr/006-auth-session-policy.md:11–15`; access до 15 минут после logout явно допускается в `docs/domains/authentication/overview.md:89–95`, сам по себе это не auth bypass finding |
| Сохранены ли independent backup и original encryption key, выполнялся ли restore? | `docs/architecture/deployment.md:137–176`; AES-GCM не читает данные с новым ключом | Проверить только наличие процедуры/метаданные подтверждённого restore, не читать secrets/PII. При отсутствии proof — изолированный restore существующими средствами в отдельной разрешённой задаче |
| Missing MOEX block действительно означает отсутствие событий или повреждённый контракт? | `backend/src/integrations/moex/moex.client.ts:182–198` vs spec `brokerage-account-upcoming-events:82–84` | Согласовать provider contract на обезличенном response fixture. До этого KEEP malformed-row/cursor guards, не превращать unknown в подтверждённый пустой календарь |

### Завершение и ограничения доказательств

Проведена смысловая сверка findings с source evidence, consumer paths, контрсценариями и защищаемыми invariants. У каждого существенного defect указан runnable verification scenario для последующей исправляющей задачи. В этом аудите тесты и exploitation не проводились, поэтому ни один defect не назван runtime-воспроизведённым.

Финальная проверка: root/backend/frontend/specs/docs остаются с пустым `git status --short`; `git diff --check` не сообщает ошибок. Новый ignored отчёт просмотрен отдельно и проверен `git diff --no-index --check /dev/null audit-results/13-reliability-and-security-report.md`: обычный Git diff его не проверяет. `git check-ignore` подтверждает путь вне root allowlist. Boy Scout review отчёта: evidence не опирается на предыдущий аудит, severity не выведена из наличия guards, лишние удаления/метрики/абстракции не предложены. Исходники, specs, docs, тесты, конфигурации и history не изменены.

## 12. Consolidation table

| ID | Decision | Severity | Confidence | Repo | Files | One-line impact | Effort | Related IDs |
| --- | --- | --- | --- | --- | --- | --- | --- | --- |
| RISK-001 | FIX | P1 | High | backend | src/modules/investments/tbank-sync/tbank-hourly.scheduler.ts; src/modules/investments/tbank-sync/tbank-sync.repository.ts; src/modules/investments/instruments/application/catalog-enrichment.service.ts; src/modules/investments/operations/application/brokerage-operations-sync.service.ts | Persistence failure может оставить running и заблокировать дальнейшие обходы живого процесса | M | RISK-002,RISK-004 |
| RISK-002 | FIX | P2 | High | backend | src/modules/investments/tbank-sync/tbank-hourly.scheduler.ts; src/modules/investments/tbank-sync/tbank-sync.repository.ts | Неисполненный из-за общего exception обход может считаться succeeded | S | RISK-001,RISK-005 |
| RISK-003 | FIX | P2 | High | backend | src/modules/investments/portfolio/infrastructure/forecast.repository.ts; src/modules/investments/portfolio/application/forecast.service.ts; src/modules/investments/upcoming-events/upcoming-events.service.ts | Старый overlapping forecast блокирует новый полный результат изменившегося окна | M | RISK-004,RISK-005 |
| RISK-004 | FIX | P2 | High | backend | src/modules/investments/instruments/application/catalog-enrichment.service.ts; src/modules/investments/upcoming-events/upcoming-events.service.ts | Stable calendar policy пропускает новые/изменённые выплаты в hourly refresh | S | RISK-001,RISK-003 |
| RISK-005 | FIX | P2 | High | frontend | src/pages/account/ui/AccountPage/AccountPage.tsx; src/pages/account/ui/AccountPage/AccountPage.vm.ts; src/pages/account/ui/AccountPage/AccountPage.test.tsx | Cached financial sums показаны без уже подготовленной freshness/error metadata | S | RISK-002,RISK-003,RISK-004 |
| RISK-006 | FIX | P2 | High | backend,frontend | backend/src/modules/investments/instruments/application/catalog-discovery.service.ts; backend/src/modules/investments/instruments/application/catalog-enrichment.service.ts; frontend/src/shared/api/client.ts | Постоянный invalid token превращается в 500 и повторные HTTP reads | S | RISK-005 |
| RISK-007 | FIX | P2 | High | backend,frontend | backend/src/modules/auth/presentation/auth.dto.ts; frontend/src/features/auth/model/auth.schema.ts | Non-ASCII password проходит frontend byte minimum и отвергается backend character minimum | S | RISK-008 |
| RISK-008 | INVESTIGATE | P2 | Medium | backend,frontend | backend/src/modules/auth/presentation/auth.controller.ts; backend/src/modules/auth/application/auth.service.ts; frontend/docker/nginx.conf | Public auth не ограничен в app/provided proxy; live perimeter protection UNVERIFIED | S | RISK-007 |