Precedenza dei parametri

In breve

La precedenza non è un elenco di preferenze: è una funzione che, per ogni parametro, restituisce valore e provenienza oppure un errore. La regola adottata qui è: argomento della chiamata, ambiente, configurazione condivisa, default dichiarato. Un valore presente ma invalido interrompe la risoluzione; non autorizza a scendere al livello successivo. Così un errore resta visibile e un agente non cambia modello, effort o directory senza dirlo.

Tabella di risoluzione

Priorità	Sorgente	Uso corretto	Se il valore è invalido
1	Argomento esplicito	Eccezione per la singola esecuzione	errore immediato
2	Ambiente del processo	Adattamento della workstation o della sessione	errore immediato
3	Configurazione condivisa	Politica ordinaria e versionabile	errore immediato
4	Default dichiarato	Solo parametri per cui esiste un valore sicuro	errore oppure valore noto

L’assenza è distinta da una stringa vuota, da un valore fuori catalogo e da una risorsa non raggiungibile. Solo l’assenza passa al livello inferiore. Il risultato diagnostico può esporre source=call, source=environment, source=config o source=default, senza stampare il valore quando è sensibile.

resolve(nome, candidati, valida):
  per sorgente in [chiamata, ambiente, configurazione, default]:
    se il candidato è assente: continua
    se non valida(candidato): fallisci indicando nome e sorgente
    restituisci { valore: candidato, sorgente }
  fallisci: parametro obbligatorio non configurato

Questa funzione deve essere unica per setup, launcher, scheduler e verifica. Se ciascun consumer reimplementa l’ordine, la precedenza è solo documentazione. Il principio è affine alla separazione fra codice e configurazione descritta da Twelve-Factor Config, ma l’ordine e la semantica d’errore sono una decisione locale.

Caso: il vincolo che nessuno leggeva

In un’integrazione reale, la configurazione conteneva un campo chiamato come un limite massimo. Il guard del launcher, però, leggeva un’altra proprietà. Un valore non supportato superava quindi il preflight e falliva soltanto nel runtime con un messaggio generico. Il difetto non era nel numero scelto: era nel contratto senza consumer.

La correzione ha reso il catalogo dei valori ammessi parte del risolutore e ha introdotto due errori distinti: “non configurato” e “non supportato dal canale”. Il test utile cambia un solo valore nella fonte condivisa, applica la configurazione e controlla che launcher e verifica osservino la stessa modifica. È una prova di propagazione, non una ricerca testuale.

Percorsi e capacità

Per una radice di lavoro la sequenza può essere più corta: argomento esplicito, ambiente, derivazione dalla posizione dello script. Non deve esistere un ultimo fallback “plausibile”. Se la derivazione non è possibile, l’esecuzione si ferma prima di toccare file. Questo collega la regola alla portabilità degli agenti.

Anche la validazione dipende dal canale. Un effort o una modalità disponibili nel client principale possono non esserlo in un companion. Prima si risolve il canale, poi si valida il parametro contro le sue capacità; l’ordine inverso certifica una configurazione che nessuno eseguirà. La prova del canale è approfondita in Verificare il canale eseguito.

Limiti

Una gerarchia non rende uniformi sistemi con capacità diverse e non stabilisce se il valore scelto sia conveniente per il task. Il resolver dimostra soltanto quale sorgente ha vinto e che il valore era valido al momento del controllo. Configurazioni modificate dopo il preflight, ambienti ereditati da processi longevi e default dei vendor richiedono ancora una verifica sul runtime effettivo.

Voci correlate

• Setup verificabile degli agenti
• Verificare il canale eseguito
• Canali di accesso ai modelli

Fonti

• The Twelve-Factor App: Config, riferimento generale sulla separazione della configurazione; non prescrive la gerarchia proposta in questa voce.