🛡️The Unbreakable Guardian · the CI that reviews every change before it reaches your users

The moment · when the need shows up

At first you build alone. You change something, refresh the screen, see it work, and you're done. There's no risk: the only one who suffers a bug is you, on your own machine, and you fix it in two minutes. That stage is paradise — and also a trap, because you get used to "if it works on my screen, it's fine."

The moment shifts the day someone else depends on your app. The first user who signs up. The client who's already paying. The teammate who also touches the code. From that point on, every change you ship no longer affects only you: it can break the app for real people, or worse, leak their data. And here's the problem — you no longer see every change one by one. You ask the AI for something, it touches 8 files, you read 2, you approve, and you ship. The disaster can be hiding in those 6 you didn't read.

The pain · where it comes from and why it hurts so much

The pain isn't dramatic at first. It's not a hacker movie. It's more like a series of small accidents that, added up, cost you dearly. And they all come from the same place: AI in builder mode is optimistic. It's thinking about making the new feature work, not about the thousand ways that change can break something else. It's in its nature — and in yours too, when you're excited building.

The most expensive accident is the leaked secret key. You ask the AI to connect a service, and to "get it working fast" it pastes your API key straight into a file. You don't notice, you approve, you push to GitHub. That key is now public. There are bots scanning GitHub 24 hours a day looking for exactly that — they can find it in minutes and start spending your money or getting into your systems. It's not a sophisticated attack: it's an oversight that someone else's machine picked up off the ground, like picking up a wallet you dropped without even noticing.

The second is the hole in the database. A change that, without meaning to, leaves one of your users' tables accessible to anyone, or creates a function with permissions it shouldn't have. You can't see it. The app keeps working exactly the same. But you've just left a window open that nobody's going to close until someone finds it — and by then it's too late.

The third is the most common and least glamorous: you broke something that used to work. You fixed button A and, without noticing, disconnected button B. In your quick test you only touched A, so you never saw it. The user who relied on B finds the app broken. In programming this has a name — a regression — and it's 80% of the real day-to-day pain.

And what happens if you DON'T do it? Nothing… for a while. That's the trap. It works without a guardian for weeks, you get comfortable, and right when the project starts to really matter — when there are users, money, or reputation on the line — the accident arrives that would have cost you 30 seconds to avoid. The guardian is cheap insurance against a very expensive day.

The 7 inspectors · what each one checks

The guardian isn't a magic block: it's 7 concrete checks that run automatically on every change. If all 7 pass, you see a green check and the change can move forward. If a single ONE fails, it turns red and the change is blocked until you fix it. That simple, that strict. Let's go through them one by one, in the order they run.

1 · Gitleaks — did you slip in a secret key by accident? It scans the whole change looking for things that look like credentials: API keys, passwords, tokens. If it finds anything that smells like a secret, it stops cold. It's the inspector that saves you from the most expensive accident of all, and that's why it runs among the very first — even before installing anything, on the clean git tree, so that key doesn't take a single step further toward the public repository.

2 · Security gate (Supabase advisors) — did this change open a hole in the database? This is the head inspector, and that's why it runs first of the ones that check your code. It asks Supabase directly: did any user table end up without its lock (RLS)? did someone create a function with dangerous permissions? was an access granted that shouldn't have been? If the answer is yes, it blocks. This is the one that protects your users' data from a silent oversight.

3 · Type-check — do the types line up? In modern programming, every piece of data has a "type" (this is a number, this is text, this is a date). This inspector confirms you're not, for example, adding a text to a date. It catches a huge family of bugs before the app even starts — errors that would otherwise show up in the user's face at the worst possible moment.

4 · Lint — is the code clean? The linter is the inspector of bad habits: variables that are declared and never used, dead code, patterns known to cause problems. It's not aesthetics for the sake of it — messy code is where bugs hide. A linter forces you to keep the house tidy so the real dirt stands out.

5 · Format — is the formatting consistent? That all the code looks the same: same spacing, same quotes, same style. It sounds like a nitpick, but it's a common language. When several people (or several AI sessions) touch the same project without an agreed format, every change mixes what you did with a swarm of shifted quotes and reshuffled indentation — and you can no longer tell the idea from the noise. The inspector imposes the same dialect for everyone, once and for all, so nobody ever has to argue about it.

6 · Tests — does what used to work still work? This is the one that catches regressions, pain #3 from above. They're automatic tests that verify the key functions still give the right result. You fixed button A; the tests confirm that B, C, and D still run. It's the inspector that lets you make big changes without fear, because you know that if you break something, it tells you instantly.

7 · Build — does it actually compile? The last inspector assembles the app from scratch, as if it were about to be published. Because it's one thing for it to "work on your computer" and another for it to build cleanly from the ground up. If the build fails here, at the gate, that's infinitely better than failing in production with users staring at a blank screen.

The cost · why this is practically free

