Базовые принципы

Код CUBIX должен быть безопасным, понятным, типизированным и совместимым с Windows-разработкой и Linux production. Изменения держи узкими: сначала исправляй владеющий слой, затем проверяй поведение.

Именование и структура

• Переменные и функции: camelCase.
• Типы и интерфейсы: PascalCase.
• Константы: UPPER_SNAKE_CASE.
• Файлы: kebab-case, Vue-компоненты: PascalCase.
• Не используй any, если контракт можно описать интерфейсом, union-типом или generic.
• API routes размещай в server/api/ с суффиксами .get.ts, .post.ts, .patch.ts, .delete.ts.
• Страницы собирай из существующих CS*-компонентов и прикладных компонентов модуля.

Server routes

Для защищённого endpoint порядок действий такой:

1. Получить текущую сессию через requireUserSession(event).
2. Получить текущего пользователя через getCurrentUserId(event) или существующий server helper.
3. Прочитать и проверить body/query через Zod.
4. Проверить право пользователя на операцию и доступность ресурса.
5. Выполнить Prisma-запрос с ограничениями, соответствующими текущему isolated instance.
6. Вернуть минимально необходимый ответ.

Не принимай от браузера userId, tenantId или другой идентификатор, который должен определяться сервером. Идентификатор сущности из URL всё равно нужно проверять через доступ текущего пользователя.

Prisma и данные

• Используй Prisma вместо конкатенации SQL.
• Применяй select для больших ответов.
• Используй include или предварительную выборку вместо N+1 запросов.
• Для больших списков добавляй pagination и ограничивай take.
• Не скрывай удаление или изменение данных за неявным fallback.
• Не логируй пароли, токены, cookie и полные персональные данные.

В target каждый клиент работает в изолированном экземпляре и базе. Не добавляй в запросы поля, которых нет в текущей Prisma-схеме, только потому что они присутствуют в старой инструкции. Если модель содержит tenantId, фильтр должен приходить из серверного контекста, а не из запроса клиента.

Валидация и ошибки

Входные данные валидируй до бизнес-логики. Для ошибки используй createError с корректным HTTP-статусом и безопасным сообщением. Ошибки валидации должны оставлять форму открытой и показывать пользователю, что нужно исправить; после успешного ответа UI должен обновить зависимые данные.

Не используй браузерные alert и confirm. Для уведомлений применяй существующий useNotifications/notification store, для подтверждений - проектный dialog-компонент.

Vue и Nuxt UI

• Новые экраны target используют Nuxt UI и Tailwind CSS v4.
• Vuetify допускается только внутри существующих совместимых обёрток или legacy-экранов.
• Перед созданием компонента проверь app/@core/components/CS-UI/ и публичные exports @cs-platform/ui-kit.
• Не дублируй бизнес-логику между страницей и drawer: вынеси общий поток в composable или server service.
• Обрабатывай pending, пустой результат, server error, disabled/saving и повторную загрузку.
• Не закрывай drawer/slideover до завершения успешного сохранения.

Проверка изменений

• После первой правки запусти узкий typecheck, lint, тест или проверку ошибок для изменённого файла.
• Для API проверь 401, невалидный body, отсутствие доступа и успешный сценарий.
• Для форм проверь create, edit, validation error, server error, loading и refresh.
• Для списков проверь pagination, пустое состояние и отсутствие повторных запросов.
• Не исправляй несвязанные failing tests без отдельной причины.

Git и документация

Используй короткие сообщения коммитов в формате type(scope): subject, если коммит требуется рабочим процессом репозитория. При изменении публичного компонента, composable или обработчика обновляй соответствующий реестр и документацию. Документация должна отражать target-код, а устаревшие legacy-примеры нужно удалять или явно помечать как исторические.