0001 — Split della configurazione tra instances.json e .env

• Status: accepted
• Date: 2026-04-26

Context

Il tool deve connettersi a più istanze Odoo (sviluppo, produzione, clienti diversi). Ogni istanza richiede:

• Metadati strutturali non sensibili: URL, nome database, versione Odoo, username, nome della variabile d'ambiente che contiene il secret.
• Secret veri e propri: password e/o API key.

I secret non devono finire nel repository, ma i metadati strutturali sono utili da versionare per condividerli col team e tenere traccia delle istanze configurate.

Mescolare i due tipi di dati nello stesso file (es. un unico .env con tutto, o un unico config.json con tutto) renderebbe troppo facile committare per errore i secret oppure perdere visibilità sulla lista delle istanze attive.

Decision

Separiamo la configurazione in due file:

• instances.json (versionato): array di istanze con name, url, database, version, username, password_env, api_key_env. Contiene solo riferimenti alle env var, mai i valori dei secret.
• .env (non versionato, in .gitignore): contiene i valori reali delle variabili referenziate da password_env / api_key_env.

load_instances() (src/odoo_analysis/config.py) legge entrambi e produce oggetti InstanceConfig con i secret avvolti in pydantic.SecretStr per evitare leak nei log.

Consequences

• ✅ I metadati strutturali sono review-abili e tracciabili in git.
• ✅ I secret restano locali; aggiungere un nuovo developer significa solo fornirgli i valori da mettere in .env.
• ✅ Pydantic + SecretStr proteggono dai leak accidentali in log/errori.
• ⚠️ La modifica della lista istanze richiede un commit in instances.json, non solo un cambio locale di .env. Accettabile: vogliamo la review.
• ⚠️ Il developer deve mantenere allineate le due fonti (nome password_env in JSON ↔ chiave in .env). Mitigato dall'errore esplicito di load_instances quando l'env var manca.