# WealthLedger backend

NestJS API WealthLedger. Backend владеет auth, SQLite-данными и server-side
интеграцией T-Bank; frontend не обращается к T-Bank напрямую.

## Быстрый старт

Требуется Node 22 (`.nvmrc`). Создайте `.env` из примера, замените placeholder
секреты и установите зависимости строго из lockfile:

```bash
cp .env.example .env
nvm use --silent
npm ci
npm run start:dev
```

`JWT_SECRET` должен быть секретом не короче 32 символов, а
`TOKEN_ENCRYPTION_KEY` — base64-кодированным 32-байтным ключом. Не добавляйте
T-Bank token в `.env`: он вводится пользователем и хранится в зашифрованном
виде.

## Проверка

Единый completion gate не изменяет versioned-файлы:

```bash
npm run verify
```

Он запускает zero-warning lint,
application/test typechecks, Jest и build. `npm run lint:fix` — отдельная
записывающая команда, `npm run test:cov` — диагностика без общего числового
threshold. `npm run test:e2e` пока не является passing gate: Prisma schema
engine останавливает migration до запуска Jest. Точный статус и trigger
пересмотра находятся в [remediation registry](../docs/development/audit-remediation.md).

Общий `tsconfig.json` включает `strict: true` и `noFallthroughCasesInSwitch`
для приложения, тестов и сборок. ESLint запрещает non-null assertions
(`value!`) и definite-assignment assertions (`field!: Type`).
Поля DTO, заполняемые вне конструктора, описываются через `declare`:
входные значения заполняет и проверяет Nest, ответные DTO описывают форму
возвращаемых объектов. `declare` не создаёт значение и не заменяет
runtime-валидацию. В обычном коде нужны инициализация или сужение типа
после проверки значения.

## Документация

- [Router conventions](.ai/CONVENTIONS.md) и [источники](.ai/SOURCES.md)
- [Backend architecture](.ai/conventions/backend-architecture.md)
- [HTTP API](.ai/conventions/backend-http-api.md), [data](.ai/conventions/backend-data.md) и [testing](.ai/conventions/backend-testing.md)
- [Security/auth](.ai/conventions/security-auth.md) и [integrations](.ai/conventions/backend-integrations.md)

- [Границы проверки API и данных](../docs/development/verification.md#api-и-хранение-данных)
- [Engineering governance и risk-based testing](../docs/development/engineering-governance.md)
- [Карта проектных фактов](../docs/README.md)
- [API contract и runtime OpenAPI](../docs/development/runtime-openapi-verification.md)
- [Обзор поставленной системы](../docs/overview.md)
- [Архитектурные решения](../docs/adr/README.md)
- [Remediation registry](../docs/development/audit-remediation.md)

Из backend runtime OpenAPI можно read-only сверить с frontend snapshot:

```bash
npm run test:openapi-contract
```

Разработка идёт напрямую по задаче пользователя. Каждый affected repo проходит
свой verify; при изменении wire contract дополнительно выполняется contract check.
Обязательного OpenSpec/SDD lifecycle нет.