@futdevpro/fsm-dynamo 1.15.17 → 1.15.20

package/.cursor/rules/__assistant_guide.mdc

@@ -1,30 +1,30 @@
----
-description: Apply if planning or reviewing operations
-alwaysApply: false
----
-# Global planning and execution policy
-- mindig amikor a user olyat vagy olyasmit, mond, hogy "ennek úgy kéne működnie, hogy ..." annak bele kell kerülni a specifikációba
-- minden nagyobb fejlesztés végén dokumentációt kell készíteni 
-
-## fejlesztési folyamat; 
-Az alábbi folyamatot a user szoros közreműködésével fogjuk végezni
-- valamilyen hibából vagy feature request-ből indulunk ki
-- átnézzük az összes kapcsolódó elemet
-- mindig kérjük, hogy 
-  - "review the issue very carefully"
-  - "be very very careful" 
-  - "plan comprehensive" 
-  - "always check exisitng solutions" 
-  - "always follow existing patterns very strictly"
-- tervezünk egy megoldást
-- implementáljuk a megoldást
-- leteszteltetjük a felhasználóval, úgy hogy futtassa az alkalmazást és a lehető legtöbb féle képpen triggereljük a subjct feature-t
-- ellenőriztetjük az érintett más funkcionalitásokat
-- ha van hiba akkor megpróbáljuk megoldani
-- a hibajavítások során figyelünk arra, hogy ha ugyan az a hiba újra előjön többször egymás után miközben javításokat végzünk, akkor az valamilyen nagyobb szintű hibára utal ami átfogóbb review-t és solution planning-et igényel. (ehhez hasonló párhuzamos session)
-- ha minden javítás kész, újból átfogó tesztet végeztetünk, majd ha ezen is átment, akkor push-oltatjuk a megoldást a user-el. figyelve az automata GIT build-ek eredményére (hátha újabb error jelentkezik, ezt a user fogja tudni visszajelezni) 
-- dokumentációt készítünk a session-ről, amiben legyen benne a user kérése is (a legközelebbi "__documentations" folder-be)
-- menet közben ahogy a user-el egyeztetünk, kieshetnek újabb feature request-ek és specifikációs kérések amiket fontos hogy feljegyezzünk!
-- Amikor fázisonkénti fejlesztéseket hajtunk végre, mindig készítsünk dokumentációt az eredményekről, és update-eljük a soron következő-, már megtervezett fázisokat, amennyiben szükséges. (de csak miután a user elfogadta és véglegesítette a megoldást.)
-
-
+---
+description: Apply if planning or reviewing operations
+alwaysApply: false
+---
+# Global planning and execution policy
+- mindig amikor a user olyat vagy olyasmit, mond, hogy "ennek úgy kéne működnie, hogy ..." annak bele kell kerülni a specifikációba
+- minden nagyobb fejlesztés végén dokumentációt kell készíteni 
+
+## fejlesztési folyamat; 
+Az alábbi folyamatot a user szoros közreműködésével fogjuk végezni
+- valamilyen hibából vagy feature request-ből indulunk ki
+- átnézzük az összes kapcsolódó elemet
+- mindig kérjük, hogy 
+  - "review the issue very carefully"
+  - "be very very careful" 
+  - "plan comprehensive" 
+  - "always check exisitng solutions" 
+  - "always follow existing patterns very strictly"
+- tervezünk egy megoldást
+- implementáljuk a megoldást
+- leteszteltetjük a felhasználóval, úgy hogy futtassa az alkalmazást és a lehető legtöbb féle képpen triggereljük a subjct feature-t
+- ellenőriztetjük az érintett más funkcionalitásokat
+- ha van hiba akkor megpróbáljuk megoldani
+- a hibajavítások során figyelünk arra, hogy ha ugyan az a hiba újra előjön többször egymás után miközben javításokat végzünk, akkor az valamilyen nagyobb szintű hibára utal ami átfogóbb review-t és solution planning-et igényel. (ehhez hasonló párhuzamos session)
+- ha minden javítás kész, újból átfogó tesztet végeztetünk, majd ha ezen is átment, akkor push-oltatjuk a megoldást a user-el. figyelve az automata GIT build-ek eredményére (hátha újabb error jelentkezik, ezt a user fogja tudni visszajelezni) 
+- dokumentációt készítünk a session-ről, amiben legyen benne a user kérése is (a legközelebbi "__documentations" folder-be)
+- menet közben ahogy a user-el egyeztetünk, kieshetnek újabb feature request-ek és specifikációs kérések amiket fontos hogy feljegyezzünk!
+- Amikor fázisonkénti fejlesztéseket hajtunk végre, mindig készítsünk dokumentációt az eredményekről, és update-eljük a soron következő-, már megtervezett fázisokat, amennyiben szükséges. (de csak miután a user elfogadta és véglegesítette a megoldást.)
+
+

