5. Datos fijados y replay de ejecución

Descripción

Al terminar esta lección vas a poder hacer que una prueba de order-triage sea reproducible: correrla hoy, mañana y después de un cambio, siempre con exactamente las mismas entradas, para que cualquier diferencia en el resultado la puedas atribuir al cambio y no al azar. Vas a saber usar los datos fijados (pin data) para congelar la salida de un nodo, con sus límites bien marcados; y vas a usar el motor de depuración de n8n —"Debug in editor" y "Copy to editor"— para tomar una ejecución pasada y volver a correrla en el editor, no para apagar un incendio en producción, sino como una herramienta de prueba repetible.

Esto importa porque la reproducibilidad es la cuarta propiedad de una prueba de verdad (lección 1), y es la que convierte tus datos sintéticos (lección 3) de "un dato que armé una vez" en "un caso de prueba que corro cuando quiera, idéntico". Sin entradas fijas, cada corrida es un experimento distinto: cambias el workflow, corres, ves un resultado distinto, y no sabes si cambió por tu ajuste o porque la entrada era otra. Con entradas fijas, aíslas la variable —el workflow— y la prueba empieza a decir la verdad.

Conexión con el módulo: en la lección 3 diseñaste los datos sintéticos; esta lección los congela para que la prueba se repita idéntica. Es el cuarto punto del checklist. Se conecta hacia atrás con el Módulo 3: vas a ver que los datos fijados son justo el campo pinData que aprendiste a borrar al normalizar el JSON, y esa tensión —útil para probar, ruido para versionar— hay que resolverla con criterio. Y se conecta hacia adelante con las lecciones 6 y 7: fijar la salida del agente de IA es lo que vuelve deterministas sus pruebas, y unas entradas fijas son la base para escribir aserciones estables.

El fotograma congelado y la caja negra

Piensa en un fotógrafo de comida que quiere perfeccionar la iluminación de un platillo. Si usa un plato de comida real, tiene un problema: la comida cambia entre foto y foto —el helado se derrite, la ensalada se marchita, el vapor se disipa—. Cuando ajusta una luz y saca otra foto, no sabe si la diferencia vino de la luz o de que el platillo ya no es el mismo. Así que los estudios profesionales usan comida falsa de utilería: un plato de resina que se ve idéntico pero no cambia nunca. Ahora, cuando el fotógrafo ajusta la luz y compara, sabe que lo único que cambió fue la luz, porque el platillo es exactamente el mismo en las dos fotos. Congeló la variable que no quería que se moviera.

Fijar datos (pin data) es poner comida de utilería en tu workflow. Tomas la salida de un nodo y la congelas: le dices a n8n "de ahora en adelante, en cada corrida manual, no ejecutes este nodo; usa exactamente estos datos que estoy congelando". El nodo Webhook que normalmente esperaría un pedido nuevo pasa a devolver siempre el mismo pedido sintético congelado. Ahora, cuando cambias la lógica del agente y vuelves a correr, sabes que la entrada fue idéntica —el mismo pedido, byte por byte— así que cualquier diferencia en la clasificación vino de tu cambio, no de un dato distinto. Congelaste la variable que no querías que se moviera.

Definamos el término con precisión. Un dato fijado (pinned data) es la salida de un nodo que n8n guarda y reutiliza en las corridas manuales, en lugar de volver a ejecutar el nodo para obtenerla. "Fijar" (pin) es la palabra de n8n para "clavar en su lugar", como clavas una nota en un corcho para que no se mueva mientras todo alrededor cambia. Mientras un dato está fijado, el nodo no se ejecuta: n8n sustituye su salida por lo congelado y sigue el flujo.

Fíjate en el beneficio doble. Reproducibilidad: la misma entrada siempre, para poder comparar. Y ahorro: si el nodo fijado era uno que llamaba a una API con cuota o con costo —el CRM, o el modelo de lenguaje del agente—, fijar su salida significa que ya no lo llamas en cada prueba. Congelas una respuesta buena una vez y pruebas cien veces contra ella, sin gastar cuota ni dinero. Esto conecta directo con el dry run de la lección 4 y con el costo cero de la lección 6: fijar datos es también una forma de no quemar presupuesto probando.

