8. Proyecto: una pasada de prueba completa en sandbox

Descripción

Al terminar este proyecto vas a haber ejecutado, de punta a punta y a costo cero, una pasada de prueba completa sobre order-triage: los siete puntos del checklist de pre-producción, encadenados en un solo procedimiento repetible, con su evidencia guardada en el repositorio. No vas a aprender técnicas nuevas —ya las tienes todas—; vas a juntarlas en el artefacto que le da sentido al módulo entero: un checklist ejecutado que demuestra, con pruebas, que order-triage está listo para promover a producción sin arriesgar datos, dinero ni reputación.

Esto importa porque este entregable es, literalmente, lo que el mercado pide por escrito y lo que defiendes en una entrevista. Cuando una oferta dice "test in a sandbox with synthetic data before deploying", no pide que sepas la teoría; pide que puedas mostrar una pasada de prueba ejecutada. Al terminar tienes eso: un archivo en cumbre-automations que cualquiera —tu equipo, un entrevistador, tú mismo en tres meses— puede leer para ver exactamente cómo se probó este workflow y con qué resultado. Es la prueba tangible de que cruzaste de "constructor de workflows" a "dueño del sistema".

Conexión con el módulo: este es el séptimo y último punto del checklist —la pasada completa con evidencia— y la síntesis de los seis anteriores. Cada fase de este proyecto es una lección: las llaves sandbox (2), los datos sintéticos (3), el dry run (4), los datos fijados (5), el agente a costo cero (6) y las aserciones (7). Aquí no se explican de nuevo; se ejecutan en orden. Y prepara el Módulo 6: una vez que tienes esta pasada verde, el siguiente paso es promover el cambio probado de staging a prod, con su rollback —que es justo donde arranca el módulo que sigue—.

El entregable: el checklist ejecutado con evidencia

Antes de hacer nada, ten claro qué vas a producir. El entregable no es un workflow nuevo ni una configuración; es un documento: un archivo docs/pre-production-checklist.md dentro de cumbre-automations, lleno con el resultado de haber corrido las siete verificaciones sobre order-triage, más la evidencia que respalda cada una.

Piénsalo como la hoja de pre-vuelo firmada de un piloto. Antes de que el avión salga de la puerta, el piloto recorre una lista —frenos, combustible, instrumentos, superficies— y firma cada punto: no "creo que está bien", sino "verifiqué esto, con este resultado, a esta hora". Esa hoja firmada es el artefacto que dice "esta aeronave está lista para volar", y queda registrada. Tu checklist ejecutado es la hoja de pre-vuelo de order-triage: cada punto verificado, con su evidencia, firmado con un commit en Git.

Así se ve la plantilla que vas a llenar:

# Pasada de prueba de pre-producción — order-triage

- Workflow: order-triage
- Versión probada (commit): __________
- Entorno de la pasada: dev + staging
- Fecha: __________
- Ejecutó: __________

## Resultado

- [ ] 1. Llaves sandbox — corrió contra el CRM de prueba, nunca producción
- [ ] 2. Datos sintéticos — 6 casos + tanda de volumen, con casos borde y sucios
- [ ] 3. Dry run — efectos secundarios protegidos (compuerta por entorno)
- [ ] 4. Datos fijados — entradas congeladas, pasada reproducible
- [ ] 5. Agente a costo cero — iterado en Ollama, validado contra el modelo vigente
- [ ] 6. Aserciones — la salida verificada contra las respuestas esperadas
- [ ] 7. Pase completo a costo cero — con evidencia adjunta

## Veredicto: PASS / FAIL

## Evidencia
(capturas, tabla de resultados de la evaluación, casos que fallaron y su fix)

El objetivo del proyecto es llenar cada casilla con una verificación real y adjuntar su evidencia. Cuando las siete estén marcadas y el veredicto sea PASS, order-triage está listo para el Módulo 6. Vamos fase por fase.

Para que veas la meta antes de empezar, así se ve el checklist ya lleno después de una pasada exitosa —esto es lo que produces al final—:

# Pasada de prueba de pre-producción — order-triage