package/.cursor/rules/_ag_backend-structure.mdc

@@ -1,86 +1,86 @@
----
-description:  when creating backend structure, backend module or backend folders.
-alwaysApply: false
----
-# Backend Project Structure [FDP-BE]
-
-## Overview
-This document outlines the standard project structure for FDP backend applications.
-
-## Directory Structure
-
-```
-📁 app/
-├── 📁 _assets/
-├── 📁 _collections/
-│   ├── 📁 email(*)/
-│   ├── 📁 consts(*)/
-│   ├── 📁 mocks(*)/
-│   └── 📁 utils(*)/
-├── 📁 _enums/
-├── 📁 _models/
-│   ├── 📁 control-models(*)/
-│   ├── 📁 data-models(*)/
-│   └── 📁 interfaces(*)/
-├── 📁 _modules/
-│   ├── 📁 moduleName/
-│   │   ├── 📁 _collections/
-│   │   ├── 📁 _enums/
-│   │   ├── 📁 _models/
-│   │   └── 📁 _services/
-│   └── 📁 anotherModule/
-│       ├── 📁 _collections/
-│       ├── 📁 _enums/
-│       ├── 📁 _models/
-│       └── 📁 _services/
-└── 📁 _routes(**)
-    ├── 📁 user/
-    │   ├── 📁 user/
-    │   │   ├── user.controller.ts
-    │   │   └── user.data-service.ts
-    │   ├── 📁 userData/
-    │   │   ├── user-data.controller.ts
-    │   │   └── user-data.data-service.ts
-    │   └── 📁 userCarts/
-    │       ├── user-carts.controller.ts
-    │       └── user-carts.data-service.ts
-    ├── 📁 products/
-    └── 📁 server/
-        ├── 📁 server-status/
-        ├── 📁 error/
-        ├── 📁 _socket-services/
-        └── 📁 core-services/
-            ├── 📁 api-services/
-            └── 📁 email-services/
-```
-
-## Directory Guidelines
-
-### Folder Creation Rules (*)
-- Create subfolders only when containing 3-5+ elements
-- For 3+ elements: Consider if it will grow to 5+
-- If likely to reach 5+: Create subfolder immediately
-- Otherwise: Keep files in the parent type folder
-
-### Route Structure (**)
-- `_routes` structure must match API paths
-- Each route folder contains related controllers and services
-
-### Module Structure (***)
-- `_modules` contains reusable, self-contained modules
-- Each module folder must contain the standard structure:
-  - `_collections/` - module-specific collections
-  - `_enums/` - module-specific enums
-  - `_models/` - module-specific models (control-models, data-models, interfaces)
-  - `_services/` - module-specific services
-- Module folders follow the same naming conventions as routes
-- Modules are organized in a flat structure within `_modules`
-
-### Naming Convention
-- Prefix type-folders with "_" for better visual hierarchy
-- Only create type-folders when they contain content
-- All modules must be in the main modules folder
-- No nested module folders within modules
-
-## Module Organization
+---
+description:  when creating backend structure, backend module or backend folders.
+alwaysApply: false
+---
+# Backend Project Structure [FDP-BE]
+
+## Overview
+This document outlines the standard project structure for FDP backend applications.
+
+## Directory Structure
+
+```
+📁 app/
+├── 📁 _assets/
+├── 📁 _collections/
+│   ├── 📁 email(*)/
+│   ├── 📁 consts(*)/
+│   ├── 📁 mocks(*)/
+│   └── 📁 utils(*)/
+├── 📁 _enums/
+├── 📁 _models/
+│   ├── 📁 control-models(*)/
+│   ├── 📁 data-models(*)/
+│   └── 📁 interfaces(*)/
+├── 📁 _modules/
+│   ├── 📁 moduleName/
+│   │   ├── 📁 _collections/
+│   │   ├── 📁 _enums/
+│   │   ├── 📁 _models/
+│   │   └── 📁 _services/
+│   └── 📁 anotherModule/
+│       ├── 📁 _collections/
+│       ├── 📁 _enums/
+│       ├── 📁 _models/
+│       └── 📁 _services/
+└── 📁 _routes(**)
+    ├── 📁 user/
+    │   ├── 📁 user/
+    │   │   ├── user.controller.ts
+    │   │   └── user.data-service.ts
+    │   ├── 📁 userData/
+    │   │   ├── user-data.controller.ts
+    │   │   └── user-data.data-service.ts
+    │   └── 📁 userCarts/
+    │       ├── user-carts.controller.ts
+    │       └── user-carts.data-service.ts
+    ├── 📁 products/
+    └── 📁 server/
+        ├── 📁 server-status/
+        ├── 📁 error/
+        ├── 📁 _socket-services/
+        └── 📁 core-services/
+            ├── 📁 api-services/
+            └── 📁 email-services/
+```
+
+## Directory Guidelines
+
+### Folder Creation Rules (*)
+- Create subfolders only when containing 3-5+ elements
+- For 3+ elements: Consider if it will grow to 5+
+- If likely to reach 5+: Create subfolder immediately
+- Otherwise: Keep files in the parent type folder
+
+### Route Structure (**)
+- `_routes` structure must match API paths
+- Each route folder contains related controllers and services
+
+### Module Structure (***)
+- `_modules` contains reusable, self-contained modules
+- Each module folder must contain the standard structure:
+  - `_collections/` - module-specific collections
+  - `_enums/` - module-specific enums
+  - `_models/` - module-specific models (control-models, data-models, interfaces)
+  - `_services/` - module-specific services
+- Module folders follow the same naming conventions as routes
+- Modules are organized in a flat structure within `_modules`
+
+### Naming Convention
+- Prefix type-folders with "_" for better visual hierarchy
+- Only create type-folders when they contain content
+- All modules must be in the main modules folder
+- No nested module folders within modules
+
+## Module Organization
 Modules should be organized in a flat structure within the main modules folder. Each module follows the same internal structure with `_collections`, `_enums`, `_models`, and `_services` folders. 

