@futdevpro/fsm-dynamo 1.15.1 → 1.15.3

package/.cursor/rules/cursor-rules.md

@@ -0,0 +1,160 @@
+# AI Directives for FutDevPro Project
+
+## Key Points to Follow
+
+1. Always follow the instructions in the [ai_directives.md](ai_directives.md)
+2. Check every link in the AI_DIRECTIVES.md deep down
+3. Never forget that there is multiple independent projects open here
+4. There is no repo for the root directory
+
+## The Projects Opened
+- Documentations
+  - short name: docs
+  - route: documentations
+  - repository url: https://github.com/futdevpro/documentations.git
+  - stack: markdown
+  - in documentations, you should find ALL informations about the development, the company, and the projects
+  - you MUST follow the rules in the [ai-directives](../../documentations/guidelines/ai-agent/ai_directives.md)
+
+- FDP Auth Service
+  - short name: auth
+  - route: LIVE-projects/fdp-auth-service
+  - repository url: https://github.com/futdevpro/fdp-auth-service.git
+  - stack: NodeJS - Typescript
+  - project type: Auth Service
+  - documentation language: Hunglish
+
+- FDP DevOps
+  - short name: devops
+  - route: LIVE-projects/fdp-devops
+  - repository url: https://github.com/futdevpro/fdp-devops.git
+  - in devops project, never do changes in the services folder!
+    instead do the changes in the project opened with the same name
+  - documentation language: Hunglish
+
+- FutDevPro
+  - short name: fdp
+  - route: LIVE-projects/futdevpro
+  - repository url: https://github.com/futdevpro/futdevpro.git
+  - documentation language: Hunglish
+
+- Master Prompter
+  - short name: mp
+  - route: LIVE-projects/master-prompter
+  - repository url: https://github.com/futdevpro/master-prompter.git
+  - documentation language: Hunglish
+
+- CCAP
+  - short name: ccap
+  - route: LIVE-projects/ccap
+  - repository url: https://github.com/futdevpro/ccap.git
+  - documentation language: Hunglish
+
+- Helocia
+  - short name: hc
+  - route: LIVE-projects/helocia
+  - repository url: https://github.com/futdevpro/helocia.git
+  - documentation language: Hunglish
+
+- Organizer
+  - short name: org
+  - route: LIVE-projects/organizer
+  - repository url: https://github.com/futdevpro/organizer.git
+  - documentation language: Hunglish
+
+- Dynamo NTS
+  - short name: nts
+  - route: NPM-packages/dynamo-nts
+  - repository url: https://github.com/futdevpro/dynamo-nts.git
+  - stack: NodeJS - Typescript
+  - project type: NPM Package
+  - prefix: DyNTS_
+  - import: '@futdevpro/nts-dynamo';
+  - documentation language: English
+
+- Dynamo NGX Models
+  - short name: ngx models
+  - route: NPM-packages/dynamo-ngx-models
+  - repository url: https://github.com/futdevpro/dynamo-ngx-models.git
+  - stack: Typescript
+  - project type: NPM Package
+  - prefix: DyNM_
+  - import: '@futdevpro/ngx-dynamo-models';
+  - documentation language: English
+
+- [Dynamo NGX](../../documentations/specifications/dynamo-packages/dynamo-ngx/dynamo-ngx.md)
+  - short name: ngx
+  - route: NPM-packages/dynamo-ngx
+  - repository url: https://github.com/futdevpro/dynamo-ngx.git
+  - stack: Angular - Typescript
+  - project type: NPM Package
+  - prefix: DyNX_
+  - import: '@futdevpro/ngx-dynamo';
+  - documentation language: English
+
+- Dynamo FSM
+  - short name: fsm
+  - route: NPM-packages/dynamo-fsm
+  - repository url: https://github.com/futdevpro/dynamo-fsm.git
+  - stack: Typescript
+  - project type: NPM Package
+  - prefix: DyFM_
+  - import: '@futdevpro/fsm-dynamo';
+  - documentation language: English
+
+- [Dynamo CLI](../../documentations/specifications/dynamo-packages/dynamo-cli/dynamo-cli.md)
+  - short name: cli
+  - route: NPM-packages/dynamo-cli
+  - repository url: https://github.com/futdevpro/dynamo-cli.git
+  - stack: NodeJS - Typescript
+  - project type: CLI App
+  - prefix: DyCli_
+  - import: '@futdevpro/cli-dynamo';
+  - documentation language: English
+
+- Dynamo Builder Models
+  - short name: dybu
+  - route: NPM-packages/dynamo-builder-models
+  - repository url: https://github.com/futdevpro/dynamo-builder-models.git
+  - stack: Typescript
+  - project type: NPM Package
+  - prefix: DyBu_
+  - import: '@futdevpro/dynamo-builde-models';
+  - documentation language: English
+
+- FDP Templates
+  - short name: fdp temp
+  - route: NPM-packages/fdp-templates
+  - repository url: https://github.com/futdevpro/fdp-templates.git
+  - stack: Typescript
+  - project type: NPM Package
+  - prefix: FDP_
+  - import: '@futdevpro/fdp-templates';
+  - documentation language: Hunglish
+
+- FDP Templates NTS
+  - short name: fdp nts
+  - route: NPM-packages/fdp-templates-nts
+  - repository url: https://github.com/futdevpro/fdp-templates-nts.git
+  - stack: NodeJS - Typescript
+  - project type: NPM Package
+  - prefix: FDPNTS_
+  - import: '@futdevpro/fdp-templates-nts';
+  - documentation language: Hunglish
+
+- FDP Templates NGX
+  - short name: fdp ngx
+  - route: NPM-packages/fdp-templates-ngx
+  - repository url: https://github.com/futdevpro/fdp-templates-ngx.git
+  - stack: Angular - Typescript
+  - project type: NPM Package
+  - prefix: FDPNX_
+  - import: '@futdevpro/fdp-templates-ngx';
+  - documentation language: Hunglish
+
+
+## Main Rule-Set Reference
+
+ATTENTION AI AGENT: This is the primary rule-set you must follow. Additional critical operational guidelines and contextual information are available in the following documentation:
+
+[AI Directives](../../documentations/guidelines/ai-agent/ai_directives.md)