- Workflow: order-triage
- Versión probada (commit): a1b2c3d
- Entorno de la pasada: dev + staging
- Fecha: 2026-07-23
- Ejecutó: (tu nombre)

## Resultado

- [x] 1. Llaves sandbox — credencial CRM API en dev apunta a sandbox-api...; lectura devolvió datos de utilería
- [x] 2. Datos sintéticos — 6 casos en test/fixtures/orders.json (feliz, grande, incompleto, 2 sucios, borde)
- [x] 3. Dry run — compuerta por entorno activa; nodo del CRM sin ejecutar en dev (captura adjunta)
- [x] 4. Datos fijados — entradas fijadas en el Webhook; dos corridas partieron de la misma entrada
- [x] 5. Agente a costo cero — iterado en llama3.2 local; validado 1 pasada contra el modelo vigente en staging
- [x] 6. Aserciones — Categorization sobre los 6 casos: 6/6 en 1; críticos al 100%
- [x] 7. Pase completo a costo cero — corrió entero sin escrituras reales ni cargos de LLM

## Veredicto: PASS

## Evidencia
- test/evidence/2026-07-run-eval.png (tabla de resultados de la evaluación)
- test/fixtures/orders.json (los 6 casos con su expected)

Fíjate en el nivel de detalle de cada línea: no dice "hecho", dice qué se verificó y con qué resultado. Esa concreción es lo que separa una hoja de pre-vuelo firmada de un "sí, ya probé". Ahora vamos a construir cada una de esas líneas, fase por fase.

La pasada completa, fase por fase

Un apunte sobre cómo trabajar este proyecto: no lo leas de corrido y lo des por hecho. Ábrelo con tu instancia de dev al lado y ejecuta cada fase sobre order-triage mientras avanzas. Si no tienes order-triage montado tal cual, hazlo sobre cualquier workflow tuyo que tenga al menos un efecto secundario (una escritura a algún lado) y, si puedes, un nodo de IA. El valor de este proyecto no está en entender las fases —eso ya lo hiciste en las lecciones— sino en correrlas de verdad una vez, porque la primera pasada real es donde descubres los detalles que la lectura esconde: que tu $env no estaba accesible, que un caso sucio rompía el parseo, que la compuerta tenía la condición al revés. Esos tropiezos son el aprendizaje; búscalos aquí, en sandbox, donde son gratis.

Fase 0 — Preparación

Antes de la primera verificación, ten a mano tres cosas del Módulo 4 y de las lecciones previas: tu instancia de dev corriendo (con el Starter Kit y Ollama), tu instancia de staging, y el repositorio cumbre-automations donde vive order-triage versionado. Anota en la plantilla el commit exacto que vas a probar —el identificador de la versión del workflow—, porque probar sin registrar qué versión probaste es como firmar una hoja de vuelo sin decir de qué avión. La pasada prueba una versión concreta, y esa versión tiene que quedar escrita.

Fase 1 — Llaves sandbox (lección 2)

Qué haces: confirmas que la credencial CRM API de tu instancia de dev apunta a la llave sandbox del CRM, no a la de producción. Corres la prueba de humo de la lección 2: una lectura de solo lectura que te devuelva los datos de utilería del CRM de prueba —"Café Prueba" y compañía—, no los clientes reales de Cumbre.

Qué esperar: la lectura devuelve datos de prueba. Verificas la marca de la llave (test/sandbox) y la URL base (sandbox-api...).

Evidencia: una captura de la credencial (con la llave tapada, claro) mostrando la URL sandbox, o del resultado de la lectura mostrando datos de utilería. Marcas la casilla 1.

Fase 2 — Datos sintéticos (lección 3)

Qué haces: preparas tu conjunto de pedidos sintéticos —los seis casos etiquetados que cubren la familia (feliz, grande, incompleto, dos sucios, borde)— en el archivo de fixtures test/fixtures/orders.json, y opcionalmente el generador de volumen para una tanda de cien. Confirmas que ningún dato corresponde a un cliente real.

Qué esperar: un archivo de fixtures versionado, con casos que incluyen a propósito lo difícil: el pedido de 52 000, el del nombre vacío, el del monto como texto, el de monto cero.

