6. El modelo mental: workflow como código

Descripción

Al terminar esta lección vas a tener un solo modelo mental que ordena todo lo que viste hasta ahora: workflow como código. Vas a poder responder la pregunta que parece filosófica y es completamente práctica —¿cuál es el workflow "de verdad", el que está en el editor o el que está en el repositorio?—, vas a conocer el ciclo de trabajo completo (editar → exportar → commit → revisar → promover), y vas a entender por qué pensar en la instancia de n8n como un runtime y en el repositorio como el source resuelve de una sola vez el versionado, los entornos y la prueba.

Esto importa porque hasta aquí acumulaste cinco problemas —qué es versionar, por qué el mercado lo pide, por qué el export/import no basta, qué hay en el JSON, qué se rompe al moverlo— y todavía te falta el marco que los une. Un modelo mental no es un adorno: es lo que te permite tomar una decisión nueva, que no está en ninguna lección, y saber qué hacer. Cuando en un proyecto real te preguntes "¿dónde debería vivir esta configuración?" o "¿qué es lo que promuevo a producción?", la respuesta va a salir de este modelo, no de memorizar reglas sueltas.

Conexión con el módulo: esta es la lección que convierte cinco piezas en un sistema. Las lecciones 3, 4 y 5 fueron el diagnóstico del problema; esta es la reformulación que lo resuelve. Y es el puente hacia el resto de la guía: el ciclo que presento aquí es, literalmente, el esqueleto de los Módulos 2 a 6. "Exportar" y "commit" son los Módulos 2 y 3; "revisar" y "promover" son los Módulos 5 y 6; los entornos donde corre cada versión son el Módulo 4. La lección 7 pone el precio a cada parte de este modelo (qué es gratis, qué se paga), y el proyecto de la lección 8 te hace dar el primer paso del ciclo con order-triage.

El recetario y la cocina

Déjame proponerte una imagen que vamos a usar el resto de la guía, porque resuelve casi todas las confusiones de un solo golpe.

Piensa en una cadena de restaurantes con varias sucursales. En una oficina central hay un recetario maestro: un libro donde está escrita, con precisión, cada receta —cantidades, pasos, tiempos, el porqué de cada decisión—. Ese recetario es la verdad de la cadena. Es lo que define qué es cada plato.

En cada sucursal hay una cocina funcionando: cocineros, sartenes, el plato saliendo caliente. La cocina es donde la comida sucede. Pero la cocina no inventa los platos: los cocina siguiendo el recetario. Si un cocinero improvisa y cambia un plato sin actualizar el recetario, la cadena tiene un problema —esa sucursal ahora hace algo distinto de las demás, y nadie sabe por qué—.

Ahora la pregunta clave: si se incendia una cocina, ¿se perdió el plato? No. Se perdió una cocina. Abres otra, le das el recetario, y en una semana esa sucursal hace exactamente los mismos platos. Lo que la cadena no puede perder es el recetario. La cocina es reemplazable; el recetario, no.

Trasládalo a n8n:

• El recetario maestro es tu repositorio: el JSON de tus workflows, versionado, con la historia de cada cambio y su porqué. Es la verdad. Define qué es cada workflow.
• La cocina es tu instancia de n8n: donde los workflows corren, procesan pedidos de verdad, se ejecutan. Es donde la automatización sucede.
• El incendio es tu instancia que se corrompe, se borra, o hay que migrarla. Si tienes el recetario —el repositorio— no perdiste tus workflows: levantas una instancia nueva, cargas el JSON, y estás de vuelta.

Esta es la reformulación completa de lo que estudiaste. En la lección 1 dije, sin explicarlo del todo, que "el repositorio, no la instancia, es la fuente de verdad". Ahora sabes por qué: porque la instancia es la cocina —reemplazable, donde las cosas suceden— y el repositorio es el recetario —la verdad, lo que no se puede perder—. Ese es el modelo mental de "workflow como código", y todo lo demás se deduce de él.

La pregunta de la identidad: ¿cuál es el workflow "de verdad"?

