Rendre la spécification décidable
- problème, utilisateurs et non-objectifs
- preuves de l'état actuel
- comportement proposé et contrats publics
- données, permissions et sémantique d'erreur
- risques, migration, retour arrière et questions ouvertes
- autorité précise demandée au relecteur
Distinguer faits, proposition et feuille de route
Le lecteur doit voir immédiatement ce qui existe aujourd'hui, ce que la spécification propose de modifier et ce qui reste une possibilité future. Un ton assuré ne remplace pas un statut.
Publier un candidat à relire
Valider le paquet localement puis publier avec --review. En cas de demande de modifications, corriger le draft source et soumettre un nouveau candidat.
ow a2ui draft check ./spec
ow a2ui draft build ./spec
ow a2ui digest ./spec/document.mdw
ow publish ./spec/document.mdw --review --no-open --timeout 900Lier l'implémentation à la révision approuvée
Dans les notes d'implémentation, preuves de livraison et dossiers d'audit, employer le lien fixe de la version approuvée. Un changement de périmètre substantiel exige une nouvelle décision.
FAQ
Questions fréquentes
L'implémentation doit-elle lier la spécification canonique ou une version fixe ?
La version approuvée et immuable sert de contrat d'implémentation ; l'URL canonique sert à consulter l'état formel actuel.
Un Agent peut-il approuver sa propre spécification ?
Non. La boucle de review attend une décision humaine explicite ; l'absence d'approbation bloque l'Agent.
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.