Părțile comune — ce moștenește un proiect fără să ceară

Trei fișiere care există ca nimeni să nu le rescrie. Un caiet care repetă anexa tehnică nu e mai complet — e mai lung, și divergent de restul companiei la prima modificare.

Fișier	Ce conține	Cine îl moștenește
`reference/anexa-tehnica-comuna.md`	NFR, securitate, logare, roluri, cache, integrări, storage, deployment, Kubernetes, audit, search	toate caietele de sarcini
`reference/biblioteca-cazuri-test-comune.md`	cazurile `TC-COM-`, legate 1:1 de `CU-`	toate planurile de testare
`reference/strategie-testare-comuna.md`	nivelurile de testare: unit, integrare, contract, E2E, non-funcțional, smoke, UAT	toate planurile de testare

Modelul de moștenire — regula de aur

Caietul specific NU rescrie partea tehnică. Completează un tabel de conformitate (§13 din template-ul de business) care marchează, per domeniu: Aplicabil · Parțial · N/A.

N/A fără motiv scris e eroare, nu alegere. Asta e singura verificare care împiedică tabelul să devină o coloană de bifat. Un domeniu tăiat cu justificare e o decizie de arhitectură; unul tăiat în tăcere e o cerință pierdută care reapare la recepție.

Planurile de testare

Planul specific moștenește strategia comună și include cazurile TC-COM-* aplicabile — implicit, toate cele ale domeniilor marcate „Aplicabil” în tabelul de conformitate. Apoi adaugă doar cazurile de business proprii, cu ID-uri TC-<APP>-NN.

Astfel acoperirea transversală e gata-făcută: nu se testează de la zero securitatea, autentificarea sau semnătura la fiecare proiect — se testează businessul.

Ordinea corectă

tabelul de conformitate în caiet → decide ce domenii sunt aplicabile
domeniile aplicabile → decid ce TC-COM-* intră în planul de testare
businessul din caiet → decide ce TC-<APP>-* se adaugă

Dacă faci planul de testare înainte de tabelul de conformitate, alegi cazurile pe intuiție. Se vede.