Ejemplo trabajado: fijar un pedido de prueba en el Webhook

Veámoslo con order-triage. Quieres probar el caso large-order-manual-review una y otra vez mientras ajustas el prompt del agente, sin tener que mandar el pedido por HTTP cada vez.

Paso 1 — Consigue el dato una vez. Mandas el pedido sintético al Webhook una primera vez (a mano, o con el generador de la lección 3), de modo que el nodo Webhook produzca su salida: el pedido de 52 000 pesos.

Paso 2 — Fíjalo. En la vista de salida (OUTPUT) del nodo Webhook, presionas el ícono de fijar (el pin). n8n congela esa salida y te muestra un aviso (un banner) indicando que el nodo tiene datos fijados. A partir de ahora, ese pin es visible en el nodo dentro del lienzo.

Paso 3 — Corre cuantas veces quieras. Ejecutas el workflow. El Webhook no espera ningún pedido nuevo: devuelve al instante el pedido de 52 000 congelado, y el flujo sigue hacia el agente. Cambias el prompt del agente, corres de nuevo: otra vez el mismo pedido exacto. Ajustas algo más, corres: idéntico. La entrada nunca se movió.

Qué esperar: cada corrida usa exactamente el mismo pedido, así que si la clasificación cambia entre una corrida y otra, sabes con certeza que fue por tu cambio en el agente, no por una entrada distinta. Ves el pin en el nodo Webhook, ves el banner de "datos fijados", y ves que el Webhook responde al instante sin esperar. Esa inmediatez es la señal de que está usando lo congelado y no ejecutándose de verdad.

Para cambiar el dato fijado: en la vista JSON de la salida hay un botón Edit que te deja editar los datos congelados a mano —perfecto para probar un caso borde: fijas un pedido, le cambias el monto a mano a 0, y ya tienes el caso edge-zero-amount sin volver a mandar nada—. Para descongelar: el banner tiene un enlace para quitar el pin (unpin); al quitarlo, la próxima corrida vuelve a ejecutar el nodo de verdad.

Ese botón Edit es más útil de lo que parece a primera vista, y vale la pena detenerse un segundo en él. Te deja generar toda una familia de casos borde a partir de un solo dato bueno, sin volver a la fuente. Fijas un pedido normal una vez; después lo duplicas mentalmente y editas: en una copia le vacías el nombre (missing-customer-name), en otra le pones el monto como texto con comas (dirty-amount-as-string), en otra lo dejas en cero (edge-zero-amount). Cada edición te da un caso nuevo, congelado y listo para correr, sin depender de que el sistema de origen te mande justo ese pedido raro. Es la forma más rápida de convertir un caso feliz en la familia de maniquíes de la lección 3, directamente en el editor.

Fijar contra simular: dos primos que se confunden

La documentación de n8n agrupa dos técnicas bajo el mismo techo —"data mocking and pinning"—, y como se parecen, conviene separarlas para no confundirlas.

Simular (mock) es generar datos de prueba que nunca existieron: es exactamente lo que hiciste en la lección 3 con el nodo Code y el dataset fijo. Inventas un pedido desde cero. La fuente del dato eres tú.

Fijar (pin) es congelar la salida real de un nodo que sí se ejecutó al menos una vez: el Webhook recibió un pedido, y tú clavas esa salida para reusarla. La fuente del dato fue una ejecución real.

La diferencia en una frase: simular inventa el dato; fijar congela un dato que ocurrió. Y se complementan de maravilla. Un patrón muy común es simular con un nodo Code —generas el pedido sintético— y luego fijar la salida de ese Code, para que el pedido inventado quede congelado y no se regenere en cada corrida. Simulas una vez, fijas el resultado, y ya tienes una entrada inventada y reproducible. Es lo mejor de las lecciones 3 y 5 juntas: el dato lo controlas tú (mock) y no cambia entre corridas (pin).

Los límites de los datos fijados (léelos con cuidado)

