Goedkeuringsworkflows
Een goedkeuring is alleen iets waard als het goedgekeurde ook is wat naar buiten gaat.
Dit beschrijft een ontwerp, geen draaiende dienst
Het probleem
Goedkeuringen leven meestal buiten de tool die publiceert. Een screenshot gaat naar een klant, de klant antwoordt ja, en dan verandert de tekst. De goedkeuring verwijst nu naar een concept dat niemand heeft, en de tool heeft geen idee, dus publiceert het wat het laatst is meegegeven.
Hoe het product is ontworpen
- Een goedkeuring is gekoppeld aan precies de inhoud die is beoordeeld. Het bewerken van een goedgekeurd concept maakt de goedkeuring ongeldig en zegt welk veld is veranderd, in plaats van de oude beslissing stilzwijgend voort te zetten.
- Een beoordelaar kan goedkeuren, wijzigingen aanvragen of afwijzen, en een opmerking is verplicht voor alles behalve goedkeuring, zodat de auteur nooit hoeft te raden wat er moet worden opgelost.
- De regel leeft in de gedeelde applicatielaag, dus de webapp, de REST-API, de MCP-server, de CLI en webhooks houden zich er allemaal aan. Geen enkel oppervlak heeft een sluiproute langs de beoordeling.
Wat daadwerkelijk gebouwd is
De goedkeuringsstatussen, het beoordelingsoppervlak, de regels voor herhaalde goedkeuring en de audit-events daarachter zijn gebouwd. Wat niet gebouwd is, is de laatste stap, omdat geen enkele connector zijn definition of done heeft gehaald, dus een goedgekeurd bericht heeft nog nergens naartoe.
Er is iets misgegaan op deze pagina
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.