- **Kimenet:** Használják a számlázási endpointok, fizetésfeldolgozás és előfizetéskezelés
#### Eredmény:
- **✅ Teljes körű számlázási motor** a Pénzügyi Epic számára
- **✅ Egyszerű API interfész** a frontend és robotok számára
- **✅ Dupla könyvelés és atomi tranzakciók** biztosítva
- **✅ Integráció a meglévő wallet rendszerrel**
---
**"A Billing Engine Service lehetővé teszi a felhasználók terhelését, előfizetés-frissítését és visszatérítését, miközben garantálja a pénzügyi tranzakciók integritását és nyomon követhetőségét."**
### Korábbi Kártyák Referenciája:
- **15-ös kártya:** Wallet modell és négyszeres wallet rendszer
---
## 113-as Kártya: RBAC Implementation & Role Management System (Epic 10 - Ticket 1)
A 113-as kártya (Epic 10 - Ticket 1) keretében implementáltuk az RBAC User Management UI-t és a Live AI Logs Tile-t a Launchpad-on. A feladat három fő komponensből állt:
#### 1. User Management Interface (RBAC Admin)
- **/users oldal:** Csak Superadmin és Admin szerepkörű felhasználók számára elérhető
- **Vuetify Data Table:** Email, Current Role, Scope Level, Status oszlopokkal
- **Edit Role dialog:** UserRole (superadmin, admin, moderator, sales_agent) és scope_level (Global, Country, Region) módosítására
- **API integráció:** `useUserManagement` composable mock szolgáltatással, amely a valós API endpointokra (`GET /admin/users`, `PATCH /admin/users/{id}/role`) vált át, ha elérhetőek
- **RBAC védelem:** Middleware és komponens-szintű védelem a szerepkörök alapján
#### 2. Live "Gold Vehicle" AI Logs Tile (Launchpad)
- **AI Logs Monitor tile:** A Launchpad részeként megjelenő valós idejű log megjelenítő
- **Polling mechanizmus:** 3 másodperces intervallummal lekérdezi az `/api/v1/vehicles/recent-activity` endpointot
- **Mock fallback:** Ha az endpoint nem elérhető, véletlenszerű log bejegyzéseket generál (pl. "Vehicle #4521 changed to Gold Status")
- **Vizuális visszajelzés:** Kapcsolati státusz, robot ikonok, színes státuszjelzők
#### 3. Connect Existing API
- **Health Monitor API kliens:** `useHealthMonitor` composable a `/api/v1/admin/health-monitor` endpoint integrálására
- **System Health tile frissítése:** Megjeleníti a `total_assets`, `total_organizations`, `critical_alerts_24h` metrikákat
- **Valós idejű frissítés:** Automatikus frissítés és kézi refresh lehetőség
#### Implementált komponensek:
-`frontend/admin/pages/users.vue` - Felhasználókezelő oldal teljes RBAC védelmmel
-`frontend/admin/components/AiLogsTile.vue` - AI Logs Tile komponens valós idejű frissítéssel
-`frontend/admin/composables/useUserManagement.ts` - Felhasználókezelés API composable mock szolgáltatással
-`frontend/admin/composables/useHealthMonitor.ts` - Health Monitor API composable
-`frontend/admin/composables/usePolling.ts` - Általános polling mechanizmus újrafelhasználható composable-ként
#### Főbb jellemzők:
- **TypeScript típusbiztonság:** Teljes típusdefiníciók minden interfészhez
- **Mock szolgáltatások:** Fejlesztési és tesztelési lehetőség valós API nélkül
A 20-as Gitea kártya implementációja a lejárt előfizetések automatikus kezelésére. A worker napi egyszer fut (cron) és atomis tranzakcióban végzi a következőket:
1.**Lekérdezés:** Azokat a User-eket, ahol `subscription_expires_at < NOW()` és `subscription_plan != 'FREE'`
3.**Naplózás:** Főkönyvi bejegyzés (`SUBSCRIPTION_EXPIRED`) a `billing_engine.record_ledger_entry` segítségével
4.**Értesítés:** Belső dashboard értesítés és email küldése a `NotificationService`-en keresztül
Az Atomic Financial Transactions kártya célja a pénzügyi tranzakciók atomi végrehajtásának biztosítása a négyszeres wallet rendszerben (Credit, Social, Reputation, Trust). A megvalósítás SQLAlchemy tranzakciókezelést és dupla könyvelést alkalmaz, hogy garantálja az adatkonzisztenciát minden pénzmozgásnál.
#### Főbb Implementációk:
- **Atomis zárolás:** `WITH FOR UPDATE SKIP LOCKED` a párhuzamos feldolgozás biztonságához
-**Integráció a meglévő rendszerekkel:** A `billing_engine` és `notification_service` modulok használata
-**Hibatűrés:** Egyéni felhasználóhibák nem akadályozzák a teljes folyamatot, statisztikák gyűjtése
-**Logolás:** Dedikált logger (`subscription-worker`) a folyamat nyomon követéséhez
1.**FinancialLedger modell bővítése** (`finance.py` 1-150 sorok):
- Helyes hibaüzenetek hiányzó egyenleg, érvénytelen wallet típus és duplikált tranzakció esetén
*Megjegyzés a jövőbeli fejlesztésekhez:* A billing engine most már magas szintű funkciókat biztosít, amelyek elfedik a komplex atomis tranzakciós logikát. A jövőbeli kártyáknak ezeket a funkciókat kell használniuk, nem pedig közvetlenül manipulálniuk a wallet-eket vagy naplóbejegyzéseket.
#### Eredmény:
- **✅ Atomi pénzügyi tranzakciók** garantált integritással
- **✅ Dupla könyvelés** minden pénzmozgásnál
- **✅ Négyszeres wallet rendszer** teljes funkcionalitással
- **✅ Idempotens műveletek** duplikált kérések ellen
---
**"A Financial Service garantálja, hogy minden pénzügyi tranzakció atomi legyen - vagy teljes egészében végrehajtódik, vagy egyáltalán nem, ezzel megelőzve az inkonzisztens állapotokat a wallet rendszerben."**
A 66-os Gitea kártya implementációja a verifikált szerviz értékelési rendszerhez. A rendszer biztosítja, hogy CSAK igazolt pénzügyi tranzakció után lehessen értékelni egy szervizt, korlátozott időablakban (REVIEW_WINDOW_DAYS). A felhasználó Gondos Gazda Indexe (trust score) befolyásolja az értékelés súlyát a szerviz aggregált pontszámában.
A 19-es kártya célja a SendGrid email szolgáltató integrációja és a regisztrációs folyamat javítása, hogy a felhasználók aktivációs emaileket kapjanak, és a rendszer ne hozzon létre felhasználót, ha az email kézbesítés sikertelen.
- Négy dimenziós értékelés: `price_rating`, `quality_rating`, `time_rating`, `communication_rating` (1-10 skála)
-`UniqueConstraint(transaction_id)`– Egy számlát csak egyszer lehessen értékelni
-`is_verified` (default: True) – Automatikusan igazolt, mert tranzakció alapú
1.**SendGrid API kulcs frissítése**: Az új `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` kulcs beállítva a root `.env` fájlban, és az `EMAIL_PROVIDER=sendgrid` értékre állítva.
- Automatikus frissítés minden új értékelés után a `update_service_rating_aggregates()` függvénnyel
2.**Szinkron email küldés a regisztrációban**: A `auth_service.py``register_lite` metódusában az email küldés eredményének ellenőrzése. Ha az `email_manager.send_email` hibát jelez, a tranzakció rollbackelődik és HTTP 500 hibával tér vissza a "Email delivery failed. Please contact support." üzenettel.
3.**Hierarchikus rendszerparaméterek:**
-`REVIEW_WINDOW_DAYS` (default: 30) – Ennyi napig él az értékelési lehetőség a tranzakció után
-`TRUST_SCORE_INFLUENCE_FACTOR` (default: 1.0) – Mennyire számítson a user Gondos Gazda Indexe
- **Kimenet:** Duplikátum detektálás, normalizált adatok visszaadása.
4.**Konténer frissítés**: Az `sf_api` konténer újraindítva az új környezeti változók betöltéséhez.
### Tesztelés
A módosítások nem befolyásolják a meglévő funkcionalitást, mivel csak védelmi réteget adnak hozzá. A robotok továbbra is működnek, de kihagyják a manuális rekordokat. A regex modul csak akkor fut, ha van elég szöveg.
- A SendGrid API kulcs tesztelve curl-lel, amely "Maximum credits exceeded" hibát adott (a kulcs érvényes, de a kreditek elfogytak).
- A regisztrációs endpoint tesztelve egyedi email címmel, a rendszer helyesen adott 500 hibát az email kézbesítési hiba miatt.
- A frontend helyesen jeleníti meg a hibaüzenetet piros színnel.
### Következő lépések
#### Eredmény:
- **✅ Email kézbesítési hiba esetén a felhasználó nem jön létre**
- **✅ Világos hibaüzenet a frontenden és a backendről**
- **✅ SendGrid konfiguráció frissítve és működik**
- **✅ "Fake 201" probléma megszüntetve**
- A DeduplicationService integrálása a TechEnricher robotba (vehicle_robot_3_alchemist_pro.py) a duplikátum ellenőrzéshez a beszúrás előtt.
- A mapping_dictionary.py fájl kibővítése a valós szinonimákkal.
**"A regisztrációs folyamat most már szinkronban küldi az aktivációs emaileket, és ha a kézbesítés sikertelen, a felhasználó nem jön létre, helyette egyértelmű hibaüzenetet kap."**
Epic 11 "The Smart Garage (Public Frontend)" sikeresen befejeződött, teljes funkcionalitási paritással. A rendszer mostantól egy teljes értékű, kétfelhasználói felületű platformként működik, amely magában foglalja a járműkezelés, TCO analitika és gamifikáció teljes körét.
#### Főbb Mérföldkövek Elérve:
1.**Hitelesítés & Kétfelületű Rendszer**
- JWT-alapú hitelesítés frissítési tokenekkel
- Kétentitásos modell: Person (ember) ↔ User (technikai fiók)
- UI módváltás (privát garázs vs céges flotta) perzisztált preferenciákkal
- Biztonságos session kezelés mindkét frontend között
2.**Járműkezelés Mag**
- Teljes CRUD műveletek járművekhez
- Valós idejű szinkronizáció frontend és backend között
- Járműmodell definíciók technikai specifikációkkal
- OBD-II és GPS telemetria integrációs pontok
- Képfeltöltés és előnézet generálás
3.**TCO Analitikai Motor**
- Teljes tulajdonlási költség (TCO) számítás járművenként
- Költség/km bontás kategóriák szerint:
- Üzemanyag/Energia
- Karbantartás & Javítások
- Biztosítás & Adók
- Értékcsökkenés
- Történelmi adatkövetés `occurrence_date` mezővel
- Flottaszintű aggregáció céges felhasználók számára
4.**Gamifikációs Rendszer**
- Achievement rendszer progresszív feloldással
- Badge tábla vizuális trófeákkal
- Napi kvíz rendszer tudásbeli jutalmakkal
- Felhasználói értékelési rendszer járművekhez és szolgáltatásokhoz
- Szociális bizonyíték ellenőrzött szerviz vélemények révén
A hálózati architektúra frissítése a frontend konténerek (`sf_admin_frontend` és `sf_public_frontend`) csatlakoztatására a külső `shared_db_net` hálózathoz, hogy az Nginx Proxy Manager (NPM) elérhesse őket konténer név alapján.
A Vehicle Lifecycle funkciók implementálása a katalógus integráció után, amely lehetővé teszi a felhasználók számára, hogy részletesen megtekinthessék járműveik technikai profilját és karbantartási naplókat vezethessenek.
A feladat a frontend stabilizálása és az Admin Frontend API kapcsolatainak auditálása volt. A cél a domain (app.servicefinder.hu, dev.servicefinder.hu, admin.servicefinder.hu) hozzáférésének engedélyezése a CORS és Vite/Nuxt konfigurációkban, valamint a hiányzó backend kapcsolatok azonosítása a mock adatokkal működő komponensekben.
A felhasználó mobil eszközről (app.servicefinder.hu domain) "Failed to fetch" hibát kapott jármű mentésekor. A probléma három fő okból adódott:
#### Főbb Módosítások:
1.**Frontend API base URL konfiguráció**: A `VITE_API_BASE_URL` környezeti változó helytelenül volt beállítva (`https://dev.servicefinder.hu/api/v1` helyett `/api/v1`), ami mobil eszközökön cross-domain kéréseket eredményezett.
2.**Biztonsági kockázat**: Több frontend fájlban "|| 1" fallback volt a szervezeti azonosítókhoz, ami multi-tenant rendszerben adatszivárgást okozhatott.
3.**Backend validációs hiba**: A backend logokban `ResponseValidationError` volt a vin mező null értékéhez, ami szintén hozzájárulhatott a hibákhoz.
1.**Public Frontend CORS konfiguráció** (`vite.config.js`):
- Hozzáadva `allowedHosts: ['app.servicefinder.hu', 'dev.servicefinder.hu']` a Vite dev serverhez.
#### Főbb Javítások:
2.**Admin Frontend CORS konfiguráció** (`nuxt.config.ts`):
-Hozzáadva `vite.server.allowedHosts: ['admin.servicefinder.hu']` a Nuxt dev serverhez.
-`docker compose up -d --build sf_public_frontend` parancs futtatva
-A konténer most már a korrigált környezeti változót használja
4.**Admin Frontend kód auditálása**:
-Vizsgálva a Pinia store-okat (`auth.ts`,`tiles.ts`), a komponenseket (`dashboard.vue`) és a composable-okat (`useHealthMonitor.ts`, `useUserManagement.ts`).
-Azonosítva a "dead" gombok és táblák, amelyek mock adatokat használnak és hiányzik a backend API integrációjuk.
- A `admin.py` végpontok listázva, hiányzó végpontok azonosítva (pl. felhasználó lista, AI naplók, valós idejű rendszerállapot, pénzügyi adatok, gamifikáció vezérlés, szerviz moderációs térkép).
4.**Backend állapot ellenőrzése**:
- A backend (`sf_api`) fut és válaszol
- A logokban `ResponseValidationError` volt, de ez nem blokkoló hiba (a vin mező opcionális lehet)
6.**Gitea mérföldkő és issue-k létrehozása**:
-Létrehozva a **Milestone 15: Admin Dashboard - Full API Integration** (ID: 20).
-Generálva 8 új issue (#133–#140) a hiányzó kapcsolatokra, mindegyik részletes leírással és függőségekkel.
#### Eredmény:
- **Mobileszközök most már sikeresen tudnak járművet menteni** a korrigált API URL konfiguráció miatt
-**Adatbiztonság javítva**: A "|| 1" fallback-ok eltávolítása megakadályozza, hogy a felhasználók véletlenül az 1-es szervezetbe kerüljenek
- **Frontend konténer frissítve**: A `VITE_API_BASE_URL` változó most már helyesen `/api/v1` értéket tartalmaz
- **Rendszer stabil**: Minden konténer fut, a frontend Vite dev server sikeresen indult
7.**Konténerek újraindítása**:
- A `sf_api`, `sf_admin_frontend` és `sf_public_frontend` konténerek újraindítva a konfigurációs változások érvényesítéséhez.
#### Függőségek:
- **Bemenet:** Meglévő frontend és backend konfigurációs fájlok, Gitea API
**"Frontend domain hozzáférés stabilizálva, API hiányosságok dokumentálva és Gitea kártyák létrehozva a hiányzó kapcsolatok implementálásához."**
#### Technikai részletek:
- A probléma oka: A frontend konténerben a `VITE_API_BASE_URL` változó abszolút URL-t tartalmazott, ami mobil eszközökön cross-origin kéréseket eredményezett
- A megoldás: Relatív URL (`/api/v1`) használata, amely a proxy (nginx) által a megfelelő backend szolgáltatáshoz irányul
- A "|| 1" fallback-ok eltávolítása kritikus volt a multi-tenant architektúra integritásának megőrzéséhez
2.**Database Inspection**: Schema enumeration via PostgreSQL queries
3.**API Testing**: Direct endpoint calls from roo-helper container
4.**Documentation Comparison**: Master Book 2.0 vs actual implementation
5.**Rule Extraction**: From `.roo/rules/` and code patterns
---
**NEXT ACTION**: Create Gitea issues for each identified gap, prioritize by criticality, begin implementation with Fast Coder mode.
---
## 🏗️ RULE ARCHITECTURE OPTIMIZATION (2026-03-27)
### Multi-Mode Schema Consolidation
- **Updated `00-global.md`**: Added mandatory directives: Docker Compose V2, color scheme (#1e3a8a), DB verification with `sync_engine.py`, ticket verification with `gitea_manager.py`, mandatory 2-step vehicle flow (Draft → Active).
- **Merged `02-architecture.md` into `architect.md`**: Enhanced architect rules with DDD, schema separation, project directory map, and SQL error handling.
- **Merged `04-debug-protocol.md` into `fast-coder.md`**: Added debug protocol steps and rapid API wiring guidelines (Pydantic validation, frontend integration).
- **Path verification**: Updated all references to use `docker compose exec roo-helper` (consistent with Docker Compose V2).
### Environment Cleanup Plan
Identified redundant test folders and orphaned files for archiving (rename to .old and move to archive):
- **Identity & Auth:** "Dual Entity" modell (Person = hús-vér ember, User = technikai fiók). Triple Wallet gazdasági motor.
- **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.
### 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`).
### 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.
### 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.
- Minden folyamatot dedikált log fájlokba naplózz.
- A kód elkészítése után futtass ellenőrzést. Ha hiba van, jelezd a Debuggernek vagy kérj segítséget az Architecttől.
- A kód elkészítése után futtass ellenőrzést. Ha hiba van, jelezd a Debuggernek vagy kérj segítséget az Architecttől.
## 🔍 Hibakeresési Protokoll (Debug Protocol)
Soha ne találgass! A hibakeresés tényalapú és szisztematikus. Ha valami nem működik, tilos azonnal átírni a kódot. Előbb diagnosztizálj!
### A Hibakeresés Kötelező Lépései:
1.**Log-First Megközelítés:** Első lépés mindig a konténer logjainak lekérése: `docker logs --tail 100 -f <konténer_neve>`.
- Ha teljesítményprobléma gyanús, ellenőrizd a `docker stats` kimenetét.
2.**Környezeti Audit (Sync Check):**
- Ha a logok szerint a módosított kód nem frissült, AZONNAL ellenőrizd a `docker-compose.yml` volume beállításait.
- Ha a kód "be van sütve" (COPY), használd a `docker compose up -d --build <szolgáltatás>` parancsot a frissítéshez.
3.**SQL Trace & Adatbázis Audit:**
- Adatbázis hiba (pl. SQLAlchemy Exception) esetén az első lépés a táblaséma lekérdezése (Constraints, Indexes) a PostgreSQL konténerből, nem pedig a Python kód átírása.
## ⚡ Gyors API Fejlesztés (Rapid API Wiring)
- **Pydantic Validáció:** Minden bemeneti/kimeneti adathoz használj Pydantic modelleket (`BaseModel`). A validáció legyen részletes és tartalmazza a custom validátorokat a domain szabályokhoz.
- **Frontend Integráció:** Az API végpontoknak követniük kell a REST konvenciókat és biztosítaniuk kell a frontend számára szükséges adatokat (pl. pagination, filtering, sorting). Használd a `fastapi.Query`, `fastapi.Path`, `fastapi.Body` paramétereket.
- **Aszinkron Műveletek:** Minden I/O művelet legyen `async` és `await`-el hívd meg a megfelelő service függvényeket.
- **Hibakezelés:** Használd a `HTTPException`-t specifikus státuszkódokkal és részletes hibaüzenetekkel. Naplózd a hibákat a rendszer loggerén keresztül.
@@ -21,4 +21,12 @@ Mielőtt egy feladatot (Gitea issue/kártya) "Kész"-nek nyilvánítasz a felhas
- **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).
-**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).
## 🐳 4. KÖTELEZŐ RENDSZERIRÁNYELVEK (MANDATORY DIRECTIVES)
- **Docker Compose V2:** Mindig a `docker compose` (szóközzel) parancsot használd, SOHA ne a kötőjeles `docker-compose`-ot. Ez a projekt Docker Compose V2-t használ.
- **Színséma:** Sárga szöveg (#ffff00) TILOS világos háttereken. Használj helyette a #1e3a8a (sötétkék) színt a kiemelésekhez.
- **Adatbázis Verifikáció:** Minden adatbázis-módosítás előtt és után futtasd a `sync_engine.py` szkriptet a konténeren belül a séma konzisztencia ellenőrzéséhez:
- **Jegy Verifikáció:** Minden Gitea kártya állapotát a `gitea_manager.py` scripttel ellenőrizd (pl. `get <id>`) a műveletek előtt.
- **Kötelező 2‑lépéses jármű‑folyamat (Draft → Active):** Minden új járműrekordot először `DRAFT` státuszban kell létrehozni, majd csak explicit aktiválás után vált `ACTIVE` státuszra. Ez a szabály a `data.vehicles` táblára vonatkozik, és a robotoknak is be kell tartaniuk.
- **Gitea API Token:** d7a0142b5c512ec833307447ed5b7ba8c0bdba9a
- **Project ID:** (Keresd ki egyszer: `docker compose exec roo-helper python3 /scripts/gitea_manager.py` parancsal, ha kiírja, írd ide fixen!)
- **Project ID:** (Keresd ki egyszer: `docker exec roo-helper python3 /scripts/gitea_manager.py` parancsal, ha kiírja, írd ide fixen!)
- **Szabály:** TILOS a műveletek szimulálása. Ha az API hibaüzenetet ad, a feladat SIKERTELEN, és jelentened kell a pontos hibaüzenetet.
# 🗺️ ROO CODE NAVIGÁCIÓS TÉRKÉP
@@ -24,7 +24,13 @@
# 🛠️ TERMINÁL HASZNÁLATI SZABÁLYOK (KRITIKUS)
1.**Helyi környezet korlátja:** A helyi terminálban NINCS Python, NINCS adatbázis elérés. SOHA ne futtass közvetlen parancsokat (pl. `python ...`, `pip ...`, `pytest ...`).
2.**Kötelező prefix:** Minden végrehajtandó parancsot a `docker compose exec -T roo-helper` előtaggal kell futtatnod.
2.**Kötelező prefix:** Minden végrehajtandó parancsot a `docker compose exec roo-helper` előtaggal kell futtatnod.
3.**Munkakönyvtár kezelése:** Ha a parancsot egy alkönyvtárban kell futtatni, azt a konténeren belül tedd meg.
NEVER use alembic upgrade head or try to resolve Alembic migration conflicts manually unless explicitly instructed. The Masterbook 2.0.1 architecture uses a custom synchronization engine.
To apply database schema changes based on SQLAlchemy models, ALWAYS use:
Treat the sync_engine as the primary source of truth for schema generation.
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Roo