Поднастроил правила и ввел чейнджлог

.trae/rules/main.md

@@ -1,90 +1,67 @@
-# AI_RULES — правила работы ассистента в проекте MES_Core
-Роль: Ты Senior Django Backend Developer.
+# AI_RULES — MES_Core
+Роль: Senior Django Backend Developer.
 
-Контекст: Разрабатывается MES/ERP система для металлообрабатывающего завода. Архитектура БД разделена на 3 приложения: warehouse, manufacturing, shiftflow.
+Контекст: mini‑MES / оперативное управление производством для металлообработки. Приложения: warehouse, manufacturing, shiftflow.
 
-Задача: Разработать слой бизнес-логики (сервисы и CBV Views) для реализации сквозного процесса производства.
+## MUST — правила, которые нельзя нарушать
 
-# AI_RULES — правила работы ассистента в проекте MES_Core
+### Коммуникация
+- Писать по‑русски.
 
-## 1) Коммуникация
-- Пиши по-русски всегда.
+### Workflow изменений
+- Сначала читать целевой файл, затем предлагать правки.
+- Сложная логика живёт в services (service layer), views остаются тонкими.
+- Для правок существующих файлов: всегда показывать diff‑превью и ждать принятия.
 
-## 2) Изменения в коде
-- Сначала читай файл и только потом предлагай правки (чтобы не ломать стиль и импорты).
+### Новые файлы
+- Для новых файлов всегда давать: полное имя + абсолютный путь + полный контент одним блоком.
 
-## 3) Создание новых файлов
-- Для новых файлов звсегда указывай: полное имя, абсолютный путь и весь контент в одном блоке.
+### Безопасность
+- Никогда не логировать/не печатать: SECRET_KEY, пароли БД, токены.
+- В logs — только тех. сообщения/ошибки/диагностика без секретов.
+- Для важных справочников/истории в models использовать on_delete=models.PROTECT.
 
