Flujos de aprobación
Una aprobación solo vale algo si lo aprobado es lo que sale.
Esto describe un diseño, no un servicio en funcionamiento
El problema
Las aprobaciones suelen vivir fuera de la herramienta que publica. Una captura de pantalla se le manda a un cliente, el cliente responde que sí, y entonces el texto cambia. La aprobación ahora se refiere a un borrador que nadie tiene, y la herramienta no lo sabe, así que publica lo último que se le entregó.
Cómo está diseñado el producto
- Una aprobación queda adjunta exactamente al contenido que se revisó. Editar un borrador aprobado invalida la aprobación e indica qué campo cambió, en lugar de simplemente arrastrar la decisión anterior en silencio.
- Un revisor puede aprobar, pedir cambios o rechazar, y un comentario es obligatorio para cualquier cosa que no sea aprobar, así que el autor nunca se queda sin saber qué corregir.
- La regla vive en la capa de aplicación compartida, así que la app web, la API REST, el servidor MCP, la CLI y los webhooks la obedecen todos. Ninguna superficie tiene un atajo para saltarse la revisión.
Lo que ya está construido de verdad
Los estados de aprobación, la superficie de revisión, las reglas de reaprobación y los eventos de auditoría detrás de ellos están construidos. Lo que no está construido es el último paso, porque ningún conector completó su definición de listo, así que una publicación aprobada todavía no tiene a dónde ir.
Encontré algo mal en esta página
Contact channels will be published here before general availability. No legal or support inbox is operating during this preview.