didi-lot2-backend/backend/docs/04_Raport_Testare_Integrare_Lot1-Lot2.md

% 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.