Caiet de Sarcini (focus business, tehnicul moștenit)

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

Principiul de eficiență: cerințele tehnice și transversale (securitate, logare, roluri, cache, integrări, storage documente, deployment, Kubernetes, audit, search, NFR) NU se rescriu în fiecare caiet — sunt comune și moștenite din anexa tehnică comună (skill parti-comune), bazată pe catalogul CU-* (skill cerinte-universale). Caietul descrie doar businessul + un mic tabel de conformitate.

Alege template-ul potrivit (PRIMUL pas)

Aplicație de business (procese, roluri, useri, forme — ex. portal cetățean, SIMSM) → references/template.md (focus business, ~80% tehnic moștenit).
Building Block PaaS (componentă de infrastructură reutilizabilă — ex. GLog/audit, notify, signing, storage) → references/template-paas-bb.md (tender-grade; produsul este tehnic, deci secțiunile tehnice se scriu, dar transversalul-standard tot se moștenește/parametrizează).
Dacă e ambiguu: dacă „actorii” sunt în mare parte alte sisteme și SDK-uri (nu utilizatori umani cu forme), e un PaaS BB.

Pași

Brainstorm scurt (batch): scop, utilizatori/sisteme consumatoare, procese, integrările GovStack folosite. Necunoscute → inbox.md, continui cu ASSUMPTION:.
Pornește din template-ul ales (vezi mai sus). Completează:
- Business: Procese (PB-), Roluri (R-), Acțiuni/UC (UC-), Forme (F-), Reguli (RB-*), Date, Integrări specifice.
- PaaS BB: Context/motivație, actori-sistem, flux principal, modelul obiectului (câmpuri universale + payload abstract), componente, moduri de livrare (REST/AMQP/SDK/sidecar), cerințe tehnice parametrizate, integritate, implementare, mentenanță/SLA.
Moștenirea tehnicului: NU rescrie securitate/cache/audit/etc. Completează §13 Tabel de conformitate marcând per domeniu: Aplicabil (default) / Parametrizat (cu valori) / N/A (cu motiv) / Abatere (cu justificare + aprobare arhitect).
Criterii de acceptanță business (§11): Given/When/Then testabile, per UC/proces.
Verifică: fiecare UC are criteriu testabil; rolurile mapate la RBAC; integrările specifice nu redescriu mecanismul comun; parametrii (p95, retenții, TTL) completați în §13.
Output dublu: 02-specifications/caiete-de-sarcini/<slug>.md + notă vault/ (skill obsidian-rag-export).
Review gate (reviewer) → la APPROVE, gitlab-sync creează issue type:spec + block:B.

De ce reduce timpul

Partea tehnică (≈80%) e scrisă o singură dată, în anexa comună; aici doar o referențiezi/parametrizezi.
Planul de testare reutilizează biblioteca TC-COM-* (skill parti-comune), legată de CU-*, deci și testarea transversală e gata.
Reducerea dezvoltării: echipa de cod știe că NFR/securitatea/deploy-ul sunt standard pe toate aplicațiile (vezi Bloc A), nu se reinventează per proiect.

Reguli

Limba: română (RU la cerere). Identificatori tehnici în engleză.
Dacă un domeniu comun NU se aplică (ex. fără căutare) → marchează N/A cu motiv, nu-l ignora tăcut.
Abaterile de la anexa comună necesită aprobarea govstack-architect (batch).

Citește references/template.md și invocă skill-ul parti-comune (anexa tehnică) ÎNAINTE de a scrie.