Los datos fijados son potentes, pero tienen límites duros que n8n documenta, y saltárselos lleva a confusiones feas. Estos son, confirmados en la documentación oficial —de todos modos, verifícalos en tu versión, porque el detalle fino puede cambiar entre versiones—:

No funcionan en producción. Este es el más importante. Las ejecuciones de producción ignoran por completo los datos fijados. El pin solo actúa en ejecuciones manuales, las que disparas desde el editor. Esto es una salvaguarda deliberada de n8n: sería un desastre que un workflow activo en producción respondiera con un pedido de prueba congelado en vez de con los pedidos reales. Así que puedes fijar datos con tranquilidad para probar; nunca van a "contaminar" la producción. Pero también significa que fijar datos es una técnica solo de prueba, no de operación.

Solo en nodos de una sola salida principal. Puedes fijar la salida de un nodo que tiene una salida principal. Los nodos con varias salidas —un IF tiene dos, true y false— no se pueden fijar (las salidas de error no cuentan para este límite). Por eso el lugar natural para fijar en order-triage es el Webhook o un nodo Code de entrada: tienen una sola salida.

No funcionan con datos binarios. Si la salida del nodo incluye datos binarios —un archivo, una imagen, un PDF—, no se puede fijar. Los datos fijados son para datos JSON, como un pedido. Para order-triage esto no estorba, porque los pedidos son JSON; pero tenlo presente si algún día pruebas un workflow que mueve archivos.

Se guardan con el workflow. Los datos fijados se guardan dentro del workflow, en el campo pinData de su JSON. Esto tiene una consecuencia grande que conecta con el Módulo 3, y merece su propia sección.

La tensión con la normalización del Módulo 3

Aquí hay un cruce importante entre esta lección y lo que aprendiste en el Módulo 3, y conviene resolverlo con criterio en vez de tropezar con él.

¿Recuerdas la lección 4 del Módulo 3, donde normalizabas el JSON para diffs limpios? El primer campo que borrabas con del(.pinData, ...) era, justamente, pinData. Lo clasificamos como volátil: ruido que ensucia el diff, porque cambia según con qué estés probando y no describe la lógica del workflow. Y ahora, en esta lección, pinData es una herramienta de prueba valiosa. ¿Contradicción?

No, es una tensión de diseño, y tiene una resolución limpia una vez que la ves. Los datos fijados son valiosos mientras pruebas, en tu editor. Pero no quieres que viajen en el JSON versionado que promueves a producción, por dos razones: son ruido en el diff (Módulo 3) y, además, en producción se ignoran de todos modos (límite de arriba), así que no aportan nada al artefacto que promueves. La resolución:

• Fija datos libremente mientras iteras en tu instancia de dev. Vive en el editor, te sirve, perfecto.
• Al exportar y versionar, normaliza y quita pinData —exactamente como enseñó el Módulo 3—. El workflow que va a Git y a producción no lleva datos fijados.
• Guarda tus casos de prueba aparte, en el archivo de fixtures de la lección 3 (test/fixtures/orders.json), no dentro del pinData del workflow. Así los datos de prueba están versionados como datos, en su propio archivo, y el workflow queda limpio.

En otras palabras: pinData es tu área de trabajo temporal para probar, no tu almacén de casos de prueba. El almacén de casos es el archivo de fixtures. Cuando quieras re-fijar un caso, lo tomas del fixture y lo fijas en el editor; cuando exportas, el fixture se queda en su archivo y el pinData se va en la normalización. Cada dato en su lugar: los de trabajo en el pin, los versionados en el fixture.

Esta es una de esas decisiones que separan a quien "usa pin data porque es cómodo" de quien entiende cómo encaja en un repositorio profesional. Si fijas un montón de datos y los commiteas dentro del workflow, ensucias el repo y arrastras ruido a producción. Si los mantienes como fixtures y usas el pin solo como área de trabajo, tienes lo mejor de los dos: pruebas cómodas y un repo limpio.

El replay de ejecución: repetir una corrida pasada

La segunda herramienta de esta lección es el replay (repetición) de una ejecución. La idea: tomar una ejecución que ya ocurrió —con sus datos exactos— y volver a cargarla en el editor para correrla otra vez.

