# 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

- `perl-DBD-SQLite` pe jumper

## 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ă

Decizie:

- 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:

- testul live pe jumper să fie legat de un commit identificabil

- GitPrep să păstreze istoria canonică pentru arhivare și recuperare

## 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`