GRegistry — Plan de implementare

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

Plan de execuție „gata de codat” pentru GRegistry — Registrul Sistemelor Informaționale (RSI). Ordinea respectă DEV-PLAYBOOK-ul comun (.claude/skills/playbook.md): spec → ADR → generare din JDL → custom code → frontend → TDD → review → livrare. Sursa modelului este ../GRegistry.jdl; ADR-urile aprobate sunt în adr/.

0. Stare curentă & precondiții

Artefact	Stare
`GRegistry.jdl` (model, sursă de adevăr)	✅ există
`GRegistry.dc.html` (design de referință)	✅ există (Dashboard complet; restul ecranelor = schițe)
Caiet de sarcini (`caiet_de_sarcini.md`)	✅ scris
Design tehnic (`platform_design.md`)	✅ scris
Schema DB (`db_schema.md`)	✅ scris
Model de domeniu (`rsi_domain.md`)	✅ scris
Scenarii de test (`test-scenarios.md`)	✅ scrise (TS-GREGISTRY-01…32)
ADR-uri `adr/ADR-001…008`	✅ Acceptate
Cod generat JHipster	⬜ de făcut (Faza 1)
Proiect GitLab `govtech/gstack/gregistry`	✅ există (remote configurat)

Precondiție de mediu: pe host nu e instalat Java/Maven. Se folosește un container maven:3.9-eclipse-temurin-21 care montează gregistry/, sau un JDK 21 local. JHipster CLI e necesar pentru generare.

Divergențe conștiente față de playbook (documentate în ADR): package md.gov.gregistry (nu systems.esempla.*), fără Kafka/Elasticsearch (ADR-008), clientFramework no cu SPA separat (ADR-007).

Faza 1 — Generare backend din JDL

cd gregistry
jhipster jdl GRegistry.jdl --force     # generează microserviciul în loc (backend)

Rezultă: entități, repository, DTO (MapStruct), servicii, *Resource, *QueryService pentru entitățile filter, changelog-uri Liquibase, pom.xml, mvnw/npmw, config.

Verificare fază: proiectul compilează (./mvnw -ntp compile), pornește pe :8085, Liquibase creează schema. Nu se scrie încă logică de business.

Regulă de aur (ADR-001): entitățile/repos/DTO generate nu se editează manual — se pierd la regenerare. Codul custom stă în clase separate (servicii de business, config, validatori) sau în zone „needle” JHipster.

Faza 2 — Custom code (logica ne-generabilă)

Ordinea de implementat, fiecare cu testul lui scris întâi (TDD, test-scenarios.md):

