@futdevpro/nts-dynamo 1.15.157 → 1.15.160

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

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

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

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