Caiet de sarcini — Registrul Interdicțiilor (Republica Moldova)

Document formal de specificare a cerințelor de proiect. Pentru detalii tehnice de implementare a stratului de integrare multi-protocol, vezi integrare_multiprotocol.md. Pentru modelul de domeniu, vezi interdictii_full.md, pentru arhitectură platform_design.md, pentru schema bazei de date db_schema.md.

1. Denumirea proiectului și context

Denumire: Registrul Interdicțiilor — sistem informatic SaaS pentru evidența, administrarea și consultarea interdicțiilor legale aplicate persoanelor fizice, persoanelor juridice, administratorilor, funcționarilor publici, străinilor, mărfurilor, armelor, vehiculelor și activelor financiare în Republica Moldova.

Beneficiar: autoritate/instituție publică a Republicii Moldova (administrator de registru); consumatori secundari — bănci, organe de control (Serviciul Fiscal, Serviciul Vamal, Poliție, Poliția de Frontieră, CNA), alte sisteme guvernamentale interconectate prin MConnect.

Cadru legal de referință (neexhaustiv — se confirmă cu beneficiarul/juriștii înainte de implementare):

Codul Penal al Republicii Moldova
Codul Contravențional al Republicii Moldova
Codul de Executare al Republicii Moldova
Legislație migrațională (regim străini/apatrizi)
Legea nr. 133/2011 privind protecția datelor cu caracter personal
Legislație privind semnătura electronică și serviciile de încredere (pentru integrarea cu MSign)
Legislație privind interoperabilitatea sistemelor informaționale de stat (pentru integrarea cu MConnect)

Justificare: în prezent interdicțiile emise de autorități diferite (instanțe, ministere, organe de control, autorități speciale) nu sunt centralizate într-un registru unic, consultabil rapid și uniform de către instituții terțe (bănci, ANAF, poliție de frontieră). Aceasta generează risc de eludare a interdicțiilor și întârzieri în verificare. Registrul Interdicțiilor centralizează ciclul de viață complet al interdicției și expune un API public de consultare pentru sistemele externe.

2. Obiectul caietului de sarcini

Obiectul prezentului document este specificarea cerințelor funcționale, nefuncționale și de interoperabilitate pentru proiectarea, dezvoltarea, testarea, implementarea și mentenanța sistemului Registrul Interdicțiilor.

2.1 Obiective generale

Centralizarea evidenței interdicțiilor legale aplicabile în Republica Moldova, indiferent de tipul entității vizate sau de autoritatea emitentă.
Digitalizarea integrală a ciclului de viață al unei interdicții — de la creare/draft până la încetare (ridicare, revocare, executare, expirare, anulare).
Expunerea unui API public de consultare, rapid și sigur, pentru sisteme guvernamentale și private (bănci, organe de control).
Asigurarea trasabilității complete (audit) pentru fiecare modificare de statut, conform cerințelor legale de evidență forensică.
Proiectarea sistemului astfel încât să poată fi consumat din orice limbaj/platformă de programare (Java, .NET, Python, Go, și altele), fără dependență de un singur ecosistem tehnologic — cerință centrală a acestui proiect (vezi §6).

2.2 Obiective specifice

Acoperirea integrală a celor 9 categorii de entități vizate de interdicții (persoane fizice, persoane juridice, administratori/fondatori, funcționari publici, străini/apatrizi, mărfuri/bunuri, arme/muniții, vehicule, active financiare) — detaliate în interdictii_full.md §1.
Acoperirea integrală a celor 11 statuturi operaționale ale unei interdicții (Draft, Condiționată, Activă, Suspendată, Contestată, Prelungită, Ridicată, Revocată, Executată, Expirată, Anulată) — interdictii_full.md §2.
Acoperirea celor 4 familii de autorități emitente (judiciare, administrative centrale, de control/supraveghere, speciale) — interdictii_full.md §3.
Acoperirea celor 4 axe de clasificare a interdicțiilor: jurisdicție, domeniu juridic, durată, intensitate — interdictii_full.md §4.
Implementarea unui strat de integrare multi-protocol (REST, gRPC, TCP raw) care permite oricărui sistem extern, scris în orice limbaj, să consume registrul fără fricțiune.

3. Domeniul de aplicare

Domeniul complet de aplicare este definit în interdictii_full.md. Rezumat:

