Flussi di approvazione
Un'approvazione vale qualcosa solo se la cosa approvata è la cosa che esce.
Questo descrive un progetto, non un servizio funzionante
Il problema
Le approvazioni di solito vivono fuori dallo strumento che pubblica. Uno screenshot va a un cliente, il cliente risponde sì, e poi il testo cambia. L'approvazione ora si riferisce a una bozza che nessuno ha, e lo strumento non ne ha idea, quindi pubblica qualunque cosa gli sia stata data per ultima.
Come è progettato il prodotto
- Un'approvazione è collegata esattamente al contenuto che è stato revisionato. Modificare una bozza approvata invalida l'approvazione e dice quale campo è cambiato, invece di portare avanti in silenzio la vecchia decisione.
- Un revisore può approvare, chiedere modifiche o rifiutare, ed è richiesto un commento per qualsiasi cosa diversa dall'approvazione, così l'autore non resta mai a indovinare cosa correggere.
- La regola vive nel livello applicativo condiviso, quindi l'app web, l'API REST, il server MCP, la CLI e i webhook la rispettano tutti. Nessuna superficie ha una scorciatoia per aggirare la revisione.
Cosa è realmente costruito
Gli stati di approvazione, la superficie di revisione, le regole di ri-approvazione e gli eventi di audit dietro di essi sono costruiti. Ciò che non è costruito è l'ultimo passo, perché nessun connettore ha superato la sua definizione di completamento, quindi un post approvato non ha ancora dove andare.
Ho trovato qualcosa che non va in questa pagina
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.