Parece una pregunta de sobremesa y es la decisión más práctica de toda la guía. Tienes tu workflow order-triage abierto en el editor de n8n, y tienes su JSON en el repositorio cumbre-automations. ¿Cuál de los dos es "el workflow"?

Antes de este módulo, la respuesta intuitiva era "el del editor, obvio; el del repo es una copia". Después de este módulo, la respuesta correcta es la opuesta: el del repositorio es el workflow; el del editor es una instancia de él corriendo.

Esta inversión es el momento en que alguien pasa de constructor a dueño del sistema, así que vale la pena detenerse. ¿Por qué el repo es "el workflow" y no el editor?

Porque el editor es efímero y el repo es permanente. Lo que está en el editor vive en la base de datos de esa instancia. Si la instancia muere, muere con ella. El repo sobrevive a cualquier instancia.

Porque el editor no tiene historia y el repo sí. El editor te muestra el estado de ahora. El repo tiene todos los estados, con su fecha y su motivo. La identidad de un workflow no es solo cómo está hoy; es también cómo llegó a estar así, y eso solo existe en el repo.

Porque puede haber muchos editores y un solo repo. Este es el punto que lo cierra. Cuando tengas entornos —dev, staging, prod—, vas a tener el "mismo" order-triage corriendo en tres instancias distintas a la vez. ¿Cuál de las tres es "el workflow"? Ninguna: son tres cocinas cocinando la misma receta. El workflow —la receta— es uno solo, y vive en el repo. Las instancias son ejecuciones de él.

Cuando adoptas esta inversión, muchas decisiones se resuelven solas. "¿Dónde hago el cambio?" —en el repo, y de ahí baja a las instancias, no al revés—. "¿Qué es lo que reviso antes de aprobar?" —el cambio en el repo, con un diff—. "¿Qué promuevo a producción?" —una versión del repo, no un editor—. La instancia deja de ser el centro del universo y pasa a ser lo que es: un lugar donde el workflow corre, uno de varios posibles.

Source y runtime: dos palabras que lo ordenan todo

Hay dos términos que la ingeniería de software usa desde hace décadas y que, aplicados a n8n, hacen clic con todo lo anterior. Vale la pena adoptarlos porque son precisos.

El source (la fuente) es la descripción de lo que un sistema debe hacer, escrita de forma permanente y versionable. En un programa clásico, el source es el código fuente que el programador escribe. En n8n, el source es el JSON de tus workflows en el repositorio. Es el recetario.

El runtime (el tiempo de ejecución) es donde el sistema efectivamente corre. En un programa clásico, el runtime es el programa ejecutándose en una computadora. En n8n, el runtime es tu instancia procesando pedidos. Es la cocina.

La relación entre los dos tiene una dirección, y esa dirección es la clave: el source manda sobre el runtime, no al revés. Escribes en el source, y el source se despliega al runtime. El runtime es una consecuencia del source. Cuando alguien cambia algo directamente en el runtime —edita un workflow en producción sin pasar por el repo—, invierte la flecha, y ahí empiezan los problemas: el runtime ahora dice algo que el source no sabe, y la próxima vez que despliegues desde el source vas a pisar ese cambio sin enterarte.

Esto tiene un nombre en n8n y es una tentación real: editar en el editor de producción "solo esta vez, porque es urgente". El modelo source/runtime te dice por qué es peligroso: acabas de crear una diferencia entre el recetario y la cocina, y esa diferencia es invisible hasta que te muerde. La disciplina del dueño del sistema es el cambio siempre nace en el source. Si es urgente, se hace rápido en el source y se despliega rápido, pero se hace en el source.

Aquí hay una honestidad que debo a la realidad de n8n: la herramienta te deja editar en el runtime. No hay una pared que te lo impida en Community. El modelo source/runtime es una disciplina que tú adoptas, no una barrera que la herramienta impone —salvo en las features de pago, que sí ponen barreras, tema de la lección 7—. Por eso es un modelo mental: su valor está en que cambia cómo decides, no en que te obligue.

El ciclo de trabajo: editar, exportar, commit, revisar, promover

