Caiet de sarcini — GRegistry, Registrul Sistemelor Informaționale (RSI)

Acest conținut nu este încă disponibil în limba selectată.

Document formal de specificare a cerințelor de proiect. Pentru modelul de domeniu autoritativ, vezi ../GRegistry.jdl; pentru arhitectură platform_design.md, pentru schema bazei de date db_schema.md, pentru glosar și punctul de intrare în wiki Home.md, iar pentru deciziile de arhitectură adr/.

1. Denumirea proiectului și context

Denumire: GRegistry — Registrul Sistemelor Informaționale (RSI): sistem informatic care constituie sursa unică de adevăr (single source of truth) pentru catalogul tuturor sistemelor informaționale ale platformei guvernamentale GStack din Republica Moldova.

Beneficiar: autoritate/instituție publică a Republicii Moldova (administratorul platformei GStack — de regulă STISC); consumatori interni ai registrului — GPortal (portalul public de servicii), GLog (jurnalizare centralizată), GStorage (arhivare/stocare) și GMonitor (monitorizare disponibilitate). Furnizorii de sisteme (instituții și organizații care dețin/ operează sisteme înregistrate) sunt utilizatori activi ai registrului.

Rolul în platformă: GRegistry este componenta de infrastructură (systemType = INFRASTRUCTURE) care ține evidența fiecărui sistem al platformei — codul stabil, categoria, tipul, statutul de ciclu de viață, vizibilitatea, criticitatea, nivelul de securitate, prelucrarea de date cu caracter personal, versiunea curentă, responsabilul tehnic, mediile de rulare, dependențele și starea de publicare pe portalul public. Toate celelalte sisteme ale platformei citesc din GRegistry; niciun alt sistem nu deține în paralel această evidență.

Cadru de referință (neexhaustiv — se confirmă cu beneficiarul înainte de implementare):

Cadrul de interoperabilitate a sistemelor informaționale de stat (MConnect/ platforma de interoperabilitate a RM).
Standardul de API guvernamental GovStack (versionare api/v1, zone de acces, probe de sănătate, metrici, erori RFC 7807 — vezi §6).
Legea nr. 133/2011 privind protecția datelor cu caracter personal (relevantă pentru marcajul handlesPersonalData și pentru datele de contact ale furnizorilor/responsabililor tehnici).
Politicile de securitate cibernetică aplicabile sistemelor informaționale de stat.

Justificare: pe măsură ce platforma GStack crește (peste 20 de sisteme — CORE, aplicative, PaaS, infrastructură — deținute de furnizori diferiți), lipsa unui catalog central, autoritativ și interconectat generează evidențe divergente, dependențe nedocumentate, publicare necontrolată pe portalul public și absența unei imagini unice a sănătății mediilor. GRegistry rezolvă acest lucru: centralizează metadatele fiecărui sistem, guvernează publicarea pe GPortal printr-un flux de aprobare și expune un API de citire standardizat pentru toți consumatorii platformei.

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 GRegistry — RSI.

2.1 Obiective generale

Constituirea unei surse unice de adevăr pentru toate sistemele informaționale ale platformei GStack, consumabilă de orice alt sistem al platformei printr-un API stabil, versionat.
Modelarea completă a fiecărui sistem: identitate (code, name), clasificare (systemType, category), ciclu de viață (status), vizibilitate, criticitate, nivel de securitate și relevanță GDPR (handlesPersonalData).
Evidența mediilor de rulare (prod/staging/test/dev) ale fiecărui sistem, cu endpoint, versiune desfășurată și stare de sănătate live.
Evidența dependențelor dintre sisteme (graful de consum tipizat), care alimentează matricea de dependențe și analizele de impact.
Guvernarea publicării pe GPortal printr-un flux de aprobare controlat (DRAFT → PROPOSED → APPROVED → PUBLISHED), astfel încât doar sistemele cu vizibilitate PUBLIC să ajungă pe portalul public.
Asigurarea unei piste de audit imutabile (append-only) pentru fiecare modificare a registrului, retransmisă către GLog pentru jurnalizare centrală.
Proiectarea API-first (fără client încorporat): interfața de administrare este un SPA Angular separat, iar API-ul este consumat direct de GPortal, GLog, GStorage și GMonitor.

