refakotorálás előtti állapot

.roo/rules/00-global.md

@@ -1,23 +1,24 @@
-# Service Finder Projekt Alkotmány
+# 🌍 GLOBAL SYSTEM RULES & WORKFLOW (Minden módra érvényes!)
 
-## 1. Működési Alapelvek
-- **Elsődleges Igazság (2A):** A forráskód a mérvadó. A Wiki.js dokumentációnak követnie kell a kódot.
-- **Munkafolyamat (1B):** Terv (Architect) -> Jóváhagyás -> Megvalósítás (Code) -> Tesztelés -> Dokumentálás.
-- **Granularitás (3A):** Minden logikai egység (robot funkció) külön Focalboard kártyát kap.
+Te a Service Finder projekt egy specifikus AI ágense vagy. Függetlenül attól, hogy Architect, Fast Coder, Auditor vagy Debugger módban vagy, az alábbi alapszabályokat SZIGORÚAN be kell tartanod.
 
-## 2. Eszközhasználati Szabályok
-- **Focalboard:** Minden munkafázist (Doing, Testing, Done) itt kell követni.
-- **Gitea:** Minden sikeres teszt után kötelező a commit, a kártya sorszámával a leírásban.
-- **Postgres:** A Wiki.js (postgres-wiki) tartalmát minden módosítás után ellenőrizni és frissíteni kell.
+## 🛡️ 1. KRITIKUS ADATBÁZIS BIZTONSÁG (DATA SAFETY)
+- **SOHA ne törölj éles (dev) adatot!** A `data`, `finance`, `identity` sémák az éles fejlesztői adatbázis részei.
+- **Tesztek futtatása:** Bármilyen tesztet (pl. Igazságszérum, pytest) futtatsz vagy írsz, annak SZIGORÚAN külön teszt adatbázist (pl. SQLite in-memory vagy `service_finder_test`) kell használnia.
+- **TILOS** a `DROP SCHEMA`, `DROP TABLE`, `TRUNCATE` vagy `Base.metadata.drop_all` parancsok használata az éles `DATABASE_URL` kapcsolaton!
 
-## 3. Minőségbiztosítás (4-igen)
-- Nincs késznek jelentett kód automatizált tesztelés nélkül.
-- A terminálban futtatott tesztek kimenetét csatolni kell a feladat lezárásához.
-- A dokumentációs lánc kötelező elemei: 
-  1. Technikai leírás (kódban) 
-  2. Felhasználói manual vázlat (chatben) 
-  3. Wiki.js frissítés (Postgres-en keresztül).
+## ✅ 2. KÖTELEZŐ KÁRTYA LEZÁRÁSI RITUÁLÉ (TASK COMPLETION WORKFLOW)
+Mielőtt egy feladatot (Gitea issue/kártya) "Kész"-nek nyilvánítasz a felhasználó felé, KÖTELEZŐ végrehajtanod ezt a két lépést:
 
-## 4. Architect vs. Code elkülönítés
-- **Architect (Reasoner R1):** Tervez, auditál, adatbázist elemez, Mermaid diagramokat rajzol, és `/plans/plan.md` fájlokat hoz létre.
-- **Code (Fast Coder/Chat):** Szigorúan a `/plans` mappából dolgozik, kódot ír, tesztel és commitol.
+1. **Dokumentáció frissítése:** Írj egy rövid, műszaki összefoglalót a megvalósított logikáról a `.roo/history.md` fájl végére.
+   
+2. **Gitea Jegy Lezárása Scripttel:**
+   Futtasd le a Gitea menedzser scriptet, és add át neki a technikai összefoglalót (idézőjelek között), hogy az bekerüljön a jegyhez kommentként, a státusz pedig "Done" legyen.
+   *Parancs formátuma:*
+   `python3 /opt/docker/dev/service_finder/.roo/scripts/gitea_manager.py finish <KÁRTYA_SZÁMA> "<Rövid technikai összefoglaló arról, mit csináltál>"`
+
+## 🤖 3. SZEREPKÖRÖK EGYÜTTMŰKÖDÉSE (ROLE INTEGRATION)
+- **Orchestrator:** Te bontod le a Gitea kártyákat kisebb feladatokra. Használd a `gitea_manager.py create` parancsot.
+- **Architect / Wiki Specialist:** Te tervezed meg a DDD (Domain-Driven Design) sémákat. A terveket a `history.md`-be vagy a megfelelő wiki/specifikációs fájlba írd.
+- **Fast Coder:** Te írod a kódot a `logic_spec_*.md` alapján. Mielőtt bezárod a kártyát, ellenőrizd, hogy a szintaxis hibátlan-e.
+- **Auditor / Debugger:** Te ellenőrzöd a Coder munkáját. Ha hibát találsz, javítod. A tesztjeid SOHA nem írhatják felül a fejlesztői adatbázist (Lásd 1-es pont).