Piénsalo como la caja negra de un avión. Después de un vuelo, la caja negra guarda todo lo que pasó: cada dato, cada lectura. Los investigadores pueden cargar esa grabación en un simulador y "re-volar" el vuelo exacto, con los mismos datos, cuantas veces necesiten, para entender qué pasó o para probar un cambio. n8n guarda una "caja negra" de cada ejecución —qué datos entraron, qué produjo cada nodo— y te deja cargarla de vuelta en el editor.

n8n tiene dos puertas a esto, según cómo terminó la ejecución que quieres repetir:

• "Copy to editor" (copiar al editor), para ejecuciones exitosas. Tomas una corrida que salió bien —por ejemplo, una donde order-triage clasificó un pedido y todo funcionó— y la copias al editor.
• "Debug in editor" (depurar en el editor), para ejecuciones fallidas. Tomas una corrida que falló y la cargas al editor para investigar y arreglar.

En ambos casos, n8n copia los datos de la ejecución a tu workflow actual y los fija (pin) en el primer nodo del workflow. Fíjate en lo elegante: el replay usa los datos fijados por debajo. Cargar una ejecución pasada es, en el fondo, fijar automáticamente en el nodo de entrada los datos exactos que tuvo esa corrida. Es pin data hecho por ti, a partir de una corrida real, en un clic.

Verifica la disponibilidad. Según la documentación, estas funciones de depuración y replay están disponibles en n8n Cloud y en los planes Community registrados (el registro gratuito de la edición Community). Si en tu instancia no ves "Debug in editor" o "Copy to editor" en la lista de ejecuciones, revisa que tu Community esté registrada. Verifica también el nombre exacto de los botones en tu versión: la interfaz cambia, y esta guía se escribió en 2026.

El replay como herramienta de PRUEBA, no de incidentes

Aquí una distinción que la guía cuida a propósito. El replay nació para diagnóstico de incidentes: una ejecución de producción falló, la cargas con "Debug in editor", ves con qué datos falló, arreglas el workflow y la re-corres. Ese uso —investigar un fallo real en producción— no es de este módulo; vive en la guía de mantenimiento en producción, porque es diagnóstico en caliente de algo que ya salió mal en vivo.

En este módulo usamos el mismo motor para algo distinto y en frío: construir un caso de prueba repetible a partir de una corrida buena. El flujo es este:

1. Corres order-triage en dev con un pedido sintético que salió como esperabas.
2. Con "Copy to editor", cargas esa ejecución exitosa al editor. n8n fija sus datos en el nodo de entrada.
3. Ahora tienes ese caso "clavado". Cada vez que cambies el workflow, lo corres contra esos datos fijados y comparas.

La diferencia es la intención: el mantenimiento usa el replay para entender por qué se rompió algo en producción; nosotros lo usamos para capturar una corrida buena y volverla un caso de prueba reproducible. Mismo botón, propósito opuesto. Guardar esta distinción te evita mezclar la prueba en frío (este módulo) con el diagnóstico en caliente (la otra guía).

Hay un cuidado de privacidad que conviene marcar aquí, porque conecta con la lección 3. El replay captura los datos exactos de la ejecución que copias —si copias una corrida que usó datos reales, esos datos reales quedan fijados en tu editor y, si exportas sin normalizar, en el JSON—. Por eso, cuando uses "Copy to editor" para armar un caso de prueba, hazlo sobre corridas que usaron datos sintéticos, no sobre corridas reales de producción. Y si alguna vez cargas una corrida real para diagnosticar (uso de la otra guía), recuerda quitar ese pinData antes de versionar, para no filtrar información de un cliente al repositorio. El replay es cómodo justamente porque fija todo; esa misma comodidad es la que puede colarte datos reales donde no deben estar.

Una nota sobre el trazado línea por línea