2.2 Obiective specifice

Acoperirea integrală a entităților din modelul de domeniu autoritativ (../GRegistry.jdl): Provider, InformationSystem, Environment, SystemDependency, PublicationRequest, ApiEndpoint, RegistryConsumer, RegistryAudit.
Acoperirea celor 4 tipuri de sistem (CORE, BUSINESS, PAAS, INFRASTRUCTURE), a celor 5 statuturi de ciclu de viață (PLANNED, DEMO, ACTIVE, DEPRECATED, RETIRED) și a celor 3 niveluri de vizibilitate (PUBLIC, INTERNAL, TEST).
Acoperirea celor 4 tipuri de mediu (PRODUCTION, STAGING, TEST, DEV) și a celor 5 stări de sănătate (UP, DEGRADED, DOWN, PLANNED, NONE).
Acoperirea celor 5 tipuri de dependență (API, EVENT, DATA, AUTH, STORAGE) și a celor 5 protocoale de API (REST, GRAPHQL, SOAP, GRPC, EVENT).
Acoperirea celor 6 stări de publicare (DRAFT, PROPOSED, APPROVED, PUBLISHED, REJECTED, UNPUBLISHED) și a celor 8 tipuri de modificare auditate (CREATE, EDIT, PUBLISH, UNPUBLISH, ENV_CHANGE, DEPENDENCY_CHANGE, STATUS_CHANGE, DELETE).

Această acoperire este deja modelată în ../GRegistry.jdl — caietul de sarcini confirmă acest domeniu ca fiind complet și obligatoriu de implementat; nu introduce cerințe noi de domeniu.

3. Domeniul de aplicare

Domeniul complet este definit în ../GRegistry.jdl. Rezumat:

Componentă domeniu	Acoperire cerută
Furnizori (`Provider`)	Instituții/organizații care dețin sisteme: cod, denumire, denumire juridică, contact, website, activ
Sisteme (`InformationSystem`)	Entitatea centrală citită de toți consumatorii; cod unic, tip, statut, vizibilitate, criticitate, securitate, GDPR, versiune, responsabil tehnic
Tipuri sistem (`SystemType`)	4: CORE, BUSINESS, PAAS, INFRASTRUCTURE
Statut sistem (`SystemStatus`)	5: PLANNED, DEMO, ACTIVE, DEPRECATED, RETIRED
Vizibilitate (`Visibility`)	3: PUBLIC, INTERNAL, TEST
Criticitate (`Criticality`)	4: CRITICAL, IMPORTANT, NORMAL, LOW
Nivel securitate (`SecurityLevel`)	3: HIGH, MEDIUM, LOW
Medii (`Environment`)	4 tipuri × 5 stări de sănătate; endpoint, versiune desfășurată, monitorizat, ultima verificare
Dependențe (`SystemDependency`)	Graf orientat tipizat (5 tipuri), `required`, notă
Publicare (`PublicationRequest`)	Flux 6 stări cu aprobator, momente, vizibilitate solicitată, comentariu
Endpoint-uri API (`ApiEndpoint`)	Suprafața de API a sistemului: cale, protocol (5), metodă, `publicApi`
Consumatori (`RegistryConsumer`)	Cititori înregistrați ai registrului cu expresie de filtrare
Audit (`RegistryAudit`)	Pistă imutabilă append-only, retransmisă către GLog

Modulele funcționale ale sistemului corespund navigației din interfața de administrare (../GRegistry.dc.html): Tablou de bord, Registrul sistemelor, Medii, Dependențe (grupul Registru), plus Publicare pe GPortal, Furnizori, API & consumatori, Jurnal modificări (grupul Guvernanță).

4. Cerințe funcționale (CF)

