@futdevpro/fsm-dynamo 1.20.9 → 1.20.10

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.

package/.cursor/rules/_ag_frontend-structure.mdc

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