# Технический аудит WealthLedger — 24.08.2026

## Статус и охват

Это неизменяемый snapshot состояния на начало повторного аудита 24.08.2026, до реализации change `harden-agent-sdd-governance`. Проверены workspace root и независимые репозитории `frontend`, `backend`, `specs`, `docs`: SDD authority, OpenSpec artifacts, agent entrypoints, локальные gates, docs-as-code, testing policy, build-versus-buy и audit traceability.

Аудит не оценивал продуктовые требования, live T-Bank, deployment или CI: текущая рабочая модель локальная. Последующие исправления отражаются в [live remediation registry](../development/audit-remediation.md), а не в этом файле.

## Итог

Предыдущая remediation существенно усилила runtime contracts, frontend boundaries, concurrency, hygiene и OpenSpec authority. Репозиторий уже имел полезные негативные fixtures, strict validation и durable architecture/features docs. Главный оставшийся риск был процессным: правила существовали фрагментами, но не образовывали один исполняемый SDD contract, который не позволит AI-агенту обойти стиль, пропустить репозиторий, переусложнить тестирование или начать custom infrastructure без оценки готового решения.

## Подтверждённые сильные стороны

- Единственный canonical store уже зарегистрирован как `wealth-ledger-specs` с root `specs/openspec`.
- Frontend имел strict TypeScript, Biome, dependency-cruiser, Knip, OpenAPI, coverage и bundle ratchets с representative negative fixtures.
- Backend имел раздельные non-mutating lint, typecheck, Jest и build commands; auth concurrency regressions защищены тестами.
- Runtime OpenAPI можно было сравнить с committed frontend snapshot отдельным read-only script.
- `docs/architecture` и `docs/features` описывали as-built состояние, ADR фиксировали важные решения.
- Authority verifier отклонял второй OpenSpec root, implicit store selection и framework planning artifacts вне store.

## Findings

### AUD24-01 — Нет единой risk-based testing policy

**Приоритет:** P1. Frontend `verify` последовательно запускал одинаковый Vitest suite через `test:run` и coverage, а общая policy не отличала тесты критического поведения от тестов DTO, декларативных файлов и hygiene scripts. Это увеличивало локальную стоимость и подталкивало агента тестировать структуру ради coverage вместо риска.

### AUD24-02 — Build-versus-buy не является обязательным архитектурным шагом

**Приоритет:** P1. Ни OpenSpec schema, ни Design template не требовали до custom auth, security, storage, integration или tooling сравнить зрелые решения. Текущая собственная auth implementation не имела ретроспективной оценки против поддерживаемых платформ, включая Better Auth; аудит не утверждает, что миграция необходима, но подтверждает отсутствие decision evidence.

### AUD24-03 — OpenSpec graph и роли артефактов недостаточно строгие

**Приоритет:** P1. Default `spec-driven` позволял Design сразу после Proposal. Project config оставался недостаточным для разделения Proposal как intent, Delta Specs как behavior, Design как architecture и Tasks как implementation checklist. Delivery Map четырёх репозиториев и последовательные owner approvals не были частью schema contract.

### AUD24-04 — Agent projection могла дрейфовать и архивировать непроверенное

**Приоритет:** P1. Root `.opencode` указывал generated OpenSpec 1.9 при установленной CLI 1.10. Upstream archive workflow допускал продолжение после warnings; project overlays не требовали всех affected-area gates, semantic verification и independent review как безусловных blockers.

### AUD24-05 — Нет согласованного canonical local gate для workspace

**Приоритет:** P1. Frontend не отклонял Node 26 до application checks и повторял tests; backend не имел одного `verify`; docs не имел validator. Четыре независимых Git-root нельзя было проверить одним dispatcher, который понимает Delivery Map и условный runtime OpenAPI contract.

### AUD24-06 — Docs-as-code и process documentation неполны

**Приоритет:** P2. Docs не имел lockfile-backed Markdown gate. OpenSpec lifecycle doc фиксировал store boundaries, но не определял Change Owner, Completion Evidence, hard-versus-guidance, test matrix или build-versus-buy. Эти правила нельзя было устойчиво обнаружить из новой agent session.

### AUD24-07 — AGENTS слои не отделяют routing от policy

**Приоритет:** P2. Root и repository-local instructions содержали часть общих правил, но не давали одинакового пути к canonical local gate, engineering governance, repository style/boundary sources и audit registry. Проверяемые invariants и guidance не были явно разделены.

### AUD24-08 — Live remediation registry не охватывает все snapshots

**Приоритет:** P2. Registry ссылался только на аудит 20.08.2026: Audit IDs A-01–A-18 из snapshot 13.08.2026 не имели однозначного текущего статуса. WL-P3-04 был `planned`, хотя ожидал отдельного accessibility scope trigger и по собственным правилам должен был быть `deferred`.

### AUD24-09 — Сохранились подтверждённые current-state contradictions

**Приоритет:** P3. ADR 003, 004 и 006 говорили о будущей реализации уже поставленных возможностей; ADR 007 требовал ручного refresh, не поясняя сохранение cached data во время background refetch. Основная spec `user-authentication` не имела H1, зафиксированного A-18.

## Рекомендуемая remediation

AUD24-01 и AUD24-03–AUD24-09 объединяются одним process change `harden-agent-sdd-governance`, потому что вместе формируют один enforceable workflow contract. AUD24-02 после него требует отдельного `assess-auth-platform-options`: оценка существующей auth должна использовать новую Solution Assessment policy и не предрешать миграцию.

## Воспроизводимая база snapshot

На входе были просмотрены OpenSpec schema/config/templates, все root `.opencode` entrypoints, пять `AGENTS.md`, repository package scripts, существующие audits/registry, ADR и main specs. Локальные проверки показали OpenSpec 1.10.0, frontend test suite дважды в composite command, backend tests под Node 22 — 19 suites / 59 tests, отсутствие docs package/lockfile и отсутствие workspace dispatcher. Первичные исходные результаты сохранены смысловыми findings выше; observed remediation evidence появится только после archive в live registry.