CF-1. Registrul sistemelor (modul central — `InformationSystem`)

CF-1.1 CRUD complet pentru sistem, cu code unic și imutabil după creare (^[a-z][a-z0-9-]*$, 2–80 caractere) — acesta este cheia de join folosită de toți consumatorii; modificarea codului este interzisă (creare sistem nou dacă e necesar).
CF-1.2 Câmpuri obligatorii la creare: name, systemType, status, visibility, criticality, securityLevel, handlesPersonalData, publishedToPortal, plus provider (relație obligatorie). Câmpuri opționale: category, currentVersion, descriptionRo, descriptionEn, techLead, techLeadEmail.
CF-1.3 Ciclu de viață pe status: PLANNED → DEMO → ACTIVE → DEPRECATED → RETIRED; fiecare tranziție de statut generează un eveniment de audit de tip STATUS_CHANGE (vezi CF-8). Regulile de tranziție permise sunt aplicate în stratul de servicii (nu în controller).
CF-1.4 Câmpul publishedToPortal este denormalizat și reflectă starea fluxului de publicare (CF-5): el nu se editează manual, ci este actualizat de tranzițiile PUBLISHED/UNPUBLISHED ale PublicationRequest.
CF-1.5 Auto-populare createdAt/updatedAt la creare și la fiecare modificare.
CF-1.6 Filtrare și paginare pe listă (vezi CF-9 și CNF): după systemType, status, visibility, criticality, securityLevel, handlesPersonalData, publishedToPortal, provider și căutare după code/name.
CF-1.7 Fiecare creare/editare/ștergere produce un eveniment de audit (CREATE/EDIT/DELETE) conform CF-8.

CF-2. Furnizori (`Provider`)

CF-2.1 CRUD furnizori cu code unic (2–60 caractere), name obligatoriu, legalName, contactEmail (validat prin pattern e-mail), website și marcaj active obligatoriu.
CF-2.2 Un sistem aparține exact unui furnizor (relație obligatorie InformationSystem → Provider); un furnizor poate deține N sisteme.
CF-2.3 Interzicerea ștergerii unui furnizor care mai deține sisteme active (integritate referențială); dezactivarea (active = false) în locul ștergerii pentru furnizorii istorici.
CF-2.4 Listă cu numărul de sisteme deținute per furnizor.

CF-3. Medii de rulare (`Environment`)

CF-3.1 Un sistem poate avea mai multe medii (prod/staging/test/dev). Fiecare mediu are environmentType și state obligatorii, plus endpointUrl, deployedVersion, monitored (obligatoriu) și lastCheckedAt.
CF-3.2 Starea de sănătate (UP, DEGRADED, DOWN, PLANNED, NONE) poate fi actualizată manual de operator sau automat de GMonitor prin API-ul de scriere (heartbeat/health push), actualizând state și lastCheckedAt.
CF-3.3 Orice schimbare de stare a unui mediu produce un eveniment de audit de tip ENV_CHANGE (CF-8).
CF-3.4 Vizualizare agregată „Sănătate medii” pe tabloul de bord (câte medii UP din total, per tip de mediu — vezi CF-9).
CF-3.5 Filtrare medii după environmentType, state, monitored, sistem.

CF-4. Dependențe între sisteme (`SystemDependency` — matricea de dependențe)

CF-4.1 Modelarea unei dependențe orientate: system (consumatorul) depinde de dependsOn (serviciul consumat) — ambele referințe către InformationSystem, obligatorii.
CF-4.2 Fiecare dependență are kind (API, EVENT, DATA, AUTH, STORAGE) și marcaj required obligatoriu, plus note opțională.
CF-4.3 Generarea matricei de dependențe (cine consumă pe cine) și a vizualizărilor „depinde de” / „este consumat de” pentru un sistem dat.
CF-4.4 Analiză de impact: la marcarea unui sistem ca DEPRECATED/RETIRED, afișarea sistemelor care depind obligatoriu (required = true) de el.
CF-4.5 Interzicerea dependențelor reflexive triviale (un sistem față de el însuși) și avertizare la introducerea de cicluri.
CF-4.6 Orice adăugare/modificare/ștergere de dependență produce un eveniment de audit DEPENDENCY_CHANGE (CF-8).

