# Development Log

Acest fișier păstrează deciziile care schimbă scopul aplicației, regulile de operare sau modelul de deployment. Nu înlocuiește git history; explică de ce au apărut schimbările mari.

## 2026-06-06 - Repository and Deployment Split

Decizie: codul aplicației se dezvoltă local și se publică în GitPrep. Jumper rămâne runtime/deploy target.

Locații:

- checkout local: `/Users/bogdan/Documents/Workspaces/Xdev/Madagascar/LocalAuthority`
- GitPrep canonical remote: `git@192.168.2.102:repositories/bogdan/LocalAuthority.git`
- GitPrep web: `http://192.168.2.102:3000/bogdan/LocalAuthority`
- runtime jumper: `/usr/local/xdev-host-manager`

Motiv:

- editarea directă pe jumper amesteca dezvoltarea cu runtime-ul
- aplicația are acum scope mai mare și va continua să evolueze
- avem nevoie de istoric, review și deploy controlat

Regulă:

- `scripts/deploy_to_jumper.sh` publică aplicația pe jumper
- `config/` nu se copiază implicit
- `config/` se copiază doar cu `--include-config`, la cerere explicită

## 2026-06-06 - Scope Expanded Beyond Host Registry

Aplicația a pornit ca manager pentru registrul de hosturi, dar scope-ul curent include:

- registry de hosturi Madagascar
- manifest DNS local pentru jumper și as01
- Work Orders pentru schimbări operaționale confirmabile
- autoritate locală de certificate pentru hosturi
- exporturi pentru servicii consumatoare, preferabil prin git

Numele de produs a devenit `Madagascar Local Authority`.

Numele tehnice rămân stabile pentru compatibilitate:

- service systemd: `host-manager`
- user Unix: `host-manager`
- runtime path: `/usr/local/xdev-host-manager`
- environment file: `/etc/xdev/host-manager.env`

## 2026-06-06 - Work Orders Before Destructive Registry Changes

Decizie: numele cu impact operațional nu se șterg direct din UI.

Exemplu inițial:

- `pmx.*.madagascar.xdev.ro`
- `pbs.*.madagascar.xdev.ro`

Aceste nume au fost create pentru vhosturi nginx cu certificate Let's Encrypt. Odată cu CA-ul local, intenția este retragerea lor, dar eliminarea din registry se face doar după:

- inventarierea vhosturilor
- crearea și instalarea certificatelor locale
- eliminarea configurațiilor legacy
- testarea accesului prin numele canonice
- verificarea că numele nu mai sunt folosite
- aprobarea finală a operatorului

Confirmarea unui WO este blocată dacă checklist-ul nu este complet.

## 2026-06-06 - Local DNS Resolution Rules

Regulă: local nu se folosește wildcard pentru `*.madagascar.xdev.ro`.

Doar numele cunoscute din manifestul local trebuie să se rezolve intern. Numele necunoscute trebuie să întoarcă `NXDOMAIN`, chiar dacă DNS public poate avea wildcard către IP-ul public.

Resolverele interne sunt:

- jumper: `192.168.2.100`
- as01: `192.168.2.2`

Sync-ul rămâne explicit:

```bash
./scripts/sync_local_hosts.sh --apply --verify
```

## 2026-06-06 - Dependency Policy

Regulă: nu se instalează npm, pip sau CPAN direct pe hosturi.

Acceptat:

- pachete din distribuție, când sunt necesare
- Perl din distribuție
- module Perl core/distribution

CPAN se folosește doar dacă pachetul ajunge prin repo-ul local auditat.

Pachete de sistem instalate în timpul evoluției:

- `ripgrep` pe jumper
- `rsync` pe jumper
- `sqlite` pe jumper
- `perl-DBD-SQLite` pe jumper
- `sqlite3` pe mazeri/GitPrep

## 2026-06-06 - OTP Login Keeps a Password-Manager-Friendly Form Shape

Observație: unele password managere și autofill-uri mobile nu inițiau corect pe login-ul Madagascar Local Authority, deși completarea mergea pe o pagină similară din PBX management.

Diferențe relevante observate pe pagina care funcționa:

