docs: refactor project docs and agents tasks

docs/agents/agent_architect.md

@@ -12,11 +12,12 @@
   - `edit_and_rules.md` — редактирование и правила категорий
   - `analytics.md` — аналитика и бюджеты
   - `auth.md` — авторизация и сессии
+  - `api_reference_accounts_categories.md` — справочники (accounts, categories)
 
 ## Цели агента
 
 1. Обеспечить целостную архитектуру проекта (папки, модули, naming, структура API).
-2. Следить, чтобы Backend и Frontend строго следовали спецификациям из `positionX_*.md`.
+2. Следить, чтобы Backend и Frontend строго следовали спецификациям из `*.md`.
 3. Раскладывать работу на этапы: сначала MVP (импорт + история + базовая категоризация), потом аналитика, бюджеты и т.д.
 4. Давать чёткие задачи Backend- и Frontend-агентам в виде:
    - какие файлы создать/изменить,

docs/agents/agent_backend.md

@@ -16,22 +16,23 @@
 - `edit_and_rules.md`
 - `analytics.md`
 - `auth.md`
+- `api_reference_accounts_categories.md`
 
 ## Основные задачи MVP
 
-1. Структура проекта
+1 Структура проекта
 
 - Создать каркас BE: `src/app.ts`, `src/routes/*`, `src/db/*`, `src/middleware/*`, `src/services/*`.
 - Реализовать конфигурацию:
   - переменные окружения (в т.ч. логин/пароль для авторизации),
   - строки подключения к Postgres.
 
-1. Миграции БД
+2 Миграции БД
 
 - Реализовать таблицы и поля строго по `db.md`, `category.md`, `edit_and_rules.md`, `analytics.md`.
 - Включить все описанные CHECK/UNIQUE/FOREIGN KEY/дополнительные поля (`is_category_confirmed`, `comment`, `alias` для accounts, `budgets` и т.д.).
 
-1. Авторизация и сессии
+3 Авторизация и сессии
 
 - Реализовать эндпоинты:
   - `POST /api/auth/login`
@@ -44,7 +45,7 @@
   - проверяет 3-часовой таймаут бездействия,
   - обнуляет сессию и отдаёт `401` по истечении таймаута.
 
-1. Импорт выписки
+4 Импорт выписки
 
 - Эндпоинт (например) `POST /api/import/statement`:
   - Принимает JSON строго формата 1.0 (см. `format.md`).
@@ -56,23 +57,23 @@
     - вставляет в `transactions` с учётом уникального индекса `(account_id, fingerprint)`,
     - по умолчанию `is_category_confirmed = FALSE`, `category_id = NULL`.
 
-1. История операций
+5 История операций
 
 - Реализовать `GET /api/transactions` по `api_history.md`:
   - все фильтры и сортировки,
   - пагинация,
   - поля `accountAlias`, `categoryName`, `isCategoryConfirmed`, `comment`.
 
-1. Редактирование транзакций и правила категорий
+6 Редактирование транзакций и правила категорий
 
 - Эндпоинт `PUT /api/transactions/{id}`:
   - Обновляет `category_id`, `comment`, `is_category_confirmed`.
 - Эндпоинты для `category_rules`:
-  - создание правила на основе входных данных (pattern, match_type, category_id, priority),
-  - обновление/деактивация,
-  - опционально — применение правила к истории (bulk-обновление транзакций с `is_category_confirmed = FALSE`).
+  - создание правила на основе входных данных (pattern, match_type, category_id, priority, requires_confirmation),
+  - обновление/деактивация (PATCH),
+  - применение правила к прошлым транзакциям (bulk-обновление: только `category_id IS NULL` или `is_category_confirmed = FALSE`).
 
-1. Аналитика
+7 Аналитика
 
 - Реализовать:
   - `GET /api/analytics/summary`

docs/agents/agent_frontend.md