package/.cursor/rules/_ag_backend.mdc

@@ -1,16 +1,16 @@
----
-description:  when creating backend development
-alwaysApply: false
----
-# Backend Development Guidelines
-
-## Project Structure
-- Follow the structure defined in [Backend Project Structure](backend-structure.md)
-
-## Error Handling
-- Use try-catch blocks for ALL operations
-- Implement proper error logging
-- Use standardized error codes (see [Error Code Pattern](error_code_pattern.md))
-- Handle all edge cases
-- Validate all inputs
-
+---
+description:  when creating backend development
+alwaysApply: false
+---
+# Backend Development Guidelines
+
+## Project Structure
+- Follow the structure defined in [Backend Project Structure](backend-structure.md)
+
+## Error Handling
+- Use try-catch blocks for ALL operations
+- Implement proper error logging
+- Use standardized error codes (see [Error Code Pattern](error_code_pattern.md))
+- Handle all edge cases
+- Validate all inputs
+

package/.cursor/rules/_ag_frontend-structure.mdc

@@ -1,87 +1,87 @@
----
-description: when creating frontend- structure, module,  or new folders.
-alwaysApply: false
----
-# Frontend Project Structure [FDP-FE]
-
-## Overview
-This document outlines the standard project structure for FDP frontend applications.
-
-## Directory Structure
-
-```
-📁 app/
-├── 📁 _collections/
-│   ├── 📁 consts(*)/
-│   ├── 📁 mocks(*)/
-│   └── 📁 utils(*)/
-├── 📁 _components/
-│   ├── 📁 <core-component-1>/
-│   ├── 📁 <core-component-2>/
-│   └── 📁 <core-component-group-1(*)>/
-├── 📁 _directives/
-├── 📁 _enums/
-├── 📁 _models/
-│   ├── 📁 control-models(*)/
-│   ├── 📁 data-models(*)/
-│   └── 📁 interfaces(*)/
-├── 📁 _modules/
-│   ├── 📁 shared/
-│   │   ├── 📁 _collections/
-│   │   ├── 📁 _components/
-│   │   │   ├── 📁 s-<shared-component-1(**)>/
-│   │   │   └── 📁 s-<shared-component-2(**)>/
-│   │   ├── 📁 _directives/
-│   │   ├── 📁 _enums/
-│   │   ├── 📁 _models/
-│   │   ├── 📁 _pipes/
-│   │   └── 📁 _services/
-│   ├── 📁 shared-standalones/
-│   ├── 📁 <module-sample>/
-│   │   ├── 📁 _collections/
-│   │   ├── 📁 _components/
-│   │   │   ├── 📁 ms-<component-1(**)>/
-│   │   │   └── 📁 ms-<component-2(**)>/
-│   └── 📁 <other-module>/
-├── 📁 _pipes/
-│   ├── 📁 <pipe-1>/
-│   └── 📁 <pipe-2>/
-└── 📁 _services/
-    ├── 📁 api-services(*)/
-    ├── 📁 control-services(*)/
-    └── 📁 data-services(*)/
-```
-
-## Directory Guidelines
-
-### Folder Creation Rules (*)
-- Create subfolders only when containing 3-5+ elements
-- For 3+ elements: Consider if it will grow to 5+
-- If likely to reach 5+: Create subfolder immediately
-- Otherwise: Keep files in the parent type folder
-
-### Component Naming (**)
-- Prefix components with module identifier (2-3 letters)
-  - Shared components: 's-'
-  - Module-specific: 'ms-', 'om-', 'ad-', 'dod-', etc.
-- Helps with:
-  - Easy navigation
-  - Module identification
-  - Preventing naming conflicts
-
-### Type Folder Convention
-- Prefix type-folders with "_" (e.g., _components, _services)
-- Only create when containing content
-- Helps identify project layer visually
-
-### Module Organization
-- All modules must be in the main _modules folder
-- No nested module folders within modules
-- Standard module structure includes:
-  - _collections
-  - _components
-  - _directives
-  - _enums
-  - _models
-  - _pipes
+---
+description: when creating frontend- structure, module,  or new folders.
+alwaysApply: false
+---
+# Frontend Project Structure [FDP-FE]
+
+## Overview
+This document outlines the standard project structure for FDP frontend applications.
+
+## Directory Structure
+
+```
+📁 app/
+├── 📁 _collections/
+│   ├── 📁 consts(*)/
+│   ├── 📁 mocks(*)/
+│   └── 📁 utils(*)/
+├── 📁 _components/
+│   ├── 📁 <core-component-1>/
+│   ├── 📁 <core-component-2>/
+│   └── 📁 <core-component-group-1(*)>/
+├── 📁 _directives/
+├── 📁 _enums/
+├── 📁 _models/
+│   ├── 📁 control-models(*)/
+│   ├── 📁 data-models(*)/
+│   └── 📁 interfaces(*)/
+├── 📁 _modules/
+│   ├── 📁 shared/
+│   │   ├── 📁 _collections/
+│   │   ├── 📁 _components/
+│   │   │   ├── 📁 s-<shared-component-1(**)>/
+│   │   │   └── 📁 s-<shared-component-2(**)>/
+│   │   ├── 📁 _directives/
+│   │   ├── 📁 _enums/
+│   │   ├── 📁 _models/
+│   │   ├── 📁 _pipes/
+│   │   └── 📁 _services/
+│   ├── 📁 shared-standalones/
+│   ├── 📁 <module-sample>/
+│   │   ├── 📁 _collections/
+│   │   ├── 📁 _components/
+│   │   │   ├── 📁 ms-<component-1(**)>/
+│   │   │   └── 📁 ms-<component-2(**)>/
+│   └── 📁 <other-module>/
+├── 📁 _pipes/
+│   ├── 📁 <pipe-1>/
+│   └── 📁 <pipe-2>/
+└── 📁 _services/
+    ├── 📁 api-services(*)/
+    ├── 📁 control-services(*)/
+    └── 📁 data-services(*)/
+```
+
+## Directory Guidelines
+
+### Folder Creation Rules (*)
+- Create subfolders only when containing 3-5+ elements
+- For 3+ elements: Consider if it will grow to 5+
+- If likely to reach 5+: Create subfolder immediately
+- Otherwise: Keep files in the parent type folder
+
+### Component Naming (**)
+- Prefix components with module identifier (2-3 letters)
+  - Shared components: 's-'
+  - Module-specific: 'ms-', 'om-', 'ad-', 'dod-', etc.
+- Helps with:
+  - Easy navigation
+  - Module identification
+  - Preventing naming conflicts
+
+### Type Folder Convention
+- Prefix type-folders with "_" (e.g., _components, _services)
+- Only create when containing content
+- Helps identify project layer visually
+
+### Module Organization
+- All modules must be in the main _modules folder
+- No nested module folders within modules
+- Standard module structure includes:
+  - _collections
+  - _components
+  - _directives
+  - _enums
+  - _models
+  - _pipes
   - _services 

