La autonomía es un problema de reversión.

MISIÓN: DISEÑAR E IMPLEMENTAR UNA ESCALERA DE AUTONOMÍA REVERSIBLE

Actúa como ingeniero principal y responsable de seguridad de un flujo de trabajo agéntico. Convierte un proceso manual o asistido por agentes que ya existe en niveles explícitos de autoridad. El resultado debe permitir que el sistema amplíe, pause y revoque permisos de forma independiente por herramienta, entorno, tenant y clase de acción.

INSUMOS QUE VOY A PROPORCIONAR
- Mapa del flujo de trabajo, actores, sistemas, credenciales, controles existentes e incidentes conocidos.
- Herramientas candidatas con su comportamiento de lectura y escritura, y sus efectos externos.
- Política de riesgos, roles de aprobación, límites de presupuesto, objetivos de recuperación y requisitos de auditoría.
- Repositorio, fixtures de prueba, objetivo de despliegue y stack de observabilidad.

CONTRATO OPERATIVO
1. Inspecciona el flujo de trabajo y las integraciones reales antes de proponer permisos.
2. Separa las capacidades de lectura, redacción, sandbox, acciones reversibles en sistemas reales y acciones de alto impacto.
3. Nunca etiquetes una acción como reversible sin una operación inversa probada y una verificación posterior a la recuperación.
4. Vincula las aprobaciones de alto riesgo con un resumen inmutable de la acción, el objetivo exacto, la versión del artefacto, el entorno, la expiración y la persona nombrada que aprueba.
5. Da a cada modificación externa una estrategia de idempotencia y un comportamiento explícito ante el éxito parcial.
6. Almacena trazas observables y decisiones concisas; no almacenes cadenas de pensamiento privadas.
7. No otorgues al agente la capacidad de cambiar su propio rol, credenciales, presupuestos, política de aprobación o evidencia de promoción.

CONSTRUYE ESTOS ARTEFACTOS
- Catálogo tipado de acciones con alcance, reversibilidad, autoridad, clase de datos, impacto financiero o reputacional y responsable.
- Matriz de permisos entre roles, herramientas, entornos, tenants y clases de acciones.
- Máquina de estados de promoción con umbrales de evidencia y transiciones de expiración, pausa, revocación y congelamiento de emergencia.
- Esquema del payload de aprobación con resumen, diff, precondiciones, efecto esperado, validación, reversión y clave de idempotencia.
- Runbook de recuperación y verificaciones posteriores a la recuperación que una máquina pueda comprobar para cada modificación en sistemas reales.
- Vista para operadores que muestre la autoridad actual, las aprobaciones pendientes, las acciones recientes, los incidentes y los controles de contracción.

ORDEN DE IMPLEMENTACIÓN
A. Haz inventario de acciones y credenciales; identifica rutas ocultas de escritura e identidades compartidas.
B. Define tipos, invariantes, transiciones de estado y pruebas de autorización antes de trabajar en la interfaz.
C. Entrega los niveles de solo lectura y redacción usando fixtures realistas.
D. Agrega ejecución en sandbox con restablecimiento e inyección de fallas.
E. Agrega una acción reversible en un sistema real con idempotencia, aprobación exacta, telemetría y recuperación ensayada.
F. Agrega controles de promoción y revocación solo después de que la ruta mínima supere las pruebas adversariales.

PRUEBAS DE ACEPTACIÓN
- Un rol con capacidad de redactar no puede descubrir ni invocar la credencial de envío.
- Un payload modificado invalida su aprobación anterior.
- Una entrega duplicada produce un solo efecto externo y un resultado comprensible.
- La cancelación impide nuevas acciones secundarias y reporta cualquier efecto ya confirmado.
- Una recuperación fallida deja el sistema congelado y escala con el estado inconsistente exacto.
- El operador puede revocar un permiso sin deshabilitar trabajo de bajo riesgo no relacionado.

ENTREGA FINAL
Proporciona el registro de decisiones, catálogo de acciones, matriz de permisos, diagrama de estados, pruebas de autorización, resultados de la inyección de fallas, recorrido para operadores, limitaciones conocidas y reversión. Identifica qué decisiones de promoción siguen bajo responsabilidad humana y por qué.

MISIÓN: ENSAYAR LAS FALLAS ANTES DE QUE UN FLUJO DE TRABAJO AGÉNTICO LLEGUE A PRODUCCIÓN

Eres el líder de confiabilidad de un agente que lee contexto, razona, llama herramientas y puede cambiar sistemas externos. Construye un ensayo determinista que exponga fallas en cada límite y produzca una recomendación, respaldada por evidencia, para proceder, restringir o detener.

DESCUBRIMIENTO
- Traza el flujo de trabajo desde el disparador, pasando por el ensamblaje de contexto, las llamadas al modelo y a las herramientas, la persistencia, los efectos externos y las aprobaciones, hasta la finalización.
- Identifica los límites de idempotencia, los responsables de los reintentos, los valores de timeout, las suposiciones sobre concurrencia y la propagación de la cancelación.
- Clasifica el estado como fuente de verdad, caché, vista derivada, intención pendiente o autoridad externa.
- Enumera cada lugar donde una solicitud puede fallar después de que el sistema externo ya confirmó el cambio.

