8. Final project: version-controlled, documented delivery

Description

By the end of this lesson you will have produced, end to end, the deliverable giving the guide its name: cumbre-automations packaged exactly as the market asks, "as version-controlled, documented JSON." A Git repository with the order-triage workflow exported via CLI, normalized and documented with a handoff README; the three dev/staging/prod environments isolated via Docker Compose; a sandbox test pass executed at zero cost; a promotion and rollback runbook; and the CI check validating the JSON on every commit. It's defensible in an interview and works as a portfolio artifact: the concrete proof that you don't just build workflows, you version, test, promote, and operate them like a system owner.

This matters because it's proof the six modules fit together. Up to now you practiced each capability separately —versioning, isolating environments, testing, promoting, reverting, validating. The final project joins them into a single deliverable, in the right order, and shows you the whole is more than the sum: a deliverable system isn't "doing the six things," it's doing them so they hold each other up. And it leaves you a real artifact, not an exercise to discard: a repository you can show and defend on Monday, in an interview.

Connection to the module: this lesson doesn't introduce new concepts; it integrates the guide's six modules. Every phase of the project is a capability you already built, put in its place inside the complete deliverable. This module's new pieces —the promotion runbook (lesson 2), the rollback runbook (lesson 5), and the CI check (lesson 7)— get added to what you already had from Modules 2 through 5. When you finish, you close out the guide's third and final visual phase —"professional promotion and delivery"— and with it, the entire guide. Pay attention to how the runbook and CI turn a "tidy" repository into an "operable" system: that's the final difference between builder and owner.

A deliverable is a promise someone else can verify

Before getting hands-on, a word about what this deliverable is and why it's put together this way.

In Module 3's project you built a repository "another developer would approve." This project raises the stakes: you build a system someone else can operate without you. The difference isn't of size, it's of nature. A tidy repository proves you know how to organize; a system with environments, runbooks, and CI proves you know how to operate. The first makes you a good builder; the second, a system owner. And the market —you already saw it, posting by posting— pays for the second.

Think of it as the difference between a nice house and a house with a deed. The nice house looks good and works while you live in it and know where the water shutoff is. The house with a deed can be transferred: it comes with the blueprints, the boiler manual, the plumber's number, and the list of what to do if the basement floods. Anyone can take it over and operate it, because it doesn't depend on knowledge living only in your head. Your cumbre-automations is going to be the house with a deed: it doesn't just work, it comes with everything someone else needs to operate it, improve it, and recover it when something fails.

There's a concrete reward in building it seriously: when you're done, you won't "know about" delivering automation systems, you'll have it done. And that distance —between knowing about and having done— is huge in an interview. Anyone can describe a rollback runbook; very few can open theirs, show they rehearsed it in staging, and explain why step 5 re-imports into the instance and not just fixes the repo. This project puts you on the second side.

A note about the starting point. The project assumes you already built, throughout the guide, Modules 2 through 5's pieces: the versioned repository, the three environments, the sandbox pass. If you've been following Cumbre's case, you already have them. If you don't have an instance handy, read the whole project anyway: the sequence and its logic come through just the same, and you run them when you have the environment. What transfers —the order, each decision's reasoning— is worth more than typing the commands once.

Worked example: the complete deliverable, phase by phase

Let's assemble cumbre-automations in nine phases. Each phase opens with where you are and closes with what to expect, so you always know if you're on track. The first three phases confirm what you already built; phases 4 through 8 add this module's pieces; 9 verifies and delivers.

Phase 0 — Where you are: six modules of work

Starting point: everything you built in the guide, distributed across pieces. This is the inventory you're going to integrate:

Piece	From which module	Status at the start
Versioned cumbre-automations repository, with .gitignore and .gitattributes	Modules 2–3	Ready
order-triage.json exported via CLI, normalized, with export.sh	Modules 2–3	Ready
Handoff docs/order-triage.md, credentials/README.md	Module 3	Ready
Three dev/staging/prod environments via Docker Compose, each with its N8N_ENCRYPTION_KEY and per-environment credentials	Module 4	Ready
A sandbox test pass executed at zero cost	Module 5	Ready
Promotion runbook, rollback runbook, CI check	Module 6	To add

