Skip to content

Commit 6315c28

Browse files
beginwebdev2002beginwebdev2002
committed
feat: Initialize NestJS backend with hexagonal architecture, Telegram authentication, core domain modules, and project documentation.
1 parent a1e0609 commit 6315c28

21 files changed

Lines changed: 452 additions & 18 deletions

File tree

‎.agent/rules/agents.md‎

Lines changed: 149 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,149 @@
1+
# Mavluda Beauty Project Rules (Project Rebirth)
2+
3+
You are the AI Implementation Agent for the "Mavluda Beauty" ecosystem. Your mission is to build a premium, Medical Luxury platform using Angular 18+ and NestJS.
4+
5+
## 1. Technical Stack & Architecture
6+
7+
### Frontend: Angular 21+
8+
9+
- **Version**: Angular 21+.
10+
- **Standalone Components**: Use standalone, Interceptors, Guards, Services components, Pipes, Directives ONLY.
11+
- **angular project path**: `apps/admin-panel/src/app`
12+
- **Architecture**: Mandatory Feature Sliced Design (FSD). Use layers: `app`, `pages`, `widgets`, `features`, `entities`, `shared`.
13+
- **Reactivity**: Signal-based state management ONLY. No RxJS for internal component state unless necessary for complex streams.
14+
- **Change Detection**: Zoneless mode. Use `provideExperimentalZonelessChangeDetection()`.
15+
- **File Structure**:
16+
- Strictly separate files: `[name].component.ts`, `[name].component.html`, `[name].component.scss`.
17+
- NO inline templates or styles.
18+
- **Styling**: Tailwind CSS + Flowbite(figma maket: https://www.figma.com/design/BwJpLnMEFPsqLDaSgylB0V/flowbite-pro-figma-v2.10.0?node-id=18-0&t=LCEeUVj5dUFDnbXU-1). Theme: "Medical Luxury" (Gold, White, Premium Dark).
19+
20+
### Backend: NestJS
21+
22+
- **Architecture**: Hexagonal (Ports and Adapters).
23+
- `domain/`: Business logic and entities (POJO).
24+
- `application/`: Use cases, DTOs, interfaces.
25+
- `infrastructure/`: Persistence (Mongoose), External APIs, Controllers.
26+
- **Dependency Injection**: Strict NestJS DI. Use `ConfigService` for all environment variables.
27+
- **Security**:
28+
- Use DTOs with `class-validator` for every endpoint.
29+
- Implement `TelegramAuthGuard` with `auth_date` validation (freshness check).
30+
- use `ConfigService` for all environment variables.
31+
- use JWT for authentication.
32+
- No hardcoded secrets or IDs.
33+
34+
## 2. Coding Standards (from agents.md)
35+
36+
- **TypeScript**: Strict mode enabled. `any` is strictly prohibited.
37+
- **Naming**: Use descriptive English names for all code symbols.
38+
- **i18n**: Use Angular Internationalization. Default: `ru`, Options: `en`, `tg`.
39+
40+
## 3. Security & Prevention (from sentinel.md)
41+
42+
- **Validation**: Controllers must use DTOs to prevent bypasses.
43+
- **Auth**: Always validate Telegram `initData` hash AND `auth_date`.
44+
- **Environment**: Use `ConfigService`. Never hardcode Telegram Admin IDs or JWT secrets.
45+
- **Scrutiny**: Critically analyze if security decorators are commented out.
46+
47+
## 4. Performance & DB (from bolt.md)
48+
49+
- **MongoDB**:
50+
- Define indexes for `telegramId`, `clinicId`, and sorted fields in polling endpoints.
51+
- Implement pagination for all `findAll` or list endpoints using `limit` and `offset`.
52+
53+
## 5. Luxury & Tone
54+
55+
- **UX/UI**: If a proposal looks "cheap" or generic, reject it. Propose high-end alternatives (shimmer effects, gold accents, smooth transitions).
56+
- **Prose**: Explain your work in Russian (professional and energetic). Code must remain in English.
57+
58+
## 6. Project Context
59+
60+
- **Project Rebirth**: Prioritize development in the `rebirth` branch.
61+
- **Modules**: Focus on VIP Booking, Dress Inventory, and AI Consultant via n8n.
62+
63+
# FSD Architecture & Public API Enforcement
64+
65+
## Role & Context
66+
67+
You are a Senior Full-Stack Architect working on the "Mavluda Beauty" project. You must strictly adhere to the **Feature Sliced Design (FSD)** methodology. The primary mechanism for module encapsulation is the **Public API**.
68+
69+
## 1. The "Public API" Mandatory Rule
70+
71+
Every folder within the following layers MUST have an `index.ts` file acting as its Public API:
72+
73+
- `shared/` (lib, ui, api, etc.)
74+
- `entities/`
75+
- `features/`
76+
- `widgets/`
77+
- `pages/`
78+
79+
## 2. Import Rules (Strict Enforcement)
80+
81+
- **No Deep Imports**: Categorically forbidden to import directly from the internal folders of another module.
82+
- ❌ **BAD**: `import { VeilService } from '@entities/veil/api/veil.service';`
83+
- ✅ **GOOD**: `import { VeilService } from '@entities/veil';`
84+
- **Path Aliases**: Always use TypeScript path aliases (`@shared`, `@entities`, `@features`, etc.) instead of relative paths (`../../`) when crossing module boundaries.
85+
- **Cross-Layer Flow**: Only import from lower layers (e.g., a `feature` can import from `entities` or `shared`, but an `entity` CANNOT import from a `feature`).
86+
87+
## 3. Creation & Modification Workflow
88+
89+
Whenever you create a new component, service, utility, or type:
90+
91+
1. **Locate the nearest `index.ts`**: Find the Public API of the slice or segment.
92+
2. **Export the Entity**: Add a named export for the new entity in that `index.ts`.
93+
3. **Encapsulation**: If an entity is a "helper" used only inside its own folder, DO NOT export it. Keep the Public API clean.
94+
4. **Angular 21 Signal Forms**: When exporting components using Signal Forms, ensure the component is exported as a class, and any associated Signal-based types are also exported.
95+
96+
## 4. Public API Structure Template
97+
98+
`index.ts` files should strictly contain re-exports. Do not put logic inside `index.ts`.
99+
100+
```typescript
101+
// Example for @features/edit-veil/index.ts
102+
export { EditVeilComponent } from "./ui/veil.component";
103+
export { VeilFormModel } from "./model/veil.data";
104+
export * from "./api/update-veil.service";
105+
```
106+
107+
# NestJS Hexagonal Architecture: Public API & Boundary Enforcement
108+
109+
## Role & Context
110+
111+
You are a Senior NestJS Architect specialized in **Hexagonal Architecture**. Your goal is to maintain strict boundaries between the **Domain**, **Application**, and **Infrastructure** layers of the "Mavluda Beauty" backend.
112+
113+
## 1. The "Public API" Rule (Module Exports)
114+
115+
Every module (e.g., `auth`, `users`, `settings`) must have an `index.ts` at its root. This file acts as the **Module's Contract**.
116+
117+
- **What to Export**: DTOs, Interfaces, specific Service classes, and Constants.
118+
- **What to Hide**: Persistence models (Mongoose Schemas), internal helper services, and private logic.
119+
120+
## 2. Layer-Specific Export Rules
121+
122+
- **Domain Layer**: Export only Entities and Domain Service interfaces. Never export database-specific logic.
123+
- **Application Layer**: Export **DTOs** (Data Transfer Objects) and **Ports** (interfaces). This is what the Frontend or other modules will interact with.
124+
- **Infrastructure Layer**: Export only the final Repository implementations or Adapters.
125+
- **Interface Layer**: Controllers should NEVER be exported. They are the entry point, not a dependency.
126+
127+
## 3. Interaction & Import Rules
128+
129+
- **Strict Port/Adapter Pattern**: If Module A needs Module B, it must only import from `@modules/module-b` (the Public API).
130+
- **No Direct Schema Access**: Module A cannot import a Mongoose Schema from Module B. It must use Module B's Service or Repository.
131+
- **Path Aliases**: Always use `@domain`, `@application`, `@infrastructure`, and `@modules` aliases. Avoid `../../` relative paths.
132+
133+
## 4. Public API Structure Template
134+
135+
`index.ts` (or `public-api.ts`) should strictly contain named exports:
136+
137+
```typescript
138+
// Example for src/modules/admin-settings/index.ts
139+
140+
// Export Application Layer (DTOs for Frontend and other services)
141+
export { UpdateSettingsDto } from "./application/dto/update-settings.dto";
142+
export { AdminSettingsResponseDto } from "./application/dto/settings-response.dto";
143+
144+
// Export Application Service (The "Port")
145+
export { AdminSettingsService } from "./application/admin-settings.service";
146+
147+
// Export Domain Entities (if needed for type safety)
148+
export { AdminSettings } from "./domain/entities/admin-settings.entity";
149+
```

‎.github/instructions/agents.md‎

Lines changed: 88 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -59,3 +59,91 @@ You are the AI Implementation Agent for the "Mavluda Beauty" ecosystem. Your mis
5959

6060
- **Project Rebirth**: Prioritize development in the `rebirth` branch.
6161
- **Modules**: Focus on VIP Booking, Dress Inventory, and AI Consultant via n8n.
62+
63+
# FSD Architecture & Public API Enforcement
64+
65+
## Role & Context
66+
67+
You are a Senior Full-Stack Architect working on the "Mavluda Beauty" project. You must strictly adhere to the **Feature Sliced Design (FSD)** methodology. The primary mechanism for module encapsulation is the **Public API**.
68+
69+
## 1. The "Public API" Mandatory Rule
70+
71+
Every folder within the following layers MUST have an `index.ts` file acting as its Public API:
72+
73+
- `shared/` (lib, ui, api, etc.)
74+
- `entities/`
75+
- `features/`
76+
- `widgets/`
77+
- `pages/`
78+
79+
## 2. Import Rules (Strict Enforcement)
80+
81+
- **No Deep Imports**: Categorically forbidden to import directly from the internal folders of another module.
82+
- ❌ **BAD**: `import { VeilService } from '@entities/veil/api/veil.service';`
83+
- ✅ **GOOD**: `import { VeilService } from '@entities/veil';`
84+
- **Path Aliases**: Always use TypeScript path aliases (`@shared`, `@entities`, `@features`, etc.) instead of relative paths (`../../`) when crossing module boundaries.
85+
- **Cross-Layer Flow**: Only import from lower layers (e.g., a `feature` can import from `entities` or `shared`, but an `entity` CANNOT import from a `feature`).
86+
87+
## 3. Creation & Modification Workflow
88+
89+
Whenever you create a new component, service, utility, or type:
90+
91+
1. **Locate the nearest `index.ts`**: Find the Public API of the slice or segment.
92+
2. **Export the Entity**: Add a named export for the new entity in that `index.ts`.
93+
3. **Encapsulation**: If an entity is a "helper" used only inside its own folder, DO NOT export it. Keep the Public API clean.
94+
4. **Angular 21 Signal Forms**: When exporting components using Signal Forms, ensure the component is exported as a class, and any associated Signal-based types are also exported.
95+
96+
## 4. Public API Structure Template
97+
98+
`index.ts` files should strictly contain re-exports. Do not put logic inside `index.ts`.
99+
100+
```typescript
101+
// Example for @features/edit-veil/index.ts
102+
export { EditVeilComponent } from "./ui/veil.component";
103+
export { VeilFormModel } from "./model/veil.data";
104+
export * from "./api/update-veil.service";
105+
```
106+
107+
# NestJS Hexagonal Architecture: Public API & Boundary Enforcement
108+
109+
## Role & Context
110+
111+
You are a Senior NestJS Architect specialized in **Hexagonal Architecture**. Your goal is to maintain strict boundaries between the **Domain**, **Application**, and **Infrastructure** layers of the "Mavluda Beauty" backend.
112+
113+
## 1. The "Public API" Rule (Module Exports)
114+
115+
Every module (e.g., `auth`, `users`, `settings`) must have an `index.ts` at its root. This file acts as the **Module's Contract**.
116+
117+
- **What to Export**: DTOs, Interfaces, specific Service classes, and Constants.
118+
- **What to Hide**: Persistence models (Mongoose Schemas), internal helper services, and private logic.
119+
120+
## 2. Layer-Specific Export Rules
121+
122+
- **Domain Layer**: Export only Entities and Domain Service interfaces. Never export database-specific logic.
123+
- **Application Layer**: Export **DTOs** (Data Transfer Objects) and **Ports** (interfaces). This is what the Frontend or other modules will interact with.
124+
- **Infrastructure Layer**: Export only the final Repository implementations or Adapters.
125+
- **Interface Layer**: Controllers should NEVER be exported. They are the entry point, not a dependency.
126+
127+
## 3. Interaction & Import Rules
128+
129+
- **Strict Port/Adapter Pattern**: If Module A needs Module B, it must only import from `@modules/module-b` (the Public API).
130+
- **No Direct Schema Access**: Module A cannot import a Mongoose Schema from Module B. It must use Module B's Service or Repository.
131+
- **Path Aliases**: Always use `@domain`, `@application`, `@infrastructure`, and `@modules` aliases. Avoid `../../` relative paths.
132+
133+
## 4. Public API Structure Template
134+
135+
`index.ts` (or `public-api.ts`) should strictly contain named exports:
136+
137+
```typescript
138+
// Example for src/modules/admin-settings/index.ts
139+
140+
// Export Application Layer (DTOs for Frontend and other services)
141+
export { UpdateSettingsDto } from "./application/dto/update-settings.dto";
142+
export { AdminSettingsResponseDto } from "./application/dto/settings-response.dto";
143+
144+
// Export Application Service (The "Port")
145+
export { AdminSettingsService } from "./application/admin-settings.service";
146+
147+
// Export Domain Entities (if needed for type safety)
148+
export { AdminSettings } from "./domain/entities/admin-settings.entity";
149+
```

‎.github/instructions/frontend.md‎

Lines changed: 14 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -149,3 +149,17 @@ export class GoodComponent {
149149
- Используйте PascalCase для классов и компонентов
150150
- Используйте kebab-case для селекторов компонентов
151151
- Предпочитайте template syntax над inline templates для сложных компонентов
152+
153+
### 🏛️ Why this works for your project
154+
155+
1. **Encapsulation**: This prevents your **Angular 21** components from becoming tightly coupled. If you change how a `signalFormGroup` is built inside a feature, the rest of the app won't break as long as the Public API remains the same.
156+
2. **Refactoring Safety**: When you move a file, you only need to update the `index.ts` in that folder. You don't have to search and replace imports across 50 different files.
157+
3. **Zoneless Performance**: By keeping dependencies clean, the Angular compiler can better optimize the **Zoneless** tree-shaking, making the "Mavluda Beauty" site load even faster.
158+
159+
---
160+
161+
### 🚀 Next Step for you
162+
163+
Now that you have this rule, try asking Antigravity to create a new "Gallery" feature. You will see it automatically create the folder, the component, the data file, and the `index.ts` to tie it all together.
164+
165+
**Would you like me to create a similar strict rule for the NestJS Backend to enforce Hexagonal Architecture boundaries?**

‎.github/instructions/typescript.md‎

Lines changed: 43 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,43 @@
1+
# FSD Architecture & Public API Enforcement
2+
3+
## Role & Context
4+
5+
You are a Senior Full-Stack Architect working on the "Mavluda Beauty" project. You must strictly adhere to the **Feature Sliced Design (FSD)** methodology. The primary mechanism for module encapsulation is the **Public API**.
6+
7+
## 1. The "Public API" Mandatory Rule
8+
9+
Every folder within the following layers MUST have an `index.ts` file acting as its Public API:
10+
11+
- `shared/` (lib, ui, api, etc.)
12+
- `entities/`
13+
- `features/`
14+
- `widgets/`
15+
- `pages/`
16+
17+
## 2. Import Rules (Strict Enforcement)
18+
19+
- **No Deep Imports**: Categorically forbidden to import directly from the internal folders of another module.
20+
- ❌ **BAD**: `import { VeilService } from '@entities/veil/api/veil.service';`
21+
- ✅ **GOOD**: `import { VeilService } from '@entities/veil';`
22+
- **Path Aliases**: Always use TypeScript path aliases (`@shared`, `@entities`, `@features`, etc.) instead of relative paths (`../../`) when crossing module boundaries.
23+
- **Cross-Layer Flow**: Only import from lower layers (e.g., a `feature` can import from `entities` or `shared`, but an `entity` CANNOT import from a `feature`).
24+
25+
## 3. Creation & Modification Workflow
26+
27+
Whenever you create a new component, service, utility, or type:
28+
29+
1. **Locate the nearest `index.ts`**: Find the Public API of the slice or segment.
30+
2. **Export the Entity**: Add a named export for the new entity in that `index.ts`.
31+
3. **Encapsulation**: If an entity is a "helper" used only inside its own folder, DO NOT export it. Keep the Public API clean.
32+
4. **Angular 21 Signal Forms**: When exporting components using Signal Forms, ensure the component is exported as a class, and any associated Signal-based types are also exported.
33+
34+
## 4. Public API Structure Template
35+
36+
`index.ts` files should strictly contain re-exports. Do not put logic inside `index.ts`.
37+
38+
```typescript
39+
// Example for @features/edit-veil/index.ts
40+
export { EditVeilComponent } from "./ui/veil.component";
41+
export { VeilFormModel } from "./model/veil.data";
42+
export * from "./api/update-veil.service";
43+
```

0 commit comments

Comments
 (0)