El modelo source/runtime se vuelve acción en un ciclo de cinco pasos. Este ciclo es el latido de todo lo que viene en la guía, así que conócelo aunque todavía no sepas ejecutar cada paso.

   ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐     ┌──────────┐
   │  EDITAR  │ ──► │ EXPORTAR │ ──► │  COMMIT  │ ──► │ REVISAR  │ ──► │ PROMOVER │
   │(en dev)  │     │ (a JSON) │     │ (al repo)│     │ (el diff)│     │(a prod)  │
   └──────────┘     └──────────┘     └──────────┘     └──────────┘     └──────────┘
        ▲                                                                    │
        └────────────────────────────────────────────────────────────────────┘
                          (el próximo cambio empieza de nuevo)

Vamos paso por paso, con order-triage:

1. Editar. Haces el cambio en el editor de tu instancia de dev —nunca en prod—. Aquí construyes, con credenciales de prueba y datos sintéticos, sin miedo, porque nada de lo que toques afecta lo real. Este es el único paso que se parece a lo que hacía el constructor; la diferencia es dónde lo haces (en dev, no en producción) y que no termina aquí.

2. Exportar. Sacas el workflow a JSON —el Download de la lección 3—. Conviertes el "edificio" del editor en el "plano" de texto. Este es el momento en que el cambio sale del runtime y se prepara para entrar al source.

3. Commit. Guardas ese JSON en el repositorio con una nota que explica el cambio —"send orders over 5000 to manual review"—. Un commit es una entrada en la historia del repo: el momento en que tu cambio se vuelve parte del recetario, con fecha, autor y motivo. Es el Módulo 2. Aquí el cambio deja de ser efímero y se vuelve permanente y versionado.

4. Revisar. Antes de que ese cambio llegue a producción, alguien —un compañero, o tú mismo con ojos frescos, o incluso una revisión asistida por IA— lo lee como un diff: ve exactamente qué cambió y decide si está bien. Es la capacidad "revisión" de la lección 3, ahora posible porque el cambio está versionado. Es el Módulo 6.

5. Promover. El cambio revisado y aprobado se despliega: baja del source a los runtimes, avanzando por entornos —de dev a staging a prod—. Promover no es "volver a construirlo en producción"; es tomar la versión exacta que probaste y aprobaste, y cargarla en el siguiente entorno. Es el Módulo 6.

Y después, el ciclo se repite: el próximo cambio vuelve a empezar en "editar", sobre la base de lo que ya está en el source.

Fíjate en lo que este ciclo garantiza, casi sin que lo notes:

• Nunca editas producción directamente (empiezas en dev).
• Todo cambio queda versionado (paso 3) antes de llegar a ningún lado importante.
• Todo cambio se revisa (paso 4) antes de producción.
• Lo que llega a producción es exactamente lo que probaste (paso 5 promueve una versión concreta, no una reconstrucción).

Esas cuatro garantías son, precisamente, lo que separaba al dueño del sistema del constructor en la lección 2. No son cuatro reglas que memorizas; son consecuencias automáticas de seguir el ciclo. Ese es el poder de un buen modelo mental: la disciplina deja de ser esfuerzo de voluntad y pasa a ser "la forma natural de hacer las cosas".

Ejemplo trabajado: un cambio de order-triage a través del ciclo

Sigamos un cambio real de principio a fin, para que el ciclo deje de ser un diagrama y sea una historia. Cumbre quiere que los pedidos de más de 5000 pesos vayan a revisión manual.

Editar (en dev). Abres order-triage en tu instancia de dev. Ajustas el nodo de decisión para el nuevo umbral. Como estás en dev, ejecutas el workflow diez veces con pedidos sintéticos de prueba —uno de 6000, uno de 4000, uno de 5000 exacto— para ver que la regla se comporta como esperas. El CRM que toca es el de prueba; el agente de IA usa la credencial de dev. Nada de esto afecta a Cumbre real. Qué esperar: ves en el panel que el de 6000 va a revisión, los otros no. Bien.

Exportar. Haces Download. Ahora tienes order-triage.json con el cambio.

Commit. Guardas ese archivo en cumbre-automations con la nota route orders over 5000 to manual review. El repo registra: quién (tú), cuándo (hoy), qué (el diff, dos líneas), por qué (la nota). El cambio es ahora parte del recetario. Qué esperar: si alguien mira la historia del repo dentro de un año, va a poder leer exactamente esta decisión y su motivo.