Stand in the repository:

cd cumbre-automations

What to expect: git status shows you a repository already populated with Modules 2 through 5's work. You don't start from zero: you start from a tidy repository missing this module's three operational pieces. The project is assembling the complete system, not building it from scratch.

Phase 1 — Confirm the versioned base (Modules 2–3)

Where you are: repository populated, about to verify its foundations. Before adding anything, confirm the base is solid, because everything else rests on it. Go through this quick list:

# The workflow exists, normalized and with a readable name:
ls workflows/order-triage.json

# The secrets are shielded (.gitignore covers .env and credentials):
cat .gitignore

# The export script exists and is executable:
ls -l scripts/export.sh

What to expect: order-triage.json is present and, opening it, it looks normalized —no pinData, versionId, meta.instanceId, keys sorted. .gitignore covers .env, credential exports, and .n8n/. export.sh is there and executable. If something fails here, go back to Module 3 to complete it before continuing: there's no point building the operation on top of an incomplete base.

Phase 2 — Confirm the three environments (Module 4)

Where you are: versioned base confirmed. Now verify the three environments exist and are isolated, because this module's promotion and rollback move between them. Your repository should have the per-environment configuration you set up in Module 4 —a docker-compose per environment, each with its own variables file and its N8N_ENCRYPTION_KEY, and test credentials in dev/staging and real ones in prod.

Use the layout you left from Module 4. One representative way to organize it is one folder per environment:

environments/
├── dev/       (docker-compose.yml + .env.example)
├── staging/   (docker-compose.yml + .env.example)
└── prod/      (docker-compose.yml + .env.example)

