Project rules the agent cannot skim past

Why checking at the end is too late

Friday, 11:00, review before the release. The agent has bypassed the layering and written straight from the controller into the database. The rule was in the rules file. It was there last time, too.

The usual way is: generate first, check afterwards. A linter, a scanner, a review, and whatever fails gets reworked. That holds for individual files. In a project of hundreds of parallel work steps, a structural mistake from step 12 has propagated by step 200. Finding it then is no longer rework but rebuilding, and the context it arose in is long gone. That is why Anvil Coder checks at every step, not at the end.

What stands in every prompt

The invariants do not live in documentation a model might have read. They stand in every prompt, at every step, for every stack.

OWASP Top 10

The ten most common security mistakes in web applications, as a rule while building instead of a checklist at the end.

SOLID

Five principles of object-oriented design that keep a class from serving too many masters.

KISS

The simplest solution that solves the problem. Not the most elegant one somebody could build.

DRY

The same decision lives in one place. Copies drift apart, and they do so silently.

Clean Code

Names that say what they mean; functions that do one thing; comments that explain the why.

Your own rules

The invariants that ship with the system are the baseline, not the limit. A particular layering, a naming scheme, a ban on certain libraries: you store them as your own guardrails, and they are loaded into every prompt exactly like the built-in ones. Store a rule machine-readably and it is also checked against the result; as prose it acts in the prompt.

From live operation the system also collects suggestions for new guardrails. None of them is applied by itself: the only way into the catalogue is your approval.

This is the point where architecture governance stops being a document nobody reads and starts being a property of the system.

Blocking or advisory

Every rule carries a severity. A blocking rule halts the run the moment it is violated; an advisory one shows up as a note without stopping it. When a rule does not fit a project, you relax it with a justification or disable it for a limited time where the rule allows it. Some rules are structurally protected and stay in force.

What guardrails do not do

They do not replace review. A system that checks every step against the same invariants produces consistent code, not necessarily correct code. Whether the requirement is right, whether the domain slicing holds, whether the solution fits the problem: that remains your decision, and Anvil Coder is built so that it stays with you. Which actions need an approval is something you configure per project.

How a rule moves from the wiki into the run, with categories, the #RULE pattern and the proposal inbox, is the subject ofGuardrails for AI coding agents.

For security reviewers

If you have to vet the catalogue before handing it to a team, here are the facts.

Eight stacks in the catalogue

A baseline for every stack, plus Spring Boot, Node/Web, React/Vite, FastAPI, Astro, Next.js and Nuxt. Every project automatically gets the packs that fit its technology.

Versioned

Every rule pack carries a version. Which version a run in flight sees never changes retroactively.

Two update channels

Fast picks up the newest version automatically. Stable picks up a version only once we have explicitly promoted it.

Signed

The catalogue is signed with an Ed25519 key; every rule file carries its fingerprint in a signed manifest. The rules that bind a run are exactly the approved ones.

Choose your starting point