package/.cursor/rules/_ag_frontend.mdc

@@ -1,40 +1,40 @@
----
-description: when creating front-end implementations
-alwaysApply: false
----
-# FDP FronEnd development Guide
-
-## Tech Stack
-- Use Angular latest version
-- Use Tailwind for SCSS Styles
-- Use the following tech stack: use Angular, Typescript, tailwind, DyNX_, DyFM_, DyNM_, FDP_, FDPNX_
-
-## Angular
-
-## Project Structure
-- Follow the structure defined in [Frontend Project Structure](frontend-structure.md)
-
-### Components
-- After 4+ rows, always create separate HTML file
-
-### Typescript
-- Use Signals
-  - For Signal properties use "_$" postfix
-- For Subjects use "_S" postfix
-- For BehaviourSubjects use "_BS" postfix
-- For Observables use "$" postfix
-- Use async methods
-- ng methods as ngOnInit should never be a promise since they won't wait for async functions
-- Don't implement ngOnInit if not needed/used.
-- for any buttons we should use dynamo new button
-- For data handlings, use data handlers and data services across multiple components whenever we need to handle data.
-
-### HTML
-- NEVER EVER use methods in HTML templates for getting data
-- Put empty lines between HTML elements in the same level
-- Use "@if" syntax in HTML instead of "*ngIf" for Angular
-- Use Tailwind classes and only create SCSS if needed, e.g. for animated elements
-- In HTML templates you should never ever use functions to display data or evaluate HTML tag rendering methods only allowed for event triggers! Use signal computed values or pipes for evaluations and pipings.
-
-## Naming
+---
+description: when creating front-end implementations
+alwaysApply: false
+---
+# FDP FronEnd development Guide
+
+## Tech Stack
+- Use Angular latest version
+- Use Tailwind for SCSS Styles
+- Use the following tech stack: use Angular, Typescript, tailwind, DyNX_, DyFM_, DyNM_, FDP_, FDPNX_
+
+## Angular
+
+## Project Structure
+- Follow the structure defined in [Frontend Project Structure](frontend-structure.md)
+
+### Components
+- After 4+ rows, always create separate HTML file
+
+### Typescript
+- Use Signals
+  - For Signal properties use "_$" postfix
+- For Subjects use "_S" postfix
+- For BehaviourSubjects use "_BS" postfix
+- For Observables use "$" postfix
+- Use async methods
+- ng methods as ngOnInit should never be a promise since they won't wait for async functions
+- Don't implement ngOnInit if not needed/used.
+- for any buttons we should use dynamo new button
+- For data handlings, use data handlers and data services across multiple components whenever we need to handle data.
+
+### HTML
+- NEVER EVER use methods in HTML templates for getting data
+- Put empty lines between HTML elements in the same level
+- Use "@if" syntax in HTML instead of "*ngIf" for Angular
+- Use Tailwind classes and only create SCSS if needed, e.g. for animated elements
+- In HTML templates you should never ever use functions to display data or evaluate HTML tag rendering methods only allowed for event triggers! Use signal computed values or pipes for evaluations and pipings.
+
+## Naming
 - Read and follow [Naming](_ag_naming.mdc) conventions

