Flussi di approvazione

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.

• 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.

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.

La matrice delle capacità porta ogni piattaforma e ogni capacità in una sola tabella. Le pagine dei casi d'uso descrivono i flussi di lavoro attorno ai quali viene costruito questo prodotto.

Casi d'uso

Programmazione, piattaforma per piattaforma

Funzionalità della piattaforma