Revisar. Tu compañera abre el diff. Ve dos líneas cambiadas —el umbral de un valor a otro, dentro de parameters, un campo estable (lección 4)—. No hay ruido de position ni de IDs porque el repo está normalizado (Módulo 3). En diez segundos entiende el cambio, ve que es correcto, y lo aprueba. Qué esperar: una revisión de segundos, no de arqueología, gracias a que el cambio está versionado y el diff es limpio.

Promover. El cambio aprobado se despliega a staging, donde se prueba una vez más en condiciones parecidas a producción, y de ahí a prod. Lo que llega a prod es exactamente el JSON que probaste en dev y revisaste en el diff —no una reconstrucción, no "lo hago otra vez en producción y espero que salga igual"—. Qué esperar: cero sorpresas en producción, porque producción recibe lo que ya viste funcionar.

Y si, contra todo pronóstico, algo sale mal en prod, tienes el paso que el ciclo hace posible: vuelves a la versión anterior del repo —que sigue ahí, con su fecha— y la promueves de nuevo. Rollback en un minuto. Eso es lo que respondía el candidato de la lección 2 en su buena entrevista, y ahora ves que no era un truco: era este ciclo.

Lo que este modelo NO significa

Como el nombre es "workflow como código", conviene despejar tres malentendidos que asustan a quien viene del mundo visual, porque ninguno de los tres es cierto.

No significa que vas a escribir JSON a mano. Sigues construyendo tus workflows en el editor visual de n8n, arrastrando y conectando nodos, exactamente como siempre. El JSON es lo que sale del editor cuando exportas, no algo que tú tecleas. En todo el ciclo, el paso "editar" es visual; el JSON aparece solo en "exportar", y de ahí en adelante lo maneja el sistema de versiones, no tus dedos. "Workflow como código" no te convierte en programador de JSON; te da los beneficios que los programadores tienen sobre su código —historia, revisión, rollback— sin que dejes de trabajar en el lienzo.

No significa que el editor visual sea malo o de principiantes. El editor es la mejor herramienta para construir, y la sigues usando. Lo que el modelo agrega no es un reemplazo del editor, sino una capa alrededor: el editor construye, el repo versiona, los entornos ejecutan. Cada uno hace lo que hace bien. Nadie te está pidiendo que abandones lo visual; te están pidiendo que no lo dejes suelto sin versión.

No significa que necesites saber programar. El modelo pide que entiendas el ciclo y la dirección de la flecha, no que sepas JavaScript ni ingeniería de software. Git —la herramienta del paso "commit"— se enseña desde cero en el Módulo 2, para alguien que nunca lo tocó. El modelo mental es conceptual; su valor está en cómo decides, y decidir bien no requiere programar. Un automatizador que nunca escribió una línea de código puede ser un dueño del sistema impecable si adopta este marco.

Dicho de otra forma: "código" aquí no es el lenguaje en que trabajas; es la disciplina con que tratas tu trabajo. Tratas el workflow con el mismo cuidado con que un buen equipo trata su código —versionado, revisado, desplegado por entornos— aunque tu workflow sea cien por ciento visual.

Por qué este marco resuelve tres problemas a la vez

Lo más elegante del modelo "workflow como código" es que no resuelve un problema: resuelve tres, y los resuelve con la misma idea. Vale la pena verlo explícito, porque es la razón por la que este es el módulo fundacional de la guía.

Resuelve el versionado. Si el source es el repo y todo cambio pasa por commit, entonces por construcción tienes historial, revisión y rollback —las tres capacidades que faltaban en la lección 3—. No las agregas aparte; vienen incluidas en tratar el repo como fuente de verdad.

Resuelve los entornos. Si el workflow es la receta y las instancias son cocinas, entonces dev/staging/prod son simplemente tres cocinas cocinando la misma receta con distintos ingredientes —credenciales de prueba en dev, reales en prod—. La misma receta, distintos ingredientes por cocina: eso es exactamente lo que resuelve el problema de credenciales por instancia de la lección 5. Los entornos dejan de ser un tema aparte y pasan a ser una consecuencia natural de separar source de runtime.