package/.cursor/rules/_ag_import-rules.mdc

@@ -1,45 +1,45 @@
----
-description:  import formatting rules
-alwaysApply: false
----
-# Import Rules and Format [FDP-Dev-import]
-
-## Overview
-This document outlines the standard import rules and formatting for FDP projects.
-
-## Import Order
-1. Angular Core imports (@angular/*)
-2. External imports (packages)
-3. FDP imports (@futdevpro/*)
-4. Shared imports (from shared modules)
-5. Internal imports (local)
-
-## Format Example
-```typescript
-import { Component, OnInit } from '@angular/core';
-import { Observable } from 'rxjs';
-import { MatDialog } from '@angular/material/dialog';
-
-import { DyFM_Log } from '@futdevpro/fsm-dynamo';
-import { FDP_User } from '@futdevpro/fdp-templates';
-
-import { SharedModule } from '../../_modules/shared/shared.module';
-
-import { FirstModule } from '../first/first.module';
-import { SecondModule } from './second.module';
-```
-
-## Rules
-1. Use spaces between import groups
-2. Use relative imports within the application
-3. Group imports by their source/type
-4. Order internal imports by relative path distance (bottom-up)
-5. Keep imports clean and organized
-6. Remove unused imports
-
-## Best Practices
-- Use explicit imports rather than wildcards
-- Keep imports alphabetically sorted within their groups
-- Use relative paths for internal imports
-- Use absolute paths for package imports
+---
+description:  import formatting rules
+alwaysApply: false
+---
+# Import Rules and Format [FDP-Dev-import]
+
+## Overview
+This document outlines the standard import rules and formatting for FDP projects.
+
+## Import Order
+1. Angular Core imports (@angular/*)
+2. External imports (packages)
+3. FDP imports (@futdevpro/*)
+4. Shared imports (from shared modules)
+5. Internal imports (local)
+
+## Format Example
+```typescript
+import { Component, OnInit } from '@angular/core';
+import { Observable } from 'rxjs';
+import { MatDialog } from '@angular/material/dialog';
+
+import { DyFM_Log } from '@futdevpro/fsm-dynamo';
+import { FDP_User } from '@futdevpro/fdp-templates';
+
+import { SharedModule } from '../../_modules/shared/shared.module';
+
+import { FirstModule } from '../first/first.module';
+import { SecondModule } from './second.module';
+```
+
+## Rules
+1. Use spaces between import groups
+2. Use relative imports within the application
+3. Group imports by their source/type
+4. Order internal imports by relative path distance (bottom-up)
+5. Keep imports clean and organized
+6. Remove unused imports
+
+## Best Practices
+- Use explicit imports rather than wildcards
+- Keep imports alphabetically sorted within their groups
+- Use relative paths for internal imports
+- Use absolute paths for package imports
 - Remove any duplicate imports