From 29c98a2a7a321ccb7e5f3708f70b18694be4b857 Mon Sep 17 00:00:00 2001 From: IsaevEA Date: Mon, 10 Aug 2026 23:24:41 +0300 Subject: [PATCH] dev --- .../feedback_engine_app_independence.md | 25 ++ ...back_no_silent_memory_reuse_after_reset.md | 26 ++ .claude/memory/бюджет_проект_план.md | 307 ++++++++++++++++++ .claude/memory/бюджет_текущий_план.md | 109 +++++++ 4 files changed, 467 insertions(+) create mode 100644 .claude/memory/feedback_engine_app_independence.md create mode 100644 .claude/memory/feedback_no_silent_memory_reuse_after_reset.md create mode 100644 .claude/memory/бюджет_проект_план.md create mode 100644 .claude/memory/бюджет_текущий_план.md diff --git a/.claude/memory/feedback_engine_app_independence.md b/.claude/memory/feedback_engine_app_independence.md new file mode 100644 index 0000000..2a3eea0 --- /dev/null +++ b/.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` и т.д.), это их уровень. diff --git a/.claude/memory/feedback_no_silent_memory_reuse_after_reset.md b/.claude/memory/feedback_no_silent_memory_reuse_after_reset.md new file mode 100644 index 0000000..5c308d3 --- /dev/null +++ b/.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]] (не делать лишнего без +запроса), но это отдельный, более конкретный случай — про то, что "лишнее" включает и переиспользование +СВОИХ старых решений без переспроса, не только новые абстракции. diff --git a/.claude/memory/бюджет_проект_план.md b/.claude/memory/бюджет_проект_план.md new file mode 100644 index 0000000..96b0618 --- /dev/null +++ b/.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+, они опираются на данные, накопленные в ядре. diff --git a/.claude/memory/бюджет_текущий_план.md b/.claude/memory/бюджет_текущий_план.md new file mode 100644 index 0000000..b3a58e1 --- /dev/null +++ b/.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`/контроллеры/репозитории — свериться с этим файлом +**и убедиться, что каждый пункт был реально произнесён в текущем контексте разговора**, а не просто +существует здесь с прошлого раза. Новые уточнения — дописывать сюда сразу.