livrare lot 2

backend/docs/00_INDEX_Dosar_Livrare_Lot2.md

@@ -0,0 +1,51 @@
+% Dosar de livrare — DiDi Lot 2 (Backend)
+% Platformă digitală inteligentă pentru prevenirea și combaterea dezinformării
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# Cuprinsul dosarului de livrare
+
+Prezentul dosar documentează livrarea **Lotului 2 — Aplicație software backend** a platformei
+DiDi. Documentele sunt corelate cu **Propunerea Tehnică Lot 2** (9 module) și cu caietul de
+sarcini.
+
+| # | Document | Conținut |
+|---|---|---|
+| 00 | **INDEX Dosar Livrare** (acest fișier) | Cuprins + stare livrare |
+| 01 | **Arhitectură Lot 2** | Arhitectura pe 3 straturi, fluxuri, model de date, integrarea cu Lot 1 |
+| 02 | **Ghid Instalare & Operare** | Instalare de la zero (`build-local.sh`), operare, comenzi |
+| 03 | **Raport Testare API** | 374/374 endpoint-uri cablate, securitate, OpenAPI validat |
+| 04 | **Raport Testare Integrare Lot1↔Lot2** | 9/9 servicii AI, 5/5 analize E2E, fail-open, 1 defect remediat |
+| 05 | **Ghid de Utilizare** | Tur al platformei cu capturi reale, mapat pe module |
+| 06 | **Matrice Trasabilitate Cerințe** | Cerințe caiet + ofertă → livrabil/dovadă |
+| 07 | **Specificații API** | Structura celor 2 API-uri (374 op.), Swagger, `x-integrations` |
+| — | **openapi.yaml** (×2) | Specificațiile OpenAPI 3.0.3 mașinabile (agent-v3 + framework) |
+| — | **scripts/integration/** | Harness reproductibil de testare a integrării + dovezi |
+
+---
+
+# Stare livrare (sinteză)
+
+| Indicator | Valoare |
+|---|---|
+| Module ofertă acoperite | **9 / 9** |
+| Endpoint-uri API cablate | **374 / 374** |
+| Integrări cu Lotul 1 verificate | **9 / 9** |
+| Analize end-to-end (tipuri de conținut) | **5 / 5** (text, URL, imagine, audio, video) |
+| Teste de integrare | **16 PASS · 1 DEGRADED (fail-open, corect) · 0 FAIL** |
+| Defecte găsite în testare | 1 — remediat și întărit |
+| Servicii live (moment recepție) | toate `healthy` |
+
+---
+
+# Acces platformă (mediu de recepție)
+
+| Resursă | Adresă | Acces |
+|---|---|---|
+| Dashboard administrativ | `https://<HOST_IP>:3001/admin` | `admin` / `Admin12345` (realm `didi-admins`) |
+| API Agent V3 | `:24803` (prin Kong `/agent-v3/*`) | JWT Bearer |
+| API didiFramework | `:3005` (prin Kong `/framework/*`) | JWT Bearer |
+| Health integrare | `GET /api/v3/health/all` | infra + 9 servicii Lot 1 |
+
+Toate documentele sunt livrate în format Markdown (sursă) și `.docx` (pentru dosar).

backend/docs/01_Arhitectura_Lot2.md

@@ -0,0 +1,245 @@
+% Documentație de arhitectură — DiDi Lot 2 (Backend)
+% Platformă digitală inteligentă pentru prevenirea și combaterea dezinformării
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# 1. Scop și context
+
+Prezentul document descrie arhitectura tehnică a **Lotului 2 — Aplicație software backend**
+din cadrul platformei DiDi, sistem de detecție a dezinformării dezvoltat în cadrul
+proiectului PNRR DIGI150. Backendul primește conținut (text, URL, imagine, audio, video),
+îl analizează pe patru dimensiuni independente și produce un verdict de risc cu scor
+(0–100) și explicație bilingvă (RO/EN).
+
+Lotul 2 acoperă **coloana vertebrală software** a platformei: orchestrarea analizei,
+brokerul de mesaje, gateway-ul de API, baza de date, autentificarea, dashboard-ul
+administrativ, observabilitatea și livrarea cloud-native. Serviciile de inteligență
+artificială propriu-zise (modele LLM, deepfake, transcriere, extractori) sunt furnizate
+de **Lotul 1 (Platforma AI)** și sunt consumate de backend prin interfețe HTTP configurabile
+(vezi §9).
+
+---
+
+# 2. Vedere de ansamblu — arhitectură pe trei straturi
+
+```
+┌──────────────────────────────────────────────────────────────────────┐
+│  STRAT 3 — Gateway & Autentificare                                     │
+│  Kong API Gateway (JWT RS256) · Keycloak (OIDC, realms clients/admins) │
+├──────────────────────────────────────────────────────────────────────┤
+│  STRAT 2 — Orchestrare                                                  │
+│  Agent V3 (:24803) — motor de analiză, dispatch async                  │
+│  didiFramework (:3005) — CRUD parametri + sync Redis                    │
+│  Workeri (techniques ×2, ai-tampered ×2, claims ×3, domain ×2,         │
+│           media-preprocess ×2, verdict-aggregator ×2)                  │
+│  Admin Dashboard (React) — configurare, monitorizare, moderare         │
+├──────────────────────────────────────────────────────────────────────┤
+│  STRAT 1 — Date                                                        │
+│  PostgreSQL 17 · Redis 7 · RabbitMQ 3.12 · MinIO (S3)                  │
+├──────────────────────────────────────────────────────────────────────┤
+│  Observabilitate transversală                                          │
+│  Prometheus · Grafana · Loki · OpenTelemetry · Jaeger · Alertmanager  │
+└──────────────────────────────────────────────────────────────────────┘
+```
+
+Principiul de proiectare: **separarea configurării de execuție**. Toți parametrii de
+analiză (tehnici, ponderi, verdicte, modele LLM, prompturi, profiluri de pipeline) sunt
+gestionați declarativ prin `didiFramework` și stocați în PostgreSQL, apoi sincronizați în
+Redis. Motorul de analiză (`agent-v3`) citește configurarea din Redis la fiecare rulare —
+astfel comportamentul se modifică fără redeploy de cod.
+
+---
+
+# 3. Componentele principale
+
+## 3.1 Agent V3 — motorul de analiză (port 24803)
+
+Serviciul central. Node.js + TypeScript + Express 5. Expune API-ul de analiză (toate
+endpoint-urile de analiză sunt **asincrone**: dispatch pe RabbitMQ, răspuns `202` + poll).
+
+Rulează patru componente de analiză independente + un calculator de verdict:
+
+| Componentă | Ce detectează | Scor |
+|---|---|---|
+| **Techniques** | tehnici de manipulare (166 tehnici, 8 dimensiuni) | manipulation_score 0–100 |
+| **AI-Tampered** | conținut generat/modificat de AI | ai_probability 0–100 |
+| **Claims** | afirmații verificate prin căutare web | credibility_score 0–100 |
+| **Source Assessment** | credibilitatea sursei/domeniului | trust_score 0–100 |
+| **Verdict** | agregare ponderată → risc final + explicație RO/EN | risk_score 0–100 |
+
+Fiecare componentă (mai puțin Domain) rulează în două etape: **screening** (analiză rapidă)
+→ **deep analysis** (analiză detaliată). Fiecare etapă are un lanț de modele LLM cu până la
+3 nivele de fallback.
+
+## 3.2 didiFramework — managementul parametrilor (port 3005)
+
+Node.js + TypeScript + Express 4. API CRUD pentru toți parametrii platformei (peste 280 de
+endpoint-uri). Stochează configurarea în PostgreSQL (schema `bos_parammgmt`) și o
+sincronizează în Redis prin `POST /api/sync-redis` (~51 chei de configurare). Gestionează de
+asemenea utilizatorii, creditele, abonamentele și integrarea cu Keycloak.
+
+## 3.3 Admin Dashboard
+
+Aplicație React 19 + Material UI. Interfață pentru: configurarea framework-ului de analiză,
+managementul modelelor LLM (chain-uri free/premium), utilizatori, istoric analize, coada de
+moderare umană (HIL), editorul de pipeline-uri și consola de rulare.
+
+## 3.4 Kong API Gateway
+
+Punctul unic de intrare pentru traficul extern. Mod DBless (configurație declarativă).
+Aplică validarea JWT (RS256, contra JWKS-ului Keycloak), rate limiting, CORS, transformări
+de request/response și limitare de dimensiune. Rutează `/api/v3/*` → agent-v3 și `/api/*` →
+didiFramework.
+
+## 3.5 Keycloak
+
+Serviciul de autentificare OIDC/OAuth2. Două realm-uri: `didi-clients` (utilizatori finali)
+și `didi-admins` (operatori). Emite token-uri JWT RS256, aplică politici de parolă, protecție
+brute-force și MFA (TOTP).
+
+## 3.6 Stratul de date
+
+- **PostgreSQL 17** — sursa de adevăr. 4 scheme: `bos_parammgmt` (parametri), `bos_analysis`
+  (rezultate), `bos_sysadmin` (utilizatori), `bos_subscriber` (date personale).
+- **Redis 7** — cache derivat din PostgreSQL (configurare) + stare de sesiune (TTL 7 zile) +
+  lock-uri workeri.
+- **RabbitMQ 3.12** — cozi async (4 componente × 6 planuri de prioritate + media-preprocess
+  + results + DLQ).
+- **MinIO** — stocare fișiere media (S3-compatibil).
+
+---
+
+# 4. Fluxul de date
+
+## 4.1 Analiză asincronă (fluxul principal)
+
+```
+Client → Kong (validare JWT) → agent-v3 :24803
+  │  validare input + verificare credite (didiFramework)
+  ▼
+Dispatcher → publică task-uri în RabbitMQ (prioritate din planul de abonament)
+  ▼  răspuns 202: { session_id, poll_url, result_url }
+
+--- în paralel, workeri Docker ---
+Worker Techniques   ┐
+Worker AI-Tampered  ├─ consumă din coadă → rulează executor → publică rezultat
+Worker Claims       │
+Worker Domain       ┘
+  ▼
+Verdict Aggregator → așteaptă toate componentele → VerdictCalculator (funcție pură)
+                   → explicație LLM (RO/EN) → persistă în PostgreSQL + Redis
+  ▼
+Client face poll: GET /:sessionId/queue-status → progres
+                  GET /:sessionId/result → AnalysisSession completă
+```
+
+## 4.2 Analiză media (video/audio/imagine)
+
+Un worker dedicat `media-preprocess` centralizează descărcarea, extragerea cadrelor
+(ffmpeg), transcrierea (Whisper) și analiza vizuală (o singură dată), apoi dispecerizează
+componentele de analiză care citesc rezultatele din cache-ul Redis — evitând reprocesarea.
+
+## 4.3 Pipeline = workflow cu dependențe explicite
+
+Fluxul de analiză este modelat ca **workflow cu dependențe explicite** (conform caietului,
+„DAG *sau* workflow"):
+
+```
+intake → [media_preprocess] → {techniques ∥ ai_tampered ∥ claims ∥ domain} → verdict → persist
+```
+
+Variantele de pipeline per tip de conținut sunt definite prin `input_type_profile`
+(6 profiluri: text_no_url, text_with_url, image, audio, video, url), fiecare cu ponderi,
+reguli de override și reguli INCONCLUSIVE proprii. Endpoint-ul `POST /dry-run` rezolvă
+întregul plan (noduri, dependențe, cozi, lanțuri de modele) fără a consuma resurse.
+
+---
+
+# 5. Securitate
+
+- **Autentificare:** JWT RS256 emise de Keycloak. Verificate criptografic **atât la gateway
+  (Kong)** cât și **în backend** (agent-v3 + didiFramework) — apărare în adâncime; un token
+  forjat/expirat este respins cu 401 pe orice cale.
+- **Autorizare (RBAC):** roluri Keycloak (`admin`, `moderator`, `senior_moderator`, `viewer`).
+  Endpoint-urile sensibile (istoric admin, moderare) impun rol.
+- **Izolarea tier-urilor:** tier-ul (free/premium) este derivat exclusiv din planul de
+  abonament returnat de didiFramework, nu din body-ul cererii — previne escaladarea de
+  privilegii.
+- **TLS** pe dashboard-ul administrativ; secretele sunt în fișiere `.env` (excluse din
+  versionare).
+
+---
+
+# 6. Scalare și reziliență
+
+- **Scalare workeri configurabilă:** `scale-workers.sh` (status/set/auto pe metrica
+  `didi_queue_depth` din Prometheus).
+- **Broker rezilient:** publisher confirms (așteaptă ACK-ul broker-ului), re-subscribe
+  automat la reconectare, DLQ cu monitor + alertă.
+- **HA PostgreSQL:** livrat ca IaC reproductibil (Patroni + etcd + HAProxy) în
+  `didiDatabase/ha-cluster/`, cu drill de failover.
+- **Fail-open pe servicii AI:** orice eroare a unui serviciu Lot 1 (timeout, indisponibil)
+  nu blochează analiza — se continuă cu fallback.
+
+---
+
+# 7. Tehnologii
+
+| Componentă | Tehnologie |
+|---|---|
+| Agent V3 | Node.js, TypeScript, Express 5 |
+| didiFramework | Node.js, TypeScript, Express 4 |
+| Admin Dashboard | React 19, Material UI 7, TypeScript |
+| Bază de date | PostgreSQL 17 (+ Patroni/HAProxy pentru HA) |
+| Cache | Redis 7 |
+| Coadă | RabbitMQ 3.12 |
+| Stocare | MinIO (S3-compatibil) |
+| Gateway | Kong 3.9 (DBless) |
+| Autentificare | Keycloak 26 |
+| Observabilitate | Prometheus, Grafana, Loki, OpenTelemetry, Jaeger, Alertmanager |
+| CI/CD | GitLab CI (build/test/publish + rollback + health-gate) |
+
+---
+
+# 8. Modelul de date (rezumat)
+
+**PostgreSQL — schema `bos_analysis`** (rezultatele analizelor): `analysis_session` (rădăcină)
++ câte un tabel per componentă (`analysis_techniques`, `analysis_ai_tampered`,
+`analysis_claims`, `analysis_domain`, `analysis_verdict`) + `moderation_queue` (coada HIL).
+
+**PostgreSQL — schema `bos_parammgmt`** (parametri, ~40 tabele): ierarhia de tehnici
+(dimensiuni → subdimensiuni → tehnici → indicatori), verdicte, ponderi, surse, claims,
+provideri și modele LLM, `component_stage_assignment` (chain-uri model per etapă și tier),
+`component_prompt`, `input_type_profile`.
+
+**Redis:** chei `didi:framework:*` și `didi:config:*` (configurare, permanente) + chei
+`didi:pipeline:*` (sesiuni, TTL 7 zile) + chei `didi:queue:*` (stare workeri, TTL scurt).
+
+---
+
+# 9. Integrarea cu Lotul 1 (Platforma AI)
+
+Agent V3 consumă serviciile Lotului 1 prin interfețe HTTP, cu **URL-uri configurabile din
+mediu** (`.env`). Pe orice deployment se ajustează doar host-urile.
+
+| Variabilă env | Serviciu Lot 1 | Rol |
+|---|---|---|
+| `LLM_ROUTER_URL` | llm-inference | modele LLM text (Qwen) + OCR |
+| `VISION_LLM_URL` | vision | analiză imagine / cadre video |
+| `DIDI_BRAIN_URL` | brain | cache de verificare + RAG (fact-checking) |
+| `VIDEO_ANALYSIS_URL` | video / BusterX | detecție deepfake video |
+| `EXTRACTORS_URL` | extractors | EXIF, ELA, spectrogramă, NER, YOLO, OCR |
+| `FORENSIC_API_URL` | forensic | trăsături forensice media |
+| `M17_WHISPER_URL` | audio | transcriere audio |
+| `M17_WEB_API_URL` | web | căutare web pentru claims/surse |
+| `DOMAIN_CHECK_API_URL` | domain-check | WHOIS/DNS/SSL/blacklist domeniu |
+
+Fiecare integrare este **fail-open**: dacă serviciul Lot 1 nu răspunde, analiza continuă cu
+degradare grațioasă, fără a eșua. Delimitarea responsabilităților: Lotul 2 orchestrează și
+consumă; Lotul 1 furnizează modelele și izolarea execuției (inclusiv sandbox-ul de cod).
+
+---
+
+*Document generat pentru dosarul de recepție Lot 2. Corespondentul tehnic detaliat per
+serviciu se află în fișierele `INDEX.md` din fiecare director de serviciu.*

backend/docs/02_Ghid_Instalare_Operare_Lot2.md

@@ -0,0 +1,188 @@
+% Ghid de instalare și operare — DiDi Lot 2 (Backend)
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# 1. Precondiții
+
+## Software
+- **Docker** ≥ 24 și **Docker Compose v2** (`docker compose version`).
+- `git`, `curl`, `bash`. Fără dependențe de rețea externă pentru pornirea backend-ului.
+
+## Hardware (recomandat, per mașină backend)
+- 8 vCPU, 16 GB RAM, 50 GB disc liber (fără modelele AI, care rulează pe Lotul 1).
+
+## Rețea
+- Backendul rulează self-contained. Pentru analiza AI reală, mașina trebuie să poată accesa
+  serviciile **Lotului 1** (platforma AI) prin URL-urile configurate în `.env` (vezi §5).
+
+---
+
+# 2. Conținutul arhivei livrate
+
+```
+backend/
+├── production/
+│   ├── build-local.sh          ← scriptul principal de instalare
+│   └── .env.example            ← șablon variabile (Redis/Keycloak/Kong)
+├── services/
+│   ├── data-layer/             ← PostgreSQL + Redis + RabbitMQ + MinIO + Keycloak
+│   │   └── didiDatabase/DIDI_full_export_2026-07-02.sql   ← seed baza de date
+│   ├── gateway-auth-layer/     ← Kong + Keycloak (config + realm)
+│   └── orchestration-layer/
+│       ├── agent-v3/           ← motorul de analiză (+ .env.example)
+│       └── didiFramework/      ← CRUD parametri (+ .env.example)
+├── admin-dashboard/            ← interfața administrativă React
+├── observability/              ← Prometheus/Grafana/Loki/OTel
+└── docs/                       ← acest ghid + arhitectură + raport testare
+```
+
+> **Seed-ul bazei de date** (`DIDI_full_export_2026-07-02.sql`, ~23 MB) trebuie să fie prezent
+> în `services/data-layer/didiDatabase/` înainte de instalare. Conține schema completă +
+> datele + toate migrațiile.
+
+---
+
+# 3. Pași de instalare
+
+## Pasul 1 — Pregătește fișierele `.env`
+
+Fiecare serviciu are un `.env.example`. Copiază-l în `.env` și completează secretele
+(valorile marcate `CHANGE_ME`):
+
+```bash
+cd backend
+cp services/orchestration-layer/agent-v3/.env.example services/orchestration-layer/agent-v3/.env
+cp services/orchestration-layer/didiFramework/.env.example services/orchestration-layer/didiFramework/.env
+cp admin-dashboard/.env.example admin-dashboard/.env
+cp production/.env.example production/.env
+```
+
+Secrete de completat în `agent-v3/.env`: cheile LLM (`OPENROUTER_API_KEY`, `OPENAI_API_KEY`,
+`GROQ_API_KEY`, opțional `ANTHROPIC_API_KEY`, `GOOGLE_API_KEY`), tokenul Whisper
+(`M17_WHISPER_TOKEN`), cheile MinIO. **URL-urile Lotului 1** se setează tot aici (vezi §5).
+
+## Pasul 2 — Rulează scriptul de instalare
+
+```bash
+cd backend/production
+chmod +x build-local.sh
+./build-local.sh [hostname]        # implicit: hostname-ul mașinii de deployment
+```
+
+Scriptul ridică toată stiva în ordinea corectă:
+1. rețea Docker `didi-network`;
+2. stratul de date (PostgreSQL + **import automat al seed-ului** la primul boot, Redis,
+   RabbitMQ, MinIO, Keycloak);
+3. Kong (gateway DBless);
+4. didiFramework + **sincronizarea Redis** (încarcă parametrii din PostgreSQL);
+5. agent-v3 + cei 13 workeri;
+6. admin dashboard.
+
+Durata tipică: 5–10 minute (majoritatea = build-ul imaginilor Docker + `npm install`).
+
+## Pasul 3 — Verifică
+
+La final, scriptul afișează un rezumat de health checks. Verificare manuală:
+
+```bash
+docker exec didi-postgres pg_isready -U bos_interface
+docker exec didi-framework wget -qO- http://127.0.0.1:3005/health
+docker exec didi-agent-v3 wget -qO- http://localhost:24803/api/v3/health
+docker exec didi-cache redis-cli -a redis123 --no-auth-warning keys 'didi:framework:*' | wc -l   # aștept 8
+```
+
+---
+
+# 4. Ce pornește (containere)
+
+| Container | Rol | Port |
+|---|---|---|
+| `didi-postgres` | PostgreSQL 17 (baza de date principală) | 5432 |
+| `didi-cache` | Redis 7 | 6379 |
+| `staging-dataLayer-rabbitmq` | RabbitMQ 3.12 | 5672 / 15672 |
+| `staging-dataLayer-minio` | MinIO (S3) | 9000 / 9001 |
+| `didi-keycloak` | Keycloak (OIDC) | 28080 (`/auth`) |
+| `didi-kong` | API Gateway (DBless) | 18000 / 18001 / 18443 |
+| `didi-framework` | CRUD parametri | 3005 (intern) |
+| `didi-agent-v3` | motor de analiză | 24803 |
+| `agent-v3-worker-*` (×11) | workeri componente | — |
+| `verdict-aggregator` (×2) | agregare verdict | — |
+| `didi-admin-local` | admin dashboard | 3081 / 3001 |
+
+---
+
+# 5. Configurarea Lotului 1 (platforma AI)
+
+Agent V3 apelează serviciile AI prin URL-uri din `agent-v3/.env`, blocul „Lot 1 — Platforma
+AI". **Pe mașina unde e instalat și Lotul 1, se ajustează doar host-urile:**
+
+```
+LLM_ROUTER_URL=http://<host-lot1>:14011          # modele LLM text + OCR
+VISION_LLM_URL=http://<host-lot1>:14011           # analiză imagine
+DIDI_BRAIN_URL=http://<host-lot1>:8090            # brain (verification cache + RAG)
+VIDEO_ANALYSIS_URL=http://<host-lot1>:54600       # deepfake video
+EXTRACTORS_URL=http://<host-lot1>:54400           # EXIF/ELA/NER/YOLO/OCR
+FORENSIC_API_URL=http://<host-lot1>:8080          # forensic
+M17_WHISPER_URL=http://<host-lot1>:54300/v1/audio/transcriptions   # transcriere
+M17_WEB_API_URL=http://<host-lot1>:51100          # web search
+DOMAIN_CHECK_API_URL=http://<host-lot1>:11000/api/v1/check/check    # domain check
+```
+
+Dacă Lotul 1 rulează pe **aceeași rețea Docker**, se pot folosi numele de container
+(ex. `http://didiAI-extractors:54400`). Dacă e pe **alt host**, se pune IP-ul.
+
+După modificarea `.env`, se reconstruiește agent-v3:
+```bash
+cd backend/services/orchestration-layer/agent-v3 && docker compose up -d --build
+```
+
+---
+
+# 6. Operare curentă
+
+## Resincronizarea parametrilor în Redis (după orice modificare de config)
+```bash
+docker exec didi-framework wget -qO- --post-data='' http://127.0.0.1:3005/api/sync-redis
+```
+
+## Reconstruirea unui serviciu
+```bash
+# agent-v3 + workeri
+cd backend/services/orchestration-layer/agent-v3 && docker compose up -d --build
+# framework
+cd backend/services/orchestration-layer/didiFramework && docker compose up -d --build
+```
+
+## Scalarea workerilor
+```bash
+cd backend/services/orchestration-layer/agent-v3
+./scale-workers.sh status                # replici + backlog live
+./scale-workers.sh set worker-claims 4   # scalare manuală
+./scale-workers.sh auto --apply          # scalare pe metrici
+```
+
+## Loguri
+```bash
+docker logs -f didi-agent-v3
+docker logs -f didi-framework
+```
+
+## Rebuild bază de date (alt host / reset)
+Vezi rețeta completă în `services/data-layer/didiDatabase/REBUILD.md`.
+
+---
+
+# 7. Depanare
+
+| Simptom | Cauză probabilă | Soluție |
+|---|---|---|
+| Baza DIDI e goală după build | seed absent înainte de primul boot | pune seed-ul + șterge volumul `didi-postgres-data` + re-rulează |
+| Analize eșuează / fără rezultat LLM | chei API lipsă sau Lot 1 inaccesibil | verifică `agent-v3/.env` (chei + URL-uri Lot 1) |
+| `401` pe orice cerere prin Kong | token JWT lipsă/invalid | obține token de la Keycloak; rutele publice (waitlist, verify-email) sunt exceptate |
+| Redis fără chei framework | sync-redis neexecutat | rulează comanda de sync (§6) |
+| Worker „mort" tăcut | reconectare broker | workerii se re-abonează automat; verifică `docker logs` |
+
+---
+
+*Documentul-pereche (operațional, cu inventar de scripturi): `backend/BUILD_AND_SCRIPTS.md`.*

backend/docs/03_Raport_Testare_API_Lot2.md

@@ -0,0 +1,136 @@
+% Raport de testare API — DiDi Lot 2 (Backend)
+% PNRR DIGI150 · contract 11.1.i3.c9
+% Data testării: 2026-07-08
+
+---
+
+# 1. Obiect și scop
+
+Prezentul raport documentează testarea completă a interfețelor de programare (API) ale
+**Lotului 2 — Backend**, respectiv cele două servicii software livrate:
+
+- **Agent V3** (motor de analiză, port 24803);
+- **didiFramework** (management parametri, port 3005).
+
+Testarea acoperă **strict Lotul 2**. Serviciile de inteligență artificială (Lotul 1) sunt
+testate separat, prin testele de integrare rulate pe mediul unde este instalat Lotul 1.
+
+Raportul constituie dovada pentru criteriul 6 din caietul de sarcini („Implementare &
+transfer": OpenAPI/Swagger + set minim de teste API) și însoțește specificațiile
+`openapi.yaml` ale celor două servicii.
+
+---
+
+# 2. Metodologie
+
+1. **Inventar din codul sursă** — toate definițiile de rute au fost extrase automat din cod
+   (nu din documentație), cu un script reproductibil. S-a verificat separat absența rutelor
+   definite dinamic, a mount-urilor cu prefix nescanate și a generatoarelor CRUD active —
+   toate verificările au ieșit goale, deci inventarul static este complet.
+2. **Probă live** — fiecare endpoint a fost apelat pe mediul de testare, cu token JWT real
+   emis de Keycloak. Strategie **non-distructivă**: cererile GET au fost apelate real; cererile
+   POST/PUT/PATCH/DELETE au fost apelate cu identificatori inexistenți sau body gol (răspunsul
+   400/404 dovedește că ruta este cablată, fără a modifica date). Endpoint-urile idempotente
+   (dry-run, sync-redis, check-credits) au fost rulate real; cele cu efect mutativ real au
+   fost verificate manual și consemnate separat.
+3. **Verificare de integritate** — s-a capturat un instantaneu al bazei de date (7 contoare)
+   înainte și după rularea completă: **identic**, confirmând că testarea nu a alterat datele.
+
+---
+
+# 3. Rezultate
+
+| Metric | Valoare |
+|---|---|
+| Endpoint-uri inventariate | **374** |
+| — Agent V3 | 87 |
+| — didiFramework | 287 |
+| Endpoint-uri cablate (răspund cu handler propriu) | **374 / 374** |
+| Rute moarte (`Cannot GET/POST …`) | **0** |
+
+**Distribuția codurilor de răspuns:**
+
+| Cod HTTP | Nr. | Semnificație |
+|---|---|---|
+| 200 | 135 | răspuns corect |
+| 400 | 102 | validare de input (comportament corect pe body/ID de test) |
+| 401 | 4 | necesită autentificare (extension API-key) — corect |
+| 403 | 2 | necesită rol (moderare) — separare de roluri funcțională |
+| 404 | 118 | resursă inexistentă (ID de test) — comportament corect |
+| 409 | 9 | conflict (ex. duplicat) — comportament corect |
+| 500 | 4 | vezi §5 (probleme cunoscute, neblocante) |
+
+Toate codurile 401/403 reflectă **comportament de securitate corect**, nu erori: rutele de
+extensie cer `X-API-Key`; operațiile de moderare (claim/resolve) cer rol
+`moderator`/`senior_moderator`, pe care contul de test (admin) nu îl deține.
+
+---
+
+# 4. Corectări efectuate în urma testării
+
+Testarea a identificat 4 defecte reale (toate de tip ordonare de rute / validare de input),
+reparate și re-testate:
+
+| Endpoint | Defect | Corecție |
+|---|---|---|
+| `GET /api/validation-rules/stats` | 500 — umbrit de ruta `/:id` declarată înainte | reordonare rute |
+| `DELETE /api/indicators/by-technique/:techniqueId` | inaccesibil — umbrit de `/:techniqueId/:indicatorId` | reordonare rute |
+| `POST /api/sync-analysis/batch` | umbrit de `/:sessionId` | reordonare rute |
+| `GET /api/weights/multipliers/type/:type` | 500 pe input non-numeric | validare → 400 |
+
+Suplimentar, s-a rulat un scan sistematic de umbriri de rute pe ambele servicii — **zero
+umbriri rămase**.
+
+---
+
+# 5. Verificări de securitate
+
+| Verificare | Rezultat |
+|---|---|
+| Cerere fără token JWT pe rută protejată (prin gateway) | **401** |
+| Cerere cu token JWT forjat | **401** |
+| Cerere cu token JWT valid | **200** |
+| Enforcement JWT la gateway — Agent V3 | **DA** |
+| Enforcement JWT la gateway — didiFramework | **DA** |
+| Verificare criptografică JWT în backend (apărare în adâncime) | **DA** (ambele servicii) |
+| Separare de roluri (RBAC pe moderare) | **DA** (403 fără rol) |
+
+---
+
+# 6. Probleme cunoscute (neblocante)
+
+1. **`/api/waitlist/*` → 500** — funcționalitatea de listă de așteptare depinde de o bază de
+   date de staging separată, neprezentă în deployment-ul standard. Funcție marginală
+   (înscriere pre-lansare), marcată `deprecated` în specificația OpenAPI.
+2. **`GET /api/v3/pipeline/history/admin/:id`** — răspunde 500 (în loc de 400) când
+   identificatorul nu are format UUID; cu UUID valid răspunde corect. Diferență cosmetică de
+   validare.
+3. Endpoint-uri legacy marcate `deprecated` în OpenAPI: `domain/*` (înlocuit de
+   source-assessment), `sync-analysis/*` (persistență directă în PostgreSQL), `prompts/*` pe
+   fișiere (sursa operațională este baza de date).
+
+---
+
+# 7. Artefacte și reproducere
+
+| Artefact | Locație |
+|---|---|
+| Specificație OpenAPI 3.0.3 — Agent V3 (87 operații) | `services/orchestration-layer/agent-v3/openapi.yaml` |
+| Specificație OpenAPI 3.0.3 — didiFramework (287 operații) | `services/orchestration-layer/didiFramework/openapi.yaml` |
+| Script de probă (reproductibil) | `scripts/api/api_probe.py` |
+| Generator de specificație | `scripts/api/generate_openapi.py` |
+| Rezultate brute ale probei | `scripts/api/probe_results_2026-07-08.json` |
+| Interfață Swagger UI | container `didi-api-docs` (ambele specificații) |
+
+Ambele specificații OpenAPI au fost **validate** cu `openapi-spec-validator` (rezultat: OK).
+Fiecare operație poartă adnotarea `x-tested` cu codul HTTP observat la probă.
+
+---
+
+# 8. Concluzie
+
+Toate cele **374 de endpoint-uri** ale Lotului 2 sunt cablate și funcționale (374/374), fără
+rute moarte. Securitatea (autentificare JWT la gateway și în backend, autorizare pe roluri)
+este verificată și funcțională. Cele 4 defecte identificate au fost corectate. Problemele
+rămase sunt marginale și documentate. Pachetul de API al Lotului 2 este **conform și
+verificabil**.

backend/docs/04_Raport_Testare_Integrare_Lot1-Lot2.md

@@ -0,0 +1,198 @@
+% Raport de testare a integrării — DiDi Lot 1 (AI) ↔ Lot 2 (Backend)
+% PNRR DIGI150 · contract 11.1.i3.c9
+% Data testării: 2026-07-09
+
+---
+
+# 1. Obiect și scop
+
+Prezentul raport documentează **testele de integrare** dintre **Lotul 2 — Backend**
+(motorul de analiză `agent-v3` + `didiFramework` + workeri) și **Lotul 1 — Platforma AI**
+(modelele LLM, deepfake, transcriere, extractoare, forensic, brain/RAG, domain-check).
+
+Raportul de testare a API-ului Lotului 2 (`03_Raport_Testare_API_Lot2`) acoperă **strict
+Lotul 2** și menționează explicit că serviciile AI (Lotul 1) „sunt testate separat, prin
+testele de integrare". Documentul de față **este acea probă**: demonstrează pe mediul live
+că cele două loturi **colaborează** — de la conectivitate punct-la-punct până la producerea
+unui verdict complet pe fiecare tip de conținut, plus proprietățile de reziliență și
+securitate ale integrării.
+
+Testarea confirmă cerințele din caietul de sarcini privind consumul de **extractoare
+specializate** (deepfake, NER, OCR, Whisper, YOLO), **modulul web-crawl/evidence**, **scorul
+de credibilitate a sursei** și **orchestrarea fluxurilor ML end-to-end** prin backend.
+
+---
+
+# 2. Metodologie
+
+Testarea a fost efectuată pe platforma live (`<HOST_IP>`, 2× H200), **non-distructiv**,
+printr-un harness reproductibil (`scripts/integration/run-integration-tests.sh`) structurat
+pe **trei niveluri**:
+
+- **Nivel A — Conectivitate & contract.** Din interiorul containerului `agent-v3`
+  (consumatorul real), fiecare serviciu Lot 1 este sondat prin `didi-network`, pe nume de
+  container (nu IP). Dovedește că boundary-ul de rețea și contractul HTTP funcționează.
+- **Nivel B — End-to-end pe tip de conținut.** Pentru fiecare din cele 5 tipuri (text, URL,
+  imagine, audio, video) se lansează o analiză reală prin `POST /api/v3/pipeline/analyze-async`
+  și se așteaptă verdictul persistat. Dovedește orchestrarea completă Lot2→Lot1→verdict.
+- **Nivel C — Proprietăți transversale.** Fail-open (degradare grațioasă la indisponibilitatea
+  unui serviciu AI), rutarea către modelul LLM local (fără fallback plătit) și enforcement-ul
+  gateway-ului peste lanțul AI.
+
+Fiecare test capturează **trei artefacte independente**: (1) request-ul emis de `agent-v3`,
+(2) **access-log-ul serviciului Lot 1** care dovedește primirea cererii, (3) **verdictul
+persistat în PostgreSQL** (`bos_analysis.analysis_session`). Toate artefactele brute sunt
+salvate în `scripts/integration/results/evidence_<timestamp>/`.
+
+Utilizatorul de test are credite alocate; strategia de dispatch este cea de producție (cozi
+RabbitMQ + workeri Docker + agregator de verdict).
+
+---
+
+# 3. Rezultate
+
+| Metric | Valoare |
+|---|---|
+| Teste de integrare rulate | **17** |
+| — Nivel A (conectivitate) | 9 |
+| — Nivel B (end-to-end) | 5 |
+| — Nivel C (transversale) | 3 |
+| **PASS** | **16** |
+| **DEGRADED** (fail-open, comportament corect) | **1** |
+| **FAIL** | **0** |
+| Defecte identificate și remediate | 1 (Lot 1 — vezi §4) |
+
+## 3.1 Nivel A — Conectivitate agent-v3 → servicii Lot 1
+
+Toate cele 9 integrări din documentația de arhitectură (§9) răspund din chiar consumatorul
+`agent-v3`, pe `didi-network`:
+
+| # | Serviciu Lot 1 | Adresă (didi-network) | Cerință acoperită | Rezultat |
+|---|---|---|---|---|
+| A1 | LLM text (Qwen 3.5) | `llm-api:14011` | flux LLM / ML | **PASS** (HTTP 200, model `qwen3.5` încărcat) |
+| A2 | LLM vision / OCR | `llm-api:14011` | extractor OCR | **PASS** (`qwen3.5` vision-capable) |
+| A3 | Whisper transcriere | `audio-api:54300` | extractor Whisper | **PASS** (HTTP 200) |
+| A4 | BusterX deepfake | `video-api:54600` | extractor deepfake | **PASS** (HTTP 200) |
+| A5 | Extractoare | `extractors:54400` | NER/YOLO/OCR/EXIF | **PASS** (HTTP 200) |
+| A6 | Forensic media | `forensic:8080` | analiză forensică | **PASS** (HTTP 200) |
+| A7 | Web / evidence | `web-api:51100` | modul web-crawl | **PASS** (HTTP 200) |
+| A8 | Brain / RAG | `brain-api:8090` | flux ML fact-check | **PASS** (HTTP 200) |
+| A9 | Domain-check (T4) | `domain-check-api:11000` | scor credibilitate sursă | **PASS** (`POST /check/check` → `risk_score` real) |
+
+## 3.2 Nivel B — Analize end-to-end (pipeline complet → verdict)
+
+Fiecare analiză a rulat prin cozile RabbitMQ și workerii de producție, verdictul fiind
+persistat în PostgreSQL. Coloana „Dovada Lot 1" citează access-log-ul serviciului apelat.
+
+| # | Input | Lanț Lot 1 | Verdict (scor/categorie) | Dovada Lot 1 | Rezultat |
+|---|---|---|---|---|---|
+| B1 | Text dezinformare (microcipuri 5G) | llm-api | **DISINFORMATION / 92** | `POST /v1/chat/completions 200` | **PASS** |
+| B2 | URL (bbc.com/news) | web + domain-check | **RELIABLE / 7** | `POST /api/v1/check/check 200` | **PASS** |
+| B3 | Imagine (titlu fals) | vision-OCR + extractoare | **DISINFORMATION / 95** | `POST /v1/chat/completions 200` (OCR a citit titlul) | **PASS** |
+| B4 | Audio (discurs) | Whisper → llm | **RELIABLE / 0** | `POST /v1/audio/transcriptions 200` | **PASS** |
+| B5 | Video | media-preprocess → BusterX | **RELIABLE / 5** | `POST /analyze/video 200` | **PASS** |
+
+> Nota B3: OCR-ul local (Qwen vision) a extras corect textul titlului fabricat din imagine,
+> iar pipeline-ul l-a clasificat DISINFORMATION — dovadă directă a lanțului vision→verdict.
+> Nota B5: verdict obținut după remedierea defectului D1 (vezi §4); BusterX a răspuns `200`.
+
+## 3.3 Nivel C — Proprietăți transversale
+
+| # | Test | Cerință | Rezultat |
+|---|---|---|---|
+| C1 | **Fail-open**: `didiAI-web-api` oprit temporar, analiză lansată | reziliență / fail-open servicii AI | **DEGRADED** — analiza s-a **terminat** cu degradare grațioasă (`status=completed`), fără eșec; serviciul a fost repornit |
+| C2 | **Rutare model local**: analiză text | flux LLM local, fără fallback plătit | **PASS** — 5 apeluri către `llm-api:14011`, provider `qwen35` local; niciun apel OpenRouter plătit |
+| C3 | **Gateway**: `POST /pipeline/analyze-async` prin Kong fără token | API Gateway + securitate | **PASS** — Kong răspunde **401**, păzind lanțul AI |
+
+Rezultatul **DEGRADED** la C1 este comportamentul **corect și dorit**: afirmația de
+reziliență din documentația de arhitectură (§6, „fail-open pe servicii AI") este validată
+empiric — indisponibilitatea unui serviciu Lot 1 nu blochează analiza.
+
+---
+
+# 4. Defecte identificate și remediate
+
+Testarea de integrare a identificat **1 defect real** (în Lotul 1), remediat și re-testat:
+
+| # | Severitate | Serviciu | Defect | Cauză rădăcină | Remediere | Verificare |
+|---|---|---|---|---|---|---|
+| **D1** | major | `didiAI-video-api` (BusterX), Lot 1 | `POST /analyze/video` → **500**; detecția deepfake nu rula (mascată de fail-open, care producea totuși verdict) | Bind-mount **stale** pe `/app/runs`: directorul host `local_gpu_stack/runs` fusese recreat după pornirea containerului → inode container (`6195429`) ≠ inode host (`6195434`) → `os.makedirs('/app/runs/<uuid>')` eșua cu `FileNotFoundError` | `docker restart didiAI-video-api` (re-rezolvă bind-mount-ul la inode-ul curent) | Inode host == container (`6195434`); test de scriere OK; `POST /analyze/video` → **200**; verdict video RELIABLE/5 |
+
+Observație importantă: defectul era **mascat** de mecanismul fail-open — analiza video se
+finaliza cu verdict, dar BusterX nu se executa efectiv. Doar inspecția access-log-ului
+serviciului Lot 1 (parte din metodologia acestui raport) a expus problema.
+
+## 4.1 Măsuri de robustețe adăugate (ca defectul să nu se repete și să nu mai fie tăcut)
+
+Pe lângă remedierea imediată, au fost adăugate două măsuri durabile:
+
+1. **Healthcheck de scriere pe `video-api` (Lot 1).** Containerul `didiAI-video-api` a primit
+   un healthcheck care **verifică efectiv scrierea în `/app/runs`** (nu doar `GET /health`).
+   Un bind-mount stale îl face imediat `unhealthy` (vizibil în `docker ps` + dashboard), în loc
+   să producă un `500` tăcut. `local_gpu_stack/docker-compose.yml`.
+
+2. **Degradare vizibilă în verdict (Lot 2).** Când BusterX era activat dar nu a returnat
+   rezultat, `media-preprocess-worker` scrie acum o santinelă `UNAVAILABLE`, iar
+   `video-2-track.ts` o **semnalează explicit** în verdictul persistat: indicator
+   `VID.2 „Verificare deepfake INDISPONIBILĂ — recomandată verificare manuală"` +
+   `coupling_context.for_verdict.deepfake_check = "unavailable"` + `needs_manual_review = true`.
+   Astfel un eșec al detecției deepfake **nu mai poate fi confundat** cu o verificare reușită.
+
+   Verificat controlat (2 rulări video pe același clip):
+
+   | Scenariu | `deepfake_check` | `needs_manual_review` | Indicator VID.2 |
+   |---|---|---|---|
+   | BusterX activ | *(absent)* | true | „BusterX deepfake detection: REAL" |
+   | BusterX oprit | **`unavailable`** | true | „Verificare deepfake INDISPONIBILĂ — verificare manuală" |
+
+   Fișiere: `agent-v3/src/queue/workers/media-preprocess-worker.ts`,
+   `agent-v3/src/queue/workers/component-worker-helpers/video-2-track.ts`.
+
+---
+
+# 5. Reflectarea integrării în specificația OpenAPI (Swagger)
+
+Integrarea cu Lotul 1 constă în dependențe **outbound** ale `agent-v3` (apeluri HTTP către
+servicii AI), nu în rute expuse de backend — prin urmare **nu** apare ca `paths` în
+specificația OpenAPI. A fost documentată, în schimb, prin două mecanisme:
+
+1. **Endpoint de sondă de integrare** — `GET /api/v3/health/all` a fost extins să verifice
+   **toate cele 9 servicii Lot 1** (pe lângă infrastructura internă), *fail-open*: o
+   dependență AI indisponibilă produce `degraded` (HTTP 200), nu `unhealthy`. Endpoint-ul
+   este documentat în `openapi.yaml` prin schema `DeepHealthResponse` și servește simultan
+   ca **test de integrare live**, rulabil oricând.
+2. **Bloc `x-integrations`** la nivel de specificație — listează cele 9 servicii Lot 1
+   consumate (cheie, variabilă de mediu, țintă pe `didi-network`, rol), contractul fail-open
+   și sonda de health. Extensie OpenAPI validă, informativă.
+
+Ambele au fost validate cu `openapi-spec-validator` (rezultat: **VALID**, OpenAPI 3.0.3).
+Verificare live a sondei extinse: 14 dependențe (4 interne + 10 AI), toate `healthy`.
+
+---
+
+# 6. Artefacte și reproducere
+
+| Artefact | Locație |
+|---|---|
+| Harness de testare (reproductibil) | `scripts/integration/run-integration-tests.sh` |
+| Fixturi (imagine, audio, video) | `scripts/integration/fixtures/` |
+| Rezultate structurate (JSON) | `scripts/integration/results/results_2026-07-09.json` |
+| Dovezi brute (access-log Lot 1, verdicte PG, health/all) | `scripts/integration/results/evidence_20260709_224124/` |
+| Sondă de integrare + schema OpenAPI | `agent-v3/openapi.yaml` (`x-integrations`, `DeepHealthResponse`) |
+| Tabel integrări Lot 1 | `docs/01_Arhitectura_Lot2.md` §9 |
+
+Rulare: `bash scripts/integration/run-integration-tests.sh` (variabile opționale:
+`AGENT_URL`, `TEST_USER`, `KONG_URL`).
+
+---
+
+# 7. Concluzie
+
+Integrarea dintre **Lotul 2 (Backend)** și **Lotul 1 (Platforma AI)** este **funcțională și
+verificată end-to-end** pe mediul live: **16/17 teste PASS**, 1 DEGRADED (comportament
+fail-open corect), **0 FAIL**. Toate cele 9 servicii AI sunt raggiunse și consumate corect;
+cele 5 tipuri de conținut produc verdicte complete; reziliența (fail-open), rutarea către
+modelul local și enforcement-ul gateway-ului sunt confirmate. Singurul defect identificat
+(D1 — bind-mount stale pe BusterX) a fost remediat și re-testat cu succes. Integrarea
+Lot1↔Lot2 este **conformă și verificabilă**, iar starea ei live este observabilă permanent
+prin `GET /api/v3/health/all`.

backend/docs/05_Ghid_Utilizare_Lot2.md

@@ -0,0 +1,296 @@
+% Ghid de utilizare — DiDi Lot 2 (Backend)
+% Platformă digitală inteligentă pentru prevenirea și combaterea dezinformării
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# 1. Scop și context
+
+Prezentul ghid prezintă utilizarea **Dashboard-ului administrativ** al Lotului 2 — interfața
+prin care operatorul configurează, rulează, monitorizează și moderează platforma DiDi de
+detecție a dezinformării. Capturile de ecran provin din **platforma reală, în funcțiune**
+(`https://<HOST_IP>:3001/admin`).
+
+Fiecare secțiune este corelată cu **modulul corespondent din Propunerea Tehnică Lot 2** și cu
+cerințele caietului de sarcini, astfel încât ghidul servește simultan ca **manual de operare**
+și ca **dovadă de conformitate funcțională**.
+
+| Zonă interfață | Modul ofertă | Rol |
+|---|---|---|
+| Autentificare | Modulul 7 | Login OIDC/Keycloak, roluri RBAC |
+| Service Monitor | Modulele 6.8, 8 | Sănătatea serviciilor + observabilitate |
+| Framework | Modulele 1.3, 6.5 | Parametrizarea completă a detecției |
+| LLM Components / Providers | Modulele 1.7, 2.5 | Modele LLM, chain-uri, chei API |
+| Pipelines | Modulele 1.2, 6.3, 6.4 | Definire, versionare, dry-run, rulare |
+| Cozi | Modulele 3, 6.4 | Broker de mesaje, procesare async |
+| Istoric analize | Modulele 2.6, 6.7 | Rezultate, verdicte, trasabilitate |
+| Moderare | Modulul 6 | Coadă HIL, triaj, revizuire umană |
+| Utilizatori | Modulele 6.6, 5.3 | Conturi, roluri, abonamente, credite |
+
+---
+
+# 2. Autentificare (Modulul 7)
+
+Accesul la dashboard se face prin **Keycloak** (OIDC/OAuth2 + PKCE), realm `didi-admins`.
+Autentificarea emite un token JWT RS256 care este verificat atât la gateway (Kong), cât și în
+backend. Rolul din token (`admin`, `moderator`, `senior_moderator`) determină ce operații sunt
+permise.
+
+![Ecran de autentificare Keycloak (realm didi-admins)](<../teste livrare/login keyckloak backend.png>){width=6in}
+
+---
+
+# 3. Monitorizarea serviciilor — Service Monitor (Modulele 6.8, 8)
+
+Ecranul principal grupează toate serviciile platformei pe straturi (Data Layer, Gateway & Auth,
+Orchestration, Monitoring) și afișează starea fiecăruia în timp real. Starea serviciilor locale
+este derivată din **starea containerelor Docker**, nu dintr-un simplu ping — deci reflectă
+sănătatea reală (`healthy` / `unhealthy`). Butonul **Open UI** deschide consola nativă a
+serviciului (MinIO, RabbitMQ etc.).
+
+![Service Monitor — stratul de date (PostgreSQL, Redis, RabbitMQ, MinIO), toate HEALTHY](<../teste livrare/dashboard_1.png>){width=6.5in}
+
+![Service Monitor — stratul de orchestrare și gateway/autentificare](<../teste livrare/dashboard_2.png>){width=6.5in}
+
+![Service Monitor — stratul de observabilitate (Prometheus, Grafana, Loki, Jaeger, Alertmanager)](<../teste livrare/dashboard_3.png>){width=6.5in}
+
+---
+
+# 4. Framework — parametrizarea detecției (Modulele 1.3, 6.5)
+
+Principiul central al platformei este **separarea configurării de execuție**: toți parametrii de
+analiză sunt gestionați declarativ din acest ecran, stocați în PostgreSQL și sincronizați în
+Redis prin butonul **Sync to Redis**. Motorul de analiză citește configurarea din Redis la
+fiecare rulare — comportamentul se modifică **fără redeploy de cod**.
+
+Pagina afișează sumarul (8 dimensiuni, 166 tehnici, 7 verdicte, 6 niveluri de risc, 12 tipuri de
+sursă, 11 platforme) și grupează parametrii pe categorii, prin tab-uri. Butoanele **Analysis
+Flow**, **Run Test Pipeline** și **Sync to Redis** permit vizualizarea fluxului, testarea și
+publicarea configurării.
+
+![DIDI Framework — vedere de ansamblu: dimensiunile de analiză (D1–D8) cu ponderi editabile](<../teste livrare/framework_!.png>){width=6.5in}
+
+## 4.1 Tehnici de manipulare (dimensiuni → subdimensiuni → tehnici → indicatori)
+
+Ierarhia de 166 de tehnici organizate pe 8 dimensiuni. Fiecare tehnică are indicatori, reguli de
+validare, ponderi și o alocare de model LLM per etapă.
+
+![Catalogul tehnicilor de manipulare](<../teste livrare/manipulation_techniques.png>){width=6.5in}
+
+![Parametrii unei tehnici de manipulare](<../teste livrare/manipulation parameters.png>){width=6.5in}
+
+![Indicatorii asociați tehnicilor de manipulare](<../teste livrare/manipulationtechniques indicators.png>){width=6.5in}
+
+![Regulile de validare pentru tehnici](<../teste livrare/manipulation_validation.png>){width=6.5in}
+
+![Alocarea modelelor LLM pe etapele componentei Techniques (screening → deep)](<../teste livrare/manipulation asignation.png>){width=6.5in}
+
+## 4.2 Conținut generat de AI (AI-Tampered)
+
+Parametrii componentei care detectează conținut generat/modificat de AI (text, imagine, video)
+și alocarea modelelor pe etape.
+
+![Parametrii componentei AI-Tampered](<../teste livrare/ai tamper parameters.png>){width=6.5in}
+
+![Alocarea modelelor LLM pentru AI-Tampered](<../teste livrare/ai tamper asignation.png>){width=6.5in}
+
+## 4.3 Afirmații verificabile (Claims)
+
+Extragerea și verificarea afirmațiilor prin căutare web, tipurile de claim și nivelurile de
+încredere.
+
+![Parametrii componentei Claims](<../teste livrare/claims parameters.png>){width=6.5in}
+
+![Tipuri de claim configurabile](<../teste livrare/claim types.png>){width=6.5in}
+
+![Taxonomia tipurilor de claim](<../teste livrare/tipuri claims.png>){width=6.5in}
+
+![Niveluri de încredere pentru claims](<../teste livrare/niveluri confidence claims.png>){width=6.5in}
+
+![Alocarea modelelor LLM pentru Claims](<../teste livrare/claims asignation.png>){width=6.5in}
+
+## 4.4 Evaluarea sursei (Source Assessment)
+
+Credibilitatea sursei/domeniului: clasificarea și credibilitatea autorului, vechimea domeniului,
+modificatorii de platformă și alocarea modelelor.
+
+![Parametrii componentei Source Assessment](<../teste livrare/source assesment parameters.png>){width=6.5in}
+
+![Credibilitatea sursei](<../teste livrare/source credibility.png>){width=6.5in}
+
+![Disponibilitatea / evaluarea sursei](<../teste livrare/source aval_.png>){width=6.5in}
+
+![Influența vechimii domeniului asupra scorului](<../teste livrare/source domain age.png>){width=6.5in}
+
+![Clasificarea autorului](<../teste livrare/clasificari autor.png>){width=6.5in}
+
+![Credibilitatea autorului](<../teste livrare/credibilitate autor.png>){width=6.5in}
+
+![Modificatori de scor per platformă](<../teste livrare/surce modificatos platform.png>){width=6.5in}
+
+![Alocarea modelelor LLM pentru Source Assessment](<../teste livrare/source assesment asignation.png>){width=6.5in}
+
+## 4.5 Analiza domeniului
+
+Scorul de risc al domeniului și semnalele de alarmă (red flags) — corespondentul frontend al
+integrării cu serviciul domain-check (T4): WHOIS, DNS, SSL, blacklist.
+
+![Scorul de risc al domeniului](<../teste livrare/domain risk.png>){width=6.5in}
+
+![Semnale de alarmă (red flags) pentru domeniu](<../teste livrare/red flags domeniu.png>){width=6.5in}
+
+## 4.6 Verdicte, scoruri și interpretări
+
+Categoriile de verdict, nivelurile de risc, pragurile de severitate, maparea scorului și regulile
+de interpretare care transformă scorurile componentelor într-un verdict final.
+
+![Categorii de verdict](<../teste livrare/categorii verdict.png>){width=6.5in}
+
+![Categoriile de verdict (detaliu)](<../teste livrare/verdict categories.png>){width=6.5in}
+
+![Niveluri de risc ale verdictului](<../teste livrare/verdict risk levels.png>){width=6.5in}
+
+![Evaluarea severității](<../teste livrare/eval severitate.png>){width=6.5in}
+
+![Severitatea verdictului](<../teste livrare/verdict severity.png>){width=6.5in}
+
+![Nivelurile de încredere ale verdictului](<../teste livrare/verdict confidence.png>){width=6.5in}
+
+![Reguli de interpretare](<../teste livrare/niveluri interpretari.png>){width=6.5in}
+
+![Maparea scorului de risc](<../teste livrare/mapari risk.png>){width=6.5in}
+
+![Suprascrieri și sinergii între componente (overrides & synergy)](<../teste livrare/verdifcts overrides & sineryg.png>){width=6.5in}
+
+## 4.7 Ponderi și profiluri de pipeline
+
+Ponderile componentelor, multiplicatorii, scenariile de ponderare și profilurile de verdict per
+tip de conținut (text, URL, imagine, audio, video).
+
+![Ponderile componentelor în verdictul final](<../teste livrare/ponderi componente.png>){width=6.5in}
+
+![Ponderile verdictului](<../teste livrare/verdict weighs.png>){width=6.5in}
+
+![Multiplicatori de scor](<../teste livrare/multiplicatori.png>){width=6.5in}
+
+![Multiplicatorii verdictului](<../teste livrare/verdict multipliers.png>){width=6.5in}
+
+![Scenarii de ponderare](<../teste livrare/scenarii pondere.png>){width=6.5in}
+
+![Profiluri de verdict per tip de input](<../teste livrare/final verdict input types profiles.png>){width=6.5in}
+
+---
+
+# 5. Modele LLM și provideri (Modulele 1.7, 2.5)
+
+Platforma folosește **lanțuri de modele** (primar + fallback-uri) per componentă și etapă.
+Providerii (local Qwen 3.5, OpenRouter etc.) și cheile API se gestionează din acest ecran, iar
+modelul primar folosit este cel **local, servit de Lotul 1** (fără costuri per-token pe calea
+principală).
+
+![Providerii LLM configurați](<../teste livrare/llm providers.png>){width=6.5in}
+
+![Managementul providerilor (1)](<../teste livrare/providers1.png>){width=6.5in}
+
+![Managementul providerilor (2) — modele și costuri](<../teste livrare/providers2.png>){width=6.5in}
+
+---
+
+# 6. Pipelines — definire, versionare, rulare (Modulele 1.2, 6.3, 6.4)
+
+Fluxul de analiză este modelat ca **workflow cu dependențe explicite**. Fiecare tip de conținut
+are un profil de pipeline propriu. Editorul permite definirea nodurilor și dependențelor,
+versionarea, iar consola de rulare permite testarea și **dry-run** (rezolvarea întregului plan —
+noduri, cozi, lanțuri de modele — fără a consuma resurse).
+
+![Editor de pipeline (1)](<../teste livrare/pipelines1.png>){width=6.5in}
+
+![Editor de pipeline (2)](<../teste livrare/pipelies2.png>){width=6.5in}
+
+![Editor de pipeline (3)](<../teste livrare/pipeline3.png>){width=6.5in}
+
+![Pipeline pentru analiza de text](<../teste livrare/textpipeline1.png>){width=6.5in}
+
+---
+
+# 7. Cozi de procesare — Broker de mesaje (Modulele 3, 6.4)
+
+Analizele asincrone sunt dispecerizate pe cozi RabbitMQ (componente × planuri de prioritate +
+media-preprocess + results + DLQ). Ecranul afișează starea cozilor, adâncimea și workerii activi.
+
+![Starea cozilor de procesare (1)](<../teste livrare/queue1.png>){width=6.5in}
+
+![Starea cozilor de procesare (2)](<../teste livrare/queue2.png>){width=6.5in}
+
+![Starea cozilor de procesare (3)](<../teste livrare/queue3.png>){width=6.5in}
+
+---
+
+# 8. Istoric analize și citirea unui verdict (Modulele 2.6, 6.7)
+
+Toate analizele sunt persistate și consultabile. Ecranul de detaliu al unei analize arată:
+verdictul final cu scor (0–100) și categorie, rezultatul fiecărei componente, afirmațiile
+verificate cu sursele care le confirmă/contrazic, căutările web efectuate și modelele folosite —
+**trasabilitate completă**.
+
+![Istoric analize — listă](<../teste livrare/analysis history.png>){width=6.5in}
+
+![Detaliu analiză — verdict DISINFORMATION (risc 100), afirmații verificate + surse care contrazic](<../teste livrare/analysis history5.png>){width=6.5in}
+
+![Detaliu analiză (2)](<../teste livrare/analysis history2.png>){width=6.5in}
+
+![Detaliu analiză (3)](<../teste livrare/analysis history3.png>){width=6.5in}
+
+![Detaliu analiză (4)](<../teste livrare/analysis history4.png>){width=6.5in}
+
+![Detaliu analiză (6)](<../teste livrare/analysis history6.png>){width=6.5in}
+
+![Detaliu analiză (7)](<../teste livrare/analysis history7.png>){width=6.5in}
+
+---
+
+# 9. Moderare umană (HIL) (Modulul 6)
+
+Sesiunile care îndeplinesc criteriile de triaj (prag de încredere, zonă gri de risc, subiecte
+sensibile) intră într-o **coadă de moderare umană**. Operatorii cu rol `moderator` /
+`senior_moderator` revizuiesc și corectează verdictele. Setările de triaj și clientul de brain
+(cache de fact-checking) se configurează din **Moderation Settings** și se sincronizează în Redis.
+
+![Setări de moderare — reguli de triaj + client brain](<../teste livrare/mode3ration1.png>){width=6.5in}
+
+![Coada de moderare — revizuirea sesiunilor](<../teste livrare/moderation2.png>){width=6.5in}
+
+---
+
+# 10. Utilizatori și abonamente (Modulele 6.6, 5.3)
+
+Managementul conturilor (sincronizate cu Keycloak), al rolurilor, al abonamentelor și al
+creditelor. Planurile de abonament determină prioritatea în cozi și lanțul de modele (free /
+premium).
+
+![Management utilizatori — conturi și roluri](<../teste livrare/user management .png>){width=6.5in}
+
+![Planuri de abonament și credite](<../teste livrare/subscription plans.png>){width=6.5in}
+
+---
+
+# 11. Rezumatul conformității funcționale
+
+Ghidul de față demonstrează, pe capturi din platforma reală, acoperirea funcțională a modulelor
+din Propunerea Tehnică Lot 2:
+
+| Modul ofertă | Funcționalitate demonstrată | Secțiune |
+|---|---|---|
+| M1 — Orchestrator | Parametrizare, pipelines, dry-run, catalog AI | §4, §5, §6 |
+| M2 — Analiză | Executori (techniques, ai-tampered, claims, source, domain), agregare verdict | §4, §8 |
+| M3 — Broker mesaje | Cozi de procesare async, priorități | §7 |
+| M4 — API Gateway | Autentificare la gateway, RBAC | §2 |
+| M5 — Baze de date | Persistare, scheme (rezultate, config, useri, abonamente) | §8, §10 |
+| M6 — Dashboard | Toată interfața administrativă (config, run, monitor, moderare, useri) | §3–§10 |
+| M7 — Autentificare | Login OIDC/Keycloak, roluri | §2 |
+| M8 — Observabilitate | Stratul de monitorizare în Service Monitor | §3 |
+| M9 — Containerizare/CI-CD | Servicii containerizate vizibile în Service Monitor | §3 |
+
+Documentul se completează cu: `01_Arhitectura_Lot2` (arhitectură), `02_Ghid_Instalare_Operare`
+(instalare/operare), `03_Raport_Testare_API` (test API), `04_Raport_Testare_Integrare_Lot1-Lot2`
+(test integrare) și specificațiile OpenAPI ale celor două servicii.

backend/docs/06_Matrice_Trasabilitate_Cerinte.md

@@ -0,0 +1,93 @@
+% Matrice de trasabilitate a cerințelor — DiDi Lot 2 (Backend)
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# 1. Scop
+
+Prezentul document asigură **trasabilitatea** dintre cerințele contractuale (caietul de sarcini
++ Propunerea Tehnică Lot 2) și livrabilele efective. Pentru fiecare modul/cerință se indică
+**dovada** (document, endpoint, ecran, test) prin care se poate verifica îndeplinirea.
+
+Legendă dovezi:
+`ARH`=01_Arhitectura · `INST`=02_Ghid_Instalare_Operare · `API`=03_Raport_Testare_API ·
+`INT`=04_Raport_Testare_Integrare · `GHID`=05_Ghid_Utilizare (cu capturi) ·
+`OAPI`=openapi.yaml (Swagger) · `COD`=cod sursă · `LIVE`=platformă în funcțiune.
+
+---
+
+# 2. Trasabilitate pe modulele Propunerii Tehnice Lot 2
+
+| # | Modul / cerință ofertă | Stare | Dovadă |
+|---|---|---|---|
+| **M1** | **Orchestrator** — motor de analiză, dispatch | ✅ | ARH §3.1, COD `agent-v3` |
+| M1.2 | Definire și modelare pipeline-uri (workflow cu dependențe) | ✅ | GHID §6, ARH §4.3 |
+| M1.3 | Configurare și parametrizare (declarativ, sync Redis) | ✅ | GHID §4, LIVE Framework |
+| M1.4 | Execuție sincronă | ✅ | API `/pipeline/analyze`, INT B1/B3 |
+| M1.5 | Execuție asincronă (202 + poll) | ✅ | API `/pipeline/analyze-async`, INT B1–B5 |
+| M1.6 | Simulare / dry-run | ✅ | OAPI `/pipeline/dry-run`, GHID §6 |
+| M1.7 | Catalog resurse AI (servicii Lot 1) | ✅ | INT §3.1 (9/9), GHID §5 |
+| M1.8 | Reluare execuții (resume/checkpoint) | ✅ | COD `dispatcher.resumeDispatch`, ARH §6 |
+| M1.9 | Monitorizare și trasabilitate | ✅ | GHID §8, `/health/all` |
+| M1.10 | API-uri expuse | ✅ | API (87 op.), OAPI agent-v3 |
+| M1.11 | Securizare comunicații (JWT) | ✅ | API §5, INT C3 |
+| M1.12 | Integrare bază de date | ✅ | ARH §8, COD `pg-adapter` |
+| **M2** | **Analiză** — workeri + executori | ✅ | ARH §3.1, COD `src/components` |
+| M2.4 | Executori: techniques, ai-tampered, claims, domain, RAG | ✅ | GHID §4, INT B1–B5 |
+| M2.5 | Integrarea cu platforma AI (Lot 1) | ✅ | **INT (raport dedicat)**, `/health/all` |
+| M2.6 | Agregare și verdict | ✅ | GHID §8, COD `aggregator` |
+| M2.7 | Procesare media (imagine/audio/video) | ✅ | INT B3/B4/B5 |
+| M2.9 | Reziliență și gestionarea erorilor (fail-open) | ✅ | INT C1 + §4.1 (degradare vizibilă) |
+| **M3** | **Broker de mesaje** (RabbitMQ) | ✅ | ARH §3.6, GHID §7 |
+| M3.2 | Topologie cozi (componente × priorități + DLQ) | ✅ | GHID §7, ARH §8 |
+| M3.4 | Mecanisme de reziliență (publisher confirms, DLQ) | ✅ | ARH §6, COD `queue/` |
+| **M4** | **API Gateway** (Kong) | ✅ | ARH §3.4 |
+| M4.3 | Autentificare și autorizare (JWT RS256, RBAC) | ✅ | API §5, INT C3, GHID §2 |
+| M4.4 | Rate limiting | ✅ | COD `kong.yml`, ARH §3.4 |
+| M4.8 | Health checks | ✅ | `/health/all`, GHID §3 |
+| **M5** | **Baze de date SQL** (PostgreSQL) | ✅ | ARH §8 |
+| M5.3 | Organizare pe scheme (analiză/config/useri/date personale) | ✅ | ARH §8, GHID §10 |
+| M5.5 | Sincronizare cu cache (Redis) | ✅ | GHID §4, COD `sync-redis` |
+| M5.8 | Securizare și disponibilitate (HA Patroni/HAProxy) | ✅ | ARH §6, COD `ha-cluster/` |
+| **M6** | **Dashboard** (React) | ✅ | **GHID (întreg)** |
+| M6.3 | CRUD pipeline-uri (workflow builder) | ✅ | GHID §6 |
+| M6.4 | Rulare pipeline și debug (run console) | ✅ | GHID §6, §7 |
+| M6.5 | CRUD catalog (modele, funcții, extractoare) | ✅ | GHID §4, §5 |
+| M6.6 | Management utilizatori | ✅ | GHID §10 |
+| M6.7 | Istoric analize | ✅ | GHID §8 |
+| M6.8 | Monitorizare servicii (health dashboard) | ✅ | GHID §3 |
+| **M7** | **Autentificare** (Keycloak OIDC) | ✅ | GHID §2, ARH §3.5 |
+| **M8** | **Observabilitate & Logging** | ✅ | GHID §3, ARH §2, INST |
+| **M9** | **Containerizare, CI/CD, Orchestrare** | ✅ | INST, `build-local.sh`, ARH §7 |
+
+---
+
+# 3. Trasabilitate pe cerințele funcționale ale caietului de sarcini
+
+| Cerință caiet (backend) | Livrabil / dovadă |
+|---|---|
+| Consumul extractoarelor specializate (deepfake, NER, OCR, Whisper, YOLO) | INT §3.1–3.2 (A3–A6, B3–B5), GHID §4 |
+| Modul web-crawl / evidence integrat cu backend | INT A7/B2, GHID §4.3 |
+| Scor de credibilitate a sursei (WHOIS/SSL/blacklist/DNS — T4) | INT A9/B2, GHID §4.4–4.5 |
+| Orchestrarea fluxurilor ML end-to-end | INT B1–B5, GHID §6 |
+| Integrarea cu API Gateway + politici de securitate | API §5, INT C3, GHID §2 |
+| Autentificare, autorizare, RBAC | API §5, GHID §2, §10 |
+| Containerizare, CI/CD, orchestrare | INST, `build-local.sh` |
+| OpenAPI/Swagger + set minim de teste API (criteriu 6) | API, OAPI (2 servicii, 374 op.) |
+| Cod sursă livrat integral, documentat | Arhiva Lot 2 + docs 01–06 |
+
+---
+
+# 4. Sinteză stare livrare
+
+| Categorie | Rezultat |
+|---|---|
+| Module ofertă acoperite | **9/9** |
+| Endpoint-uri API cablate (Lot 2) | **374/374** (API) |
+| Integrări Lot 1 verificate | **9/9** (INT) |
+| Teste de integrare | **16 PASS / 1 DEGRADED (fail-open) / 0 FAIL** |
+| Defecte identificate în testare | 1, remediat + întărit (INT §4) |
+| Documente de livrare | 01–06 + OpenAPI + rapoarte de test |
+
+Toate modulele din Propunerea Tehnică Lot 2 sunt **implementate, livrate și verificabile** pe
+platforma în funcțiune, cu dovezi trasabile în documentele indicate.

backend/docs/07_Specificatii_API_Lot2.md

@@ -0,0 +1,87 @@
+% Specificații API — DiDi Lot 2 (Backend)
+% PNRR DIGI150 · contract 11.1.i3.c9
+
+---
+
+# 1. Scop
+
+Lotul 2 expune două servicii cu API documentat prin **OpenAPI 3.0.3**, însumând **374 de
+operații**. Prezentul document rezumă structura API-urilor și modul de consultare (Swagger UI).
+Specificațiile complete, mașinabile, sunt livrate ca fișiere `openapi.yaml`.
+
+| Serviciu | Port | Operații | Specificație |
+|---|---|---|---|
+| **Agent V3** (motor de analiză) | 24803 | **87** | `services/orchestration-layer/agent-v3/openapi.yaml` |
+| **didiFramework** (parametri) | 3005 | **287** | `services/orchestration-layer/didiFramework/openapi.yaml` |
+| **Total** | | **374** | validate cu `openapi-spec-validator` (OK) |
+
+Ambele API-uri sunt protejate prin **JWT RS256** (Keycloak), verificat la gateway (Kong) și în
+backend. Autentificarea se face cu header `Authorization: Bearer <token>`.
+
+---
+
+# 2. Agent V3 — API de analiză (87 operații)
+
+Toate endpoint-urile de analiză sunt **asincrone** (dispatch pe RabbitMQ, răspuns `202` + poll).
+
+| Prefix | Rol |
+|---|---|
+| `/api/v3/pipeline/*` | Pipeline complet: analiză (sync/async), status, istoric, dry-run, resume, cancel |
+| `/api/v3/techniques/*` | Detecția tehnicilor de manipulare |
+| `/api/v3/ai-tampered/*` | Detecția conținutului generat/modificat de AI |
+| `/api/v3/claims/*` | Extragerea + verificarea afirmațiilor |
+| `/api/v3/source-assessment/*` | Credibilitatea sursei |
+| `/api/v3/domain/*` | Analiza domeniului (WHOIS/DNS/SSL — T4) |
+| `/api/v3/media/*` | Upload/download fișiere media (MinIO) |
+| `/api/v3/health`, `/api/v3/health/all` | Liveness + health profund cu **toate dependențele Lot 1** |
+
+**Fluxul tipic de analiză:**
+
+1. `POST /api/v3/pipeline/analyze-async` cu `{ media_type, text|url|media_url, user_id }`
+   → `202 { session_id, poll_url, result_url }`
+2. `GET /api/v3/pipeline/{session_id}/queue-status` → progres
+3. `GET /api/v3/pipeline/{session_id}/result` → `AnalysisSession` completă (verdict + componente)
+
+**Integrarea cu Lotul 1** este documentată în specificație prin blocul `x-integrations`
+(cele 9 servicii AI consumate, cu variabila de mediu, ținta pe `didi-network` și rolul) și prin
+schema `DeepHealthResponse` a endpoint-ului `/api/v3/health/all` — care servește și ca sondă de
+integrare live (vezi raportul 04).
+
+---
+
+# 3. didiFramework — API de parametri (287 operații)
+
+CRUD complet pentru toți parametrii platformei (schema `bos_parammgmt`), plus utilizatori,
+abonamente și integrarea Keycloak.
+
+| Grup | Rol |
+|---|---|
+| `/api/techniques`, `/api/dimensions`, `/api/subdimensions`, `/api/indicators`, `/api/validation-rules` | Ierarhia de tehnici de manipulare |
+| `/api/verdicts`, `/api/weights`, `/api/risk-levels` | Verdicte, ponderi, niveluri de risc |
+| `/api/claims`, `/api/sources`, `/api/platforms` | Claims, surse, platforme |
+| `/api/providers/*`, `/api/llm-models` | Provideri LLM, modele, chei API |
+| `/api/prompts` | Prompturi per componentă/etapă |
+| `/api/sync-redis` | Sincronizarea configurării PostgreSQL → Redis |
+| `/api/admin/*` | Utilizatori, roluri, containere, moderare |
+| `/api/subscriptions`, `/api/auth/*` | Abonamente, autentificare, credite |
+
+---
+
+# 4. Consultarea interactivă (Swagger UI)
+
+Ambele specificații sunt servite printr-o interfață **Swagger UI** (container `didi-api-docs`),
+unde fiecare operație poate fi inspectată și testată. Fiecare operație poartă adnotarea
+`x-tested` cu codul HTTP observat la proba live (vezi raportul 03).
+
+Alternativ, fișierele `openapi.yaml` pot fi deschise în orice unealtă compatibilă OpenAPI 3.0
+(Swagger Editor, Postman, Insomnia, generatoare de client).
+
+---
+
+# 5. Testare și validare
+
+- **374/374** endpoint-uri cablate și funcționale (raport `03_Raport_Testare_API`).
+- Ambele specificații **validate** cu `openapi-spec-validator` (OpenAPI 3.0.3, rezultat OK).
+- Securitate verificată: 401 fără token / cu token forjat, 200 cu token valid, RBAC pe operațiile
+  sensibile (raport 03 §5).
+- Integrarea cu Lotul 1 testată separat (raport `04_Raport_Testare_Integrare_Lot1-Lot2`).