Componentă domeniu	Acoperire cerută
Entități vizate	9 categorii: PF, PJ, ADMIN, FUNCTIONAR_PUBLIC, STRAIN, MARFA, ARMA, VEHICUL, ACTIV_FINANCIAR
Statuturi interdicție	11: DRAFT, CONDITIONATA, ACTIV, SUSPENDAT, CONTESTATA, PRELUNGITA, RIDICATA, REVOCATA, EXECUTATA, EXPIRAT, ANULAT
Autorități emitente	4 familii: judiciară, administrativă centrală, control/supraveghere, specială
Clasificare jurisdicție	NATIONALA, LOCALA, REGIONALA, INTERNATIONALA, TRANSFRONTALIERA
Clasificare domeniu	ADMINISTRATIV, PENAL, FISCAL, VAMAL, MEDIU, SECURITATE, MIGRATIONAL, ECONOMIC, ALTUL
Clasificare durată	TEMPORARA, PERMANENTA, CONDITIONATA, PANA_LA_EXECUTARE
Clasificare intensitate	TOTALA, PARTIALA, CONDITIONATA, PROGRESIVA
Acțiuni interzise concrete	32 tipuri (IMPORT, EXPORT, CIRCULATIE, PORT_ARMA, TRANZACTIONARE, IESIRE_TARA, etc.) cu scope structurat (limite valorice, geografie, contraparte, ferestre temporale)

Această acoperire este deja modelată în interdictii.jdl (v2) — caietul de sarcini confirmă acest domeniu ca fiind complet și obligatoriu de implementat, nu introduce cerințe noi de domeniu.

4. Cerințe funcționale (CF)

CF-1. Gestiune interdicții (modul central)

CF-1.1 Creare interdicție în statut DRAFT, cu validare obligatorie a entității vizate, autorității emitente, temeiului legal (opțional), jurisdicției, domeniului, duratei și intensității.
CF-1.2 Flux de aprobare: DRAFT → ACTIV (sau → CONDITIONATA dacă durata necesită o condiție), cu actor responsabil (ex. șef direcție).
CF-1.3 Suspendare temporară (ACTIV → SUSPENDAT) și reactivare (SUSPENDAT → ACTIV).
CF-1.4 Contestare (ACTIV → CONTESTATA) cu rezoluție: respingere (→ ACTIV) sau admitere (→ ANULAT, de către autoritate superioară).
CF-1.5 Prelungire (ACTIV → PRELUNGITA → ACTIV cu end_date extins, sau → EXPIRAT dacă cererea e respinsă și termenul a trecut).
CF-1.6 Ridicare (ACTIV → RIDICATA), revocare (ACTIV/SUSPENDAT → REVOCATA), executare (ACTIV → EXECUTATA) — fiecare cu act justificativ obligatoriu atașat.
CF-1.7 Expirare automată (ACTIV → EXPIRAT) printr-un job programat zilnic, când end_date este atinsă.
CF-1.8 Anulare din orice stare (* → ANULAT) de către autoritate superioară, cu motivare obligatorie.
CF-1.9 Fiecare tranziție de statut generează exact o intrare în jurnalul de evenimente (audit), conform matricei de tranziții din platform_design.md §4.

CF-2. Gestiune entități polimorfice

CF-2.1 CRUD pentru entitatea vizată, cu validare structurală a câmpurilor specifice categoriei (atribute — schema per categorie, vezi platform_design.md §3.3).
CF-2.2 Unicitate identificator în interiorul categoriei (categorie + identificator), cu posibilitate legitimă de reapariție a aceluiași IDNP în categorii diferite (ex. persoană fizică și administrator).
CF-2.3 Căutare/filtrare entități după categorie, identificator, nume afișat.

CF-3. Acțiuni interzise (scope)

CF-3.1 O interdicție poate avea N acțiuni interzise concrete, fiecare cu intensitate proprie (poate diferi de intensitatea globală a interdicției).
CF-3.2 Scope structurat per acțiune: limite valorice, geografie, contraparte, ferestre temporale, canale — validat conform exemplelor din platform_design.md §3.3.

CF-4. Autorități emitente

CF-4.1 CRUD autorități, cu familie (judiciară/administrativă/ control/specială) și nivel (centrală/teritorială).
CF-4.2 Asociere autoritate ↔ interdicție (emitent) și autoritate ↔ act justificativ (per rol — emitere, ridicare, revocare, etc.).

