@futdevpro/nts-dynamo 1.15.126 → 1.15.127

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 

package/.cursor/rules/_ag_naming.mdc

@@ -1,116 +1,116 @@
----
-description:  when naming new- elements, classes and else.
-alwaysApply: false
----
-# FDP Naming Conventions [FDP-Dev-Naming]
-
-## Overview
-This document outlines the standard naming conventions for FDP projects.
-
-## General Rules
-- Use PascalCase for:
-  - Classes
-  - Interfaces
-  - Types
-  - Enums
-- Use camelCase for:
-  - Variables
-  - Constants
-  - Methods
-- Use descriptive, meaningful names
-
-## Module Prefixes
-- Each element must be prefixed with its module's 2-3 letter identifier
-- Helps with:
-  - Navigation
-  - Module identification
-  - Preventing naming conflicts
-- Example: `FE_Page_Component` for FlowEditor module
-
-## Element Types
-Format: Element Name (File Pattern) -> Class Postfix
-
-### Model Elements
-#### Basic Models
-- Data Model (*.data-model.ts) -> _DataModel
-- Control Model (*.control-model.ts) -> _ControlModel
-- Interface (*.interface.ts) -> _Interface
-
-#### Special Models
-- Params (*-params.control-model.ts) -> _Params_ControlModel
-- Settings (*-settings.control-model.ts) -> _Settings_ControlModel
-- Settings Constants (*-settings.const.ts) -> _settings_const
-- Data Params (DyFM_DataModel_Params in *.data-model.ts) -> _DataModel_Params
-
-### FullStack Elements
-- Type (*.type-enum.ts) -> _Type
-- ServiceBase (*.service-base.ts) -> _ServiceBase
-- ControlService (*.control-service.ts) -> _ControlService
-- ApiService (*.api-service.ts) -> _ApiService
-
-### Frontend Elements
-- Module (*.module.ts) -> _Module
-- RoutingModule (*.routing-module.ts) -> _RoutingModule
-- DataService (*.data-service.ts) -> _DataService
-- Component (*.component.ts) -> _Component
-- Directive (*.directive.ts) -> _Directive
-- Pipe (*.pipe.ts) -> _Pipe
-- Route (*.route-enum.ts) -> _Route
-- FullRoute (in route-enum file) -> _FullRoute
-- CSS classes: kebab-case
-- CSS variables: --kebab-case
-- Event handlers: handleEventName
-- Boolean variables: is prefix only (e.g., isActive, isEnabled)
-
-### Backend Elements
-- Controller (*.controller.ts) -> _Controller
-- DataService (*.data-service.ts) -> _DataService
-- SocketServerService (*.socket-server-service.ts) -> _SocketServerService
-- SocketClientService (*.socket-client-service.ts) -> _SocketClientService
-- EmailService (*.email-service.ts) -> _EmailService
-
-## File Naming
-- One class per file
-- File name matches class name
-- Test files: class-name.spec.ts
-- Interface files: interface-name.interface.ts
-- Type files: type-name.type.ts
-
-## Naming Examples
-```typescript
-// Module
-jóska-pista.module.ts -> JóskaPista_Module
-
-// Routing Module
-jóska-pista.routing-module.ts -> JóskaPista_RoutingModule
-
-// Services
-jp-vlmi.api-service.ts -> JP_Vlmi_ApiService
-jp-vlmi.data-service.ts -> JP_Vlmi_DataService
-jp-vlmi.control-service.ts -> JP_Vlmi_ControlService
-jp-vlmi.service-base.ts -> JP_Vlmi_ServiceBase
-
-// Models
-jp-vlmi.data-model.ts -> JP_Vlmi_DataModel
-jp-vlmi.control-model.ts -> JP_Vlmi_ControlModel
-jp-vlmi.interface.ts -> JP_Vlmi_Interface
-jp-vlmi-params.control-model.ts -> JP_Vlmi_Params_ControlModel
-jp-vlmi-settings.control-model.ts -> JP_Vlmi_Settings_ControlModel
-jp-vlmi-settings.const.ts -> JP_vlmi_settings_const
-
-// Enums
-jp-vlmi.type-enum.ts -> JP_Vlmi_Type
-jp-vlmi.route-enum.ts -> JP_Vlmi_Route
-
-// Frontend Specific
-handleUserClick() // Event handler
-isUserActive // Boolean variable
-.user-profile // CSS class
---primary-color // CSS variable
-```
-
-## File Structure
-- Module elements should be in the module's directory
-- Shared elements should be in the shared module
-- Use appropriate type folders (_services, _components, etc.)
+---
+description:  when naming new- elements, classes and else.
+alwaysApply: false
+---
+# FDP Naming Conventions [FDP-Dev-Naming]
+
+## Overview
+This document outlines the standard naming conventions for FDP projects.
+
+## General Rules
+- Use PascalCase for:
+  - Classes
+  - Interfaces
+  - Types
+  - Enums
+- Use camelCase for:
+  - Variables
+  - Constants
+  - Methods
+- Use descriptive, meaningful names
+
+## Module Prefixes
+- Each element must be prefixed with its module's 2-3 letter identifier
+- Helps with:
+  - Navigation
+  - Module identification
+  - Preventing naming conflicts
+- Example: `FE_Page_Component` for FlowEditor module
+
+## Element Types
+Format: Element Name (File Pattern) -> Class Postfix
+
+### Model Elements
+#### Basic Models
+- Data Model (*.data-model.ts) -> _DataModel
+- Control Model (*.control-model.ts) -> _ControlModel
+- Interface (*.interface.ts) -> _Interface
+
+#### Special Models
+- Params (*-params.control-model.ts) -> _Params_ControlModel
+- Settings (*-settings.control-model.ts) -> _Settings_ControlModel
+- Settings Constants (*-settings.const.ts) -> _settings_const
+- Data Params (DyFM_DataModel_Params in *.data-model.ts) -> _DataModel_Params
+
+### FullStack Elements
+- Type (*.type-enum.ts) -> _Type
+- ServiceBase (*.service-base.ts) -> _ServiceBase
+- ControlService (*.control-service.ts) -> _ControlService
+- ApiService (*.api-service.ts) -> _ApiService
+
+### Frontend Elements
+- Module (*.module.ts) -> _Module
+- RoutingModule (*.routing-module.ts) -> _RoutingModule
+- DataService (*.data-service.ts) -> _DataService
+- Component (*.component.ts) -> _Component
+- Directive (*.directive.ts) -> _Directive
+- Pipe (*.pipe.ts) -> _Pipe
+- Route (*.route-enum.ts) -> _Route
+- FullRoute (in route-enum file) -> _FullRoute
+- CSS classes: kebab-case
+- CSS variables: --kebab-case
+- Event handlers: handleEventName
+- Boolean variables: is prefix only (e.g., isActive, isEnabled)
+
+### Backend Elements
+- Controller (*.controller.ts) -> _Controller
+- DataService (*.data-service.ts) -> _DataService
+- SocketServerService (*.socket-server-service.ts) -> _SocketServerService
+- SocketClientService (*.socket-client-service.ts) -> _SocketClientService
+- EmailService (*.email-service.ts) -> _EmailService
+
+## File Naming
+- One class per file
+- File name matches class name
+- Test files: class-name.spec.ts
+- Interface files: interface-name.interface.ts
+- Type files: type-name.type.ts
+
+## Naming Examples
+```typescript
+// Module
+jóska-pista.module.ts -> JóskaPista_Module
+
+// Routing Module
+jóska-pista.routing-module.ts -> JóskaPista_RoutingModule
+
+// Services
+jp-vlmi.api-service.ts -> JP_Vlmi_ApiService
+jp-vlmi.data-service.ts -> JP_Vlmi_DataService
+jp-vlmi.control-service.ts -> JP_Vlmi_ControlService
+jp-vlmi.service-base.ts -> JP_Vlmi_ServiceBase
+
+// Models
+jp-vlmi.data-model.ts -> JP_Vlmi_DataModel
+jp-vlmi.control-model.ts -> JP_Vlmi_ControlModel
+jp-vlmi.interface.ts -> JP_Vlmi_Interface
+jp-vlmi-params.control-model.ts -> JP_Vlmi_Params_ControlModel
+jp-vlmi-settings.control-model.ts -> JP_Vlmi_Settings_ControlModel
+jp-vlmi-settings.const.ts -> JP_vlmi_settings_const
+
+// Enums
+jp-vlmi.type-enum.ts -> JP_Vlmi_Type
+jp-vlmi.route-enum.ts -> JP_Vlmi_Route
+
+// Frontend Specific
+handleUserClick() // Event handler
+isUserActive // Boolean variable
+.user-profile // CSS class
+--primary-color // CSS variable
+```
+
+## File Structure
+- Module elements should be in the module's directory
+- Shared elements should be in the shared module
+- Use appropriate type folders (_services, _components, etc.)
 - Follow the project structure guidelines for placement 

