@futdevpro/nts-dynamo 1.15.157 → 1.15.163

package/.cursor/rules/__main.mdc

@@ -1,64 +0,0 @@
----
-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 +0,0 @@
----
-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 +0,0 @@
----
-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 +0,0 @@
----
-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())

package/.cursor/rules/_ag_documentation_writing_rules.mdc

@@ -1,372 +0,0 @@
----
-description:  When creating documentations
-alwaysApply: false
----
-# Documentation Writing Rules
-
-## Core Rules
-1. Documentation language:
-  - For FDP documentations: write the documentation in Hungarian
-    - In Hungarian documentation, use English words for technical terms and programming concepts to maintain clarity and consistency with code implementation
-  - For Dynamo documentations: write the documentation in English
-2. Focus on behavior, not implementation
-3. Write from user's perspective
-  - In FDP: the user is the webSite/webApp user
-  - In Dynamo: the user is the developer
-4. Keep language clear and simple
-  - Use active voice
-  - Avoid technical jargon unless necessary
-5. Follow the template structure
-6. Keep it short and informative
-7. Documentation Validation Process:
-  - Before adding new content to the documentation:
-    1. Locate the implementation file
-    2. Verify the new information matches the implementation
-    3. Add the verified information to documentation
-  - Before removing content from the documentation:
-    1. Locate the implementation file
-    2. Confirm the information is no longer valid
-    3. Remove the outdated information from documentation
-8. Don't add sections that is not reqiured, requested, or specially needed
-9. **Always** read linked implementation files before
-10. AI-Specific Considerations:
-  - Use explicit file paths and references
-  - Include clear context markers
-  - Maintain consistent ID patterns
-  - Document tool-specific requirements
-  - Use proper markdown formatting for better AI parsing
-  - Include clear section boundaries
-  - Use explicit type annotations where possible
-11. **Never** change paths
-
-## Documentation IDs
-- All documentation IDs follow a hierarchical structure from system-level to feature-level documentation.
-- Never use in reference documentation or higher-level documentation
-- Only use at the exact detailed documentation and where the feature is implemented
-- Never change existing IDs, only highlight it if its incorrect
-
-### System IDs
-- Used ONLY for system/project-level documentation
-- Format: [System]
-  - System: Usually three-letter, code of the project/package
-- Must be unique at the system level
-- [Prefix] = [System]
-- Parent is:
-  - For System: FDP or Dynamo
-  - For Module: a System
-  - For Section_Group: a Module
-  - For Section: a Module
-
-### Module IDs
-- Used ONLY for module-level documentation
-- Format: [System]-[Module]
-  - System: Inherits from System ID
-  - Module: Usually three-letter, code of the module
-- Must be unique at the module level
-
-### Feature IDs
-- Used ONLY for low-level design documentation
-  - But never on Sections or Section Groups
-- Format: [System]-[Module]-[SHORTCUT]
-  - System: Inherits from System ID
-  - Module: Inherits from Module ID
-  - SHORTCUT: First letters of the function/class/ect extended to make it unique
-    - Examples: DMS (DataManagementSystem), UIF (UserInterfaceFactory)
-- Must be unique at the feature level
-
-### Section IDs
-- Used ONLY for sections
-- Format: [Section] OR [Section-Group]
-  - Sections should never have ID other than [Section] OR [Section-Group]
-  - Sections should always have the [Section] flag
-  - Section Groups should always have the [Section-Group] flag
-
-## Quick Checklist
-- [ ] Written in the required language (Hungarian for FDP, English for Dynamo) [REQUIRED]
-- [ ] Written from correct user perspective (end-user for FDP, developer for Dynamo) [REQUIRED]
-- [ ] Uses clear and simple language [REQUIRED]
-- [ ] Follows template structure [REQUIRED]
-- [ ] Has valid Documentation ID [REQUIRED]
-- [ ] Focuses on behavior, not implementation details [RECOMMENDED]
-- [ ] All content has been validated against implementation [REQUIRED]
-- [ ] Uses proper {File Main_Name} format (not filenames with extensions) [REQUIRED]
-- [ ] Table of contents uses proper component names, not filenames [REQUIRED]
-- [ ] Markdown links should work in ToC, dont miss "_"s and "pefix_"s
-
-## Basic Template
-- If there is a specific Documentation Template for your type use that, otherwise use this:
-    ```markdown
-    #{Name of the Documentation} [{ID(optional)}]
-    (Use System-ID [SYSTEM] for system-level documentation)
-    (Use Module-ID [SYSTEM]-[MODULE] for module-level documentation)
-    (Use Section/SectionGroup-ID [SYSTEM]-[MODULE]-[SHORTCUT] for low-level design documentation ONLY)
-
-    ## Overview (Required)
-    (
-      - Purpose: Brief description of what this documentation covers
-      - Main Features: List of key features or capabilities in this documentation
-      - Brief summary, focused on usability/tools based on the content
-      - Only create overview when the content is ready to be summarized (use: "[TODO]" while its not filled)
-    )
-
-    ### Key Features
-    [TODO] (List key features, focused on usability/tools)
-
-    ## Table of Contents (Required)
-      (Links for each section, member and children)
-
-    ## {Contents} (Required)
-      (Detailed informations about the subjects)
-
-    (link back)
-    ```
-
-## Documentation File Hierarchy
-
-### For Project/Package Documentation Structure
-- Use the following hierarchy template:
-  - {system-code}.md 
-    - {module1}
-      - {Prefix}-{module1}_{section1}.md
-      - {Prefix}-{module1}_{section2}.md
-      - {Prefix}-{module1}-module.md
-    - {module2}
-      - {Prefix}-{module2}_{section1}.md
-      - {Prefix}-{module2}_{section2}.md
-      - {Prefix}-{module2}-module.md
-      - {Prefix}-{module2}_{section-group1}
-        - {Prefix}-{module2}-{section-group1}_{section1}.md
-        - {Prefix}-{module2}-{section-group1}_{section2}.md
-        - {Prefix}-{module2}-{section-group1}.md
-      ...
-- RULES:
-  1. Low-level elements should contain only title and Overview section with [TODO]
-  2. Keep file names lowercase but use proper capitalization in titles and content
-  3. File naming patterns:
-    - Package files: {package-name}.md
-    - Module files: {Prefix}-{module-name}-module.md
-    - Section files: {Prefix}-{module-name}_{section}.md
-    - Code prefixes: {CODE_Prefix}_{MODULE}_
-    - Import paths: {IMPORT_PATH}/{module}
-
-#### Creating Project/Package Documentation File Hierarchy
-- Use the following template for each new section element: 
-    ```markdown
-    # {SYSTEM_NAME} {Module Name} {Section}
-
-    ## Overview
-    [TODO]
-    ```
-
-## Documentation Read
-- You can define the Documentation type using the [Documentation IDs](#Documentation-IDs)
-
-## Documentation Templates
-- RELATIVE_PATH: path to the local implementation file, using relative path from the md file
-  - AI Agents won't be able to use this, but the IDE will be
-- ABSOLUTE_PATH: path to the local implementation file, using absolute path from root
-  - The IDE won't be able to use this, but the AI Agents will be
-
-### For Project/Package
-- Use the following template for creating a Package Documentation:
-    ```markdown
-    # {System_Name} [{System-ID}]    
-    **Package:** `{package-code}`  
-    **Code prefix:** {CODE_Prefix_}
-    **Import:** `{IMPORT_PATH}`
-    **Dependencies:** {List of dependencies in FDP hierarchy}
-    **Link:** [package.json]({RELATIVE_PATH})
-    **Base location** {ABSOLUTE_PATH}
-
-    ## Overview
-    (Base templates for System_Name Projects.)
-
-    ### Key Features
-    [TODO] (List key features, focused on usability/tools)
-
-    ## Description
-    [TODO] (Base templates for System_Name Systems providing modular architecture for various project types.)
-
-    ## Table of Contents
-    1. [Main Module](#{main-module})
-    2. [{Module1 Name}](#{module1-name}-module)
-    3. [{Module2 Name}](#{module2-name}-module)
-
-    ## Modules
-
-    ### [Main Module](main/{Prefix}-main-module.md)
-    [TODO] (Exported members)
-
-    ### [{Module1 Name}]({module1-name}/{Prefix}-module1-name-module.md)
-    [TODO] (Exported members)
-
-    ## Exported Members
-
-    ### {Section1 Name}
-    - [`{Exported_Member1}`]({module1-name}/{Prefix}-module1-name-module.md/#Exported_Member1) short description
-
-    [Back to {Parent Name}](../{parent-documentation-name}.md)
-    ```
-
-### For Module
-- Use the following template for creating a Module Documentation:
-    ```markdown
-    # {System_Name} {Module_Name} Module Documentation [{Module-ID}]
-    **Import:** `{IMPORT_PATH}/{module-path}`
-    **Link:** [index]({RELATIVE_PATH to the index})
-    **Base location** {ABSOLUTE_PATH to the index}
-
-    ## Overview
-    [TODO] (Module description)
-
-    ### Key Features
-    [TODO] (List key features)
-
-    ## Table of Contents (ONLY if the Sections are in different files)
-    1. [{Section1_Name}]({Prefix}-{module-name}_{section1}.md)
-    2. [{Section2_Name}]({Prefix}-{module-name}_{section2}.md)
-    3. [{Section_Group1}]({Prefix}-{module-name}_{section1-group}/[{Prefix}-{module-name}_{section1-group}.md)
-      - [{Section1_Name}]({Prefix}-{module-name}_{section1-group}/{Prefix}-{module-name}-{section1-group}_{section1}.md)
-      - [{Section2_Name}]({Prefix}-{module-name}_{section1-group}/{Prefix}-{module-name}-{section1-group}_{section2}.md)
-
-    ## Table of Contents (ONLY if the Files/Features are here in this file)
-    1. [{Section_Group1}](#{Section-Group1-Name})
-      - [{File1 Main_Name}](#{file1-main_name})
-      - [{File2 Main_Name}](#{file2-main_name})
-    
-    ## Detailed Documentation (ONLY if the Sections are in different files)
-    [TODO] (Exported members)
-    
-    ## {Section Group1 Name} (ONLY if the Files/Features are here in this file)
-
-    ### [{File1 Main_Name}]({path to the implementation file1})
-    {Package Project File1/Feature}
-
-    ### [{File2 Main_Name}]({path to the implementation file2})    
-    {Package Project File2/Feature}
-
-    ...
-
-    [Back to {System_Name}](../{package-code}.md)
-    ```
-
-### For Section Group
-- Use the following template for creating a Documentation Section Group:
-    ```markdown
-    # {System_Name} {Module_Name} {Section_Group_Name} Documentations [Section-Group]
-
-    ## Overview
-    [TODO] Section Group description
-
-    ### Key Features
-    [TODO] (List key features)
-
-    ## Table of Contents
-    1. [{Section1_Name}]({Prefix}-{module-name}_{section1}.md)
-    2. [{Section2_Name}]({Prefix}-{module-name}_{section2}.md)
-
-    ## Detailed Documentation
-    [TODO] (Exported members)
-
-    [Back to {Module_Name}](../{Prefix}-{module-name}-module.md)
-    ```
-
-### For Section
-- Use the following template for creating a Documentation Section:
-    ```markdown
-    # {System_Name} {Module_Name} {Section_Name} Documentation [Section] 
-
-    ## Overview
-    [TODO] {Section description}
-
-    ### Key Features
-    [TODO] List key features
-
-    ## Table of Contents
-    1. [{Sub Section1 Name}](#{Sub-Section1-Name})
-      - [{File1 Main_Name}](#{File1-Main_Name})
-      - [{File2 Main_Name}](#{File2-Main_Name})
-    2. [{Sub Section2 Name}](#{Sub-Section1-Name})
-      - [{File1 Main_Name}](#{File3-Main_Name})
-      - [{File2 Main_Name}](#{File4-Main_Name})
-    
-    ## {Sub Section1 Name} (required and based on File Types)
-
-    ### [{File1 Main_Name}]({path to the implementation file1})
-    [Package Project File1]
-
-    ### [{File2 Main_Name}]({path to the implementation file2})    
-    [Package Project File2]
-
-    ...
-
-    [Back to {Module_Name or Section_Group_Name}]({Prefix}-{module-name}-module.md)
-    ```   
-- Sub Sections generated based on the file types: somehting.{file-type}.ts
-  - E.g.: 
-    - Enums for *.enum.ts
-    - Constants for *.const.ts
-
-### For Package Project File/Feature
-- Use the following template for each file/feature documented: 
-    ```markdown 
-    ### [`{Main_Name}`]({RELATIVE_PATH to the implementation file})
-      - **Code:** [{Feature-ID}]
-      - **Base Location:** `{ABSOLUTE_PATH}`
-      - **Description(only for multiple Exported Members):** {short description about the main concept of the members}
-      - **Exported Members(required):**
-        - `{exportedMember}`: {short description}
-          - **Aliases(optional):** `{exportedMember1Alias1}`, `{exportedMember1Alias2}`
-          - **Extending(optional):** [{ExtendedMemberName}]({RELATIVE_PATH to extending type documentation or "MISSING LINK"}
-          - **Properties(optional):**
-            - `{property}`: {short description}
-          - **Methods(optional):**
-            - `{method}`: {short description}
-          - **Type(optional: CONST ONLY):** {type and link if it is available in documentation}
-          - **Values(optional: ENUM ONLY):**
-            - `{value}`: {short description}
-          - **Features(optional):**
-            - {feature}
-    ```
-- File/Feature Documentations should be on level3:###
-
-#### STRICT RULES for {Main_Name}:
-- **NEVER** use the actual filename with extensions (e.g., do not use "token.control-model.ts")
-- **ALWAYS** Read the linked file and then:
-  - For files with a single exported member:
-    - Use the **exact same name** of the exported member (e.g., FDP_Token)
-  - For files with multiple exported members:
-    - If there is a significant exported member, use its **exact same name**
-    - If there is no significant exported member, use a short, descriptive name that clearly represents the file's content (e.g., Token Control Models)
-- These rules apply to both the Table of Contents section and the headers for each file
-
-#### STRICT RULES for {route in the local project hierarchy to the implementation file}:
-- **NEVER CHANGE** "route in the local project hierarchy to the implementation file"
-
-#### STRICT RULES for Aliases and Exported members:
-- Never add aliases as exported members, but always add them as Aliases
-
-#### RULES for extensions
-- Extension Links:
-  - Always gather the extensions
-  - Link to the parent documentation when available
-  - Use "MISSING LINK" when parent documentation is not found
-
-## Formatting Rules
-- Use backticks (`) for:
-  - Code references
-  - File names
-  - Function names
-  - Class names
-  - Property names
-  - Method names
-  - Enum values
-- Use bold (**) for:
-  - Section headers
-  - Important terms
-  - Required fields
-- Use italics (*) for:
-  - Optional fields
-  - Notes
-  - Warnings
-

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

@@ -1,113 +0,0 @@
----
-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 +0,0 @@
----
-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.