CF-5. Acte justificative

CF-5.1 Atașare a unui sau mai multor acte (hotărâre, sentință, decizie, proces-verbal, ordin, dispoziție) la o interdicție, fiecare cu rol explicit (EMITERE, MODIFICARE, PRELUNGIRE, SUSPENDARE, REACTIVARE, CONTESTARE, RIDICARE, REVOCARE, EXECUTARE).
CF-5.2 Stocare document (URI extern — S3/MinIO), hash SHA-256 pentru integritate, câmp pentru semnătură electronică (integrare MSign — vezi CF-9).

CF-6. Temei legal

CF-6.1 Lookup normalizat de articole de lege (act normativ, articol, alineat), reutilizabil între interdicții — nu text liber.

CF-7. Condiții (interdicții condiționate)

CF-7.1 Pentru durata = CONDITIONATA, interdicția este legată obligatoriu de o condiție (eveniment, îndeplinire obligație, decizie autoritate, prag temporal).
CF-7.2 La îndeplinirea condiției, tranziție automată sau manuală CONDITIONATA → ACTIV.

CF-8. Jurnal de evenimente (audit, append-only)

CF-8.1 Fiecare tranziție de statut produce o intrare imutabilă (actor, data, tip, payload).
CF-8.2 Interzicere absolută a UPDATE/DELETE pe jurnalul de evenimente — la nivel de aplicație și la nivel de bază de date (trigger).
CF-8.3 Raportare „ce a făcut utilizatorul X în perioada Y” pe baza jurnalului.

CF-9. Notificări

CF-9.1 Notificare multi-canal (EMAIL, SMS, MCONNECT, WEBHOOK) la evenimente cheie (aprobare, suspendare, ridicare, expirare).
CF-9.2 Urmărire status livrare (PENDING, SENT, DELIVERED, FAILED) cu retry pentru notificările eșuate.

CF-10. Consultare publică / API extern

CF-10.1 Endpoint public de consultare după IDNP/IDNO/identificator, care returnează doar interdicțiile cu statut ACTIV sau SUSPENDAT (efect juridic public).
CF-10.2 Mascare câmpuri sensibile conform GDPR/Legea 133 înainte de expunere publică.
CF-10.3 Rate limiting și autentificare (API key/OAuth2) pentru consumatori externi.
CF-10.4 Logare obligatorie a fiecărei consultări externe (audit acces).

CF-11. Interoperabilitate multi-limbaj (cerință transversală majoră)

