GLog — Specificație Tehnică Completă

Serviciul de Audit și Jurnalizare GovStack (Building Block PaaS) · succesorul MLog · cod arhitectură JLS Document unic, coerent: scop → actori → cazuri de utilizare → sistemul ca acțiuni → colectarea datelor → API → afișarea/consumul datelor → interfața utilizator → model de date → cerințe (tabelar, trasabile la ADR).

Public țintă dublu: (1) echipa de dezvoltare GLog — urmărirea cerințelor în implementare; (2) echipele altor sisteme — cunoașterea capacităților GLog pentru a-și planifica integrarea.

Câmp	Valoare
Document	Specificație Tehnică Completă
Sistem	GLog — Serviciul de Audit și Jurnalizare
Versiune	0.1 (draft, în lucru)
Autor	Esempla Systems · GovStack
Data	2026-06-25
Cod / repo	`govtech/gstack/glog` (GitLab)
ADR-uri	GLog-ADR-001 … GLog-ADR-010
Legendă stare	✅ implementat & testat · 🟡 de finalizat · ⛔ blocat (dependență externă)

1. Scop și context

1.1 Scopul sistemului

GLog este componenta comună (Building Block) de audit și jurnalizare a platformei GovStack. Orice sistem informațional de stat îi trimite evenimente de audit (cine, ce, când, în ce sistem, asupra cărui obiect), iar GLog le validează, le sigilează tamper-evident, le stochează izolat per sistem (multi-tenant), le redirecționează către sisteme externe (MLog, OpenSearch, SIEM) și le reține conform politicii. GLog este succesorul compatibil al MLog (HG 708/2014).

1.2 De ce există (problema rezolvată)

Astăzi auditul e fie o bibliotecă in-process (blochează tranzacția de business, single-tenant, fără integritate verificabilă), fie un microserviciu izolat fără retenție și fără izolare. GLog îl înlocuiește cu un serviciu PaaS reutilizabil: 1 BB pentru N sisteme, zero duplicare.

1.3 Pentru cine (și cum se citește documentul)

Dezvoltatorii GLog citesc tot, urmăresc §11–§12 (cerințe tabelare + trasabilitate ADR) ca listă de lucru.
Sistemele integratoare citesc §3 (capacități), §6 (colectarea datelor), §7 (API), §8 (consumul datelor) — de aici își planifică integrarea înainte ca GLog să intre în producție.

1.4 Capacitatea de planificare pentru alte sisteme

Acest document este contractul de capacitate publicat pe portal. Pe baza lui, un sistem consumator poate decide: ce mod de ingest folosește (REST/AMQP/Kafka/SDK), ce câmpuri trimite, cum citește/verifică auditul, ce SLA-uri să aștepte — fără a aștepta lansarea în producție. Stările (✅/🟡) indică ce e deja disponibil în mediile de test și ce urmează.

2. Actori și roluri

Actor	Tip	Rol față de GLog
Sistem SaaS consumator (.NET / Java)	sistem	Produce evenimente de audit; consumă date de audit
Broker de evenimente (RabbitMQ / Kafka)	sistem	Sursă asincronă de evenimente
Operator platformă GovStack	uman	Administrează nomenclatoare, retenție, tenanți
Auditor / organ de control	uman	Verifică integritatea; consultă evenimentele autorizate
Keycloak (ATS)	sistem	Emite JWT (scope + claim `tenant`)
MLog / OpenSearch / SIEM	sistem	Destinații de forward

Scope-uri (roluri tehnice): audit:write (scriere), audit:read (citire), audit:admin (administrare), audit:admin:cross-tenant (operatori platformă).

3. Capacitățile sistemului (rezumat pentru integratori)

Ce poate face un sistem consumator cu GLog:

#	Capacitate	Cum o accesează	Stare
C1	Trimite evenimente de audit sincron	REST `POST /api/v1/app/audit-events`	✅
C2	Trimite evenimente în lot	REST `:batch` (max 500)	🟡
C3	Trimite evenimente asincron, volum mare	AMQP (RabbitMQ)	✅
C4	Trimite evenimente prin streaming	Kafka consumer	🟡
C5	Integrează prin pachet, cu buffer local	SDK NuGet (.NET) / Nexus (Java)	🟡
C6	Citește/filtrează auditul propriu	REST `GET /api/v1/app/audit-events` (paginat)	✅
C7	Vede detaliul unui eveniment	REST `GET …/audit-events/{id}`	✅
C8	Exportă auditul (CSV/XLSX)	REST `…/export`	🟡
C9	Verifică integritatea (tamper-evidence)	REST `GET …/admin/audit-events/integrity`	✅
C10	Primește auditul redirecționat (SIEM/OpenSearch)	Webhook / index	✅
C11	Rămâne compatibil cu MLog	Forward MLog (JOSE/mTLS)	⛔ (schema MLog)

