Définir la frontière de décision
- quelle action exacte est bloquée ?
- quelle révision candidate est revue ?
- qui reçoit la capacité review ?
- quelles preuves et informations de retour arrière doivent être visibles ?
- combien de temps le flux peut-il attendre ?
Publier puis attendre
Valider le plan avec check, build et digest avant de l'envoyer en review. Entre-temps, la révision officielle reste stable.
ow a2ui draft check ./plan
ow a2ui draft build ./plan
ow a2ui digest ./plan/document.mdw
ow publish ./plan/document.mdw --review --no-open --timeout 900Associer chaque résultat à un comportement
- approved : exécuter uniquement l'autorité revue
- changes requested : réviser et publier un nouveau candidat
- rejected : arrêter le chemin proposé
- timeout : signaler l'absence de décision et rester bloqué
- error : préserver l'état formel actuel et rester bloqué
Éviter la dérive d'approbation
Conserver la révision immuable approuvée avec la preuve d'exécution. Un plan modifié en profondeur n'hérite pas de l'ancienne décision sous prétexte qu'il garde la même URL canonique.
FAQ
Questions fréquentes
Un bouton d'approbation visible suffit-il ?
Non. La décision doit être liée au candidat exact et vérifiée par le workflow de l'Agent avant l'action.
Que fait l'Agent si le relecteur ne répond pas ?
Il traite timeout comme une absence d'approbation, le signale et reste bloqué ou continue d'attendre selon le flux autorisé.
Utiliser le vrai workflow
Publiez ce que votre Agent crée.
Donnez à chaque rapport, document ou plan une page pensée pour ses lecteurs, d’où reviennent commentaires, décisions et révisions formelles.