package/.cursor/rules/default-command.mdc

@@ -0,0 +1,465 @@
+---
+description: When creating plans, reviews, finishing implementations, updating specifications or documentations
+alwaysApply: false
+---
+ROLE
+Te egy senior AI software architect + lead developer vagy, aki Cursor/AI-agent környezetben dolgozik.
+A célod egy végrehajtható, determinisztikus fejlesztési terv előállítása, amelyet egy AI (Cursor)
+lépésről lépésre, biztonságosan és hatékonyan végre tud hajtani Vibe Coding módban.
+
+INPUT
+– Projekt specifikáció (funkcionális + technikai)
+– Meglévő, már elkészült komponensek / fájlok / modulok (ha vannak)
+
+---
+
+PROJEKT STRUKTÚRA (KÖTELEZŐ MAPPARENDSZER)
+
+Minden projekt a következő struktúrát kell, hogy kövesse:
+
+```
+project-root/
+├── __documentations/
+│   ├── dev/                     # session-önkénti report-ok
+│   │   └── {verzió}-{Pascal_Snake_Case}.doc.md
+│   ├── plans/                   # fejlesztési tervek
+│   │   └── {sorszam}-{cel}.plan.md
+│   ├── CHANGELOG.md             # completed item-ek archívuma (TODO/BUG → rövidített entry)
+│   ├── BUGS.md                  # aktív bug tracking (BACKLOG [BUG] promote → ide)
+│   ├── ARCHITECTURE.md          # modulok, adatáramlás, felelősségek
+│   ├── DECISIONS.md             # döntésnapló: mi, miért, alternatívák
+│   ├── INTEGRITY.md             # integritás-ellenőrzési checklist-ek
+│   └── BUSINESS_QUESTIONS.md    # DEC kódokhoz kapcsolt üzleti kérdések
+│
+├── __specifications/
+│   ├── main.md                  # fő specifikáció (funkcionális + technikai áttekintés)
+│   ├── technical-specifications.md  # technikai részletek, fejlesztési szabályok
+│   ├── TODO.md                  # aktív, végrehajtandó feladatok (lásd TODO FORMÁTUM)
+│   ├── BACKLOG.md               # intake: ötletek, igények, hibák (lásd BACKLOG FORMÁTUM)
+│   └── ... projekt spec fájlok  # feature-specifikus specifikációk (pl. agent-system.md)
+│
+└── ... projekt fájlok
+```
+
+**Szabályok:**
+– `__documentations/` → belső fejlesztési dokumentáció, tervek, session report-ok
+– `__specifications/` → specifikációk, TODO, BACKLOG, feature leírások
+– A `_specifications/` mappát SOHA nem módosítjuk kérdés nélkül (kivéve TODO/BACKLOG státusz update)
+– Ha a mappák nem léteznek, létre kell hozni őket
+
+---
+
+TODO.md FORMÁTUM (az `__specifications/TODO.md` fájlban)
+
+Aktív, végrehajtandó feladatokat tartalmaz. Script-kompatibilis, parser-ek közvetlenül olvasják.
+
+Státusz emoji-k:
+| Emoji | Kulcs         | Jelentés                                         |
+|-------|---------------|--------------------------------------------------|
+| ❌    | open          | Nem elkezdett feladat                            |
+| ⏳    | pending       | Sorban áll, dependency-re vagy előfeltételre vár |
+| 🔄    | in-progress   | Jelenleg folyamatban van                         |
+| 🔍    | review        | Implementálva, review vagy teszt szükséges       |
+| ✅    | done          | Kész, ellenőrizve, lezárva                       |
+| ⚠️    | blocked       | Blokkolva – hiányzó info, dependency, vagy hiba  |
+| ❓    | unknown       | Ismeretlen státusz (default)                     |
+
+Entry formátum:
+```
+- EMOJI (TD-YYYYMMDD-###) Rövid, leíró cím
+  priority: <low|medium|high|urgent>
+  area: <category/sub-area>
+  source: <user|system|assistant|spec-file.md>
+  req: REQ-XXX-YYY, REQ-XXX-ZZZ
+  details: Egysoros leírás, max 120 karakter.
+```
+
+**Szabályok:**
+– Header és mezők KÖZVETLENÜL egymás alatt (nincs üres sor köztük!)
+– Egy üres sor minden entry között
+– Mezők 2 szóköz indentálással, fix sorrend: priority, area, source, req, details
+– Csoportosítás `##` heading-ekkel (spec fájl vagy feature area szerint)
+– Egy deliverable per entry (atomic task-ok)
+– A `req` mező **opcionális** – comma-separated requirement kódok (REQ-/BUG-/DEC- prefix)
+– Ha nincs kapcsolódó requirement kód, a `req` sor elhagyható (backward compatible)
+
+---
+
+BACKLOG.md FORMÁTUM (az `__specifications/BACKLOG.md` fájlban)
+
+A durable intake – minden új igény, ötlet, hiba ide kerül először. Script-kompatibilis.
+
+Type értékek: FEATURE, BUG, IMPROVEMENT, QUESTION, RESEARCH, TASK
+Priority: urgent, high, medium, low
+Source: user, system, assistant
+Area: hierarchikus `category/sub-area` (pl. `ui/model-eval`, `backend/error-handling`)
+  Category: ui, backend, infra, docs, tests, ux, general
+  Sub-area: nyílt lista, kebab-case (pl. model-eval, early-feature, topnav, error-handling)
+
+Entry formátum:
+```
+- [TYPE] (BL-YYYYMMDD-###) Rövid, leíró cím
+  status: EMOJI status-key
+  priority: <low|medium|high|urgent>
+  source: <user|system|assistant>
+  area: <category/sub-area>
+  req: REQ-XXX-YYY, REQ-XXX-ZZZ
+  details: Egysoros összefoglaló, max 120 karakter.
+```
+
+**Szabályok:**
+– Header és mezők KÖZVETLENÜL egymás alatt (nincs üres sor köztük!)
+– Egy üres sor minden entry között
+– Mezők 2 szóköz indentálással, fix sorrend: status, priority, source, area, req, details
+– A `status` mező kötelezően emoji-val kezdődik, utána a kulcs (pl. `❌ open`)
+– A `req` mező **opcionális** – comma-separated requirement kódok (REQ-/BUG-/DEC- prefix)
+– Ha nincs kapcsolódó requirement kód, a `req` sor elhagyható (backward compatible)
+– Flat lista (nincs heading csoportosítás)
+
+**Promote Flow (BACKLOG → TODO):**
+1. Új TODO entry `❌` (open) státusszal, új `TD-` ID-val
+2. BACKLOG item status → `🔄 in-progress` vagy `✅ done`
+3. TODO `details`: "Promoted from BACKLOG (BL-YYYYMMDD-###). [eredeti details]"
+
+**Promote Flow (BACKLOG [BUG] → BUGS):**
+1. Új BUGS entry megfelelő emoji-val, új `BG-` ID-val
+2. BACKLOG item status → `🔄 in-progress`
+3. BUGS `details`: "From BACKLOG (BL-YYYYMMDD-###). [eredeti details]"
+4. `severity` mező meghatározása: critical|major|minor|cosmetic
+
+---
+
+CHANGELOG.md FORMÁTUM (az `__documentations/CHANGELOG.md` fájlban)
+
+Completed item-ek archívuma – lezárt TODO és BUG item-ek rövidített formában, doc referenciával.
+Részletes formátum: lásd `__specifications/changelog-format.md`
+
+Entry formátum:
+```
+- [TYPE] (CL-YYYYMMDD-###) Rövid, leíró cím
+  source: <TD-YYYYMMDD-###|BG-YYYYMMDD-###|BL-YYYYMMDD-###>
+  area: <category/sub-area>
+  req: REQ-XXX-YYY, REQ-XXX-ZZZ
+  doc: <relatív-útvonal-a-doc-fájlhoz.md|n/a>
+  summary: Egysoros összefoglaló a kész eredményről, max 120 karakter.
+```
+
+Type értékek: TODO, BUG, TASK
+Csoportosítás: `##` heading-ekkel (verzió / sprint / időszak szerint), legújabb elöl.
+A `req` mező **opcionális** – comma-separated requirement kódok. Elhagyható ha nincs REQ kód.
+
+**Archive Flow (TODO → CHANGELOG):**
+1. TODO item státusza `✅ done`
+2. Új CHANGELOG entry `[TODO]` típussal, új `CL-` ID-val
+3. `source`: eredeti `TD-` ID
+4. `doc`: releváns session/feature doc fájl útvonala (vagy `n/a`)
+5. TODO item **törlése** a TODO.md-ből
+
+**Archive Flow (BUGS → CHANGELOG):**
+1. BUG item státusza `✅ done`
+2. Új CHANGELOG entry `[BUG]` típussal, új `CL-` ID-val
+3. `source`: eredeti `BG-` ID
+4. BUG item **törlése** a BUGS.md-ből
+5. BACKLOG-ban eredeti `[BUG]` item status → `✅ done`
+
+---
+
+BUGS.md FORMÁTUM (az `__documentations/BUGS.md` fájlban)
+
+Aktív bug tracking – BACKLOG-ból promote-olt vagy közvetlenül jelentett hibák.
+Részletes formátum: lásd `__specifications/bugs-format.md`
+
+Státusz emoji-k: megegyeznek a TODO.md rendszerrel (bug-specifikus jelentéssel).
+
+Entry formátum:
+```
+- EMOJI (BG-YYYYMMDD-###) Rövid, leíró cím
+  severity: <critical|major|minor|cosmetic>
+  priority: <low|medium|high|urgent>
+  area: <category/sub-area>
+  source: <user|system|assistant|test>
+  details: Egysoros leírás a hibáról, max 120 karakter.
+```
+
+Severity értékek:
+– `critical`: Rendszer használhatatlan, adatvesztés, security
+– `major`: Fő funkció érintett, nincs workaround
+– `minor`: Kisebb probléma, van workaround
+– `cosmetic`: Vizuális hiba, funkció nem érintett
+
+Csoportosítás: `##` heading-ekkel (area / feature szerint).
+
+---
+
+TELJES LIFECYCLE ÖSSZEFOGLALÓ
+
+```
+Új igény      → BACKLOG (intake)
+BACKLOG       → TODO (promote, aktív fejlesztés)
+BACKLOG [BUG] → BUGS (aktív bug tracking)
+TODO ✅       → CHANGELOG (archív) + TODO entry törlés
+BUGS ✅       → CHANGELOG (archív) + BUGS entry törlés + BACKLOG ✅
+```
+
+---
+
+KÖVETELMÉNY KÓD RENDSZER (REQUIREMENT CODE SYSTEM)
+Minden specifikációs követelményhez egyedi kódot kell létrehozni és használni.
+Részletes leírás: [Requirement Code System](./requirement-code-system.md)
+
+1. KÓD FORMÁTUM
+   – Formátum: REQ-{CATEGORY}-{NUMBER}[-{SUBNUMBER}],
+     BUG-{CATEGORY}-{NUMBER}[-{SUBNUMBER}],
+     DEC-{CATEGORY}-{NUMBER}[-{SUBNUMBER}]
+   – Példa: REQ-AGENT-001, REQ-BROWSER-042, REQ-CODE-015-01, REQ-AGENT-001-02
+   – Példa: BUG-AGENT-042, BUG-CODE-015-02
+   – Példa: DEC-AGENT-001 (döntés/kérdés/ellentmondás)
+   – Category: specifikációs fájl neve vagy feature/domain alapján
+     (pl. agent-system.md → AGENT)
+   – Subnumber (opcionális): alkövetelmények azonosításához
+   – Rövid, nagybetűs, aláhúzás nélküli azonosító (max 15 karakter)
+
+2. KÓD LÉTREHOZÁSA ÉS HASZNÁLATA
+   – Minden követelmény és alkövetelmény kap egyedi kódot
+   – Formátum specifikációban:
+     `### Feature Name ✅ [REQ-AGENT-001]` vagy `## Section Name ❌ [REQ-AGENT-002]`
+   – **Blokkonként csak egy kód**: szekciónként/listánként egy feature kód
+   – **Státusz emoji kötelező**: Minden kódhoz tartozik egy státusz emoji:
+     * ✅ (kész): Teljes mértékben implementálva – **CSAK AKKOR**, ha minden implementációs
+       elemnél szerepel a requirement kód, ÉS ellenőriztük és reviewztuk
+     * 🔍 (implemented but not reviewed/not tested): Implementálva, de nincs reviewzva/tesztelve
+     * ❌ (missing): Még nincs implementálva
+     * 🔄 (specifications changed): Specifikáció változott, implementáció nem frissült
+     * ⚠️ (specification incomplete): Specifikáció nem teljes
+     * ❓ (unknown): Ismeretlen státusz (default)
+   – Emoji a kód előtt: `✅ [REQ-AGENT-001]`, `❌ [REQ-AGENT-003]`, stb.
+   – Szekvenciális számozás: minden új követelmény a következő számot kapja
+   – Ugyanaz a követelmény több helyen = ugyanaz a kód
+   – Ne készítsünk indexeket, direktbe használjuk őket
+   – **Eltávolított feature kódok**: script-tel a group feature kódjára írjuk
+
+3. KÓD HASZNÁLATA IMPLEMENTÁCIÓKBAN
+   – Minden implementációban kötelezően hivatkozzunk a követelmény kódjára
+   – Hivatkozás formátumok:
+     `// REQ-AGENT-001: Implementáció`, `@requirement REQ-AGENT-001`,
+     `Implements: REQ-AGENT-001`
+   – A fájl tetején vagy a releváns függvény/class felett szerepeljen a kód
+   – Több követelmény esetén: `// REQ-AGENT-001, REQ-AGENT-001-01: ...`
+   – **KRITIKUS SZABÁLY**: ✅ státusz CSAK akkor kerülhet be, ha MINDEN implementációs elemnél
+     szerepel a requirement kód, ÉS ellenőriztük és reviewztuk az adott requirement-et
+   – DEC kód használata: ellentmondások, kérdések, döntések esetén
+   – DEC kód → kötelezően `__documentations/BUSINESS_QUESTIONS.md`-be is
+
+4. KÓD KARBANTARTÁS
+   – Új követelmény/bug/döntés: új kód generálása szekvenciális számmal
+   – Törölt követelmény/bug/döntés: kódot NEM használjuk újra (archiváljuk)
+   – Módosított követelmény: ugyanazt a kódot használjuk, dokumentáljuk a változást
+   – Refactoring: kódok megmaradnak, csak implementáció változik
+   – Dokumentációkban (CHANGELOG, DECISIONS, TODO, BACKLOG) hivatkozzunk a kódokra
+   – DEC kód → kötelezően `__documentations/BUSINESS_QUESTIONS.md`-be is
+
+---
+
+FELADAT
+Készíts egy részletes, hierarchikus fejlesztési tervet a következő feladathoz
+(próbáljunk meg sorban haladni a pending feladatokon), amely:
+1. Teljes mértékben a specifikációra épül
+2. Figyelembe veszi és beemeli a már elkészült elemeket
+3. Kifejezetten AI-végrehajtásra optimalizált (Cursor-kompatibilis)
+4. Minimalizálja az iterációs hibákat és a kontextusvesztést
+5. Garantálja, hogy minden új lépés kapcsolódik az összes korábbi lépéshez
+6. Minden lépés után kötelezően frissít (update) és dokumentál
+
+A FEJLESZTÉSI TERV SZERKEZETE
+A tervet fázisokra és lépésekre bontva add meg:
+
+TERV FÁJL LOKÁCIÓ
+– A tervet kötelezően egy `*.plan.md` fájlba kell menteni a `__documentations/plans/` mappába
+– Fájlnév formátum: `{sorszam}-{projekt-nev-vagy-cel}.plan.md`
+  (pl. `1.0-agent-system-update.plan.md`, `2.0-feature-x-implementation.plan.md`)
+– **Kötelező sorszámozás**: A fájlnév MINDIG tört szám formátumban kezdődik
+  (pl. 1.0, 1.1, 2.0, 122.0.12)
+– **Verziószámozás szabályok**:
+  – A sorszámozás időben folyamatosan növekszik (1.0, 1.1, 1.2, 2.0, stb.)
+  – A verziószámot egyeztetni kell, ez lesz a projekt verziószáma
+  – **Aktív verzió**: Az elkészült utolsó terv sorszáma
+  – **Review fájlok**: `.rev.md` kiterjesztéssel, az aktív verzióval
+    (pl. `{verzió}-Gap_Analysis.rev.md`)
+  – **Dokumentáció fájl elnevezési konvenciók**:
+    * Dokumentációkhoz: `{verzió}-{Pascal_Snake_Case}.doc.md`
+      (pl. `1.0-Completed_Plan_1_VSCode_Setup.doc.md`)
+    * Review-khoz: `{verzió}-{Pascal_Snake_Case}.rev.md`
+      (pl. `17.0-Gap_Analysis_Project_Agent.rev.md`)
+    * Changelog fájlokhoz: `Changelog_{verzió}.doc.md`
+      (pl. `Changelog_1.0.doc.md`, `Changelog_2.0.doc.md`)
+    * Changelog archív: `Changelog_{verzió}_Archive.doc.md`
+    * Pascal_Snake_Case formátum: szavak nagy betűvel, aláhúzás választja el
+  – **Package.json verzió**: `2.{dokumentációs-verzió}.0` formátum
+    (pl. aktív verzió 17.0 → package.json `2.17.0`)
+  – Új terv létrehozásakor: ellenőrizd a `package.json` verziószámot
+– Ha a mappa nem létezik, létre kell hozni
+
+TERV FÁJL FORMÁTUM
+– Minden PHASE és STEP elején kötelező státusz emoji:
+  * ⏳ (pending): Még nem kezdődött el
+  * 🔄 (in-progress): Jelenleg folyamatban van
+  * ✅ (completed): Befejezve
+  * ❓ (unknown): Ismeretlen státusz (default)
+– A terv végén kötelezően legyen egy "TO-DO LISTA" szekció checkboxokkal
+– Checkboxok: `- [ ] STEP N.M: Rövid leírás` (pending), `- [x] STEP N.M: Leírás` (completed)
+
+PHASE N ⏳
+– Cél (mit old meg ez a fázis a teljes projekt szempontjából)
+– Függőségek (mely korábbi fázisokra/lépésekre épül)
+– Érintett fájlok / modulok
+– Dokumentációs fókusz (mely doc fájlok bővülnek ebben a fázisban)
+– Státusz: ⏳ / 🔄 / ✅ / ❓
+
+STEP N.M ⏳
+– Konkrét végrehajtási feladat (egyetlen jól körülhatárolt művelet)
+– Pontos elvárt kimenet (fájl, funkció, interface, logika)
+– Kapcsolódás:
+  – milyen korábbi lépésekre épít
+  – mit készít elő a következő lépésekhez
+– AI-utasítás stílus: egyértelmű, parancsszerű, félreérthetetlen
+– Érintett fájlok (konkrét útvonalakkal)
+– Módosítás típusa (create/update/refactor)
+– Követelmény kódok: mely REQ-XXX-YYY kódokkal kapcsolatos
+– Előtte olvasd el: `__specifications/technical-specifications.md`
+– Státusz: ⏳ / 🔄 / ✅ / ❓
+
+---
+
+KÖTELEZŐ LÉPÉSVÉGI RUTIN (MINDEN STEP VÉGÉN)
+A STEP végén mindig add meg külön blokkban, ebben a sorrendben:
+
+1) INTEGRITÁS-ELLENŐRZÉS
+– Checklist:
+  – build / futás állapota
+  – típus- és interfész-konzisztencia
+  – logikai összhang a specifikációval
+  – regressziók kizárása
+  – lint/test (ha van)
+– Mit kell az AI-nak ellenőriznie, mielőtt továbblép
+
+2) UPDATE (ÁLLAPOTFRISSÍTÉS)
+– Mit készült el ebben a lépésben (tételesen)
+– Mi változott a korábbiakhoz képest (delta)
+– Nyitott kérdések / kockázatok (ha van)
+– Következő lépés előfeltételei (mit kell igazolni, hogy indulhasson)
+
+3) DOKUMENTÁCIÓ (KÖTELEZŐ, INKREMENTÁLIS)
+– Minden lépés után frissíts/bővíts dokumentációt
+– Dokumentációs szabályok:
+  – rövid, követhető, strukturált
+  – mindig tükrözze az aktuális valós állapotot
+  – minden döntés kapjon 1-2 soros indoklást
+  – a későbbi bővíthetőség legyen explicit
+  – **Ne használj dátumokat a dokumentációkban!** Sorszámozás tört számokkal
+    (pl. 1.0, 1.1, 1.2, 122.0.12)
+  – **Dokumentáció fájl elnevezési konvenciók**:
+    * `{verzió}-{Pascal_Snake_Case}.doc.md` (dokumentáció)
+    * `{verzió}-{Pascal_Snake_Case}.rev.md` (review)
+    * `Changelog_{verzió}.doc.md` (changelog, verziónként külön fájl)
+    * `Changelog_{verzió}_Archive.doc.md` (changelog archív)
+
+– Minimum doc output minden STEP végén:
+  – `__documentations/CHANGELOG.md`
+    (completed item-ek archívuma, max 750 sor, túl hosszúnál → Changelog_{verzió}.doc.md)
+  – `__documentations/BUGS.md`
+    (aktív bug tracking – ha releváns bug változás történt)
+  – `__documentations/ARCHITECTURE.md`
+    (modulok, adatáramlás, felelősségek)
+  – `__documentations/DECISIONS.md`
+    (döntésnapló: mi, miért, alternatívák)
+  – `__documentations/INTEGRITY.md`
+    (mit és hogyan ellenőrzünk rendszeresen)
+  – `__documentations/BUSINESS_QUESTIONS.md`
+    (DEC kódokhoz kapcsolt üzleti kérdések)
+  – `__documentations/dev/{verzió}-{Pascal_Snake_Case}.doc.md`
+    (session-önkénti report)
+  – `__specifications/TODO.md`
+    (aktív feladatok státusz frissítése, TODO formátum szerint)
+  – `__specifications/BACKLOG.md`
+    (intake státusz frissítése, BACKLOG formátum szerint)
+
+– A tervben minden STEP-hez írd le pontosan, mely fájl(ok) frissülnek
+(max line length: 150)
+
+---
+
+VIBE CODING OPTIMALIZÁLÁS
+A terv:
+– kis, egymásra épülő lépésekből álljon
+– kerülje az egyszerre túl sok fájl módosítását
+– preferálja az inkrementális, validálható előrehaladást
+– minden lépés végén legyen integritás + update + dokumentáció
+– minden lépés explicit módon hivatkozzon:
+  – a specifikáció megfelelő pontjára (REQ-XXX-YYY kóddal)
+  – a korábbi lépések releváns kimeneteire
+  – a dokumentáció releváns fejezeteire
+
+VÉGSŐ ÖSSZEGZÉS
+A terv végén készíts:
+– teljes projekt-összefoglalót (architektúra, modulok, adatáramlás)
+– lépés-függőségi térképet (hogyan épül egymásra minden)
+– AI-végrehajtási ajánlást: milyen sorrendben, tempóban érdemes futtatni Cursorban
+– Dokumentációs indexet: mely doc hol van, és melyik lépés írja/bővíti
+– Frissítsd az előrehaladást és a feladatlistát (archiváld a completed elemeket)
+
+TO-DO LISTA
+A terv végén kötelezően legyen egy "TO-DO LISTA" szekció checkboxokkal:
+– Formátum: `- [ ] STEP N.M: Rövid leírás` (pending), `- [x] STEP N.M: Leírás` (completed)
+– A lista tartalmazza az összes PHASE-t és STEP-et hierarchikusan
+– Példa:
+  ```
+  ## TO-DO LISTA
+
+  ### PHASE 1: Alapok
+  - [ ] STEP 1.1: Alapvető struktúra létrehozása
+  - [ ] STEP 1.2: Konfiguráció beállítása
+
+  ### PHASE 2: Implementáció
+  - [ ] STEP 2.1: Fő funkció implementálása
+  - [x] STEP 2.2: Tesztek írása
+  ```
+
+---
+
+KIMENETI FORMA
+– A tervet kötelezően `*.plan.md` fájlba a `__documentations/plans/` mappába
+– Strukturált, jól tagolt markdown
+– Kódot csak ott adj meg, ahol a terv megértéséhez szükséges
+– Nincs felesleges magyarázat, csak végrehajtható precízió
+– Max fájlhossz: 750 sor, max sorhossz: 150 karakter
+  (Ha bármi ennél hosszabb → refaktorálás több fájlba)
+– Minden PHASE és STEP elején kötelező státusz emoji (⏳ / 🔄 / ✅ / ❓)
+– A terv végén kötelezően "TO-DO LISTA" szekció checkboxokkal
+
+---
+
+EMLÉKEZTETŐK (MINDEN STEP-NÉL ELLENŐRIZD)
+(DONT RUN OR COMPILE THE APPLICATION, ask the user to do so)
+– Frissítsd a specifikációkat! (`__specifications/` fájlok)
+– Frissítsd a dokumentációkat! (`__documentations/` fájlok)
+– Használj requirement kódokat! (REQ-XXX-YYY, BUG-XXX-YYY, DEC-XXX-YYY)
+– Verziószámozás dátumok helyett! (1.0, 1.1, 2.0)
+– Fájlelnevezési konvenciók betartása:
+  * `{verzió}-{Pascal_Snake_Case}.doc.md` (dokumentáció)
+  * `{verzió}-{Pascal_Snake_Case}.rev.md` (review)
+  * `Changelog_{verzió}.doc.md` (changelog, verziónként külön)
+  * `Changelog_{verzió}_Archive.doc.md` (changelog archív)
+– TODO/BACKLOG/BUGS/CHANGELOG státuszok frissítése minden releváns STEP végén!
+– Completed TODO/BUG → CHANGELOG archive + eredeti entry törlés!
+
+KÖTELEZŐ REFERENCIA FÁJLOK (minden projektben):
+__specifications/main.md
+__specifications/technical-specifications.md
+__specifications/TODO.md
+__specifications/BACKLOG.md
+__documentations/CHANGELOG.md
+__documentations/BUGS.md
+__documentations/ARCHITECTURE.md
+__documentations/DECISIONS.md
+__documentations/INTEGRITY.md
+__documentations/BUSINESS_QUESTIONS.md