Garanție de izolare: un sistem vede și interoghează doar evenimentele propriului tenant_id.

4. Cazuri de utilizare (use cases)

Fiecare UC: actor · precondiții · flux · postcondiții · reguli · ADR · stare.

UC-01 — Înregistrare eveniment (REST, sincron) ✅

Actor: sistem consumator. Precondiții: token audit:write valid; tenant_id din claim.
Flux: 1) trimite POST /api/v1/app/audit-events cu câmpurile universale + details. 2) GLog validează schema. 3) verifică tenant_id (claim == payload). 4) verifică Idempotency-Key. 5) calculează entry_hash. 6) persistă. 7) programează forward conform strategiei.
Postcondiții: eveniment persistat, sigilat (hash), răspuns 201 + Location + entry_hash.
Reguli: RB-validare, RB-tenant, RB-idempotență. ADR: [GLog-ADR-001], [GLog-ADR-005].

UC-02 — Înregistrare în lot (batch) 🟡

Actor: sistem consumator. Flux: POST …:batch cu max 500 evenimente; răspuns 202 + sumar {accepted, rejected[], idempotent_hits}. ADR: [GLog-ADR-005].

UC-03 — Ingest asincron AMQP ✅

Actor: sistem/broker. Flux: publică pe exchange audit.events; GLog consumă, sigilează, persistă; mesaj invalid → DLX (fără pierdere). ADR: [GLog-ADR-005].

UC-04 — Ingest streaming Kafka 🟡

Flux: GLog consumă din topic; commit offset după persistare. ADR: [GLog-ADR-005].

UC-05 — Publicare prin SDK (buffer + retry) 🟡

Flux: client.publish(event); SDK validează local, bufferează, expediază (mod AUTO: REST sincron / AMQP async); la indisponibilitate, persistă local până la confirmare. ADR: [GLog-ADR-008].

UC-10 — Listare și filtrare audit ✅

Actor: sistem/auditor (audit:read). Flux: GET …/audit-events?from&to&object_type&action_type&severity&idnp&q&page&size; răspuns paginat {items, page, size, total}, doar pentru tenant-ul propriu. ADR: [GLog-ADR-009].

UC-11 — Detaliu eveniment ✅

Flux: GET …/audit-events/{id} → evenimentul + details JSONB. ADR: [GLog-ADR-001].

UC-12 — Export audit 🟡

Flux: GET …/export?…&format=csv|xlsx → flux de date coerent cu filtrul.

UC-20 — Verificare integritate ✅

Actor: auditor/operator (audit:admin). Flux: GET …/admin/audit-events/integrity?tenant_id&from&to&object_type; GLog recalculează lanțul → {entriesChecked, chainBreaks[], lastVerifiedAt}. ADR: [GLog-ADR-002].

UC-30/31 — Gestiune nomenclatoare ✅

Actor: operator (audit:admin). Flux: CRUD pe audit_object_type și audit_action_type (cu strategy LOCAL/MLOG/ALL/NONE), per tenant, fără re-deploy. ADR: [GLog-ADR-006].

UC-32 — Gestiune politici de retenție 🟡

Flux: CRUD audit_retention_policy (retain_for_days, on_expiry); job nightly aplică politica. ADR: [GLog-ADR-007].

UC-33 — Acces cross-tenant (operator platformă) ✅

Flux: cu scope audit:admin:cross-tenant, citire/operații peste tenanți; orice acces e jurnalizat. Fără scope → 403. ADR: [GLog-ADR-003].

UC-40/42 — Forward și replay ✅ (MLog ⛔)

Flux: după persistare, conform strategy, GLog trimite la sinkuri (Webhook/SIEM/OpenSearch ✅; MLog JOSE/mTLS ⛔); eșec → outbox + retry; POST …/admin/audit-events/forward/replay reia. ADR: [GLog-ADR-006].