Resuelve la prueba. Si puedes desplegar la misma versión exacta a dev que a prod, entonces puedes probar en dev con la certeza de que lo que pruebas es idéntico a lo que va a correr en prod. Probar deja de ser "espero que en producción se comporte igual" y pasa a ser "es el mismo JSON, tiene que comportarse igual". El sandbox del Módulo 5 se apoya entero en esta garantía.

Los tres problemas —versionar, entornos, probar— parecían tres temas distintos, y son tres caras de una sola idea: separar lo que el workflow ES (el source, la receta) de dónde CORRE (el runtime, la cocina). Una vez que haces esa separación, los tres se ordenan solos. Por eso vale la pena instalar el modelo mental ahora, en el módulo 1, antes de la técnica: porque cada módulo que sigue no es un tema nuevo, es una parte de este mismo modelo hecha operativa.

Errores comunes

Tratar la instancia como la fuente de verdad y el repo como un backup (conceptual). Qué pasa: alguien monta un repositorio pero sigue haciendo los cambios en el editor y "exportando al repo de vez en cuando" como respaldo. La flecha está invertida: la verdad sigue viviendo en la instancia, y el repo va detrás, incompleto. Tarde o temprano el repo y la instancia divergen y el repo deja de servir. Por qué pasa: es la costumbre del constructor —el editor fue siempre el centro— y cuesta invertirla. Cómo detectarlo: si tu flujo es "cambio en el editor, luego respaldo al repo", tienes la flecha al revés. Cómo corregirlo: adopta que el cambio nace pensando en el source. En la práctica sigues editando en el editor de dev (paso 1 del ciclo), pero el cambio no está "hecho" hasta que está en el repo (paso 3), y producción solo recibe lo que sale del repo (paso 5). El repo no es donde respaldas; es de donde despliegas.

Editar directamente en producción "solo esta vez" (práctico y peligroso). Qué pasa: hay una urgencia, alguien entra al editor de prod y hace el cambio ahí mismo, sin pasar por dev ni por el repo. Funciona en el momento, y crea una diferencia silenciosa entre el runtime y el source. La próxima vez que alguien despliegue desde el repo, pisa ese cambio urgente sin saber que existía, y el problema "arreglado" reaparece. Por qué pasa: la urgencia hace que el ciclo se sienta como burocracia. Cómo detectarlo: si tu instancia de producción tiene cambios que el repo no conoce, ya divergieron. Cómo corregirlo: incluso en una urgencia, el cambio nace en el source —se hace rápido en dev, se commitea, se promueve rápido—. Si de verdad tocaste producción a mano por una emergencia extrema, el paso siguiente obligatorio es reflejar ese cambio en el repo de inmediato, para que el recetario vuelva a coincidir con la cocina.

Confundir "promover" con "reconstruir" (conceptual). Qué pasa: alguien entiende que hay que llevar el cambio a producción y lo interpreta como "vuelvo a hacer el mismo cambio en el editor de producción". Ahora hay dos construcciones distintas que deberían ser iguales pero se hicieron por separado, y cualquier diferencia entre ellas es un bug esperando. Por qué pasa: sin el modelo source/runtime, "llevar a producción" suena a "rehacer allá". Cómo detectarlo: si tu forma de desplegar es repetir los pasos en otra instancia, estás reconstruyendo, no promoviendo. Cómo corregirlo: promover es mover el mismo artefacto —el mismo JSON que probaste— al siguiente entorno, no rehacerlo. Lo que garantiza que producción se comporte como la prueba es que sea, byte por byte, lo mismo. El Módulo 6 te da las formas concretas de promover sin reconstruir.

