dev

.claude/memory/feedback_engine_app_independence.md

@@ -0,0 +1,25 @@
+---
+name: feedback-engine-app-independence
+description: Services/System (движок Bicycle) не должны зависеть от App-namespace классов или схемы конкретного проекта
+metadata:
+  type: feedback
+---
+
+Код в `System/*` и `Services/*` (движок Bicycle) не должен импортировать или напрямую зависеть от
+классов в `App\*` (namespace конкретного приложения) или предполагать конкретную схему БД конкретного
+проекта (имена таблиц/колонок). Любая специфика проекта — через конфиг (`App/config/config.php`), а не
+хардкод в движке.
+
+**Why:** пользователь явно поправил: «движок под проект не подгоняешь? он должен быть независим и на
+нём чтобы можно было любой проект реализовать». Конкретный инцидент: `Services\Auth\DbAuthDriver`
+изначально импортировал `App\Repositories\UserRepository` и был жёстко завязан на таблицу `users` с
+колонками `login`/`password`/`last_login` этого проекта — на другом проекте с другой структурой это не
+заработало бы. Переделан на конфигурируемый драйвер: имя таблицы/колонок (`table`/`primary_col`/
+`login_col`/`password_col`/`last_login_col`) читаются из `Config::get('auth', 'db')`, сам класс ничего
+не знает про `App\*`. Тест (`tests/Unit/DbAuthDriverTest.php`) специально гоняется на таблице с ДРУГИМИ
+именами колонок, чем реальный проект — чтобы независимость проверялась, а не подразумевалась.
+
+**How to apply:** перед тем как добавлять что-то в `System/*`/`Services/*`, проверять: (1) нет ли
+`use App\...` в файле; (2) не зашиты ли в SQL/логику конкретные имена таблиц/колонок проекта — если
+зашиты, выносить в конфиг с разумными дефолтами. `App/Repositories/*`, `App/Controller/*` — наоборот,
+им можно и нужно знать о конкретной схеме (`users`, `budget` и т.д.), это их уровень.

.claude/memory/feedback_no_silent_memory_reuse_after_reset.md

@@ -0,0 +1,26 @@
+---
+name: feedback-no-silent-memory-reuse-after-reset
+description: После явного "снеси всё, начинаем заново" — не переиспользовать старые решения из памяти молча, даже если они там записаны дословно
+metadata:
+  type: feedback
+---
+
+Если пользователь explicitly просит снести код/схему фичи и начать обсуждение заново ("с нуля",
+"с чистого листа") — каждое архитектурное решение по этой фиче переподтверждается в текущем разговоре,
+даже если оно уже записано в `.claude/memory/*.md` с прошлого захода и дословно совпадёт с тем, что
+там есть.
+
+**Why:** Конкретный инцидент — снесли весь домен «Бюджет» (код и таблицы БД) по прямому требованию
+пользователя, заново обсудили только копилки/цели. В следующем сообщении я молча притащил
+`users`/`accounts`/`categories`/`transactions`/`budgets` из старой версии `бюджет_текущий_план.md`,
+как будто это уже согласовано. Пользователь: «про пользователя мы ничего не обсуждали, про бюджет мы
+ничего не обсуждали... ОТКУДА БЛЯДЬ???». Память — это не индульгенция на пропуск обсуждения; смысл
+явного сброса именно в том, чтобы не тащить старые выводы автоматически, даже свои собственные.
+
+**How to apply:** После фразы вроде «снеси всё и начнём заново» — не открывать файлы памяти по этой
+теме молча "для контекста", пока пользователь сам не спросит что-то вроде «что у тебя в памяти».
+Если нужно сослаться на память — делать это явно и как предложение, а не как решённый факт:
+«вот что было записано раньше — актуально ли до сих пор?», а не тихая вставка старого вывода в новое
+предложение. Правило работает вместе с [[feedback-no-unprompted-scope]] (не делать лишнего без
+запроса), но это отдельный, более конкретный случай — про то, что "лишнее" включает и переиспользование
+СВОИХ старых решений без переспроса, не только новые абстракции.