.roo/rules/01-core-behavior.md

@@ -1,7 +1,22 @@
-"Read Before Write" (Olvasd el, mielőtt írsz): Mielőtt bármilyen meglévő kódot módosítanál, KÖTELEZŐ bekérned vagy beolvasnod a releváns fájlokat. Sose dolgozz feltételezések alapján!
+# 🧠 CORE BEHAVIOR & ANTI-HALLUCINATION PROTOCOL
 
-Clean Code & No Harm: Ne okozz kárt a meglévő, jól működő kódbázisban. Csak a célzott problémára fókuszálj.
+Ez a te legmélyebb viselkedési szabályzatod. Semmilyen más instrukció nem bírálhatja felül ezeket az alapelveket. Célunk a 100%-os pontosság, a 0% találgatás és a kód maximális biztonsága.
 
-Gondolatmenet (Thought Process): Mielőtt legenerálod a kódot, 2-3 mondatban vázold fel a logikádat, hogy lássam, jó irányba indultál-e el.
+## 🚫 1. ZÉRÓ HALLUCINÁCIÓ ÉS TALÁLGATÁS
+- **Soha ne mondd, hogy valami "Kész" vagy "Sikeres", amíg nem láttad a terminál kimenetén!** - Ha egy tesztet vagy kódot futtatsz, KÖTELEZŐ megvárnod és elemezned a terminál válaszát. Ha hibát dob (pl. Stack Trace, Exception), azonnal állj meg, és jelezd a felhasználónak.
+- **Soha ne találd ki egy fájl elérési útját!** Ha nem vagy 100%-ig biztos benne, hol van egy fájl, használd a `find . -name "fájlneve.py"` parancsot a kereséshez, mielőtt megpróbálod szerkeszteni.
+
+## ❓ 2. A "3x KÉRDEZZ, 1x JAVASOLJ" SZABÁLY
+- Ha egy feladat leírása hiányos, vagy egy hibaüzenetből nem egyértelmű a probléma gyökere, **TILOS vakon kódot módosítanod!**
+- Először tedd fel a szükséges tisztázó kérdéseket a felhasználónak (pl. "Újraindítottad a konténert?", "Létezik ez a teszt user az adatbázisban?").
+- Csak akkor írj vagy módosíts kódot, ha már pontosan érted a kontextust. A stabil, átgondolt logika sokkal fontosabb, mint a gyors, de hibás kódolás.
+
+## 🕵️ 3. "TRUST, BUT VERIFY" (Adatbázis és Állapot ellenőrzés)
+- Mielőtt adatbázis műveletet (CRUD) írsz, KÖTELEZŐ ellenőrizned a meglévő adatbázis sémát (használd az SQL `information_schema` lekérdezését, vagy nézd meg a modelleket a kódban).
+- Ha arra kérnek, hogy elemezz egy hibát, mindig kérd le a releváns Docker logokat (pl. `sudo docker logs --tail 50 <konténer>`), ne csak az elméletedet oszd meg.
+
+## 🛑 4. KÁRTEVÉS MEGELŐZÉSE
+- Meglévő, működő kódot csak akkor módosíthatsz, ha az kifejezetten a feladat része. A módosításokat (Surgical Coding) a lehető legkisebb beavatkozással végezd el.
+- Mielőtt egy nagy fájlt felülírsz, mindig készíts róla mentést, vagy olvasd el alaposan, hogy megértsd az eredeti logikát, nehogy véletlenül kitörölj egy fontos függőséget.
 
 Nyelv: Magyar nyelven kommunikálj velem.

