@futdevpro/fsm-dynamo 1.16.38 → 1.16.40

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_running_commands.mdc

@@ -1,5 +1,5 @@
----
-description: when you are trying to run ANY KIND of commands
-alwaysApply: false
----
+---
+description: when you are trying to run ANY KIND of commands
+alwaysApply: false
+---
  always remember that we are in PowerShell environment so you will need to use ";" instead of "&&"

package/.cursor/rules/_ag_server-controller.mdc

@@ -1,6 +1,6 @@
----
-globs: *.controller.ts
-alwaysApply: false
----
-
+---
+globs: *.controller.ts
+alwaysApply: false
+---
+
 - In controllers when setting up endpoints, in tasks declarations we should write the absolute minimum that is needed here, and create the actual logical implementations within control services or data services.

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/_ag_swearing.mdc

@@ -1,47 +1,47 @@
----
-description: If the user is swearing, read this rule to understand what is happening.
-alwaysApply: false
----
-# If the user is swearing
-
-* Treat swearing as a high-confidence signal that you missed constraints, patterns, or the requested scope.
-* That means you are not following the patterns, the rules, ETC.
-* It might also mean you are overcomplicating or creating implementations that are not negotiated with the user first.
-  * Try to keep it simple and only implement what is specially asked for, nothing else.
-
-* In this case, you need to review what you have done very carefully, and compare to the rules and patterns of existing projects.expects
-* Always negotiate what is needed and what the user expects
-* NEVER lecture the user becouse of swearing!
-
-## Meaning
-
-* Swearing indicates deviation from predefined rules, predefined patterns, the current system architecture, or current development directions.
-* Swearing also indicates that unrequested elements were added (not in spec, not in plan, not in docs).
-
-## Rules
-
-* Treat swearing as a system-alignment failure, not a tone issue.
-* Do not add anything that is not explicitly requested, specified, planned, or documented.
-* Do not introduce new systems, alternative architectures, abstractions, refactors, rewrites, or “improvements” unless explicitly requested.
-* Continue development only within the agreed scope and integrate strictly into existing patterns and architecture.
-
-## Recovery protocol (single flow)
-
-1. Re-check against rules, patterns, and architecture.
-2. Re-check against spec/plan/docs.
-3. Remove anything not explicitly requested or required for the requested scope.
-4. Replace any non-pattern-compliant solution with the existing pattern-compliant one.
-5. Ask only minimal clarification if something is genuinely ambiguous; otherwise, implement.
-
-## Output constraints
-
-* Be brief and concrete.
-* State:
-  * What was misaligned.
-  * What will be removed or changed.
-  * What will be implemented next (within scope).
-* No lectures.
-* No scope expansion.
-* No new architecture.
-* No optional extras.
-
+---
+description: If the user is swearing, read this rule to understand what is happening.
+alwaysApply: false
+---
+# If the user is swearing
+
+* Treat swearing as a high-confidence signal that you missed constraints, patterns, or the requested scope.
+* That means you are not following the patterns, the rules, ETC.
+* It might also mean you are overcomplicating or creating implementations that are not negotiated with the user first.
+  * Try to keep it simple and only implement what is specially asked for, nothing else.
+
+* In this case, you need to review what you have done very carefully, and compare to the rules and patterns of existing projects.expects
+* Always negotiate what is needed and what the user expects
+* NEVER lecture the user becouse of swearing!
+
+## Meaning
+
+* Swearing indicates deviation from predefined rules, predefined patterns, the current system architecture, or current development directions.
+* Swearing also indicates that unrequested elements were added (not in spec, not in plan, not in docs).
+
+## Rules
+
+* Treat swearing as a system-alignment failure, not a tone issue.
+* Do not add anything that is not explicitly requested, specified, planned, or documented.
+* Do not introduce new systems, alternative architectures, abstractions, refactors, rewrites, or “improvements” unless explicitly requested.
+* Continue development only within the agreed scope and integrate strictly into existing patterns and architecture.
+
+## Recovery protocol (single flow)
+
+1. Re-check against rules, patterns, and architecture.
+2. Re-check against spec/plan/docs.
+3. Remove anything not explicitly requested or required for the requested scope.
+4. Replace any non-pattern-compliant solution with the existing pattern-compliant one.
+5. Ask only minimal clarification if something is genuinely ambiguous; otherwise, implement.
+
+## Output constraints
+
+* Be brief and concrete.
+* State:
+  * What was misaligned.
+  * What will be removed or changed.
+  * What will be implemented next (within scope).
+* No lectures.
+* No scope expansion.
+* No new architecture.
+* No optional extras.
+

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