Creer que el modelo mental es opcional porque "yo trabajo solo" (conceptual). Qué pasa: alguien que automatiza en solitario concluye que source/runtime, repos y ciclos son cosa de equipos grandes, y que para una persona es exagerado. Por qué pasa: la palabra "colaboración" domina la conversación sobre versionado, y quien trabaja solo no se siente aludido. Cómo detectarlo: si tu justificación para saltarte el modelo es "no tengo con quién colaborar", revisa. Cómo corregirlo: recuerda que de las cuatro capacidades de la lección 3, solo una (colaboración) requiere un equipo; las otras tres —historial, revisión, rollback— te sirven igual solo. El "tú de dentro de tres meses" es, a todos los efectos, otra persona: no se va a acordar de por qué cambiaste el umbral, y va a agradecer el recetario tanto como un compañero. El modelo mental es para cualquiera que quiera que su sistema le sobreviva a su propia memoria.

Ejercicios

Ejercicio 1 — Responde la pregunta de la identidad. Un colega te dice: "el repo es solo una copia de respaldo; el workflow de verdad es el que corre en producción". Escribe tu respuesta en cuatro o cinco frases, usando la imagen del recetario y la cocina, y explicando por qué la flecha va del source al runtime y no al revés.

Ver solución

Una respuesta posible:

"Yo lo veo al revés: el que corre en producción es una ejecución del workflow, no el workflow. Piensa en una cadena de restaurantes: la cocina de producción es una sucursal cocinando; el recetario en la oficina central es lo que define qué es cada plato. Si se incendia la cocina, no perdiste los platos, perdiste una cocina —abres otra y le das el recetario—. Lo mismo aquí: si la instancia de producción se corrompe, con el repo levantas otra y cargas el JSON. Por eso el cambio tiene que nacer en el repo y bajar a producción, no al revés: si alguien improvisa en la cocina sin actualizar el recetario, esa sucursal hace algo que nadie más sabe, y el próximo despliegue lo pisa. El repo es la verdad; la instancia es una de varias cocinas."

Por qué funciona: si tu respuesta separó "el workflow" (la receta, permanente) de "una ejecución del workflow" (la cocina, reemplazable) y explicó la dirección de la flecha, ya tienes el modelo mental completo. Nota que la mejor respuesta no niega que producción importe —importa mucho, es donde el negocio pasa— sino que niega que producción sea la fuente. Esa distinción es todo.

Ejercicio 2 — Ubica cada módulo en el ciclo. El ciclo tiene cinco pasos: editar, exportar, commit, revisar, promover. Para cada uno, di qué módulo de esta guía lo enseña a fondo (puedes revisar el temario del DISEÑO o de la lección 1). Después identifica qué paso del ciclo NO aparece explícito en la lista de cinco pero es donde vive el Módulo 5.

Ver solución

• Editar — es la habilidad que traes de las guías de construcción; esta guía lo ubica en el entorno correcto (dev), que es el Módulo 4.
• Exportar — el Módulo 3 (exportar con la CLI, normalizar, estructurar el repo). El Download del editor lo viste en la lección 3 de este módulo.
• Commit — el Módulo 2 (Git desde cero: staging, commits, ramas, rollback).
• Revisar — el Módulo 6 (revisar cambios como diffs, incluida la revisión de cambios de IA).
• Promover — el Módulo 6 (promover entre entornos, rollback, runbook).

El paso que no está explícito en los cinco pero es central: probar. Vive escondido dentro de "editar" (pruebas en dev) y entre "revisar" y "promover" (pruebas en staging antes de prod). Es el Módulo 5 completo, la prueba en sandbox. El ciclo de cinco pasos es el esqueleto; la prueba es lo que le da confianza a la promoción.

Por qué funciona: este ejercicio te muestra que la guía entera es este ciclo desplegado. No son seis temas sueltos; son las cinco fases de un solo flujo, más la prueba que lo hace confiable. Si tienes el ciclo en la cabeza, tienes el mapa de todo lo que falta.

Ejercicio 3 — Diagnostica una flecha invertida. Lee esta descripción de cómo trabaja un equipo y señala en qué momento exacto invierten la flecha source→runtime, qué problema concreto va a causar, y cómo lo corregirías:

"Hacemos los cambios directo en la instancia de producción porque es más rápido. Cada viernes, alguien exporta todos los workflows de producción y sube los JSON al repositorio, para tener un respaldo por si acaso."

Ver solución

