@futdevpro/fsm-dynamo 1.16.37 → 1.16.39

package/.c8rc.json

@@ -1,26 +1,26 @@
-{
-  "reporter": [
-    "html",
-    "text",
-    "lcov"
-  ],
-  "reports-dir": "./coverage",
-  "include": [
-    "src/**/*.ts"
-  ],
-  "exclude": [
-    "src/**/*.spec.ts",
-    "src/**/*.spec.js",
-    "src/spec/**",
-    "**/node_modules/**",
-    "**/coverage/**",
-    "**/*.d.ts",
-    "**/*.const.ts",
-    "**/*.enum.ts",
-    "**/*.interface.ts",
-    "**/*.type.ts",
-    "**/index.ts"
-  ],
-  "all": true
-}
-
+{
+  "reporter": [
+    "html",
+    "text",
+    "lcov"
+  ],
+  "reports-dir": "./coverage",
+  "include": [
+    "src/**/*.ts"
+  ],
+  "exclude": [
+    "src/**/*.spec.ts",
+    "src/**/*.spec.js",
+    "src/spec/**",
+    "**/node_modules/**",
+    "**/coverage/**",
+    "**/*.d.ts",
+    "**/*.const.ts",
+    "**/*.enum.ts",
+    "**/*.interface.ts",
+    "**/*.type.ts",
+    "**/index.ts"
+  ],
+  "all": true
+}
+

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