CF-5. Publicare pe GPortal (`PublicationRequest` — flux de aprobare)

CF-5.1 Flux de stări: DRAFT → PROPOSED → APPROVED → PUBLISHED, cu ramurile REJECTED (respins la aprobare) și UNPUBLISHED (retras de pe portal).
CF-5.2 Precondiție obligatorie: doar sistemele cu visibility = PUBLIC pot fi propuse/publicate. Propunerea unui sistem INTERNAL sau TEST este respinsă la nivel de serviciu.
CF-5.3 Trasabilitatea fluxului: requestedBy/requestedAt la propunere, approvedBy/approvedAt la aprobare, publishedAt la publicare, requestedVisibility (snapshot) și comment (motivare, obligatorie la REJECTED).
CF-5.4 La tranziția PUBLISHED, actualizarea flagului denormalizat InformationSystem.publishedToPortal = true; la UNPUBLISHED, revenire la false (CF-1.4).
CF-5.5 Segregarea rolurilor: cel care propune (PROPOSED) nu poate fi același cu cel care aprobă (APPROVED) — regulă de tip „four-eyes”.
CF-5.6 Fiecare tranziție de publicare produce un eveniment de audit (PUBLISH/UNPUBLISH) conform CF-8.
CF-5.7 Un sistem poate avea mai multe cereri de publicare în timp (istoric); se afișează cererea curentă și istoricul.

CF-6. Suprafața de API a sistemelor (`ApiEndpoint`)

CF-6.1 CRUD endpoint-uri pentru un sistem: path obligatoriu, protocol (REST, GRAPHQL, SOAP, GRPC, EVENT), method (verb HTTP unde aplicabil), description, publicApi (obligatoriu).
CF-6.2 Marcajul publicApi distinge endpoint-urile expuse extern (prin gateway/GPortal) de cele interne.
CF-6.3 Expunerea catalogului de endpoint-uri publice ale unui sistem prin API-ul de citire, pentru consum de către GPortal (secțiunea „API & consumatori”).

CF-7. Consumatori ai registrului (`RegistryConsumer`)

CF-7.1 CRUD consumatori înregistrați (GPortal, GLog, GStorage, GMonitor și alți cititori): name obligatoriu, description, filterExpression (ex. vis=public), active obligatoriu.
CF-7.2 filterExpression definește subsetul de sisteme pe care consumatorul îl citește (ex. GPortal citește doar sistemele publice și publicate); expresia este validată sintactic.
CF-7.3 Evidența ultimului acces per consumator și posibilitatea dezactivării (active = false) fără ștergere.

CF-8. Jurnal de modificări (audit append-only — `RegistryAudit`)

CF-8.1 Fiecare operație asupra registrului produce exact o intrare de audit imutabilă: changeType (CREATE, EDIT, PUBLISH, UNPUBLISH, ENV_CHANGE, DEPENDENCY_CHANGE, STATUS_CHANGE, DELETE), actor (obligatoriu), summaryRo/summaryEn, ipAddress, occurredAt (obligatoriu) și referința opțională către sistemul afectat.
CF-8.2 Interzicere absolută a UPDATE/DELETE pe tabela de audit — la nivel de aplicație (repository fără operații de modificare) și la nivel de bază de date (trigger/constrângere). Vezi convenția de audit din db_schema.md.
CF-8.3 Fiecare intrare de audit este retransmisă către GLog pentru jurnalizare centralizată (fire-and-forget, fără a bloca tranzacția de business; retransmiterea eșuată se reia).
CF-8.4 Filtrare/paginare a jurnalului după changeType, actor, sistem și interval de timp; raportare „ce a modificat utilizatorul X în perioada Y”.
CF-8.5 Feed „Modificări recente” pe tabloul de bord (CF-9).

