Rules and checks

When the agent stops and when you decide

The agent stops when a script detects a problem you cannot assess from the outside, such as a review of an outdated version. For risks you can judge, it explains the risk, lets you decide how to proceed and records your decision. See records and risk.

Rules checked in every project

Each rule says who checks it, when the check runs, what happens if it fails and what it does not cover.

Rule	Checked by and when	If the check fails	Not covered
A merge requires your approval for the named change, unless automatic merging is enabled.	The merge script checks when it runs. The Git pre-push hook refuses direct pushes to main.	The script leaves the pull request open. The hook refuses the push.	Someone with repository access can merge by hand if GitHub does not protect the private repository.
Live changes made through the kit’s scripts require your approval for the named change.	The approval script checks before each approved live change and merge.	The script refuses the change if it cannot find an unused approval for that exact action.	A host tool used outside the kit. Claude Code also asks before certain approval commands.
Scripts check secrets in commands, output, records and commits.	Claude Code hooks check before and after tool calls. Push and project checks scan commits.	The hook refuses a command or push, or the project check fails.	Tool-call hooks apply to Claude Code. A record written manually is checked when it falls within a later scan.
The project check must pass before a merge.	The merge script reads the GitHub check result when it runs.	The script stops and leaves the pull request open. A missing result does not count as a pass.	This rule covers the check result, not every possible defect in the tool.
A merge uses the exact saved version that was reviewed.	The project review check and merge script compare the review record with the current version.	The check fails or the merge script stops.	If a different GitHub login has not approved the version reviewed, the merge script reports the review as unverified.
A launch on a supported recipe requires a confirmed backup and a defined rollback step. Later launches also require an earlier build to be available.	The launch script checks before each launch.	The script stops the launch.	Without a recipe, the script cannot run the recipe checks. A first launch has no earlier build to restore.
An accepted risk remains recorded as accepted.	The agent retains the acceptance in project records. The project risk-area check reports accepted areas. Maintainer tests, including the replay state check and risk-area test, test this behaviour in temporary projects.	Maintainer tests report a mismatch when the tested state is incorrect.	The maintainer tests do not run in your project. They do not prevent an agent from manually changing an acceptance to “done”.

What a result means

Every check that can stop a merge reports one of five results.

Result	Meaning	Effect on a merge
Pass	The check found no problem in what it checked.	None. The result is only reported.
Fail	The check found a problem.	The merge stops.
Not run	The check did not start, or the tool crashed.	The merge stops. The kit never shows it as a pass.
Inconclusive	The check could not reach a conclusion.	A person must review the result before approving the merge.
Not applicable	The check does not apply to this change.	None. The result is only reported.

The result policy defines these outcomes and their effect on merging. Hosting recipe checks report in plain language instead; when a check cannot run, it reports “not checked”.

When a project lacks a prerequisite for a check, the check can start in report-only mode: it reports its limits without claiming a pass. You decide when to make it enforced, and the decision is recorded with the date. This does not turn a required project check that failed or did not run into permission to merge.

How the kit tests itself

• Scripts check the kit’s own files and rules. One command runs the suite and identifies each failing check.
• A mutation run deliberately breaks one safeguard at a time in a temporary copy and reports which checks detect it.
• Replays run scripted conversations and grade the agent’s behaviour. Each test project contains a fake secret, and the replay check fails the run if that secret appears in its output or saved records.
• Each release is rebuilt and compared with the reviewed copy. The release steps say how.

These checks provide evidence about the kit, but do not establish that a tool built with it is safe.