@futdevpro/fsm-dynamo 1.15.2 → 1.15.4

package/.cursor/rules/__main.mdc

@@ -15,6 +15,7 @@ Always follow patterns of existing projects! (tech stack, naming, codes, everyth
 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.
@@ -51,7 +52,8 @@ my common requirements:
 - 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) 
+- 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

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

@@ -3,100 +3,310 @@ description: When creating plans, reviews, finishing implementations, updating s
 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.
+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}]
+   – 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 (pl. REQ-AGENT-001-01, REQ-AGENT-001-02)
+   – 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**: A specifikációkban blokkonként (szekciónként, listánként) csak egy feature kód jelenik meg, nem minden sornál
+   – 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): A követelmény/bug/döntés teljes mértékben implementálva van - **CSAK AKKOR**, ha minden implementációs elemnél (fájl, függvény, class, stb.) szerepel a requirement kód (a specifikációs és a requirement kód is), ÉS ellenőriztük és alaposan reviewztuk az adott requirement-et. Ellenőrizni kell, hogy minden implementációs elem tartalmazza-e a megfelelő requirement kód hivatkozást (pl. `// REQ-AGENT-001`, `@requirement REQ-AGENT-001`, `Implements: REQ-AGENT-001`), valamint alaposan át kell nézni és reviewzni az implementációt, hogy valóban teljes mértékben megfelel-e a specifikációnak
-     * 🔍 (implemented but not reviewed/not tested): A követelmény/bug/döntés implementálva van, de még nincs reviewzva vagy tesztelve. Az implementáció elkészült, de még nem történt meg az ellenőrzés és a tesztelés
-     * ❌ (missing): A követelmény/bug/döntés még nincs implementálva
-     * 🔄 (specifications changed): A specifikációban változtatás történt, de az implementáció még nem frissült
-     * ⚠️ (specification incomplete): A specifikáció nem teljes - például teszteseteknél kifejtésre vár az összes létező teszteset, vagy más specifikációs elemek hiányoznak/kifejtésre várnak
-     * ❓ (unknown): Ismeretlen státusz. (default)
-   – Az emoji a kód előtt jelenik meg: `✅ [REQ-AGENT-001]` vagy `🔍 [REQ-AGENT-002]` vagy `❌ [REQ-AGENT-003]` vagy `🔄 [REQ-AGENT-004]` vagy `⚠️ [REQ-AGENT-005]` vagy `❓ [REQ-AGENT-006]`
+     * ✅ (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 is előfordulhat, de ugyanazt a kódot használja
+   – 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**: Ha egy feature kódot eltávolítunk, azt script-tel át kell írni a group feature kódjára
+   – **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`
+   – 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**: A ✅ (kész) státusz csak akkor kerülhet be a specifikációban, ha MINDEN implementációs elemnél (fájl, függvény, class, modul, stb.) szerepel a requirement kód hivatkozás, ÉS ellenőriztük és alaposan reviewztuk az adott requirement-et. Ellenőrizni kell, hogy minden implementációs elem tartalmazza-e a megfelelő requirement kódot, valamint alaposan át kell nézni és reviewzni az implementációt, hogy valóban teljes mértékben megfelel-e a specifikációnak, mielőtt a ✅ státuszt beállítjuk.
-   – DEC kód használata: ellentmondások, kérdések, döntések esetén (pl. implementáció vs specifikáció eltérés, duplikált implementáció, üzleti/technikai döntés szükséges)
-   – Ha bármilyen kérdés merül fel (DEC kód), akkor az kötelezően kerüljön bele az üzleti kérdések dokumentációjába is (__documentations/BUSINESS_QUESTIONS.md vagy hasonló)
+   – **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, MISSING_FEATURES, NEXT_STEPS) hivatkozzunk a kódokra
-   – Ha bármilyen kérdés merül fel (DEC kód), akkor az kötelezően kerüljön bele az üzleti kérdések dokumentációjába is
+   – 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:
+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, és ezt a dokumentációt a következő lépések aktívan használják és bővítik
+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`, `122.0.12-spec-code-integration.plan.md`)
-– **Kötelező sorszámozás**: A fájlnév MINDIG sorszámmal kezdődik tört szám formátumban (pl. 1.0, 1.1, 2.0, 122.0.12), hogy követhető legyen a sorrend és hierarchia
+– 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 aktív verzió mindig az elkészült utolsó terv sorszáma
-  – **Review fájlok**: Minden review fájl (gap-analysis, status report, stb.) ugyanezzel a verziószámozással készül, mindig az aktív verzióval, és `.rev.md` kiterjesztéssel (pl. `{aktív-verzió}-Gap_Analysis_Project_Agent.rev.md`, `{aktív-verzió}-Phase_26_Status_Report.rev.md`)
+  – **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` formátum (pl. `1.0-Completed_Plan_1_VSCode_Setup.doc.md`)
-    * Review-khoz: `{verzió}-{Pascal_Snake_Case}.rev.md` formátum (pl. `17.0-Gap_Analysis_Project_Agent.rev.md`)
-    * Changelog fájlokhoz: `Changelog_{verzió}.doc.md` formátum (pl. `Changelog_1.0.doc.md`, `Changelog_2.0.doc.md`)
-    * Changelog archív fájlokhoz: `Changelog_{verzió}_Archive.doc.md` formátum (pl. `Changelog_12.0_Archive.doc.md`)
-    * A "Changelog" mindig nagy betűkkel, előre kerül, majd a verziószám
-    * Changelog fájlok verziónként külön fájlokban vannak (felosztva, hogy ne legyenek túl hosszúak)
-    * Pascal_Snake_Case formátum: szavak nagy betűvel kezdődnek, aláhúzás választja el őket (pl. `Completed_Plan_1_VSCode_Setup`)
-  – **Package.json verzió**: A verziószámot a `package.json` fájlban is vezetni kell, és a `2.{dokumentációs-verzió}.0` formátumot használja, ahol a dokumentációs verzió az aktív verzió (pl. ha az aktív verzió 17.0, akkor a package.json verzió `2.17.0`)
-  – Új terv létrehozásakor: Ellenőrizd a `package.json`-ben lévő verziószámot, és az aktív verzió alapján add meg az új terv sorszámát
+    * 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 / Megváltozott specifikáció még nincs implementálva.
+  * 🔄 (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, amely tartalmazza az összes STEP-et
-– A checkboxok formátuma: `- [ ] STEP N.M: Rövid leírás` (pending), `- [x] STEP N.M: Rövid leírás` (completed)
+  * ❓ (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)
@@ -114,11 +324,11 @@ STEP N.M ⏳
 – 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 ez a lépés
-  (ha új követelményt implementálunk, generáljunk kódot; ha meglévőt, használjuk a kódot)
-- Amikor kódokat készítünk előtte mindig olvasd el a technikai specifikációt. hogy alkalmazhasd a fejlesztési szabályokat. (__specifications/technical-specifications.md)
+– 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:
@@ -139,33 +349,45 @@ A STEP végén mindig add meg külön blokkban, ebben a sorrendben:
 – 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 úgy, hogy a következő lépések abból dolgozzanak
+– 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 (mire számítunk később)
-  – **Ne használj dátumokat a dokumentációkban!** Helyette mindig sorszámozást használj tört számokkal (pl. 1.0, 1.1, 1.2, 122.0.12), hogy könnyebben tudjunk sub-elemeket létrehozni és a dokumentációk strukturáltak maradjanak
+  – 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**:
-    * Dokumentációkhoz: `{verzió}-{Pascal_Snake_Case}.doc.md` formátum (pl. `1.0-Completed_Plan_1_VSCode_Setup.doc.md`)
-    * Review-khoz: `{verzió}-{Pascal_Snake_Case}.rev.md` formátum (pl. `17.0-Gap_Analysis_Project_Agent.rev.md`)
-    * Changelog fájlokhoz: `Changelog_{verzió}.doc.md` formátum (pl. `Changelog_1.0.doc.md`, `Changelog_2.0.doc.md`)
-    * Changelog archív fájlokhoz: `Changelog_{verzió}_Archive.doc.md` formátum (pl. `Changelog_12.0_Archive.doc.md`)
-    * A "Changelog" mindig nagy betűkkel, előre kerül, majd a verziószám
-    * Changelog fájlok verziónként külön fájlokban vannak (felosztva, hogy ne legyenek túl hosszúak)
-    * Pascal_Snake_Case formátum: szavak nagy betűvel kezdődnek, aláhúzás választja el őket (pl. `Completed_Plan_1_VSCode_Setup`)
+    * `{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 (lépésenkénti változásnapló, sorszámozva tört számokkal pl. 1.0, 1.1, 2.0, if longer than 750 rows, archive completed elements to Changelog_{verzió}.doc.md files)
-  – /__documentations/ARCHITECTURE.md (modulok, adatáramlás, felelősségek, sorszámozva tört számokkal)
-  – /__documentations/DECISIONS.md (rövid döntésnapló: mi, miért, alternatívák, sorszámozva tört számokkal pl. 1.0, 1.1, 2.0)
-  – /__documentations/INTEGRITY.md (mit és hogyan ellenőrzünk rendszeresen, sorszámozva tört számokkal)
-  – /__documentations/MISSING_FEATURES.md (update statuses, sorszámozva tört számokkal, if longer than 750 rows, archive completed elements)
-  – /__documentations/NEXT_SPTEPS.md (update statuses, sorszámozva tört számokkal, if longer than 750 rows, archive completed elements, shorten into /__documentationsCOMPLETED_STEPS.md)
-  – /__documentations/BUSINESS_QUESTIONS.md (ha bármilyen kérdés merül fel - DEC kód, akkor kötelezően ide is kerüljön, sorszámozva tört számokkal)
-  – /__documentations/developments/{verzió}-{Pascal_Snake_Case}.md (session-önkénti report, verziószám mindig a session name előtt, pl. 1.0-Session_Implementation.md, 1.1-Session_Spec_Creation.md, 2.0-Session_Feature_Update.md)
-– A tervben minden STEP-hez írd le pontosan, mely doc fájl(ok) frissülnek és milyen új sorok/fejezetek kerülnek bele
+  – `__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
@@ -181,49 +403,63 @@ 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, milyen tempóban érdemes futtatni Cursorban
+– 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
-- Dokumentáljunk és update-eljük az előre haladást és a feladatlistát. (archiváljuk a completed és túl hosszú elemeket)
+– 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ó, amely tartalmazza az összes STEP-et checkbox formátumban:
-– Formátum: `- [ ] STEP N.M: Rövid leírás` (pending) vagy `- [x] STEP N.M: Rövid leírás` (completed)
+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 egy `*.plan.md` fájlba kell menteni a `__documentations/plans/` mappába
+– 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 az a terv megértéséhez szükséges
+– 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ó
-– Semmilyen file ne legyen hosszabb, mint 750 sor és soronként 150 karakter. (Amennyiben bármi ennél hosszabb, azt refaktorálnunk kell több külön fájlá.)
+– 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 legyen egy "TO-DO LISTA" szekció checkboxokkal
+– 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!
 
-(DONT RUN OR COMPLIE THE APPLICATION, ask the user to do so)
-Never forget to update the specifications!
-Never forget to update the documentations!
-Never forget to create and use requirement codes (REQ-XXX-YYY, BUG-XXX-YYY, DEC-XXX-YYY) in both specifications and implementations!
-Never forget: Use version numbers (1.0, 1.1, 2.0) instead of dates in documentation files!
-Never forget: Follow the documentation file naming conventions:
-  - Documentation files: {verzió}-{Pascal_Snake_Case}.doc.md (e.g., 1.0-Completed_Plan_1_VSCode_Setup.doc.md)
-  - Review files: {verzió}-{Pascal_Snake_Case}.rev.md (e.g., 17.0-Gap_Analysis_Project_Agent.rev.md)
-  - Changelog files: Changelog_{verzió}.doc.md (e.g., Changelog_1.0.doc.md, Changelog_2.0.doc.md)
-  - Changelog archive files: Changelog_{verzió}_Archive.doc.md (e.g., Changelog_12.0_Archive.doc.md)
-  - Changelog files are split by version to keep them manageable (not too long)
-
-__documentations/MISSING_FEATURES.md 
-__documentations/NEXT_STEPS.md 
-__specifications/main.md 
-__specifications/technical-specifications.md
+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/build/_models/control-models/data-property-params.control-model.js

@@ -86,7 +86,7 @@ class DyFM_DataProperty_Params extends DyFM_DataProperty_Settings {
         super();
         if (set) {
             if (!set.type && !set.forbidden) {
-                log_util_1.DyFM_Log.error('DYNAMO ERROR: ', `\n type is missing from DynamoBEDataPropertyParams at "${set.key}" in ` +
+                log_util_1.DyFM_Log.error('DYNAMO ERROR: ', `\n type is missing from DynamoNTSDataPropertyParams at "${set.key}" in ` +
                     `"${parentDataParams?.dataName}" model.` +
                     `\n stackLocation: ${(0, stack_util_1.DyFM_getConstructionStackLocation)(2)}`);
             }
@@ -123,7 +123,7 @@ class DyFM_DataProperty_Params extends DyFM_DataProperty_Settings {
             Object.assign(this, set);
         }
         else {
-            log_util_1.DyFM_Log.error('DYNAMO ERROR: ', `\nMISSING DynamoBEDataPropertyParams constructor input at "${this.key}"!` +
+            log_util_1.DyFM_Log.error('DYNAMO ERROR: ', `\nMISSING DynamoNTSDataPropertyParams constructor input at "${this.key}"!` +
                 `\n stackLocation: ${(0, stack_util_1.DyFM_getConstructionStackLocation)(2)}`);
         }
     }

package/build/_models/control-models/data-property-params.control-model.js.map

@@ -1 +1 @@
-{"version":3,"file":"data-property-params.control-model.js","sourceRoot":"","sources":["../../../src/_models/control-models/data-property-params.control-model.ts"],"names":[],"mappings":";;;AAAA,gEAA6D;AAC7D,oEAAwF;AACxF,oFAAgF;AAQhF,qFAAqF;AAErF,MAAa,0BAA0B;IACrC,GAAG,CAAU;IACb,IAAI,CAAoC;IACxC,YAAY,CAAU;IACtB,OAAO,CAAc;IAErB,MAAM,CAAW;IACjB,QAAQ,CAAW;IACnB,QAAQ,CAAW;IACnB,KAAK,CAAW;IAChB,SAAS,CAAW;IAEpB,iCAAiC;IACjC;;;;;;;OAOG;IACH,kBAAkB,CAAU;IAC5B,WAAW,CAAW;IACtB,gBAAgB,CAAU;IAE1B;;;;;OAKG;IACH,cAAc,CAAY;IAC1B,2BAA2B;IAC3B,cAAc,CAAU,CAAC,2BAA2B;IACpD;;OAEG;IACH,eAAe,CAAW;IAC1B;;;;;;;;;;;;;;;;OAgBG;IACH,iBAAiB,CAAU;IAE3B,SAAS,CAAU;IACnB,SAAS,CAAU;IAEnB,eAAe,CAA4B;IAE3C,oBAAoB,CAAyD;CAC9E;AA/DD,gEA+DC;AAGD;6DAC6D;AAC7D;;;;;;;;;;;GAWG;AACH,MAAa,wBAA6C,SAAQ,0BAA8C;IAE9G,mEAAmE;IACnE,0DAA0D;IAEjD,oBAAoB,GAA2D,EAAE,CAAC;IAE3F,YACE,GAAmD,EACnD,gBAA6C;QAE7C,KAAK,EAAE,CAAC;QAER,IAAI,GAAG,EAAE,CAAC;YACR,IAAI,CAAC,GAAG,CAAC,IAAI,IAAI,CAAC,GAAG,CAAC,SAAS,EAAE,CAAC;gBAChC,mBAAQ,CAAC,KAAK,CACZ,gBAAgB,EAChB,0DAA0D,GAAG,CAAC,GAAG,OAAO;oBACtE,IAAI,gBAAgB,EAAE,QAAQ,UAAU;oBAC1C,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;YACJ,CAAC;YAED,IAAI,GAAG,CAAC,kBAAkB,EAAE,CAAC;gBAC3B,IAAI,GAAG,CAAC,QAAQ,KAAK,KAAK,EAAE,CAAC;oBAC3B,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,uEAAuE,GAAG,CAAC,GAAG,OAAO;wBACrF,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBACxC,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;gBACJ,CAAC;qBAAM,IAAI,GAAG,CAAC,QAAQ,KAAK,SAAS,EAAE,CAAC;oBACtC,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,iEAAiE,GAAG,CAAC,GAAG,OAAO;wBAC7E,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBAC1C,iDAAiD;wBACjD,6DAA6D;wBAC7D,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBACF,GAAG,CAAC,QAAQ,GAAG,IAAI,CAAC;gBACtB,CAAC;YACH,CAAC;YAED,IAAI,GAAG,CAAC,cAAc,EAAE,CAAC;gBACvB,IAAI,GAAG,CAAC,KAAK,EAAE,CAAC;oBACd,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,kFAAkF,GAAG,CAAC,GAAG,OAAO;wBAC9F,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBAC1C,8DAA8D;wBAC9D,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBAEF,GAAG,CAAC,KAAK,GAAG,KAAK,CAAC;gBACpB,CAAC;gBAED,IAAI,CAAC,GAAG,CAAC,iBAAiB,EAAE,CAAC;oBAC3B,mBAAQ,CAAC,MAAM,CACb,kBAAkB,EAClB,iEAAiE,GAAG,CAAC,GAAG,OAAO;wBAC7E,IAAI,gBAAgB,EAAE,QAAQ,gCAAgC,GAAG,CAAC,GAAG,eAAe;wBACtF,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBACF,GAAG,CAAC,iBAAiB,GAAG,GAAG,CAAC,GAAG,CAAC;gBAClC,CAAC;YACH,CAAC;YAED,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC;QAC3B,CAAC;aAAM,CAAC;YACN,mBAAQ,CAAC,KAAK,CACZ,gBAAgB,EAChB,8DAA8D,IAAI,CAAC,GAAG,IAAI;gBAC1E,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;QACJ,CAAC;IACH,CAAC;IAED,WAAW;QACT,OAAO,IAAI,CAAC;IACd,CAAC;IAED,sCAAsC;IACtC,SAAS;QACP,QAAQ,IAAI,CAAC,IAAI,EAAE,CAAC;YAClB,KAAK,kDAAuB,CAAC,MAAM;gBACjC,OAAO,MAAM,CAAC;YAEhB,KAAK,kDAAuB,CAAC,MAAM;gBACjC,OAAO,MAAM,CAAC;YAEhB,KAAK,kDAAuB,CAAC,OAAO;gBAClC,OAAO,OAAO,CAAC;YAEjB,KAAK,kDAAuB,CAAC,IAAI;gBAC/B,OAAO,IAAI,CAAC;YAEd,KAAK,kDAAuB,CAAC,MAAM,CAAC;YACpC;gBACE,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,IAAI,CAAC,EAAE,CAAC;oBAC9B,OAAO,KAAK,CAAC;gBACf,CAAC;qBAAM,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,IAAI,CAAC,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,UAAU,CAAC,EAAE,CAAC;oBACxE,OAAO,QAAQ,CAAC;gBAClB,CAAC;qBAAM,CAAC;oBACN,OAAO,MAAM,CAAC;gBAChB,CAAC;QACL,CAAC;IACH,CAAC;CACF;AA5GD,4DA4GC"}
+{"version":3,"file":"data-property-params.control-model.js","sourceRoot":"","sources":["../../../src/_models/control-models/data-property-params.control-model.ts"],"names":[],"mappings":";;;AAAA,gEAA6D;AAC7D,oEAAwF;AACxF,oFAAgF;AAQhF,qFAAqF;AAErF,MAAa,0BAA0B;IACrC,GAAG,CAAU;IACb,IAAI,CAAoC;IACxC,YAAY,CAAU;IACtB,OAAO,CAAc;IAErB,MAAM,CAAW;IACjB,QAAQ,CAAW;IACnB,QAAQ,CAAW;IACnB,KAAK,CAAW;IAChB,SAAS,CAAW;IAEpB,iCAAiC;IACjC;;;;;;;OAOG;IACH,kBAAkB,CAAU;IAC5B,WAAW,CAAW;IACtB,gBAAgB,CAAU;IAE1B;;;;;OAKG;IACH,cAAc,CAAY;IAC1B,2BAA2B;IAC3B,cAAc,CAAU,CAAC,2BAA2B;IACpD;;OAEG;IACH,eAAe,CAAW;IAC1B;;;;;;;;;;;;;;;;OAgBG;IACH,iBAAiB,CAAU;IAE3B,SAAS,CAAU;IACnB,SAAS,CAAU;IAEnB,eAAe,CAA4B;IAE3C,oBAAoB,CAAyD;CAC9E;AA/DD,gEA+DC;AAGD;6DAC6D;AAC7D;;;;;;;;;;;GAWG;AACH,MAAa,wBAA6C,SAAQ,0BAA8C;IAE9G,mEAAmE;IACnE,0DAA0D;IAEjD,oBAAoB,GAA2D,EAAE,CAAC;IAE3F,YACE,GAAmD,EACnD,gBAA6C;QAE7C,KAAK,EAAE,CAAC;QAER,IAAI,GAAG,EAAE,CAAC;YACR,IAAI,CAAC,GAAG,CAAC,IAAI,IAAI,CAAC,GAAG,CAAC,SAAS,EAAE,CAAC;gBAChC,mBAAQ,CAAC,KAAK,CACZ,gBAAgB,EAChB,2DAA2D,GAAG,CAAC,GAAG,OAAO;oBACvE,IAAI,gBAAgB,EAAE,QAAQ,UAAU;oBAC1C,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;YACJ,CAAC;YAED,IAAI,GAAG,CAAC,kBAAkB,EAAE,CAAC;gBAC3B,IAAI,GAAG,CAAC,QAAQ,KAAK,KAAK,EAAE,CAAC;oBAC3B,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,uEAAuE,GAAG,CAAC,GAAG,OAAO;wBACrF,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBACxC,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;gBACJ,CAAC;qBAAM,IAAI,GAAG,CAAC,QAAQ,KAAK,SAAS,EAAE,CAAC;oBACtC,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,iEAAiE,GAAG,CAAC,GAAG,OAAO;wBAC7E,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBAC1C,iDAAiD;wBACjD,6DAA6D;wBAC7D,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBACF,GAAG,CAAC,QAAQ,GAAG,IAAI,CAAC;gBACtB,CAAC;YACH,CAAC;YAED,IAAI,GAAG,CAAC,cAAc,EAAE,CAAC;gBACvB,IAAI,GAAG,CAAC,KAAK,EAAE,CAAC;oBACd,mBAAQ,CAAC,IAAI,CACX,kBAAkB,EAClB,kFAAkF,GAAG,CAAC,GAAG,OAAO;wBAC9F,IAAI,gBAAgB,EAAE,QAAQ,UAAU;wBAC1C,8DAA8D;wBAC9D,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBAEF,GAAG,CAAC,KAAK,GAAG,KAAK,CAAC;gBACpB,CAAC;gBAED,IAAI,CAAC,GAAG,CAAC,iBAAiB,EAAE,CAAC;oBAC3B,mBAAQ,CAAC,MAAM,CACb,kBAAkB,EAClB,iEAAiE,GAAG,CAAC,GAAG,OAAO;wBAC7E,IAAI,gBAAgB,EAAE,QAAQ,gCAAgC,GAAG,CAAC,GAAG,eAAe;wBACtF,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;oBACF,GAAG,CAAC,iBAAiB,GAAG,GAAG,CAAC,GAAG,CAAC;gBAClC,CAAC;YACH,CAAC;YAED,MAAM,CAAC,MAAM,CAAC,IAAI,EAAE,GAAG,CAAC,CAAC;QAC3B,CAAC;aAAM,CAAC;YACN,mBAAQ,CAAC,KAAK,CACZ,gBAAgB,EAChB,+DAA+D,IAAI,CAAC,GAAG,IAAI;gBAC3E,qBAAqB,IAAA,8CAAiC,EAAC,CAAC,CAAC,EAAE,CAC5D,CAAC;QACJ,CAAC;IACH,CAAC;IAED,WAAW;QACT,OAAO,IAAI,CAAC;IACd,CAAC;IAED,sCAAsC;IACtC,SAAS;QACP,QAAQ,IAAI,CAAC,IAAI,EAAE,CAAC;YAClB,KAAK,kDAAuB,CAAC,MAAM;gBACjC,OAAO,MAAM,CAAC;YAEhB,KAAK,kDAAuB,CAAC,MAAM;gBACjC,OAAO,MAAM,CAAC;YAEhB,KAAK,kDAAuB,CAAC,OAAO;gBAClC,OAAO,OAAO,CAAC;YAEjB,KAAK,kDAAuB,CAAC,IAAI;gBAC/B,OAAO,IAAI,CAAC;YAEd,KAAK,kDAAuB,CAAC,MAAM,CAAC;YACpC;gBACE,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,IAAI,CAAC,EAAE,CAAC;oBAC9B,OAAO,KAAK,CAAC;gBACf,CAAC;qBAAM,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,IAAI,CAAC,IAAI,IAAI,CAAC,IAAI,EAAE,QAAQ,CAAC,UAAU,CAAC,EAAE,CAAC;oBACxE,OAAO,QAAQ,CAAC;gBAClB,CAAC;qBAAM,CAAC;oBACN,OAAO,MAAM,CAAC;gBAChB,CAAC;QACL,CAAC;IACH,CAAC;CACF;AA5GD,4DA4GC"}

package/build/_modules/ai/_collections/ai-model-ref.util.d.ts

@@ -0,0 +1,43 @@
+import { DyFM_AI_Provider } from '../_enums/ai-provider.enum';
+/**
+ * AI modell hivatkozas formatum: {provider}:{model}
+ *
+ * Peldak: "open-ai:gpt-4o", "anthropic:claude-3-5-sonnet-latest", "fdp-ai:fdp-base-1"
+ * A provider resz a DyFM_AI_Provider enum erteke, a model resz a provider sajat modell azonositoja.
+ */
+export declare class DyFM_AI_ModelRef_Util {
+    /** az elvlaszto karakter a provider es modell kozott */
+    private static readonly separator;
+    /** az osszes ervenyes provider ertek gyorstarhely */
+    private static readonly validProviders;
+    /**
+     * Osszeallitas provider + model -bol
+     * @param provider - AI provider enum ertek
+     * @param model - provider-specifikus modell azonosito
+     */
+    static create(provider: DyFM_AI_Provider, model: string): string;
+    /**
+     * Szetbontas provider + model -re
+     * @param modelRef - formatum: {provider}:{model}
+     */
+    static parse(modelRef: string): {
+        provider: DyFM_AI_Provider;
+        model: string;
+    };
+    /**
+     * Provider kinyerese a modelRef-bol
+     * @param modelRef - formatum: {provider}:{model}
+     */
+    static getProvider(modelRef: string): DyFM_AI_Provider;
+    /**
+     * Model kinyerese a modelRef-bol
+     * @param modelRef - formatum: {provider}:{model}
+     */
+    static getModel(modelRef: string): string;
+    /**
+     * Validalas -- ellenorzi, hogy a modelRef megfelel-e a {provider}:{model} formatumnak
+     * @param modelRef - a vizsgalando string
+     */
+    static isValid(modelRef: string): boolean;
+}
+//# sourceMappingURL=ai-model-ref.util.d.ts.map

package/build/_modules/ai/_collections/ai-model-ref.util.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"ai-model-ref.util.d.ts","sourceRoot":"","sources":["../../../../src/_modules/ai/_collections/ai-model-ref.util.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,gBAAgB,EAAE,MAAM,4BAA4B,CAAC;AAE9D;;;;;GAKG;AACH,qBAAa,qBAAqB;IAChC,wDAAwD;IACxD,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,SAAS,CAAe;IAEhD,qDAAqD;IACrD,OAAO,CAAC,MAAM,CAAC,QAAQ,CAAC,cAAc,CAEpC;IAEF;;;;OAIG;IACH,MAAM,CAAC,MAAM,CAAC,QAAQ,EAAE,gBAAgB,EAAE,KAAK,EAAE,MAAM,GAAG,MAAM;IAIhE;;;OAGG;IACH,MAAM,CAAC,KAAK,CAAC,QAAQ,EAAE,MAAM,GAAG;QAAE,QAAQ,EAAE,gBAAgB,CAAC;QAAC,KAAK,EAAE,MAAM,CAAA;KAAE;IAqB7E;;;OAGG;IACH,MAAM,CAAC,WAAW,CAAC,QAAQ,EAAE,MAAM,GAAG,gBAAgB;IAItD;;;OAGG;IACH,MAAM,CAAC,QAAQ,CAAC,QAAQ,EAAE,MAAM,GAAG,MAAM;IAIzC;;;OAGG;IACH,MAAM,CAAC,OAAO,CAAC,QAAQ,EAAE,MAAM,GAAG,OAAO;CAgB1C"}