CF-9. Tablou de bord (`Dashboard`)

CF-9.1 Indicatori agregați: total sisteme, sisteme publicate pe GPortal, sisteme interne/PaaS nepublicate, medii monitorizate (și câte cu probleme).
CF-9.2 Distribuția sistemelor pe tip (CORE/BUSINESS/PAAS/ INFRASTRUCTURE) și pe statut (ACTIVE/DEMO/PLANNED/RETIRED).
CF-9.3 Progresul publicării (X din N sisteme publicate) și rezumatul de sănătate a mediilor per tip (prod/staging/test).
CF-9.4 Feed de modificări recente alimentat din jurnalul de audit (CF-8.5).
CF-9.5 Toate valorile din tabloul de bord provin exclusiv din API-ul de citire al registrului (fără surse paralele).

CF-10. API de citire pentru consumatori (GPortal, GLog, GStorage, GMonitor)

CF-10.1 API de citire versionat (api/v1) care expune sistemele, mediile, dependențele și endpoint-urile, cu filtrare (ex. vis=public, published=true, type=CORE) și paginare.
CF-10.2 Zona publică a API-ului expune doar sistemele cu visibility = PUBLIC și publishedToPortal = true (consum de către GPortal); sistemele INTERNAL/TEST nu părăsesc registrul prin zona publică.
CF-10.3 Zonele interne (staff/admin) expun evidența completă pentru consumatorii autentificați (GMonitor pentru medii, GLog pentru audit).
CF-10.4 API de scriere restrânsă pentru GMonitor: actualizarea stării de sănătate a mediilor (state, lastCheckedAt) — vezi CF-3.2 — fără drept de modificare a altor câmpuri.
CF-10.5 Fiecare consum este atribuit unui RegistryConsumer înregistrat (CF-7) și respectă filterExpression-ul acestuia.
CF-10.6 Erori standardizate RFC 7807 (application/problem+json) și răspunsuri conforme standardului GovStack (vezi §6).

CF-11. Administrare, autentificare și roluri (GSSO / Keycloak)

CF-11.1 Autentificare prin GSSO (Keycloak) cu OAuth2/OIDC; sistemul nu ține parole proprii (authenticationType = oauth2).
CF-11.2 RBAC pe autorități Spring Security mapate din claim-urile de rol Keycloak: minim ROLE_ADMIN (administrator registru — CRUD complet, aprobare publicare) și ROLE_EDITOR (furnizor/operator — editare sisteme proprii, propunere publicare, fără aprobare).
CF-11.3 Segregarea sarcinilor la publicare (CF-5.5): rolul de aprobare este distinct de rolul de propunere.
CF-11.4 Interfața de administrare este un SPA Angular separat (arhitectură API-first, clientFramework no) care consumă API-ul GRegistry; GRegistry nu livrează un client web încorporat.

5. Cerințe nefuncționale (CNF)