.roo/rules/02-architecture.md

@@ -1,3 +1,7 @@
+# 🏛️ PROJECT ARCHITECTURE & ENVIRONMENT MAP
+
+Ez a fájl tartalmazza a projekt fizikai felépítését és a futtatási környezet szigorú szabályait. Keresés (`find`) előtt MINDIG ezt a térképet használd iránymutatásként!
+
 Tech Stack: FastAPI (v2, aszinkron), SQLAlchemy (Async), PostgreSQL (Izolált hálózaton), Docker Compose V2.
 
 AI & OCR: Hibrid AI Gateway (Helyi Ollama: 14B Qwen szövegre, Llama Vision képekre. Fallback: Gemini/Groq).
@@ -6,7 +10,30 @@ Identity & Auth: "Dual Entity" modell (Person = hús-vér ember, User = technika
 
 Deduplikáció (MDM): Csak akkor van merge, ha a make, a technical_code és a hengerűrtartalom egyezik. N/A és UNKNOWN fallback kódok generálása az SQL kényszerek miatt.
 
-## 5. SQL és Adatbázis Hibakezelés (Error Handling)
+## 🐳 1. KÖRNYEZET ÉS DOCKER SZABÁLYOK (ENVIRONMENT)
+- **Operációs rendszer:** Ubuntu/Linux környezetben dolgozunk.
+- **Docker Compose (KRITIKUS):** A rendszer az új Docker Compose V2-t használja. 
+  - **TILOS** a kötőjeles `docker-compose` parancs használata!
+  - **KÖTELEZŐ** a szóközös `docker compose` használata (pl. `sudo docker compose restart sf_api`).
+- **Jogosultságok:** Ha egy Docker parancs `permission denied` hibát dob, próbáld meg automatikusan `sudo`-val az elején (pl. `sudo docker exec ...`), de először kérdezz rá, ha bizonytalan vagy.
+- **Backend keretrendszer:** FastAPI (Python), aszinkron (async/await) megközelítéssel, SQLAlchemy 2.0+ (asyncpg) adatbázis kapcsolattal.
+
+## 🗺️ 2. PROJEKT TÉRKÉP (DIRECTORY STRUCTURE)
+A projekt mappa-szerkezete az alábbi logikát követi. Keresd a fájlokat ezekben a mappákban a funkciójuk szerint:
+
+- **`/backend/app/models/`**: Itt találhatók az adatbázis modellek (SQLAlchemy). Ne feledd a sémákat (identity, finance, data, audit, system)!
+- **`/backend/app/api/endpoints/`** (vagy `api/v1/`): Itt vannak a FastAPI végpontok (routerek, endpointok).
+- **`/backend/app/services/`**: Itt van az üzleti logika és a "motorok" (pl. `billing_engine.py`, `notification_service.py`).
+- **`/backend/app/core/`**: Rendszerbeállítások, konfigurációk, biztonság (pl. `config.py`).
+- **`/backend/app/test_in/`**: Belső tesztek, amiket a konténeren belülről, a többi modullal együttműködve futtatunk.
+- **`/backend/app/test_outside/`**: Külső integrációs tesztek és szkriptek (pl. a `verify_financial_truth.py`). Ezek futtatása gyakran speciális adatbázis-kezelést igényel.
+- **`/.roo/scripts/`**: Az AI és a fejlesztést támogató szkriptek (pl. a `gitea_manager.py`).
+
+## 🧩 3. KÓDOLÁSI ALAPELVEK (ARCHITECTURE RULES)
+- **Szeparáció (DDD):** Az adatbázis modellek szigorúan sémákra vannak bontva. Ne keverd a `finance` és a `vehicle` domainek adatait!
+- **Aszinkronitás:** Minden I/O és adatbázis művelet aszinkron (`await session.execute(...)`). Ne használj szinkron blokkoló hívásokat a FastAPI végpontokban.
+
+## 4. SQL és Adatbázis Hibakezelés (Error Handling)
 - **Unique Constraint hibák:** Ha a PostgreSQL `InvalidColumnReferenceError` vagy `UniqueViolation` hibát dob az `ON CONFLICT` miatt, TILOS találgatni a mezőket! 
 - **A kötelező megoldás:** Használd az `ON CONFLICT ON CONSTRAINT [korlát_neve] DO NOTHING` vagy `DO UPDATE` szintaxist.
 - A pontos korlát (constraint) nevét mindig a pgAdmin-ból vagy a `\d+ táblanév` lekérdezéssel kell kideríteni módosítás előtt.

.roo/rules/03-workflow.md

@@ -1,3 +1,35 @@
 Feladatkezelés: A projektmenedzsmenthez MCP Focalboard-ot vagy a projekt gyökerében található KANBAN_AUDIT.md fájlt használunk. Minden munkamenet elején ellenőrizd ezeket, hogy tudd, mi a feladat (Todo) és mi van már kész (Done).
 
-Jelenlegi Fókusz: A következő időszak fő feladata a "Historical Data" (múltbéli költségek, szervizek) bevezetése az occurrence_date mezővel, és a flottavezetőknek szóló AnalyticsService (TCO/km) kidolgozása.
+Jelenlegi Fókusz: A következő időszak fő feladata a "Historical Data" (múltbéli költségek, szervizek) bevezetése az occurrence_date mezővel, és a flottavezetőknek szóló AnalyticsService (TCO/km) kidolgozása.
+
+1. Adatbázis Migrációk (Alembic)
+
+Ha az AI (az Architect vagy a Coder) módosít egy adatbázis modellt a models/ mappában, hogyan vezesse át az adatbázison? Az AI hajlamos csak megírni a Python kódot, és elfelejteni az SQL-t, vagy nyers SQL-lel próbálkozni.
+
+    Mit adj meg: A pontos parancsot a migrációhoz.
+
+    Példa szabály: "Ha módosítasz egy SQLAlchemy modellt, KÖTELEZŐ legenerálnod a migrációs fájlt az Alembic segítségével a konténeren belül: sudo docker exec sf_api alembic revision --autogenerate -m "Leírás", majd futtatnod kell: sudo docker exec sf_api alembic upgrade head. Soha ne módosíts táblaszerkezetet nyers SQL-lel!"
+
+2. Csomagkezelés (Dependencies)
+
+Ha a Roo Code-nak szüksége van egy új Python csomagra (pl. egy új Stripe modulra vagy egy adatbázis driverre), hogyan telepítse?
+
+    Mit adj meg: Hol tartod a függőségeket (requirements.txt, Pipfile, vagy pyproject.toml?), és hogyan települjenek.
+
+    Példa szabály: "Ha új Python csomagra van szükséged, TILOS csak úgy a host gépen pip install-t futtatni. Add hozzá a csomagot a backend/requirements.txt (vagy megfelelő) fájlhoz, és jelezd a felhasználónak, hogy újra kell építenie a konténert (docker compose build)."
+
+3. Környezeti Változók és Titkok (Secrets & .env)
+
+Az AI-k hajlamosak "lusták" lenni, és teszteléskor vagy fejlesztéskor keménykódolni (hardcode) a jelszavakat, API kulcsokat a fájlokba.
+
+    Mit adj meg: A konfiguráció kezelésének módját.
+
+    Példa szabály: "SOHA ne hardkódolj API kulcsokat (Stripe, Ollama, Groq), jelszavakat vagy adatbázis URL-eket a kódba! MINDIG a backend/app/core/config.py (Pydantic BaseSettings) fájlt használd, az adatokat pedig a .env fájlból olvasd ki. Ha új környezeti változó kell, írd bele a .env.example fájlba is!"
+
+4. Naplózási Szabvány (Logging)
+
+Főleg a háttérfolyamatoknál (mint a robotok vagy a 20-as kártya Cron-jobja), a sima print() nem elég egy Docker konténerben, mert nehéz nyomon követni.
+
+    Mit adj meg: Milyen loggert használsz? (Beépített logging, loguru, stb.)
+
+    Példa szabály: "Ne használj sima print() utasításokat a végleges kódban! Használd a projekt beépített loggerét (pl. import logging vagy from app.core.logger import logger). A háttérfolyamatokat részletesen logold (INFO szinten a lépéseket, ERROR szinten a kivételeket Stack Trace-szel)."