5. Sistemul ca acțiuni (comportamentul intern)

Ce face GLog cu fiecare eveniment, ca secvență de acțiuni:

#	Acțiune a sistemului	Descriere	ADR	Stare
A1	Autentifică	Validează JWT (scope + `aud=glog`) sau cert/mTLS	[GLog-ADR-004]	✅
A2	Validează schema	Câmpuri universale obligatorii prezente și corecte	[GLog-ADR-001]	✅
A3	Verifică tenantul	`tenant_id` din claim == din payload, altfel `403`	[GLog-ADR-003]	✅
A4	Deduplică	`Idempotency-Key` în fereastra de 24h	[GLog-ADR-005]	✅
A5	Sigilează	`entry_hash = SHA-256(prev_hash ‖ payload ‖ ts ‖ tenant_id)`, lanț per (tenant, object_type)	[GLog-ADR-002]	✅
A6	Persistă	Scrie în PostgreSQL (`details` JSONB), setează `received_at`, `ingestion_source`	[GLog-ADR-001]	✅
A7	Redirecționează	Conform `strategy`: scrie în outbox, dispatch async la sinkuri	[GLog-ADR-006]	✅ (MLog ⛔)
A8	Reține / expiră	Job programat aplică politica de retenție (DELETE/ARCHIVE)	[GLog-ADR-007]	🟡
A9	Verifică integritatea	La cerere, recalculează lanțul și raportează rupturile	[GLog-ADR-002]	✅
A10	Auto-jurnalizează	Acțiunile de administrare proprii sunt și ele audit	[GLog-ADR-001]	✅

6. Colectarea datelor (metode de ingest)

GLog acceptă același eveniment prin patru căi; alegerea ține de profilul sistemului consumator.

6.1 REST (sincron) ✅

POST /api/v1/app/audit-events — pentru volum mic/mediu și confirmare imediată.

{
  "tenant_id": "eintegritate",
  "event_timestamp": "2026-06-25T08:30:00Z",
  "object_type": "INSPECTOR",
  "action_type": "UPDATE_INSPECTOR",
  "object_affected": "12345",
  "severity": "INFO",
  "event_category": "BUSINESS",
  "idnp": "2002004012345",
  "user_details": "Ion Popescu",
  "ip_address": "10.1.2.3",
  "correlation_id": "req-abc-123",
  "view_link": "/inspectors/12345",
  "details": { "event": "EDIT_INSPECTOR", "component": "registry",
               "action": "UPDATE", "detail": { "before": {}, "after": {} } }
}

Antete: Authorization: Bearer <JWT>, Idempotency-Key, X-Correlation-Id, Accept-Language: ro|ru. Răspuns: 201 Created + Location: /api/v1/app/audit-events/{id} + corpul cu entry_hash.

6.2 REST batch 🟡

POST /api/v1/app/audit-events:batch — listă (max 500), răspuns 202 + sumar.

6.3 AMQP (RabbitMQ) ✅

Exchange audit.events (topic, durabil), routing tenant.{id}.{object_type}.{severity}, coadă audit.ingest + DLX audit.ingest.dlx. Mesaj = același JSON ca la REST. Pentru volum mare, non-blocant.

6.4 Kafka 🟡

Consumer pe topic configurat; commit offset după persistare.

6.5 SDK embedded 🟡

Esempla.Audit.Client (NuGet) și md.gov:audit-client (Nexus/Maven): buffer local + retry, mod AUTO (REST sincron pentru acțiuni user, AMQP pentru evenimente de sistem). SDK-ul nu duplică logica; doar formatează, validează local și expediază.

7. Partea API (suprafața de integrare)

Conform Standardului API GovStack: api/v{N} + zone, erori RFC 7807, endpoint-uri operaționale.

7.1 Endpoint-uri funcționale

