← Indice documentazione Guida all'architettura › approvazione

Metnos

Flusso di approvazione
Come una proposta viene mostrata, decisa ed eseguita senza perdere identità, lingua o stato.

Quando la policy richiede una decisione umana, Metnos non esegue il passo. Registra una proposta pendente, la presenta sul canale dell'utente e riprende soltanto dopo una decisione valida. Testo, etichette e pulsanti seguono la lingua firmata dell'istanza.

Indice

  1. Quando viene chiesta una decisione
  2. Il flusso corrente
  3. Chat web e Telegram
  4. Lingua d'istanza e isolamento per utente
  5. Esempio in linguaggio naturale
  6. Invarianti di sicurezza
  7. Confini attuali e riferimenti

1. Quando viene chiesta una decisione

Il vaglio e la policy valutano il passo preparato dal pianificatore. L'esito può consentire l'esecuzione, negarla oppure produrre una proposta approval_required. Soltanto il terzo caso apre un dialogo di consenso.

La forma della proposta dipende dalla capability e dal canale. Non esiste un contratto pubblico che imponga sempre tre righe o sempre due pulsanti. Il contratto stabile è semantico: la persona deve poter riconoscere l'azione, il suo obiettivo e le conseguenze rilevanti prima di decidere.

2. Il flusso corrente

  1. Il runtime prepara executor e argomenti, senza eseguire l'azione.
  2. La policy produce una proposta tipizzata e il canale la salva nello stato cap_pending, legato al mittente e al turn_id.
  3. La UI mostra il testo della proposta e le scelte disponibili.
  4. Una risposta testuale oppure un callback valido consuma la stessa proposta.
  5. Lo stato viene rimosso prima dell'esecuzione, così un doppio clic o una risposta ripetuta non può eseguire due volte il passo.
  6. Un rifiuto, una scadenza o un identificatore non più corrente non esegue nulla.

Per i flussi che usano il registro atomico approval_registry, il token è inoltre monouso, ha una scadenza predefinita di dieci minuti ed è vincolato a canale e mittente. Il registro applica la transizione con una transazione SQLite.

3. Chat web e Telegram

CanalePresentazioneDecisione
Chat webLa proposta compare nella conversazione; i dialoghi strutturati possono aprirsi come modulo incorporato.La risposta o il modulo vengono risolti nella stessa conversazione e nello stesso spazio utente.
TelegramQuando il tipo lo consente, il messaggio include i pulsanti localizzati Approva e Rifiuta. I dialoghi non rappresentabili come pulsanti restano testuali.Il callback cap:<turn_id>:yes|no deve coincidere con la proposta ancora pendente. Anche una risposta testuale sì/no usa lo stesso stato.

Il trasferimento di una conversazione tra dispositivi non trasferisce l'identità a un altro utente: conversazione, sessione attiva e stato pendente restano nello spazio del proprietario.

4. Lingua d'istanza e isolamento per utente

Le etichette user-facing sono chiavi del catalogo i18n, non stringhe possedute dal renderer. La lingua viene risolta una volta dalla richiesta d'istanza firmata e il medesimo valore viene propagato a renderer, pianificatore e Tutor. Il binding canale–utente non può sostituirlo.

Tutti gli utenti della stessa istanza ricevono quindi la stessa lingua. Per offrire due lingue operative simultanee servono due istanze distinte. Una chiave non ancora tradotta segue la catena di ripiego lingua d'istanza → inglese → italiano.

5. Esempio in linguaggio naturale

Chiedi a Metnos con una richiesta come quella di questo esempio: «Invia il rapporto a [email protected] e mostrami cosa verrà inviato prima di procedere».

Metnos prepara il passo e, se la policy richiede conferma, mostra una proposta localizzata. Un possibile contenuto è:

Inviare il rapporto mensile a [email protected]
Operazione non annullabile dopo la consegna
[Approva] [Rifiuta]

L'esempio illustra le informazioni necessarie, non un layout fisso. Su Telegram le scelte possono essere pulsanti; nella chat web possono essere una risposta o un modulo incorporato.

6. Invarianti di sicurezza

InvarianteEffetto
Decisore = richiedenteInoltrare un messaggio o conoscere un token non trasferisce l'autorità a un'altra persona.
Identificatore correnteUn pulsante appartenente a un turno precedente viene rifiutato.
Consumo prima dell'esecuzioneDoppi clic e retry non duplicano l'azione.
ScadenzaUna proposta troppo vecchia deve essere generata di nuovo.
Isolamento per utenteStato, conversazione e decisione non sono condivisi fra utenti; la lingua appartiene invece all'istanza.
Nessuna delega implicitaApprovare un passo non crea automaticamente un permesso generale o permanente.

7. Confini attuali e riferimenti

Una concessione persistente deve essere rappresentata esplicitamente dalla policy, avere un ambito riconoscibile e offrire un percorso di revoca. Metnos non la deduce dalla frequenza delle approvazioni, dalla loro formulazione o dal silenzio dell'utente.

Per il percorso utente delle pagine e dei canali, vedi la guida all'interfaccia.