Реализует issue #23: тип и статус счетов, автоклассификация брокерских/ИИС/накопительных счетов как инвестиций, отдельный показатель дохода от процентов для накопительных счетов.
Реализует issue #23: тип и статус счетов, автоклассификация брокерских/ИИС/накопительных счетов как инвестиций, отдельный показатель дохода от процентов для накопительных счетов.
Версии: frontend 0.10.0, backend 0.7.0, shared 0.3.0.
Review findings (blocking): 1) frontend/src/pages/AnalyticsPage.tsx и TransactionFilters.tsx по-прежнему показывают в выборе счёта только alias/номер — тип и статус недоступны при выборе счёта в аналитике, что нарушает критерий issue #23. 2) В import.ts операции инвестиционного счёта сразу получают is_category_confirmed = TRUE, поэтому последующий SQL авторазметки правил их пропускает (WHERE t2.is_category_confirmed = FALSE); правила возвратов/прочих операций не могут переопределить дефолтную категорию «Инвестиции», хотя она должна быть fallback. 3) Нет проверки повторного импорта, сохраняющей ручные accountType/status; добавьте тест (и желательно тест API/сервиса). Сборки shared/backend/frontend и semantics test проходят; DB integration test не запустился в sandbox (EPERM для tsx IPC).
Review findings (blocking): 1) `frontend/src/pages/AnalyticsPage.tsx` и `TransactionFilters.tsx` по-прежнему показывают в выборе счёта только alias/номер — тип и статус недоступны при выборе счёта в аналитике, что нарушает критерий issue #23. 2) В `import.ts` операции инвестиционного счёта сразу получают `is_category_confirmed = TRUE`, поэтому последующий SQL авторазметки правил их пропускает (`WHERE t2.is_category_confirmed = FALSE`); правила возвратов/прочих операций не могут переопределить дефолтную категорию «Инвестиции», хотя она должна быть fallback. 3) Нет проверки повторного импорта, сохраняющей ручные `accountType/status`; добавьте тест (и желательно тест API/сервиса). Сборки shared/backend/frontend и semantics test проходят; DB integration test не запустился в sandbox (EPERM для tsx IPC).
Повторный review после dd29903: оба прежних замечания по отображению в фильтрах и приоритету правил исправлены. Остались блокирующие замечания: 1) backend/src/services/accounts.ts при ручной классификации существующего счёта назначает «Инвестиции», но оставляет is_category_confirmed = FALSE. При включённом «Только подтверждённые» все эти операции пропадут из аналитики, а правила для уже существующих операций не применяются. Нужно либо выполнить тот же rule-first/fallback проход, либо подтвердить fallback после применения правил. 2) По-прежнему нет теста, проверяющего повторный импорт после ручного изменения accountType/status (критерий issue #23). Дополнительно: в аналитических списках показываются технические значения savings/brokerage/..., тогда как в списке счетов используются русские подписи; лучше унифицировать отображение. Проверки: сборки shared/backend/frontend и test:analytics проходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.
Повторный review после dd29903: оба прежних замечания по отображению в фильтрах и приоритету правил исправлены. Остались блокирующие замечания: 1) `backend/src/services/accounts.ts` при ручной классификации существующего счёта назначает «Инвестиции», но оставляет `is_category_confirmed = FALSE`. При включённом «Только подтверждённые» все эти операции пропадут из аналитики, а правила для уже существующих операций не применяются. Нужно либо выполнить тот же rule-first/fallback проход, либо подтвердить fallback после применения правил. 2) По-прежнему нет теста, проверяющего повторный импорт после ручного изменения `accountType/status` (критерий issue #23). Дополнительно: в аналитических списках показываются технические значения `savings/brokerage/...`, тогда как в списке счетов используются русские подписи; лучше унифицировать отображение. Проверки: сборки shared/backend/frontend и `test:analytics` проходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.
Финальный review после c6b79c1: функциональные замечания исправлены — существующие операции подтверждаются, типы в аналитических фильтрах русифицированы. Остался один блокирующий пробел по критериям issue #23: в PR нет проверки повторного импорта, которая подтверждает сохранение вручную заданных accountType и status. Сам код импорта метаданные не обновляет, но это требование должно быть закреплено runnable-тестом (интеграционный или сервисный). Сборки shared/backend/frontend и test:analytics проходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.
Финальный review после c6b79c1: функциональные замечания исправлены — существующие операции подтверждаются, типы в аналитических фильтрах русифицированы. Остался один блокирующий пробел по критериям issue #23: в PR нет проверки повторного импорта, которая подтверждает сохранение вручную заданных `accountType` и `status`. Сам код импорта метаданные не обновляет, но это требование должно быть закреплено runnable-тестом (интеграционный или сервисный). Сборки shared/backend/frontend и `test:analytics` проходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.
Финальный review: добавленный test:import:db сейчас не является runnable-тестом из-за connector-а. В тесте db.connect всегда возвращает один и тот же уже взятый client, но importStatement в каждом вызове вызывает client.release() в finally. После первого импорта второй вызов и промежуточный client.query(UPDATE ...) работают с освобождённым клиентом и должны завершиться Client has already been released. Нужен connector, который выдаёт новый pool client на каждый вызов, либо изменение владения/release в тестовой обвязке. В остальном по diff прежние замечания исправлены. В sandbox запуск также блокируется EPERM для tsx IPC.
Финальный review: добавленный `test:import:db` сейчас не является runnable-тестом из-за connector-а. В тесте `db.connect` всегда возвращает один и тот же уже взятый `client`, но `importStatement` в каждом вызове вызывает `client.release()` в `finally`. После первого импорта второй вызов и промежуточный `client.query(UPDATE ...)` работают с освобождённым клиентом и должны завершиться `Client has already been released`. Нужен connector, который выдаёт новый pool client на каждый вызов, либо изменение владения/release в тестовой обвязке. В остальном по diff прежние замечания исправлены. В sandbox запуск также блокируется EPERM для tsx IPC.
Финальный review после 3d7d0e6 завершён без blocking findings. Тест повторного импорта теперь использует отдельные pool clients, cleanup выполняется в порядке transactions → imports → accounts; проверка сохранения accountType/status присутствует. Миграция, API/UI, rule-first/fallback классификация и interest metric согласованы с требованиями. Проверки: сборки shared/backend/frontend и git diff --check проходят. test:import:db в sandbox не запускается из-за ограничения окружения tsx IPC (listen EPERM /tmp/tsx-1000/*.pipe), а не из-за ошибки теста.
Финальный review после 3d7d0e6 завершён без blocking findings. Тест повторного импорта теперь использует отдельные pool clients, cleanup выполняется в порядке transactions → imports → accounts; проверка сохранения `accountType/status` присутствует. Миграция, API/UI, rule-first/fallback классификация и interest metric согласованы с требованиями. Проверки: сборки shared/backend/frontend и `git diff --check` проходят. `test:import:db` в sandbox не запускается из-за ограничения окружения `tsx` IPC (`listen EPERM /tmp/tsx-1000/*.pipe`), а не из-за ошибки теста.
admin
merged commit 5f282d199d into main2026-08-20 06:15:32 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Реализует issue #23: тип и статус счетов, автоклассификация брокерских/ИИС/накопительных счетов как инвестиций, отдельный показатель дохода от процентов для накопительных счетов.
Версии: frontend 0.10.0, backend 0.7.0, shared 0.3.0.
Review findings (blocking): 1)
frontend/src/pages/AnalyticsPage.tsxиTransactionFilters.tsxпо-прежнему показывают в выборе счёта только alias/номер — тип и статус недоступны при выборе счёта в аналитике, что нарушает критерий issue #23. 2) Вimport.tsоперации инвестиционного счёта сразу получаютis_category_confirmed = TRUE, поэтому последующий SQL авторазметки правил их пропускает (WHERE t2.is_category_confirmed = FALSE); правила возвратов/прочих операций не могут переопределить дефолтную категорию «Инвестиции», хотя она должна быть fallback. 3) Нет проверки повторного импорта, сохраняющей ручныеaccountType/status; добавьте тест (и желательно тест API/сервиса). Сборки shared/backend/frontend и semantics test проходят; DB integration test не запустился в sandbox (EPERM для tsx IPC).Повторный review после
dd29903: оба прежних замечания по отображению в фильтрах и приоритету правил исправлены. Остались блокирующие замечания: 1)backend/src/services/accounts.tsпри ручной классификации существующего счёта назначает «Инвестиции», но оставляетis_category_confirmed = FALSE. При включённом «Только подтверждённые» все эти операции пропадут из аналитики, а правила для уже существующих операций не применяются. Нужно либо выполнить тот же rule-first/fallback проход, либо подтвердить fallback после применения правил. 2) По-прежнему нет теста, проверяющего повторный импорт после ручного измененияaccountType/status(критерий issue #23). Дополнительно: в аналитических списках показываются технические значенияsavings/brokerage/..., тогда как в списке счетов используются русские подписи; лучше унифицировать отображение. Проверки: сборки shared/backend/frontend иtest:analyticsпроходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.Финальный review после
c6b79c1: функциональные замечания исправлены — существующие операции подтверждаются, типы в аналитических фильтрах русифицированы. Остался один блокирующий пробел по критериям issue #23: в PR нет проверки повторного импорта, которая подтверждает сохранение вручную заданныхaccountTypeиstatus. Сам код импорта метаданные не обновляет, но это требование должно быть закреплено runnable-тестом (интеграционный или сервисный). Сборки shared/backend/frontend иtest:analyticsпроходят; DB integration test в sandbox не запускается из-за EPERM для tsx IPC.Финальный review: добавленный
test:import:dbсейчас не является runnable-тестом из-за connector-а. В тестеdb.connectвсегда возвращает один и тот же уже взятыйclient, ноimportStatementв каждом вызове вызываетclient.release()вfinally. После первого импорта второй вызов и промежуточныйclient.query(UPDATE ...)работают с освобождённым клиентом и должны завершитьсяClient has already been released. Нужен connector, который выдаёт новый pool client на каждый вызов, либо изменение владения/release в тестовой обвязке. В остальном по diff прежние замечания исправлены. В sandbox запуск также блокируется EPERM для tsx IPC.Финальный review после
3d7d0e6завершён без blocking findings. Тест повторного импорта теперь использует отдельные pool clients, cleanup выполняется в порядке transactions → imports → accounts; проверка сохраненияaccountType/statusприсутствует. Миграция, API/UI, rule-first/fallback классификация и interest metric согласованы с требованиями. Проверки: сборки shared/backend/frontend иgit diff --checkпроходят.test:import:dbв sandbox не запускается из-за ограничения окруженияtsxIPC (listen EPERM /tmp/tsx-1000/*.pipe), а не из-за ошибки теста.