Cod	Cerință
CNF-1	Performanță — timp de răspuns API de citire ≤ 300 ms p95 pentru interogări după `code` sau listă filtrată paginată; registrul este read-heavy, cu cache Ehcache + Hibernate L2.
CNF-2	Disponibilitate — minim 99,5% uptime pentru API-ul de citire (este dependență directă a GPortal, GLog, GStorage, GMonitor).
CNF-3	Securitate — autentificare OAuth2/OIDC prin GSSO (Keycloak); RBAC pe autorități; toate comunicațiile peste TLS; zone de acces separate (public/citizen/staff/admin — vezi §6).
CNF-4	Scalabilitate — arhitectură de microserviciu (Spring Boot, port 8085) integrabilă în platforma GStack, capabilă să susțină creșterea numărului de sisteme și de consumatori fără rescriere.
CNF-5	Localizare — API și mesaje în limba română (nativă) și engleză; descrieri bilingve la nivel de entitate (`descriptionRo`/`descriptionEn`, `summaryRo`/`summaryEn`); chei i18n în SPA și în `messages_*.properties` (backend).
CNF-6	Conformitate GDPR/Legea 133 — marcajul `handlesPersonalData` per sistem; datele de contact (furnizor, responsabil tehnic) sunt tratate ca date personale; fără ștergere fizică a istoricului de audit.
CNF-7	Trasabilitate — orice modificare a registrului este atribuibilă unui `actor`, unui `ipAddress` și unui `occurredAt`, ireversibil din jurnalul de audit append-only (CF-8).
CNF-8	Interoperabilitate — conformitate cu standardul de API GovStack (§6); API-first, contract OpenAPI publicat, consumabil de orice sistem al platformei.
CNF-9	Suveranitate date — găzduire pe infrastructura guvernamentală/govcloud RM, în cadrul platformei GStack.
CNF-10	Backup & disaster recovery — RPO ≤ 1 oră, RTO ≤ 4 ore; registrul fiind sursă unică de adevăr, indisponibilitatea lui afectează întreaga platformă.
CNF-11	Fără Kafka, fără Elasticsearch — spre deosebire de registrul Interdicții, GRegistry nu folosește un event-bus Kafka și nu indexează în Elasticsearch; filtrarea și căutarea se fac în PostgreSQL (JPA Criteria + paginare). Retransmiterea către GLog se face prin apel de serviciu, nu prin bus.
CNF-12	Observabilitate — probe `/health/live`, `/health/ready` și endpoint `/metrics` conforme GovStack (§6); GMonitor consumă aceste probe.

6. Cerințe de interoperabilitate (standardul GovStack API)

GRegistry respectă standardul de API guvernamental GovStack, comun tuturor sistemelor platformei. Cerințe concrete:

Versionare — toate rutele de business sub prefixul api/v1; schimbările incompatibile introduc o versiune nouă, fără a rupe consumatorii existenți.
Zone de acces — API-ul este segmentat pe zone:
- public — date deschise (sisteme publice și publicate), fără autentificare sau cu autentificare minimă;
- citizen — date pentru utilizatori autentificați (unde aplicabil);
- staff — evidență internă completă pentru operatorii registrului;
- admin — administrare (aprobare publicare, gestiune consumatori, roluri).
Probe de sănătate — /health/live (liveness) și /health/ready (readiness), consumate de GMonitor și de orchestrator.
Metrici — endpoint /metrics pentru scraping (formatul convenit la nivel de platformă).
Erori — format RFC 7807 (application/problem+json) uniform pentru toate răspunsurile de eroare.
Contract — specificație OpenAPI 3.x publicată și versionată, sursă pentru generarea clienților consumatorilor.

Consumatorii nativi ai registrului sunt GPortal, GLog, GStorage și GMonitor; fiecare este înregistrat ca RegistryConsumer (CF-7) și citește prin zona și filterExpression-ul care îi corespund. Retransmiterea auditului către GLog (CF-8.3) se face prin apel de serviciu HTTP, fără magistrală de evenimente (vezi CNF-11).

7. Arhitectura tehnică (rezumat)

Stack confirmat (din ../GRegistry.jdl): JHipster microserviciu — Spring Boot 3, package md.gov.gregistry, port 8085, PostgreSQL (dev și prod), autentificare oauth2 (GSSO/Keycloak, OIDC), cache Ehcache + Hibernate L2, Liquibase, MapStruct (DTO), servicii cu serviceClass. Fără Kafka, fără Elasticsearch. clientFramework no (API-first) — UI-ul este un SPA Angular separat, iar API-ul este consumat de GPortal. Limbi: ro (nativă) + en. Teste E2E: Cypress.

Layering standard JHipster — modificările se păstrează în stratul corect:

SPA Angular / consumatori  --HTTPS+OIDC-->  web.rest.*Resource (doar DTO)
   -> service.*Service (+ QueryService pentru filtrare JPA Criteria)
   -> service.mapper (MapStruct, entity<->DTO)
   -> repository.*Repository (Spring Data JPA)  -> PostgreSQL

