From 3efd8e5060eb22aec99993f6e1ae02bdd88e1a24 Mon Sep 17 00:00:00 2001 From: ackFromRedmi Date: Thu, 16 Apr 2026 23:43:58 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9F=D0=BE=D0=B4=D0=BD=D0=B0=D1=81=D1=82?= =?UTF-8?q?=D1=80=D0=BE=D0=B8=D0=BB=20=D0=BF=D1=80=D0=B0=D0=B2=D0=B8=D0=BB?= =?UTF-8?q?=D0=B0=20=D0=B8=20=D0=B2=D0=B2=D0=B5=D0=BB=20=D1=87=D0=B5=D0=B9?= =?UTF-8?q?=D0=BD=D0=B4=D0=B6=D0=BB=D0=BE=D0=B3?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- .trae/rules/main.md | 123 ++++++++++++++++++-------------------------- CHANGELOG.md | 22 ++++++++ 2 files changed, 72 insertions(+), 73 deletions(-) create mode 100644 CHANGELOG.md diff --git a/.trae/rules/main.md b/.trae/rules/main.md index a2111ba..488f771 100644 --- a/.trae/rules/main.md +++ b/.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) - -## 8) Транзакции и гонки данных (warehouse/shiftflow) -- Все операции списания/начисления на складе делай в transaction.atomic() . -- На изменяемые складские остатки используй select_for_update() чтобы избежать гонок. -- Для массовых операций избегай N+1: - - select_related / prefetch_related - - bulk update/create там, где это безопасно. +### Комментарии +- Python/бекенд: добавлять поясняющие комментарии там, где есть бизнес‑логика, транзакции, конкурентность, фоновые задачи, сложные алгоритмы (BOM, списания, начисления). + - Комментарии нейтральные: описывают поведение/причину, без личных формулировок. +- Django HTML‑шаблоны: не добавлять template‑комментарии ({# ... #}). -## 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 ...') — не глотаем, пробрасываем дальше \ No newline at end of file + - Is readonly: режим “только просмотр”. diff --git a/CHANGELOG.md b/CHANGELOG.md new file mode 100644 index 0000000..ce46b89 --- /dev/null +++ b/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 и процесс ведения истории изменений. \ No newline at end of file