Evidencia: el propio archivo orders.json commiteado (queda en Git, es su propia evidencia). Marcas la casilla 2.

Fase 3 — Dry run: efectos protegidos (lección 4)

Qué haces: confirmas que order-triage tiene su compuerta por entorno —el IF que lee {{ $env.CUMBRE_ENV }} antes del nodo que escribe al CRM— y que en dev desvía el flujo al nodo que no escribe. Corres el caso large-order-manual-review y verificas que el nodo del CRM queda gris, sin ejecutar.

Qué esperar: el flujo se va por la rama de dry run, el nodo HTTP del CRM no se colorea, y ni el CRM sandbox ni el de producción reciben un registro nuevo. La corrida fue completa; la escritura, cero.

Evidencia: una captura del lienzo con el nodo del CRM sin ejecutar y la rama de dry run activa, o la salida del nodo Edit Fields con { "dry_run": true, ... }. Marcas la casilla 3.

Fase 4 — Datos fijados: reproducibilidad (lección 5)

Qué haces: fijas las entradas de tus casos —en el Webhook o en el nodo Code de entrada— para que la pasada sea reproducible. Corres el mismo caso dos veces y confirmas que la entrada fue idéntica las dos.

Qué esperar: el nodo de entrada muestra su pin, responde al instante sin esperar, y las dos corridas parten exactamente del mismo pedido. Recuerda: al exportar el workflow para versionar, normalizas y quitas el pinData (Módulo 3); los casos viven en el fixture, no en el pinData.

Evidencia: una captura del nodo de entrada con el pin activo, o una nota de que las dos corridas partieron de la misma entrada. Marcas la casilla 4.

Fase 5 — Agente a costo cero (lección 6)

Qué haces: dos movimientos. Primero, en dev, apuntas el AI Agent al modelo local de Ollama (llama3.2 o mistral) con temperatura baja, e iteras el prompt hasta que clasifique bien tus casos —gratis, cuantas veces necesites—. Segundo, en staging, haces una pasada de validación contra el modelo vigente de producción, para confirmar que la lógica se sostiene con la trufa y no solo con el champiñón.

Qué esperar: decenas de corridas en dev sin un cargo; una pasada de validación en staging con el modelo real que confirma (o corrige) lo afinado. Confirmas que el modelo de producción está vigente, no retirado.

Evidencia: una nota de qué modelo local usaste para iterar y contra qué modelo vigente validaste, más el resultado de la validación. Marcas la casilla 5.

Fase 6 — Aserciones: verificar la salida (lección 7)

Qué haces: montas la evaluación —con el nodo Evaluation y la métrica Categorization, o con el patrón manual de IF + Code si tu versión no lo trae— comparando la clasificación del agente contra la columna expected de cada caso. Defines los umbrales: 100% en los casos críticos (el pedido grande, el incompleto), agregado alto (p. ej. 90%) en los normales.

Qué esperar: una tabla de resultados, un caso por fila, con 1 donde el agente acertó y 0 donde falló, más un agregado y un veredicto. Si algún caso falla —el agente clasificó distinto de lo esperado—, lo ves aquí, sin haber leído una salida a ojo.

Evidencia: la tabla de resultados de la evaluación (o la salida del nodo Code con el veredicto), incluidos los casos que fallaron y cómo los corregiste. Marcas la casilla 6.

Fase 7 — El pase completo y su evidencia (síntesis)

Qué haces: corres la pasada entera, encadenada: el disparador recorre los casos, el agente (local, gratis) clasifica, la compuerta protege los efectos, la evaluación califica contra las respuestas esperadas, y obtienes un veredicto global. Confirmas que toda la pasada corrió a costo cero —modelo local, sin escrituras reales— y reproducible.

Qué esperar: un veredicto PASS si todos los críticos pasaron y el agregado superó su umbral; FAIL si no, con los casos culpables señalados. Un FAIL no es un fracaso del proyecto: es el sistema haciendo su trabajo —atrapó un problema antes de producción—. Corriges, vuelves a correr (gratis, porque es a costo cero), y repites hasta PASS.

Evidencia: llenas el pre-production-checklist.md con el veredicto, adjuntas las evidencias de cada fase, y lo commiteas en cumbre-automations. Ese commit es tu firma en la hoja de pre-vuelo. Marcas la casilla 7.