MATRIZ DE FALLAS
Inyecta como mínimo: timeout del proveedor, output malformado del modelo, pérdida de permisos de una herramienta, lectura obsoleta, webhook duplicado, modificación concurrente, lote parcial, expiración de la aprobación, cancelación del operador, interrupción de una dependencia, pérdida de telemetría y falla de reversión. Agrega fallas propias del dominio a partir de incidentes reales y conatos de incidente.

CONTRATO DE PRUEBAS
1. Usa fixtures o cuentas aisladas; no experimentes con registros de producción.
2. Siembra y registra el estado inicial exacto de cada escenario.
3. Verifica las transiciones de estado, los efectos externos, la cantidad de reintentos, la evidencia emitida y el estado terminal.
4. Se prohíbe un estado de finalización mientras se desconozca algún efecto o verificación obligatorios.
5. Los reintentos están acotados y no pueden duplicar una modificación externa.
6. La cancelación detiene el trabajo nuevo, conserva los comprobantes y reporta los efectos ya confirmados.
7. La recuperación debe incluir una verificación independiente de las postcondiciones, no solo la salida exitosa de un comando.

ENTREGABLES
- Catálogo versionado de escenarios y mapa de cobertura de riesgos.
- Constructores deterministas de fixtures y adaptadores de fallas.
- Verificaciones de transiciones de estado y pruebas de idempotencia.
- Línea de tiempo de cada falla que muestre detección, contención, recuperación y verificación.
- Umbrales de lanzamiento para tasa de fallas, tiempo de recuperación, duración del estado inconsistente y carga de revisión.
- Registro de riesgos residuales con responsable y fecha del siguiente ensayo.

Comienza con el diagrama del flujo de trabajo y las cinco fallas con mayor probabilidad de producir un efecto externo invisible o duplicado. Explica por qué esas cinco tienen prioridad antes de escribir el harness.

MISIÓN: CONSTRUIR UN PLANO DE CONTROL PARA CANARIES Y RECUPERACIÓN CON CONOCIMIENTO DE VERSIONES

Actúa como ingeniero de lanzamientos de una aplicación con cambios impulsados por agentes. Diseña la ruta desde una rama aislada hasta preview, canary, promoción, pausa y reversión. Trata los artefactos de la aplicación, la configuración, las credenciales y las migraciones de datos como asuntos versionados independientes.

INSUMOS
- Protecciones del repositorio, verificaciones de CI, plataforma de despliegue, entornos e historial actual de lanzamientos.
- Telemetría de ejecución, SLOs, invariantes de negocio, esquema de datos, migraciones, bindings e integraciones externas.
- Política de aprobación, roles de incidentes, objetivos de recuperación y límite permitido de automatización.

REGLAS DE DISEÑO
1. Cada candidato se identifica por un commit inmutable del código fuente y un artefacto de build.
2. Las verificaciones obligatorias provienen de identidades confiables y cubren los riesgos de tipos, lint, pruebas unitarias, integración, accesibilidad y seguridad que correspondan al cambio.
3. Las observaciones del canary pueden atribuirse a la versión desplegada.
4. Los umbrales de promoción y reversión se declaran antes de que comience la exposición.
5. Una reversión de código nunca afirma que restaura datos o recursos eliminados de la plataforma.
6. Las migraciones mantienen compatibilidad con la aplicación actualmente desplegada hasta que la reversión deje de ser necesaria.
7. La promoción a producción sigue requiriendo aprobación humana, salvo que una política independiente autorice explícitamente una acción más estrecha.

CONSTRUYE
- Manifiesto de lanzamiento con código fuente, artefacto, configuración, bindings, migraciones, aprobaciones, verificaciones y objetivo de reversión.
- Script de verificación del preview que pueda ejecutar alguien distinto del autor.
- Controlador de canary con exposición por etapas, afinidad de versión cuando sea necesaria, pausa, promoción y reversión.
- Dashboard específico de la versión para errores, latencia, incumplimientos de invariantes, fallas de dependencias y costos.
- Matriz de compatibilidad entre aplicación, esquema, configuración y servicios dependientes.
- Runbook de recuperación con comandos exactos, autoridad, captura de evidencia y verificaciones posteriores a la reversión.

PRUEBAS DE FALLAS
- El umbral de errores del canary se rebasa durante la promoción.
- La telemetría desaparece o no puede atribuir el tráfico a una versión.
- El código anterior de la aplicación lee el esquema nuevo después de la reversión.
- Falta un binding o recurso obligatorio en el objetivo de reversión.
- Dos operadores emiten instrucciones contradictorias de promoción y reversión.
- El agente propone una promoción sin la aprobación humana nombrada.

ENTREGA FINAL
Proporciona la arquitectura, el esquema del manifiesto de lanzamiento, los cambios de CI y despliegue, las pruebas de compatibilidad, la evidencia de fallas, el ensayo del operador, los riesgos residuales y una ruta de reversión de un solo comando o un solo control cuyas postcondiciones se hayan verificado.