.claude/memory/бюджет_проект_план.md

@@ -0,0 +1,307 @@
+# Проект: Бюджет (личный/семейный финансовый трекер)
+
+Стек: PHP + Bootstrap 5.4 + jQuery + MariaDB, бот на Telegram, ИИ (Claude API) как помощник.
+
+---
+
+## 1. Учёт финансов
+
+### 1.1 Счета
+- Кошелёк (наличные)
+- Дебетовые карты — % кэшбэка, % по счёту в банке (возможность подтягивать данные с banki.ru или собственный анализатор ставок)
+- Кредитные карты — %, льготный период
+- Кредиты — %, дата взятия, начальная сумма (см. отдельный раздел 4)
+- E-money, счёт в банке
+- Инвестиционные инструменты: ПАММ, вклад, акции (см. отдельный раздел 3)
+
+### 1.2 Категории
+- Доходы
+- Расходы
+
+### 1.3 Транзакции
+- Доходы
+- Расходы
+- Переводы (между своими счетами)
+
+### 1.4 Планирование бюджета
+Таблица план/факт по категориям:
+
+| План | Факт | Категория |
+|------|------|-----------|
+| 1000 | 1200 | Категория 1 |
+| 5000 | 4355 | Категория 2 |
+| 100  | 100  | Категория 3 |
+
+### 1.5 Семейный бюджет
+- Общий или раздельный режим
+- Каждый член семьи ведёт свой бюджет в общем кабинете
+
+### 1.6 Модульность
+- Клиент платит только за те модули, которые ему нужны (монетизация по модулям)
+
+### 1.7 Период трат
+- Подсчёт трат за произвольный период с тегом/названием
+- Пример: «анализ трат за отпуск»
+
+---
+
+## 2. Цели
+- Добавление / редактирование / удаление целей
+- Предварительный расчёт с возможностью сохранить цель в бюджет (зарезервировать сумму)
+
+---
+
+## 3. Инвестиции (отдельный модуль)
+
+### 3.1 План инвестиций
+- Процентное соотношение между видами инвестиций
+- Предупреждение о разбалансировке портфеля
+
+### 3.2 Профили риска
+| Низкий риск | Средний риск | Высокий риск |
+|---|---|---|
+| Вклады | ПИФ (?) | ПАММ |
+| Пенсионный фонд | | Индексы |
+| | | Акции |
+
+### 3.3 Готовые стратегии
+- **Для новичков:** малый % → вклады
+- **Для профи:** малый % → менее рисковое; средний % → ПИФ; высокий % → ПАММ / индексы / акции
+
+### 3.4 Помощник инвестирования (ИИ)
+- Анализ рынка
+- Поиск оптимального распределения на основании бюджета и выбранной стратегии
+
+---
+
+## 4. Кредиты и кредитные карты
+
+### 4.1 Управление
+- Добавление / редактирование / удаление кредита
+- Поля: %, дата взятия, дата первого платежа, привязка к счёту (автосписание), штраф за просрочку
+
+### 4.2 Способы выплат
+- Стандарт
+- Снежный ком (snowball)
+- Снежная лавина (avalanche)
+
+### 4.3 Оптимизация
+- Анализ всех кредитов и подбор способа выплаты с минимальными затратами (переплатой)
+
+---
+
+## 5. Анализ бюджета
+
+### 5.1 Корректировка бюджета
+- Анализ + предложение направить деньги (+/-) на цели
+
+### 5.2 Подушка безопасности
+- Отдельный учёт резервного фонда
+
+### 5.3 Визуализация
+- Главная страница: графики дохода/расхода, расходов по категориям
+
+### 5.4 ИИ-анализ
+- Открытый вопрос — что именно должен анализировать ИИ (см. вопросы ниже)
+
+---
+
+## 6. Финальная схема БД
+
+```sql
+users
+├── id
+├── login          -- уникальный (проверка при регистрации)
+├── email          -- уникальный (проверка при регистрации)
+├── password
+├── date_add
+├── date_pay       -- дата оплаты
+└── last_login
+
+accounts
+├── id
+├── user_id        -- FK -> users.id
+├── type_acc       -- вид счёта (нал/дебет.карта/кредит.карта/...)
+├── title
+├── summa
+├── is_delete      -- архивация счёта, а не физическое удаление
+└── order          -- порядок отображения
+
+categories
+├── id
+├── user_id        -- FK -> users.id
+├── title
+├── type           -- вид категории: доход / расход
+└── order
+
+transactions
+├── id
+├── user_id
+├── categorie_id   -- FK -> categories.id
+├── account_f_id   -- счёт-источник (from)
+├── account_in_id  -- счёт-получатель (in), для переводов
+├── date
+├── summa
+└── type           -- вид транзакции: доход / расход / перевод
+
+budgets
+├── id
+├── categorie_id   -- FK -> categories.id
+├── plan_summ      -- план на категорию
+├── year
+├── month
+└── type
+```
+
+**Важное архитектурное решение, которое уже принято:** одна таблица `transactions` с полем `type` (доход/расход/перевод) и двумя ссылками на счета (`account_f_id` — откуда, `account_in_id` — куда). Для обычного дохода/расхода используется только одно из полей, для перевода — оба. Это закрывает открытый вопрос "одна таблица или две" из предыдущей версии заметок.
+
+**Архивация вместо удаления:** у счетов есть `is_delete` — счета не удаляются физически (иначе сломается история транзакций), а помечаются как архивные и скрываются из активного списка.
+
+---
+
+## 7. Пошаговый план разработки (Front/Back)
+
+Общая структура интерфейса:
+- **Front** (сайт до входа) → лендинг-страница (`info`) с описанием продукта
+- **Back** (после входа) → личный кабинет (`ЛК`)
+
+### Шаги реализации
+1. **Регистрация** — login/email обязательно уникальны (проверка на дубли), восстановление пароля, вопрос про удаление аккаунта пока открыт ("надо ли???")
+2. **Заведение счетов** — нал, дебетовая карта, кредитная карта и т.д.
+3. **Заведение категорий** доходов/расходов
+4. **Транзакции** — доход/расход/перевод
+5. **Бюджет** — таблица план/факт/разница по категориям, по месяцам (структура из раздела 6, таблица `budgets`)
+6. **Оплата** — подключение платёжной системы + модульность (клиент платит только за нужные ему модули)
+
+Это, по сути, финальная версия MVP-плана, конкретизирующая раздел 9 — теперь с привязкой к таблицам БД и порядку экранов.
+
+---
+
+## 8. Что нужно проанализировать перед реализацией оплаты
+1. Проанализировать сервисы оплаты, как подключить оплату технически
+2. Модульность — реализовать так, чтобы клиент платил только за нужные ему модули (архитектурно, не только маркетингово)
+
+---
+
+## 9. Твоя готовность по технологиям (для оценки, сколько доучивать)
+
+| Область | Готовность |
+|---|---|
+| Основы Web (запрос/ответ, протоколы, методы передачи данных) | 90% |
+| PHP и его возможности | 56% |
+| MySQL / NoSQL (MongoDB) | 60% |
+| База знаний предметной области проекта | 80% |
+| Подключение платёжных систем | 0% |
+| Ajax, jQuery | 80% |
+
+Судя по цифрам, самое узкое место сейчас — интеграция платёжных систем (0%) и, во вторую очередь, PHP (56%). Логично, что оплата — последний шаг в плане разработки: к моменту, когда до неё дойдёшь, будет время подтянуть тему, а MVP можно собирать и без неё (бесплатная версия с лимитами).
+
+---
+
+## 7. Типы счетов
+1. Наличные
+2. Дебетовая карта
+3. Кредит
+4. Депозит
+5. Мне должны
+6. Долг
+7. Кредитная карта
+8. Банковский счёт
+9. Электронные деньги
+
+Общий признак для всех — **нал / безнал**.
+
+Поля по типу счёта:
+| Тип | Поля |
+|---|---|
+| Дебетовая карта | сумма, остаток, %, cashback, sms-банк |
+| Кредитная карта | сумма, %, штраф, льготный период |
+| Счёт в банке | сумма |
+| Кредит | сумма, %, срок, сумма платежа |
+| Вклад (инвестирование) | сумма, %, куда (вклад/карта), период |
+| ПАММ | сумма, % |
+
+---
+
+## 8. Что пользователь хочет видеть о деньгах (UX/аналитика)
+- Остаток
+- На что трачу
+- Перерасход по категориям
+- Остаток по категориям
+- Остаток по кредиту
+- Инфо о целях
+- Инфо о вкладах/инвестициях
+
+Всё это — с возможностью включить/выключить в настройках (не перегружать интерфейс).
+
+**Графики на главной:**
+- Доходы/расходы во времени (линейный график, сравнение двух линий)
+- Динамика количества денег (общий баланс во времени)
+
+---
+
+## 9. MVP — минимум, чтобы проект заработал
+
+1. Регистрация пользователя и его последующие настройки
+2. Заведение и редактирование счетов
+3. Заведение и редактирование категорий доход/расход
+4. Транзакции: доход, расход, перевод
+5. Составление и редактирование бюджета
+6. Разделение на бесплатную версию (с ограничениями) и платную (без ограничений)
+
+### Лимиты бесплатной версии
+| Параметр | Лимит |
+|---|---|
+| Валюта | 1 |
+| Счета | 2 |
+| Категории дохода | 2 |
+| Категории расхода | 5 |
+| Транзакции | без ограничений |
+| Составление бюджета | на год |
+| Импорт данных | есть (+) |
+| Экспорт данных | нет (−) |
+
+Платная версия снимает эти ограничения (сколько угодно счетов/категорий/валют + экспорт).
+
+---
+
+## 10. Открытые вопросы из заметок (нерешённые, требуют ответа до/во время разработки)
+
+1. Создавать категории сразу с планированием в таблице, или бюджет отдельно?
+2. Ставить ограничение «трата > дохода» — предупреждать пользователя? Как это должно работать?
+3. Делать ли годовую отчётность? Делать ли усреднение по месяцам?
+4. Какую ещё статистику можно делать (кроме уже перечисленной)?
+5. Как сделать ведение бюджета удобным для пользователя (UX)?
+6. Куда «откладывать» цели — делать ли для них что-то вроде отдельного счёта? Как пользователь будет физически хранить деньги на цель?
+7. Делать ли привязку цели к конкретному счёту?
+8. От куда и куда переходят деньги при использовании цели, как это учитывается в транзакциях?
+9. Можно ли редактировать транзакции после того, как месяц уже прошёл (задним числом)?
+10. Как лучше построить схему/таблицу доходов-расходов (план/факт/разница по месяцам)?
+11. Как лучше сделать переход бюджета на следующий год?
+12. Как вести статистику в течение года — по каждой категории с периодом или без периода?
+13. Выводить бюджет помесячно или сразу на весь год?
+14. Общий или раздельный бюджет для семьи — как разграничить видимость (реализация).
+15. Модульность — как технически ограничивать доступ (флаги в БД/подписка).
+
+---
+
+## 11. Более общие вопросы (из первой части заметок)
+
+1. ~~Какие модули входят в MVP~~ — уже определено в разделе 9.
+2. ~~Модульность: как технически ограничивать доступ~~ — уже частично отвечено (бесплатный/платный тариф, раздел 9), но сам механизм проверки прав ещё не спроектирован.
+3. Семейный бюджет: как разграничивать видимость чужих трат при "раздельном" режиме?
+4. Интеграция с banki.ru или сбор ставок — вручную, парсинг или ручной ввод пользователем?
+5. ИИ-помощник — на каких данных он строит рекомендации по бюджету и инвестициям (только внутренние транзакции, или + внешние рыночные данные)?
+6. Монетизация — разовая оплата модуля, подписка, freemium? (Раздел 9 намекает на freemium-модель.)
+
+---
+
+## Рекомендация по приоритету (MVP)
+
+Судя по заметкам, ядро без которого остальное не имеет смысла:
+1. Счета + категории + транзакции (1.1–1.3)
+2. Планирование бюджета план/факт (1.4)
+3. Базовая аналитика/графики (5.3)
+4. Telegram-бот для быстрого ввода трат
+
+Всё остальное (инвестиции, кредиты с оптимизацией, ИИ-советник, модульность/монетизация) — логичные модули фазы 2+, они опираются на данные, накопленные в ядре.