Una pasada que falla, y cómo se lee

Vale la pena caminar una pasada que no sale verde a la primera, porque es lo que va a pasarte en la vida real, y saber leerlo es medio módulo.

Corres la pasada completa sobre order-triage. El disparador recorre los seis casos, el agente (local, gratis) clasifica cada uno, la evaluación califica. Y el veredicto llega: FAIL. La tabla de resultados dice:

case	expected	agente respondió	Categorization
happy-path-approve	approved	approved	1
large-order-manual-review	manual_review	manual_review	1
missing-customer-name	missing_info	missing_info	1
dirty-amount-as-string	approved	missing_info	0
dirty-whitespace-and-case	approved	approved	1
edge-zero-amount	missing_info	missing_info	1

Cinco de seis en 1, uno en 0. El culpable es dirty-amount-as-string: el pedido de 3 500 pesos con el monto escrito como texto "3,500.00". Esperabas approved —es un pedido normal de 3 500—, pero el agente lo mandó a missing_info. Qué esperar leer de esto: el agente se confundió con el formato del monto; probablemente interpretó "3,500.00" como un dato roto o incompleto en vez de como tres mil quinientos.

Ahora viene lo importante: qué haces con ese 0. No bajas el umbral. Investigas por qué el agente se confundió y decides el arreglo correcto, que aquí puede ser de dos naturalezas:

• Arreglar el prompt para que el agente entienda montos con separadores de miles como texto. Ajustas, y como iterar en Ollama es gratis (Fase 5), vuelves a correr sin costo hasta que el caso pase.
• Arreglar el workflow para que limpie el monto —convertir "3,500.00" a 3500— antes de que llegue al agente, con un nodo Code de normalización. Quizás el agente no debería tener que lidiar con datos sucios; quizás eso es trabajo de un paso previo.

Cuál de los dos es "el correcto" depende de tu diseño, y esa decisión es justamente el valor de haber encontrado el fallo en sandbox: lo estás resolviendo con calma, gratis, sobre un dato sintético, y no a las tres de la mañana con un pedido real de 3 500 pesos atorado en missing_info en producción. Corriges, vuelves a correr la pasada entera (a costo cero), y esta vez el dirty-amount-as-string sale en 1. Veredicto: PASS. Ahora sí.

Fíjate en lo que acaba de pasar: el checklist hizo exactamente su trabajo. Atrapó un caso sucio realista que el "corrió una vez y salió bien" de la lección 1 jamás habría visto —porque ese caso feliz nunca incluyó un monto mal formateado—. El FAIL no fue un problema del proyecto; fue el proyecto funcionando.

Cuándo corres la pasada: completa contra de humo

No toda modificación merece la pasada completa de siete fases, y fingir que sí lleva a que nadie la corra. Conviene calibrar el esfuerzo al cambio, con dos niveles.

La pasada completa —las siete fases— se corre cuando el cambio es de fondo: tocaste la lógica del agente, cambiaste el prompt de clasificación, agregaste un efecto secundario nuevo, o vas a promover a producción. Cualquier cosa que pueda alterar qué decide el workflow pide la pasada entera, porque es justo lo que las aserciones verifican.

Una prueba de humo (smoke test) —un subconjunto rápido— se corre para cambios menores que casi seguro no tocan el comportamiento: renombraste un nodo, ajustaste un comentario, moviste algo en el lienzo. Una prueba de humo corre solo los casos críticos —el pedido grande, el incompleto— para confirmar en treinta segundos que "no se prendió fuego nada obvio", sin la ceremonia completa. El nombre viene de la electrónica: enciendes el aparato y ves si sale humo; si no, al menos lo básico funciona.

La regla de calibración: ante la duda, pasada completa. La prueba de humo es para cuando estás seguro de que el cambio no toca el comportamiento; si tienes que preguntarte "¿esto podría cambiar cómo clasifica?", la respuesta ya es correr la completa. Y antes de promover a producción, siempre la completa, sin excepción —ahí no hay cambios "menores", porque cruzar a producción es en sí el evento mayor—. Esta calibración es la que hace el checklist sostenible: si cada coma exigiera siete fases, lo abandonarías en una semana; si nada las exige, no pruebas. El punto medio es lo que lo vuelve un hábito real.