Metodă	Cale	Zonă	Scope	Descriere	Stare
POST	`/api/v1/app/audit-events`	app	`audit:write`	ingest unitar	✅
POST	`/api/v1/app/audit-events:batch`	app	`audit:write`	ingest în lot	🟡
GET	`/api/v1/app/audit-events`	app	`audit:read`	listă paginată	✅
GET	`/api/v1/app/audit-events/{id}`	app	`audit:read`	detaliu	✅
GET	`/api/v1/app/audit-events/export`	app	`audit:read`	export CSV/XLSX	🟡
GET	`/api/v1/admin/audit-events/integrity`	admin	`audit:admin`	verificare lanț	✅
POST	`/api/v1/admin/audit-events/forward/replay`	admin	`audit:admin`	replay outbox	✅
CRUD	`/api/v1/admin/audit-object-types`	admin	`audit:admin`	nomenclatoare obiect	✅
CRUD	`/api/v1/admin/audit-action-types`	admin	`audit:admin`	nomenclatoare acțiune + strategy	✅
CRUD	`/api/v1/admin/audit-retention-policies`	admin	`audit:admin`	politici retenție	🟡

7.2 Endpoint-uri operaționale (publice) ✅

/health/live · /health/ready · /metrics (Prometheus) · /info · /api/v1/openapi.json (OpenAPI 3.1).

7.3 Autentificare

OAuth2 Resource Server (Keycloak), JWT aud=glog, scope-uri audit:*.
mTLS / certificat pentru integratori care cer auth pe bază de certificat (și forward MLog).
tenant_id derivat din claim; scriere cu tenant ≠ claim → 403. ADR: [GLog-ADR-004].

7.4 Convenții

Erori RFC 7807 (application/problem+json + correlationId).
Paginare ?page&size → plic {items, page, size, total}.
Idempotență Idempotency-Key; corelare X-Correlation-Id; i18n Accept-Language: ro|ru; date ISO 8601 UTC.
Contract OpenAPI 3.1 publicat (generare clienți) + AsyncAPI pentru AMQP/Kafka.

8. Afișarea și consumul datelor

Cum scot datele sistemele consumatoare/auditorii:

Metodă	Descriere	Mecanism	Stare
Listare/filtrare	după perioadă, tip obiect/acțiune, severitate, IDNP, text liber	`GET …/audit-events` paginat; căutare full-text trigram în Postgres	✅
Detaliu	un eveniment + payload `details`	`GET …/audit-events/{id}`	✅
Export	extras pentru raportare/arhivă	`…/export?format=csv	xlsx` (streaming)
Verificare integritate	dovadă tamper-evidence pe un interval	`…/admin/audit-events/integrity` → chain breaks	✅
Forward (push)	livrare automată către SIEM/OpenSearch/MLog	webhook / index / MLog	✅ (MLog ⛔)
Back-link în UI-ul apelantului	`view_link` readuce la obiectul vizat în sistemul-sursă	câmp `view_link` în eveniment	✅

Căutare: implicit Postgres trigram (fără dependență de Elasticsearch); OpenSearch opțional ca sink pentru căutare avansată. ADR: [GLog-ADR-009].

9. Partea de interfață utilizator (UI)

9.1 Principiu (v1 headless → admin portal)

GLog v1 este headless (doar API); UI-urile consumatoare folosesc API-ul. Un portal de administrare comun (Angular, conform GovStack Design System / UDS) se adaugă într-o fază ulterioară. Cerințele UI de mai jos sunt specificate acum ca echipa de dezvoltare să planifice, dar nu sunt livrate în v1. ADR: [GLog-ADR-010].

9.2 Ecrane ale portalului de administrare (planificate)

Ecran	Funcție	Rol	Stare
Event Browser	căutare/filtrare/detaliu/export evenimente	`audit:read`	🟡
Integrity Dashboard	rulează verificarea integrității, afișează rupturile de lanț	`audit:admin`	🟡
Nomenclatoare	gestiune object/action types (cu `strategy`)	`audit:admin`	🟡
Politici de retenție	configurare `retain_for_days` / `on_expiry` per tip obiect	`audit:admin`	🟡
Monitor forward / outbox	stare livrări, replay manual	`audit:admin`	🟡
Gestiune tenanți	tenanți, sinkuri active (operatori platformă)	`audit:admin:cross-tenant`	🟡

9.3 Cerințe transversale față de UI

ID	Cerință UI	Nivel	Stare
UI-01	Interfață în RO și RU; fără text hardcodat	MUST	🟡
UI-02	Conformitate WCAG 2.1 AA pe fluxurile principale	SHOULD	🟡
UI-03	Vizibilitatea acțiunilor/datelor controlată de RBAC (scope-uri)	MUST	🟡
UI-04	Aliniere la GovStack Design System (UDS) — componente comune	SHOULD	🟡
UI-05	Filtre persistente + paginare + sortare în Event Browser	MUST	🟡
UI-06	Indicarea vizuală a rupturilor de integritate (roșu)	MUST	🟡

