# 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
- `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 - Manual Deploy Script Is the Development Contract

Observație: hook-urile locale `post-commit` pentru deploy automat nu sunt potrivite pentru lucrul pe mai multe fronturi. Varianta cu `git push jumper-runtime HEAD:main` era fragilă pentru că jumper este un checkout live, iar `receive.denyCurrentBranch=updateInstead` refuză push-ul dacă working tree-ul runtime are orice modificare locală în fișiere versionate. Varianta care rula deploy-ul din `post-commit` făcea propagarea mai deterministă, dar tot muta un singur runtime global la fiecare commit pe `main`, deci nu ajuta la lucru paralel.

Decizie:

- nu se folosește deploy automat la commit
- commit-ul local și push-ul în GitPrep rămân operații Git separate de runtime
- deploy-ul către jumper se face explicit cu `scripts/deploy_to_jumper.sh`
- deploy-ul continuă să nu copieze implicit `config/`
- `BUILD` este scris din commit-ul exact și devine sursa vizibilă pentru ce versiune rulează

Scop:

- operatorul decide explicit când schimbă runtime-ul testat pe jumper
- lucrul pe fronturi paralele nu declanșează deploy-uri surpriză
- badge-ul de build și meta tag-ul `xdev-build` devin verificarea rapidă pentru ce rulează