@@ -1,64 +1,64 @@
----
-description: 
-globs: 
-alwaysApply: true
----
-# Follow these
-[cursor-rules](cursor-rules.md)
-
-Strictly keep and follow patterns from the existing codebase!
-Always use, and align to @futdevpro/* packages
-Never import from "*/../../NPM-packages/*", use '@futdevpro/*' instead
-when suggesting, always try to read both main opened screen, since they are usually releated
-Always try to follow the existing patterns for code and formatting (dont forget to break long lines and use existing naming patterns).
-Always follow patterns of existing projects! (tech stack, naming, codes, everything!)
-We need no quick fixes only the best solution possible using Dy*
-Always look around for existing solutions before implementing new one
-Always look for samples in codebase
-Always maintain a "Single Source of Truth" for data management: each data domain should have ONE dedicated data-service that owns and manages that data. All components, services, and modules must consume data through these centralized data-services instead of duplicating queries, fetches, or data transformations. Never create parallel data access paths — if a data-service already handles a resource, extend it rather than creating a new one.
-Always implement fixes and features that are highlighted or requested by the user
-Always use existing scripts and architecture.
-Never try to modify configs if the user didn't asked specially to do so.
-Never create new test file types other than is already used in the project.
-Never create javascript files!
-Never use powershell commands, or anything that is not on the allowed list. (allowed: npm, pnpm, cd, npx)
-Don't use custom scripts, use the npm scripts provided in the current project.
-The npm scripts are complex, no need to run build and test separately, run only "npm test" (or check the scripts first)
-(IF you want to run multiple scripts you need to use ";" instead of "&&", eg.: cd .. ; npm test instead of cd .. && npm test)
-All projects have a _specifications folder in root, where we describe the expected functionality of how certain parts of the application should work (AI should never modify these files)
-All projects can have a __documentations folder in root, where we create documentations about what we've done in previous sessions (AI should always create very brief but describing documentations after each bigger implementation or refactor) (date flag these)
-
-
-my common requirements:
-- use existing enums, interfaces, services, etc. if possible
-- follow the existing patterns sctriclty; 
-    namings, file namings, module structure, error handlings, logging, testing, documentation, etc.
-- create enums instead of string literals
-- create interfaces for sub-objects
-- create interfaces for every object that is used more than once
-- one file should have only one export (only allowed more for DataModels and its dataParams)
-- enums should be; keyNameIsCamelCase = 'value-is-kebab-case'
-- break long lines at 120 characters
-- EVERY let, const, function, arrow function, and all inputs should have types. (always use types, dont create "as" casters)
-- 'as' casts should NEVER be used (only in very unique cases), (if 'as' casters are inevitable and unleavable then that indicates a serious issue)
-- if a file is longer than 500 lines, it should be considered for a refactor (main service can be ~1000 lines)
-- create static util service for services that are not needs connection to other services
-- add code documentation for every function, class, interface, enum, etc. (skip inputs)
-- add inline code documentation for every logical step, decision, and other important parts of the code
-- create sub-folders for more than 3 files with the same group (same system part)
-- every method needs more than 3 inputs should use a single object input instead of an argument list.
-- when passing or declaring objects, always write both key and value, never shorthand from local variable
-- use time constants for times from fsm eg: second, minute, hour, day, week
-- use "string[]" instead of "Array<string>"
-- use shortest, simplest codes eg: "if (inputResponse?.missingInformation?.flag) {" instead of "if (inputResponse && inputResponse.missingInformation && inputResponse.missingInformation.flag === true) {", or "if (!count) {" instead of "if (count === 0) {"
-- never create new index files for modules
-- put main methods in try catch (eg methods that are called from controllers)
-- prefer async and promise-based solutions over Observables and subscribe; use async/await and Promise where it fits, avoid RxJS subscribe when a one-shot async flow is enough.
-- No backward compatibility. No legacy support. Refactor all affected code. Do not keep migration layers, shims, or transitional code. Breaking changes allowed.
-
-- avoid using import() or require() methods, put the imports at the top of the file
-
-- the documentation should be in Hungarian 
-  - use Hunglish, use English words for technical terms, element names and programming concepts to maintain clarity and consistency with code implementation
-    - add "-" between english words and hungarian (affixation), eg: "figyelünk a channel-re"
-
+---
+description: 
+globs: 
+alwaysApply: true
+---
+# Follow these
+[cursor-rules](cursor-rules.md)
+
+Strictly keep and follow patterns from the existing codebase!
+Always use, and align to @futdevpro/* packages
+Never import from "*/../../NPM-packages/*", use '@futdevpro/*' instead
+when suggesting, always try to read both main opened screen, since they are usually releated
+Always try to follow the existing patterns for code and formatting (dont forget to break long lines and use existing naming patterns).
+Always follow patterns of existing projects! (tech stack, naming, codes, everything!)
+We need no quick fixes only the best solution possible using Dy*
+Always look around for existing solutions before implementing new one
+Always look for samples in codebase
+Always maintain a "Single Source of Truth" for data management: each data domain should have ONE dedicated data-service that owns and manages that data. All components, services, and modules must consume data through these centralized data-services instead of duplicating queries, fetches, or data transformations. Never create parallel data access paths — if a data-service already handles a resource, extend it rather than creating a new one.
+Always implement fixes and features that are highlighted or requested by the user
+Always use existing scripts and architecture.
+Never try to modify configs if the user didn't asked specially to do so.
+Never create new test file types other than is already used in the project.
+Never create javascript files!
+Never use powershell commands, or anything that is not on the allowed list. (allowed: npm, pnpm, cd, npx)
+Don't use custom scripts, use the npm scripts provided in the current project.
+The npm scripts are complex, no need to run build and test separately, run only "npm test" (or check the scripts first)
+(IF you want to run multiple scripts you need to use ";" instead of "&&", eg.: cd .. ; npm test instead of cd .. && npm test)
+All projects have a _specifications folder in root, where we describe the expected functionality of how certain parts of the application should work (AI should never modify these files)
+All projects can have a __documentations folder in root, where we create documentations about what we've done in previous sessions (AI should always create very brief but describing documentations after each bigger implementation or refactor) (date flag these)
+
+
+my common requirements:
+- use existing enums, interfaces, services, etc. if possible
+- follow the existing patterns sctriclty; 
+    namings, file namings, module structure, error handlings, logging, testing, documentation, etc.
+- create enums instead of string literals
+- create interfaces for sub-objects
+- create interfaces for every object that is used more than once
+- one file should have only one export (only allowed more for DataModels and its dataParams)
+- enums should be; keyNameIsCamelCase = 'value-is-kebab-case'
+- break long lines at 120 characters
+- EVERY let, const, function, arrow function, and all inputs should have types. (always use types, dont create "as" casters)
+- 'as' casts should NEVER be used (only in very unique cases), (if 'as' casters are inevitable and unleavable then that indicates a serious issue)
+- if a file is longer than 500 lines, it should be considered for a refactor (main service can be ~1000 lines)
+- create static util service for services that are not needs connection to other services
+- add code documentation for every function, class, interface, enum, etc. (skip inputs)
+- add inline code documentation for every logical step, decision, and other important parts of the code
+- create sub-folders for more than 3 files with the same group (same system part)
+- every method needs more than 3 inputs should use a single object input instead of an argument list.
+- when passing or declaring objects, always write both key and value, never shorthand from local variable
+- use time constants for times from fsm eg: second, minute, hour, day, week
+- use "string[]" instead of "Array<string>"
+- use shortest, simplest codes eg: "if (inputResponse?.missingInformation?.flag) {" instead of "if (inputResponse && inputResponse.missingInformation && inputResponse.missingInformation.flag === true) {", or "if (!count) {" instead of "if (count === 0) {"
+- never create new index files for modules
+- put main methods in try catch (eg methods that are called from controllers)
+- prefer async and promise-based solutions over Observables and subscribe; use async/await and Promise where it fits, avoid RxJS subscribe when a one-shot async flow is enough.
+- No backward compatibility. No legacy support. Refactor all affected code. Do not keep migration layers, shims, or transitional code. Breaking changes allowed.
+
+- avoid using import() or require() methods, put the imports at the top of the file
+
+- the documentation should be in Hungarian 
+  - use Hunglish, use English words for technical terms, element names and programming concepts to maintain clarity and consistency with code implementation
+    - add "-" between english words and hungarian (affixation), eg: "figyelünk a channel-re"
+

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

@@ -1,8 +1,8 @@
----
-description:  when debug
-alwaysApply: false
----
-
-
-- when debugging always use unified global debug log method
+---
+description:  when debug
+alwaysApply: false
+---
+
+
+- when debugging always use unified global debug log method
 - use global debugging tool instead of fetch() (global telewag tool should have that fetch())