# Database Development Log

Decizii despre SQLite, schema runtime, migrare, seed, backup/restore si sursele de adevar pentru date operationale.

## 2026-06-09 - SQLite Runtime Source of Truth

Observatie: editarile de hosts facute in aplicatia live puteau ramane in working tree-ul de pe jumper sau puteau fi suprascrise/confuzionate la push-ul de cod. Modelul vechi descria simultan `config/hosts.yaml` ca registry editabil in git si ca data operationala runtime, ceea ce nu era o sursa de adevar clara.

Decizie:

- `var/host-manager.sqlite` devine sursa de adevar runtime pentru registry si Work Orders

- `config/hosts.yaml` si `config/work-orders.yaml` raman seed/snapshot/export compatibility files

- la prima pornire, aplicatia seed-uieste documentele lipsa din YAML in SQLite

- la acel moment exista un manifest TSV explicit pentru sync-ul DNS local; acesta a fost retras prin contractul din 2026-06-11

Scop:

- editarile facute in UI sa nu se piarda la deploy/push de cod

- sa existe o singura autoritate runtime

## 2026-06-09 - Relational Runtime Schema

Observatie: primul pas SQLite mutase sursa de adevar din git in baza de date, dar o pastra ca document YAML intr-o tabela generica. Asta rezolva pierderea editarilor la push, dar nu oferea o baza de date operationala reala.

Decizie:

- `hosts.fqdn` devine cheia reala pentru hosturi, ca numele complete sa evite coliziuni intre domenii

- `legacy_id` ramane doar compatibilitate pentru UI/API-ul curent

- aliasurile sunt pastrate in `host_aliases`, inclusiv dupa retragere

- vhosturile sunt in `vhosts` si pot fi mutate prin schimbarea `host_fqdn`

- rolurile, sursele, flagurile si SSH sunt in tabele separate, nu coloane adaugate continuu in `hosts`

- workerii de date au `data_workers`, `dhcp_leases` si `mdns_observations`

- certificatele emise au `certificates` si `certificate_dns_names`

- `documents` ramane doar tabel legacy pentru migrare din modelul vechi document-store

Scop:

- schema sa poata sustine inventar, DNS, vhosturi, observatii externe si certificate fara sa piarda istoric operational

- aliasurile/vhosturile retrase sa ramana audibile in baza de date

- structura sa fie extensibila fara sa supraincarce tabelul `hosts`

## 2026-06-10 - DHCP Lease Push Collector

Observatie: DHCP-ul de pe `192.168.2.1` este autoritatea pentru alocarea IP-urilor LAN, dar baza runtime avea doar tabela `dhcp_leases`, fara un colector operational.

Decizie:

- MikroTik impinge evenimentele de lease prin `lease-script` catre `POST /api/collect/dhcp-leases`

- endpoint-ul este protejat cu `HOST_MANAGER_DHCP_PUSH_TOKEN`, separat de sesiunea OTP pentru UI

- ingest-ul scrie doar in `dhcp_leases` si actualizeaza workerul `dhcp-router`

- observatiile DHCP raman material de audit/propunere si nu modifica automat host registry-ul sau manifestul DNS

Scop:

- sa colectam lease-uri fara credential SSH pentru router in aplicatie

- sa pastram DHCP ca sursa observata cu prioritate mare, dar fara side effect automat asupra DNS-ului local

## 2026-06-11 - Registry Maturity Contract

Observatie: modelul vechi pastra mai multe artefacte care puteau fi confundate cu surse de adevar: `local-hosts.tsv`, campuri legacy din export si surse istorice pe host.

Decizie:

- SQLite ramane singura sursa de adevar runtime

- `hosts.yaml` devine produsul finit descarcabil si vizibil raw in UI

- `local-hosts.tsv` nu mai este fisier versionat sau download; resolver sync genereaza recorduri efemere din SQLite

- schema urca la versiunea 3 cu `tags` si `host_tags`

- `dhcp_leases` si `mdns_observations` sunt inputuri observate pentru hinturi/autocomplete, nu muta automat registry-ul

Motiv:

- sa evitam drift intre DB, exporturi si configurarea resolverelor

- sa facem tagurile o functie administrabila, nu text liber fara catalog

- sa pastram observatiile externe utile fara sa le promovam automat in DNS