Writing a requirement in Rules does not mean an Agent will follow it. Rules can be forgotten or skipped, and even if the Agent claims to have followed them, the result remains unconfirmed without verification. Turning checkable rules into mandatory checks that block further progress on failure reduces reliance on the executor's voluntary compliance.
For example, a project may prohibit Controllers from accessing Repositories directly. A reminder in Rules may still be ignored, and functional tests may pass despite the violation. Encoding this dependency rule in an architecture check and requiring it to pass before merging blocks that violation:
Controller → Repository Check fails; merge blocked
Controller → Service → Repository Passes this dependency check
A read-only database account is more direct. A rule prohibiting data changes can still be violated. If the account's effective privileges on the target tables allow only reading, the database rejects direct attempts to modify those tables through that account. The permission restriction remains effective even if the Agent forgets the instruction.
This reliability has a defined scope: the architecture check blocks only the dependency violations it covers, and read-only privileges restrict the corresponding operations through that account. Checks must actually run, and failure must block further progress. Printing a warning while still allowing a merge does not enforce the rule.
When the main effort shifts from production to verification, making automatically checkable requirements mandatory can reduce the burden of manual verification.