Las versiones recientes del motor de depuración de n8n (2026) han ido sumando capacidades para inspeccionar una ejecución con más detalle —por ejemplo, seguir cómo cambian los datos a lo largo del flujo, y en algunos casos observar el comportamiento dentro de nodos de código—. Como estas capacidades evolucionan rápido y su forma exacta depende de tu versión, no voy a describir campos ni botones específicos que quizás no existan en tu instalación. Verifica en el panel de tu versión y en la doc oficial qué ofrece tu motor de depuración para inspeccionar una ejecución paso a paso. El principio que sí es estable y que te llevas de aquí: n8n guarda los datos de cada ejecución, y puedes recargarlos para observarlos y repetirlos. Los detalles de la interfaz, confírmalos tú; no te fíes de una captura de pantalla de hace seis meses.

Reproducibilidad de toda la cadena: dónde el azar se cuela

Fijar la entrada resuelve la mitad de la reproducibilidad. Pero hay una fuente de variación que el pin del Webhook no toca, y conviene verla ahora porque es el puente a la lección 6: el nodo AI Agent no es determinista por naturaleza.

Piénsalo así. Fijas el pedido de entrada, perfecto: la misma entrada siempre. El flujo llega al agente, que le manda ese pedido a un modelo de lenguaje. Y aquí está el asunto: un modelo de lenguaje puede dar respuestas distintas a la misma entrada. Le mandas el mismo pedido dos veces y una vez lo clasifica "revisión manual" y otra "aprobado", sin que tú cambiaras nada. El azar no estaba en la entrada —esa la fijaste—; estaba dentro del modelo. Congelaste la comida de utilería, pero el fotógrafo cambia de humor entre foto y foto.

Esto tiene dos remedios, y los dos viven en la lección 6, así que aquí solo los nombro para que veas el mapa:

• Fijar la salida del agente, no solo la entrada. Igual que fijas el Webhook, puedes fijar la salida del nodo AI Agent con una respuesta buena que capturaste. Así, mientras pruebas la lógica posterior al agente —la compuerta, el CRM—, el agente responde siempre lo mismo, porque su salida está congelada. Dejas de depender de su humor.
• Bajar la temperatura del modelo. Muchos modelos tienen un parámetro (temperatura) que controla cuánto azar meten; en cero, tienden a responder de forma más estable a la misma entrada. No lo vuelve perfectamente determinista, pero reduce la variación.

La consecuencia práctica para tus pruebas: decide qué estás probando y fija todo lo demás. Si pruebas la lógica posterior al agente, fija la salida del agente (y así ni siquiera llamas al modelo, ahorrando costo). Si pruebas al agente mismo —¿clasifica bien?—, entonces no puedes fijar su salida, porque es justo lo que quieres evaluar; ahí entra la lección 7 (aserciones sobre la salida del agente, tolerando su variación con un umbral). Fijar es congelar lo que no estás probando para aislar lo que sí. Qué congelas depende de qué preguntas.

Errores comunes

Fijar datos y creer que también aplican en producción (conceptual y peligroso al revés). Qué pasa: alguien fija un pedido de prueba en el Webhook, promueve el workflow, y teme —o espera— que producción responda con ese pedido congelado. Por qué pasa: no queda claro que el pin es solo para ejecuciones manuales. Cómo detectarlo: si crees que un dato fijado va a actuar en una ejecución de producción, tienes el modelo mental equivocado. Cómo corregirlo: recuerda el límite duro —producción ignora el pin data—. En un sentido es tranquilizador (no vas a contaminar prod con datos de prueba); en otro es un recordatorio de que fijar es una técnica de editor, no de operación. Y por eso mismo, al promover, el pinData sobra: no hace nada en prod y solo ensucia el JSON.

Commitear el workflow con pinData adentro (práctico). Qué pasa: alguien fija varios casos de prueba, exporta el workflow y lo commitea sin normalizar. Ahora el repo tiene un order-triage.json con un pinData gordo de datos de prueba, que ensucia cada diff y viaja a producción sin aportar nada. Por qué pasa: fijar es cómodo y es fácil olvidar que quedó guardado en el JSON. Cómo detectarlo: si al abrir tu order-triage.json exportado ves un campo pinData con datos, no lo normalizaste. Cómo corregirlo: aplica la normalización del Módulo 3 —del(.pinData, ...)— antes de commitear, y guarda tus casos de prueba en el archivo de fixtures, no en el pin. El pin es área de trabajo; el fixture es el almacén versionado.