- formular clasic `method="post"`
- câmp de cont cu `autocomplete="username"`
- câmp unic pentru codul OTP, separat de cele 6 căsuțe vizuale

Decizie:

- UI-ul rămâne cu 6 căsuțe OTP
- formularul include și câmpuri ajutătoare off-screen pentru `username` și OTP agregat
- JS sincronizează codul complet între câmpul agregat și cele 6 căsuțe
- formularul păstrează `autocomplete="on"` la nivel de form, ca hint-urile specifice de pe câmpuri să nu fie neutralizate

Scop:

- compatibilitate mai bună cu password managere și autofill mobil
- fără a complica interfața vizibilă

## 2026-06-08 - Commit and Push Is the Development Contract

Observație: schimbările lăsate mult timp ca dirty working tree se pierd ușor în timpul deploy-urilor, reseturilor și schimbărilor de context. Pentru development, unitatea de lucru trebuie să fie commit-ul local, nu un set de fișiere uitate în stare necomisă.

Decizie:

- se lucrează cu commit-uri locale mici și coerente
- pentru test live, commit-ul se împinge în checkout-ul runtime de pe jumper cu `git push jumper-runtime HEAD:main`
- pentru arhivare și istoric canonic, același commit se împinge în GitPrep cu `git push origin main`
- jumper rămâne target de test live, nu locul principal de editare
- `scripts/deploy_to_jumper.sh` rămâne unealtă explicită de rsync deploy, dar nu înlocuiește disciplina commit/push
- `BUILD` rămâne sursa vizibilă pentru ce versiune rulează

Scop:

- niciun front de lucru să nu rămână doar în fișiere dirty locale sau runtime
- testul live pe jumper să fie legat de un commit identificabil
- GitPrep să păstreze istoria canonică pentru arhivare și recuperare
- badge-ul de build și meta tag-ul `xdev-build` devin verificarea rapidă pentru ce rulează

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

Observație: editările de hosts făcute în aplicația live puteau rămâne în 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 în git și ca dată operațională runtime, ceea ce nu era o sursă de adevăr clară.

Decizie:

- `var/host-manager.sqlite` devine sursa de adevăr runtime pentru registry și Work Orders
- `config/hosts.yaml` și `config/work-orders.yaml` rămân seed/snapshot/export compatibility files
- la prima pornire, aplicația seed-uiește documentele lipsă din YAML în SQLite
- download-urile `/download/hosts.yaml`, `/download/local-hosts.tsv` și `/download/monitoring.json` sunt randate din SQLite
- `config/local-hosts.tsv` rămâne manifest generat explicit pentru sync-ul DNS local
- push-urile de cod către jumper nu trebuie să înlocuiască baza runtime din `var/`

Scop:

- editările făcute în UI să nu se piardă la deploy/push de cod
- să existe o singură autoritate runtime
- YAML/TSV să rămână utile pentru export, review și bootstrap fără să fie storage-ul live

## 2026-06-09 - Relational Runtime Schema

Observație: primul pas SQLite mutase sursa de adevăr din git în baza de date, dar o păstra ca document YAML într-o tabelă generică. Asta rezolva pierderea editărilor la push, dar nu oferea o bază de date operațională reală.

Decizie:

- `hosts.fqdn` devine cheia reală pentru hosturi, ca numele complete să evite coliziuni între domenii
- `legacy_id` rămâne doar compatibilitate pentru UI/API-ul curent
- aliasurile sunt păstrate în `host_aliases`, inclusiv după retragere
- vhosturile sunt în `vhosts` și pot fi mutate prin schimbarea `host_fqdn`
- rolurile, sursele, flagurile și SSH sunt în tabele separate, nu coloane adăugate continuu în `hosts`
- workerii de date au `data_workers`, `dhcp_leases` și `mdns_observations`
- certificatele emise au `certificates` și `certificate_dns_names`
- `documents` rămâne doar tabel legacy pentru migrare din modelul vechi document-store

Scop:

- schema să poată susține inventar, DNS, vhosturi, observații externe și certificate fără să piardă istoric operațional
- aliasurile/vhosturile retrase să rămână audibile în baza de date
- structura să fie extensibilă fără să supraîncarce tabelul `hosts`