Entitățile nu părăsesc stratul de servicii — controllerele fac schimb doar de DTO.
Filtrarea URL-driven există doar pe entitățile declarate filter în JDL: InformationSystem, Environment, PublicationRequest, SystemDependency.
Paginare pe InformationSystem, RegistryAudit, Environment, PublicationRequest.
Regulile de ciclu de viață (statut sistem, flux de publicare) sunt aplicate în stratul de servicii; fiecare tranziție scrie un RegistryAudit.
RegistryAudit este write-only (append-only) — vezi CF-8.2.

Detalii complete — diagrame de sistem, componente, ER, fluxuri — în platform_design.md. Schema PostgreSQL derivată din JDL, convenția append-only și trigger-ele de audit — în db_schema.md. Deciziile de arhitectură — în adr/.

8. Livrabile contractuale

Model de domeniu finalizat (../GRegistry.jdl) și microserviciu generat (backend Spring Boot), conform prezentului caiet de sarcini.
SPA Angular separat pentru administrare (Registrul sistemelor, Medii, Dependențe, Publicare, Furnizori, API & consumatori, Jurnal modificări, Tablou de bord).
Cod sursă complet (backend + SPA), versionat în repository Git (git.esempla.systems/govtech/gstack/gregistry).
Specificație OpenAPI 3.x publicată, versionată (api/v1), conformă standardului GovStack (§6), cu zone de acces documentate.
Documentație tehnică: arhitectură (platform_design.md), schema bazei de date (db_schema.md), glosar (Home.md) și decizii de arhitectură (adr/).
Migrări Liquibase (append-only), inclusiv trigger-ele de blocare UPDATE/DELETE pe tabela de audit.
Integrări documentate cu GSSO (OIDC), GLog (retransmitere audit) și GMonitor (health push pe medii).
Suite de teste: JUnit (backend), Cypress (E2E), teste de contract pentru API-ul de citire consumat de GPortal/GLog/GStorage/GMonitor.
Scripturi de deployment (Docker Compose pentru PostgreSQL, build de producție) și ghid de integrare pentru consumatori.

9. Etape și planificare

Fază	Conținut	Durată orientativă
Faza 0	Finalizare model domeniu (`../GRegistry.jdl`) + caiet de sarcini + ADR-uri inițiale	— (în curs)
Faza 1	Generare microserviciu; CRUD Sisteme + Furnizori; ciclu de viață statut cu audit; API de citire (zona public/staff) consumat de GPortal	1–2 luni
Faza 2	Medii + sănătate (health push GMonitor); Dependențe + matrice; Tablou de bord	1–2 luni
Faza 3	Flux de publicare pe GPortal (aprobare four-eyes); API & endpoint-uri; Consumatori; retransmitere audit către GLog	1–2 luni
Faza 4	Integrare GSSO (OIDC) end-to-end, hardening securitate, OpenAPI publicat + clienți consumatori, conformitate GovStack completă	1 lună

10. Criterii de acceptanță / recepție

Toate cele 8 entități din ../GRegistry.jdl sunt implementate, cu toate enumerările (tip, statut, vizibilitate, criticitate, securitate, tip mediu, stare mediu, stare publicare, tip modificare, protocol, tip dependență) și relațiile lor.
code-ul unui sistem este unic, validat prin pattern și imutabil după creare (test negativ la modificare).
Fiecare tranziție de statut de sistem, schimbare de mediu, modificare de dependență și tranziție de publicare produce exact o intrare în RegistryAudit; UPDATE/DELETE pe audit este blocat demonstrabil la nivel de aplicație și de bază de date (test negativ).
Fluxul de publicare respectă precondiția visibility = PUBLIC și segregarea four-eyes; publishedToPortal este actualizat corect la PUBLISHED/ UNPUBLISHED.
Zona publică a API-ului returnează exclusiv sistemele PUBLIC + publicate; sistemele INTERNAL/TEST nu sunt expuse public (test).
GMonitor poate actualiza starea unui mediu prin API-ul de scriere restrânsă, fără a modifica alte câmpuri (test de autorizare).
Fiecare intrare de audit este retransmisă către GLog; eșecul retransmiterii nu blochează tranzacția de business și este reluat (test).
API-ul respectă standardul GovStack: api/v1, zone de acces, /health/live, /health/ready, /metrics, erori RFC 7807 (test de contract).
Autentificarea prin GSSO (OIDC) și maparea rolurilor ROLE_ADMIN/ROLE_EDITOR sunt funcționale end-to-end.
Suveranitatea datelor (găzduire GStack/govcloud RM) este confirmată de beneficiar înainte de punerea în producție.