CF-11.1 API-ul trebuie expus simultan prin trei protocoale: REST/HTTP (OpenAPI), gRPC, și un protocol raw TCP propriu — astfel încât orice sistem extern, indiferent de limbajul de programare (Java, .NET, Python, Go, sau altele), să poată integra registrul fără adaptoare proprietare.
CF-11.2 Pentru protocolul REST, trebuie publicate SDK-uri client generate automat pentru minimum Java, .NET (C#), Python și Go.
CF-11.3 Toate cele trei protocoale trebuie să expună aceeași logică de business (fără reguli duplicate sau divergente între protocoale).
Detalii complete de implementare: integrare_multiprotocol.md.

CF-12. Administrare utilizatori operatori

CF-12.1 CRUD operatori registru (AppUser, distinct de utilizatorul de autentificare JHipster), cu statut (ACTIV/INACTIV/BLOCAT) și rol funcțional (minim ADMIN/EMITENT; roluri extinse precum SEF_DIRECTIE/ AUDITOR/INSPECTOR mapate pe autorități Spring Security).

5. Cerințe nefuncționale (CNF)

Cod	Cerință
CNF-1	Performanță — timp de răspuns API public ≤ 300ms p95 pentru consultare după identificator unic.
CNF-2	Disponibilitate — minim 99,5% uptime pentru API public de consultare (orele lucrătoare critice negociabile cu beneficiarul).
CNF-3	Securitate — autentificare JWT (HS512) pentru portal intern; RBAC pe baza rolurilor funcționale; toate comunicațiile externe peste TLS.
CNF-4	Scalabilitate — arhitectură capabilă să susțină creșterea volumului de interdicții și a numărului de consumatori externi fără rescriere (vezi planul de platformă generică, `platform_design.md §7`).
CNF-5	Localizare — interfață și mesaje în limba română (nativă) și engleză, cu chei i18n în frontend (`webapp/i18n`) și backend (`messages_*.properties`).
CNF-6	Conformitate legală — GDPR/Legea 133 (mascare date sensibile, drept la rectificare prin proces formal, fără ștergere fizică a istoricului juridic).
CNF-7	Trasabilitate — orice modificare a unei interdicții este atribuibilă unui actor și unui moment în timp, ireversibil din jurnalul de audit.
CNF-8	Interoperabilitate (detaliată în CF-11 și `integrare_multiprotocol.md`) — sistemul nu trebuie să impună un limbaj/framework client specific.
CNF-9	Suveranitate date — găzduire pe infrastructură guvernamentală/govcloud RM, fără dependență de cloud public fără justificare legală explicită.
CNF-10	Backup & disaster recovery — RPO ≤ 1 oră, RTO ≤ 4 ore pentru componentele cu efect juridic (interdicții active).

6. Cerințe de interoperabilitate (secțiune dedicată)

Aceasta este o cerință centrală a proiectului, nu opțională: sistemul trebuie proiectat de la început pentru a fi consumat dinamic, din orice limbaj de programare, fără ca echipele externe să fie nevoite să scrie integrări proprietare de la zero.

Sistemul va expune simultan:

REST + OpenAPI — API HTTP/JSON, descris complet în OpenAPI 3.x, versionat (/api/v1), cu SDK-uri client generate automat pentru Java, .NET, Python și Go.
gRPC — contract strict definit în Protocol Buffers, pentru integrări server-to-server cu cerințe de performanță și tipare strictă.
TCP raw — protocol propriu, ușor de implementat în orice limbaj care suportă socket-uri TCP (toate cele patru limbaje de referință o fac nativ), pentru cazurile de utilizare cu cerințe de latență minimă și volum mare (ex. verificare bancară în timp real a unor liste mari de IDNP-uri).

Cerința de bază: toate trei protocoalele rulează peste același strat de servicii de business — nu există nicio regulă de validare sau de tranziție de stare implementată de două ori, în două protocoale diferite.

Specificația tehnică completă (framing, scheme de mesaje, porturi propuse, autentificare per protocol, generare SDK, exemple de cod) este detaliată separat în integrare_multiprotocol.md — documentul de față stabilește doar cerința, nu implementarea.

7. Arhitectura tehnică (rezumat)

Stack confirmat: JHipster 8.11 monolith — Spring Boot 3 + Angular 19 (standalone components), PostgreSQL (prod) / H2 (dev), Elasticsearch (indexare Interdictie și Entitate), JWT (HS512), Liquibase, MapStruct, Ehcache + Hibernate L2. Package md.gov.interdictii.

Detalii complete — diagrame de sistem, componente, ER, lifecycle (state machine), activity și sequence flows — în platform_design.md §1-§6. Planul pe termen lung de extragere a unei platforme generice de registre guvernamentale (reutilizabilă pentru permise, sancțiuni, ONG-uri etc.) este descris în platform_design.md §7.

8. Livrabile contractuale

Model de domeniu finalizat (interdictii.jdl) și aplicație generată (backend + frontend), conform interdictii_full.md.
Cod sursă complet (backend Spring Boot, frontend Angular), versionat în repository Git.
Documentație tehnică completă: arhitectură, schema bazei de date, specificație de integrare multi-protocol.
Specificație OpenAPI 3.x publicată + SDK-uri client generate pentru Java, .NET, Python, Go.
Definiții .proto pentru gRPC + stub-uri generate pentru cele 4 limbaje de referință.
Specificație și implementare server TCP raw (protocol documentat, exemple client minimale pentru cele 4 limbaje).
Suite de teste: JUnit (backend), Jest (frontend), Cypress (E2E), teste de contract pentru cele 3 protocoale de integrare.
Scripturi de deployment (Docker Compose pentru servicii dependente, build de producție).
Manual de operare/mentenanță și ghid de integrare pentru consumatori externi.

9. Etape și planificare

Aliniat cu roadmap-ul orientativ din platform_design.md §7.6:

Fază	Conținut	Durată orientativă
Faza 0	Finalizare model domeniu (`interdictii.jdl` v2) + checklist decizii (`db_schema.md §8`) + caiet de sarcini	— (în curs)
Faza 1	Generare aplicație, workflow DRAFT→ACTIV cu aprobare, ridicare + event log, API public consultare cu mascare	1-3 luni
Faza 1.5	Implementare strat de integrare multi-protocol (REST/OpenAPI, gRPC, TCP raw) + SDK-uri client	1-2 luni
Faza 2	Integrare MSign + MConnect SSO, hardening, document storage (MinIO)	1-2 luni
Faza 3	Extragere `gov-registry-commons` (platformă reutilizabilă, Pattern B din `platform_design.md §7.3`)	2 luni
Faza 4	Al doilea registru pe platformă (validare reuse)	3 luni

10. Criterii de acceptanță / recepție

Toate cele 9 categorii de entități, 11 statuturi, 4 familii de autorități și 4 axe de clasificare din interdictii_full.md sunt implementate și testate (test funcțional per categorie/statut).
Toate tranzițiile de statut din matricea platform_design.md §4 produc exact o intrare în jurnalul de evenimente; UPDATE/DELETE pe jurnal este blocat demonstrabil (test negativ).
API public de consultare returnează exclusiv interdicții ACTIV/ SUSPENDAT, cu mascare GDPR validată.
Toate cele 3 protocoale de integrare (REST, gRPC, TCP raw) sunt funcționale și demonstrează apel end-to-end către același rezultat de business pentru același caz de test (ex. consultare după IDNP).
SDK-urile client (Java, .NET, Python, Go) compilează și execută cu succes un test de fum (smoke test) împotriva mediului de testare.
Suveranitatea datelor (găzduire) și conformitatea GDPR/Legea 133 sunt confirmate de beneficiar înainte de punerea în producție.

11. SLA

Indicator	Țintă
Disponibilitate API public	≥ 99,5%
Timp de răspuns API public (p95)	≤ 300ms
RPO (Recovery Point Objective)	≤ 1 oră
RTO (Recovery Time Objective)	≤ 4 ore
Timp răspuns suport incident critic	≤ 4 ore lucrătoare

12. Mentenanță și suport post-implementare

Suport corectiv (bug-fixing) garantat minimum 12 luni post go-live.
Suport evolutiv (cerințe noi, registre suplimentare) — contract separat, posibil pe baza platformei generice (platform_design.md §7).
Actualizări de securitate (dependențe, framework) — politică de aplicare în maximum 30 zile de la publicarea unei vulnerabilități critice.

13. Cerințe privind echipa de implementare

Experiență dovedită Spring Boot 3 / JHipster, Angular 19 standalone components.
Experiență cu PostgreSQL (inclusiv JSONB), Elasticsearch, Liquibase.
Experiență cu proiectarea de API-uri multi-protocol (REST/OpenAPI, gRPC) și, de preferință, cu protocoale TCP custom.
Cunoștințe privind cadrul legal RM relevant (protecția datelor, semnătură electronică, interoperabilitate guvernamentală) sau capacitate de colaborare strânsă cu juriștii beneficiarului.

14. Anexe

14.1 Glosar (reluat din `Home.md`)

Termen	Definiție
Interdicție	Înregistrarea de registru — restricția juridică emisă de o autoritate asupra unei entități.
Entitate	Subiectul polimorfic al interdicției (persoană, bun, activ).
Acțiune interzisă	Acțiunea concretă blocată, cu scope structurat.
Statut	Una din cele 11 stări ale interdicției.
Autoritate emitentă	Organul care emite interdicția.
Act	Document justificativ atașat unei interdicții.
Temei legal	Articol normativ care fundamentează interdicția.
Condiție	Eveniment/obligație de care depinde efectul unei interdicții condiționate.
Eveniment interdicție	Intrare în jurnalul de audit append-only.
IDNP / IDNO	Identificator național persoană fizică / juridică.
MConnect / MSign	Platforma de interoperabilitate / serviciul de semnătură electronică ale RM.

14.2 Documente de referință

interdictii_full.md — sursa de adevăr a domeniului.
platform_design.md — arhitectură, diagrame, plan platformă generică.
db_schema.md — DDL PostgreSQL și checklist decizii.
integrare_multiprotocol.md — specificație tehnică a stratului de integrare REST/gRPC/TCP raw.
interdictii.jdl — model JHipster JDL autoritativ.
CLAUDE.md (root) — convenții de cod și arhitectură pentru echipa de dezvoltare.