10. Modelul de date

10.1 Eveniment de audit — câmpuri universale

Câmp	Tip	Oblig.	Rol
`id`	UUID v7	da	cheie, sortare naturală
`tenant_id`	varchar(64)	da	ce sistem
`event_timestamp` / `received_at`	timestamptz	da	când s-a produs / când a fost recepționat
`ingestion_source`	enum(REST,AMQP,KAFKA,EMBEDDED)	da	calea de intrare
`object_type` / `action_type`	varchar(64)	da	ce
`object_affected`	varchar(255)	nu	obiectul vizat
`event_category` / `severity`	enum	nu	clasificare
`idnp` / `user_details` / `ip_address`	varchar	cond.	cine / de unde
`correlation_id` / `view_link`	varchar	nu	corelare / back-link
`details`	JSONB	nu	payload abstract specific aplicației
`prev_hash` / `entry_hash`	char(64)	da	lanț de integritate (`prev_hash` genesis la primul element)

10.2 Nomenclatoare & configurare

audit_object_type (code, tenant_id) — tipuri de obiect per tenant.
audit_action_type (code, tenant_id, strategy ∈ {LOCAL,MLOG,ALL,NONE}) — tipuri de acțiune + strategie forward.
audit_retention_policy (tenant_id, object_type, retain_for_days, on_expiry, archive_target).
audit_forward_outbox (audit_event_id, sink, status ∈ {PENDING,SENT,ERROR}, attempts, next_attempt_at).

ADR: [GLog-ADR-001] (model), [GLog-ADR-006] (strategy), [GLog-ADR-007] (retenție).

11. Cerințe funcționale (tabelar, trasabile la ADR)

ID	Cerință	Nivel	UC	ADR	Stare
FR-001	Ingest REST unitar (201 + entry_hash)	MUST	UC-01	ADR-001/005	✅
FR-002	Ingest REST batch (max 500, 202 + sumar)	MUST	UC-02	ADR-005	🟡
FR-003	Ingest AMQP (RabbitMQ) + DLX	MUST	UC-03	ADR-005	✅
FR-004	Ingest Kafka (consumer)	SHOULD	UC-04	ADR-005	🟡
FR-005	SDK NuGet/.NET + Nexus/Java (buffer + retry, AUTO)	MUST	UC-05	ADR-008	🟡
FR-006	Model eveniment: universal + payload JSONB	MUST	UC-01/11	ADR-001	✅
FR-007	Idempotență (Idempotency-Key, 24h)	MUST	UC-01	ADR-005	✅
FR-008	Multi-tenancy (claim JWT; izolare scriere+citire)	MUST	UC-33	ADR-003	✅
FR-009	Integritate hash chain per (tenant, object_type)	MUST	UC-20	ADR-002	✅
FR-010	Endpoint verificare integritate	MUST	UC-20	ADR-002	✅
FR-011	Listare/filtrare paginată	MUST	UC-10	ADR-009	✅
FR-012	Detaliu eveniment	MUST	UC-11	ADR-001	✅
FR-013	Export CSV/XLSX	MUST	UC-12	ADR-009	🟡
FR-014	Forward Webhook (SIEM/OpenSearch) + outbox + replay	MUST	UC-40/42	ADR-006	✅
FR-015	Forward MLog (JOSE + mTLS)	MUST	UC-40	ADR-006	⛔
FR-016	Retenție configurabilă + job	MUST	UC-32	ADR-007	🟡
FR-017	Nomenclatoare (object/action types + strategy)	MUST	UC-30/31	ADR-006	✅
FR-018	Acces cross-tenant (operatori platformă)	MUST	UC-33	ADR-003	✅
FR-019	Auth token + Keycloak + cert/mTLS	MUST	toate	ADR-004	✅
FR-020	Conformitate Standard API (zone, RFC7807, operațional)	MUST	§7	ADR-004	✅
FR-021	Portal de administrare (ecrane §9.2)	SHOULD	§9	ADR-010	🟡

12. Cerințe non-funcționale (tabelar, trasabile la ADR / CU)

