Bicycle/.claude/memory/feedback_reference_code_handling.md

name	description	metadata
feedback-reference-code-handling	Пользователь часто присылает код из своих других проектов (eoffice_v3 и т.п.) как референс — как с этим работать	type project

Пользователь регулярно кидает готовый код из своих старых/других проектов (/home/isaevea/http/eoffice_v3 и подобные) как образец того, что нужно сделать в Bicycle — целыми классами (Repository, Model, render()-методы Controller, CSS/JS-подключение во View). Это не абстрактные пожелания, а буквальный рабочий код, который он хочет видеть похожим здесь.

Why: Несколько раз за сессию 2026-08-07 я либо: (а) придумывал что-то стилистически похожее, но не совпадающее с тем, что он реально писал в своём коде (например свойство $_driver вместо $pdo — он дважды написал $this->pdo сам, прежде чем я понял, что нужно называть именно так), либо (б) слепо копировал референс, не заметив реальные баги/нестыковки в нём (в eoffice_v3 Repository::getList() по умолчанию FETCH_KEY_PAIR — падает не на ровно 2 колонках; FETCH_CLASS не получает obj_class; свой счётчик вложенности транзакций в каждом Repository — ломается, если два репозитория делят одно PDO-подключение). На прямой вопрос «у нас свой проект, мне нужно не также а правильно» — стало ясно: копировать вслепую не нужно, нужно оценивать критически.

How to apply:

1. Когда пользователь присылает референс-код — сначала спросить себя (не обязательно вслух), реально ли это то, что нужно 1-в-1, или в нём могут быть баги/устаревшие паттерны конкретно под старый проект (например поддержка нескольких "модулей", которых в Bicycle нет).
2. Портировать с адаптацией под реалии Bicycle (уже собранные классы вроде PdoConnection с его SAVEPOINT- логикой могут делать что-то лучше/надёжнее, чем то, что в референсе — не дублировать хуже).
3. Если сомневаешься, действительно ли имя/сигнатура должны совпадать буквально — можно посмотреть исходник самого референс-проекта на диске (он часто лежит рядом, в других папках /home/isaevea/http/*), а не гадать по вставленным фрагментам — так нашлись оригиналы Database.php/PdoDriver.php/ Statement.php/ProfilerPDO.php/Repository.php в eoffice_v3/System/Classes/ (имя файла там осталось PdoDriver.php — это чужой проект, не переименовывался вслед за нашим PdoConnection).
4. Если пользователь явно пишет что-то вроде $this->pdo (даже с ошибкой в другом месте кода) — это сильный сигнал именно про нейминг, не опечатка; после второго повтора — не переспрашивать, а сразу переименовывать под него (см. также feedback-less-confirmation).
5. После адаптации — явно резюмировать пользователю, ЧТО именно отличается от референса и почему (иначе выглядит как будто я не выполнил задачу «сделай как там»), см. пример в roadmap.md.