Session Intake — `vault/0-inbox/` ca punct de intrare

Regula este normativă (vezi CLAUDE.md §0 pasul 5 și §5d). Acest document descrie procedura completă și diagrama celor două track-uri.

Principiu

Orice intenție de lucru intră întâi ca subdosar în vault/0-inbox/. Nu există „muncă fără intrare”. La începutul fiecărei sesiuni, Orchestratorul (ATLAS) scanează 0-inbox/, clasifică fiecare subdosar și îl rulează pe track-ul potrivit. Așa nu reîncepem munca, nu pierdem materiale și fiecare livrabil are o sursă trasabilă.

0-inbox/ rămâne „gunoiul” (captură brută, nefiltrată) — vezi 0-inbox/README.md. Nimic din 0-inbox/ nu intră în export-ul RAG; doar 1-procesat/ și 2-structurat/.

Clasificare (ce track?)

Semnal în subdosar	Track	Destinație finală
Standarde, principii globale, stack, arhitectură, procese, ADR-uri de platformă, research transversal	Principii (Bloc A)	01-govstack-foundation/ + docs/ (după aprobare)
Concept de aplicație/modul, exemplu de caiet, procese de business, payloaduri, deck de produs	Specificație (Bloc B→C)	02-specifications/caiete-de-sarcini/ → testare → dezvoltare
Material brut de cunoaștere (articole, PDF/docx răzlețe) fără intenție clară de livrabil	Cunoaștere (/ingest)	1-procesat/ + 2-structurat/

Dacă un subdosar e ambiguu sau amestecat, pune o întrebare în BATCH (questions/inbox.md) și mergi mai departe cu un ASSUMPTION: rezonabil.

Diagrama celor două track-uri

                         vault/0-inbox/<subdosar>
                                   │
                 ┌─────────────────┴──────────────────┐
                 ▼                                     ▼
        TRACK PRINCIPII (Bloc A)            TRACK SPECIFICAȚIE (Bloc B→C)
        ex: 0-inbox/Framework/              ex: 0-inbox/GLog/
                 │                                     │
   distilare ce e important &           caiet de sarcini (template potrivit)
   scalabil la framework                + ADR-uri per modul, moștenind _comune/
                 │                                     │
   candidați CU-* / ADR                 02-specifications/caiete-de-sarcini/
                 │                                     │
        ┌── POARTĂ aprobare ──┐                 POARTĂ review (reviewer)
        ▼ (teamlead)                                   │
   01-govstack-foundation/              ┌──────────────┼───────────────┐
   + docs/ (varianta finală)            ▼              ▼               ▼
                 │                  test-plan      curs Moodle     proceduri
            export vault/RAG                            │
                                                03-development/ (Bloc C)
                                                        │
                                                  cod + teste + MR GitLab

Track Principii — pași

1. Citește materialul; identifică ce e principiu reutilizabil vs. ce e specific unui proiect.
2. Formulează candidați: cerințe universale (CU-* prin skill govstack-requirements) și/sau ADR-uri (vault/templates/adr.md).
3. Acumulează deciziile cu impact pentru poarta de aprobare (teamlead) — în BATCH.
4. După aprobare: promovează varianta finală în 01-govstack-foundation/ și documentează în docs/.
5. Publică în vault + export RAG (obsidian-rag-export). Arhivează sursa brută în 0-inbox/.

Track Specificație — pași

1. Clasifică tipul aplicației: business app → template.md; PaaS building block → template-paas-bb.md (skill caiet-de-sarcini).
2. Scrie caietul moștenind partea transversală din 02-specifications/_comune/ (anexa-tehnica-comuna.md, standard-api.md, cerinte-universale.md).
3. ADR-uri per modul lângă caiet.
4. Poartă reviewer (conformitate + calitate); CRITICAL blochează.
5. Notă vault + issue GitLab (type:spec, block:B).
6. Downstream (sesiuni viitoare): plan de testare (test-plan), curs Moodle (moodle-course), proceduri (enablement-author), apoi dezvoltarea în 03-development/.

Porți de aprobare (decizii ireversibile / costisitoare — vezi §1)

• Promovarea în 01-govstack-foundation/ (devine normă de framework).
• Marcarea unui caiet „done” (intră în licitație / dezvoltare).
• Schimbări de arhitectură care modifică cerinte-universale.md sau standard-api.md.

Convenție de denumire subdosar

• Principii: nume tematic, ex. Framework/, Securitate/, Observabilitate/.
• Specificație: numele aplicației/BB, ex. GLog/, MPower/, Interdictii/.