ID	Cerință	Țintă / parametru	CU / ADR	Stare
NFR-01	Latență ingest REST (p95)	< 100 ms	CU-PERF-001	✅
NFR-02	Latență procesare AMQP (p95)	< 500 ms	CU-PERF-001	✅
NFR-03	Debit	≥ 5.000 ev/s/instanță	CU-PERF-001	🟡
NFR-04	Disponibilitate ingest	99,9% / lună; ≥ 3 replici	CU-AVAIL-001	🟡
NFR-05	Securitate transport	TLS ≥ 1.2; secrete în Vault	CU-SEC-001/002	✅
NFR-06	Date personale (IDNP)	minimizare; cifrare la repaus; acces auditat	CU-PD-001/003	🟡
NFR-07	Observabilitate	loguri JSON + correlation-id; /metrics; tracing	CU-OBS-001/002/003	✅
NFR-08	Persistență	Postgres per-serviciu; migrări expand/contract	CU-DATA-001	✅
NFR-09	Deploy	GitLab CI/CD; rolling/blue-green + rollback; K8s	CU-DEPLOY/K8S	🟡
NFR-10	i18n nomenclatoare	RO/RU/EN	CU-I18N-001	✅

13. Trasabilitate (cerință → ADR → criteriu → test → stare dezvoltare)

Cerință	ADR	Criteriu de acceptanță (rezumat)	Caz de test	Stare
FR-001	ADR-001/005	POST valid → 201 + entry_hash, p95 < 100 ms	TC-GLOG-01	✅
FR-003	ADR-005	mesaj invalid AMQP → DLX, fără pierdere	TC-GLOG-03	✅
FR-008	ADR-003	2 tenanți → niciun query nu vede celălalt tenant	TC-GLOG-MT	✅
FR-009/010	ADR-002	UPDATE direct în DB → chain_breaks ≥ 1 în < 1 s	TC-GLOG-20	✅
FR-014	ADR-006	sink down → outbox; replay → SENT	TC-GLOG-40	✅
FR-015	ADR-006	export către MLog compatibil (zero-diff)	TC-GLOG-MIG	⛔
FR-016	ADR-007	retenție aplicată; integritate păstrată după purge	TC-GLOG-32	🟡
FR-019	ADR-004	fără scope → 401/403; cu scope → ok	TC-GLOG-AUTH	✅
FR-020	ADR-004	endpoint-uri operaționale + RFC7807	TC-COM-API-04/05	✅

14. Stare de implementare (pentru urmărirea dezvoltării)

Fază	Conținut	Stare
P1	Schelet + model + integritate	✅
P2	Ingest REST, tenant guard, OAuth2, RFC7807, OpenAPI, operațional	✅
P3	JPA/Postgres, integrity endpoint, paginare, AMQP+DLX, forward+outbox+replay	✅
P3b	MLog real (JOSE/mTLS ⛔), Kafka, retenție, SDK-uri, export, batch	🟡
P4	Conformance kit GovStack	🟡
P5	Cutover pilot (export verificat, zero-diff)	🟡

Stare cod: 46 teste verzi (unit + integrare Testcontainers Postgres + RabbitMQ); mvn clean test → BUILD SUCCESS. Repo: govtech/gstack/glog.

15. Dependențe pentru sistemele integratoare (planificare)

Ce trebuie să pregătească un sistem consumator pentru a integra GLog:

Identitate: client Keycloak cu scope-urile audit:* necesare; (opțional) certificat pentru mTLS.
Decizie de transport: REST (simplu) vs. AMQP/Kafka (volum) vs. SDK (buffer local).
Maparea evenimentelor: definirea object_type / action_type proprii + structura details.
Back-link: convenția view_link către obiectul din sistemul-sursă.
Retenție: stabilirea politicii per tip obiect (cu beneficiarul).

Aceste capacități sunt disponibile în mediile de test pe măsură ce fazele devin ✅. Un sistem consumator poate începe integrarea pe căile ✅ fără a aștepta lansarea în producție; căile 🟡/⛔ se anunță pe portal la trecerea în ✅.

Anexă — Referințe

Caiet de sarcini (business + tehnic): glog-audit-logging.md
ADR-uri: glog/adrs/GLog-ADR-001 … 010
Plan de testare: test-plans/glog-audit-logging.md
RFB (document de licitație): GLog-RFB-Document-Licitatie.docx
Cod & wiki: GitLab govtech/gstack/glog

Esempla Systems · GovStack · GLog — Specificație Tehnică Completă · v0.1 · 2026-06-25