Una nota que abre el Módulo 6: esta pasada, que aquí corres a mano, es candidata a automatizarse. Un check de CI —integración continua— puede correr al menos las verificaciones más mecánicas (que el JSON sea válido, que la estructura esté bien) en cada commit, sin que tú las dispares. Eso es tema del módulo que sigue; por ahora, correrla a mano te enseña qué es lo que después vas a automatizar.

Dónde vive la evidencia (y por qué en el repo)

Toda la evidencia —el checklist lleno, las capturas, la tabla de resultados, el fixture de casos— vive dentro del repositorio cumbre-automations, no en tu carpeta de Descargas ni en tu cabeza. Una estructura razonable:

cumbre-automations/
├── workflows/
│   └── order-triage.json          # normalizado, sin pinData (Módulo 3)
├── test/
│   ├── fixtures/
│   │   └── orders.json            # los casos sintéticos con su expected
│   └── evidence/
│       └── 2026-07-run.png        # capturas de la pasada
└── docs/
    └── pre-production-checklist.md # la hoja de pre-vuelo, llena y firmada

Que la evidencia viva en Git tiene tres consecuencias que la hacen valiosa de verdad, no burocracia. Queda versionada: la pasada de hoy y la de dentro de un mes conviven en la historia; puedes ver cómo evolucionó la prueba. Es reproducible por otro: cualquiera del equipo clona el repo, lee el checklist, corre los mismos casos del fixture, y obtiene el mismo veredicto —la prueba no depende de ti—. Y es un artefacto de portafolio: en una entrevista, en vez de decir "yo pruebo bien", abres el repo y muestras la hoja de pre-vuelo firmada de un workflow real. Lo segundo pesa infinitamente más que lo primero.

Esta es la razón profunda por la que el checklist es un archivo y no una costumbre: una costumbre no se puede mostrar, ni versionar, ni entregar. Un archivo sí. El día que dejes Cumbre, la siguiente persona abre pre-production-checklist.md y sabe exactamente cómo se prueba order-triage antes de tocarlo. Eso es ser dueño del sistema: dejar el sistema operable por otro.

Una honestidad sobre la evidencia: no toda evidencia envejece igual de bien. Una captura de pantalla es útil el día que la tomas, pero se vuelve vieja —cambia la interfaz, cambian los datos— y nadie puede "re-verificarla". La evidencia más valiosa no es la que muestra el resultado, sino la que permite reproducirlo: el archivo de fixtures con los casos y sus expected, y una nota de cómo correr la evaluación. Con eso, otro no tiene que creerle a tu captura; corre la prueba y obtiene su propio veredicto. Prefiere siempre la evidencia reproducible (el fixture, el procedimiento) sobre la evidencia estática (la captura); la captura acompaña, el fixture prueba. Es el mismo principio de "reproducible" de la lección 5, aplicado ahora a cómo guardas la prueba de que probaste.

Errores comunes

Marcar una casilla sin la evidencia (conceptual, vacía el ejercicio). Qué pasa: alguien recorre el checklist marcando casillas de memoria —"sí, corrí contra sandbox, marco"— sin adjuntar la prueba. El checklist queda lleno pero hueco: nadie, ni el mismo autor en un mes, puede confirmar que la verificación de verdad ocurrió. Por qué pasa: marcar es rápido; capturar la evidencia toma un minuto más. Cómo detectarlo: si una casilla marcada no tiene al lado una captura, una tabla o un archivo que la respalde, es una casilla de fe, no de prueba. Cómo corregirlo: la regla del piloto —no firmas un punto que no verificaste con el instrumento a la vista—. Cada casilla marcada lleva su evidencia adjunta; sin evidencia, la casilla queda sin marcar.