11. SLA

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

Notă: GRegistry fiind sursa unică de adevăr a platformei, indisponibilitatea lui degradează GPortal, GLog, GStorage și GMonitor; de aceea țintele de disponibilitate și RTO sunt tratate ca fiind critice pentru întreaga platformă.

12. Mentenanță și suport post-implementare

Suport corectiv (bug-fixing) garantat minimum 12 luni post go-live.
Suport evolutiv (câmpuri/enumerări noi, consumatori suplimentari, extinderea fluxului de publicare) — contract separat.
Actualizări de securitate (dependențe, framework, Keycloak/GSSO) — politică de aplicare în maximum 30 zile de la publicarea unei vulnerabilități critice.
Migrări Liquibase strict append-only; niciun changelog comis nu se editează.

13. Cerințe privind echipa de implementare

Experiență dovedită Spring Boot 3 / JHipster (microservicii), API-first.
Experiență Angular (SPA standalone) pentru interfața de administrare.
Experiență PostgreSQL (JPA Criteria, filtrare/paginare), Liquibase (inclusiv trigger-e de audit).
Experiență cu OAuth2/OIDC și Keycloak (integrare GSSO).
Cunoașterea standardului de API GovStack (versionare, zone, probe, RFC 7807) sau capacitate de aliniere rapidă la acesta.

14. Anexe

14.1 Glosar (reluat din `Home.md`)

Termen	Definiție
GRegistry / RSI	Registrul Sistemelor Informaționale — sursa unică de adevăr a platformei GStack.
InformationSystem (Sistem)	Înregistrarea centrală: un sistem informațional al platformei, citit de toți consumatorii.
Provider (Furnizor)	Instituția/organizația care deține și operează unul sau mai multe sisteme.
Environment (Mediu)	Un mediu de rulare al unui sistem (prod/staging/test/dev) cu stare de sănătate live.
SystemDependency (Dependență)	Relație orientată tipizată: un sistem consumă un alt sistem.
PublicationRequest (Cerere de publicare)	Fluxul de aprobare pentru expunerea unui sistem pe GPortal.
ApiEndpoint	Un punct din suprafața de API a unui sistem (cale, protocol, metodă).
RegistryConsumer (Consumator)	Sistem înregistrat care citește din registru (GPortal, GLog, GStorage, GMonitor).
RegistryAudit (Jurnal de modificări)	Pistă de audit imutabilă append-only, retransmisă către GLog.
GPortal / GLog / GStorage / GMonitor	Sistemele consumatoare ale registrului: portal public / jurnalizare / stocare / monitorizare.
GSSO	Serviciul de autentificare unic al platformei (Keycloak, OIDC).
GovStack	Platforma și standardul de API guvernamental al Republicii Moldova.

14.2 Documente de referință

../GRegistry.jdl — model JHipster JDL autoritativ (sursa de adevăr a domeniului).
platform_design.md — arhitectură, diagrame, fluxuri.
db_schema.md — schema PostgreSQL și convenția de audit append-only.
Home.md — punct de intrare în wiki și glosar.
adr/ — deciziile de arhitectură (Architecture Decision Records).
../GRegistry.dc.html — machetă UI (module de navigație: Tablou de bord, Registrul sistemelor, Medii, Dependențe, Publicare pe GPortal, Furnizori, API & consumatori, Jurnal modificări).