BELETAGE CATUC

Pentru programe

Contractul de date

Aceleași date pe care le arată situl, în fișiere JSON statice, cu versiune și cu sha256 calculat pe octeții publicați. Se consumă la build, nu la cerere: fără capăt viu, fără cheie, fără dependință la rulare. Forma e cea cerută de primii consumatori, ArchiTools și PlanHub (06.09.2026).

Fișierele

fișierce conținerânduriversiuneoctețisha256
termene.jsontoate ceasurile extrase din Cod: un număr urmat de o unitate de timp, cu felul zilelor, fraza verbatim, articolul și diviziunea lui 4632026-09-134381708235ccfc7cd7…
sarbatori.jsonregula de numărare, verbatim (art. 580 din Cod, art. 599 din Codul administrativ, art. 139 din Codul muncii), convențiile noastre și sărbătorile legale pe trei ani 32026-09-0410523dc113738dbd8…
cazuri-calcul-termen.jsonfixture-ul calculatorului: intrări și rezultatele motorului nostru, inclusiv zilele sărite; o reimplementare care le reproduce numără la fel ca noi 132026-09-043846002ae5b5aa22…
definitii.jsoncele 160 de definiții ale anexei nr. 1, cu termenul, definiția verbatim, slugul și pagina 1602026-09-05977870adb2e5aca8f…
index.jsonmanifestul: pentru fiecare fișier, sha256, octeți, rânduri, versiune 42026-09-13

Cum se pinuiește

Descarcă fișierul, calculează hash-ul pe octeții lui și compară-l cu cel din manifest. Ține copia și hash-ul în repoul tău; la build descarcă din nou și compară.

curl -sO https://catuc.beletage.ro/contract/termene.json
sha256sum termene.json
curl -s https://catuc.beletage.ro/contract/index.json | python3 -c 'import json,sys; print(json.load(sys.stdin)["fisiere"]["termene.json"]["sha256"])'

Hash-ul e pe octeții fișierului, nu pe o regulă de serializare: nu trebuie să știi cum serializăm ca să-l verifici. Un hash diferit înseamnă că s-au schimbat octeții publicați, nu buildul: generat_la e data tragerii din sursă, nu ora buildului, deci două builduri pe aceleași date și același cod dau aceiași octeți. Când sursa e aceeași și se schimbă felul în care o compunem, schimbarea e scrisă în manifest (schimbari) și mai jos, la istoric.

Câmpurile

termene.json
schema, versiune, verificat_la, generat_la, sursa, nota[], cate, termene[]; un termen: unit_id, articol, eticheta, numar, unitate (zile / luni / ani), fel (lucratoare / calendaristice / nu_spune), fraza (verbatim), cale, url, procedura ({ slug, denumire, url }, sau null la ceasurile din anexe). Rândurile nu sunt deduplicate: același ceas citit din alineat și din litera lui apare de două ori.
sarbatori.json
regula (cod, calcul, sarbatori: unit_id și text verbatim), conventii[] (ale noastre, spuse ca atare), an_de_baza, ani (an → listă de { data, eticheta, fraza, sursa }).
cazuri-calcul-termen.json
cazuri[]: start, numar, masura, fel ca intrare; sfarsit, regula, ziua_saptamanii, sarite[] ca rezultat al motorului nostru. Azi 13 cazuri.
definitii.json
definitii[]: termen, slug, abreviere, definitie[] (paragrafe verbatim), url.

Istoric

Schimbările care au mișcat octeții fără o tragere nouă din sursă. Când hash-ul pinuit nu se mai potrivește și versiunea e aceeași, aici scrie de ce.

Ce înseamnă o versiune nouă

termene.json și manifestul poartă versiunea artefactului de corpus (2026-09-13); definitii.json pe a artefactului de portal; sarbatori.json și cazurile pe a regulilor trase din corpus. Când o versiune se mișcă, diferența e numărată pe /timp/. unit_id e identificatorul corpusului și rămâne stabil cât timp corpusul îl păstrează; nu promitem noi în locul lui.

Regula casei se aplică și aici: nimic din fișiere nu e interpretare. Ceasurile sunt extragerea din text, regula e verbatim, sărbătorile sunt tabela noastră declarată, iar cazurile sunt ce numără motorul nostru pe acea regulă. Dacă numeri altfel (de pildă fără ziua de început ca ziua 1), fixture-ul îți arată exact unde diferi; ce regulă aplici rămâne decizia ta.