Probar una versión y promover otra (práctico y peligroso). Qué pasa: alguien corre la pasada completa, obtiene PASS, y después le hace "un ajuste chiquito de último momento" al workflow antes de promover, sin volver a probar. Promovió una versión que nunca pasó el checklist. Por qué pasa: el ajuste parece inofensivo, y volver a correr la pasada da pereza. Cómo detectarlo: compara el commit que anotaste en la plantilla con el commit que promueves; si no son el mismo, probaste una cosa y promueves otra. Cómo corregirlo: la pasada prueba una versión exacta, identificada por su commit. Cualquier cambio después de la pasada —por chico que sea— invalida el veredicto y exige correrla de nuevo. Como es a costo cero y reproducible, volver a correrla es barato; hazlo.

Tratar un FAIL como un fracaso en vez de como el éxito del sistema (conceptual). Qué pasa: la pasada da FAIL, y alguien se frustra o —peor— baja el umbral para que dé PASS. Por qué pasa: un FAIL se siente como que algo salió mal. Cómo detectarlo: si tu reacción a un FAIL es ajustar el umbral en vez de arreglar el workflow, estás disparándole al mensajero. Cómo corregirlo: un FAIL es exactamente lo que el checklist debe producir cuando hay un problema —atrapó un fallo antes de producción, que es el objetivo entero del módulo—. Celebra el FAIL: te ahorró un incidente. Arregla el workflow, no el umbral, y vuelve a correr. Bajar el umbral para que pase es como taparle la boca a la alarma de incendios: silencia el aviso, no apaga el fuego.

Ejercicios

Ejercicio 1 — Ordena la pasada. Sin mirar, escribe las siete fases de la pasada completa en el orden correcto, y para cada una, la lección de la que viene. Después justifica por qué las llaves sandbox van antes que las aserciones.

Ver solución

El orden: (1) llaves sandbox (lección 2), (2) datos sintéticos (3), (3) dry run / efectos protegidos (4), (4) datos fijados / reproducibilidad (5), (5) agente a costo cero (6), (6) aserciones (7), (7) pase completo con evidencia (síntesis).

Por qué las llaves sandbox van antes que las aserciones: el orden va de preparar el entorno seguro a verificar el resultado. No tiene sentido verificar la salida (aserciones) si todavía puedes estar tocando producción: primero te aseguras de que nada de lo que corras tenga consecuencias reales (sandbox, datos sintéticos, dry run), después lo vuelves reproducible (datos fijados), después lo haces barato (agente local), y solo al final verificas que la salida es correcta. Verificar primero y proteger después sería revisar la puntería después de haber disparado.

Por qué funciona: el orden no es una lista arbitraria; es la secuencia lógica de "hazlo seguro → hazlo repetible → hazlo barato → verifica que acierta". Si te lo sabes en orden, te sabes el módulo.

Ejercicio 2 — Ejecuta una fase de verdad. Toma la Fase 6 (aserciones) y ejecútala sobre order-triage (o sobre un workflow tuyo con un nodo AI Agent). Arma al menos tres casos con su expected, corre la evaluación —con el nodo Evaluation o el patrón manual—, y escribe el veredicto con su evidencia. Si no tienes order-triage montado, descríbelo en detalle: qué tres casos, qué métrica, qué umbral, qué evidencia guardarías.

Ver solución

No hay una respuesta única, pero una buena ejecución tiene estas piezas: tres casos que cubran distinto —uno feliz (approved), uno crítico (manual_review para el pedido grande), uno incompleto (missing_info)—; la métrica Categorization (coincidencia exacta contra expected); umbrales 100% en el crítico, agregado alto en el resto; y como evidencia, la tabla de resultados con el 1/0 de cada caso y el veredicto.

Si un caso falla, la ejecución correcta no es bajar el umbral: es leer por qué el agente clasificó distinto —¿el prompt es ambiguo?, ¿el modelo local difiere del de producción?— corregirlo, y volver a correr (gratis).

Por qué funciona: ejecutar una fase de verdad, aunque sea una, convierte el módulo de teoría en un músculo. La Fase 6 es la más rica porque junta datos (los casos), IA (el agente) y verificación (la métrica); si la puedes correr sola, puedes correr la pasada entera.

Ejercicio 3 — Defiéndelo en una entrevista. Un entrevistador te pregunta: "¿cómo pruebas un workflow que le escribe al CRM real y usa un agente de IA, sin arriesgar producción ni gastar de más?". Responde en un párrafo, como lo harías en la entrevista, usando el vocabulario del módulo.