You'd expect an enterprise-grade guardian to cost money. It doesn't. This one costs ~$0 and adds about ~15 seconds per check. Honest breakdown: Supabase advisors are free. GitHub Actions (the engine that runs the inspectors) gives you 2,000 free minutes a month on private repositories — and it's unlimited and free on public repositories. A run of all 7 takes seconds, so with 2,000 minutes you do thousands of checks a month without paying a cent.

The repo · what you're going to copy

You don't have to invent anything. The whole guardian is packaged in a public, verified repository, ready to copy. It's 4 files you bring into your project, plus a step-by-step installation guide. It's written in pure JavaScript and doesn't depend on anything weird.

The installation protocol · once, for good

Here's the good part: you install it once and it protects you forever. There's no daily maintenance, nothing to remember to run. It lives in your repository and fires on its own with every change. The installation is 6 steps, and the master prompt below hands them to your AI so it does them with you. First, look at the full map to understand what's going to happen.

// Step 3: the script you add to your package.json (in the "scripts" section)
{
  "scripts": {
    "db:advisors:gate": "node scripts/supabase-advisors-gate.mjs"
  }
}

# The 2 secrets from step 5 are created in GitHub, NOT in the code:
# Repository → Settings → Secrets and variables → Actions → New secret
#
#   SUPABASE_PROJECT_REF   → your project's ref (changes per project)
#   SUPABASE_ACCESS_TOKEN  → your account token (the same for all your projects)
#
# The gate is built to skip itself (with a warning) if these secrets are missing,
# so it never breaks a project that doesn't have them configured yet.

The master prompt · paste it to your AI and have it install it for you

This is the only prompt you need. You paste it to your coding agent (Claude Code, Cursor, or whichever you use) while standing inside your project, and it walks you through the 6 steps, tweaking the 3 values for you and explaining every move. Fill in the [brackets] with your own details before sending it.

I want to set up in this project a continuous integration (CI) guardian that reviews every change before it reaches production. The template is in the public repo github.com/MentexDev/NeuralOS-CI-Blindaje and it brings 7 inspectors: Gitleaks (secrets), the Supabase advisors security gate (which runs FIRST of the ones that check the code), type-check, lint, format, tests, and build. If ONE fails, the change is blocked.

Context for my project:
- Database: Supabase.
- Package manager: [npm / pnpm / yarn].
- Name of my package (the "name" in package.json): [name].

Guide me step by step, without me having to know how to program, and in this order:

1. Bring in the 4 template files (backend-ci.template.yml, gitleaks.toml.template, scripts/supabase-advisors-gate.mjs, and scripts/supabase-advisors-allowlist.json) and put them where they go. The workflow must end up in .github/workflows/ WITHOUT the .template suffix.

2. Find the 3 <<<CAMBIAR>>> markers in the files and replace them with my project's real values (folder, paths, package name). Show me exactly what you changed in each one.

3. Add to my package.json the script "db:advisors:gate": "node scripts/supabase-advisors-gate.mjs" without deleting my existing scripts.

4. Explain to me EXACTLY where I find my PROJECT_REF in Supabase, and how I generate my account ACCESS_TOKEN.

5. Tell me step by step how to create the 2 secrets in GitHub (SUPABASE_PROJECT_REF and SUPABASE_ACCESS_TOKEN). Remind me they must NEVER go inside a project file, only in GitHub Secrets.

6. Remind me to enable "Leaked Password Protection" in Supabase (Auth → Settings).

At the end:
- Give me the exact command to commit and push these files, and tell me what I should see in GitHub's checks tab (the 7 inspectors running, and which one runs first).
- If any inspector would turn red with my project as it stands right now (for example, I have no tests, or my code has type errors), warn me BEFORE and tell me the simplest way to get it to green honestly, without disabling the inspector.

The habit · where this lives in your day-to-day

The beauty of the guardian is that it doesn't demand discipline from you. It's not a habit you have to remember like "drink water" or "exercise." Once installed, it fires on its own every time you ship a change. Your only job is to watch the color: green, keep going; red, fix what the inspector points to before continuing.

The moment you experience it is right when you push a change to GitHub (or when you open a "pull request," if you work with branches — see the parallel branches resource). That's when GitHub launches the 7 inspectors automatically. In seconds you have the verdict. If you work with AI, this is the point where its builder-mode optimism meets an auditor that doesn't get excited: the machine coldly reviews what the AI built hot.

The easiest paths · what you do and what the machine does

To make it crystal clear where you put your hand and where you don't: you do the installation ONCE (with the prompt above, your AI walks you through it). After that, everything is automatic. Here's the real split of effort.

Closing · a guardian that never sleeps

Building with AI is fast and addictive, and that speed is exactly what makes it dangerous: you go so fast that you don't see everything that gets shipped. The guardian doesn't slow you down — it lets you go fast with a net underneath. Every change passes through 7 inspectors in seconds, and if something smells off, it stops before it touches a single user. It costs zero, you set it up once, and it gives you something money usually can't buy: sleeping soundly knowing nothing broken reaches production by oversight.