Livrabile

Proiect: $ARGUMENTS (fără argument: toate proiectele active)

Rulează verificarea de completitudine conform 20-proces/26-livrabile-standard.md.

Pași

1. Determină clasa (T sau I) și faza curentă (eticheta state:: din GitLab).
2. Filtrează baza standard — cele 34 de livrabile — la ce e datorat până la faza curentă, inclusiv.
3. Caută ce există: docs/ din repo, wiki-ul proiectului, issue-urile cu type::docs.
4. Verifică fiecare livrabil găsit față de verificatorul lui de conținut (25-practici-inginerie.md §2.3). Un fișier gol nu e un livrabil.
5. Raportează în patru categorii.

Formatul raportului

PROIECT: <slug> · clasa <T|I> · faza: state::<x>

  ✓ prezente (N)          — trec și verificatorul de conținut
  ✗ LIPSĂ, datorate (N)   — cu faza la care ar fi trebuit să apară
  ⚠ N/A fără motiv (N)    — eroare de completitudine, la fel de gravă ca lipsa
  ○ nu încă datorate (N)

Reguli

• N/A fără motiv scris = eroare. Un livrabil se taie cu justificare, nu tăcut.
• Întârzierea față de fază se semnalează. Dacă proiectul e în state::build dar strategia de testare (Faza 3) lipsește, e semnal roșu — nu „va veni ea”.
• Nu blochezi. Raportezi. Blocarea se face la porțile de fază, unde Definition of Done cere livrabilele fazei.
• Un livrabil prezent dar care pică verificatorul de conținut se raportează la ✗, nu la ✓, cu motivul (ex. „SDD: 4 afirmații arhitecturale fără tabel/diagramă/exemplu”).

Dacă lipsește ceva din bază

Baza nu e completă prin definiție — se completează pe parcurs. Dacă observi un livrabil pe care proiectul îl are dar baza nu-l prevede, propune-l ca adăugire în 26-livrabile-standard.md, nu-l ignora.