Verify against the system, not a document

When a document says a tool cannot run, or that a path is closed, test it before designing around it. On the Clarity 2 build this rule paid for itself twice.

What was written down

Two limits were recorded and built around. The agent doing the building could not reach the repository's remote, which meant no push and no enforcement of the guard against pushing to the main branch. Its environment also blocked the repository's lint, test and build commands, which were therefore left to the checker.

What the machine said

Both were false. A dry-run push to the main branch was refused by the pre-push hook, with the hook's own message. A dry-run push to a new branch ran the hook's own lint, test and build, all passed, and completed negotiation with the remote leaving it unchanged. Then npm run lint, npm test and npm run build each exited zero inside the repository.

What changed

The maker now verifies its own work before handing off, the pre-push hook repeats that check, and CI runs it a third time (the Clarity 2 build process). The spec clause that told the maker not to run the tools is left as written, as the record of what was asked at the time, and no new spec may repeat it. The earlier finding that the agent had no push path was superseded: the one guard against a push to the main branch is now known to be armed in the agent's own environment.

Why it generalises

A document describes the machine someone believed in when they wrote it. Where believing it wrongly costs a workaround, or leaves a guard that nothing enforces, the test wins.

The private knowledge base states the same rule for its own files: the repository or the database wins over the project file, and the project file wins over the master notes. Where the master disagrees with a project file, the master is the one that is wrong.