@futdevpro/fsm-dynamo 1.16.38 → 1.16.40

package/.cursor/rules/_ag_file-refactoring.mdc

@@ -1,113 +1,113 @@
----
-description: when refactoring large files or extracting code sections from files
-alwaysApply: false
----
-# File Refactoring és Code Extraction Guidelines
-
-## Extract File Content Parancs Használata
-
-Amikor nagy fájlokat refaktorálunk vagy kód részeket extraktolunk fájlból, **MINDIG** használjuk a Dynamo CLI `extract-file-content` parancsát.
-
-### Parancs Használata
-
-```bash
-dc efc <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
-```
-
-Vagy a hosszabb alias-szal:
-```bash
-dc extract-file-content <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
-```
-
-### Paraméterek
-
-- `<source-file>` - A forrás fájl elérési útja (relatív vagy abszolút)
-- `--start <start-line>` - A kezdő sor száma (1-based, beleértve ezt a sort)
-- `--end <end-line>` - A vég sor száma (1-based, beleértve ezt a sort)
-- `--output <output-name>` - A kimeneti fájl neve (kiterjesztés nélkül vagy kiterjesztéssel)
-- `--target-dir <target-directory>` - Opcionális: célkönyvtár (alapértelmezett: ugyanaz, mint a forrás fájl könyvtára)
-
-### Automatikus Funkciók
-
-A parancs automatikusan:
-- **Detektálja és hozzáadja a szükséges importokat** a kiemelt kód alapján
-- **Hozzáadja a copyright header-t** (TypeScript fájlok esetén)
-- **Törli a kiemelt sorokat** az eredeti fájlból
-- **Konvertálja a fájlnevet kebab-case-re**
-- **MD fájlok esetén** nem ad hozzá copyright headert és importokat
-
-### Használati Esetek
-
-#### 1. Nagy Fájlok Refaktorálása
-
-Ha egy fájl **500+ sor** hosszú, és logikailag szétbontható:
-1. Azonosítsd a különálló funkcionalitást vagy modult
-2. Használd az `efc` parancsot a kód kiemelésére új fájlba
-3. Az eredeti fájlból automatikusan törlődnek a kiemelt sorok
-
-**Példa:**
-```bash
-# Kiemeljük a user validation logikát egy külön fájlba
-dc efc src/services/user.service.ts --start 150 --end 300 --output user-validation
-# Ez létrehozza: src/services/user-validation.ts
-```
-
-#### 2. Modulok Kiemelése
-
-Amikor egy nagy fájlból külön modult vagy service-t szeretnénk kiemelni:
-1. Határozd meg a modul kezdő és vég sorait
-2. Add meg a kimeneti fájl nevét
-3. Opcionálisan add meg a célkönyvtárat
-
-**Példa:**
-```bash
-# Kiemeljük a notification service-t egy külön fájlba
-dc efc src/services/communication.service.ts --start 50 --end 200 --output notification-service --target-dir src/services/notifications
-```
-
-#### 3. TypeScript Interface-ek és Type-ok Kiemelése
-
-Amikor type definíciókat szeretnénk külön fájlba kiemelni:
-```bash
-dc efc src/models/user.model.ts --start 1 --end 50 --output user-types --target-dir src/models/types
-```
-
-### Fontos Megjegyzések
-
-- **MINDIG** használd ezt a parancsot nagy fájlok refaktorálásakor
-- A parancs **automatikusan törli** a kiemelt sorokat az eredeti fájlból
-- Az importok **automatikusan detektálódnak** és hozzáadódnak az új fájlhoz
-- MD fájlok esetén csak a tartalom kerül kiemelésre (nincs header, nincs import)
-- A fájlnevek **automatikusan kebab-case-re** konvertálódnak
-- **PowerShell környezet**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort
-
-### Workflow
-
-1. Azonosítsd a kiemelendő kód részt (kezdő és vég sor)
-   - **FONTOS**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
-2. Futtasd az `efc` parancsot a megfelelő paraméterekkel
-3. Ellenőrizd az új fájlt, hogy minden szükséges import benne van-e
-4. Ellenőrizd az eredeti fájlt, hogy a kiemelt sorok törölve lettek-e
-5. Szükség esetén manuálisan finomhangold az importokat
-
-### Törlés Parancs (Ha Csak Törölni Akarunk)
-
-Ha csak sorokat szeretnénk törölni (nem kiemelni), használd a `delete-file-lines` parancsot:
-
-```bash
-dc dfl <source-file> --start <start-line> --end <end-line>
-```
-
-Vagy:
-```bash
-dc delete-file-lines <source-file> --start <start-line> --end <end-line>
-```
-
-### Best Practices
-
-- **Sor számok meghatározása**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
-- **PowerShell parancs elválasztás**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort (pl. `cd .. ; pnpm test` helyes, `cd .. && pnpm test` helytelen)
-- **Előzetes ellenőrzés**: Mielőtt futtatnád a parancsot, ellenőrizd, hogy a sorok tartalma valóban kiemelhető-e
-- **Git commit**: Mielőtt refaktorálást kezdesz, commit-old a változtatásokat
-- **Tesztelés**: A refaktorálás után mindig teszteld, hogy a funkcionalitás változatlan maradt-e
-- **Dokumentáció**: Nagyobb refaktorálások után frissítsd a dokumentációt
+---
+description: when refactoring large files or extracting code sections from files
+alwaysApply: false
+---
+# File Refactoring és Code Extraction Guidelines
+
+## Extract File Content Parancs Használata
+
+Amikor nagy fájlokat refaktorálunk vagy kód részeket extraktolunk fájlból, **MINDIG** használjuk a Dynamo CLI `extract-file-content` parancsát.
+
+### Parancs Használata
+
+```bash
+dc efc <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
+```
+
+Vagy a hosszabb alias-szal:
+```bash
+dc extract-file-content <source-file> --start <start-line> --end <end-line> --output <output-name> [--target-dir <target-directory>]
+```
+
+### Paraméterek
+
+- `<source-file>` - A forrás fájl elérési útja (relatív vagy abszolút)
+- `--start <start-line>` - A kezdő sor száma (1-based, beleértve ezt a sort)
+- `--end <end-line>` - A vég sor száma (1-based, beleértve ezt a sort)
+- `--output <output-name>` - A kimeneti fájl neve (kiterjesztés nélkül vagy kiterjesztéssel)
+- `--target-dir <target-directory>` - Opcionális: célkönyvtár (alapértelmezett: ugyanaz, mint a forrás fájl könyvtára)
+
+### Automatikus Funkciók
+
+A parancs automatikusan:
+- **Detektálja és hozzáadja a szükséges importokat** a kiemelt kód alapján
+- **Hozzáadja a copyright header-t** (TypeScript fájlok esetén)
+- **Törli a kiemelt sorokat** az eredeti fájlból
+- **Konvertálja a fájlnevet kebab-case-re**
+- **MD fájlok esetén** nem ad hozzá copyright headert és importokat
+
+### Használati Esetek
+
+#### 1. Nagy Fájlok Refaktorálása
+
+Ha egy fájl **500+ sor** hosszú, és logikailag szétbontható:
+1. Azonosítsd a különálló funkcionalitást vagy modult
+2. Használd az `efc` parancsot a kód kiemelésére új fájlba
+3. Az eredeti fájlból automatikusan törlődnek a kiemelt sorok
+
+**Példa:**
+```bash
+# Kiemeljük a user validation logikát egy külön fájlba
+dc efc src/services/user.service.ts --start 150 --end 300 --output user-validation
+# Ez létrehozza: src/services/user-validation.ts
+```
+
+#### 2. Modulok Kiemelése
+
+Amikor egy nagy fájlból külön modult vagy service-t szeretnénk kiemelni:
+1. Határozd meg a modul kezdő és vég sorait
+2. Add meg a kimeneti fájl nevét
+3. Opcionálisan add meg a célkönyvtárat
+
+**Példa:**
+```bash
+# Kiemeljük a notification service-t egy külön fájlba
+dc efc src/services/communication.service.ts --start 50 --end 200 --output notification-service --target-dir src/services/notifications
+```
+
+#### 3. TypeScript Interface-ek és Type-ok Kiemelése
+
+Amikor type definíciókat szeretnénk külön fájlba kiemelni:
+```bash
+dc efc src/models/user.model.ts --start 1 --end 50 --output user-types --target-dir src/models/types
+```
+
+### Fontos Megjegyzések
+
+- **MINDIG** használd ezt a parancsot nagy fájlok refaktorálásakor
+- A parancs **automatikusan törli** a kiemelt sorokat az eredeti fájlból
+- Az importok **automatikusan detektálódnak** és hozzáadódnak az új fájlhoz
+- MD fájlok esetén csak a tartalom kerül kiemelésre (nincs header, nincs import)
+- A fájlnevek **automatikusan kebab-case-re** konvertálódnak
+- **PowerShell környezet**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort
+
+### Workflow
+
+1. Azonosítsd a kiemelendő kód részt (kezdő és vég sor)
+   - **FONTOS**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
+2. Futtasd az `efc` parancsot a megfelelő paraméterekkel
+3. Ellenőrizd az új fájlt, hogy minden szükséges import benne van-e
+4. Ellenőrizd az eredeti fájlt, hogy a kiemelt sorok törölve lettek-e
+5. Szükség esetén manuálisan finomhangold az importokat
+
+### Törlés Parancs (Ha Csak Törölni Akarunk)
+
+Ha csak sorokat szeretnénk törölni (nem kiemelni), használd a `delete-file-lines` parancsot:
+
+```bash
+dc dfl <source-file> --start <start-line> --end <end-line>
+```
+
+Vagy:
+```bash
+dc delete-file-lines <source-file> --start <start-line> --end <end-line>
+```
+
+### Best Practices
+
+- **Sor számok meghatározása**: Ahhoz, hogy az előre meghatározott sor számok jók legyenek, **hátulról előre kell haladni** - tehát csak a magas számokkal kezdjünk, legmagasabbal, és attól megyünk lefelé
+- **PowerShell parancs elválasztás**: Mivel PowerShell-ben dolgozunk, a mappa választás és parancs elválasztására **pontosvesszőt (;)** kell használni, nem az és-és (&&) operátort (pl. `cd .. ; pnpm test` helyes, `cd .. && pnpm test` helytelen)
+- **Előzetes ellenőrzés**: Mielőtt futtatnád a parancsot, ellenőrizd, hogy a sorok tartalma valóban kiemelhető-e
+- **Git commit**: Mielőtt refaktorálást kezdesz, commit-old a változtatásokat
+- **Tesztelés**: A refaktorálás után mindig teszteld, hogy a funkcionalitás változatlan maradt-e
+- **Dokumentáció**: Nagyobb refaktorálások után frissítsd a dokumentációt

package/.cursor/rules/_ag_fixes_rules.mdc

@@ -1,6 +1,6 @@
----
-description:  apply when we are facing errors, issues or bugs.
-alwaysApply: false
----
-
+---
+description:  apply when we are facing errors, issues or bugs.
+alwaysApply: false
+---
+
 When we are trying to solve an issue, an error or a bug, we always need to check the related specifications first about what is the required best case.

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