# WealthLedger

## Workspace

`frontend`, `backend`, `docs` и `specs` — независимые Git-репозитории.
Root — отдельный Git-репозиторий `WealthLedger/main`; команды Git выполняй
из нужного repo. Root tracking ограничен allowlist в `.gitignore`;
вложенные repos и локальные данные в main не добавляй, включая `git add -f`.
Структура checkout и запуск — в [README](README.md).
`references/**`, dated audits и архивы — read-only источники.

## Работа

1. Начинай с задачи пользователя, ожидаемого результата и affected areas. Работай напрямую: OpenSpec/SDD artifacts, approvals и archive не являются prerequisite. Используй прежний SDD workflow только по явному запросу.
2. Прочитай local `AGENTS.md` affected repo. Для frontend/backend прочитай его `.ai/CONVENTIONS.md` и `.ai/SOURCES.md`, затем только темы, которые активируют задача, пути или обнаруженная граница.
3. До выбора реализации проследи поведение и инварианты, найди ближайший существующий owner и 1–3 подходящих примера. Код показывает реализацию; документированный контракт не выводится из случайного аналога.
4. Выбирай простейшее полное решение у ответственного владельца. Новая abstraction или dependency требует текущей потребности; посторонний рефакторинг оставляй отдельно.
5. Выбирай тип знания по задаче через [вход docs](docs/README.md): новая функция или межрепозиторное поведение → соответствующая область, спецификации, нужные ADR, затем реализация; ошибка с неясным ожиданием → спецификация, docs, код и тесты; архитектурное изменение → архитектура/ADR, затронутые спецификации и код. Локальная ошибка сборки, линтера или очевидный implementation bug → инструкции и код нужного repo; документация → docs/AGENTS.md и CONTRIBUTING.md. Расширяй контекст по конкретному пробелу; missing required source или конфликт требований сообщи до зависимого решения.
6. При новой границе и перед завершением повтори routing по actual staged, unstaged и новым файлам. Сохраняй чужие изменения; уточнение контекста не расширяет задачу.
7. Проверь результат по задаче, рискованным случаям и local gates. Сохрани краткие команды/результаты; сообщи оставшиеся ограничения. Успех lint/tests не заменяет semantic review.

Перед Node-командой активируй `.nvmrc` affected repo через `nvm use --silent`.

## Ветки и релизы

Новая работа — в отдельной ветке от `develop`, затем PR в `develop`.
Прямой push в `main` запрещён. Commits и заголовки PR — Conventional Commits.
Перед release/hotfix, merge между `main` и `develop`, изменением release-конфигурации
или CI refs прочитай [процесс релиза](README.md#релизы-и-ветки).