Meter azar en el nodo fijado sin darse cuenta (conceptual). Qué pasa: alguien fija la salida de un nodo, pero el nodo anterior al fijado genera algo con azar, y como el fijado congela solo su propio nodo, cree que toda la prueba es reproducible cuando no lo es aguas arriba. Por qué pasa: se confunde "fijé un nodo" con "fijé toda la entrada". Cómo detectarlo: si algo antes del nodo fijado varía entre corridas, la reproducibilidad se rompe antes del pin. Cómo corregirlo: fija en el nodo de entrada —el Webhook o el primer Code— para que toda la cadena aguas abajo reciba lo mismo siempre. Fijar en medio del flujo solo congela de ahí para adelante; lo de antes sigue suelto.

Ejercicios

Ejercicio 1 — ¿Se puede fijar? Para cada nodo, di si puedes fijar su salida y por qué: (a) el Webhook de entrada de order-triage; (b) un nodo IF que separa pedidos grandes de chicos; (c) un nodo Code que devuelve un pedido en JSON; (d) un nodo que descarga un PDF de factura; (e) el nodo AI Agent que clasifica.

Ver solución

(a) Sí — el Webhook tiene una sola salida principal y produce JSON. Es el lugar ideal para fijar la entrada de la prueba. (b) No — un IF tiene dos salidas (true y false); los datos fijados solo funcionan en nodos de una sola salida principal. (c) Sí — un Code de una salida que devuelve JSON se puede fijar. (d) No — un PDF es dato binario, y no se puede fijar datos binarios. (e) Sí (normalmente) — el AI Agent tiene una salida principal y devuelve JSON/texto; fijar su salida es justo lo que la lección 6 va a aprovechar para pruebas deterministas.

Por qué funciona: las dos preguntas que deciden son "¿una sola salida principal?" y "¿es JSON, no binario?". El IF cae por lo primero, el PDF por lo segundo. El Webhook, el Code y el AI Agent pasan las dos, y por eso son los nodos donde vas a fijar en la práctica.

Ejercicio 2 — Resuelve la tensión con el repo. Un compañero fijó los seis casos de prueba en el Webhook y va a commitear el workflow así, "para que los casos queden guardados en Git". Explica por qué es mala idea y qué debería hacer en su lugar.

Ver solución

Es mala idea por tres razones. Una: el pinData con los seis casos ensucia cada diff del workflow —el Módulo 3 lo clasificó como volátil justo por esto—, así que cada vez que alguien toque la lógica, el diff va a mezclar el cambio real con el ruido de los datos fijados. Dos: ese pinData viaja a producción, donde se ignora por completo, así que no aporta nada al artefacto promovido: es peso muerto. Tres: guardar los casos dentro del workflow los ata a ese workflow, cuando en realidad son datos que quisieras poder reusar y versionar por separado.

Lo que debería hacer: guardar los seis casos en el archivo de fixtures (test/fixtures/orders.json), versionado como datos en su propio archivo (lección 3). Al exportar el workflow, normalizar y quitar el pinData (Módulo 3). Cuando quiera probar, toma un caso del fixture y lo fija en el editor como área de trabajo temporal. Así los casos quedan versionados —cumpliendo su intención— pero como datos, no metidos en el JSON del workflow.

Por qué funciona: separa el almacén de casos (el fixture, versionado) del área de trabajo (el pin, temporal). Es la misma disciplina de separar datos de lógica que atraviesa toda la guía.

Ejercicio 3 — Replay para capturar un caso. Describe, paso a paso, cómo usarías "Copy to editor" para convertir una corrida buena de order-triage en un caso de prueba reproducible, y en qué se diferencia esto de usar "Debug in editor" para un incidente de producción.

Ver solución

Para capturar un caso de prueba: (1) corres order-triage en dev con un pedido sintético que sale como esperabas —digamos, el grande que va a revisión manual—. (2) En la lista de ejecuciones, abres esa corrida exitosa y eliges "Copy to editor". (3) n8n copia los datos de esa ejecución al editor y los fija en el nodo de entrada. (4) Ahora tienes ese caso clavado: cada vez que cambies el workflow, lo corres contra esos datos fijados y comparas el resultado.

