41 lines
4.0 KiB
Plaintext
41 lines
4.0 KiB
Plaintext
# Project Context
|
|
You are building an Enterprise Identity Provider (IdP) ecosystem, heavily inspired by "Yandex ID".
|
|
Domain: id.lendry.ru
|
|
The project is a monorepo consisting of microservices.
|
|
|
|
# Tech Stack & Constraints
|
|
- Backend (Core): NestJS, TypeScript, @nestjs/microservices.
|
|
- Backend (Media/WS): Golang (Gorilla WebSocket).
|
|
- Frontend & Docs: Next.js (App Router), React, Tailwind CSS.
|
|
- UI Library: STRICTLY `shadcn/ui` (latest) and `lucide-react` for icons. Do NOT use other UI libraries.
|
|
- Database & ORM: PostgreSQL, **Prisma v7.0.0+**. CRITICAL: Use strictly Prisma 7+ syntax. Do not use deprecated Prisma features.
|
|
- Infrastructure: Docker, Redis, RabbitMQ, gRPC (Protobuf).
|
|
|
|
# Language & Localization (CRITICAL)
|
|
- The ENTIRE user-facing application, UI elements, tooltips, placeholders, and documentation MUST be in Russian.
|
|
- ALL backend error messages, validation messages (e.g., class-validator), logs, and exception throws MUST be in Russian (e.g., `throw new UnauthorizedException('Неверный пароль')`).
|
|
- Variable names, functions, database columns, and comments should remain in English.
|
|
|
|
# Autonomous Execution Rules
|
|
- You are running in an autonomous Agent mode.
|
|
- ALWAYS write complete, production-ready code. NEVER leave `// TODO: implement later` or placeholder stubs.
|
|
- Whenever you finish a logical block or phase, use the terminal to verify your work (e.g., `npm run lint`, `npx tsc --noEmit`, `npx prisma validate`, `go build`).
|
|
- If a terminal command fails, read the error output carefully, fix the code, and run the command again. You have 3 attempts to self-correct before halting.
|
|
- Do NOT modify existing working code unless explicitly necessary to fix a bug or integrate a new feature.
|
|
|
|
# Specific Business Logic Rules
|
|
- Super Admin Race Condition: The first registered user MUST become `isSuperAdmin = true`. Use Redis locks or Serializable PG transactions to prevent race conditions.
|
|
- PIN Code Logic: If `PinCode.isEnabled` is true, login yields a session with `pinVerified = false` (temporary state). User must enter PIN to unlock full session.
|
|
- NO HARDCODING: Global business rules (like session lock timeouts, max family members) must be dynamic. Fetch them from the `SystemSetting` database table via API, do not hardcode values in the frontend codebase.
|
|
|
|
# ANTI-LAZINESS & UI/UX FIDELITY DIRECTIVES (CRITICAL)
|
|
- DO NOT TAKE SHORTCUTS: Never choose the "easy", "cheap", or "lazy" implementation path. If a complex UI component is required, build it properly.
|
|
- NO STATIC MOCKS: Do not build "Potemkin villages". Every button, tab, and form you create MUST have actual state management, onClick handlers, and API connections attached to it immediately.
|
|
- UNIFIED COMPONENTS: When a visual reference shows a complex, monolithic component (e.g., a flag dropdown integrated *inside* a masked phone input), you MUST build the custom unified version using wrappers and focus-within states. DO NOT fallback to placing disconnected standard components next to each other.
|
|
- PREMIUM FEEL: Always implement micro-interactions. Use input masking (e.g., `+7 (999) 000-00-00`), loading spinners inside buttons during API calls, smooth transitions, and proper empty/error states.
|
|
- COMPLETE THE JOB: Never leave `// TODO: implement later` comments. Write the full, production-ready logic right now.
|
|
|
|
# HOLISTIC IMPLEMENTATION & VISUAL COMPLIANCE (CRITICAL)
|
|
- SYSTEMIC THINKING: If you modify a UI component or business logic flow (e.g., Auth/Login), you MUST actively check if parallel or related flows (e.g., Registration, Password Reset, Profile Edit) require the same updates. Never leave half the system outdated.
|
|
- EXPLICIT VISUALS: If instructions mention specific visual elements (e.g., "Unicode emoji flags", "specific icons"), you must implement them EXACTLY. Do not substitute with plain text labels (like "RU" instead of 🇷🇺) to save time.
|
|
- REUSABILITY: Never duplicate complex UI logic. Complex elements (like a masked phone input with a dropdown) MUST be extracted into standalone, reusable React components (e.g., `components/ui/phone-input.tsx`) and imported wherever needed. |