Template SPEC — aplicație internă

Template standard pentru un spec document al unei aplicații interne. Completează fiecare secțiune; șterge-le pe cele care nu se aplică, dar nu sări peste deciziile pe care le forțează. Scopul unui spec bun nu e documentația — e să forțeze deciziile ambigue la suprafață înainte să scrii cod.

1. Titlu și scop

• Nume aplicație, o singură frază despre ce face și pentru cine.
• Problema concretă pe care o rezolvă (nu „digitalizare", ci „reduce timpul de procesare a avizelor de la 15 min la 30s").

2. Context de business

• De ce acum, de ce nu o soluție existentă.
• Costul problemei dacă NU se construiește (bani/timp/risc).

3. Utilizatori și personas

• Cine folosește, ce nivel tehnic, câți sunt.
• Ce sistem/autorizații are fiecare astăzi.

4. Cerințe funcționale

• Listă de user stories sau cerințe numerotate, cu prioritate (P0/P1/P2).
• Fiecare cerință: „ca [rol], vreau [acțiune], ca să [scop]".

5. Cerințe non-funcționale

• Performanță (latență, throughput, volum de date).
• Disponibilitate (uptime, RPO/RTO dacă e critic).
• Scalabilitate (câți utilizatori concurenți).

6. Fluxuri principale + edge cases

• Happy path pas cu pas.
• Edge cases explicite: input gol, date ilegibile, timeout, duplicate, conflict de scriere.

7. Model de date

• Entități, relații, câmpuri cheie.
• Ce e persistent vs derivat; ce poate fi șters/anonymizat.

8. Integrări

• API-uri externe (cine, ce endpoint, ce contract).
• Autentificare la fiecare integrare.
• Ce se întâmplă când integrarea pică (fallback, retry, circuit breaker).

9. Autentificare și autorizare

• Cine se loghează, cum (SSO, local, MFA).
• Roluri și permisiuni (matrice rol × acțiune).

10. UI/UX

• Ecrane principale, wireframes sau descriere text.
• Stil vizual, component library, responsive.

11. Securitate și conformitate

• Date sensibile, criptare în repaus/în tranzit.
• Cerințe de conformitate (GDPR, intern, ISO) și audit.
• Politica de păstrare a datelor.

12. Observabilitate

• Logging (ce se loghează, format, retenție).
• Metrici cheie și praguri de alertă.
• Trace-uri pentru fluxuri multi-serviciu.

13. Limitări și non-goals

• Ce NU face aplicația (explicit, ca să nu se extindă scope-ul).
• Constrângeri cunoscute (ex: fără GPU, single-writer DB).

14. Plan de rollout / migrare

• Faze de lansare, migrare date existente.
• Rollback plan, pilot group, cutover.

15. Criterii de acceptare (DoD)

• Liste concrete, verificabile: „avizul X e procesat în <60s cu acuratețe >95%".
• Cine semnează că e gata de producție.

Legături: the-architect-app-prompt · cfohub-analyst-agent-mvp · Skill vs Wiki — principiu de design agent