Flux d'approbation
Une approbation ne vaut quelque chose que si ce qui est approuvé est ce qui sort.
Ceci décrit une conception, pas un service en fonctionnement
Le problème
Les approbations vivent généralement en dehors de l'outil qui publie. Une capture d'écran part vers un client, le client répond oui, puis le texte change. L'approbation renvoie maintenant à un brouillon que personne n'a, et l'outil n'en sait rien, il publie donc ce qui lui a été donné en dernier.
Comment le produit est conçu
- Une approbation est attachée exactement au contenu qui a été révisé. Modifier un brouillon approuvé invalide l'approbation et indique quel champ a changé, plutôt que de faire tacitement perdurer l'ancienne décision.
- Un réviseur peut approuver, demander des modifications ou rejeter, et un commentaire est requis pour tout sauf l'approbation, l'auteur n'est donc jamais laissé à deviner quoi corriger.
- La règle vit dans la couche applicative partagée, l'application web, l'API REST, le serveur MCP, la CLI et les webhooks lui obéissent donc tous. Aucune surface n'a de raccourci pour contourner la révision.
Ce qui est réellement construit
Les états d'approbation, la surface de révision, les règles de réapprobation et les événements d'audit derrière eux sont construits. Ce qui n'est pas construit est la dernière étape, parce qu'aucun connecteur n'a atteint sa définition de fait, une publication approuvée n'a donc encore nulle part où aller.
J'ai trouvé quelque chose qui ne va pas sur cette page
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.