átlagos kiegészítséek jó sok

2026-03-22 11:02:05 +00:00
parent f53e0b53df
commit 5d44339f21
249 changed files with 20922 additions and 2253 deletions
--- a/docs/admin_system_epic.md
+++ b/docs/admin_system_epic.md
@@ -0,0 +1,173 @@
+# 🏛️ Admin System Epic: v2.0 - Enterprise Admin & Dynamic Config
+
+**Mérföldkő:** v2.0 - Enterprise Admin & Dynamic Config  
+**Cél:** A Service Finder adminisztrációs rétegének átfogó fejlesztése, amely lehetővé teszi a dinamikus konfigurációk kezelését, szerepköralapú hozzáférés-vezérlést (RBAC), felhasználói és tartalmi moderálást, valamint anomália detektálást a rendszer integritásának védelme érdekében.
+
+**Prioritás:** Magas  
+**Becsült időtartam:** 4 hét (4 fázis)  
+**Felelős:** Core Team  
+**Státusz:** Tervezés
+
+---
+
+## 📋 Issue #1 (Phase 1): Hardcode Audit & Config Motor
+
+**Cím:** Hardcode Audit & Config Motor  
+**Pontszám:** 50 XP  
+**Határidő:** 2026-04-04  
+**Scope:** Backend, Database  
+**Type:** Refactor, Infrastructure  
+
+### Leírás
+A kódban található beégetett értékek (pl. 50 XP, limit értékek, API URL-ek) átvizsgálása és kiváltása dinamikus konfigurációs rendszerrel. Létrehozni egy `SystemParameter` táblát a `system` sémában, amely kulcs-érték párokat tárol, és egy `ConfigService` osztályt, amely ezeket az értékeket gyorsítótárazza és szolgáltatja az alkalmazás számára.
+
+### 🔗 Függőségek (Dependencies)
+- **Bemenet:** Meglévő kódban található hardcode értékek, PostgreSQL adatbázis
+- **Kimenet:** Minden olyan modul, amely hardcode értékeket használ (pl. gamification, billing, robot kvóták)
+
+### 📝 To-Do List
+- [ ] **Hardcode Audit Script** írása, amely végigvizsgálja a `backend/` mappát és listázza a potenciális hardcode értékeket
+- [ ] **`SystemParameter` tábla tervezése** (id, key, value, data_type, description, scope, is_encrypted, created_at, updated_at)
+- [ ] **Alembic migráció** generálása a tábla létrehozásához
+- [ ] **`ConfigService` osztály** megírása a következőkkel:
+  - [ ] `get(key, default=None)` metódus
+  - [ ] `set(key, value)` metódus (csak admin)
+  - [ ] In‑memory cache (TTL 5 perc)
+  - [ ] Async támogatás
+- [ ] **Hardcode értékek cseréje** a `ConfigService`-re a következő modulokban:
+  - [ ] `gamification.py` (XP értékek, szintek)
+  - [ ] `billing_engine.py` (díjak, limitek)
+  - [ ] `dvla_service.py` (API kvóták)
+  - [ ] `notification_service.py` (sablonok)
+- [ ] **Admin API végpont** `/api/v1/admin/config` a konfigurációk kezeléséhez (GET, PUT)
+- [ ] **Tesztelés** unit és integrációs tesztekkel
+
+---
+
+## 📋 Issue #2 (Phase 2): RBAC & Admin Security Layer
+
+**Cím:** RBAC & Admin Security Layer  
+**Pontszám:** 40 XP  
+**Határidő:** 2026-04-11  
+**Scope:** Backend, Security  
+**Type:** Feature, Security  
+
+### Leírás
+Szerepkörök (Superadmin, Moderator, Support) bevezetése és az `/api/v1/admin` router jogosultság-kezelésének megvalósítása. Minden végpontnak ellenőriznie kell a felhasználó szerepkörét és scope-ját a `UserTrustProfile` alapján.
+
+### 🔗 Függőségek (Dependencies)
+- **Bemenet:** `identity.user` és `identity.user_trust_profile` táblák, JWT token
+- **Kimenet:** Admin API végpontok, frontend admin felület
+
+### 📝 To-Do List
+- [ ] **Szerepkör enum** definiálása (`Superadmin`, `Moderator`, `Support`, `Auditor`)
+- [ ] **`UserTrustProfile` tábla bővítése** `role` és `permissions` mezőkkel
+- [ ] **Alembic migráció** a mezők hozzáadásához
+- [ ] **`AdminSecurity` dependency** létrehozása a következőkkel:
+  - [ ] `require_role(role)` dekorátor
+  - [ ] `require_permission(permission)` dekorátor
+  - [ ] Scope ellenőrzés (organization, global)
+- [ ] **`/api/v1/admin` router védelme** a dependency-vel
+- [ ] **Permission matrix** dokumentálása (melyik szerepkör mit tehet)
+- [ ] **Teszt felhasználók** létrehozása seed scripttel
+- [ ] **Integrációs tesztek** a szerepkörökhöz
+
+---
+
+## 📋 Issue #3 (Phase 3): Core Admin API Végpontok
+
+**Cím:** Core Admin API Végpontok  
+**Pontszám:** 60 XP  
+**Határidő:** 2026-04-18  
+**Scope:** Backend, API  
+**Type:** Feature  
+
+### Leírás
+Felhasználók, KYC, járművek és szervizek kezelését végző admin API végpontok megvalósítása (listázás, szűrés, tiltás, jóváhagyás, törlés). Minden művelet naplózása az audit táblába.
+
+### 🔗 Függőségek (Dependencies)
+- **Bemenet:** Meglévő user, vehicle, service táblák, RBAC layer
+- **Kimenet:** Admin dashboard, moderátori munkafolyamatok
+
+### 📝 To-Do List
+- [ ] **Felhasználó kezelés:**
+  - [ ] `GET /admin/users` – listázás, szűrés (email, név, státusz)
+  - [ ] `PUT /admin/users/{user_id}/ban` – tiltás (indoklással)
+  - [ ] `PUT /admin/users/{user_id}/approve` – KYC jóváhagyás
+  - [ ] `DELETE /admin/users/{user_id}` – soft delete
+- [ ] **Jármű kezelés:**
+  - [ ] `GET /admin/vehicles` – listázás, szűrés (rendszám, márka)
+  - [ ] `PUT /admin/vehicles/{vehicle_id}/flag` – gyanúsként megjelölés
+  - [ ] `DELETE /admin/vehicles/{vehicle_id}` – törlés (ha hamis adat)
+- [ ] **Szerviz kezelés:**
+  - [ ] `GET /admin/services` – listázás, szűrés (név, hely, minősítés)
+  - [ ] `PUT /admin/services/{service_id}/verify` – kézi ellenőrzés
+  - [ ] `PUT /admin/services/{service_id}/suspend` – felfüggesztés
+- [ ] **KYC dokumentumok:**
+  - [ ] `GET /admin/kyc/pending` – függőben lévő kérelmek
+  - [ ] `PUT /admin/kyc/{request_id}/review` – áttekintés és döntés
+- [ ] **Audit naplózás** minden admin művelethez (`audit.admin_actions` tábla)
+- [ ] **Pagination és filter** támogatása minden listázó végponthoz
+- [ ] **Swagger dokumentáció** frissítése
+
+---
+
+## 📋 Issue #4 (Phase 4): Anomália Detektálás (Anti-Cheat)
+
+**Cím:** Anomália Detektálás (Anti-Cheat)  
+**Pontszám:** 30 XP  
+**Határidő:** 2026-04-25  
+**Scope:** Backend, Robot, Security  
+**Type:** Feature, Monitoring  
+
+### Leírás
+Robot felügyelő (Cron/Background task) létrehozása, amely figyeli a gyanús tömeges validációkat, helyadatokat és egyéb potenciális csalási kísérleteket. Riasztás generálása és automatikus intézkedések (pl. ideiglenes letiltás).
+
+### 🔗 Függőségek (Dependencies)
+- **Bemenet:** Audit naplók, vehicle validations, user actions
+- **Kimenet:** Riasztások, automatikus blokkolások, admin értesítések
+
+### 📝 To-Do List
+- [ ] **Anomália detektálási szabályok** definiálása:
+  - [ ] Túl sok validáció ugyanarról az IP‑ről ( >100/óra)
+  - [ ] Tömeges helyadat‑módosítás rövid időn belül
+  - [ ] Gyanús XP farmolás (több account ugyanarról az eszközről)
+  - [ ] Hamis járműadatok ismételt feltöltése
+- [ ] **`AnomalyDetector` service** létrehozása:
+  - [ ] Szabályok futtatása időzített ciklusban (pl. 10 percenként)
+  - [ ] Gyanús események rögzítése `audit.suspicious_events` táblába
+  - [ ] Riasztás generálás (email, Slack, in‑app notification)
+- [ ] **Automatikus intézkedések:**
+  - [ ] IP ideiglenes blokkolása (1 óra)
+  - [ ] Felhasználói account letiltása (manual review required)
+  - [ ] Validációk visszavonása
+- [ ] **Admin dashboard widget** a gyanús tevékenységek megjelenítéséhez
+- [ ] **Tesztadatok generálása** és detektálás validálása
+- [ ] **Külső integráció** (pl. Fail2ban, Cloudflare) tervezése
+
+---
+
+## 🗺️ Roadmap & Kapcsolódó Feladatok
+
+1. **v2.1 – Admin Dashboard UI** (Frontend epic) – a fenti API-k felhasználásával
+2. **v2.2 – Real‑time Notification System** – WebSocket‑alapú értesítések adminoknak
+3. **v2.3 – Advanced Analytics for Admins** – jelentéskészítő, exportálás
+
+## 📊 Metrikák és Sikerfeltételek
+
+- **Hardcode redukció:** 90%‑os csökkenés a kódban található magic number‑ek számában
+- **RBAC teljes lefedettség:** Minden admin végpont védett szerepkör‑alapú ellenőrzéssel
+- **Anomália detektálás pontosság:** Legalább 95%‑os recall a csalási kísérleteknél
+- **Válaszidő:** Admin API végpontok átlagos válaszideje < 200 ms
+
+## 👥 Felelősségek
+
+- **Backend Lead:** Phase 1 & 2
+- **Security Engineer:** Phase 2 & 4  
+- **API Developer:** Phase 3
+- **QA Engineer:** Tesztelés minden fázisban
+
+---
+
+*Dokumentum frissítve: 2026‑03‑21*  
+*Verzió: 1.0*
--- a/docs/auth_registration_audit.md
+++ b/docs/auth_registration_audit.md
@@ -0,0 +1,115 @@
+# Authentication & Registration Module Audit
+
+**Audit Date:** 2026-03-19  
+**Gitea Issue:** #98  
+**Auditor:** Rendszerauditőr  
+
+## 1. Overview
+
+This audit examines the current state of the authentication and registration module within the Service Finder backend. The user reported that a three‑step registration logic (Lite, Complete KYC) was fully implemented and functional but was disconnected from the routers during a refactoring. The goal is to map the existing code, identify missing endpoints, and verify router connectivity.
+
+## 2. Auth Service Analysis (`backend/app/services/auth_service.py`)
+
+The `AuthService` class contains the core registration logic, split into two phases:
+
+### 2.1 `register_lite`
+- **Purpose:** First‑step registration with dynamic limits and Sentinel auditing.
+- **Input:** `UserLiteRegister` schema (email, password, first/last name, region, language, timezone).
+- **Process:**
+  1. Fetches admin‑configurable parameters (`auth_min_password_length`, `auth_default_role`, `auth_registration_hours`).
+  2. Creates a `Person` record (inactive).
+  3. Creates a `User` record with hashed password, role, region, language, timezone.
+  4. Generates a UUID verification token and stores it in `VerificationToken`.
+  5. Sends a registration email with a verification link.
+  6. Logs the event via `security_service.log_event`.
+- **Output:** A new `User` with `is_active=False`.
+
+### 2.2 `complete_kyc`
+- **Purpose:** Second‑step full profile completion, organization creation, and gamification initialization.
+- **Input:** `UserKYCComplete` schema (phone, birth details, address, identity docs, ICE contact, preferred currency).
+- **Process:**
+  1. Retrieves the user and their linked `Person`.
+  2. Fetches dynamic settings (organization naming template, default currency, KYC bonus XP).
+  3. Calls `GeoService.get_or_create_full_address` to create a precise address record.
+  4. Enriches the `Person` with mother’s name, birth place, phone, address, identity docs.
+  5. Creates an `Organization` (individual type) with a generated slug.
+  6. Creates a `Branch` (main), `OrganizationMember` (OWNER), `Wallet`, and `UserStats`.
+  7. Activates the user and sets a folder slug.
+  8. Awards gamification points via `GamificationService.award_points`.
+- **Output:** Fully activated user with organization, wallet, and infrastructure.
+
+### 2.3 Supporting Methods
+- `authenticate`: Validates email/password against the stored hash.
+- `verify_email`: Marks a verification token as used (no endpoint exposed).
+- `initiate_password_reset`: Creates a password‑reset token and sends an email.
+- `reset_password`: Validates the token and updates the password.
+- `soft_delete_user`: Soft‑deletes a user with audit logging.
+
+## 3. Schemas (`backend/app/schemas/auth.py`)
+
+### 3.1 `UserLiteRegister` (Step 1)
+```python
+email: EmailStr
+password: str (min_length=8)
+first_name: str
+last_name: str
+region_code: Optional[str] = "HU"
+lang: Optional[str] = "hu"
+timezone: Optional[str] = "Europe/Budapest"
+```
+
+### 3.2 `UserKYCComplete` (Step 2)
+- **Personal details:** `phone_number`, `birth_place`, `birth_date`, `mothers_last_name`, `mothers_first_name`
+- **Atomic address fields:** `address_zip`, `address_city`, `address_street_name`, `address_street_type`, `address_house_number`, optional stairwell/floor/door/HRsz
+- **Identity documents:** `identity_docs: Dict[str, DocumentDetail]` (e.g., ID_CARD, LICENSE)
+- **Emergency contact:** `ice_contact: ICEContact`
+- **Preferences:** `preferred_language`, `preferred_currency`
+
+### 3.3 `User` Response/Update Schemas (`backend/app/schemas/user.py`)
+- `UserBase`, `UserResponse`, `UserUpdate` – used for profile management.
+
+## 4. Endpoints (`backend/app/api/v1/endpoints/auth.py`)
+
+Currently three endpoints are implemented and routed:
+
+| Method | Path | Description |
+|--------|------|-------------|
+| POST   | `/auth/register` | Lite registration (creates user, sends verification email) |
+| POST   | `/auth/login` | OAuth2 password flow, returns JWT tokens |
+| POST   | `/auth/complete‑kyc` | Completes KYC, activates user, creates organization/wallet |
+
+**Missing endpoints** (service methods exist but no routes):
+- `GET/POST /auth/verify‑email` – email verification
+- `POST /auth/forgot‑password` – password‑reset initiation
+- `POST /auth/reset‑password` – password reset with token
+- `GET /auth/me` – already exists in `users.py` under `/users/me`
+
+## 5. Router Inclusion (`backend/app/api/v1/api.py`)
+
+The auth router is correctly included:
+```python
+api_router.include_router(auth.router, prefix="/auth", tags=["Authentication"])
+```
+Thus the three existing endpoints are reachable under `/auth`.
+
+## 6. Missing Pieces & Discrepancies
+
+1. **Three‑step registration:** The audit found only two explicit steps (Lite, KYC). A third step (e.g., vehicle addition, fleet setup) is not present in the auth module; it may belong to other domains (assets, vehicles).
+2. **Email verification endpoint:** The `verify_email` method is ready but no route exposes it.
+3. **Password‑reset endpoints:** The `initiate_password_reset` and `reset_password` methods are implemented but not routed.
+4. **Onboarding flow:** After KYC, the user is fully activated, but there is no dedicated “onboarding” endpoint that guides through optional post‑registration steps.
+5. **Dynamic configuration:** The service heavily relies on `config.get_setting` – all parameters are stored in `system_parameters`, making the system admin‑configurable.
+
+## 7. Recommendations
+
+1. **Route the missing endpoints:** Add `/auth/verify‑email`, `/auth/forgot‑password`, `/auth/reset‑password` to `auth.py`.
+2. **Consider a third step:** If a third registration step is required (e.g., “add your first vehicle”), design a separate endpoint under `/assets` or `/vehicles` and link it from the front‑end onboarding flow.
+3. **Verify email‑template existence:** Ensure the email templates (`reg`, `pwd_reset`) are defined in `email_manager`.
+4. **Test the full flow:** Write an end‑to‑end test that covers Lite registration → email verification → KYC completion → password reset.
+5. **Document the dynamic parameters:** List all `system_parameter` keys used by the auth module (`auth_min_password_length`, `auth_default_role`, `auth_registration_hours`, `org_naming_template`, `finance_default_currency`, `gamification_kyc_bonus`, `auth_password_reset_hours`).
+
+## 8. Conclusion
+
+The authentication and registration module is **architecturally complete** and **production‑ready**. The business logic is well‑structured, uses dynamic configuration, and integrates with the broader ecosystem (geo, gamification, organizations, wallets). The only gap is the lack of routed endpoints for email verification and password reset – a straightforward addition that does not require changes to the core logic.
+
+Once the missing endpoints are connected, the three‑step registration (Lite → Verify → KYC) will be fully operational, and the module will satisfy all functional requirements.
--- a/docs/mcp_config_audit_2026-03-15.md
+++ b/docs/mcp_config_audit_2026-03-15.md
@@ -0,0 +1,233 @@
+# MCP Konfiguráció Audit és Hibaelhárítási Útmutató
+
+**Dátum:** 2026-03-15  
+**Auditor:** Rendszerauditőr / Főmérnök  
+**Cél:** A globális és projekt MCP beállítások elemzése, működési problémák azonosítása, valamint a saját rendszerbeállításhoz szükséges információk összegyűjtése.
+
+## 1. Jelenlegi Konfigurációk
+
+### 1.1 Globális MCP Beállítások
+**Fájl:** `/home/coder/.local/share/code-server/User/globalStorage/rooveterinaryinc.roo-cline/settings/mcp_settings.json`
+
+```json
+{
+	"mcpServers": {
+		"focalboard": {
+			"command": "docker",
+			"args": [
+				"run",
+				"-i",
+				"--rm",
+				"--network",
+				"shared_db_net",
+				"--env-file",
+				"/opt/docker/dev/service_finder/.roo/.env.focalboard",
+				"mcp-focalboard-custom",
+				"node",
+				"build/index.js"
+			],
+			"disabled": true,
+			"autoApprove": [],
+			"alwaysAllow": [
+				"create_card",
+				"move_card",
+				"get_boards",
+				"get_cards"
+			]
+		},
+		"postgres-wiki": {
+			"command": "npx",
+			"args": [
+				"-y",
+				"@modelcontextprotocol/server-postgres",
+				"postgresql://wikijs:MiskociA74@wikijs-db:5432/wiki"
+			]
+		},
+		"postgres-service-finder": {
+			"command": "npx",
+			"args": [
+				"-y",
+				"@modelcontextprotocol/server-postgres",
+				"postgresql://sf_user:AppSafePass_2026@service-finder-db:5432/service_finder_db"
+			]
+		}
+	}
+}
+```
+
+### 1.2 Projekt MCP Beállítások
+**Fájl:** `.roo/mcp.json`
+```json
+{
+  "mcpServers": {
+    "postgres-wiki": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-postgres",
+        "postgresql://wikijs:${WIKIJS_DB_PASSWORD}@wikijs-db:5432/wiki"
+      ]
+    },
+    "postgres-service-finder": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-postgres",
+        "postgresql://sf_user:${SF_DB_PASSWORD}@service-finder-db:5432/service_finder_db"
+      ]
+    },
+    "filesystem": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-filesystem",
+        "/opt/docker/dev/service_finder"
+      ]
+    }
+  }
+}
+```
+
+**Fájl:** `.roo/mcp_settings.json`
+```json
+{
+  "mcpServers": {
+    "focalboard": {
+      "command": "docker",
+      "args": [
+        "run",
+        "-i",
+        "--rm",
+        "--network", "shared_db_net",
+        "--env-file", "/opt/docker/dev/service_finder/.roo/.env.focalboard",
+        "mcp-focalboard-custom",
+        "node",
+        "build/index.js"
+      ],
+      "disabled": false,
+      "autoApprove": [],
+      "alwaysAllow": ["create_card", "move_card", "get_boards", "get_cards"]
+    },
+    "postgres-wiki": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-postgres",
+        "postgresql://wikijs:'MiskociA74'@wikijs-db:5432/wiki"
+      ]
+    },
+    "postgres-service-finder": {
+      "command": "npx",
+      "args": [
+        "-y",
+        "@modelcontextprotocol/server-postgres",
+        "postgresql://sf_user:'AppSafePass_2026'@service-finder-db:5432/service_finder_db"
+      ]
+    }
+  }
+}
+```
+
+### 1.3 Környezeti Fájlok
+- **`.roo/.env.focalboard`** – tartalmazza a Focalboard kapcsolati adatokat:
+  ```
+  FOCALBOARD_HOST=http://focalboard:8000
+  FOCALBOARD_USERNAME=kincses
+  FOCALBOARD_PASSWORD=MiskociA74
+  FOCALBOARD_TOKEN=k6p5mijdxdtg3ig6bhq5wurfx4y
+  ```
+
+## 2. Azonosított Problémák
+
+### 2.1 Inkonzisztens `disabled` állapot
+- **Globális beállítás:** `focalboard` → `disabled: true`
+- **Projekt beállítás:** `focalboard` → `disabled: false`
+- **Hatás:** A szerver nem indul el, ha a globális beállítás felülírja a projektet.
+
+### 2.2 Hiányzó Filesystem Szerver a Globális Beállításokban
+- A projekt `.roo/mcp.json` definiál egy `filesystem` szervert, amely a munkaterület könyvtárát szolgálja ki.
+- A globális beállítások **nem tartalmaznak** `filesystem` szervert, így a fájlrendszer MCP nem lesz elérhető a kliens számára.
+
+### 2.3 Jelszó Escape Karakterek
+- A projekt `mcp_settings.json` a jelszavakat aposztrófok között adja meg (pl. `'MiskociA74'`). Ez lehet, hogy felesleges, és hibás kapcsolódást eredményezhet.
+
+### 2.4 Docker Hálózati Függőség
+- A `focalboard` szerver a `shared_db_net` Docker hálózatra támaszkodik.
+- A Docker daemon nem érhető el a jelenlegi felhasználói környezetből (`permission denied`). Ennek oka:
+  - A felhasználó nincs a `docker` csoportban, vagy
+  - A Docker socket nem megfelelően van mountolva a konténerbe.
+
+### 2.5 MCP Szerver Képek Hiánya
+- A `mcp-focalboard-custom` image nem feltétlenül létezik a helyi Docker registry‑ben.
+- Az `npx` csomagok (`@modelcontextprotocol/server-postgres`, `@modelcontextprotocol/server-filesystem`) telepítve vannak? Ha nem, az első futtatáskor letöltődnek, de időtúllépést okozhatnak.
+
+## 3. Szükséges Információk a Saját Rendszer Beállításához
+
+Ahhoz, hogy a felhasználó a saját környezetében működő MCP konfigurációt építsen ki, a következő információkat kell összegyűjtenie / ellenőriznie:
+
+### 3.1 Docker Konfiguráció
+- **Docker csoporttagság:** `groups` parancs – a felhasználónak a `docker` csoportban kell lennie.
+- **Docker socket elérési út:** `/var/run/docker.sock` jogosultságai (`ls -la /var/run/docker.sock`).
+- **Hálózat létezése:** `docker network ls | grep shared_db_net` (sudo-val).
+- **Konténerek állapota:** `docker ps | grep roo-helper` – a `roo-helper` konténernek futnia kell a `gitea_manager.py` script futtatásához.
+
+### 3.2 Környezeti Változók
+- **WIKIJS_DB_PASSWORD** és **SF_DB_PASSWORD** – a projekt `.env` fájlból kell kinyerni, hogy a helyettesítés működjön.
+- **Focalboard token** érvényessége – a tokennek meg kell egyeznie a Focalboard szerver konfigurációjával.
+
+### 3.3 MCP Szerver Képek és Csomagok
+- **Egyéni MCP kép:** `docker images | grep mcp-focalboard-custom`
+- **NPM csomagok:** `npx @modelcontextprotocol/server-postgres --version` (a konténeren belül)
+
+### 3.4 Roo‑Cline Beállítási Hierarchia
+- **Melyik beállítás fájl érvényes?** A Roo‑Cline a globális (`~/.local/share/code-server/...`) vagy a projekt (`.roo/`) beállításokat használja?  
+  *Általában a globális beállítások felülírják a projekt szintűeket, de ez függ a kliens implementációjától.*
+
+### 3.5 Tesztelési Lépések
+1. **Focalboard szerver indítása kézzel:**
+   ```bash
+   docker run -i --rm --network shared_db_net --env-file .roo/.env.focalboard mcp-focalboard-custom node build/index.js
+   ```
+2. **PostgreSQL szerver teszt:**
+   ```bash
+   npx -y @modelcontextprotocol/server-postgres postgresql://sf_user:AppSafePass_2026@service-finder-db:5432/service_finder_db
+   ```
+3. **Filesystem szerver teszt:**
+   ```bash
+   npx -y @modelcontextprotocol/server-filesystem /opt/docker/dev/service_finder
+   ```
+
+## 4. Javasolt Javítási Lépések
+
+1. **Globális beállítások frissítése:**  
+   Másold át a projekt `filesystem` szerver definícióját a globális `mcp_settings.json` fájlba, és állítsd a `focalboard` `disabled` értékét `false`-ra (ha a Focalboard szükséges).
+
+2. **Jelszó escape egységesítése:**  
+   Távolítsd el a felesleges aposztrófokat a jelszavak körül a `mcp_settings.json`-ból.
+
+3. **Docker jogosultságok ellenőrzése:**  
+   Add hozzá a felhasználót a docker csoporthoz: `sudo usermod -aG docker $USER`, majd jelentkezz be újra.
+
+4. **Hálózat létrehozása (ha hiányzik):**  
+   ```bash
+   docker network create shared_db_net
+   ```
+
+5. **MCP kép buildelése (ha szükséges):**  
+   A `mcp-focalboard-custom` kép forráskódja a projektben lehet. Buildeld le:  
+   ```bash
+   docker build -t mcp-focalboard-custom -f Dockerfile.focalboard .
+   ```
+
+6. **Tesztelés a Roo‑Cline‑ben:**  
+   Indítsd újra a VS Code‑ot (vagy a Roo‑Cline bővítményt), hogy a módosított beállítások érvénybe lépjenek, majd próbáld ki az MCP szervereket (pl. fájllistázás, adatbázis lekérdezés).
+
+## 5. Következő Lépések a Projektben
+
+- Hozz létre egy Gitea kártyát a fenti javítások végrehajtására (ha a Docker elérhető).
+- Dokumentáld a végleges működő konfigurációt a `docs/` mappában.
+- Frissítsd a `.roo/history.md` fájlt a változtatásokról.
+
+---
+
+*Ez a dokumentum a Service Finder projekt Audit módjában készült, kizárólag információgyűjtés és elemzés céljából. A javításokat a megfelelő szerepkör (pl. Fast Coder vagy Architect) hajthatja végre.*
--- a/docs/ultimatespecs_integration_audit.md
+++ b/docs/ultimatespecs_integration_audit.md
@@ -0,0 +1,134 @@
+# UltimateSpecs Integráció Audit
+
+## Áttekintés
+Ez a dokumentum a Service Finder projekt `backend/app/workers/vehicle` könyvtárában található Python fájlok auditját tartalmazza, különös tekintettel az `https://www.ultimatespecs.com/` weboldalról történő járműadatok gyűjtésére.
+
+## Audit Dátum
+2026-03-17
+
+## Vizsgált Könyvtár
+`/opt/docker/dev/service_finder/backend/app/workers/vehicle`
+
+## Talált Források
+
+### 1. UltimateSpecs.com Integráció
+Két fő fájl tartalmaz explicit hivatkozást az UltimateSpecs domainre:
+
+#### a) `vehicle_robot_2_1_ultima_scout.py`
+- **Cél:** A `vehicle_model_definitions` táblából veszi a `pending` vagy `manual_review_needed` státuszú járműveket
+- **Működés:** Az UltimateSpecs keresőjén (`https://www.ultimatespecs.com/index.php?q=...`) keresztül talál meg adatlapokat
+- **Eredmény:** A talált variációkat új rekordként menti `enrich_ready` státusszal
+- **Technológia:** Playwright böngésző automatizálás, SQLAlchemy adatbázis műveletek
+- **Rate Limiting:** 3-6 másodperc véletlenszerű várakozás minden lekérdezés között
+
+#### b) `r5_ultimate_harvester.py`
+- **Cél:** A már megtalált járművek technikai specifikációinak scrape-elése
+- **Működés:** Közvetlen ugrás az adatlapra, táblázatok elemzése
+- **Kinyert adatok:** Lóerő (kW), lökettérfogat, nyomaték, maximális sebesség, gyorsulás 0-100 km/h, súly, tengelytáv, ülések száma
+- **Technológia:** Playwright, regex alapú adatkinyerés
+- **Adatbázis frissítés:** A `vehicle_model_definitions` tábla megfelelő mezőinek feltöltése
+
+### 2. Egyéb Külső Források
+A rendszer több más forrást is használ járműadatok gyűjtéséhez:
+
+#### a) Auto-Data.net
+- **Fájlok:** `R0_brand_hunter.py`, `vehicle_robot_2_auto_data_net.py`
+- **Cél:** Márkák és modellek listázása
+- **URL:** `https://www.auto-data.net/en/allbrands`
+
+#### b) RDW (Holland Nyílt Adat)
+- **Fájlok:** `vehicle_robot_1_5_heavy_eu.py`, `vehicle_robot_0_discovery_engine.py`, `vehicle_robot_1_catalog_hunter.py`, `vehicle_robot_2_1_rdw_enricher.py`
+- **Cél:** Holland járművek technikai adatai
+- **URL:** `https://opendata.rdw.nl/resource/m9d7-ebf2.json`
+
+#### c) NHTSA (USA)
+- **Fájlok:** `vehicle_robot_1_2_nhtsa_fetcher.py`, `vehicle_robot_1_4_bike_hunter.py`
+- **Cél:** Amerikai járművek modell listái
+- **URL:** `https://vpic.nhtsa.dot.gov/api/vehicles/GetModelsForMakeYear/...`
+
+#### d) DVLA (UK)
+- **Fájl:** `vehicle_robot_1_gb_hunter.py`
+- **Cél:** Brit járművek hiteles adatai
+- **URL:** `https://driver-vehicle-licensing.api.gov.uk/vehicle-enquiry/v1/vehicles`
+
+#### e) GitHub Raw JSON
+- **Fájl:** `vehicle_data_loader.py`
+- **Cél:** Nyílt adatkészletek
+- **URL-ek:**
+  - `https://raw.githubusercontent.com/DanielKohut/car-data/master/car_data.json`
+  - `https://raw.githubusercontent.com/matthlavacka/car-list/master/car-list.json`
+
+#### f) AutoEvolution.com
+- **Fájlok:** `bike_R0_brand_hunter.py`, `test_aprilia.py`
+- **Cél:** Motorok adatai
+- **URL:** `https://www.autoevolution.com/moto/`
+
+#### g) Ollama API
+- **Fájlok:** `vehicle_robot_3_alchemist_pro.py`, `vehicle_robot_2_researcher.py`
+- **Cél:** AI-alapú adatfeldolgozás és elemzés
+- **URL:** `http://sf_ollama:11434/api/generate`
+
+## Függőségek
+
+### Bemeneti Függőségek
+1. **Külső API-k és Weboldalak:** Minden fent felsorolt forrás
+2. **Böngésző Automatizálás:** Playwright keretrendszer Chromium böngészőhöz
+3. **Adatbázis Kapcsolat:** PostgreSQL adatbázis SQLAlchemy ORM-mel
+4. **Hálózati Infrastruktúra:** Stabil internetkapcsolat, proxy beállítások
+
+### Kimeneti Függőségek
+1. **`vehicle_model_definitions` tábla:** A járművek mesterkatalógusa, amely a Service Finder alkalmazás alapját képezi
+2. **További feldolgozó robotok:** Az `enrich_ready` státuszú rekordok a következő feldolgozási lépésekbe kerülnek
+3. **Analitikai Rendszer:** A gyűjtött adatok a TCO (Total Cost of Ownership) számításokhoz és egyéb elemzésekhez használhatók
+
+## Műszaki Megvalósítás
+
+### Playwright Használata
+Mindkét UltimateSpecs robot Playwright-et használ a weboldal böngészéséhez:
+- **Headless mód:** Háttérben futó böngésző
+- **Timeout kezelés:** 25-30 másodperc timeout
+- **Hibatűrés:** Kivételkezelés és újrapróbálkozási mechanizmus
+
+### Adatbázis Műveletek
+- **Atomi zárolás:** `FOR UPDATE SKIP LOCKED` a párhuzamos feldolgozáshoz
+- **Duplikáció ellenőrzés:** URL alapján ellenőrzi, hogy már létezik-e a rekord
+- **Státusz kezelés:** `pending` → `expanded_to_variants` vagy `research_failed_empty`
+
+### Rate Limiting és Etikett Viselkedés
+- **Várakozások:** 3-6 másodperc véletlenszerű várakozás lekérdezések között
+- **Kvóta kezelés:** A `QuotaManager` naplózza a DVLA API hívásokat
+- **User-Agent:** Valós böngésző user-agent használata
+
+## Biztonsági Szempontok
+
+### Adatvédelmi Megfontolások
+1. **Nyilvános adatok:** Az UltimateSpecs és más források nyilvánosan elérhető adatokat tartalmaznak
+2. **API kulcsok:** A DVLA API kulcs környezeti változóból kerül betöltésre (`.env` fájl)
+3. **Adatminőség:** A scrapelt adatok hitelességét a rendszer validálja és auditálja
+
+### Jogi Megfontolások
+1. **Terms of Service:** Az UltimateSpecs ToS-ét be kell tartani (rate limiting, robot.txt)
+2. **Adatfelhasználás:** Csak saját adatbázis feltöltésére használjuk, nem terjesztjük tovább
+3. **Nyílt adatok:** A többi forrás nyílt adatlicenc alatt áll (RDW, NHTSA, GitHub)
+
+## Javaslatok
+
+### 1. Monitoring Fejlesztése
+- **Naplózás:** Részletesebb naplózás a scrape sikerről/sikertelenségéről
+- **Metrikák:** API hívások számának nyomon követése
+- **Riasztások:** Ha egy forrás hosszabb ideig nem elérhető
+
+### 2. Hibakezelés Javítása
+- **Retry logika:** Intelligensebb újrapróbálkozási stratégia
+- **Fallback források:** Ha az UltimateSpecs nem elérhető, alternatív források használata
+- **Adatvalidáció:** Scrapelt adatok formátumellenőrzése
+
+### 3. Teljesítmény Optimalizálás
+- **Párhuzamos feldolgozás:** Több jármű egyidejű feldolgozása
+- **Cache réteg:** Gyakran lekérdezett adatok gyorsítótárazása
+- **Adatbázis indexek:** Optimalizált lekérdezések gyorsabb végrehajtásához
+
+## Következtetés
+Az UltimateSpecs integráció teljesen működőképes és jól implementált. A rendszer megfelelő rate limitinggel és hibatűréssel rendelkezik, etikusan viselkedik a célweboldallal szemben. A többforrásos megközelítés (RDW, NHTSA, DVLA, Auto-Data.net) biztosítja az adatok átfogó lefedettségét és redundanciáját.
+
+A jelenlegi implementáció készen áll éles használatra, és alapvetően nem igényel módosítást. Javasolt azonban a fent említett monitoring és hibakezelési fejlesztések implementálása a hosszú távú megbízhatóság érdekében.
--- a/docs/v02/history.md
+++ b/docs/v02/history.md
@@ -0,0 +1,24 @@
+Sikeresen létrehoztam az EPIC 9 mérföldkövet és mind az 5 hozzá tartozó Issue-kártyát a Gitea rendszerben. A teljes folyamat sikeresen lezárult:
+
+## 📋 Létrehozott elemek:
+
+1. **Mérföldkő (EPIC 9):** "EPIC 9: UltimateSpecs Pipeline Overhaul (Decoupled, Car & Moto Ready)" - ID: 12
+2. **Issue 1:** "DB: Extend ExternalReferenceLibrary with" - ID: 87
+3. **Issue 2:** "Worker: vehicle_ultimate_r0_spider" - ID: 88  
+4. **Issue 3:** "Worker: vehicle_ultimate_r1_scraper" - ID: 89
+5. **Issue 4:** "Worker: vehicle_ultimate_r2_enricher" - ID: 90
+6. **Issue 5:** "Worker: vehicle_ultimate_r3_finalizer" - ID: 91
+
+## 🏗️ Architektúra áttekintés:
+
+A 4 fázisú aszinkron Producer-Consumer rendszer teljesen specifikálva van:
+- **R0 Spider:** URL-ek gyűjtése az UltimateSpecs oldalról (autók és motorok)
+- **R1 Scraper:** HTML tartalom letöltése Playwright-rel (Cloudflare bypass)
+- **R2 Enricher:** Fuzzy mapping és technikai adatok kinyerése
+- **R3 Finalizer:** Adatok validálása és mesterkatalógusba helyezés
+
+## ✅ Ellenőrzés:
+
+A `sudo docker exec roo-helper python3 /scripts/gitea_manager.py list` parancs kiírta, hogy mind az 5 kártya aktív és a megfelelő mérföldkőhöz (EPIC 9) van rendelve. A kártyák tartalma követi a szigorú Gitea sablont, beleértve a Mérföldkő, Cél, Függőségek és Elemzés szekciókat.
+
+Az EPIC 9 és mind az 5 kártya sikeresen létrejött a Gitea-ban, készen állnak a fejlesztés megkezdésére.