Rendre le plan réellement décisionnel
Exposez objectif, périmètre, hypothèses, changements envisagés, systèmes touchés, risques, rollback et autorité demandée. Distinguez les faits vérifiés du jugement de l'Agent : c'est ce qui rend une approbation interprétable.
Soumettre une candidate qui bloque
Après check, build et digest, publiez avec --review et un timeout. Le lien de revue donne un pouvoir de décision : ne le distribuez pas comme une URL de lecture.
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 900Faire correspondre chaque résultat à un comportement
Approved autorise uniquement le périmètre revu. Changes requested impose de corriger la source et de soumettre une autre candidate ; Rejected arrête le chemin proposé ; timeout ou erreur signifie absence de décision, jamais consentement implicite.
Gouverner également les changements ultérieurs
Si le plan change matériellement, ajoutez une candidate à la même identité et demandez une revue à nouveau. Une approbation ancienne ne couvre pas un autre plan sous prétexte que son URL est identique.
ow publish ./plan/document.mdw --update <document_id> --review --no-openFAQ
Questions fréquentes
L'Agent peut-il continuer après une demande de modifications ?
Il peut réviser et resoumettre, mais ne doit pas exécuter la candidate qui a reçu cette décision.
Une approbation couvre-t-elle toutes les révisions suivantes ?
Non. Toute candidate matériellement différente demande une décision attachée à sa propre révision.
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.