package/.cursor/rules/_ag_should-be.mdc

@@ -1,7 +1,7 @@
----
-description: Apply if the user states a "it should do/work like this/that"
-alwaysApply: false
----
-
-# Global planning and execution policy
+---
+description: Apply if the user states a "it should do/work like this/that"
+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

package/.cursor/rules/ai_development_guide.md

@@ -1,61 +1,61 @@
-# AI Development Guide
-
-## Language Requirements
-- Write all code in English
-- Write all logs in English
-- Write all code documentation in Hungarian
-- Write all comments in Hungarian
-- Write all error messages in English
-
-## Core Rules
-- Read and follow naming conventions (see [Naming Conventions](naming.md))
-- Use explicit type definitions (avoid automatic type inference)
-- Implement proper error handling
-- Never write logics into getters, getters should be only mappers
-- If the task is complex, or need includes many subject members, do it one by one
-
-## Code Structure
-- One class/function per file
-- Clear file organization
-- Consistent import order
-- No circular dependencies
-- Proper separation of concerns
-
-## Error Handling
-- Use try-catch blocks
-- Log all errors in English
-- Provide meaningful error messages in English
-- Handle edge cases
-- Validate inputs
-
-## Testing Requirements
-- Unit tests for all functions
-- Integration tests for features
-- Test edge cases
-- Maintain test coverage
-- Mock external dependencies
-
-## Documentation
-- Hungarian comments and documentation
-- JSDoc for functions in Hungarian
-- Clear parameter descriptions in Hungarian
-- Usage examples in Hungarian
-- Update docs with changes
-
-## Best Practices
-- DRY (Don't Repeat Yourself)
-- SOLID principles
-- Clean code practices
-- Performance optimization
-- Security considerations
-
-## Project-Specific Guidelines
-- Only for Frontend Development: Read [Frontend Guidelines](frontend.md)
-- Only for Backend Development: Read [Backend Guidelines](backend.md) 
-
-## Refactor
-- All files length should be under 300 lines
-  - For files over 300 lines, mark it with "// [TOO LONG FILE]"
-
-## Format
+# AI Development Guide
+
+## Language Requirements
+- Write all code in English
+- Write all logs in English
+- Write all code documentation in Hungarian
+- Write all comments in Hungarian
+- Write all error messages in English
+
+## Core Rules
+- Read and follow naming conventions (see [Naming Conventions](naming.md))
+- Use explicit type definitions (avoid automatic type inference)
+- Implement proper error handling
+- Never write logics into getters, getters should be only mappers
+- If the task is complex, or need includes many subject members, do it one by one
+
+## Code Structure
+- One class/function per file
+- Clear file organization
+- Consistent import order
+- No circular dependencies
+- Proper separation of concerns
+
+## Error Handling
+- Use try-catch blocks
+- Log all errors in English
+- Provide meaningful error messages in English
+- Handle edge cases
+- Validate inputs
+
+## Testing Requirements
+- Unit tests for all functions
+- Integration tests for features
+- Test edge cases
+- Maintain test coverage
+- Mock external dependencies
+
+## Documentation
+- Hungarian comments and documentation
+- JSDoc for functions in Hungarian
+- Clear parameter descriptions in Hungarian
+- Usage examples in Hungarian
+- Update docs with changes
+
+## Best Practices
+- DRY (Don't Repeat Yourself)
+- SOLID principles
+- Clean code practices
+- Performance optimization
+- Security considerations
+
+## Project-Specific Guidelines
+- Only for Frontend Development: Read [Frontend Guidelines](frontend.md)
+- Only for Backend Development: Read [Backend Guidelines](backend.md) 
+
+## Refactor
+- All files length should be under 300 lines
+  - For files over 300 lines, mark it with "// [TOO LONG FILE]"
+
+## Format
 - Break long lines, use lint project's rules

package/.cursor/rules/ai_directives.md

@@ -52,7 +52,7 @@ After code changes:
   1. Request specification from user
   2. If specification not provided:
      - Read [documentation rules](documentation_writing_rules.md)
-     - Create specification in /documentations/specifications
+     - Create specification in /fdp-documentations/specifications
      - Get approval before continuing
   3. If specification provided:
      - Review and ensure it's complete
@@ -83,7 +83,7 @@ After code changes:
 - No sensitive information in commits
 
 ## Project Guidelines
-- Read and use [FDP Packages](../../documentations/specifications/packages.md)
+- Read and use [FDP Packages](../../fdp-documentations/specifications/packages.md)
 - Maintain consistent structure
 - Follow project documentation