What matters isn't the folder's exact name, but that three things from Module 4 hold: each environment is an isolated instance, each has its own N8N_ENCRYPTION_KEY, and the .env files with real values are not in the repository (only the valueless .env.example files, thanks to phase 1's .gitignore).

What to expect: the three environments are defined, isolated, and none leaks secrets into the repository. Confirm git status shows no .env with real values. If you bring up all three, each runs its own n8n instance in its own container —n8n-dev, n8n-staging, n8n-prod— which are the destinations you promote between.

Phase 3 — Confirm the sandbox pass (Module 5)

Where you are: environments confirmed. Before documenting the promotion, confirm the evidence exists that order-triage was tested in sandbox at zero cost, because promoting something untested breaks the promotion principle. Module 5's pass used synthetic data, sandbox keys, dry run, execution replay, and assertions with the Evaluation node, with local Ollama models for testing the AI Agent node with no spend.

Leave a record of that pass in the repository, at docs/sandbox-test-pass.md, so the deliverable shows that it was tested and how:

# Sandbox test pass — order-triage

Run in the staging environment, at zero cost.

## What was tested
- Order classification by the AI Agent node (local Ollama model, no API cost).
- Order enrichment with the HTTP Request node against the sandbox CRM.

## How it was tested (Module 5)
- Synthetic data: generated orders, no real customer data.
- Sandbox keys: the test CRM, not the real one.
- Dry run: side effects (writing to the CRM) guarded during the test.
- Execution replay: pinned executions were re-run to validate changes.
- Assertions with the Evaluation node: verified classification falls into the
  expected categories (approved / manual review / missing information).

## Result
The pass came out green before promoting to prod. (This is a practice example; on a
real project, attach your executions' metrics and screenshots.)

What to expect: docs/sandbox-test-pass.md documents order-triage passed its sandbox test before any promotion to prod. This isn't just portfolio evidence; it's the promotion's honest precondition: only what's tested gets promoted.

Phase 4 — The promotion runbook (lesson 2)

Where you are: base, environments, and test confirmed. Now you add this module's first operational piece: the runbook documenting how order-triage gets promoted to prod. It goes in docs/runbook-promotion.md:

# Runbook: promoting order-triage to prod

## When to use this
When an order-triage change passed its sandbox test (staging) and needs to be
brought to production in a controlled way.

## Owner
The operator with access to the repository and the n8n-prod container.

## Preconditions
- The change is committed and reviewed (diff approved in a pull request).
- The sandbox pass in staging came out green.
- The real credentials (Cumbre CRM key, Cumbre LLM key) already exist in prod.

## Steps
1. Stand in the repository and confirm the version to promote:
       cd cumbre-automations
       git diff HEAD~1 workflows/order-triage.json   # check ONLY the expected thing changed

2. Copy the good JSON to prod's container:
       docker cp workflows/order-triage.json n8n-prod:/tmp/order-triage.json

3. Import into prod (arrives INACTIVE by default — that's what we want):
       docker exec -u node -it n8n-prod n8n import:workflow \
         --input=/tmp/order-triage.json

4. Open order-triage in prod's editor. Verify the logic is the new one and
   the nodes with credentials (AI Agent, HTTP Request) resolve, not red.

5. Activate order-triage in prod (activation switch), watching.

## Verification
- A real order comes in and gets classified correctly with the new logic.
- The CRM node authenticates and responds with no error.

## If something goes wrong
- Run docs/runbook-rollback.md immediately. Don't debug in prod.

Notice how the runbook condenses all of lesson 2 into executable steps: pulling from the repo, reviewing the diff, importing inactive, verifying credentials, activating deliberately. And how it ends pointing at the rollback runbook: promotion and reversion are two faces of the same procedure.

What to expect: docs/runbook-promotion.md exists and anyone with the access could promote order-triage to prod by following it, without having designed the system. That's the standard: a runbook someone else can execute.

Phase 5 — The rollback runbook, and rehearsing it (lesson 5)

Where you are: the promotion runbook ready. Now the emergency exit: lesson 5's rollback runbook, in docs/runbook-rollback.md (use the one you wrote there, with its two halves —reverting in the repo and re-importing into the instance— and its observable verification).

But adding the file isn't enough: rehearse it in staging, as you learned. Deliberately promote a "bad" version of order-triage to staging, and then run the rollback runbook to the letter to go back. Leave a record of the rehearsal at the end of the runbook:

## Rehearsal (mandatory before trusting this runbook)
Rehearsed in staging on <date>: deliberately promoted a version with the
threshold at 100, ran this runbook step by step, and staging returned to
the good version in ~5 minutes. No step failed. (Repeat the rehearsal if
you change the procedure.)

What to expect: docs/runbook-rollback.md exists and was rehearsed in staging. The difference between a written runbook and a rehearsed one is the difference between a plan and a wish; your deliverable has the rehearsed version, with the drill's date. In an interview, "I rehearsed it Tuesday in staging" weighs a lot more than "I have a runbook."

Phase 6 — The CI check (lesson 7)

Where you are: both runbooks ready. Now the automatic inspector: lesson 7's CI workflow, in .github/workflows/validate-workflows.yml. Create it with that lesson's content —the one validating every workflow is parseable JSON (jq empty) and normalized (comparing against the form export.sh leaves).

Remember the strict path requirement: the file has to be exactly in .github/workflows/, with the leading dot, or GitHub Actions won't run it.

What to expect: pushing the file to GitHub, the validate-workflows workflow shows up in the "Actions" tab, and on every commit touching workflows/*.json it runs on its own, leaving a green check if the JSON is valid and normalized, or a red X with a useful message if not. Test it deliberately: commit an order-triage.json with an extra comma and confirm the check turns red; then fix it and confirm it goes green again. Seeing the smoke detector sound and go quiet confirms it works.

Phase 7 — Document how you build with AI (lesson 4)

Where you are: the operation automated. Add a short note documenting the safe AI-building loop, because it's part of how this system gets operated and a guaranteed interview question. It goes in docs/ai-authoring.md:

# Building with AI — how and where

## Principle
AI (via n8n's MCP server) builds and edits workflows ONLY in dev,
never in prod. In prod the MCP module is disabled by configuration.

## Per-environment configuration
- dev:  N8N_MCP_ACCESS_ENABLED=true      (AI can build here)
- prod: N8N_DISABLED_MODULES=mcp         (the MCP endpoint doesn't even exist here)

## The safe loop
AI proposes in dev -> gets exported and committed -> the human reviews the DIFF
in a pull request -> gets promoted through the normal flow (dev -> staging -> prod).
AI proposes; the human approves. What gets promoted is never what the AI says,
it's what the reviewed diff shows.

(Check the variable names and the MCP endpoint in your n8n version's docs:
this area evolves fast.)

What to expect: docs/ai-authoring.md puts the per-environment lock and the safe loop in writing. Even if you don't use AI on every change, documenting it proves you know how to use it without losing control —exactly what an evaluator wants to confirm.

Phase 8 — The handoff README tying everything together, plus visual evidence

Where you are: every piece in place. Now the root README.md, which is the repository's cover and the first thing whoever opens it sees —an evaluator, a teammate, you in six months. It has to let someone start and operate the system without asking you anything. Add, at the top, a screenshot of order-triage open in n8n's editor, with its Webhook, its AI Agent node, and its connected HTTP Request node: the visual evidence turning the JSON tangible.

# cumbre-automations

![order-triage in the n8n editor](docs/img/order-triage.png)

Cumbre's automations, delivered as version-controlled, documented JSON.

## What this is
Cumbre's automation repository. Contains order-triage (Webhook ->
AI Agent -> HTTP Request to the CRM), versioned, tested, with environments and runbooks.

## How to get started (dev)
1. Copy environments/dev/.env.example to .env and fill in your values.
2. Bring up the environment: docker compose -f environments/dev/docker-compose.yml up -d
3. Import the workflow: see docs/runbook-promotion.md.

## How it's operated
| I need to… | See |
|---|---|
| Promote a change to prod | docs/runbook-promotion.md |
| Revert a change that broke prod | docs/runbook-rollback.md |
| Understand what order-triage does | docs/order-triage.md |
| Know what was tested and how | docs/sandbox-test-pass.md |
| Build workflows with AI | docs/ai-authoring.md |
| Keep the repo up to date | scripts/export.sh |

## Where the secrets are
Outside the repository, always. Each environment has its credentials on its
own instance; the repo only carries references. See credentials/README.md.

## Automatic verification
Every commit touching a workflow goes through the CI check
(.github/workflows/validate-workflows.yml): parseable, normalized JSON.

Notice the README doesn't explain every piece in detail —that's what the docs are for— it orients. It's an index sending you to each place based on what the person needs to do. That's the handoff move: not dumping all your knowledge, but leaving the map to find it.

What to expect: a root README.md with the screenshot at the top and the "how it's operated" table pointing at every runbook and doc. A stranger opening the repository sees, on the cover, what the system is, how to start it, and where to go for each operation. The house with a deed.

Phase 9 — Final verification, security, and delivery

Where you are: the complete deliverable. Before committing the final delivery, the security review, with the same rigor as Module 3:

git status

Review it with an auditor's eye. These new pieces should appear: docs/runbook-promotion.md, docs/runbook-rollback.md, docs/sandbox-test-pass.md, docs/ai-authoring.md, .github/workflows/validate-workflows.yml, the updated README.md, the image. These should not appear, under any circumstance: any .env with values, any credential exports, the .n8n/ folder, or anything shaped like a secret. As a double check, review the content before committing:

git diff --cached

Read it looking for sk-, Bearer , password, long keys. If you find a secret, stop, remove it, and if it already got exported, rotate that credential.

Once the check passes, you —not the script, not the AI— decide what enters the history:

git add .
git commit -m "Final delivery: order-triage versioned, with environments, tests, runbooks, and CI"
git push

What to expect: a commit capturing the complete deliverable, and —if you have the GitHub remote— the push making it visible and triggering the CI check for the first time on the delivery. Open your repository on GitHub: you see the cover with the screenshot, the green CI mark, and the whole navigable structure. cumbre-automations is now a real, defensible portfolio artifact.

The delivery rubric: how a system owner gets judged

The standard isn't "I did the nine phases"; it's "a competent evaluator would confirm there's a system owner here, not just a builder." This is the list the complete deliverable gets judged by, grouped by what each layer demonstrates:

Versioning and cleanup (Modules 2–3):

• order-triage.json exported via CLI, normalized (no volatile fields, keys sorted).
• A save with no logic changes would produce an empty diff after normalizing.
• export.sh reproduces the repo's state from one command.

Security (Module 3) — reviewed first and most harshly:

• No credential value in the repo, encrypted or plain, or in the history.
• .gitignore covers .env, credential exports, and .n8n/.
• Secrets live on each instance, not in the repository.

Environments (Module 4):

• Three environments isolated by Docker Compose, each with its own N8N_ENCRYPTION_KEY.
• Test credentials in dev/staging, real ones in prod, with the reference resolving in each.

Test (Module 5):

• Evidence of a sandbox pass executed at zero cost, with what was tested and how.

Operation (Module 6) — what separates the owner from the builder:

• Promotion runbook executable by someone else.
• Rollback runbook executable and rehearsed in staging, with both halves (repo and instance).
• Green CI check validating the JSON on every commit.
• The safe AI-building loop documented (AI in dev, never in prod).

Handoff (everything together):

• Root README with visual evidence letting you start and operate without asking the author.
• The stranger test passes: someone could operate the system with just the documentation.

If your cumbre-automations checks all these boxes, it isn't an exercise: it's the proof, verifiable line by line, that you crossed from workflow builder to automation system owner. The layer most people fail is operation —the rehearsed runbooks and CI— because it's the one this module added and the one fewer people know the market asks for. It's, not by coincidence, the one setting you apart the most.

The final defense: your artifact in the interview

Close the project imagining the conversation you built it for. An interviewer opens your cumbre-automations and asks the questions you already know how to answer, because each one is a design decision you can point to:

• "How do you get a change to production?" → The promotion runbook.
• "And if it breaks something?" → The rollback runbook, rehearsed in staging.
• "How do you guarantee the JSON is correct?" → Green CI, validating every commit.
• "How do you test without touching the real CRM?" → The zero-cost sandbox pass, with synthetic data and local models.
• "How do you avoid leaking a credential?" → .gitignore since the first commit and credentials out of the repo.
• "If you use AI, how doesn't it break production?" → The safe loop: the AI in dev, the human reviews the diff, it gets promoted.
• "Could someone else pick this up without you?" → The handoff README, live.

None of those answers is theory. All of them are evidence the interviewer can verify by opening your repository. That's the difference between saying "I know how to use n8n" and demonstrating "I own an automation system" —and it's, word for word, what the best job postings ask for when they write "as version-controlled, documented JSON" and "no prototype = no conversation."

Keep this repository. Polish it. It's the project you're going to show off, and every module in this guide added a layer answering another interview question.

Common mistakes

Delivering the tidy repository but without the operational layer (conceptual, the mistake defining this project). What happens: someone builds an impeccable repository —versioned, normalized, documented— but stops there, with no runbooks or CI, and believes they already delivered "professionally." In the interview, when asked how they promote or revert, they have nothing to point to. Why it happens: the operational layer is the newest and the one fewer people know the market asks for; it's easy to believe "tidy" is enough. How to spot it: if your repo has no executable runbooks or CI check, you're missing exactly what separates the owner from the builder. How to fix it: a tidy repository proves you organize; runbooks and CI prove you operate. The complete deliverable needs both layers. The nice house isn't the house with a deed.

Documenting a runbook without rehearsing it (practical). What happens: someone writes both polished runbooks and commits them, but never runs them. In an interview they say "I have a rollback runbook," and if the interviewer asks "did you test it?", the honest answer is "no." An unrehearsed runbook almost always has a mistake only the rehearsal reveals. Why it happens: writing feels like finishing; rehearsing seems optional. How to spot it: if no runbook ran start to finish, they're hypotheses, not plans. How to fix it: rehearse the rollback in staging and record it with the date. "I rehearsed it Tuesday" is an owner's answer; "I have it written" is a builder's. The rehearsal is what turns the document into a guarantee.

Forgetting the visual evidence and delivering only JSON (practical, portfolio). What happens: someone shares a repository of pure JSON and expects the evaluator to "see" the workflow. Whoever doesn't read JSON fluently can't picture it, and the real work doesn't get communicated. Why it happens: to whoever built it, the JSON is the workflow; to whoever evaluates it from outside, it's abstract text. How to spot it: if your README has no screenshot of the assembled order-triage, it's missing the tangible half. How to fix it: put the screenshot at the top of the root README. The image shows it works; the repo shows you know how to deliver it; together they tell the complete story. A portfolio artifact communicates at a glance or it doesn't communicate at all.

Committing the final delivery without the security check (practical). What happens: someone, eager to finish, jumps from the final README straight to git add . && git commit && git push, skipping the audit git status and git diff --cached, and drags an .env or a credential export into the history —and worse, into GitHub's public remote. Why it happens: verification feels like a formality when everything "is already ready." How to spot it: if you pushed without having explicitly looked at what you were pushing, you skipped the control. How to fix it: the security check isn't optional, and especially not on the final delivery, which also goes to a visible remote. Always look at what's going in before it goes in; on a GitHub push, a committed secret is a published secret. It's cheaper to review than to rotate credentials and clean the history afterward.

Exercises

Exercise 1 — Self-assess with the complete rubric. Take your finished cumbre-automations (or the one you built following the project) and go through it with the delivery rubric, box by box, paying special attention to the operation layer. Note which ones you can check confidently and which you can't. For each box you can't check, write in one sentence the concrete action that's missing.

See solution

There's no single answer; the result is your diagnosis. What most people discover is that the versioning, security, and environments layers get checked confidently —they're the most practiced— and that the weak ones are in the operational layer: the rehearsed (not just written) rollback runbook and green CI. The clean-history box also tends to fail, because people review the current state and not the history.

If you can't check a box, that's your next task, concrete and small: not "improve the repo" in the abstract, but "rehearse the rollback in staging and note the date" or "confirm CI runs in the Actions tab." The rubric turns "is my deliverable okay?" into a list of specific actions.

Why it works: reviewing yourself with an evaluator's rubric before a real one reviews you is the skill the whole guide chases. Every box you fix is a comment they won't have to make in the interview. And paying attention to the operational layer means paying attention to exactly what sets you apart.

Exercise 2 — Trace each piece to its module. Without looking back at phase 0, take the deliverable's seven pieces —versioned repository, normalized order-triage, three environments, sandbox pass, promotion runbook, rollback runbook, CI check— and say which guide module each comes from. Then explain in one sentence why the project's phase order (confirm the base, then the environments, then the test, then the operation) isn't arbitrary.

See solution

The pieces and their modules: versioned repository and normalized order-triage → Modules 2–3; three isolated environments → Module 4; sandbox pass → Module 5; promotion runbook, rollback runbook, and CI check → Module 6 (lessons 2, 5, and 7).

Why the order isn't arbitrary: each phase rests on the previous one. You can't document the promotion (phase 4) without having the environments you promote between (phase 2, Module 4); you can't promote honestly without the test authorizing it (phase 3, Module 5); you can't revert (phase 5) without the versioned base to go back to (phase 1, Modules 2–3). The project confirms the foundations before building the operation on top, because operation without foundations collapses. The order is causal, not chronological by chance.

Why it works: seeing each deliverable piece come from a different module shows you the whole guide was building, without you noticing, one system's parts. The final project doesn't add much new content; it reveals everything before it was, from the start, a single deliverable broken apart across six modules.

Exercise 3 — Defend your artifact. Choose three of the seven interview questions from "The final defense" and write, for each, the answer you'd give pointing at a concrete piece of your repository (not Cumbre's in the abstract). Practice them out loud as if you were in the interview.

See solution

There's no single answer, because you point at your own repository. An example of three:

• "And if a change breaks production?" → "I have a rollback runbook, right here in docs/runbook-rollback.md, and I rehearsed it in staging on Tuesday: I deliberately caused a problem and went back to the good version in about five minutes. It has both halves, reverting in the repo and re-importing into the instance, because fixing only the repo leaves production broken."
• "How do you guarantee the JSON is correct?" → "This CI check, in the Actions tab, validates every commit: that the JSON is parseable and normalized. See, it's green. If I commit something broken, it turns red and tells me how to fix it, so quality doesn't depend on me remembering to review."
• "If you use AI to build, how doesn't it break production?" → "The AI only builds in dev, via MCP; in prod I disabled the MCP module with N8N_DISABLED_MODULES=mcp, so it can't even connect there. What the AI proposes goes through a diff I review in a pull request before it gets promoted. The AI proposes; I approve."

Why it works: practicing the defense out loud, pointing at real pieces, is what turns a good repository into a good interview. The artifact doesn't speak for itself; you defend it. And since every answer points at verifiable evidence, you're not claiming you know: you're demonstrating it. That's the difference the whole guide prepared you to make.

Summary and closing the guide

You made it to the end. In this lesson you integrated the six modules into one deliverable: cumbre-automations, the house with a deed. You assembled, in nine phases, the versioned and normalized repository (Modules 2–3), the three environments isolated via Docker Compose (Module 4), the zero-cost sandbox pass's evidence (Module 5), and this module's three operational pieces —the promotion runbook, the rollback runbook rehearsed in staging, and green CI— plus the safe AI-building loop's note and a handoff README with visual evidence letting the system be operated without you. You checked it with the system owner's rubric and prepared its defense for the interview, where every question is a design decision you can point to.

Now look back at the whole path, because it's worth seeing it in full. You started, in Module 1, with a loose JSON in a downloads folder and an uncomfortable question: why doesn't having the file mean having control? You learned Git from scratch (Module 2), to export, normalize, structure, and document a repository (Module 3), to set up three truly isolated environments (Module 4), to test in sandbox without spending a cent (Module 5), and —in this module— to promote carefully, review every change (AI's included), revert with a rehearsed runbook, decide between free and paid with judgment, and automatically validate on every commit. Every module was a piece of a single system, and today's project revealed them as what they always were: the parts of the deliverable the market asks for in writing.

You crossed the line the guide promised in its first line: from workflow builder to automation system owner. Not because you build better workflows —you already knew how to do that— but because now you wrap them in the discipline turning them into a deliverable, operable, recoverable-by-others system. And you did it entirely down the self-hosted Community path at zero cost, without paying a subscription, with standard tools —Git, Docker, GitHub Actions— transferring to anywhere you work tomorrow.

What follows isn't in this guide; it's in your work. Take this artifact and make it yours: replace order-triage with a real workflow you built, with its AI Agent node and its external API, and build your cumbre-automations under your own name. Polish it until it checks every rubric box. And when a posting says "as version-controlled, documented JSON," you're not going to have to explain that you know how to do it: you're going to open the repository and show it. That's the goal we've been chasing from the start, and you already have it in your hands.

Thanks for making it this far. More challenges and more systems to deliver are coming, but crossing this line —from putting flows together to owning systems— is worth celebrating. Not bad at all for the road you traveled.

Resources

• About READMEs — GitHub Docs — how GitHub presents your root README as the cover of the repository you just delivered.
• Use the command line — n8n Docs — the reference for export:workflow and import:workflow orchestrating the deliverable's promotion and rollback.
• GitHub Actions documentation — GitHub Docs — the platform for the CI check validating your JSON on every commit, the delivery's last layer.
• Source control and environments — n8n Docs — the paid feature you now understand from the inside, because you did by hand what it automates.
• Set up and use the n8n MCP server — n8n Docs — the MCP server for the safe AI-building loop; check the details on your version, since it evolves fast.
• git — the simple guide and the official documentation — the Git reference, the standard tool you learned that transfers to any project you take on after this guide.