La flecha se invierte desde el primer momento: los cambios nacen en el runtime (producción), y el repo va detrás, cada viernes, copiando lo que producción ya decidió. El source no manda sobre el runtime; el runtime manda sobre el source. El repo no es una fuente de verdad, es un espejo retrasado.

Problemas concretos que causa: (1) no hay revisión antes de producción —los cambios ya están en vivo cuando el repo se entera—; (2) los cambios de lunes a jueves no existen en el repo hasta el viernes, así que un rollback a mitad de semana no tiene a dónde volver; (3) si dos personas cambian producción el mismo día, la sobrescritura silenciosa de la lección 3 ocurre en vivo, sobre datos reales; (4) el repo "de respaldo" tiene mezclados los cambios buenos con cualquier improvisación urgente, sin distinguirlos ni explicarlos.

Cómo corregirlo: invertir la flecha. Los cambios nacen en dev, se commitean al repo (con revisión), y se promueven a producción. Producción deja de ser donde se edita y pasa a ser donde se despliega lo aprobado. El "respaldo del viernes" desaparece porque ya no hace falta: el repo siempre está adelante del runtime, no detrás.

Por qué funciona: el error del equipo no es no tener repo —lo tienen—; es tenerlo del lado equivocado de la flecha. Reconocer la dirección de la flecha es lo que distingue un repo que es fuente de verdad de uno que es un cementerio de backups. Esa es la lección central del módulo, aplicada.

Resumen y siguiente paso

En esta lección instalaste el modelo mental que ordena todo el módulo: workflow como código. Viste la imagen del recetario y la cocina —el repositorio es el recetario maestro, la verdad permanente; la instancia de n8n es la cocina, donde los workflows corren pero que es reemplazable—, y con ella resolviste la pregunta de la identidad: el workflow "de verdad" es el del repositorio, y el del editor es una de varias ejecuciones posibles. Adoptaste los términos source (la fuente versionada, el repo) y runtime (donde corre, la instancia), y la regla de que la flecha va del source al runtime, nunca al revés. Recorriste el ciclo de trabajo —editar en dev, exportar a JSON, commit al repo, revisar el diff, promover a producción— siguiendo un cambio real de order-triage de principio a fin, y viste que ese ciclo garantiza por construcción las cuatro cosas que hacen a un dueño del sistema: no editar producción, versionar todo, revisar todo, y promover exactamente lo que probaste. Y entendiste por qué este marco resuelve tres problemas a la vez —versionado, entornos y prueba— porque los tres son caras de una sola idea: separar lo que el workflow ES de dónde CORRE.

Antes de avanzar deberías poder: explicar con el recetario y la cocina por qué el repo es la fuente de verdad; nombrar los cinco pasos del ciclo en orden; y detectar cuándo un equipo tiene la flecha source→runtime invertida.

Ya tienes el problema diagnosticado y el modelo que lo resuelve. Falta una pieza de honestidad antes de cerrar el módulo: ¿cuánto de todo esto es gratis y cuánto se paga? n8n tiene features de control de versiones y entornos integradas en la interfaz, pero viven en los planes de pago. La lección 7 te dice con total franqueza qué trae Community gratis —que es, spoiler, todo lo que necesitas para hacer lo de esta guía—, qué exige Enterprise o Business, y el criterio para decidir cuándo vale la pena pagar. Y te da un recorrido por la interfaz de n8n 2.0 para que sepas dónde vive hoy el export/import y la superficie de source control. Es la lección que te deja tomar una decisión de dinero con los ojos abiertos.

Recursos

• Source control and environments — n8n Docs — la visión oficial de n8n sobre source y environments; útil para contrastar el modelo conceptual de esta lección con la implementación de pago de la herramienta.
• Git and n8n — n8n Docs — cómo n8n concibe la relación entre su instancia y un repositorio Git (en su feature de pago): push envía del runtime al source, pull trae del source al runtime, exactamente la dirección de flecha de esta lección.
• Environments in n8n — n8n Docs — la idea de múltiples entornos respaldados por ramas de Git; el "varias cocinas, una receta" de esta lección en la versión de pago.
• Export and import workflows — n8n Docs — el paso "exportar" del ciclo, con la herramienta que ya conoces.