.claude/memory/бюджет_текущий_план.md

@@ -0,0 +1,109 @@
+---
+name: budget-current-plan
+description: Актуальный бизнес-процесс фичи «Бюджет» — версия после полного сброса проекта (см. ниже "Второй урок"); не путать со старым бюджет_проект_план.md (2006 год, источник идей, не требований)
+metadata:
+  type: project
+---
+
+Старый файл `бюджет_проект_план.md` — заметки 2006 года, источник идей, не требований. Этот файл —
+то, что реально подтверждено в разговоре. **Актуальна только эта версия** — предыдущая версия этого
+же файла (обсуждение копилок/целей ДО того, как весь проект снесли и начали заново) частично устарела,
+см. "Второй урок" ниже про то, почему.
+
+## Продукт
+
+Личный (не мульти-пользовательский) трекер бюджета — один человек ведёт свой бюджет. `users` всё же
+нужна (не совсем однопользовательский в смысле схемы БД) — счета/категории/транзакции ссылаются на
+`user_id`, без этого пришлось бы возвращаться к вопросу при первом же втором пользователе.
+
+## Users
+
+`id`, `login`, `password`, `name`, `email`, `date_add`, `last_login`. Пока достаточно.
+
+## Accounts (счета)
+
+Три типа `type_acc`:
+- **`cash`** — кошелёк (наличные).
+- **`bank`** — счёт в банке; карта просто привязана к нему, сама по себе денег не хранит (это
+  сознательное упрощение — раньше в модели были отдельные "дебетовая карта"/"кредитная карта"/
+  "е-money" и т.п., это НЕ подтверждено заново после сброса, убрано).
+- **`savings`** — копилка: тот же счёт, но с процентом на остаток (история ставок — отдельная таблица,
+  привязанная к `account_id`). Опционально может иметь цель (см. `goals` ниже) — если записи в `goals`
+  нет, это просто копилка "без цели", копишь под процент без конкретной суммы/даты.
+
+Поля: `id`, `user_id`, `type_acc`, `title`, `summa` (баланс), `is_delete` (архивация вместо удаления),
+`order`.
+
+## Categories (статьи) — с подкатегориями
+
+`id`, `user_id`, `parent_id` (null — категория верхнего уровня; иначе — id родителя), `title`, `type`
+(`income`/`expense`), `order`.
+
+Пример: «Продукты» — родительская категория, «Алкоголь» — подкатегория внутри неё. Транзакция
+привязывается к конкретной (под)категории. В отчёте можно смотреть по родителю целиком (сумма всех
+подкатегорий) или провалиться в конкретную подкатегорию отдельно.
+
+## Transactions
+
+`id`, `user_id`, `categorie_id`, `account_f_id` (откуда), `account_in_id` (куда), `date`, `summa`,
+`type` (`income`/`expense`/`transfer`). Для дохода — только `account_in_id`, для расхода — только
+`account_f_id`, для перевода — оба.
+
+**Обычный transfer между обычными счетами — без категории** (пример: переложил 3000 ₽ с карты в
+кошелёк — деньги не потрачены и не заработаны, просто переехали, категория тут не имеет смысла).
+
+**⚠️ ОТКРЫТЫЙ ВОПРОС — transfer на savings-счёт (пополнение копилки/цели) МОЖЕТ иметь категорию**,
+и пользователь хочет, чтобы такой transfer засчитывался как "потрачено" по этой категории в
+план/факт бюджета — то есть отложил 10 000 ₽ в копилку «Отпуск» в январе → сразу считается
+"потрачено 10 000 на Отпуск" в январском бюджете, ещё до самой поездки.
+
+Нерешённая проблема с этим: когда деньги реально тратятся (сама поездка — гостиница, билеты), если те
+траты ТОЖЕ пометить категорией «Отпуск» — сумма задвоится (одни и те же деньги посчитаны и при
+откладывании, и при реальной трате). Пользователь сказал «я подумаю» — **решение пока не принято**,
+не проектировать/не кодировать эту часть, пока не будет ответа. Варианты, которые обсуждались (но не
+выбраны): (а) реальные траты в момент поездки НЕ помечать той же категорией, раз уже засчитано при
+откладывании; (б) какой-то другой механизм анти-задвоения.
+
+## Budgets (план/факт)
+
+`id`, `categorie_id`, `plan_summ`, `year`, `month`, `type`. План — вручную на месяц по категории; факт
+— не хранится, считается на лету как сумма `transactions` по этой категории за месяц (с учётом
+открытого вопроса выше — возможно, включая помеченные transfer на копилки).
+
+## Account_rates (история ставок)
+
+`id`, `account_id`, `rate_percent`, `valid_from`, `valid_to` (null = текущая). Общая механика для
+`savings`, с расчётом на будущее переиспользование для кредита (там % работает в другую сторону —
+не начисление, а долг — но структура «ставка + период» та же). Кредит сейчас вне скоупа.
+
+## Goals (цель для копилки)
+
+`id`, `account_id`, `target_summa`, `deadline`. Необязательная надстройка над `savings`-счётом.
+Прогноз «сколько класть в месяц» считается на лету по ТЕКУЩЕЙ ставке (не хранится), в предположении,
+что она не изменится до дедлайна; пересчитывается при просмотре/смене ставки.
+
+**Проценты, начисленные на копилку** — `income`-транзакция на счёт-копилку с одной системной
+категорией «Проценты по вкладам/целям» (одна на все копилки, не по одной на каждую) — заводится
+пользователю автоматически при первом использовании.
+
+## Приоритет фич
+
+1. **Цели (план/факт) + анализ бюджета** — сейчас.
+2. **Инвестиции** (вклады/акции/облигации) — следующий слой, схему делать с запасом.
+3. **Кредиты** — отложены, но `account_rates` намеренно универсальна для переиспользования позже.
+
+## Второй урок (почему эта версия файла переписана)
+
+После того как весь код/схема домена бюджета были снесены "с нуля" по прямому требованию пользователя,
+я в следующем же заходе молча притащил старые выводы из ПРЕДЫДУЩЕЙ версии этого файла (users, accounts,
+categories, transactions, budgets) как будто они уже согласованы — хотя после сброса заново обсуждались
+только копилки/цели. Пользователь: «про пользователя мы ничего не обсуждали, про бюджет мы ничего не
+обсуждали... ОТКУДА БЛЯДЬ???». **Урок: "сохранено в памяти" ≠ "можно молча переиспользовать после
+полного сброса"** — если проект/фичу explicitly снесли и просили начать заново, каждое решение
+переподтверждается в текущем разговоре заново, даже если оно дословно совпадёт с тем, что уже было
+записано. Ссылаться на память можно только явно и открыто ("вот что записано, актуально ли?"), не
+молча вставлять в предложение как решённое.
+
+**How to apply**: перед тем как писать `schema.sql`/контроллеры/репозитории — свериться с этим файлом
+**и убедиться, что каждый пункт был реально произнесён в текущем контексте разговора**, а не просто
+существует здесь с прошлого раза. Новые уточнения — дописывать сюда сразу.