La diferencia con "Debug in editor" para un incidente: "Debug in editor" es para una ejecución fallida de producción, y el objetivo es diagnosticar —ver con qué datos reales se rompió, arreglar el workflow, re-correr—. Eso es diagnóstico en caliente de un incidente real, y vive en la guía de mantenimiento. "Copy to editor" en nuestro caso es para una corrida exitosa de prueba, y el objetivo es capturar un caso bueno y volverlo reproducible. Mismo motor de replay; uno diagnostica un fallo real, el otro captura una prueba.

Por qué funciona: los dos botones cargan una ejecución pasada fijando sus datos, pero la intención y el origen difieren —fallo real vs corrida de prueba, diagnóstico vs captura—. Tener clara esa frontera te evita mezclar el trabajo de este módulo (prueba en frío) con el de la guía de producción (incidentes en caliente).

Resumen y siguiente paso

En esta lección viste cómo volver reproducible una prueba. Los datos fijados (pin data) congelan la salida de un nodo —como la comida de utilería del fotógrafo— para que cada corrida manual use exactamente la misma entrada, aislando tu cambio en el workflow de cualquier variación en los datos; y de paso ahorran cuota y dinero, porque el nodo fijado ya no se llama. Grabaste sus límites duros: no funcionan en producción (solo en ejecuciones manuales), solo en nodos de una sola salida principal, no con datos binarios, y se guardan en el pinData del workflow —lo que crea una tensión con la normalización del Módulo 3 que se resuelve así: fija libre mientras iteras, pero guarda tus casos en un archivo de fixtures y quita el pinData al versionar—. Y viste el replay: "Copy to editor" (corridas exitosas) y "Debug in editor" (corridas fallidas) cargan una ejecución pasada fijando sus datos en el primer nodo, y los usamos como herramienta de captura de casos de prueba, no de diagnóstico de incidentes (eso es otra guía). Marcaste como "verificar en tu versión" los detalles finos del trazado paso a paso, porque evolucionan rápido.

Con esto marcas el cuarto punto del checklist: las entradas están fijadas para que la prueba sea reproducible. Y ganaste, de paso, dos cosas que no buscabas directamente pero que valen oro: pruebas que no vuelven a llamar a la fuente (ahorro de cuota y dinero) y una forma de capturar cualquier corrida buena como caso permanente.

Antes de avanzar deberías poder: explicar qué es fijar datos y su beneficio doble (reproducibilidad y ahorro); nombrar los cuatro límites del pin data; y resolver la tensión entre pinData como herramienta de prueba y como ruido a normalizar.

Ya tienes pruebas reproducibles. Ahora llega el caso especial que más duele en el bolsillo: el nodo AI Agent. Cada vez que pruebas order-triage, el agente llama a un modelo de lenguaje, y si ese modelo es de pago, cada corrida cuesta —justo cuando probar bien implica correr muchas veces—. La lección 6 resuelve esto: probar el agente contra un modelo local de Ollama (Llama 3, Mistral) del Starter Kit, a costo cero; cuándo sí conviene un modelo en la nube vigente; y cómo fijar prompts y salidas para pruebas deterministas del agente.

Recursos

• Data mocking and pinning — n8n Docs — la referencia oficial de los datos fijados: cómo fijar, editar y quitar el pin, y los límites (producción, una salida, sin binarios).
• Pin and mock data — n8n Docs — la guía de cómo fijar y simular datos, con el ícono de pin, el banner y el botón Edit de la vista JSON.
• Debug and re-run past executions — n8n Docs — "Debug in editor" y "Copy to editor", el replay que carga una ejecución pasada y la fija en el primer nodo; verifica ahí la disponibilidad por plan.
• View executions — n8n Docs — dónde encuentras la lista de ejecuciones desde la que disparas un replay.
• Módulo 3, lección 4 — "Normalizar el JSON para diffs limpios" (en esta misma guía): el del(.pinData, ...) que quita los datos fijados al versionar; repásalo para resolver la tensión entre el pin como herramienta de prueba y como ruido en el diff.