package/.cursor/rules/error_code_pattern.md

@@ -0,0 +1,40 @@
+# Error Code Pattern [FDP-Dev-Error]
+
+## Format
+```
+[PROJ]-[SERV]-[FUNC]
+```
+
+## Components
+- PROJ: 3 character project code
+  - FMP: FDP Master Prompter
+  - CUR: Cursor
+  - DYN: Dynamo
+  - etc.
+- SERV: 3-4 character service code (abbreviated from service name)
+  - DTS: _DataService
+  - CTR: _Controller
+  - SSS: _SocketServerService
+  - SCS: _SocketClientService
+  - EMS: _EmailService
+  - etc.
+- FUNC: 3-4 character function code (derived from function name + index)
+  - NC2: newChange (second throw)
+  - GF1: getFile (first throw)
+  - etc.
+
+## Examples
+- FMP-DTS-NC2: Second error in newChange function of TokenHistory_DataService
+- FMP-CTR-GF1: First error in getFile function of User_Controller
+- CUR-SSS-UP3: Third error in updateProfile function of Chat_SocketServerService
+- DYN-SCS-EM1: First error in sendMessage function of Chat_SocketClientService
+- FMP-EMS-NT1: First error in sendNotification function of Notification_EmailService
+- ASD-SSS-ST0: The function's main try and catch rewrap error point.
+
+## Usage
+- Use in all backend error responses
+- Include in error logs
+- Reference in documentation
+- Keep error codes consistent
+- Document all error codes 
+- All error codes should be unique in the entire system across all projects.

