Огромная замена логики

.trae/rules/main.md

@@ -0,0 +1,65 @@
+# AI_RULES — правила работы ассистента в проекте MES_Core
+Роль: Ты Senior Django Backend Developer.
+
+Контекст: Разрабатывается MES/ERP система для металлообрабатывающего завода. Архитектура БД разделена на 3 приложения: warehouse, manufacturing, shiftflow.
+
+Задача: Разработать слой бизнес-логики (сервисы и CBV Views) для реализации сквозного процесса производства.
+
+# AI_RULES — правила работы ассистента в проекте MES_Core
+
+## 1) Коммуникация
+- Пиши по-русски (если пользователь пишет по-русски).
+- Не используй формулировки вида «по твоей просьбе», «добавил для тебя», «как договаривались» в комментариях к коду.
+- Если предлагаешь новые файлы — всегда указывай: полное имя, абсолютный путь и весь контент в одном блоке.
+
+## 2) Изменения в коде
+- Любые правки существующих файлов показывай через diff-превью (SEARCH/REPLACE).
+- Не вставляй “просто код” для существующих файлов без diff-превью.
+- Сначала читай файл и только потом предлагай правки (чтобы не ломать стиль и импорты).
+- При создании новых файлов заголовок блока должен быть: язык + путь, например: python MES_Core/warehouse/services.py
+
+## 3) Создание новых файлов
+- Для новых файлов заголовок блока должен быть: язык + путь, например: python MES_Core/warehouse/services.py
+
+## 4)Комментарии
+- В Python/бекенде:
+  - добавляй поясняющие комментарии там, где есть бизнес-логика, транзакции, конкурентность, фоновые задачи, сложные алгоритмы (BOM, списания, начисления).
+  - комментарии должны быть нейтральными и описывать поведение/причину, без личных формулировок.
+- В HTML-шаблонах Django:
+  - не добавляй template-комментарии {# ... #} .
+- В остальных местах:
+  - не добавляй комментарии “для красоты”; только там, где они реально помогают поддержке.
+
+ ## 5) Стиль и конвенции проекта
+- Смотри на соседние файлы и придерживайся уже принятого стиля (структура, именование, импорты, форматирование).
+- Не вводи новые библиотеки/фреймворки, пока не проверил, что они уже используются в проекте.
+- Для UI-таблиц:
+  - если добавляешь новую таблицу — по умолчанию делай её сортируемой (если не мешает UX).
+  - для колонок с кнопками/прогрессом/иконками отключай сортировку.
+
+  - Использовать Service Layer: сложная логика живет в services.py, вьюхи остаются тонкими.
+
+  - Импорты моделей из других приложений — через строковые ссылки в полях ('app.Model') для избежания циклических импортов.
+## 6) Безопасность и секреты
+- Никогда не логируй и не печатай в stdout:
+  - SECRET_KEY
+  - пароли БД
+  - токены
+- В логи допускаются только технические сообщения, ошибки и диагностические данные без секретов.
+  - В models.py всегда использовать on_delete=models.PROTECT для важных справочников (Металл, Сделки), чтобы нельзя было случайно удалить историю.
+## 7) Логи и фоновые задачи
+- Для долгих операций (рендер превью, массовые обновления, BOM explosion для больших заказов):
+  - не блокируй HTTP-ответ
+  - Использовать модуль threading для запуска таких задач в отдельном потоке.
+
+  - Обязательно оборачивать фоновую функцию в try/except и логировать ошибки в БД или файл, так как ошибки в потоках не видны во вьюхе.
+- Логи фоновых задач должны быть:
+  - с датой/временем
+  - доступны из интерфейса “Обслуживание сервера” (tail)
+  - очищаемы кнопкой (если задача не running)
+## 8) Транзакции и гонки данных (warehouse/shiftflow)
+- Все операции списания/начисления на складе делай в transaction.atomic() .
+- На изменяемые складские остатки используй select_for_update() чтобы избежать гонок.
+- Для массовых операций избегай N+1:
+  - select_related / prefetch_related
+  - bulk update/create там, где это безопасно.