Audit append-only (ADR-003)
- Changelog Liquibase nou (append-only!) cu trigger BEFORE UPDATE OR DELETE ON registry_audit care ridică excepție (db_schema.md §5).
- RegistryAuditService fără metode de update/delete; helper record(changeType, system, actor, ip, summaryRo/En) apelat din celelalte servicii.
- Test: TS-GREGISTRY audit — UPDATE/DELETE respins la nivel de DB și de serviciu.
Publication state machine (ADR-004)
- PublicationRequestService cu tranziții validate DRAFT→PROPOSED→APPROVED→PUBLISHED, REJECT, UNPUBLISH; tranziții ilegale respinse.
- Guard: doar visibility=PUBLIC poate ajunge PUBLISHED (test negativ).
- Efecte: setează InformationSystem.publishedToPortal; scrie RegistryAudit (PUBLISH/UNPUBLISH/STATUS_CHANGE).
- Teste: happy path, reject, unpublish, invariant „PUBLIC ∧ publishedToPortal”.
Model de citire publică / zone API (ADR-006)
- InformationSystemQueryService: metodă publică ce forțează server-side visibility=PUBLIC ∧ publishedToPortal=true (apelantul nu poate cere sisteme interne).
- Controllere pe zone: /api/v1/public/** (anonim/consumator), /api/v1/staff/**, /api/v1/admin/** (OIDC). Erori RFC 7807.
- Teste: consumator public vede doar PUBLIC+PUBLISHED; scurgere de sisteme interne = fail.
Reguli de dependență (ADR-005)
- SystemDependencyService: interzice auto-dependența (system ≠ dependsOn); scrie audit DEPENDENCY_CHANGE. Endpoint pentru matricea de dependențe (proiecție DTO).
- Teste: creare muchie direcțională; auto-dependență respinsă.
Audit pe mutații — toate operațiile de scriere (create/edit/delete InformationSystem, Environment health change, Provider) apelează RegistryAuditService.record(...) cu ChangeType corect.
Securitate OIDC (ADR-002)
- Config resource server (issuer/JWKS GSSO), mapper claim-uri Keycloak → authorities (ROLE_REGISTRY_ADMIN/EDITOR/VIEWER), reguli de acces pe zone.
- Test: 401 fără token pe zone protejate; zona publică rămâne accesibilă.

Verificare fază: ./mvnw verify verde; toate scenariile din test-scenarios.md mapate pe teste automate.

Faza 3 — i18n

Chei în două locuri: src/main/resources/i18n/messages_{ro,en}.properties (backend) și, pentru SPA, fișierele Angular i18n. Termenii de domeniu rămân ca atare; se traduc etichetele de UI. ro = nativ.

Faza 4 — Frontend Angular (SPA separat) (ADR-007)

Proiect Angular separat; auth Authorization Code + PKCE contra GSSO.
Client generat din OpenAPI (/api/v1/openapi.json).
Ecrane, în ordinea din navigația GRegistry.dc.html:
1. Tablou de bord — KPI-uri (total, publicate, interne/PaaS, medii monitorizate), distribuții pe tip/statut, sănătate medii, modificări recente (din RegistryAudit).
2. Registrul sistemelor — listă filtrabilă/paginată + formular creare/editare sistem.
3. Medii — stare live per mediu, actualizare health.
4. Dependențe — matricea de dependențe.
5. Publicare pe GPortal — coada de cereri + acțiuni propune/aprobă/publică/depublică.
6. Furnizori — CRUD Provider.
7. API & consumatori — ApiEndpoint + RegistryConsumer.
8. Jurnal modificări — RegistryAudit (read-only).
Limbaj vizual: paletă navy/sky-blue, IBM Plex Sans, carduri — extras din Dashboard.

Faza 5 — Testare (docker-compose ridicat de agent) (playbook §9)

docker compose -f src/main/docker/postgresql.yml up -d   # doar Postgres (fără Kafka/ES)
./mvnw verify                                             # unit + integrare
# api_audit.py --base http://localhost:8085               # conformitate Standard API
docker compose -f src/main/docker/postgresql.yml down -v  # oprește ȘI curăță (în finally)

Niveluri: unit (reguli de business), integrare (repository/endpoint pe Postgres real, Testcontainers), API-conformitate (health/live, health/ready, metrics, RFC 7807), e2e frontend (când există).
Fiecare scenariu din test-scenarios.md = un test automat verde. Nimic „should/probably”.

Faza 6 — Review, livrare, checkpoint

reviewer gate: spec + cod + Standard API. CRITICAL → înapoi la Faza 2/5.
MR pe branch feat/<task-id> cu Closes #<issue> — niciodată push în main.
Checkpoint: task-ledger + state.json + wiki gregistry/Stare; issue GitLab comentat.

Definition of Done (rezumat — vezi playbook §10)

Generat din JDL; custom code doar unde JHipster nu acoperă.
Append-only audit (serviciu + trigger) verificat.
Publication state machine + guard vizibilitate verificate.
Zona publică nu întoarce niciodată sisteme interne/test.
Frontend aliniat la GRegistry.dc.html.
Teste unit + integrare verzi pe docker-compose ridicat/oprit de agent; api_audit.py trece.
Lint curat, build OK; i18n ro+en complet.
Scenarii documentate (test-scenarios.md) ↔ teste automate.
reviewer = APPROVE; MR legat de issue; checkpoint scris.

Secvențierea recomandată (drum critic)

Faza1 (generare) → Audit append-only → Publication SM → Zone API/public read
   → Reguli dependență → Audit pe mutații → Securitate OIDC → i18n
   → Frontend (Dashboard întâi) → Testare completă → Review → Livrare

Elementele independente care se pot paraleliza: Furnizori CRUD, ApiEndpoint/Consumer, și ecranele de frontend care nu depind de fluxul de publicare.