@@ -13,17 +13,18 @@
   - `edit_and_rules.md`
   - `analytics.md`
   - `auth.md`
+  - `api_reference_accounts_categories.md`
   - а также модели данных и категорий из `db.md`, `category.md`.
 
 ## Основные экраны
 
-1. Логин
+1 Логин
 
 - Форма `login/password`, запрос `POST /api/auth/login`.
 - При успехе — переход на Историю.
 - При `401` на любых защищённых запросах — редирект на Login.
 
-1. История операций
+2 История операций
 
 - Таблица с колонками:
   - Дата,
@@ -50,7 +51,7 @@
   - галочка “Создать правило для похожих транзакций в будущем” (по умолчанию включена),
   - вызов `PUT /api/transactions/{id}` и соответствующего API для правил (если решено вызывать напрямую).
 
-1. Аналитика
+3 Аналитика
 
 - Верхний блок выбора периода: неделя/месяц/год/произвольный + стрелки “←/→” (кроме произвольного).
 - Фильтры:
@@ -60,7 +61,7 @@
 - Блок 2: график времени (`/api/analytics/timeseries`).
 - Блок 3: диаграмма/таблица по категориям (`/api/analytics/by-category`).
 
-1. Настройки (минимум)
+4 Настройки (минимум)
 
 - Список счетов с алиасами:
   - отображение номера счёта и alias,

docs/agents/agent_rules_analytics.md

@@ -9,7 +9,7 @@
 
 2. Следить за тем, чтобы:
    - все суммы считаются в копейках,
-   - учитывался флаг `is_category_confirmed`,
+   - учитывались флаги `is_category_confirmed` и `requires_confirmation`,
    - фильтры по периодам/счётам/категориям корректно отражались в SQL.
 
 3. Подготавливать “чистые” интерфейсы для FE:
@@ -21,7 +21,8 @@
   - `db.md`,
   - `api_history.md`,
   - `edit_and_rules.md`,
-  - `analytics.md`.
+  - `analytics.md`,
+  - `api_reference_accounts_categories.md`.
 
 ## Ограничения
 

docs/agents/agent_statement_converter.md

@@ -24,7 +24,7 @@
 
 ## Задачи агента
 
-1. Конвертация PDF → сырые строки
+1 Конвертация PDF → сырые строки
 
 - Использовать доступный инструмент (локальный ИИ/LLM API или библиотеку),
   чтобы преобразовать PDF-выписку в структурированный текст/табличное представление:
@@ -32,7 +32,7 @@
   - таблица операций (дата/время, сумма, комиссия, описание и т.п.).
 - Корректно обрабатывать переносы строк в описании операции.
 
-1. Маппинг полей в JSON 1.0
+2 Маппинг полей в JSON 1.0
 
 - Извлечь из заголовка:
   - `accountNumber`,
@@ -45,19 +45,19 @@
   - выделить `commission` (если в выписке отдельная колонка, иначе `0`);
   - сформировать `description` как максимально близкое к тексту из выписки поле.
 
-1. Нормализация сумм
+3 Нормализация сумм
 
 - Все суммы, которые приходят в формате `12345.67`, должны быть преобразованы в целое число копеек:
   - `12345.67 → 1234567`.
 - Важно избегать ошибок округления (использовать работу со строками, а не float).
 
-1. Проверка целостности (по возможности)
+4 Проверка целостности (по возможности)
 
 - При наличии `openingBalance` и `closingBalance`:
   - проверить, что `openingBalance + Σ(amountSigned) == closingBalance` (с допустимой погрешностью, если есть комиссии/особые операции);
   - если проверка не проходит, вернуть предупреждение вместе с JSON (или отдельный отчёт).
 
-1. Выходной результат
+5 Выходной результат
 
 - Агент должен возвращать один JSON-объект строго по схеме 1.0.
 - Дополнительно может возвращаться диагностическая информация (лог), но она должна быть отделена от финального JSON.