-## 4)Комментарии
-- В Python/бекенде:
-  - добавляй поясняющие комментарии там, где есть бизнес-логика, транзакции, конкурентность, фоновые задачи, сложные алгоритмы (BOM, списания, начисления).
-  - комментарии должны быть нейтральными и описывать поведение/причину, без личных формулировок.
-- В HTML-шаблонах Django:
-  - не добавляй template-комментарии {# ... #} .
+### Транзакции и гонки (warehouse/shiftflow)
+- Любые операции списания/начисления/перемещений — в transaction.atomic().
+- Изменяемые складские остатки блокировать через select_for_update().
+- Избегать N+1: select_related/prefetch_related, bulk операции — только где безопасно.
 
- ## 5) Стиль и конвенции проекта
-- Смотри на соседние файлы и придерживайся уже принятого стиля (структура, именование, импорты, форматирование).
-- Не вводи новые библиотеки/фреймворки, пока не проверил, что они уже используются в проекте.
-- Для UI-таблиц:
-  - если добавляешь новую таблицу — по умолчанию делай её сортируемой (если не мешает UX).
+### Роли и доступ
+- Роли приложения — Django Groups (мульти‑роли). Имена групп совпадают с кодами ролей: operator/master/technologist/clerk/supply/prod_head/director/observer/admin.
+- Проверка доступа во вьюхах: has_any_role(roles, [...]). primary_role — только для UI.
+- На этапе миграции допускается fallback на EmployeeProfile.role, но новые правки ориентировать на группы.
 
-  - Использовать Service Layer: сложная логика живет в services.py, вьюхи остаются тонкими.
+### Логи
+- Для внутренних функций/сервисов: logger = logging.getLogger('mes').
+- Перед выполнением: logger.info('fn:start ...').
+- После успеха: logger.info('fn:done ...').
+- Ошибки: logger.exception('fn:error ...') и пробрасывать дальше.
 
-  - Импорты моделей из других приложений — через строковые ссылки в полях ('app.Model') для избежания циклических импортов.
+### Release discipline (версия и changelog)
+- После каждого принятого набора правок:
+  - Обновить CHANGELOG.md в секции [Unreleased] (Added/Changed/Fixed).
+  - В конце ответа всегда писать: “Нужно ли поднять версию? Рекомендация: …”.
+- Правило bump (SemVer):
+  - UI/шаблоны/стили/тексты → PATCH (x.y.Z).
+  - Логика/вьюхи/сервисы/модели/миграции/доступы → MINOR (x.Y.0).
+  - Изменения данных/совместимости → обсудить MAJOR (X.0.0), даже если проект ещё в 0.x.
 
-## 6) Безопасность и секреты
-- Никогда не логируй и не печатай в stdout:
-  - SECRET_KEY
-  - пароли БД
-  - токены
-- В логи допускаются только технические сообщения, ошибки и диагностические данные без секретов.
-  - В models.py всегда использовать on_delete=models.PROTECT для важных справочников (Металл, Сделки), чтобы нельзя было случайно удалить историю.
-## 7) Логи и фоновые задачи
-- Для долгих операций (рендер превью, массовые обновления, BOM explosion для больших заказов):
-  - не блокируй HTTP-ответ
-  - Использовать модуль threading для запуска таких задач в отдельном потоке.
+## SHOULD — правила, которые желательно соблюдать
 
-  - Обязательно оборачивать фоновую функцию в try/except и логировать ошибки в БД или файл, так как ошибки в потоках не видны во вьюхе.
-- Логи фоновых задач должны быть:
-  - с датой/временем
-  - доступны из интерфейса “Обслуживание сервера” (tail)
-  - очищаемы кнопкой (если задача не running)
+### Комментарии
+- Python/бекенд: добавлять поясняющие комментарии там, где есть бизнес‑логика, транзакции, конкурентность, фоновые задачи, сложные алгоритмы (BOM, списания, начисления).
+  - Комментарии нейтральные: описывают поведение/причину, без личных формулировок.
+- Django HTML‑шаблоны: не добавлять template‑комментарии ({# ... #}).
 
-## 8) Транзакции и гонки данных (warehouse/shiftflow)
-- Все операции списания/начисления на складе делай в transaction.atomic() .
-- На изменяемые складские остатки используй select_for_update() чтобы избежать гонок.
-- Для массовых операций избегай N+1:
-  - select_related / prefetch_related
-  - bulk update/create там, где это безопасно.
+### Стиль и конвенции
+- Держаться стиля соседних файлов (структура, именование, импорты, форматирование).
+- Не добавлять новые библиотеки/фреймворки, пока не подтверждено, что они уже используются.
 
-## 9) Роли и доступ (Django Groups)
-- Использовать Django Groups как роли приложения (мульти-роли).
-- Имена групп должны совпадать с кодами ролей, используемых в коде, например:
-  - operator
-  - master
-  - technologist
-  - clerk
-  - supply
-  - prod_head
-  - director
-  - observer
-  - admin
-- Назначение ролей в Django admin:
-  - Users → выбрать пользователя → поле Groups → добавить нужные группы → Save.
-- Примечание: на этапе миграции допускается fallback на EmployeeProfile.role, чтобы при деплое до раздачи групп доступ не "слетал".
+### UI
+- Если добавляется новая UI‑таблица — по умолчанию делать сортируемой (если это не мешает UX).
 
 ### Назначение станков и цехов пользователю
-- Привязка станков/цехов делается через профиль сотрудника:
-  - Shiftflow → Employee profiles → выбрать профиль пользователя.
+- Привязка через профиль сотрудника:
   - Machines: закреплённые станки (для операторов).
   - Allowed workshops: доступные цеха (ограничение видимости/действий).
-  - Is readonly: режим "только просмотр".
-
-  Правило для новых внутренних функций (как договор):
-
-- Всегда берём логгер logger = logging.getLogger('mes')
-- Перед выполнением — logger.info('fn:start ...', ключевые параметры)
-- После успешного выполнения — logger.info('fn:done ...', ключевые результаты)
-- На важных шагах — logger.info('fn:step ...', детали)
-- Исключение — с context: logger.exception('fn:error ...') — не глотаем, пробрасываем дальше
+  - Is readonly: режим “только просмотр”.

CHANGELOG.md

@@ -0,0 +1,22 @@
+# Changelog
+
+Все заметные изменения в этом проекте документируются в этом файле.
+
+Формат — по мотивам “Keep a Changelog”, версионирование — SemVer (пока 0.x).
+- UI/шаблоны/стили/тексты → увеличиваем PATCH (x.y.Z)
+- Логика/вьюхи/сервисы/модели/миграции/доступы → увеличиваем MINOR (x.Y.0)
+- Изменения, влияющие на данные/совместимость → обсуждаем MAJOR (X.0.0), даже если проект ещё в 0.x
+
+## [Unreleased]
+### Added
+- 
+
+### Changed
+- 
+
+### Fixed
+- 
+
+## [0.7.1] - 2026-04-16
+### Added
+- Введён CHANGELOG.md и процесс ведения истории изменений.