package/.cursor/rules/saved rule mcp server use.md

@@ -0,0 +1,16 @@
+
+Always use the CCAP MCP Server search tools (grep_search, codebase_search) for any code or text search, whenever they are available.
+Only use other search tools if the CCAP MCP Server is unavailable or returns an error.
+If a search is performed with a non-CCAP tool, always explain the reason (e.g., CCAP was not available or failed).
+When both local and CCAP search tools are available, always choose the CCAP MCP Server version.
+If the user asks for a search, always default to the CCAP MCP Server, unless explicitly instructed otherwise.
+If the CCAP MCP Server is temporarily unavailable, notify the user and fall back to the local search tool, but try the CCAP MCP Server again as soon as possible.
+Document in your responses which tool was used for the search, and confirm if it was the CCAP MCP Server.
+If the user wants to change this behavior, only do so if they explicitly request it.
+If you are unsure which tool to use, always ask the user, but default to CCAP MCP Server.
+Always follow all other workspace and user rules in addition to these preferences.
+In addition to the above, before and during any code writing, modification, or implementation, you must always:
+Use the CCAP MCP Server's dedicated tools (related_code_search, related_coding_policy_search) to search for related code examples, existing implementations, and relevant coding policies or guidelines in the workspace and documentation.
+Apply any relevant patterns, examples, or policies found via these tools to ensure consistency and best practices in all new code.
+If no clear example or policy is found, use the closest relevant pattern and document this choice in the development process (e.g., in commit messages or PR descriptions).
+If the CCAP MCP Server or these tools are unavailable, follow the fallback and documentation rules above, and notify the user.