Ver solución

Una respuesta sólida suena así: "Lo pruebo en un sandbox aislado —mi entorno de dev— antes de tocar producción. Conecto el nodo del CRM a una llave sandbox, así ninguna escritura pega en el CRM real; y para los casos donde ni el sandbox debe tocarse, tengo una compuerta por entorno que corta el efecto en un dry run. Pruebo con datos sintéticos que cubren casos borde y datos sucios, no con datos reales de clientes, por privacidad. Fijo esas entradas para que la prueba sea reproducible. El agente lo pruebo contra un modelo local de Ollama para iterar a costo cero, y valido una vez contra el modelo vigente de producción antes de promover. Y no me quedo en 'corrió': escribo aserciones con el nodo Evaluation que comparan la clasificación del agente contra la respuesta esperada de cada caso, con un umbral de aprobación. Todo queda como un checklist ejecutado con evidencia en el repositorio, versionado, que cualquiera del equipo puede correr y reproducir."

Por qué funciona: esa respuesta usa, en orden, las siete técnicas del módulo con su nombre de mercado, y cierra con el entregable. Un entrevistador que pide "test in a sandbox" reconoce cada pieza. La diferencia con un candidato que "sabe construir workflows" es exactamente ese párrafo: no describe cómo arma un flujo, describe cómo lo prueba y entrega como un dueño del sistema.

Resumen y siguiente paso

En este proyecto ejecutaste la pasada de prueba completa sobre order-triage: las siete verificaciones del checklist encadenadas —llaves sandbox, datos sintéticos, dry run, datos fijados, agente a costo cero, aserciones y el pase completo— a costo cero y de forma reproducible. Produjiste el entregable que le da sentido al módulo: el pre-production-checklist.md lleno y firmado con un commit, con su evidencia versionada en cumbre-automations —tu hoja de pre-vuelo de order-triage—. Y viste por qué ese artefacto importa: queda versionado, lo puede reproducir otro, y es lo que muestras en una entrevista en lugar de solo afirmar que pruebas bien. Grabaste los tres errores que lo vacían —marcar sin evidencia, probar una versión y promover otra, tratar un FAIL como fracaso en vez de como el éxito del sistema—.

Con esto marcas el séptimo y último punto del checklist, y completas la capacidad de salida del módulo: probar por completo un workflow en un sandbox, sin tocar producción ni quemar presupuesto, dejando un checklist repetible con su evidencia versionada.

Antes de pasar al Módulo 6 deberías poder: recitar las siete fases en orden con su lección; ejecutar al menos una fase de verdad sobre un workflow; defender tu proceso de prueba en un párrafo con el vocabulario del mercado; y explicar por qué la evidencia reproducible (el fixture) vale más que la estática (la captura).

Lo que sigue cierra el ciclo de entrega. Tienes order-triage versionado (Módulos 2 y 3), en entornos aislados (Módulo 4) y ahora probado con evidencia (este módulo). El Módulo 6 te enseña a promover ese cambio probado de staging a prod de forma controlada, a revisar los cambios como diffs —incluida la parte de IA—, a construir un runbook de rollback para volver atrás en minutos si algo falla, y a cerrar con un check de CI que valida el JSON en cada commit. La pasada verde que produjiste aquí es, precisamente, la luz verde que el Módulo 6 necesita para cruzar la última línea: de "probado" a "en producción, con red de seguridad".

Recursos

• Test and improve AI workflows — n8n Docs — la sección que reúne evaluación, datasets y métricas; el marco de la Fase 6.
• Data mocking and pinning — n8n Docs — fijar datos para la reproducibilidad de la Fase 4.
• Self-hosted AI Starter Kit — n8n Docs — el entorno con Ollama que hace la Fase 5 a costo cero.
• Manual, partial, and production executions — n8n Docs — las ejecuciones manuales sobre las que corre toda la pasada (recuerda: el pin no aplica en producción).
• Source control and environments — n8n Docs — el marco de entornos y versionado donde vive el checklist; puente al Módulo 6 de promoción.