A rule in an instruction file is a request

An agent reads your rules file and usually follows it. For the rules that protect main, usually is not enough.

Why a rule in a file is only a request

A rules file goes into the agent's context. The agent can forget it, misread it or decide it doesn't apply this time. Nothing stops the action that breaks it.

A rule written only in an instruction file is a request.

That doesn't make the file useless. In the factory's own tests, the rules file made the model refuse a blocked action before the guard was even asked. It is the first layer, not the last.

Three layers

Many AI coding tools can run a script at fixed moments; some cannot. The factory uses these hooks like this:

• Before a command or a file write, a guard looks at the action. It can block it, with a reason the agent sees. It stops an agent from writing the control files: the checks, the CI settings and the rules file itself.
• After a file write, lint runs on that one file. It warns the agent and never blocks.
• When the agent wants to stop, the full gate runs. If it fails, the agent is told why and sent back, at most twice. On the third failure it stops and a person takes over.

A person who owns the control files can let the agent change them. That switch is read only from the shell, never from a settings file, because a settings file is something an agent could write.

A guard is a help, not a wall

A guard that reads the text of a shell command cannot be complete. A script the command runs, a variable or a wildcard in a path, or a link made in the same command can get past it. A person can switch hooks off. If the hook script can't start, a tool may go on with the action.

So say plainly what each hook does not stop, and don't call a guard finished.

The wall is the required check

The real gate runs where the author of a change can't reach it: in CI, on every pull request, with the scripts and settings from main. A pull request is judged by the rules of main, not by rules it brings itself. When a local hook passes a change to the rules and CI refuses it, that is the design working. One gap: the code host may take the CI workflow file itself from the pull request, so give that file a named owner who must approve changes to it.

Write down, for each rule, whether a machine enforces it or people keep it by agreement. Both are fine. Mixing them up is not.

Try it

In your own repository:

1. List every rule in your rules file. Mark each one: request, hook, or required check.
2. Pick one request that protects main. Write a check that fails when the rule is broken.
3. Plant a fault that breaks the rule and watch the check go red. A green run alone shows nothing.