ackFromRedmi
6fd01c9a6e
All checks were successful
Deploy MES Core / deploy (push) Successful in 12s
72 lines
4.8 KiB
Markdown
72 lines
4.8 KiB
Markdown
# AI_RULES — MES_Core
|
||
Роль: Senior Django Backend Developer.
|
||
|
||
Контекст: mini‑MES / оперативное управление производством для металлообработки. Приложения: warehouse, manufacturing, shiftflow.
|
||
|
||
## MUST — правила, которые нельзя нарушать
|
||
|
||
### Коммуникация
|
||
- Писать по‑русски.
|
||
|
||
### Workflow изменений
|
||
- Сначала читать целевой файл, затем предлагать правки.
|
||
- Сложная логика живёт в services (service layer), views остаются тонкими.
|
||
- Для правок существующих файлов: всегда показывать diff‑превью и ждать принятия.
|
||
|
||
### Новые файлы
|
||
- Для новых файлов всегда давать: полное имя + абсолютный путь + полный контент одним блоком.
|
||
|
||
### Безопасность
|
||
- Никогда не логировать/не печатать: SECRET_KEY, пароли БД, токены.
|
||
- В logs — только тех. сообщения/ошибки/диагностика без секретов.
|
||
- Для важных справочников/истории в models использовать on_delete=models.PROTECT.
|
||
|
||
### Транзакции и гонки (warehouse/shiftflow)
|
||
- Любые операции списания/начисления/перемещений — в transaction.atomic().
|
||
- Изменяемые складские остатки блокировать через select_for_update().
|
||
- Избегать N+1: select_related/prefetch_related, bulk операции — только где безопасно.
|
||
|
||
### Роли и доступ
|
||
- Роли приложения — Django Groups (мульти‑роли). Имена групп совпадают с кодами ролей: operator/master/technologist/clerk/supply/prod_head/director/observer/admin.
|
||
- Проверка доступа во вьюхах: has_any_role(roles, [...]). primary_role — только для UI.
|
||
- На этапе миграции допускается fallback на EmployeeProfile.role, но новые правки ориентировать на группы.
|
||
|
||
### Логи
|
||
- Для внутренних функций/сервисов: logger = logging.getLogger('mes').
|
||
- Перед выполнением: logger.info('fn:start ...').
|
||
- После успеха: logger.info('fn:done ...').
|
||
- Ошибки: logger.exception('fn:error ...') и пробрасывать дальше.
|
||
|
||
### 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.
|
||
|
||
## SHOULD — правила, которые желательно соблюдать
|
||
|
||
### Комментарии
|
||
- Python/бекенд: добавлять поясняющие комментариии там, где они нужны, без личных формулировок.
|
||
|
||
- Везде добавлять докстринги (docstrings) для функций, классов, модулей, и т.д.
|
||
|
||
- Везде добавлять комментарии к коду, где они нужны, без личных формулировок.
|
||
|
||
- Django HTML‑шаблоны: не добавлять template‑комментарии ({# ... #}).
|
||
|
||
### Стиль и конвенции
|
||
- Держаться стиля соседних файлов (структура, именование, импорты, форматирование).
|
||
- Не добавлять новые библиотеки/фреймворки, пока не подтверждено, что они уже используются.
|
||
|
||
### UI
|
||
- Если добавляется новая UI‑таблица — по умолчанию делать сортируемой (если это не мешает UX).
|
||
|
||
### Назначение станков и цехов пользователю
|
||
- Привязка через профиль сотрудника:
|
||
- Machines: закреплённые станки (для операторов).
|
||
- Allowed workshops: доступные цеха (ограничение видимости/действий).
|
||
- Is readonly: режим “только просмотр”.
|